robots.txt erstellen 2026: Anleitung mit Beispielen, KI-Crawlern und einem Fehler, den wir selbst hatten

Eine robots.txt zu erstellen dauert zwei Minuten. Eine Textdatei, ein paar Zeilen, hochladen, fertig. So steht es in fast jeder Anleitung, und im Prinzip stimmt das auch. Wir haben für diesen Artikel trotzdem nicht einfach die Syntax abgeschrieben, sondern nachgemessen, was mit unserer eigenen robots.txt auf getmind.io wirklich passiert: wer sie abholt, wer sich daran hält und wie verschiedene Programme sie lesen.

Das Ergebnis war unangenehmer als erwartet. Unsere eigene, nur fünf Zeilen lange robots.txt wurde von Pythons Standard-Parser genau umgekehrt gelesen wie von Google. Zwei Verzeichnisse, die wir gesperrt hatten, galten für jedes Programm, das diesen Parser benutzt, als freigegeben. Der Grund war eine einzige Zeile, die in vielen Vorlagen im Netz steht und die wir gedankenlos übernommen hatten. Außerdem zeigte sich in den Logs: Ein gesperrter Pfad in der robots.txt ist für Angreifer eine Einladung. Von 148 Anfragen auf eine Datei in unserem gesperrten Ordner kamen 118 von IP-Adressen, die vorher die robots.txt gelesen hatten.

In dieser Anleitung erfährst du, wie du eine robots.txt erstellst, die jeder Crawler gleich versteht, welche Vorlagen für WordPress, Shops und KI-Crawler sinnvoll sind, wo die Grenzen liegen und welche Fehler wir selbst gemacht haben. Alle Zahlen stammen aus unseren eigenen Server-Logs vom 9. bis 19. Oktober 2026 (101.447 Zugriffe) und aus Tests vom 19. Oktober 2026.

Das Video von Jens Steingröver (SEO Online Consulting) ist von 2023 und damit älter als unsere übliche Grenze. Wir haben es trotzdem gewählt, weil es die Grundlagen auf Deutsch ruhig und korrekt erklärt; an der Syntax hat sich seitdem nichts geändert. Was im Video fehlt, sind die KI-Crawler und die Parser-Unterschiede. Darum geht es weiter unten.

Was ist eine robots.txt?

Die robots.txt ist eine einfache Textdatei im Hauptverzeichnis deiner Domain, also immer unter https://deine-domain.de/robots.txt. Sie sagt Crawlern, also automatischen Programmen von Suchmaschinen, KI-Firmen und SEO-Tools, welche Bereiche deiner Website sie abrufen dürfen und welche nicht.

Das Format heißt offiziell Robots Exclusion Protocol. Es existiert seit 1994, war aber fast 30 Jahre lang nur eine informelle Absprache. Erst im September 2022 wurde es als RFC 9309 offiziell standardisiert, maßgeblich auf Betreiben von Google. Dieser Standard ist wichtig, weil er Fragen klärt, die vorher jeder Crawler anders beantwortete. Eine davon hat uns erwischt, dazu gleich mehr.

Drei Dinge solltest du von Anfang an wissen:

1. Die robots.txt ist eine Bitte, keine Sperre. Seriöse Crawler halten sich daran, technisch erzwungen wird nichts. Jeder Browser, jedes Skript und jeder Angreifer kann gesperrte URLs trotzdem aufrufen.
2. Sie steuert das Crawlen, nicht das Indexieren. Eine gesperrte Seite kann trotzdem in Google erscheinen, wenn andere Seiten auf sie verlinken. Dann steht sie dort ohne Beschreibung („Für diese Seite sind keine Informationen verfügbar“).
3. Sie gilt pro Host und Protokoll. https://www.example.de/robots.txt regelt nur www.example.de, nicht shop.example.de und nicht http://example.de.

Wozu braucht man eine robots.txt?

Die ehrliche Antwort zuerst: Eine kleine Website braucht eigentlich keine robots.txt. Fehlt die Datei und liefert der Server sauber einen 404-Fehler, gehen alle Crawler davon aus, dass sie alles abrufen dürfen. Genau das will eine normale Website meistens auch.

Sinnvoll wird die robots.txt in vier Situationen:

• Crawl-Budget sparen: Online-Shops mit Filtern, Sortierungen und Suchergebnisseiten erzeugen schnell Millionen URL-Varianten. Mit der robots.txt hältst du Crawler aus diesen Endlosräumen heraus, damit sie ihre Zeit für deine echten Produkt- und Kategorieseiten verwenden.
• Server entlasten: Wenn aggressive SEO-Crawler oder KI-Bots deine Datenbank auslasten, kannst du sie gezielt aussperren. Das funktioniert allerdings nur bei denen, die sich an Regeln halten.
• KI-Training steuern: Seit 2023 ist die robots.txt das wichtigste Mittel, um zu entscheiden, ob GPTBot, ClaudeBot, Google-Extended & Co. deine Inhalte für das Training von Sprachmodellen verwenden dürfen.
• Sitemap bekannt machen: Die Zeile Sitemap: ist der einfachste Weg, allen Suchmaschinen deine XML-Sitemap mitzuteilen, auch denen, bei denen du kein Konto hast.

Was die robots.txt nicht kann: Seiten aus Google entfernen (dafür brauchst du noindex), vertrauliche Daten schützen (dafür brauchst du ein Passwort) oder böswillige Bots stoppen (dafür brauchst du eine Firewall oder Rate-Limits).

Aufbau und Syntax: die fünf Befehle, die du kennen musst

Eine robots.txt besteht aus Gruppen. Jede Gruppe beginnt mit einer oder mehreren User-agent-Zeilen und enthält danach Regeln. Mehr ist es nicht.

User-agent: Googlebot
Disallow: /intern/

User-agent: *
Disallow: /tmp/
Disallow: /suche

Sitemap: https://example.de/sitemap.xml

User-agent

Gibt an, für welchen Crawler die folgenden Regeln gelten. * bedeutet „alle, für die es keine eigene Gruppe gibt“. Die Groß- und Kleinschreibung des Namens spielt keine Rolle. Wichtig: Ein Crawler folgt genau einer Gruppe, nämlich der spezifischsten, die zu ihm passt. Hat Googlebot eine eigene Gruppe, ignoriert er die *-Gruppe komplett. Das ist einer der häufigsten Denkfehler: Man sperrt etwas unter * und schreibt dann eine eigene Googlebot-Gruppe, in der die Sperre fehlt.

Disallow

Verbietet alle URLs, deren Pfad mit dem angegebenen Wert beginnt. Disallow: /admin sperrt also auch /administrator, /admin-login und /admin.php. Willst du nur den Ordner sperren, schreib Disallow: /admin/. Ein leeres Disallow: bedeutet „nichts verboten“.

Der Pfad ist case-sensitive: Disallow: /admin sperrt /Admin nicht. Das haben wir im Test bestätigt (siehe unten).

Allow

Erlaubt explizit einen Pfad, meistens als Ausnahme innerhalb eines gesperrten Bereichs:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Allow war lange kein Teil des ursprünglichen Standards, wird aber seit RFC 9309 offiziell unterstützt. Wie Allow und Disallow gegeneinander gewichtet werden, ist genau die Stelle, an der Parser auseinanderlaufen.

Sitemap

Verweist auf deine XML-Sitemap. Die Zeile gehört zu keiner Gruppe und darf überall stehen, muss aber eine vollständige URL enthalten (https://…, nicht /sitemap.xml). Mehrere Sitemap-Zeilen sind erlaubt.

Wildcards: * und $

Google, Bing und RFC 9309 unterstützen zwei Sonderzeichen in Pfaden:

• * steht für beliebig viele Zeichen: Disallow: /*?sort= sperrt jede URL mit dem Parameter sort.
• $ markiert das Ende der URL: Disallow: /*.pdf$ sperrt alle PDFs, aber nicht /datei.pdf?version=2.

Wir haben das mit einem RFC-konformen Parser geprüft: /a.pdf wurde gesperrt, /a.pdf?x=1 war erlaubt. Genau wie erwartet. Pythons eingebauter Parser dagegen kennt Wildcards überhaupt nicht und hielt auch /a.pdf für erlaubt.

Und was ist mit Crawl-delay, Noindex und Host?

• Crawl-delay ist nicht standardisiert. Google ignoriert es komplett, Bing und Yandex halten sich daran. Wer Googlebot bremsen will, muss das über die Serverantwort (429/503) regeln.
• Noindex in der robots.txt hat Google am 1. September 2019 offiziell abgeschafft. Es wirkt nicht mehr.
• Host war eine Yandex-Erweiterung und ist heute bedeutungslos.

Unser Test: drei Parser, eine Datei, zwei Meinungen

Hier wird es interessant. So sah unsere robots.txt auf getmind.io bis heute Morgen aus:

User-agent: *
Allow: /
Disallow: /tmp/
Disallow: /kaufland-preise/

Sitemap: https://getmind.io/sitemap-index.xml

Sieht vernünftig aus: grundsätzlich alles erlauben, zwei interne Ordner sperren. Diese Form findest du in unzähligen Vorlagen. Wir haben die Datei durch drei verschiedene Parser geschickt und gefragt: Darf GPTBot /tmp/x abrufen?

Der Unterschied liegt im Auswahlverfahren. RFC 9309 und Google sagen: Passen mehrere Regeln, gewinnt die längste, also spezifischste. Disallow: /tmp/ (5 Zeichen) schlägt Allow: / (1 Zeichen). Pythons Standardmodul arbeitet dagegen nach dem älteren Prinzip „die erste passende Regel gewinnt“. Und die erste Regel war Allow: /, die auf absolut jede URL passt. Alles, was danach kommt, wird nie mehr gelesen.

Das ist kein theoretisches Problem. urllib.robotparser steckt in sehr vielen kleinen Crawlern, Skripten und selbstgebauten Scrapern, gerade im KI-Umfeld, wo viele Werkzeuge in Python geschrieben sind. Für alle diese Programme war unsere Sperre unsichtbar.

Zur Gegenprobe haben wir einen zweiten Fall getestet, bei dem auch die RFC-Parser genau hinsehen müssen: Allow: /page gegen Disallow: /*.php für die URL /page.php. Beide Regeln sind gleich lang (fünf Zeichen). Laut RFC 9309 gewinnt bei Gleichstand die am wenigsten einschränkende Regel, also Allow. Unser Node-Parser meldete trotzdem „gesperrt“. Auch RFC-nahe Implementierungen sind sich also in Randfällen nicht einig.

Der Fix: eine Zeile löschen

Die Lösung war trivial. Allow: / ist überflüssig, denn alles, was nicht verboten ist, ist ohnehin erlaubt. Ohne diese Zeile lesen alle drei Parser die Datei identisch:

User-agent: *
Disallow: /tmp/
Disallow: /kaufland-preise/

Sitemap: https://getmind.io/sitemap-index.xml

Diese Version ist seit dem 19. Oktober 2026 auf getmind.io live. Die Lehre: Schreib deine robots.txt so, dass sie nicht von der Auswahllogik abhängt. Konkret: keine pauschalen Allow: /-Zeilen, Allow nur für echte Ausnahmen innerhalb eines Disallow-Bereichs, und die Allow-Ausnahme dann immer länger formulieren als das Disallow, zu dem sie gehört.

robots.txt erstellen: Schritt für Schritt

Schritt 1: Prüfen, ob schon eine existiert

Ruf https://deine-domain.de/robots.txt im Browser auf. Viele Systeme erzeugen automatisch eine. WordPress liefert eine virtuelle robots.txt aus, die nicht als Datei auf dem Server liegt, sondern von PHP erzeugt wird. Shopware, Shopify und viele Baukästen machen das ähnlich. Lädst du dann eine echte Datei hoch, ersetzt sie die virtuelle Version, was du wissen solltest, bevor du dich wunderst, warum deine Yoast-Einstellungen nicht mehr greifen.

Prüf außerdem den HTTP-Statuscode, nicht nur den Inhalt. Mit curl -I https://deine-domain.de/robots.txt siehst du ihn sofort. Google behandelt die Codes sehr unterschiedlich:

Besonders tückisch ist der 5xx-Fall: Wenn deine robots.txt wegen eines Serverproblems tagelang einen 500er liefert, crawlt Google im schlimmsten Fall gar nichts mehr. Bei getmind.io liefert die Datei 200 mit content-type: text/plain; charset=utf-8, und http:// sowie www. leiten sauber per 308 bzw. 301 auf die HTTPS-Version um.

Schritt 2: Entscheiden, was gesperrt werden soll

Mach dir eine Liste mit drei Spalten: Was soll gecrawlt werden, was nicht, und welche Crawler willst du gesondert behandeln? Typische Kandidaten für eine Sperre:

• Interne Suchergebnisseiten (/suche, /?s=)
• Filter- und Sortierparameter in Shops (?sort=, ?filter=)
• Warenkorb, Checkout, Kundenkonto
• Staging- oder Testverzeichnisse (die gehören eigentlich hinter ein Passwort, siehe unten)

Nicht sperren solltest du CSS- und JavaScript-Dateien. Google rendert Seiten wie ein Browser. Fehlen ihm die Stylesheets, sieht es eine kaputte Seite und bewertet sie womöglich als nicht mobilfreundlich.

Schritt 3: Die Datei schreiben

Öffne einen einfachen Texteditor (nicht Word!) und speichere die Datei als robots.txt mit UTF-8-Kodierung. Der Dateiname muss klein geschrieben sein. Google liest maximal 500 KiB, alles danach wird ignoriert. Zum Vergleich: Unsere Datei hat 105 Byte, die von Wikipedia 28.275 Byte, beide weit unter der Grenze.

Schritt 4: Hochladen

Die Datei muss ins Stammverzeichnis der Domain, sodass sie direkt unter /robots.txt erreichbar ist. Eine robots.txt in /blog/robots.txt wird von keinem Crawler beachtet. Bei statischen Seiten (Astro, Hugo, Next.js mit Export) legst du sie in den public/-Ordner, bei klassischen Servern per FTP/SFTP ins Webroot.

Wer einen eigenen Server mit Nginx oder Caddy betreibt, kann die Datei auch direkt in der Serverkonfiguration ausliefern, ohne Datei. In Nginx zum Beispiel:

location = /robots.txt {
    default_type text/plain;
    return 200 "User-agent: *\nDisallow: /tmp/\n\nSitemap: https://example.de/sitemap.xml\n";
}

Für eine Staging-Umgebung ist das praktisch, weil die Sperre dann nicht versehentlich mit dem Code auf die Live-Seite wandert.

Schritt 5: Testen

Teste die Datei, bevor du dich darauf verlässt:

• Google Search Console → Einstellungen → robots.txt-Bericht. Dort siehst du, welche Version Google zuletzt abgerufen hat, wann und ob es Fehler gab. Den alten interaktiven robots.txt-Tester hat Google Ende 2023 abgeschaltet.
• Bing Webmaster Tools haben weiterhin einen robots.txt-Tester, mit dem du einzelne URLs prüfen kannst. Mehr zu Bing in unserem Artikel über Bing SEO.
• Mit einem Parser auf der Kommandozeile, wenn du ganz sicher gehen willst. Unser Test oben hat gezeigt, warum es sich lohnt, mehr als einen zu fragen.

Danach dauert es eine Weile, bis die Änderung wirkt. Google speichert die robots.txt in der Regel bis zu 24 Stunden zwischen. In der Search Console kannst du einen erneuten Abruf anstoßen.

Wer liest deine robots.txt? Unsere Logfile-Auswertung

Wir haben alle Zugriffe auf getmind.io vom 9. bis 19. Oktober 2026 ausgewertet: 101.447 Anfragen, davon 1.293 auf /robots.txt. Die häufigsten Abrufer laut User-Agent:

ClaudeBot fragt die Datei etwa zwölfmal pro Tag ab (115 Abrufe in 9,4 Tagen), Googlebot rund zwanzigmal. GPTBot dagegen holte sie in zehn Tagen nur dreimal, rief aber 1.673 andere URLs ab. Das ist kein Regelverstoß: Ein Crawler darf die Datei zwischenspeichern, und Google sagt ausdrücklich, dass es das bis zu 24 Stunden tut.

Wichtige Einschränkung: Diese Zahlen beruhen auf dem User-Agent, also auf der Selbstauskunft des Clients. In unserer Logfile-Analyse zu KI-Crawlern haben wir gezeigt, dass 93 % der Anfragen, die sich als KI-Bot ausgaben, gefälscht waren. Die Tabelle zeigt also, wer behauptet, die Datei zu lesen, nicht wer es wirklich ist. Für die Kernaussage, dass seriöse Crawler die robots.txt regelmäßig abholen, reicht das aber, denn diese Größenordnung deckt sich mit den verifizierten Zahlen aus der älteren Analyse.

KI-Crawler in der robots.txt: GPTBot, ClaudeBot und Co.

Für viele ist das heute der eigentliche Grund, eine robots.txt anzulegen. Die großen KI-Firmen betreiben jeweils mehrere Crawler mit unterschiedlichen Aufgaben, und das ist entscheidend für die Frage, was du sperrst:

Die Unterscheidung zwischen Training und Suche ist der Kern. Wer GPTBot sperrt, verhindert, dass OpenAI die Inhalte für künftige Modelle verwendet. In ChatGPT-Suchergebnissen kann die Seite trotzdem auftauchen, solange OAI-SearchBot erlaubt ist. Wer pauschal alle Bots mit „GPT“ oder „Claude“ im Namen sperrt, verschwindet unter Umständen auch aus den KI-Suchen, und genau dort entsteht gerade ein neuer Traffic-Kanal. Wie sich das auf die Sichtbarkeit in Google auswirkt, erklären wir in Google KI-SEO.

Eine typische Konfiguration für „Training nein, Suche ja“:

# Kein KI-Training
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Google-Extended
User-agent: Applebot-Extended
User-agent: CCBot
Disallow: /

# Alle anderen, inkl. Suchcrawler
User-agent: *
Disallow: /suche

Sitemap: https://example.de/sitemap.xml

Mehrere User-agent-Zeilen untereinander bilden eine gemeinsame Gruppe. Das spart Wiederholungen. Achtung: Die KI-Crawler aus der ersten Gruppe folgen nur dieser Gruppe. Die Regel Disallow: /suche aus der *-Gruppe gilt für sie nicht, was hier egal ist, weil sie ohnehin alles gesperrt haben.

Wie machen das große deutsche Seiten?

Wir haben am 19. Oktober 2026 die robots.txt von 18 bekannten Websites abgerufen und ausgezählt. Ergebnis: 12 der 16 Seiten, die eine echte Datei auslieferten, erwähnen GPTBot ausdrücklich, darunter spiegel.de, zeit.de, faz.net, tagesschau.de, t3n.de, golem.de, amazon.de und chefkoch.de. Spiegel und Zeit sperren GPTBot komplett mit Disallow: /.

Interessant sind die Ausreißer:

• reddit.com braucht keine KI-Liste, denn die Datei sperrt mit User-agent: * und Disallow: / schlicht alle Crawler und regelt den Zugang stattdessen über Verträge.
• wikipedia.org hat mit 28.275 Byte die längste Datei der Stichprobe, nennt GPTBot aber nicht. Wikipedia sperrt vor allem Crawler, die durch zu hohe Last aufgefallen sind.
• heise.de lieferte uns auf /robots.txt den Statuscode 410 Gone, auch mit Browser- und Googlebot-User-Agent. Nach den Regeln von Google bedeutet ein 4xx-Code: Es gibt keine robots.txt, alles ist erlaubt. Ob das gewollt ist oder ob ein Bot-Schutz unseren Server ausgesperrt hat, können wir von außen nicht unterscheiden.
• stackoverflow.com antwortete mit 418 I’m a teapot, einem Scherz-Statuscode, den Bot-Abwehrsysteme gerne für unerwünschte Abrufer verwenden. Auch das ist für einen regelkonformen Crawler formal ein „alles erlaubt“.

Die Stichprobe ist klein und zeigt nur einen Tag. Die Tendenz ist trotzdem eindeutig: Bei Nachrichtenseiten und großen Shops ist die KI-Sperre Standard geworden. Bei einem Firmenblog wie unserem ist die Abwägung eine andere: Wir wollen, dass KI-Assistenten unsere Artikel kennen und zitieren, deshalb sperren wir keinen KI-Crawler.

Die robots.txt ist kein Sicherheitswerkzeug, und unsere Logs beweisen es

Diesen Abschnitt solltest du lesen, bevor du jemals einen geheimen Pfad in die robots.txt schreibst.

Die robots.txt ist öffentlich. Jeder kann sie lesen, und zwar nicht nur Suchmaschinen. Wer dort Disallow: /admin-geheim/ einträgt, veröffentlicht damit eine Liste der Stellen, die er für schützenswert hält.

Wir haben geprüft, was das in der Praxis bedeutet. In unserer robots.txt stand Disallow: /tmp/. In den zehn Tagen der Auswertung gab es 148 Anfragen auf genau /tmp/.env, also eine Datei, in der Webanwendungen gewöhnlich Passwörter und API-Schlüssel ablegen. Die Anfragen kamen von 120 verschiedenen IP-Adressen. 118 der 148 Anfragen (80 %) kamen von IPs, die vorher unsere robots.txt abgerufen hatten, die Hälfte davon innerhalb von gut fünf Sekunden danach.

Zum Vergleich: Bei den allgemeinen Scans auf /.env im Stammverzeichnis, die jede Website im Internet abbekommt, lag dieser Anteil bei 70 %, bei /backend/.env, /api/.env und /app/.env jeweils bei 58 bis 60 %. Unser gesperrter Ordner wurde also überdurchschnittlich oft von Clients angefragt, die vorher die robots.txt gelesen hatten. Das ist ein Hinweis, kein Beweis, denn manche Scanner prüfen /tmp/ ohnehin. Er passt aber zum bekannten Muster: Automatisierte Scanner lesen die robots.txt, nehmen jede Disallow-Zeile als Startpunkt und hängen typische Dateinamen an.

Ein Muster im Detail: Viele dieser Anfragen trugen einen User-Agent, der wie ein KI-Crawler aussah, darunter auch CCBot. Ein echter Crawler, der sich an die robots.txt hält, würde /tmp/ gar nicht anfragen. Wer das trotzdem tut, ist mit hoher Wahrscheinlichkeit nicht der, für den er sich ausgibt.

Unser /tmp/-Ordner war übrigens nie gefährlich: Alle 148 Anfragen bekamen einen 404, weil dort keine .env liegt. Die Konsequenz für dich:

• Vertrauliches gehört hinter eine Authentifizierung, nicht in die robots.txt. HTTP Basic Auth, ein Login oder eine IP-Sperre im Webserver.
• Dateien wie .env gehören nicht ins Webroot. Punkt.
• Unbekannte Admin-Pfade nicht in die robots.txt schreiben. Wenn du sie verstecken willst, verlinke sie nirgends und schütze sie mit einem Passwort. Für Seiten, die nicht in Google erscheinen sollen, ist noindex im HTML-Kopf oder im X-Robots-Tag-Header der richtige Weg.
• Gegen unhöfliche Bots hilft nur Technik: Rate-Limits, eine Firewall wie UFW und automatische Sperren mit Fail2ban.

Vorlagen: robots.txt für typische Websites

Minimal: die meisten Websites und Blogs

User-agent: *
Disallow:

Sitemap: https://example.de/sitemap.xml

Erlaubt alles und nennt die Sitemap. Für die meisten Websites ist das die beste Wahl, und es ist unmissverständlich für jeden Parser.

WordPress

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/

Sitemap: https://example.de/wp-sitemap.xml

admin-ajax.php muss erreichbar bleiben, weil viele Themes und Plugins darüber Inhalte nachladen. Die Allow-Zeile ist länger als die Disallow-Zeile, also lesen Longest-Match- und First-Match-Parser sie gleich, solange sie direkt hinter dem Disallow steht. Mehr zum WordPress-SEO findest du in unserem Vergleich der WordPress-SEO-Plugins.

Online-Shop

User-agent: *
Disallow: /checkout/
Disallow: /account/
Disallow: /warenkorb
Disallow: /*?sort=
Disallow: /*&sort=
Disallow: /*?filter=
Disallow: /suche

Sitemap: https://example.de/sitemap.xml

Die Wildcard-Regeln halten Crawler aus Sortier- und Filtervarianten heraus. Bevor du sie einträgst, prüf in der Search Console, ob diese URLs überhaupt gecrawlt werden. Wenn deine Shop-Software sie bereits mit canonical und noindex versieht, ist eine robots.txt-Sperre sogar kontraproduktiv: Google kann dann das noindex nicht mehr lesen. Für Shopware haben wir die Details in unserem Artikel über Shopware SEO zusammengestellt.

Staging- und Testumgebung

User-agent: *
Disallow: /

Sperrt alles. Ergänzend sollte die Staging-Seite aber immer ein Passwort haben. Und: Pass auf, dass diese Datei nie auf die Live-Seite kopiert wird. Das ist einer der klassischen Fehler, nach denen eine Website über Nacht aus Google verschwindet.

Die häufigsten Fehler beim robots.txt erstellen

1. Disallow: / auf der Live-Seite. Meistens aus der Staging-Umgebung übernommen. Folge: Google crawlt nichts mehr, die Rankings verfallen in den folgenden Wochen.
2. Allow: / als erste Zeile. Unser eigener Fehler. Für Google harmlos, für First-Match-Parser hebt es alle folgenden Sperren auf.
3. CSS und JS sperren. Google sieht die Seite dann nicht so, wie Nutzer sie sehen.
4. Mit Disallow Seiten aus dem Index werfen wollen. Funktioniert nicht. Im Gegenteil: Eine gesperrte Seite kann ihr noindex nicht mehr zeigen und bleibt dadurch eher im Index.
5. Vergessene Gruppen-Logik. Eine eigene Googlebot-Gruppe ersetzt die *-Gruppe für Google vollständig, alle allgemeinen Sperren müssen dort wiederholt werden.
6. Relative Sitemap-URL. Sitemap: /sitemap.xml ist ungültig, es muss die vollständige Adresse sein.
7. Geheime Pfade eintragen. Siehe oben: Die robots.txt ist die erste Datei, die Scanner lesen.
8. Falsche Datei-Kodierung oder Dateiname. Robots.txt oder robots.TXT wird auf vielen Servern nicht gefunden. UTF-8 mit BOM kann bei manchen Parsern die erste Zeile unbrauchbar machen.
9. Dauerhafte Serverfehler. Ein 5xx auf /robots.txt lässt Google im schlimmsten Fall das Crawlen ganz einstellen.

Wenn du WordPress mit Yoast SEO nutzt, zeigt dieses Video von „Einfach Erklärt“ (März 2026), wo du die robots.txt direkt im Plugin bearbeitest, ohne FTP. Achte dabei auf die Punkte aus unserer Fehlerliste: Yoast schreibt dann eine echte Datei, die die virtuelle WordPress-Version ersetzt.

robots.txt, Meta-Robots und X-Robots-Tag: was wofür?

Diese drei Werkzeuge werden ständig verwechselt. Die Kurzfassung:

Entscheidend ist die Reihenfolge: Ein Crawler muss eine Seite abrufen dürfen, um ihr noindex zu sehen. Wer eine Seite per robots.txt sperrt und mit noindex versieht, erreicht das Gegenteil: Google sieht das noindex nie. Willst du eine Seite zuverlässig aus Google entfernen, lass sie crawlbar und setz noindex. Erst wenn sie aus dem Index verschwunden ist, kannst du sie zusätzlich sperren, wenn du das Crawl-Budget sparen willst.

Fazit: robots.txt erstellen, aber kurz halten

Eine gute robots.txt ist kurz, eindeutig und enthält nichts Geheimes. Für die meisten Websites reicht eine Handvoll Zeilen: eine Sitemap-Angabe, eventuell ein paar Sperren für Such- und Filterseiten und eine bewusste Entscheidung zu KI-Crawlern.

Unsere wichtigsten Erkenntnisse aus der eigenen Messung:

• Schreib Regeln, die jeder Parser gleich versteht. Unsere fünfzeilige Datei wurde von Pythons Standardparser umgekehrt gelesen, weil Allow: / oben stand. Eine gelöschte Zeile hat das behoben.
• Seriöse Crawler halten sich daran und fragen oft nach. ClaudeBot holte unsere Datei rund zwölfmal pro Tag ab, Googlebot etwa zwanzigmal.
• Die robots.txt schützt nichts. 80 % der Anfragen auf eine .env-Datei in unserem gesperrten Ordner kamen von IPs, die die robots.txt vorher gelesen hatten.
• Trenne bei KI-Crawlern Training und Suche. Wer alles sperrt, verliert auch die Sichtbarkeit in ChatGPT, Claude und Perplexity.

Wenn du mehr darüber wissen willst, welche dieser Crawler echt sind und welche nur so tun, lies unsere Logfile-Analyse zu KI-Crawlern.

FAQ: robots.txt erstellen

Wie erstelle ich eine robots.txt?

Öffne einen einfachen Texteditor, schreib deine Regeln (mindestens User-agent: * und eine Disallow- oder Sitemap-Zeile), speichere die Datei als robots.txt in UTF-8 und lade sie ins Stammverzeichnis deiner Domain hoch. Sie muss unter https://deine-domain.de/robots.txt mit Statuscode 200 erreichbar sein. Anschließend in der Google Search Console im robots.txt-Bericht prüfen.

Braucht jede Website eine robots.txt?

Nein. Fehlt die Datei und liefert der Server einen 404, gehen alle Crawler davon aus, dass alles erlaubt ist. Sinnvoll ist sie, sobald du Bereiche ausschließen, KI-Training steuern oder deine Sitemap bekannt machen willst. Eine Minimalversion mit Sitemap-Zeile schadet nie.

Wo muss die robots.txt liegen?

Immer im Stammverzeichnis des Hosts, also direkt unter /robots.txt. Jede Subdomain und jedes Protokoll braucht eine eigene Datei: shop.example.de wird von der robots.txt auf www.example.de nicht erfasst.

Kann ich mit der robots.txt eine Seite aus Google entfernen?

Nein, dafür ist sie das falsche Werkzeug. Die robots.txt verhindert nur das Crawlen. Eine gesperrte Seite kann trotzdem im Index bleiben, wenn andere Seiten auf sie verlinken. Zum Entfernen nutzt du noindex und lässt die Seite so lange crawlbar, bis Google sie aus dem Index genommen hat.

Wie sperre ich KI-Crawler wie GPTBot und ClaudeBot?

Lege eine eigene Gruppe mit User-agent: GPTBot, User-agent: ClaudeBot (und ggf. Google-Extended, CCBot, Applebot-Extended) an und darunter Disallow: /. Willst du weiterhin in KI-Suchen auftauchen, lass OAI-SearchBot, Claude-SearchBot und PerplexityBot erlaubt. Diese Crawler sind für die Suche zuständig, nicht für das Training.

Halten sich alle Bots an die robots.txt?

Nein. Seriöse Suchmaschinen und die großen KI-Firmen halten sich nach eigenen Angaben daran, und unsere Logs stützen das für die verifizierten Bots. Scanner, Scraper und Bots mit gefälschtem User-Agent ignorieren sie oder nutzen sie sogar als Wegweiser zu interessanten Pfaden.

Was ist der Unterschied zwischen Disallow und noindex?

Disallow in der robots.txt verbietet das Abrufen einer URL. noindex im HTML oder HTTP-Header erlaubt das Abrufen, verbietet aber die Aufnahme in den Suchindex. Beides zusammen auf derselben Seite funktioniert nicht, weil der Crawler das noindex nie zu sehen bekommt.

Wie lange dauert es, bis Änderungen an der robots.txt wirken?

Google speichert die Datei in der Regel bis zu 24 Stunden zwischen, kann bei Serverproblemen aber auch länger eine alte Version verwenden. In der Search Console kannst du im robots.txt-Bericht einen erneuten Abruf beantragen. Andere Crawler haben eigene Intervalle. In unseren Logs holte ClaudeBot die Datei etwa alle zwei Stunden ab, GPTBot dreimal in zehn Tagen.

Sollte ich Allow: / in meine robots.txt schreiben?

Nein. Es ist überflüssig, weil ohnehin alles erlaubt ist, was nicht verboten ist. Gleichzeitig kann es schaden: Parser, die nach dem Prinzip „erste passende Regel gewinnt“ arbeiten, darunter Pythons Standardbibliothek, ignorieren dann alle späteren Disallow-Zeilen. Das ist uns auf getmind.io selbst passiert.

Wird Crawl-delay von Google beachtet?

Nein. Google ignoriert Crawl-delay vollständig. Bing und Yandex beachten die Angabe. Wenn Googlebot deinen Server zu stark belastet, liefere vorübergehend die Statuscodes 429 oder 503 aus. Google drosselt daraufhin automatisch.

Wie groß darf eine robots.txt sein?

Google verarbeitet maximal 500 KiB, alles danach wird ignoriert. In der Praxis ist das kaum relevant: Die längste Datei in unserer Stichprobe (Wikipedia) hatte 28 KB. Wenn deine Datei deutlich wächst, ist das meistens ein Zeichen, dass du mit Wildcards zusammenfassen solltest.