Robots.txt Ratgeber

Robots.txt für Subdomains: So prüfen wir den Gültigkeitsbereich

Unser Verfahren für Protokoll, Host, Port, www, Staging und Deployment-Ownership, bevor wir robots.txt-Regeln ändern.

Von Robots.txt Tools Editorial TeamZuletzt geprüft am 2026-10-012 Min. Lesezeit

Redaktionelle Methode: Dieser Leitfaden dokumentiert den Prüfablauf des Robots.txt Tools Editorial Teams. Formulierungen in der ersten Person beschreiben diesen Ablauf und behaupten keine Kundenarbeit oder persönlichen Fallstudien.

Robots.txt für Subdomains: So prüfen wir den Gültigkeitsbereich

Wenn eine Regel korrekt aussieht, aber nicht wirkt, prüfen wir zuerst den Scope. Robots.txt gilt für eine konkrete Origin aus Protokoll, Host und Port.

Wir trennen jede Origin

https://example.com/robots.txt
https://www.example.com/robots.txt
https://shop.example.com/robots.txt
http://example.com/robots.txt
https://example.com:8443/robots.txt

Zwischen diesen Origins gibt es keine automatische Vererbung.

Wir erstellen eine Host-Liste

Production, www, Shop, Docs, Preview und Staging werden separat abgerufen. So erkennen wir veraltete Dateien, 404-Antworten oder unterschiedliche Plattformen.

Wir klären Deployment-Ownership

Framework, CMS, CDN oder Reverse Proxy können die öffentliche Antwort erzeugen. Deshalb ändern wir erst dann Code oder Einstellungen, wenn klar ist, welche Schicht /robots.txt ausliefert.

Wir testen auf dem richtigen Host

Eine Shop-URL prüfen wir gegen die Shop-Policy. Der Tester zeigt die gewinnende Regel; der Checker bestätigt die Live-Datei.

Staging braucht echte Sicherheit

Private Umgebungen schützen wir mit Authentifizierung oder Netzwerkzugriff. Disallow: / ist keine Sicherheit. Bei öffentlichen Previews prüfen wir zusätzlich noindex.

Unser Scope-Gate umfasst HTTP/HTTPS, Host, Port, www, Subdomains, Migrationen und die tatsächlich veröffentlichte Antwort.

Scope gilt pro Origin

robots.txt gehört zur Kombination aus Protokoll, Host und Port. https://example.com/robots.txt steuert nicht automatisch shop.example.com, www.example.com, HTTP oder einen anderen Port. Deshalb inventarisieren wir jeden öffentlich erreichbaren Origin und rufen dort jeweils /robots.txt ab.

Das ist besonders bei CDN-Migrationen, Wechseln zwischen www und Apex sowie Plattform-Splits wichtig. Eine korrekte Datei auf der Hauptdomain behebt keinen veralteten Robots-Stand auf einem Subdomain-System.

Redirects verschmelzen Policies nicht

Auch wenn www auf die Root-Domain weiterleitet, prüfen wir die konkrete Redirect-Kette von /robots.txt. Wir identifizieren, ob Anwendung, CDN, CMS oder Plattform die Antwort besitzt, und ändern genau diese Ebene. So vermeiden wir Regeln in einer Datei, die den betroffenen Origin gar nicht kontrolliert.

Passende Anleitungen