robots.txt

Unsicher, ob deine robots.txt schadet statt hilft?

Wir prüfen, was tatsächlich gesperrt ist, ob Suchmaschinen deine Seite vollständig rendern können und ob alte Regeln aus früheren Betreuungen noch mitlaufen.

Die robots.txt ist eine Textdatei im Wurzelverzeichnis einer Domain, mit der Betreiber Suchmaschinen-Crawlern mitteilen, welche Bereiche sie abrufen dürfen und welche nicht. Sie steuert das Crawling, nicht die Indexierung — eine gesperrte Seite kann trotzdem in den Suchergebnissen erscheinen. Die Einhaltung ist freiwillig; seriöse Crawler halten sich daran, andere nicht.

Kurz zusammengefasst:

• Liegt immer unter /robots.txt im Wurzelverzeichnis — nirgendwo sonst.
• Steuert das Abrufen, nicht das Erscheinen im Index.
• Wer eine Seite aus dem Index halten will, braucht noindex — und darf sie dann nicht per robots.txt sperren.
• Sie ist öffentlich lesbar und taugt nicht als Zugriffsschutz.
• Gehört als Verweisziel für die XML-Sitemap genutzt.

Der wichtigste Denkfehler

„Ich sperre die Seite in der robots.txt, dann ist sie aus Google raus.“ — Das ist falsch, und der Irrtum richtet regelmäßig Schaden an.

Die robots.txt verhindert, dass eine Seite abgerufen wird. Kennt die Suchmaschine die URL aus anderer Quelle — etwa durch einen Link von außen —, kann sie die Adresse trotzdem in den Index aufnehmen. Sie zeigt dann einen Treffer ohne Beschreibung an, weil sie den Inhalt nicht lesen durfte.

Noch unangenehmer ist die Kombination: Wer eine Seite per robots.txt sperrt und ein noindex auf ihr platziert, erreicht das Gegenteil des Gewünschten. Die Suchmaschine darf die Seite nicht abrufen und sieht das noindex deshalb nie.

Aufbau

Die Datei besteht aus Blöcken. Jeder beginnt mit User-agent und richtet sich an einen bestimmten Crawler; * gilt für alle.

• User-agent: — für wen der Block gilt
• Disallow: — was nicht abgerufen werden soll
• Allow: — Ausnahme innerhalb eines gesperrten Bereichs
• Sitemap: — vollständige URL zur Sitemap, gilt unabhängig von den Blöcken

Zwei Regeln, an denen es oft scheitert: Ein Crawler befolgt nur den für ihn passendsten Block, nicht mehrere gleichzeitig. Und bei widersprüchlichen Angaben gewinnt bei Google die spezifischere Regel, nicht die zuerst genannte.

Was Sperren kostet

Ein häufiger und teurer Fehler ist das Aussperren von CSS und JavaScript. Suchmaschinen rendern Seiten heute wie ein Browser. Wer die Gestaltungs- und Skriptdateien sperrt, lässt die Suchmaschine eine kaputte Seite sehen — mit Folgen für die Bewertung der Darstellung auf Mobilgeräten und für alles, was per JavaScript nachgeladen wird.

In WordPress betrifft das vor allem pauschale Sperren auf /wp-includes/ oder /wp-content/. Solche Regeln stammen aus Anleitungen von vor über zehn Jahren und richten heute mehr Schaden an als Nutzen.

Sinnvolle Einsätze

• Endlose Parameterkombinationen aus Filtern und Sortierungen, die Crawler beschäftigen, ohne Inhalt zu liefern
• Interne Suchergebnisseiten
• Sehr große Medienbereiche, die nicht gefunden werden sollen
• Der Verweis auf die Sitemap — die wohl nützlichste Zeile der Datei

Für alles andere gilt: Im Zweifel nichts sperren. Eine robots.txt, die nur die Sitemap nennt und sonst alles erlaubt, ist für die meisten Websites die richtige.

Crawler von KI-Systemen

Betreiber von KI-Diensten setzen eigene Crawler ein, die sich über die robots.txt ansprechen lassen. Wer nicht möchte, dass Inhalte für das Training verwendet werden, kann diese gezielt aussperren.

Das ist allerdings eine Abwägung, keine reine Schutzmaßnahme: Dieselben oder verwandte Crawler holen häufig auch die Inhalte, die in KI-Antworten zitiert werden. Wer alles sperrt, verschwindet damit unter Umständen aus genau den Antworten, in denen er vorkommen möchte — siehe GEO. Die Entscheidung sollte bewusst fallen und nicht als Nebenwirkung einer kopierten Beispieldatei.

Prüfen

Die Datei ist unter deine-domain.de/robots.txt im Browser abrufbar — der erste und einfachste Test. In der Google Search Console lässt sich zusätzlich sehen, welche Fassung abgerufen wurde und ob es Fehler gab.

WordPress erzeugt die Datei virtuell, wenn keine echte Datei existiert. Sobald eine physische robots.txt im Wurzelverzeichnis liegt, gewinnt diese — und Plugin-Einstellungen laufen ins Leere. Das ist eine häufige Fehlerquelle bei Websites, die schon mehrere Betreuer hatten.

Häufige Fragen

Verhindert die robots.txt, dass eine Seite bei Google erscheint?

Nein. Sie verhindert nur das Abrufen. Ist die URL anderweitig bekannt, kann sie trotzdem im Index landen — dann ohne Beschreibung. Wer eine Seite sicher aus den Ergebnissen halten will, nutzt noindex und erlaubt das Crawling.

Kann ich mit der robots.txt Inhalte schützen?

Nein. Die Datei ist öffentlich abrufbar und listet damit sogar auf, welche Bereiche interessant sein könnten. Vertrauliche Inhalte gehören hinter einen Passwortschutz.

Soll ich wp-content oder wp-includes sperren?

Nein. Diese Empfehlung ist veraltet. Suchmaschinen brauchen Zugriff auf CSS und JavaScript, um die Seite so zu sehen wie ein Besucher. Pauschale Sperren führen zu falschen Bewertungen der Darstellung.

Brauche ich überhaupt eine robots.txt?

Zwingend nicht. Fehlt sie, wird alles gecrawlt. Sinnvoll ist sie trotzdem — schon wegen des Verweises auf die Sitemap.

Soll ich KI-Crawler aussperren?

Das ist eine Abwägung. Sperren schützt vor der Nutzung als Trainingsmaterial, kann aber auch dazu führen, dass die Inhalte in KI-Antworten nicht mehr als Quelle auftauchen. Wer auf Sichtbarkeit in KI-Systemen setzt, sollte sehr gezielt vorgehen.

Warum wirkt meine robots.txt-Einstellung im Plugin nicht?

Vermutlich liegt eine echte Datei im Wurzelverzeichnis. WordPress erzeugt die robots.txt nur dann virtuell, wenn keine physische Datei vorhanden ist — existiert eine, hat sie Vorrang.