- →Die robots.txt steuert Crawling, nicht Indexierung: Eine per Disallow gesperrte URL kann über externe Links trotzdem im Index landen. Zuverlässige Deindexierung braucht eine crawlbare Seite mit noindex.
- →Google unterstützt genau vier Felder (user-agent, disallow, allow, sitemap). Direktiven wie crawl-delay oder noindex in der robots.txt sind toter Code, das hat Google in den Dokumentations-Updates 2025/2026 festgezurrt.
- →Die Fehlercodes haben harte Konsequenzen: 404 heißt alles erlaubt, 5xx heißt zunächst alles gesperrt. Der HTTP-Status der Datei gehört ins Monitoring, nicht nur die Homepage.
- →2026 ist die robots.txt ein Policy-Dokument für AI-Governance: GPTBot und ClaudeBot wachsen stark, aber laut Cloudflare hatten Mitte 2025 nur rund 14 % der Top-10.000-Domains explizite AI-Regeln. Der Rest entscheidet per Unterlassung.
- →Google-Extended zu sperren ist reine Training-Kontrolle: Es hat keinerlei Einfluss auf Googlebot, die Suche oder AI Overviews.
- →Im Netlinking gilt: Ein Link auf einer nicht crawlbaren Seite ist verbranntes Budget. Die robots.txt des Zielmediums gehört vor jede Buchung, nicht danach.
Was die robots.txt wirklich ist
Eine robots.txt ist eine Textdatei im Root einer Domain, die Crawlern mitteilt, welche Pfade sie abrufen dürfen. Das klingt banal, aber die operative Realität ist: Diese Datei ist die erste Ressource, die jeder seriöse Bot vor dem Crawl einer Site anfragt, und damit der einzige Ort, an dem ein Betreiber die Maschinenzugriffe auf seine Inhalte zentral regelt. Sie ist eine Absichtserklärung, kein Zugangsschutz: Das Robots Exclusion Protocol, seit 1994 Konvention und seit 2022 als RFC 9309 formalisiert, funktioniert nur, weil sich reputable Crawler freiwillig daran halten.
Google dokumentiert das ausdrücklich: Die eigenen Crawler folgen den robots.txt-Regeln beim automatischen Crawling immer, so die im April 2026 aktualisierte Referenz zu den «common crawlers» in der Google-Crawling-Dokumentation. Wer die Datei dagegen als Sicherheitsmechanismus versteht, hat sie missverstanden. Bösartige Scraper ignorieren sie schlicht, und die Datei selbst ist öffentlich abrufbar: Jeder Wettbewerber kann sie lesen und daraus die Architektur der Site ableiten.
Wie schlicht die Praxis tatsächlich ist, zeigt eine Google-Analyse von 16 Millionen robots.txt-Dateien, deren Ergebnisse im April 2026 publik wurden (StanVentures): Die Nutzung kollabiert fast vollständig auf drei Felder, user-agent, disallow und allow, mit einem nahezu senkrechten Abfall danach. Der Wildcard-User-agent * dominiert, die meisten Betreiber schreiben Pauschalregeln statt crawlerspezifischer Gruppen. Parallel hat Google in seinem Dokumentations-Changelog klargestellt: Jedes Feld, das nicht in der offiziellen Dokumentation steht, wird nicht unterstützt. Punkt.
Mechanik 2026: vier Felder, klare Fehlerregeln
Die Datei liegt zwingend im Root des jeweiligen Hosts: https://www.beispiel.de/robots.txt gilt für genau diesen Host. Eine Subdomain braucht ihre eigene Datei, ein Unterverzeichnis wird komplett ignoriert. Google liest die Datei pro Protokoll-Host-Kombination und cached sie in der Regel bis zu 24 Stunden. Wer eine Regel ändert, sollte also nicht erwarten, dass sie in der nächsten Minute greift.
Unterstützt sind exakt vier Felder: user-agent, disallow, allow und sitemap. Die Regeln werden pro User-agent-Gruppe ausgewertet, bei konkurrierenden Pfadregeln gewinnt die spezifischste (Longest Match), und allow kann gezielt Ausnahmen in gesperrte Verzeichnisse schneiden. Wildcards mit * und das Ende-Zeichen $ erlauben Musterregeln, etwa für Parameter-URLs. Der Sitemap-Verweis ist der pragmatischste Teil der Datei: ein absoluter Link auf die XML-Sitemap der Domain, den jeder Crawler findet, auch ohne Zugang zur Search Console.
Die Fehlerbehandlung ist der Teil, den die meisten Audits ignorieren, obwohl er die härtesten Konsequenzen hat. Nach Google Search Central gilt: Antwortet die robots.txt mit einem 4xx-Status (inklusive 404), crawlt Google ohne jede Einschränkung, als gäbe es keine Datei. Antwortet sie mit 5xx, behandelt Google die gesamte Site zunächst als komplett gesperrt. Ein kaputter Server, der ausgerechnet die robots.txt mit 503 ausliefert, stoppt damit das Crawling der ganzen Domain.
Die Web-Almanac-Daten 2025 (zusammengefasst von Search Engine Land, April 2026) zeigen leichte Besserung im Feld: Der Anteil der robots.txt-Abrufe mit 404 fiel von 14 % auf 13 %, 5xx-Antworten liegen bei rund 0,1 %. Die Google-Studie über 16 Millionen Dateien fand zugleich massenhaft kaputte Exemplare, darunter komplette HTML-Seiten, die als robots.txt ausgeliefert werden. Der robots.txt-Report in der Search Console zeigt, welche Version Google zuletzt gelesen hat und ob sie parsebar war: Das gehört in jedes technische Monitoring.
Crawling steuern heißt nicht Indexierung steuern
Der teuerste Denkfehler im Umgang mit der Datei: disallow verhindert Crawling, nicht Indexierung. Eine gesperrte URL kann trotzdem im Index landen, wenn externe Links auf sie zeigen. Google zeigt sie dann ohne Beschreibung an, weil es den Inhalt nie gelesen hat. Wer eine Seite zuverlässig aus dem Index will, braucht das Gegenteil einer Sperre: Die Seite muss crawlbar sein, damit Google das noindex-Signal im Meta-Tag oder HTTP-Header überhaupt sehen kann. Beides gleichzeitig, Disallow plus noindex, neutralisiert sich selbst.
Das war nicht immer so sauber getrennt: Bis 2019 tolerierte Google eine inoffizielle noindex-Direktive in der robots.txt, seitdem ist sie toter Code. Die 2025 aktualisierte Dokumentation hat diese Linie noch einmal festgezurrt: Alles, was nicht user-agent, disallow, allow oder sitemap ist, wird ignoriert, auch das immer noch massenhaft kopierte crawl-delay.
Bleibt das Argument Crawl-Budget. Laut Google Search Central ist Crawl-Budget-Management primär ein Thema für sehr große Websites. Ein Magazin mit 300 Artikeln optimiert hier nichts Messbares. Relevant wird die Datei bei programmatischen Strukturen mit Facetten, Parametern und sechsstelligen URL-Räumen: Dort entscheidet eine saubere Disallow-Architektur, ob Googlebot seine Zeit auf indexierbaren Inhalten verbringt oder in endlosen Filterkombinationen verbrennt.
AI-Bots: die robots.txt als Policy-Dokument
Die strukturelle Veränderung der letzten zwei Jahre: Die robots.txt ist vom reinen Crawl-Steuerungsinstrument zum Policy-Dokument für Bot- und AI-Governance geworden, so die Einordnung von Search Engine Land (April 2026). Die Zahlen dahinter sind eindeutig: GPTBot stieg von 2,9 % (Desktop) beziehungsweise 2,7 % (Mobile) aller Crawler-Requests 2024 auf 4,5 % und 4,2 % im Jahr 2025. ClaudeBot verdoppelte sich fast, von 1,9 %/1,6 % auf 3,6 %/3,4 % (Web Almanac 2025 via Search Engine Land).
Gleichzeitig regelt kaum jemand diese Zugriffe bewusst: Nach Cloudflare-Analysen hatten Mitte 2025 nur rund 14 % der Top-10.000-Domains überhaupt AI-spezifische robots.txt-Regeln. Die übrigen rund 86 % treffen die Entscheidung zwischen AI-Training und AI-Sichtbarkeit per Unterlassung.
Besonders hartnäckig ist die Verwirrung um Google-Extended. Der Token steuert ausschließlich, ob Inhalte für das Training von Googles AI-Systemen wie Gemini genutzt werden dürfen. Er hat keinerlei Einfluss auf Googlebot, auf die Suche oder auf AI Overviews, die weiterhin über den regulären Googlebot laufen (so die Google-Dokumentation, aufbereitet unter anderem im Conductor-Guide 2026). Wer AI Overviews vollständig vermeiden wollte, müsste Googlebot sperren und damit die eigene Suchsichtbarkeit opfern. Das ist keine SEO-Entscheidung mehr, sondern eine Verlagsstrategie-Entscheidung.
Unsere Haltung: Training-Bots und Retrieval-Bots getrennt bewerten. Ein Retrieval-Bot wie OAI-SearchBot bringt Zitierungen in AI-Antworten und damit potenziell Sichtbarkeit zurück; ein reiner Training-Crawler gibt nichts zurück. Für die meisten Publisher ist «Training sperren, Retrieval erlauben» der rationale Default, festgehalten in expliziten Regeln statt per Zufall.
Die Netlinking-Perspektive: crawlbar oder wertlos
Für Netlinking-Operationen ist die robots.txt des Zielmediums Due Diligence, keine Formalie. Ein Backlink existiert für Google erst, wenn die verlinkende Seite gecrawlt und indexiert wurde. Steht die Publikations-URL hinter einem Disallow, wird der Link nie gelesen, nie gewertet, nie im Linkgraph verbucht. Genau davor warnt auch die Auswertung der Google-Studie (StanVentures, April 2026): Gastbeiträge auf Sites, deren robots.txt Google aussperrt, sind verbranntes Outreach-Budget.
Die Prüfroutine vor jeder Buchung dauert zwei Minuten: robots.txt des Zielhosts lesen, den Pfad der geplanten Publikation gegen die Disallow-Regeln halten, zusätzlich Meta-Robots und X-Robots-Tag der Kategorie prüfen und stichprobenartig kontrollieren, ob vergleichbare Artikel des Mediums tatsächlich im Index stehen. Wer Links über Zwischenhändler kauft, kann diese Kontrolle oft gar nicht durchführen, weil die Ziel-URL erst nach der Zahlung feststeht.
Das ist einer der Gründe, warum wir bei Nautilinks die 50 französischen Redaktionsmedien, auf denen unsere Kunden publizieren, im Eigenbetrieb führen: Crawl-Policy, Indexierbarkeit und robots.txt jeder einzelnen Domain kontrollieren wir selbst, statt auf den Webmaster eines fremden Partners zu hoffen. Welche Medien eine Kampagne tragen können, lässt sich im offen einsehbaren Katalog der Plattform prüfen, inklusive der Domains und damit auch ihrer Crawl-Konfiguration, vor der ersten Bestellung.
Typische Fehler aus der Audit-Praxis
Der Klassiker bleibt das Staging-Deployment: Eine Testumgebung läuft mit Disallow für die gesamte Site, die Datei wandert beim Launch mit auf die Live-Domain, und das Crawling steht still. Aus eigener Audit-Erfahrung ist das der häufigste Totalschaden, gerade weil er still passiert. Die Site bleibt erreichbar, Nutzer merken nichts, nur die Crawling-Statistiken in der Search Console kippen über Wochen ab.
Zweiter Dauerbrenner: gesperrte CSS- und JavaScript-Ressourcen. Google rendert Seiten, um Layout und Mobiltauglichkeit zu bewerten. Wer /assets/ oder Theme-Verzeichnisse pauschal sperrt, liefert Google eine kaputte Version der eigenen Site zur Bewertung. Drittens die Datei selbst als Fehlerquelle: Die 16-Millionen-Analyse fand robots.txt-URLs, die komplette HTML-Seiten ausliefern, etwa weil ein CMS die Fehlerseite mit Status 200 rendert. So eine Datei ist für den Parser unbrauchbar, mit undefiniertem Ergebnis für die ganze Domain.
Und schließlich der Irrglaube, die robots.txt sei ein Datenschutzinstrument. Gerade im deutschen Markt sehen wir Disallow-Regeln auf Admin-Bereiche, interne Verzeichnisse oder Kundenportale, offenbar in der Annahme, damit etwas für die DSGVO-Konformität zu tun. Das Gegenteil ist der Fall: Die Datei ist öffentlich und macht sensible Pfade erst recht auffindbar. Zugriffsschutz gehört auf Server- und Auth-Ebene, per HTTP-Auth, Login oder IP-Restriktion. Die robots.txt schützt exakt nichts, sie bittet höflich.
Nautilinks betreibt ein eigenes Netzwerk redaktioneller Medien. In-House verfasste Artikel, Transparenzhinweise beachtet, Ankertext-Mix kalibriert.
Häufige Fragen
Warum taucht eine per Disallow gesperrte URL trotzdem in den Suchergebnissen auf?
Weil disallow nur das Crawling verhindert, nicht die Indexierung. Verweisen externe Links auf die URL, kann Google sie als reinen URL-Eintrag indexieren, ohne den Inhalt je gelesen zu haben. Die Lösung ist kontraintuitiv: Sperre aufheben, damit Googlebot die Seite abruft und das noindex im Meta-Tag oder X-Robots-Header sehen kann. Erst nach erfolgter Deindexierung lässt sich die Crawl-Sperre wieder setzen, falls sie dann überhaupt noch nötig ist.
Was passiert, wenn meine robots.txt mit einem 5xx-Fehler antwortet?
Google behandelt die gesamte Site zunächst so, als wäre alles gesperrt, und das Crawling stoppt. Laut Google-Dokumentation kann nach längerer Nichterreichbarkeit eine gecachte Version genutzt oder die Datei wie nicht vorhanden behandelt werden, darauf sollte aber niemand bauen. Ein 404 ist dagegen harmlos: keine Datei heißt keine Einschränkungen. Deshalb gehört der HTTP-Status der robots.txt ins Uptime-Monitoring, nicht nur die Erreichbarkeit der Homepage.
Ist crawl-delay 2026 noch eine sinnvolle Direktive?
Für Google nicht. Die Dokumentation stellt seit den Updates 2025/2026 klar, dass nur user-agent, disallow, allow und sitemap unterstützt werden; crawl-delay wird ignoriert. Bing wertet die Direktive weiterhin aus. Wer Googlebots Frequenz wirklich drosseln muss, macht das über Serverantworten wie 503 oder 429, denn Google passt die Crawl-Rate ohnehin an die Serverperformance an. In den meisten Dateien ist crawl-delay ein Kopierartefakt aus einem Tutorial von 2012.
Sollte ich GPTBot, ClaudeBot und Google-Extended sperren?
Getrennt entscheiden. Training-Tokens wie GPTBot fürs Modelltraining oder Google-Extended kosten bei Sperrung keine Suchsichtbarkeit: Google-Extended hat keinen Einfluss auf Googlebot oder AI Overviews. Retrieval-Bots wie OAI-SearchBot liefern dagegen Zitierungen in AI-Antworten; wer sie sperrt, verzichtet auf diese Sichtbarkeit. Entscheidend ist eine explizite Policy: Laut Cloudflare hatten Mitte 2025 nur rund 14 % der Top-10.000-Domains überhaupt AI-spezifische Regeln definiert.
Zählt ein gekaufter Backlink, wenn die verlinkende Seite per robots.txt gesperrt ist?
Praktisch nein. Google muss die verlinkende Seite crawlen, um den Link überhaupt zu sehen; eine Disallow-Regel verhindert genau das. Die Seite kann zwar als URL-Eintrag im Index stehen, ihr Inhalt und damit der Link bleiben aber ungelesen und fließen nicht in den Linkgraph ein. Vor jeder Buchung gehört deshalb der Pfad der Publikations-URL gegen die robots.txt des Mediums geprüft, plus Meta-Robots und eine Index-Stichprobe vergleichbarer Artikel.
Braucht jede Subdomain eine eigene robots.txt?
Ja. Die Datei gilt pro Protokoll-Host-Kombination: blog.beispiel.de liest nicht die Datei von www.beispiel.de. Ein Unterverzeichnis wie /blog/robots.txt wird komplett ignoriert, die Datei muss im Root des jeweiligen Hosts liegen. Bei Migrationen und Multi-Host-Setups, etwa einem Shop auf Subdomain oder separaten CDN-Hosts, ist das eine klassische Lücke: Der Haupt-Host ist sauber konfiguriert, während die Subdomain völlig ungeregelt gecrawlt wird oder versehentlich gesperrt ist.
Prüfen Sie Ihr Wissen
Quiz: robots.txt
1/3Welche Felder unterstützt Google in der robots.txt offiziell?