robots.txt

Die robots.txt ist eine einfache Textdatei im Stammverzeichnis einer Website, die Suchmaschinen-Crawlern Anweisungen gibt, welche Bereiche der Seite sie besuchen dürfen und welche nicht. Sie folgt dem Robots Exclusion Protocol und ist unter /robots.txt direkt im Root der Domain erreichbar. Die Datei ist kein Sicherheitsmechanismus, sondern eine höfliche Aufforderung an wohlmeinende Bots.

Technischer Hintergrund

Die robots.txt arbeitet mit einfachen Direktiven: User-agent gibt an, welcher Bot angesprochen wird (z. B. Googlebot oder * für alle). Disallow sperrt einen Pfad, Allow erlaubt explizit einen Unterpfad innerhalb eines gesperrten Bereichs. Zusätzlich kann mit Sitemap der Pfad zur XML-Sitemap angegeben werden. Ein Crawl-delay wird von einigen Bots (nicht Google) als Hinweis zur Crawl-Geschwindigkeit respektiert.

WordPress generiert eine virtuelle robots.txt automatisch, wenn keine physische Datei vorhanden ist. Diese Standard-Version sperrt lediglich /wp-admin/ und erlaubt /wp-admin/admin-ajax.php. SEO-Plugins erweitern diese Ausgabe häufig um zusätzliche Regeln. Sobald eine physische robots.txt im httpdocs-Verzeichnis liegt, wird die virtuelle Version von WordPress ignoriert.

Wichtig zu verstehen: Die robots.txt verhindert nicht die Indexierung. Wenn eine Seite von extern verlinkt ist, kann Google sie trotz Disallow-Regel indexieren – nur nicht crawlen. Für echte Indexierungssteuerung sind Canonical URLs und Meta-Robots-Tags (noindex) erforderlich.

Bedeutung für die WordPress-Wartung

Eine falsch konfigurierte robots.txt kann erheblichen Schaden anrichten: Im schlimmsten Fall sperrt sie versehentlich die gesamte Website für Suchmaschinen. Dies passiert häufig nach einem Relaunch, wenn die Staging-Einstellung Disallow: / versehentlich auf die Live-Seite übernommen wird. Bei der Wartung sollte die robots.txt regelmässig geprüft werden – besonders nach Umzügen, Domain-Wechseln oder dem Wechsel zwischen Staging und Produktion.

Häufige Probleme

• Disallow: / sperrt versehentlich die gesamte Website nach einem Relaunch oder Staging-Übernahme
• Wichtige Ressourcen (CSS, JS) werden blockiert, was das Rendering durch Google verhindert
• Die physische Datei und die virtuelle WordPress-robots.txt widersprechen sich
• SEO-Plugins überschreiben benutzerdefinierte Regeln ohne Vorwarnung
• Veraltete Disallow-Regeln sperren Bereiche, die längst öffentlich sein sollten
• Die Datei enthält Syntaxfehler (z. B. fehlende Zeilenumbrüche), die Bots verwirren

Best Practices

• Die robots.txt so schlank wie möglich halten – nur wirklich nötige Sperren eintragen
• Niemals sensible Bereiche ausschliesslich über robots.txt schützen – dafür gibt es Authentifizierung und HTTPS
• Nach jedem Relaunch oder Staging-zu-Live-Übernahme die robots.txt als erstes prüfen
• Den Verweis auf die Sitemap immer einbinden: Sitemap: https://example.com/sitemap.xml
• Die Datei über die Google Search Console mit dem robots.txt-Tester validieren
• WordPress-interne Pfade wie /wp-includes/ oder /wp-content/uploads/ nicht pauschal sperren, da Suchmaschinen Zugriff auf eingebettete Ressourcen benötigen
• Änderungen dokumentieren und versionieren, damit im Fehlerfall schnell zurückgerollt werden kann