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-09-131 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.

Passende Anleitungen