Crawling ≠ Indexierung: robots.txt steuert, ob ein Crawler eine URL besucht – nicht, ob sie im Index landet. Eine per robots.txt gesperrte URL kann trotzdem indexiert werden und in Suchergebnissen erscheinen – oft ohne Snippet, weil Google den Inhalt nicht kennt, aber die URL über externe Links entdeckt hat. Wer keine Indexierung will, braucht noindex – und die Seite muss dafür crawlbar bleiben.
Einer reicht für 90 %: Die meisten Websites kommen mit drei Direktiven aus: User-agent, Disallow und Sitemap. Aber ein einzelnes Disallow: / in der Produktion verhindert das gesamte Crawling – bereits bekannte URLs können trotzdem im Index verbleiben, bis Google sie auf anderem Weg deindexiert. Der häufigste und teuerste Fehler aus meinen Audits.
KI-Crawler 2026: GPTBot, OAI-SearchBot, ClaudeBot und Google-Extended lassen sich präzise steuern – jeder für einen anderen Zweck. robots.txt und llms.txt arbeiten auf verschiedenen Ebenen: robots.txt steuert das Crawling (standardisiert via RFC 9309), llms.txt ist eine neue, noch nicht normierte Konvention, die KI-Systemen bei konkreten Anfragen Orientierung geben soll – kein IETF-Standard, aber in der Praxis bereits aktiv genutzt.
Dienstagmorgen, technisches Audit für einen neuen Kunden. Erste Handlung, immer: domain.de/robots.txt im Browser öffnen. Und ich sehe das:
User-agent: *
Disallow: /Vollständige Crawl-Sperre. Seit dem Relaunch vor vier Monaten. Der Kunde fragte, warum der organische Traffic nach dem Launch auf null gefallen war. Jetzt wusste er es. Die Entwickler hatten die Staging-Konfiguration 1:1 in die Produktion übernommen. Klassiker. Teurer Klassiker.
Die robots.txt ist eine der unscheinbarsten Dateien im technischen SEO – zwei Zeilen reichen für den schlimmsten anzunehmenden Unfall. Richtig eingesetzt, lenkt sie Crawler auf das Wesentliche, schützt dein Crawl Budget und gibt dir 2026 sogar Kontrolle darüber, welche KI-Systeme deine Inhalte für ihr Training verwenden dürfen.
Dieser Leitfaden ist das, was ich meinen Kunden schicke, bevor wir den ersten technischen Audit durchgehen – direkt aus meiner Arbeit als Product Developer bei iGaming.com und aus gut 50 technischen SEO-Projekten bei SEO Kreativ. Keine Theorie, die du anderswo schon gelesen hast. Praxis, die ich selbst anwende.
Was ist robots.txt – und was ist sie nicht?
noindex. Aber: Die Seite muss dafür crawlbar bleiben, sonst kann Google das noindex-Signal nicht lesen.Die robots.txt ist eine schlichte Textdatei im Stammverzeichnis deiner Domain – also unter domain.de/robots.txt. Sie folgt dem Robots Exclusion Protocol (RFC 9309) und wird von Google offiziell in der Search Central Dokumentation beschrieben, das seit September 2022 als offizieller IETF-Standard dokumentiert ist, und enthält Anweisungen an Web-Crawler: welche Pfade sie besuchen dürfen, welche nicht.
Das Wichtigste zuerst – und das wird in jedem zweiten Audit verwechselt:
| robots.txt kann | robots.txt kann nicht |
|---|---|
| Crawling einer URL verhindern | Indexierung einer URL verhindern |
| Crawl-Ressourcen auf wichtige Bereiche lenken | Zugriff für echte Nutzer sperren |
| Bestimmten Crawlern spezifische Regeln geben | Seiten aus dem Index entfernen, die dort schon sind |
| Den Sitemap-Pfad kommunizieren | Sensible Daten schützen (kein Ersatz für Authentifizierung) |
| KI-Crawler vom Training ausschließen | Sicherstellen, dass Crawler sich an die Regeln halten |
robots.txt ist außerdem eine Empfehlung, keine Verpflichtung. Seriöse Crawler – Googlebot, Bingbot, GPTBot – halten sich daran. Malware-Bots und Content-Scraper mit Absicht halten sich an gar nichts. Wer wirklich schützen will, braucht Authentifizierung, Rate Limiting und Firewall-Regeln.
Disallow: /geheim/ schützt keine vertraulichen Inhalte. Erstens respektieren nicht alle Crawler die Direktive. Zweitens ist die robots.txt öffentlich – jeder kann sie aufrufen und sieht genau, welche Pfade du als sensibel markierst. Angreifer nutzen das aktiv als Reconnaissance-Tool.Syntax und Direktiven: das musst du kennen
User-agent, Disallow, Sitemap. Alles andere ist Feinsteuerung. Aber ein leeres Disallow: (kein Wert) bedeutet „alles erlaubt“ – das Gegenteil von Disallow: /. Diesen Unterschied solltest du auswendig kennen.Eine robots.txt besteht aus einem oder mehreren Blöcken. Jeder Block beginnt mit User-agent und enthält danach die Direktiven für genau diesen Crawler. Zwischen Blöcken muss eine Leerzeile stehen – fehlt sie, interpretieren manche Crawler alles als einen einzigen Block.
Die sechs Direktiven im Überblick
| Direktive | Bedeutung | Unterstützung |
|---|---|---|
User-agent | Für welchen Crawler gilt der Block. * = alle. | Universal |
Disallow | Pfad sperren. Leer lassen = alles erlaubt. / = alles gesperrt. | Universal |
Allow | Pfad explizit freigeben – überschreibt Disallow. Spezifischer Pfad gewinnt. | Alle RFC-9309-konformen Crawler (historisch: Google, Bing) |
Sitemap | Absolute URL zur XML-Sitemap. Mehrfach verwendbar, außerhalb der Blöcke. | Google, Bing, Yandex |
Crawl-delay | Wartezeit in Sekunden zwischen Crawler-Anfragen. | Bing, Yandex – nicht Google |
# | Kommentarzeile, wird ignoriert. | Universal |
Crawl-delay vollständig – das ist seit Jahren dokumentiertes Verhalten. Die Crawl-Geschwindigkeit für Google lässt sich ausschließlich über die Search Console unter „Einstellungen → Crawl-Statistiken“ beeinflussen. Wer Crawl-delay für Google in der robots.txt stehen hat, kann den Eintrag ersatzlos löschen.Syntax-Regeln, die in der Praxis Fehler verursachen
Ein wichtiger Punkt für alle, die robots.txt-Regeln für Google schreiben: Der Token Googlebot gilt für beide Crawler-Varianten – Smartphone und Desktop. Es ist nicht möglich, in der robots.txt zwischen ihnen zu unterscheiden, weil beide denselben User-agent-Token verwenden. Google bestätigt das explizit: „you cannot selectively target either Googlebot Smartphone or Googlebot Desktop using robots.txt.“ Wer versucht, separate Mobile/Desktop-Regeln zu bauen, baut auf einer Grundlage, die nicht existiert.
Wildcards funktionieren bei Google, aber nicht bei allen Crawlern gleich. Disallow: /admin* blockiert alles, das mit /admin beginnt. Disallow: /*.pdf$ blockiert alle PDFs – das $ steht für „Ende der URL“. Groß-/Kleinschreibung ist relevant: Disallow: /Admin blockt nicht /admin. Bei Konflikten zwischen Allow und Disallow gewinnt bei Google immer die spezifischere Regel.
Das Minimum – die sauberste robots.txt für kleine Websites
# robots.txt für domain.de
# Stand: 2026
User-agent: *
Disallow:
Sitemap: https://www.domain.de/sitemap.xml
Disallow: ohne Wert: alle Crawler dürfen alles. Sitemap-Pfad kommuniziert. Mehr braucht es für viele kleine Websites schlicht nicht.
Infografik: Anatomy einer robots.txt
Bevor es zu den Praxisszenarien geht – hier der visuelle Überblick über Aufbau, Direktiven und die drei wichtigsten Merksätze:
5 Praxisszenarien mit Copy-paste-Code
Szenario 1: WordPress-Standard
Mein Ausgangspunkt für WordPress-Seiten ohne besondere Anforderungen – aus hunderten von Projekten destilliert:
# robots.txt WordPress-Standard
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/
Disallow: /?s=
Disallow: /search/
Sitemap: https://www.domain.de/sitemap_index.xmlAdmin-Bereich gesperrt, AJAX-Endpoint explizit freigegeben (den brauchen manche Frontend-Komponenten), Theme- und Plugin-Assets gesperrt (null SEO-Wert, Crawl Budget schonen), Suchergebnisseiten gesperrt (Duplicate Content).
Szenario 2: E-Commerce mit Facetten-Navigation
Facetten-Navigation ist der klassische Anwendungsfall. Filter-Parameter erzeugen Tausende von URL-Kombinationen, die gecrawlt werden, aber keinen SEO-Wert haben und das Crawl Budget auffressen:
# robots.txt E-Commerce
User-agent: *
Disallow: /checkout/
Disallow: /cart/
Disallow: /account/
Disallow: /*?filter=
Disallow: /*?sort=
Disallow: /*?page=
Disallow: /search?
Allow: /
Sitemap: https://www.shop.de/sitemap.xmlDisallow: /*?filter= blockiert alle URLs mit dem Parameter ?filter= – unabhängig von Pfad und weiteren Parametern. Das klingt präzise, kann aber breiter greifen als gedacht. Immer mit dem Google robots.txt Tester gegen fünf URL-Varianten prüfen, bevor es live geht.Szenario 3: Staging-Umgebung – und warum sie niemals in die Produktion darf
# STAGING ONLY – niemals in Produktion!
User-agent: *
Disallow: /Diese zwei Zeilen gehören auf jedes Staging-System. Und in jede Deployment-Pipeline, die ich aufsetze, gibt es eine eigene robots.txt-Prüfung als Pflicht-Gate vor dem Go-live. Das ist keine Paranoia – das ist die Lektion aus dem Fall, mit dem dieser Artikel beginnt.
Szenario 4: Mehrsprachige Website
Bei Sprachunterordnern ist die robots.txt meist unkompliziert – crawlen lassen, Sitemaps kommunizieren. Jede Subdomain braucht ihre eigene robots.txt:
# robots.txt mehrsprachig
User-agent: *
Disallow: /intern/
Disallow: /preview/
Sitemap: https://www.domain.de/sitemap-de.xml
Sitemap: https://www.domain.de/sitemap-en.xml
Sitemap: https://www.domain.de/sitemap-fr.xmlMehrfach-Sitemap-Angaben sind valide und sinnvoll bei großen Projekten.
Szenario 5: Gezielter Mediencrawler-Block
Wer Bilder aus bestimmten Bereichen aus der Google-Bildersuche heraushalten will, ohne den normalen Googlebot zu blockieren:
# Nur Bild-Crawler einschränken
User-agent: Googlebot-Image
Disallow: /intern/
Disallow: /produkte/intern/
User-agent: *
Disallow: /intern/
Sitemap: https://www.domain.de/sitemap.xmlrobots.txt und Crawl-Budget
Crawl-delay ignoriert Googlebot komplett. Wer das Crawl Budget für Google wirklich drosseln will, macht das ausschließlich in der Search Console.Crawl Budget beschreibt, wie viele Seiten Googlebot in einem bestimmten Zeitraum auf deiner Website besucht. Für kleine bis mittlere Websites unter 10.000 indexierte URLs ist das selten ein limitierender Faktor. Für große Shops, Publisher oder Plattformen mit Facetten-Navigation, Tag-Archiven und URL-Parametern kann es kritisch werden.
Aus meiner Arbeit bei iGaming.com weiß ich, wie schnell sich das zuspitzt: Ein Shop mit 80.000 Produktseiten und ungezügelter Facetten-Navigation produziert leicht zwei Millionen crawler-erreichbare URLs. Wenn Googlebot die meisten davon besucht, haben die 80.000 relevanten Seiten weniger Budget – und werden seltener gecrawlt und aktualisiert. Das ist kein theoretisches Problem, das ist ein häufiger Grund für Indexierungsprobleme.
| Maßnahme | Wirkung auf Crawl Budget | Empfehlung |
|---|---|---|
| Nicht-indexierte URLs in robots.txt sperren | Mittel bis hoch |  Empfohlen für Parameter, Facetten, Duplikate |
| Crawl-delay (non-Google) | Reduziert Crawl-Rate für Bing/Yandex |  Nur bei Server-Lastproblemen |
| Sitemap aktuell halten | Lenkt auf relevante URLs | Immer empfohlen |
| Interne Linkstruktur bereinigen | Hoch – direkter Einfluss | Wichtiger als robots.txt |
| Redirect-Ketten abbauen | Mittel | Technische Hygiene |
| Crawl-Rate in Search Console drosseln | Direkte Wirkung auf Googlebot | Nur bei Server-Problemen |
KI-Crawler steuern: GPTBot, ClaudeBot, Google-Extended & Co.
Google-Extended blockiert nur Gemini-Training – nicht die Suche. Und robots.txt und llms.txt sind kein Entweder-oder: robots.txt (RFC 9309-Standard) steuert das Crawling. llms.txt ist eine neue, noch nicht normierte Konvention für KI-Systeme. Beide wirken auf verschiedenen Ebenen – robots.txt ist obligatorisch, llms.txt optional und noch kein IETF-Standard.Das war 2022 noch keine Frage, die in technischen Audits auftauchte. Heute fragen mich Kunden danach in jedem zweiten Projekt. Die Crawler der KI-Unternehmen haben sich in den letzten zwei Jahren enorm differenziert – und wer sie pauschal behandelt, verliert Kontrolle.
Die wichtigsten KI-Crawler 2026 mit verifizierten User-agent-Namen, laut offizieller Dokumentation der Anbieter – u.a. OpenAI Platform Docs:
| User-agent | Betreiber | Zweck |
|---|---|---|
GPTBot | OpenAI | KI-Training (ChatGPT, GPT-Modelle) |
OAI-SearchBot | OpenAI | ChatGPT-Suche / Atlas-Index |
ChatGPT-User | OpenAI | User-getriggertes Browsing in ChatGPT |
ClaudeBot | Anthropic | Training & Retrieval |
anthropic-ai | Anthropic | Älterer User-agent (weiterhin aktiv) |
PerplexityBot | Perplexity AI | KI-Suchindex |
Google-Extended | Gemini & Vertex AI Training/Grounding – kein Ranking-Signal, kein Einfluss auf Google Search | |
Bytespider | ByteDance | Training (TikTok-Ökosystem) |
Ein Block, der KI-Training sperrt, ohne Googlebot für die Suche zu berühren:
# KI-Training blockieren (Suche unberührt)
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Disallow: /
User-agent: ChatGPT-User
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: anthropic-ai
Disallow: /
User-agent: PerplexityBot
Disallow: /
User-agent: Bytespider
Disallow: /
# Nur Gemini-Training – NICHT die Google-Suche
User-agent: Google-Extended
Disallow: /Disallow: / für GPTBot stoppt das Training-Crawling. Die llms.txt hingegen steuert, was eine KI bei einer konkreten Nutzeranfrage priorisiert – das sind zwei verschiedene Ebenen. Wer KI-Training stoppen, aber trotzdem in KI-Antworten auftauchen will, kombiniert beide.Wichtige Einschränkung: robots.txt ist ein Hinweis, keine technische Sperre. Seriöse Anbieter wie OpenAI und Anthropic haben öffentlich erklärt, die Direktiven zu respektieren. Wer absoluten Schutz will, braucht serverseitige Maßnahmen – Firewall-Regeln auf Basis von IP-Ranges oder User-agent-Strings.
Die häufigsten Fehler aus echten Audits
Disallow: / aus dem Staging in die Produktion übernommen. Zweithäufigster: CSS und JavaScript geblockt. Beides ist in drei Minuten reparierbar – wenn man es rechtzeitig bemerkt.Fehler 1: Disallow: / in der Produktion
Den teuersten Fehler aus meinen Audits habe ich in diesem Artikel bereits beschrieben. Er passiert fast immer beim Relaunch. Wichtig: Disallow: / verhindert das Crawling, entfernt aber nicht sofort bereits bekannte URLs aus dem Index – die können noch wochenlang als Einträge ohne Snippet auftauchen. Mein Gegenmittel: In jedem Deployment-Prozess gibt es einen expliziten robots.txt-Check als Pflicht-Gate – unabhängig davon, wer das Deployment durchführt.
Fehler 2: CSS und JavaScript geblockt
# Schlecht – verhindert korrekte Darstellung
User-agent: *
Disallow: /wp-content/
Disallow: /assets/js/
Disallow: /assets/css/Google rendert Seiten wie ein Browser. Wenn Googlebot CSS und JavaScript nicht laden kann, sieht er eine kaputte Seite und bewertet sie entsprechend. CSS- und JS-Dateien gehören nicht in die Sperrliste.
Fehler 3: noindex und robots.txt kombinieren
Wenn eine URL in robots.txt geblockt ist, kann Google den noindex-Tag nicht lesen – weil Googlebot die Seite nicht besucht. Die URL kann trotzdem indexiert werden (durch externe Links), dann aber ohne Inhalt und ohne Snippet. Faustregel: Entweder robots.txt-Sperre (Crawling verhindern) oder noindex (Indexierung verhindern, Crawling erlauben) – nie beides gleichzeitig. Das bestätigt Google explizit in der noindex-Dokumentation.
Fehler 3b: Für PDFs und Nicht-HTML-Dateien gibt es kein noindex im HTML-Head
Einen Fehler, den ich in Audits regelmäßig bei Publisher- und Shop-Websites sehe: PDFs sollen nicht indexiert werden – aber es wurde nur ein noindex-Meta-Tag gesetzt, der bei einer HTML-Seite funktioniert hätte. PDFs haben keinen <head>-Bereich. Der einzige Weg, Google mitzuteilen, dass eine PDF-Datei nicht indexiert werden soll, ist der X-Robots-Tag im HTTP-Antwort-Header – bestätigt von Google in der offiziellen Dokumentation.
Für Apache in der .htaccess:
<Files ~ "\.pdf$">
Header set X-Robots-Tag "noindex, nofollow"
</Files>Für Nginx:
location ~* \.pdf$ {
add_header X-Robots-Tag "noindex, nofollow";
}X-Robots-Tag lesen kann – das Muster ist identisch mit dem noindex-Problem oben.Fehler 4: Relative statt absolute Sitemap-URL
# Falsch
Sitemap: /sitemap.xml
# Richtig
Sitemap: https://www.domain.de/sitemap.xmlDie Sitemap-Direktive erwartet eine vollständige, absolute URL. Relative Pfade werden von vielen Crawlern nicht korrekt interpretiert.
Fehler 5: Crawl-delay für Googlebot
Ich sehe das noch regelmäßig in Audits: Crawl-delay: 10 für Googlebot. Google ignoriert das vollständig. Der Eintrag ist nicht schädlich, aber nutzlos – und er suggeriert, dass jemand denkt, er hätte damit etwas erreicht.
Fehler 6: Kein Test vor dem Go-live
Die robots.txt live zu stellen ohne vorherigen Test ist wie ein Deployment ohne Review. Dass es meistens gut geht, macht es nicht zur guten Praxis.
robots.txt testen: mein 5-Schritt-Protokoll
| Tool | Was es kann | Wo |
|---|---|---|
| Google robots.txt Tester | Offizielle Google-Implementierung, testet URL gegen User-agent | Google Search Console → Einstellungen |
| Screaming Frog | Massentest: welche gecrawlten URLs sind geblockt? | Desktop-Tool |
| Search Console → URL-Abdeckung | „Durch robots.txt blockierte URLs“ nach Go-live | Search Console → Indexierung |
Mein Protokoll für jeden robots.txt-Change:
- Änderung lokal vornehmen, Kommentar mit Datum ergänzen.
- Im Google robots.txt Tester gegen drei repräsentative URLs prüfen: eine, die geblockt sein soll; eine, die durchkommen soll; eine Grenzfall-URL (z. B. die Allow-Ausnahme).
- Für Wildcard-Regeln mindestens fünf URL-Varianten testen.
- Deployen.
- 48 Stunden später Search Console prüfen: keine unerwarteten „durch robots.txt blockiert“-Meldungen in der URL-Abdeckung.
Häufig gestellte Fragen (FAQ)
Brauche ich überhaupt eine robots.txt?
Technisch nein – ohne robots.txt crawlt Googlebot alles. Praktisch empfehle ich immer eine, zumindest um die Sitemap zu kommunizieren und offensichtliche Crawler-Fallen zu sperren. Die drei Minuten Aufwand lohnen sich.
Was passiert, wenn meine robots.txt nicht erreichbar ist?
Ein 5xx-Serverfehler lässt Googlebot das Crawling der Domain temporär pausieren. Ein 404 (nicht gefunden) interpretiert Google als „keine Einschränkungen“ und crawlt alles. Die robots.txt muss immer mit HTTP 200 antworten.
Kann ich KI-Training stoppen, aber trotzdem in KI-Antworten auftauchen?
Ja – und das ist 2026 eine relevante strategische Entscheidung. Disallow: / für GPTBot stoppt das Training-Crawling. Die llms.txt steuert unabhängig davon, was eine KI bei einer konkreten Anfrage priorisiert. Beide Ebenen funktionieren unabhängig voneinander.
Hilft robots.txt gegen Scraper?
Nein. Scraper mit Absicht ignorieren robots.txt. Die Datei richtet sich an kooperative Crawler. Gegen echtes Scraping helfen Rate Limiting, IP-Blocking und – wenn nötig – rechtliche Schritte.
Was passiert bei Konflikten zwischen Allow und Disallow?
Bei Google gewinnt die spezifischere Regel. Allow: /produkte/sale/ überschreibt Disallow: /produkte/, weil der Allow-Pfad länger und damit spezifischer ist. Bei anderen Crawlern kann die Logik abweichen – im Zweifelsfall testen.
Kann ich mehrere robots.txt-Dateien für eine Domain haben?
Nein. Es gibt immer genau eine robots.txt pro Domain-Origin, im Stammverzeichnis. Subdomains (blog.domain.de) brauchen jeweils eine eigene Datei unter blog.domain.de/robots.txt.
Fazit: simpel aufbauen, gezielt steuern, immer testen
Starte mit dem Minimum. Sperr offensichtliche Crawler-Fallen. Kommuniziere die Sitemap. Entscheide bewusst, welche KI-Crawler du wie steuerst – das ist 2026 keine theoretische Frage mehr. Und beobachte, ob die llms.txt für dein Setup sinnvoll ist – sie ist noch kein formaler Standard, wird aber von mehreren KI-Systemen bereits aktiv genutzt.
Wer tiefer in das Thema einsteigen will: Der Crawling- & Indexierungs-Guide erklärt, wie Googlebot die robots.txt in den Gesamtprozess von Crawling bis Indexierung einbettet – inklusive Index-Tiers und Caffeine-System. Die robots.txt ist der Eingang. Was dahinter passiert, ist die eigentlich interessante Geschichte.
Disallow: / in der Produktion? ✓ — CSS und JS nicht gesperrt? ✓ — Sitemap als absolute URL? ✓ — Google robots.txt Tester durchgelaufen? ✓ — KI-Crawler-Strategie definiert (GPTBot, ClaudeBot, Google-Extended)? ✓
