Robots.txt Fehler: Die häufigsten Fehler und wie Sie sie beheben

Welche robots txt Fehler sind am häufigsten?

Robots txt Fehler sind falsche Crawling Anweisungen an Suchmaschinen: gesperrte Dateien für CSS und JavaScript, eine viel zu breite Disallow Regel, robots.txt statt noindex, übersehene Groß und Kleinschreibung, eine fehlerhafte Sitemap Zeile und eine Datei über 500 KiB. Die Folge ist meist ein stiller Verlust an Traffic.

Die Datei besteht nur aus wenigen Zeilen, deshalb schreiben viele Teams sie einmal und vergessen sie dann. Allerdings genügt ein einziger Schrägstrich, um eine ganze Website für den Googlebot zu schließen. Seit 2012 führe ich technische Audits durch, und einige der teuersten Probleme steckten genau in dieser kleinen Textdatei.

Das Sperren von KI Crawlern behandle ich hier nicht; dazu gibt es meinen eigenen Leitfaden zu KI Crawlern und llms.txt. Stattdessen konzentriere ich mich auf Fehler, die das klassische Crawling für die Google Suche stören. Jeder Punkt stützt sich auf die offizielle Dokumentation von Google und auf den Standard RFC 9309.

Was leistet eine robots.txt Datei und was leistet sie nicht?

Die robots.txt ist eine einfache Textdatei im Stammverzeichnis Ihres Hosts. Konkret sagt sie Crawlern, welche Pfade sie abrufen dürfen. Das heißt, sie steuert das Crawling, nicht die Indexierung. Wer diesen Unterschied übersieht, produziert die Hälfte der typischen Fehler fast automatisch.

Die Einführung von Google zur robots.txt sagt es deutlich: Die Datei ist kein Mechanismus, um eine Seite aus Google herauszuhalten. Außerdem haben die Regeln keine bindende Kraft. Jeder Crawler entscheidet selbst, ob er sie befolgt, und bösartige Bots ignorieren die Datei einfach.

• Crawling steuern: Sie teilt seriösen Crawlern mit, welche Pfade sie nicht abrufen sollen.
• Sitemap melden: Über die Sitemap Zeile nennt sie die Adresse Ihrer XML Sitemap.
• Keine Deindexierung: Eine Seite verschwindet durch sie nicht aus den Suchergebnissen.
• Kein Schutz: Sie schützt keinen privaten Ordner; im Gegenteil, sie zeigt dessen Adresse jedem, der die Datei öffnet.

Dazu kommt die Frage des Standards. Jahrzehntelang war die robots.txt nur eine informelle Konvention. Im September 2022 machte RFC 9309 das Robots Exclusion Protocol zu einem offiziellen Standard. Der Parser von Google folgt diesem Standard, daher gelten die meisten Regeln unten auch für andere große Suchmaschinen.

Folglich ist die robots.txt kein Sicherheitswerkzeug. Für Adminbereiche und Testumgebungen brauchen Sie Passwörter. Mit diesem Rahmen im Kopf sehen Sie schneller, warum die folgenden Fehler immer wiederkehren.

Warum ist das Sperren von CSS und JavaScript ein ernster Fehler?

Der Googlebot liest eine Seite nicht nur als reines HTML. Stattdessen rendert er sie wie ein Browser und bewertet das Ergebnis. Deshalb sieht Google nicht, was Ihre Besucher sehen, wenn Sie Themedateien, Stylesheets oder wichtige Skripte blockieren.

Alte Gewohnheiten sorgen hier noch immer für Ärger. Zum Beispiel empfahlen ältere Themes und veraltete Anleitungen, ganze Plugin oder Inhaltsordner zu sperren. Dabei liegen genau dort oft die Dateien, die Menü, Produktraster oder Preisbox aufbauen. Somit sieht Google eine leere oder kaputte Seite.

Google bleibt bei diesem Thema ausgewogen. Laut offizieller Anleitung dürfen Sie unwichtige Bilder, Skripte oder Stildateien blockieren. Allerdings sollten Sie das lassen, wenn die Seite ohne diese Dateien schwerer zu verstehen ist. In der Praxis ist die Grenze schwer zu ziehen, daher lasse ich Ressourcendateien standardmäßig offen.

Für Bilder gilt dieselbe Logik. Wenn Ihre Produktfotos in der Bildersuche erscheinen sollen, lassen Sie diese Ordner offen. Andererseits ist es sinnvoll, wirklich wertlose Dateien zu sperren, etwa alte Backups oder temporäre Downloads. Entscheidend ist, dass hinter jeder Sperre eine bewusste Entscheidung steht.

Zur Kontrolle starten Sie in der Search Console bei der URL Prüfung einen Livetest und sehen sich den gerenderten Screenshot an. Wirkt die Seite nackt, listen Sie die Ressourcen auf, die der Googlebot nicht laden konnte. Danach entscheiden Sie Datei für Datei, ob die Sperre bleiben soll.

Wie kann eine einzige falsche Disallow Zeile die ganze Website sperren?

Eine Disallow Regel wirkt als Präfix für Pfade. Wenn Sie also Disallow: / schreiben, sperren Sie jede Adresse, die im Stammverzeichnis beginnt, und damit die gesamte Website. Eine leere Disallow Zeile sagt dagegen das Gegenteil: Nichts ist gesperrt. Kurz gesagt, der Unterschied besteht aus einem einzigen Zeichen.

Am häufigsten sehe ich diesen Fehler am Tag des Livegangs. Ein Entwickler setzt Disallow: / auf die Testumgebung, und die Datei wandert dann mit allem anderen auf den Liveserver. Niemand bemerkt es, denn für Besucher funktioniert die Seite ganz normal. Erst einige Wochen später fällt die Kurve in der Search Console.

Die Präfixlogik erzeugt zudem subtilere Fehler. Zum Beispiel sperrt Disallow: /blog nicht nur den Blogordner, sondern auch /blogartikel oder /blogger, weil beide Pfade mit denselben Buchstaben beginnen. Meinen Sie den Ordner, dann schließen Sie die Regel mit einem Schrägstrich ab: Disallow: /blog/ drückt Ihre Absicht viel genauer aus.

1. Lesen Sie jede Disallow Zeile und notieren Sie, welche Pfade sie tatsächlich abdeckt.
2. Beenden Sie die Regel mit einem Schrägstrich, wenn Sie einen Ordner meinen.
3. Testen Sie echte Adressen, sobald Sie den Platzhalter (*) oder das Endzeichen ($) nutzen.
4. Nehmen Sie den Punkt „robots.txt Stammregel“ in Ihre Checkliste für den Livegang auf.

Kann die robots.txt eine Seite aus dem Google Index entfernen?

Nein. Das ist das verbreitetste Missverständnis. Sperren Sie eine Seite in der robots.txt, crawlt Google sie nicht mehr; verlinken andere Seiten aber auf diese Adresse, kann Google die URL trotzdem indexieren. Dann sehen Sie ein nacktes Ergebnis ohne Beschreibung.

Die Einführung von Google beschreibt genau dieses Szenario: Eine gesperrte Seite kann im Index landen, wenn andere Websites auf sie verweisen. In der Search Console erkennen Sie das an einem Status, der meldet, dass die Seite trotz Sperre in der robots.txt im Index steht.

Eine noindex Zeile in der robots.txt hilft ebenfalls nicht. Google beendete die Unterstützung dieser inoffiziellen Regel zum 1. September 2019 und kündigte das im Search Central Blog an. Anders gesagt, Google unterstützt heute nur vier Felder: User-agent, allow, disallow und sitemap.

Wenn Sie eine Seite aus den Suchergebnissen heraushalten möchten, haben Sie drei Wege:

• Setzen Sie ein noindex Metatag auf die Seite und lassen Sie das Crawling offen.
• Nutzen Sie für Dateien ohne HTML, etwa PDFs, den Header X-Robots-Tag.
• Schützen Sie private Bereiche mit einem Passwort oder löschen Sie die Seite ganz.

Warum schadet die Kombination aus noindex und Disallow?

Weil Google eine Seite crawlen muss, um ihr noindex Tag zu sehen. Markieren Sie eine Seite mit noindex und sperren Sie sie zugleich in der robots.txt, kommt der Googlebot nicht hinein und liest das Tag nie. Somit kann die Seite genau dort bleiben, wo Sie sie nicht haben wollten: im Index.

Dieser Fehler beginnt meist mit guten Absichten. Ein Team möchte eine Gruppe von Seiten aufräumen und denkt, zwei Schutzmaßnahmen seien besser als eine. Allerdings heben sich die beiden Maßnahmen gegenseitig auf. Setzen Sie zuerst noindex, lassen Sie Google die Seiten erneut crawlen und dann aus dem Index nehmen.

Sind die Seiten aus dem Index verschwunden, können Sie danach eine Regel in der robots.txt ergänzen, um Crawling Kapazität zu sparen. Trotzdem zählt die Reihenfolge: erst noindex, dann beobachten, zuletzt sperren. Sonst entstehen „Geister“ URLs, die monatelang im Index hängen.

Filter und Sortierparameter sind der Bereich, in dem dieser Fehler am häufigsten auftritt. Onlineshops sperren oft Tausende Parameter URLs und versehen sie gleichzeitig mit noindex. Für die Planung hilft Ihnen der Entscheidungsweg in meinem Beitrag zu URL Parametern und SEO.

Welche robots txt Fehler entstehen durch Groß und Kleinschreibung?

In der Datei gelten zwei verschiedene Regeln. Feldnamen wie User-agent, allow und disallow unterscheiden nicht zwischen Groß und Kleinschreibung. Pfadwerte dagegen schon. Disallow: /Produkte/ erfasst also /produkte/ nicht.

Das spielt vor allem auf Websites eine Rolle, auf denen sich alte und neue URL Strukturen überlappen. Zum Beispiel nutzte eine frühere Version einer Website großgeschriebene Ordnernamen, die neue Version dagegen Kleinbuchstaben. Die robots.txt behielt allerdings die alte Schreibweise. Folglich bleibt der Bereich, den Sie schließen wollten, komplett offen.

Auch der umgekehrte Fall kommt vor. Liefert ein CMS denselben Inhalt unter groß und kleingeschriebenen Adressen aus, bleibt die zweite Variante crawlbar, wenn Sie nur eine sperren. In diesem Fall liegt die eigentliche Lösung nicht in der robots.txt, sondern in einer Weiterleitung auf eine kanonische Schreibweise.

Meine Prüfung ist einfach. Ich ziehe aus den Serverlogs die Pfade, die der Googlebot tatsächlich abruft, und vergleiche sie Buchstabe für Buchstabe mit den Zeilen der robots.txt. Das können Sie mit der Logfile Analyse ebenso tun. So finden Sie robots txt Fehler anhand echter Crawling Daten statt durch Raten.

Welche Regel gewinnt, wenn sich Allow und Disallow widersprechen?

Google wählt die Regel mit dem längsten passenden Pfad. Das heißt, die spezifischste Regel gewinnt. Sind zwei passende Regeln gleich lang, wendet Google die am wenigsten einschränkende an, also die Allow Regel.

Diese Logik überrascht Teams, die in Reihenfolgen denken. Viele nehmen an, dass die Zeile weiter oben Vorrang hat. Für Google spielt die Reihenfolge der Zeilen jedoch keine Rolle; entscheidend ist die Länge der Übereinstimmung.

Schreiben Sie zum Beispiel Disallow: /konto/ und Allow: /konto/login zusammen, bleibt die Loginseite crawlbar. Denn die Allow Regel passt auf einen längeren Pfad. Bewusst eingesetzt ist dieses Muster praktisch: Sie schließen einen Ordner und öffnen darin eine einzelne Seite.

Ein kniffligerer Fall: Sie sperren einen Sortierparameter mit Disallow: /*?sort= und lassen die Paginierung mit Allow: /*?seite= offen. Trägt eine Adresse beide Parameter, müssen Sie ausrechnen, welche Regel länger passt. Diese Rechnung geht leichter schief, als es aussieht.

Platzhalter machen die Rechnung zusätzlich schwerer. Deshalb testen Sie das Ergebnis an mehreren echten Adressen, sobald sich Regeln überschneiden. Wenn Sie Ihre Regeln neu aufbauen wollen, bietet der robots.txt Generator einen sauberen Startpunkt; danach prüfen Sie die Überschneidungen von Hand.

Warum verschmelzen User-agent Gruppen auf unerwartete Weise?

Die Regeln der robots.txt arbeiten in Gruppen. Jede Gruppe beginnt mit einer oder mehreren Zeilen User-agent, und die Regeln darunter gelten für diese Crawler. Ein Crawler folgt nur der Gruppe, die am spezifischsten auf ihn passt, und ignoriert den Rest.

Hier liegt die typische Falle. Enthält die Datei eine allgemeine Sterngruppe und eine eigene Gruppe für den Googlebot, liest der Googlebot nur seine eigene Gruppe. Wichtige Sperren in der Sterngruppe gelten für ihn dann nicht mehr. Viele Teams ergänzen eine Googlebot Gruppe, ohne zu merken, dass sie damit ihre allgemeinen Regeln verlieren.

Andererseits fasst Google zwei getrennte Gruppen für denselben User-agent zu einer zusammen. In komplexen Dateien führt dieses Verhalten zu Überraschungen. Besonders oft passiert das auf Websites, auf denen mehrere Plugins oder mehrere Teams Zeilen in dieselbe Datei schreiben.

• Halten Sie pro Crawler genau eine Gruppe.
• Öffnen Sie eine eigene Googlebot Gruppe, dann kopieren Sie die allgemeinen Regeln auch dort hinein.
• Setzen Sie Kommentarzeilen zwischen die Gruppen, damit klar bleibt, wer was warum ergänzt hat.

Welche robots txt Fehler stecken in der Sitemap Zeile?

Die Sitemap Zeile ist der einfachste Weg, Crawlern Ihre Sitemap zu zeigen. Dennoch sammeln sich auch hier typische robots txt Fehler. Am häufigsten sehe ich eine relative Adresse. Google erwartet als Wert jedoch eine vollständige URL samt Protokoll.

Der zweite Fehler ist ein Verweis auf eine verschobene oder gelöschte Sitemap. Nach einem Relaunch ändert sich die Adresse der Sitemap oft, während die robots.txt die alte behält. Drittens mischen viele HTTP und HTTPS oder die Varianten mit und ohne www. Die Adresse der Sitemap sollte zur kanonischen Version Ihrer Website passen.

Es gibt auch gute Nachrichten. Laut offizieller Dokumentation dürfen Sie mehrere Sitemap Zeilen angeben, und diese gehören zu keiner User-agent Gruppe. Zudem muss die Sitemap nicht auf demselben Host wie die robots.txt liegen.

1. Prüfen Sie, ob die Sitemap Zeile eine vollständige URL enthält.
2. Öffnen Sie die Adresse im Browser; Sie sollten den Statuscode 200 und gültiges XML sehen.
3. Nehmen Sie Adressen, die Sie in der robots.txt sperren, aus der Sitemap heraus, denn die beiden Signale widersprechen sich.

Müssen Sie die Sitemap neu erstellen, beschleunigt der XML Sitemap Generator die Arbeit. Für das Datumsfeld lohnt sich mein Beitrag dazu, wie Sie lastmod in der Sitemap richtig setzen.

Welche Probleme verursachen das Limit von 500 KiB und das Dateiformat?

Google liest die ersten 500 Kibibyte einer robots.txt und ignoriert alles danach. Auch RFC 9309 verlangt, dass Crawler mindestens 500 KiB verarbeiten. Für eine kleine Website wirkt die Grenze weit weg; automatisch erzeugte Dateien wachsen allerdings schnell.

Am häufigsten sehe ich das auf Websites, die für Tausende einzelne Adressen jeweils eine eigene Disallow Zeile anlegen. Zum Beispiel bläht ein Plugin, das für jedes gelöschte Produkt eine Zeile ergänzt, die Datei immer weiter auf. Überschreitet sie die Grenze, verlieren die Regeln am Ende ihre Wirkung, und niemand weiß, welche Zeilen Google übersprungen hat.

Die Lösung heißt Muster statt Einzeladressen. Teilen die Seiten einen Ordner oder einen Parameter, ersetzt eine Regel Hunderte Zeilen. Außerdem behandeln Sie gelöschte Seiten besser mit dem Statuscode 404 oder 410 als mit der robots.txt.

Beim Format gibt es ebenfalls zwei Regeln. Speichern Sie die Datei als UTF8 und trennen Sie Zeilen mit CR, CR/LF oder LF. Typografische Anführungszeichen aus einer Textverarbeitung, unsichtbare Zeichen oder eine andere Kodierung können das Parsen stören. Die Details finden Sie im Text von RFC 9309.

Wie beeinflusst der Statuscode des Servers die robots.txt?

Google achtet bei der robots.txt ebenso auf die HTTP Antwort wie auf den Inhalt. Bei einer Antwort im Bereich 2xx verarbeitet Google die Datei wie geliefert. Bei Antworten im Bereich 4xx, außer 429, tut Google so, als gäbe es keine Datei, und crawlt ohne Einschränkungen.

Die eigentliche Gefahr liegt bei Fehlern im Bereich 5xx. Laut der Spezifikation von Google zur robots.txt stoppt Google bei einem Serverfehler zunächst für 12 Stunden das Crawling. In den folgenden 30 Tagen nutzt Google die letzte gültige Kopie aus dem Cache. Danach, sofern die Website selbst erreichbar ist, verhält sich Google so, als gäbe es keine Einschränkungen.

Also kann schon ein kurzer Serverfehler auf der Adresse der robots.txt das Crawling der ganzen Website bremsen. Das sehe ich vor allem dann, wenn eine Firewall, ein CDN oder ein Wartungsmodus die Anfrage blockiert. Ist Ihre Crawling Rate ohne klaren Grund gefallen, prüfen Sie diesen Statuscode zusammen mit den Schritten aus meinem Beitrag dazu, warum der Googlebot weniger crawlt.

Noch ein Detail: 429 unterscheidet sich von den anderen Codes im Bereich 4xx. Google liest ihn nicht als „keine Datei“, sondern als „langsamer“, und senkt die Crawling Rate. Denken Sie daran, wenn Sie Regeln zur Ratenbegrenzung schreiben, die den Googlebot betreffen.

Auch für Weiterleitungen gibt es eine Grenze. Google folgt mindestens fünf Weiterleitungen und behandelt die Datei danach wie einen Statuscode 404. Zudem speichert Google die Datei in der Regel bis zu 24 Stunden im Cache, daher wirkt Ihre Änderung nicht immer sofort.

Warum übersehen Teams Subdomains, Protokolle und Ports?

Eine robots.txt gilt nur für den Host, das Protokoll und den Port, unter denen sie liegt. Die Datei auf beispiel.de deckt also shop.beispiel.de nicht ab. Jede Subdomain braucht eine eigene robots.txt in ihrem eigenen Stammverzeichnis.

Unternehmen, die einen Shop, einen Blog oder ein Hilfecenter auf einer eigenen Subdomain betreiben, vergessen das oft. Sie pflegen die Datei der Hauptseite sorgfältig, während die Subdomain gar keine Datei hat oder die Standarddatei der Plattform behält. Diese Standarddatei lässt manchmal nutzlose Bereiche offen und sperrt manchmal wichtige Seiten.

Auch der Speicherort zählt. Die robots.txt wirkt nur im Stammverzeichnis; in Unterordnern suchen Crawler nie danach. Ein Dienst auf einem Port außerhalb des Standards braucht ebenfalls eine eigene Datei. HTTP und HTTPS gelten zudem als getrennte Ursprünge, daher sollte Ihre Weiterleitungskette auch die Anfrage nach der robots.txt an die richtige Stelle schicken.

Eine praktische Gewohnheit hilft hier. Listen Sie alle Domains und Subdomains auf, öffnen Sie jede Adresse der robots.txt und notieren Sie den Inhalt. Dieses kleine Inventar zeigt schnell eine vergessene Testsubdomain im Index oder einen Shopbereich, der geschlossen bleibt.

Planen Sie einen Umbau, dann hilft Ihnen meine Checkliste für die Website Migration, damit keines dieser Details verloren geht.

Warum bewirken Crawl-delay und andere nicht unterstützte Zeilen nichts?

Google unterstützt in der robots.txt nur vier Felder: User-agent, allow, disallow und sitemap. Zeilen wie Crawl-delay, noindex, nofollow oder host ignoriert Google. Sie dürfen in der Datei stehen, haben auf den Googlebot aber keinerlei Wirkung.

Das Problem entsteht, weil Teams sich auf diese Zeilen verlassen. Zum Beispiel glaubt ein Team, das bei hoher Serverlast Crawl-delay ergänzt, das Problem sei gelöst, obwohl sich die Crawling Rate des Googlebots überhaupt nicht ändert. Einige andere Suchmaschinen beachten die Zeile womöglich; Google tut das nicht.

Belastet der Googlebot Ihren Server, dann signalisieren vorübergehende Antworten mit 500, 503 oder 429, dass Google langsamer crawlen soll. Eine dauerhafte Lösung bedeutet jedoch mehr Serverkapazität, besseres Caching und weniger nutzlose Adressen. Für diese technischen Grundlagen lohnen sich meine Tipps zum technischen SEO.

Häufige robots.txt Fehler und die richtige Lösung im Vergleich

Die Tabelle stellt alle Fehler aus diesem Beitrag nebeneinander. Öffnen Sie Ihre eigene Datei und gleichen Sie jede Zeile damit ab.

Nutzen Sie die Tabelle als Vorlage für Ihr Audit. Prüfen Sie für jede Zeile, ob Ihre Datei eine passende Regel enthält. Markieren Sie die zutreffenden Zeilen, dann kehren Sie zum passenden Abschnitt zurück und setzen die Lösung um. So prüfen Sie die ganze Datei in einer Sitzung.

Alle Zeilen haben eines gemeinsam: Der Fehler verursacht selten einen sichtbaren Ausfall. Die Website läuft, Seiten laden, und trotzdem bricht das Crawling still weg. Deshalb bringen regelmäßige Kontrollen mehr als eine einmalige Korrektur.

Mit welchen Tools finden Sie robots txt Fehler?

Der erste Halt ist die Search Console. Der Bericht zur robots.txt in den Einstellungen zeigt, wann Google Ihre Datei zuletzt abgerufen hat, welche Antwort kam und welche Warnungen beim Parsen auftraten. Die URL Prüfung verrät dann, ob die robots.txt eine einzelne Adresse sperrt.

Sind Sie neu in dem Tool, erklärt meine Anleitung zur Google Search Console die wichtigsten Berichte. Trotzdem liefert die Search Console nur die Zusammenfassung von Google. Was der Crawler wirklich abgerufen hat, sehen Sie erst in den Serverlogs.

• Serverlogs: Sie zeigen, welche Antwort der Googlebot für die robots.txt bekam und ob er gesperrte Bereiche weiter anfragt.
• Crawling Tools: Sie crawlen Ihre Website unter Beachtung der robots.txt und exportieren eine Liste gesperrter Adressen.
• Allgemeiner SEO Check: Der SEO Check liefert Ihnen eine schnelle Prüfung auf Seitenebene.

In den Logs achten Sie vor allem auf zwei Dinge. Erstens, ob der Googlebot die robots.txt regelmäßig abruft und welchen Statuscode er erhält. Zweitens, wie oft er die Bereiche besucht, die Sie sperren wollen. Einen Bereich zu sperren, den der Googlebot nie besucht, bringt Ihnen nichts; es macht die Datei nur unübersichtlich.

Meine Methode besteht darin, alle drei Quellen zusammen zu lesen. Meldet die Search Console zum Beispiel eine gesperrte Seite, prüfe ich in den Logs, wann der Googlebot diesen Pfad zuletzt abgerufen hat. Daraus lässt sich grob ablesen, wie lange der Fehler schon wirkt.

Was sollten Sie vor einem Livegang oder einer Migration prüfen?

Viele Fehler in der robots.txt entstehen am Tag, an dem eine neue Version live geht. Design, CMS und Server ändern sich; die Datei bleibt dagegen entweder alt oder kommt als Kopie der Testumgebung an. Arbeiten Sie deshalb am Tag des Livegangs eine kurze Checkliste ab.

1. Öffnen Sie die robots.txt der Liveseite und stellen Sie sicher, dass keine Zeile Disallow: / darin steht.
2. Prüfen Sie, dass die Datei den Statuscode 200 liefert und nicht hinter einer Weiterleitungskette liegt.
3. Kontrollieren Sie, ob die Sitemap Zeile auf die neue Sitemap zeigt.
4. Vergleichen Sie die Ordnernamen der neuen URL Struktur Buchstabe für Buchstabe mit den Zeilen der robots.txt.
5. Testen Sie wichtige Seitenvorlagen per URL Prüfung live und sehen Sie sich die gerenderte Ansicht an.
6. Beobachten Sie in der ersten Woche die Anfragen des Googlebots in den Serverlogs.

Die Liste kostet zehn Minuten, verhindert aber einen Sichtbarkeitsverlust, der Wochen dauern kann. Um SEO im gesamten Projekt zu schützen, kombinieren Sie sie mit den Schritten aus meinem Beitrag dazu, wie Sie SEO beim Website Relaunch schützen.

Wie bauen Sie einen Prozess auf, der robots txt Fehler verhindert?

Eine einmalige Korrektur reicht nicht, denn die robots.txt ist eine lebende Datei. Plugins ergänzen Zeilen, Teams wechseln, neue Subdomains entstehen. Die Datei braucht deshalb eine verantwortliche Person, und jede Änderung braucht einen Eintrag im Protokoll.

Der Prozess, den ich empfehle, hat drei Teile. Erstens verwalten Sie die Datei in einer Versionskontrolle und notieren zu jeder Änderung einen kurzen Grund. Zweitens prüfen Sie jeden Monat den Bericht zur robots.txt in der Search Console und die Zahl gesperrter Seiten. Schließlich arbeiten Sie bei jedem größeren Release die Checkliste oben ab.

Messen Sie außerdem das Ergebnis jeder Änderung. Nachdem Sie eine Regel ergänzt oder entfernt haben, beobachten Sie einige Wochen lang den Bericht zur Seitenindexierung und die Crawling Statistiken. Bewegt sich die Zahl gesperrter Adressen nicht wie erwartet, gehen Sie zurück zur Regel. Ob eine Korrektur wirkt, wissen Sie nur, wenn Sie sie messen.

In der SEO Beratung, die ich gemeinsam mit meinem Team umsetze, steht die robots.txt bei jedem technischen Audit weit oben. Denn ein Fehler in dieser Datei kann die Wirkung von Inhalten und Links vollständig zunichtemachen. Wir stellen zuerst sicher, dass das Crawling gesund ist, und gehen dann zu den anderen Aufgaben über.

Zusammengefasst machen robots txt Fehler selten Lärm, doch ihre Folgen halten lange an. Öffnen Sie Ihre Datei noch heute, vergleichen Sie sie mit der Tabelle oben und prüfen Sie, ob Sie jede Zeile in einem Satz erklären können. Eine Zeile, die Sie nicht erklären können, brauchen Sie wahrscheinlich nicht.