robots.txt für Onlineshops: was sie steuert, was sie nicht kann — und welche KI-Crawler heute zählen

Die robots.txt ist eine UTF-8-Textdatei unter /robots.txt im Stammverzeichnis Ihrer Domain. Sie steuert das Crawling, nicht die Indexierung: Eine per Disallow gesperrte Seite kann laut Google weiterhin in den Ergebnissen erscheinen, wenn andere Websites auf sie verweisen. Normiert sind nur user-agent, allow und disallow — Crawl-delay kennt der Standard nicht.

Stand dieses Beitrags: Alle Angaben zu Bot-Namen, unterstützten Feldern und Prüfwegen wurden am 6. September 2026 an der jeweiligen Herstellerdokumentation geprüft. Genau diese Liste veraltet am schnellsten: Meta und Amazon haben ihre Crawler zuletzt in mehrere Tokens aufgeteilt. Prüfen Sie die Tabelle in Abschnitt 6 deshalb zweimal im Jahr gegen die verlinkten Originalseiten.

1. Was die robots.txt regelt — und was ausdrücklich nicht

Seit September 2022 ist das Robots Exclusion Protocol ein offizieller Internet-Standard: RFC 9309, Kategorie „Standards Track", verfasst von Martijn Koster, Gary Illyes, Henner Zeller und Lizzi Sassman. Damit endete eine 28 Jahre lange Phase, in der jeder Crawler-Betreiber die Datei ein wenig anders auslegen durfte (Quelle: RFC 9309 beim RFC Editor, abgerufen am 6. September 2026).

Der Standard legt drei Dinge fest, die im Alltag oft übersehen werden. Erstens den Ort: Die Regeln müssen laut RFC „in a file named ‚/robots.txt' (all lowercase) in the top-level path of the service" liegen, und die Datei muss UTF-8-codiert sein. Eine robots.txt in einem Unterordner hat keine Wirkung. Zweitens die Größe: Der Parser muss mindestens 500 Kibibyte lesen; Google ignoriert alles darüber. Drittens die Haltbarkeit: Crawler sollen eine zwischengespeicherte Fassung nicht länger als 24 Stunden verwenden.

Viel wichtiger ist aber, was die Datei nicht leistet. Google formuliert das in der eigenen Einführung unmissverständlich: „Eine Seite, die in der robots.txt-Datei als nicht zugelassen angegeben ist, kann weiterhin indexiert werden, wenn von anderen Websites auf sie verwiesen wird." Adresse und Ankertext landen dann in den Ergebnissen — nur ohne Inhalt, weil Google die Seite ja nicht abrufen durfte. Wer eine Seite wirklich heraushalten will, braucht laut derselben Quelle „das meta-noindex-Tag oder einen entsprechenden Antwortheader" oder einen Passwortschutz (Quelle: Google: Einführung zu robots.txt-Dateien, Stand 18. Dezember 2025, abgerufen am 6. September 2026).

Der zweite Irrtum ist gefährlicher. Die robots.txt ist kein Sicherheitswerkzeug. Der RFC widmet dem einen eigenen Abschnitt: „Listing paths in the robots.txt file exposes them publicly and thus makes the paths discoverable." Wer dort Disallow: /interner-admin-2024/ schreibt, hat den Pfad soeben veröffentlicht. Jeder kann die Datei abrufen, sie ist per Definition öffentlich.

Und drittens: Regeln sind eine Bitte, keine Schranke. Sie wirken bei Crawlern, die sich daran halten wollen. Wer Bots wirklich stoppen muss, weil sie den Server belasten oder Preise abgreifen, braucht eine Ebene davor — dazu haben wir beschrieben, was Cloudflare für Shop-Betreiber leistet und wo dieser Netzwerk-Türsteher an seine Grenzen kommt. Die robots.txt ordnet den legitimen Verkehr; sie hält keinen unerwünschten ab.

2. Die Felder, die zählen: normiert, geduldet, wirkungslos

Eine Zeile besteht aus Feld, Doppelpunkt und Wert. Klingt trivial, hat aber drei Fallstricke: Der Feldname ist unempfindlich gegen Groß- und Kleinschreibung, der Pfadwert nicht. Und Zeilen, die kein bekanntes Feld tragen, ignoriert der Parser vollständig — was in Abschnitt 3 noch wichtig wird.

Zwei Zeilen dieser Tabelle widersprechen dem, was in vielen Ratgebern und sogar in Googles eigener KI-Zusammenfassung zu diesem Suchbegriff steht. Die Sitemap-Zeile gilt dort als vierter Grundbefehl. Im RFC ist sie das nicht: Der Standard nennt sie unter „other records that are not part of the robots.txt protocol" und führt „Sitemaps" ausdrücklich als Beispiel für eine solche Erweiterung an. Das ist kein Grund, sie wegzulassen — Google, Bing und andere unterstützen sie —, aber ein Grund, sie richtig einzuordnen: Sie gehört zu keiner Gruppe und gilt für alle Crawler.

Crawl-delay ist der zweite Fall. Das Feld kommt im gesamten RFC 9309 kein einziges Mal vor. Google schreibt in der Spezifikation wörtlich: „Google unterstützt die folgenden Felder (andere Felder wie crawl-delay werden nicht unterstützt)." Anthropic wertet die Zeile für die eigenen Bots aus, bezeichnet sie in derselben Dokumentation aber selbst als „non-standard Crawl-delay extension". Die Zeile schadet nicht — sie tut nur bei den meisten Crawlern nichts. Wer die Google-Crawlfrequenz drosseln will, tut das in der Search Console, nicht in der Datei.

Die Platzhalter sind dagegen ein echtes Werkzeug und, anders als oft dargestellt, seit RFC 9309 normiert: Abschnitt 2.2.3 listet #, $ und * unter „Crawlers MUST support the following special characters". Bei konkurrierenden Regeln gewinnt laut RFC die längste Übereinstimmung, gemessen in Zeichen; sind allow und disallow gleich lang, setzt sich allow durch. Genau darauf beruhen die Filtermuster in Abschnitt 4.

3. Die Gruppen-Falle: warum eigene Bot-Regeln Sperren aufheben

Dies ist der Fehler, den wir in Shop-Dateien am häufigsten sehen, und er ist nicht offensichtlich. Ein Crawler befolgt genau eine Gruppe. Der RFC beschreibt das Verfahren so: Der Bot sucht die Gruppe, deren Produkt-Token zu seinem Namen passt; findet er keine, gilt für ihn die Gruppe mit *. Andere Gruppen werden ignoriert.

Google formuliert die Konsequenz noch schärfer: „Bestimmte User-Agent-Gruppen und globale Gruppen (*) werden nicht kombiniert." Wer also eine *-Gruppe mit zwölf Sperren pflegt und darunter eine eigene Gruppe für Googlebot mit nur einer Zeile Allow: / anlegt, hat für Googlebot sämtliche zwölf Sperren aufgehoben. Der Shop öffnet damit ausgerechnet dem wichtigsten Crawler alle Filter- und Warenkorbseiten.

Die zweite Variante derselben Falle ist noch subtiler. Der Parser ignoriert unbekannte Zeilen — und behandelt zwei durch eine solche Zeile getrennte Blöcke als eine einzige Gruppe. Google zeigt das in der Spezifikation an einem Beispiel, das sinngemäß so aussieht:

• User-agent: partnerbot
• Sitemap: https://www.beispielshop.de/sitemap.xml
• User-agent: preisbot
• Disallow: /

Gemeint war eine komplette Sperre für preisbot. Tatsächlich ignoriert der Parser die Sitemap-Zeile, verschmilzt beide Blöcke zu einer Gruppe — und sperrt damit auch partnerbot vollständig aus. Deshalb gehören Sitemap-Zeilen ans Dateiende, nicht zwischen zwei Gruppen.

Drei Regeln machen die Sache beherrschbar. Erstens: Jede Sperre, die in der *-Gruppe steht, gehört wortgleich in jede eigene Gruppe. Zweitens: Legen Sie nur dort eigene Gruppen an, wo Sie wirklich abweichen wollen. Drittens: Schreiben Sie in einem Kommentar direkt über die erste eigene Gruppe, dass sie nicht erbt. Diese eine Zeile hat schon manchen Kollegen davor bewahrt, ein halbes Jahr später eine Sperre nur an einer Stelle nachzuziehen.

4. Shop-Muster: Filter, Suche, Warenkorb, Kundenkonto

Ein Shop unterscheidet sich von einer Firmenseite in genau einem Punkt: Er erzeugt Adressen schneller, als ein Crawler sie abarbeiten kann. Drei Filter mit je fünf Ausprägungen ergeben rechnerisch bereits über hundert Kombinationen je Kategorie — mal Sortierung, mal Seitenzahl. Google beschreibt das Problem in einer eigenen Anleitung zur Facettensuche und nennt zwei Folgen: „Übermäßiges Crawling" und „Langsamere Entdeckungs-Crawlings", weil den Crawlern die Zeit für neue, nützliche Adressen fehlt.

Die Empfehlung dort ist eindeutig: „Verwende robots.txt, um das Crawling von Facettensuche-URLs zu verhindern. Oft gibt es keinen triftigen Grund, das Crawling von gefilterten Elementen zuzulassen." Google lässt in seinem eigenen Beispiel nur die Produktseiten und eine ungefilterte Listenseite offen — sinngemäß in dieser Form:

• user-agent: Googlebot
• disallow: /*?*farbe=
• disallow: /*?*groesse=
• allow: /*?produkte=alle$

Die folgende Übersicht überträgt das auf die Bereiche, die in fast jedem Shop vorkommen. Die Regelvorschläge sind unsere Praxis-Empfehlung, nicht der Wortlaut einer Herstellerquelle; die Begründung zur ersten Zeile stammt aus Googles Facetten-Anleitung.

Zwei Hinweise aus derselben Google-Anleitung passen in keine Tabellenzeile, gehören aber in jedes Shop-Projekt. Erstens: Nutzen Sie & als Trennzeichen zwischen Parametern. Komma, Semikolon und eckige Klammern sind für Crawler „nur schwer als Parametertrennzeichen zu erkennen". Zweitens: Liefert eine Filterkombination kein Ergebnis, gehört dort ein echter Statuscode 404 hin — keine Weiterleitung auf eine allgemeine Fehlerseite und keine leere Trefferliste mit Status 200.

Und eine Warnung, die genau hier greift: Sperren Sie eine Filterseite nicht gleichzeitig per Disallow und per noindex. Google warnt ausdrücklich, dass „der kombinierte Einsatz mehrerer Crawling- und Indexierungsregeln … Konflikte zwischen sich widersprechenden Regeln verursachen" kann. Der Mechanismus ist simpel: Was nicht gecrawlt wird, kann auch nicht gelesen werden — das noindex bleibt unsichtbar.

Ein Canonical-Tag ersetzt eine Sperre in der robots.txt nicht, er ergänzt sie. Google liest ihn erst nach dem Abruf und nennt ihn für Facettensuchen langfristig weniger wirksam als eine Crawling-Sperre. Seinen Platz hat er dort, wo Adressen erreichbar bleiben sollen: bei Varianten per Parameter, bei Kampagnen-Links und bei Produkten in mehreren Kategoriepfaden. Welche Adresse in welchem Fall das Original ist, zeigt unser Beitrag zum Canonical-Tag im Onlineshop.

5. JTL-Shop und Shopify: was die Hersteller wirklich dokumentieren

Hier wird es unbequem, und wir sagen das offen: Für JTL-Shop existiert am 6. September 2026 keine offizielle Dokumentation einer Standard-robots.txt. Die naheliegende Adresse im JTL-Guide liefert einen 404, ein öffentliches Quellcode-Verzeichnis gibt es nicht, und die robots.txt unter jtl-software.de gehört zum Konzernauftritt, nicht zu einem Shop. Die einzigen Fundstellen sind Forenbeiträge einzelner Anwender. Wir geben solche Inhalte nicht als „JTL-Standard" aus — was in einem Shop steht, hängt ohnehin von Template, Plugins und Serverkonfiguration ab.

Sinnvoller ist deshalb eine eigene, begründete Startaufstellung. In JTL-Shops sperren wir üblicherweise die Warenkorb- und Bestellstrecke, den Kundenkonto-Bereich, die interne Suche, Vergleichs- und Merkzettel-Adressen sowie die Filterparameter der Kategorieansicht — und lassen Bilder, CSS und JavaScript vollständig offen, damit Google die Seite rendern kann. Welche Pfade das im Einzelfall genau sind, lesen wir aus den Serverprotokollen und der Search Console ab, nicht aus einer Vorlage. Wer seinen Shop grundsätzlich prüfen lassen möchte, findet den Ablauf in unserer Shop-Analyse.

Bei Shopify ist die Lage umgekehrt: Der Mechanismus ist gut dokumentiert, die konkreten Regeln sind es nicht. Shopify schreibt, es erzeuge „a robots.txt file by default, which works for most shops", weshalb das zugehörige Template in keinem Theme enthalten sei. Wer es braucht, legt templates/robots.txt.liquid an. Die Standardregeln werden dabei „mirrored through the Liquid robots object" — Sie arbeiten also mit den Objekten weiter, statt Klartext hinzuschreiben (Quelle: Shopify: robots.txt.liquid, abgerufen am 6. September 2026).

Der entscheidende Satz derselben Seite lautet: „The default rules are updated regularly to ensure that SEO best practices are always applied." Wer die Datei überschreibt, übernimmt damit die Pflege — inklusive aller künftigen Anpassungen, die Shopify sonst stillschweigend nachzieht. Das ist ein realer Nachteil, den viele Anleitungen verschweigen. Ändern Sie deshalb nur, was Sie begründen können, und ergänzen Sie über die Liquid-Objekte, statt sie zu ersetzen. Wie die übrigen Stellschrauben der Plattform zusammenwirken, steht in unserem Beitrag zu Shopify SEO.

6. Die KI-Crawler-Liste, Stand 6. September 2026

Diese Tabelle ist der Grund, warum robots.txt-Dateien altern. Sie enthält ausschließlich Tokens, die der jeweilige Anbieter selbst dokumentiert. Jede Zeile wurde am 6. September 2026 an der Herstellerseite gegengelesen. Bots, für die wir keine offizielle Dokumentation gefunden haben, stehen bewusst nicht darin — auch dann nicht, wenn ihre Namen in vielen Beispieldateien kursieren.

Vier Punkte daraus sind für Shop-Betreiber entscheidend. Erstens: Die Schalter sind unabhängig. OpenAI schreibt ausdrücklich, ein Betreiber könne OAI-SearchBot erlauben, „in order to appear in search results", und gleichzeitig GPTBot sperren. Wer beide in einem Rutsch aussperrt, spart keine Trainingsdaten, sondern verliert Sichtbarkeit in den Antworten.

Zweitens: Ein Trainings-Opt-out kostet keine Rankings. Google stellt zu Google-Extended klar: „Google-Extended does not impact a site's inclusion in Google Search nor is it used as a ranking signal." Apple formuliert es für Applebot-Extended genauso — Inhalte bleiben „discoverable through Spotlight, Siri, and Safari".

Drittens: Änderungen wirken verzögert. OpenAI nennt für die Suche rund 24 Stunden, Perplexity ebenfalls bis zu 24 Stunden. Amazon arbeitet notfalls mit „a cached copy from the last 30 days". Wer heute etwas sperrt und morgen kontrolliert, misst nichts.

Viertens: Amazon hat einen Sonderfall eingebaut. Erwähnt Ihre Datei den Amzn-SearchBot nicht, erlaubt aber andere Suchbots, dann folgt er laut Doku „in accordance with the robots.txt directives given to other search bots". Ihre Googlebot-Gruppe steuert damit indirekt auch Alexa.

Was diese Bots für die Sichtbarkeit in Antwortmaschinen bedeuten, ordnet unser Beitrag zur Generative Engine Optimization ein — dort geht es um die inhaltliche Seite, hier um den technischen Zugang. Ein sauberer Zugang ohne zitierfähige Inhalte bringt nichts, und umgekehrt genauso wenig.

7. Drei Sorten Bot, die ständig verwechselt werden

Die Tabelle wirkt erst unübersichtlich, sobald man alle Namen als eine Gruppe liest. Tatsächlich zerfällt sie in drei Klassen mit völlig verschiedenen Folgen. Google beschreibt dieselbe Dreiteilung für die eigenen Crawler.

• Trainings-Crawler. GPTBot, ClaudeBot, Meta-ExternalAgent, Amazonbot, CCBot und die Steuer-Tokens Google-Extended und Applebot-Extended. Eine Sperre hält Ihre Texte aus künftigen Modellen heraus. Sie kostet keine Rankings — aber sie nimmt Ihnen auch die Chance, dass ein Modell Ihre Marke später von sich aus kennt.
• Suchindex-Bots. OAI-SearchBot, Claude-SearchBot, PerplexityBot, Meta-WebIndexer, Amzn-SearchBot und Applebot. Sie sind das Gegenstück zum Googlebot in der jeweiligen Antwortmaschine. Eine Sperre ist hier fast immer ein Eigentor: Sie verschwinden aus Antworten, in denen Ihre Wettbewerber weiter genannt werden.
• Nutzerausgelöste Fetcher. ChatGPT-User, Perplexity-User, Meta-ExternalFetcher, Amzn-User und Claude-User. Sie holen eine Seite, weil ein Mensch gerade danach gefragt hat.

Die dritte Klasse verdient eine eigene Warnung, weil die Anbieter dort selbst Grenzen einräumen. Perplexity schreibt zum Perplexity-User: „Since a user requested the fetch, this fetcher generally ignores robots.txt rules." OpenAI formuliert für ChatGPT-User: „Because these actions are initiated by a user, robots.txt rules may not apply." Meta sagt zum ExternalFetcher, dieser „kann robots.txt-Regeln umgehen", Amazon zum Amzn-User, er folge „womöglich nicht allen" Regeln. Diese vier Bots lassen sich über die Datei also nicht zuverlässig steuern.

Dasselbe Muster kennt Google seit Langem. Die eigene Übersicht unterscheidet gängige Crawler, die „immer die robots.txt-Regeln für automatisches Crawling" beachten, Sonderfall-Crawler und nutzerausgelöste Fetcher — und nennt als Beispiel, dass „AdsBot den globalen robots.txt-User-Agent (*)" ignoriert. Wer AdsBot steuern will, braucht dafür eine eigene Gruppe.

Praktische Konsequenz: Erwarten Sie von der robots.txt Ordnung, nicht Kontrolle. Bots, die Preise abgreifen oder Anmeldeformulare durchprobieren, lesen sie ohnehin nicht. Wie sich solcher Verkehr tatsächlich stoppen lässt, haben wir am Beispiel automatisierter Angriffe auf Onlineshops beschrieben — dort geht es um Sperren, die durchgesetzt werden, nicht um Bitten.

8. Unsere eigene robots.txt — Entscheidung und Selbstprüfung

Wir halten es für redlich, das eigene Haus zu zeigen, wenn wir über Wartung schreiben. Unsere Datei ist unter yagemi.de/robots.txt öffentlich abrufbar, umfasst 172 Zeilen und trägt im Kopf das Entstehungsdatum 13. Juni 2026. Die Strategie steht als Kommentar direkt darunter: maximale Sichtbarkeit für Such- und Antwort-Bots, gesperrt ist nur, was niemandem nützt.

Gesperrt sind in der *-Gruppe im Wesentlichen vier Dinge: der interne Bereich /stylebook/, Kampagnen-Landingpages unter /lp/, die Danke-Seiten nach einer Formularabsendung sowie System- und Verwaltungspfade wie /includes/, /vendor/, /ajax/ und /yagemiadmin/. Dazu kommen die Rechtstexte und die Fehlerseiten. Ausdrücklich freigegeben bleiben Bilder, CSS und JavaScript. Für Suchmaschinen und für vierzehn KI- und Antwort-Bots gibt es eigene Gruppen mit Allow: / — die Entscheidung lautet also: Wir lassen lesen, auch für das Training.

Diese Abwägung ist kein Selbstläufer, und wir stellen sie ehrlich dar. Dagegen spricht, dass unsere Texte damit in Modellen landen können, ohne dass wir etwas davon haben. Dafür sprach am Ende ein nüchterner Grund: Wir leben davon, dass Mittelständler uns finden — und immer häufiger fragen sie nicht Google, sondern einen Assistenten. Wer aus dem Trainingsmaterial verschwindet, verschwindet mittelfristig auch aus den Antworten. Für einen Verlag mit Bezahlinhalten kann dieselbe Rechnung genau andersherum ausgehen.

Beim Schreiben dieses Beitrags haben wir unsere Datei Zeile für Zeile gegen die verlinkten Herstellerseiten gehalten. Das Ergebnis war lehrreich, und es belegt die These dieses Artikels besser als jedes fremde Beispiel:

• Eine wirkungslose Zeile. Am Ende der *-Gruppe steht Crawl-delay: 1. Google ignoriert das Feld. Es schadet nicht, aber es ist genau die Sorte Zeile, die in Dateien überlebt, weil niemand sie prüft.
• Drei fehlende Bot-Gruppen. Wir haben eine Gruppe für meta-externalagent, aber keine für Meta-WebIndexer und Meta-ExternalFetcher — Meta hat seine Crawler nach unserem Dateidatum aufgeteilt. Dasselbe gilt für Amzn-SearchBot und Amzn-User bei Amazon sowie für Google-CloudVertexBot und OAI-AdsBot.
• Zwei Einträge ohne Herstellerbeleg. Für zwei Tokens in unserer Datei haben wir am 6. September 2026 keine offizielle Anbieterdokumentation gefunden. Beide sind erlaubt, richten also keinen Schaden an — sie stehen aber ohne Grundlage dort und fliegen bei der nächsten Pflege heraus.

Alle drei Punkte fallen in dieselbe Kategorie: Die Datei war am Tag ihrer Entstehung korrekt. Sie ist es heute nur noch überwiegend, weil sich nicht der Standard geändert hat, sondern die Namen der Bots. Genau deshalb gehört sie in einen Wartungsrhythmus und nicht in die Kategorie „einmal richtig gemacht".

9. Prüfen und überwachen: der robots.txt-Bericht

Viele Anleitungen im Netz verweisen noch auf den früheren robots.txt-Tester in der Search Console. Wir haben am 6. September 2026 die drei aktuellen Google-Dokumentationsseiten zum Thema sowie die zugehörige Search-Console-Hilfe geprüft: Dieser Tester kommt dort nicht mehr vor. Dokumentiert ist heute der robots.txt-Bericht.

Er zeigt laut Hilfe die robots.txt-Dateien „der 20 wichtigsten Hosts" einer Property, den Abrufstatus je Datei, die dabei gefundenen Fehler und einen Versionsverlauf. Drei Dinge daraus sind im Shop-Alltag nützlich (Quelle: Search-Console-Hilfe: robots.txt-Bericht, abgerufen am 6. September 2026).

1. Abrufstatus lesen. „Nicht abgerufen – Nicht gefunden (404)" ist kein Drama: Google hält ausdrücklich fest, dass dann alle Adressen gecrawlt werden dürfen. Kritisch ist der andere Fall — ein Serverfehler.
2. Versionsverlauf nutzen. Der Bericht speichert frühere Fassungen und nimmt eine Anfrage nur dann in den Verlauf auf, wenn sich Datei oder Ergebnis geändert haben. Damit lässt sich nachträglich klären, seit wann eine Sperre wirkt.
3. Erneutes Crawlen beantragen. Über das Menü neben einer Datei. Sinnvoll nach einem behobenen Fehler oder wenn Sie eine wichtige Sperre aufgehoben haben — mit dem ausdrücklichen Hinweis der Hilfe, dass ein sofortiges Neu-Crawling der freigegebenen Adressen dadurch nicht garantiert ist.

Der wichtigste Überwachungspunkt ist der Serverfehler, und er wird fast immer übersehen. Der RFC schreibt für den 5xx-Fall vor: „the crawler MUST assume complete disallow". Google konkretisiert das für die eigene Infrastruktur: In den ersten zwölf Stunden wird das Crawling der Website gestoppt, danach greift für dreißig Tage die letzte fehlerfreie Fassung. Praktisch heißt das: Wer seinen Shop in den Wartungsmodus schaltet und dabei auch die robots.txt mit Status 503 ausliefert, kann Google eine halbe Nacht lang komplett aussperren. Liefern Sie diese eine Datei deshalb immer mit Status 200 aus — auch im Wartungsmodus.

Für den laufenden Betrieb reicht ein schlanker Rhythmus: nach jedem Shop-Update und nach jedem Relaunch der Blick in den Bericht, zweimal im Jahr ein Abgleich der Bot-Tabelle. Welche weiteren Berichte der Search Console im Handel wirklich etwas bringen, haben wir in unserem Leitfaden zur Google Search Console zusammengestellt.

10. Sieben Fehler, die uns in Shop-Dateien regelmäßig begegnen

Die folgenden sieben Punkte stammen aus unserer Projektarbeit. Jede Folge ist an RFC 9309 oder der Google-Dokumentation belegt, damit Sie im Zweifel nachschlagen können, statt uns glauben zu müssen.

Ein achter Punkt taucht seltener auf, kostet dafür am meisten: das pauschale Aussperren von KI-Bots per Sammelregel, meist aus einer Vorlage übernommen. Anthropic weist in der eigenen Dokumentation darauf hin, dass auch der Umweg über IP-Sperren nichts bringt, weil er den Bots gerade den Zugriff auf die robots.txt verbaut. Wer steuern will, muss die Tokens einzeln benennen — und vorher entscheiden, welche der drei Bot-Klassen aus Abschnitt 7 er wirklich meint.

Alle Angaben wurden am 6. September 2026 an der jeweiligen Originaldokumentation geprüft und im abgerufenen Text gegengelesen. Anbieter ändern Bot-Namen und Zwecke laufend — die vollständige Quellenliste steht am Ende des Beitrags.

11. Fazit: eine Datei, zwei Pflegetermine im Jahr

Die robots.txt ist kein kompliziertes Werkzeug. Drei normierte Felder, zwei Platzhalter, eine Handvoll Regeln — das lernt man an einem Nachmittag. Kompliziert ist nur die Umgebung: Ein Shop erzeugt endlos Adressen, und die Zahl der Bots, die Namen und Zwecke ändern, wächst weiter.

Drei Dinge tragen die Datei durch den Alltag. Erstens die saubere Trennung von Crawling und Indexierung: Was aus dem Index soll, gehört auf noindex, nicht in ein Disallow. Zweitens die Gruppen-Disziplin: Jede eigene Bot-Gruppe wiederholt die Sperren der *-Gruppe, sonst hebt sie sie auf. Drittens die Entscheidung bei den KI-Bots — bewusst getroffen, nach Klassen getrennt und mit Datum dokumentiert.

Und der wichtigste Punkt ist kein technischer: Setzen Sie sich zwei Termine im Jahr in den Kalender. Wir haben bei unserer eigenen Datei drei Lücken gefunden, obwohl sie erst wenige Monate alt ist. Eine Datei, die zwei Jahre unangetastet läuft, kennt weder Meta-WebIndexer noch Amzn-SearchBot — und steuert damit still einen wachsenden Teil des Verkehrs überhaupt nicht mehr.

12. Häufige Fragen zur robots.txt

Was ist eine robots.txt und wofür braucht ein Onlineshop sie?

Die robots.txt ist eine Textdatei im Stammverzeichnis Ihrer Domain. Sie sagt Crawlern, welche Pfade sie abrufen dürfen und welche nicht. Für einen Shop ist sie vor allem ein Werkzeug gegen Verschwendung: Filter-, Sortier- und Suchseiten erzeugen beliebig viele Adressen, die Rechenzeit kosten und keinen Besucher bringen.

Was bedeutet Disallow in der robots.txt?

Disallow nennt einen Pfad, den der angesprochene Crawler nicht abrufen soll. Der Wert beginnt immer mit einem Schrägstrich und wird von Google mit Beachtung der Groß- und Kleinschreibung ausgewertet. Eine Zeile ohne Pfad wird ignoriert. Trifft keine Regel zu, gilt die Adresse als erlaubt.

Verhindert Disallow, dass eine Seite bei Google erscheint?

Nein. Google schreibt dazu wörtlich, eine per robots.txt gesperrte Seite könne weiterhin indexiert werden, wenn andere Websites auf sie verweisen. Adresse und Ankertext landen dann ohne Inhalt in den Ergebnissen. Wer eine Seite wirklich heraushalten will, nutzt ein noindex oder einen Passwortschutz.

Wie erstelle ich eine robots.txt für meinen Shop?

Legen Sie eine reine Textdatei in UTF-8 an und veröffentlichen Sie sie unter Ihrer Domain im Stammverzeichnis. Beginnen Sie mit einer Gruppe für alle Crawler, sperren Sie Warenkorb, Kasse, Kundenkonto, interne Suche und Filterparameter, ergänzen Sie die Sitemap-Zeile und prüfen Sie das Ergebnis in der Search Console.

Wie sperre ich KI-Crawler wie GPTBot oder ClaudeBot aus?

Mit einer eigenen Gruppe je Bot: eine Zeile User-agent mit dem Token, darunter Disallow und ein Schrägstrich. Wichtig ist die Trennung nach Zweck. GPTBot sammelt Trainingsdaten, OAI-SearchBot bedient die Suche in ChatGPT. Wer beide sperrt, verliert auch die Sichtbarkeit in den Antworten.

Halten sich KI-Crawler an die robots.txt?

Die dokumentierten Crawler der großen Anbieter tun das nach eigener Aussage. Ausdrücklich ausgenommen sind nutzerausgelöste Abrufe: OpenAI, Perplexity, Meta und Amazon schreiben für ihre Nutzer-Agents selbst, dass Regeln dort nicht oder nicht vollständig greifen. Unbekannte Bots halten sich ohnehin an nichts.

Wo teste ich meine robots.txt bei Google?

In der Google Search Console über den robots.txt-Bericht. Er zeigt die gefundenen Dateien der zwanzig wichtigsten Hosts, den Abrufstatus, erkannte Fehler und einen Versionsverlauf. Über das Menü neben einer Datei lässt sich ein erneutes Crawlen beantragen, wenn Sie einen Fehler behoben haben.

Gehören Filter- und Parameterseiten in die robots.txt?

In den meisten Shops ja. Google empfiehlt für Facettensuchen ausdrücklich, das Crawling der gefilterten Adressen zu unterbinden, und lässt nur die Produktseiten sowie eine ungefilterte Listenseite offen. Prüfen Sie vorher, ob einzelne Filterseiten echte Suchnachfrage haben und ranken sollen; solche Ausnahmen geben Sie gezielt per Allow wieder frei.

Wie oft muss ich meine robots.txt prüfen?

Zweimal im Jahr reicht meist, dazu nach jedem Relaunch und nach jedem Shop-Update. Der Grund sind weniger Syntaxfehler als neue Bot-Namen: Meta und Amazon haben ihre Crawler zuletzt aufgeteilt. Eine Datei, die zwei Jahre alt ist, kennt diese Tokens nicht.

13. Quellen & offizielle Informationen

Alle Quellen wurden am 6. September 2026 abgerufen; die zitierten Formulierungen wurden im abgerufenen Text gegengelesen. Externe Quellen öffnen in einem neuen Tab.

• RFC 9309 — Robots Exclusion Protocol — der Standard selbst: normierte Records, Sonderzeichen, Gruppenauswahl, 500-Kibibyte-Grenze, 24-Stunden-Cache, Verhalten bei Serverfehlern und die Sicherheitswarnung zu gelisteten Pfaden (Standards Track, September 2022).
• Google — Wie Google die robots.txt-Spezifikation interpretiert — unterstützte Felder ohne crawl-delay, Groß- und Kleinschreibung im Pfadwert, Nichtkombination eigener Gruppen mit der Sternchen-Gruppe, Platzhalter-Tabelle, Verhalten bei 5xx-Fehlern (Stand 14. Juli 2026).
• Google — Einführung zu robots.txt-Dateien — der Wortlaut dazu, dass gesperrte Seiten weiterhin indexiert werden können, und die Warnung vor sich widersprechenden Crawling- und Indexierungsregeln (Stand 18. Dezember 2025).
• Google — Crawling von Facettensuche-URLs verbessern — Empfehlung zur Sperrung gefilterter Adressen samt Beispielregeln, das Trennzeichen-Argument und der 404 bei leerer Filterkombination (Stand 6. März 2026).
• Google Search-Console-Hilfe — robots.txt-Bericht — Umfang des Berichts, Abrufstatus, Versionsverlauf und die Funktion „Erneutes Crawlen beantragen".
• Google — Gängige Crawler — Google-Extended als reines Steuer-Token ohne Ranking-Wirkung sowie Google-CloudVertexBot (Stand 14. Juli 2026).
• Google — Übersicht über Crawler und Fetcher — die Dreiteilung in gängige Crawler, Sonderfall-Crawler und nutzerausgelöste Fetcher, inklusive AdsBot-Ausnahme (Stand 17. Juni 2026).
• OpenAI — Overview of OpenAI Crawlers — GPTBot, OAI-SearchBot, ChatGPT-User und OAI-AdsBot, die Unabhängigkeit der Schalter und die Vorlaufzeit von rund 24 Stunden (Herstellerdokumentation).
• Anthropic — Crawler und Blockierung — ClaudeBot, Claude-User und Claude-SearchBot, Crawl-delay als Nicht-Standard und der Hinweis, warum IP-Sperren kein tauglicher Weg sind (Herstellerdokumentation).
• Perplexity — PerplexityBot und Perplexity-User — Abgrenzung von Suchindex und nutzerausgelöstem Abruf, der die Regeln in der Regel ignoriert (Herstellerdokumentation).
• Apple — About Applebot — Applebot für Spotlight, Siri und Safari sowie Applebot-Extended als reines Trainings-Opt-out ohne Wirkung auf die Auffindbarkeit (Herstellerdokumentation).
• Meta — Webcrawler — Meta-ExternalAgent, Meta-WebIndexer, Meta-ExternalFetcher, FacebookExternalHit und Meta-ExternalAds mit ihren jeweiligen Zwecken (Herstellerdokumentation).
• Amazon — Amazonbot — Amazonbot, Amzn-SearchBot und Amzn-User, die Zwischenspeicherung von bis zu dreißig Tagen und der Rückfall auf die Regeln anderer Suchbots (Herstellerdokumentation).
• Common Crawl — CCBot — der User-Agent-String, das offizielle Blockier-Snippet und die Warnung vor Crawlern, die sich fälschlich als CCBot ausgeben (Betreiberdokumentation).
• Shopify — robots.txt.liquid — automatisch erzeugte Standarddatei, Anpassung über das Template und der Hinweis, dass Shopify die Standardregeln laufend aktualisiert (Herstellerdokumentation).
• Unsere eigene robots.txt — Grundlage des Praxisbeispiels und des Selbstbefunds in Abschnitt 8; 172 Zeilen, entstanden am 13. Juni 2026.

Bewusst nicht enthalten: eine „Standard-robots.txt für JTL-Shop" — dazu existiert am 6. September 2026 keine Herstellerdokumentation, nur Forenbeiträge. Ebenso wenig eine Aufzählung der Shopify-Standardregeln, die der Anbieter selbst nicht auflistet, sowie Bot-Tokens ohne offizielle Anbieterquelle. Zu Microsofts Bingbot machen wir keine Detailangaben, weil die Hilfeseiten beim Abruf nur ein Skript-Gerüst ohne Fließtext liefern.