Search Console Robots Bericht: So lesen Sie ihn und beheben robots.txt Fehler

Wenn Sie wissen möchten, wie Google Ihre robots.txt tatsächlich sieht, ist der Search Console Robots Bericht (offiziell der robots.txt Bericht) die erste Anlaufstelle. In diesem Leitfaden gehen Talha Aslan und Team den Bericht Zeile für Zeile durch. Wir erklären, was jeder Status bedeutet und in welcher Reihenfolge Sie Fehler beheben. Falls Sie noch keine Datei haben, erstellen Sie zunächst mit unserem kostenlosen robots.txt Generator einen sauberen Entwurf.

Allerdings bearbeitet der Bericht nichts. Er zeigt nur, was Google erhalten hat. Deshalb ändern Sie immer die Datei auf Ihrem Server. Danach prüfen Sie im Bericht, ob die Änderung bei Google angekommen ist.

Falls robots.txt für Sie neu ist, erklären wir die Grundlagen in einem eigenen Beitrag: was robots.txt ist und wie Sie sie erstellen. Hier konzentrieren wir uns daher nur auf das Lesen des Berichts.

Der eigentliche Nutzen liegt in der Frühwarnung. Zum Beispiel kann ein Theme Update, ein Sicherheitsplugin oder ein Serverwechsel die Antwort der robots.txt unbemerkt stören. Wenn Sie das sehen, bevor der Traffic sinkt, dauert die Korrektur meist nur Minuten.

Was ist mit dem alten robots.txt Tester passiert?

Die ältere Search Console hatte einen eigenen Tester. Dort konnten Sie Regeln einfügen und prüfen, ob Google eine URL blockiert. Heute nennt die offizielle Google Anleitung zum Erstellen einer robots.txt zwei Wege, um Syntaxprobleme zu beheben: den robots.txt Bericht in der Search Console und die Open Source Bibliothek von Google.

Trotzdem sollten Sie ein Detail nicht übersehen. Der Bericht funktioniert nur für Dateien, die auf Ihrer Website bereits erreichbar sind. Wenn Sie also einen Entwurf vor dem Livegang testen möchten, brauchen Sie stattdessen lokale Tests oder eine sorgfältige Vorbereitung.

Zum Beispiel kann ein Entwickler die Bibliothek lokal kompilieren und Regeln auf dem eigenen Rechner prüfen. Ohne Entwickler ist es dagegen am sichersten, die Regeln einfach zu halten.

Unser Rat: Ändern Sie immer nur einen kleinen Satz an Regeln. Nach der Veröffentlichung öffnen Sie den Bericht und prüfen das Ergebnis. Somit wissen Sie sofort, welche Zeile ein Problem verursacht. Außerdem lohnt sich eine Kopie der vorherigen Version, damit Sie in Minuten zurückkehren können.

Wo finden Sie den Bericht in der Search Console?

In der Praxis liegt der Bericht im Bereich Einstellungen der Search Console. Menünamen können sich ändern, deshalb raten wir davon ab, sich auf exakte Schaltflächentexte zu verlassen. Wenn Sie die Einstellungen öffnen, sehen Sie im Abschnitt zum Crawling einen Eintrag für robots.txt.

1. Melden Sie sich in der Search Console an und wählen Sie die richtige Property.
2. Öffnen Sie im linken Menü die Einstellungen.
3. Klicken Sie im Abschnitt zum Crawling auf den Eintrag für robots.txt.
4. Prüfen Sie die Tabelle, die für jeden Host eine eigene Zeile zeigt.

Auch der Typ der Property spielt eine Rolle. Eine Domain Property kann mehrere Hosts im selben Bericht zeigen, etwa die Version mit www, die Version ohne www und Subdomains. Eine Property mit URL Präfix deckt dagegen nur dieses Präfix ab. Wenn Sie die Search Console zum ersten Mal einrichten, hilft Ihnen unsere Search Console Anleitung für Einsteiger.

Welche Spalten zeigt der Bericht und was bedeuten sie?

Die Tabelle ist schlicht. Allerdings beantwortet jede Spalte eine andere Frage. Halten Sie die folgende Übersicht neben dem Bericht bereit.

Danach klicken Sie auf eine Zeile und sehen den Inhalt, den Google zuletzt abgerufen hat. Außerdem listet der Bericht Versionen aus der jüngeren Vergangenheit. So verfolgen Sie, an welchem Tag eine Änderung bei Google ankam.

Was bedeuten die Abrufstatus im Bericht?

Im Bericht begegnen Ihnen drei wesentliche Ergebnisse. Zudem kann der genaue Wortlaut je nach Sprache der Oberfläche leicht abweichen. Daher erklären wir die Bedeutung und nicht den exakten Text.

• Erfolgreicher Abruf: Google hat die Datei erhalten. Prüfen Sie die Spalte Probleme separat.
• Nicht gefunden (404): Der Server meldet, dass keine Datei existiert. Google nimmt dann an, dass keine Crawlingbeschränkungen gelten.
• Abruf aus anderem Grund gescheitert: Ein Serverfehler, eine Zeitüberschreitung oder ein Netzwerkproblem stand im Weg. Das ist der kritischste Fall.

Zum Beispiel ist ein Status 404 oft kein Grund zur Panik. Wenn Ihre Website allerdings bestimmte Bereiche sperren soll, bedeutet 404, dass keine dieser Regeln greift. Folglich bleiben Ordner offen, die Sie eigentlich ausschließen wollten.

Außerdem entsteht ein 404 manchmal durch den falschen Speicherort. Liegt die Datei in einem Unterordner, sucht Google dort nicht. Google liest nur die Datei im Stammverzeichnis, direkt nach dem Domainnamen.

Wie crawlt Google Ihre Website bei Status 404?

Laut der robots.txt Spezifikation von Google behandelt Google Antworten mit 4xx so, als gäbe es keine robots.txt Datei. Das heißt, Google geht von keinen Crawlingbeschränkungen aus. Den Code 429 nimmt das Dokument von dieser Regel aus.

Zudem sagt dasselbe Dokument, dass Sie 401 oder 403 nicht zur Begrenzung der Crawlrate einsetzen sollen. Wenn also Ihr Sicherheitsplugin dem Googlebot eine 403 liefert, ist das keine Methode zur Beschränkung. Google liest diese Antwort wie eine fehlende Datei.

In der Praxis öffnen Sie die Datei URL in einem privaten Browserfenster. Erscheint der Inhalt, liegt das Problem wahrscheinlich im Cache oder in einer Weiterleitung. Lädt nichts, laden Sie die Datei erneut ins Stammverzeichnis hoch.

Was macht Google bei einem Serverfehler (5xx)?

Dieser Abschnitt ist der wichtigste Teil, denn ein Status 5xx beeinflusst das Crawling direkt. Die offizielle Dokumentation von Google beschreibt einen gestuften Ablauf.

1. In den ersten 12 Stunden stoppt Google das Crawling der Website, fragt die Datei aber weiter an.
2. Danach nutzt Google bis zu 30 Tage lang die letzte erfolgreiche Version aus dem Cache, falls vorhanden. Ohne Cache geht Google von keinen Beschränkungen aus.
3. Nach 30 Tagen verhält sich Google wie ohne Datei, wenn die Website grundsätzlich erreichbar ist. Ist sie nicht erreichbar, stoppt Google das Crawling und fragt die Datei regelmäßig an.

Kurz gesagt kann ein dauerhafter Serverfehler an der robots.txt das Crawling bremsen, obwohl Ihre Seiten gesund sind. Sehen Sie dazu einen deutlichen Einbruch im Crawlingdiagramm, helfen die Schritte im Beitrag warum der Googlebot weniger crawlt.

Wie zeigt der Bericht eine robots.txt mit Weiterleitung?

Laut Dokumentation folgt der Googlebot bei robots.txt mindestens fünf Weiterleitungen. Erreicht er die Datei danach nicht, wertet Google das Ergebnis wie einen Status 404. Außerdem folgt Google keinen logischen Weiterleitungen wie JavaScript oder Meta Refresh.

Eine einzelne Weiterleitung von HTTP auf HTTPS oder von der Version mit www auf die Version ohne www stört also nicht. Andererseits summieren sich verkettete Weiterleitungen aus Plugins, CDN und Server schnell.

Sehen Sie im Bericht einen unerwarteten Status 404, öffnen Sie die Datei URL mit einer Headerprüfung und zählen die Sprünge. Ist die Kette lang, leiten Sie direkt auf die finale Adresse weiter. Somit profitieren robots.txt und die gesamte Crawlingeffizienz.

Wie lesen Sie die Warnungen in der Spalte Probleme?

Hat Google die Datei abgerufen, zeigt die Spalte Probleme aber eine Zahl, dann hat Google einige Zeilen nicht verstanden. Laut offizieller Dokumentation ignoriert Google ungültige Zeilen. Eine Byte Order Mark (BOM) am Dateianfang gehört ebenfalls dazu.

Diese Ursachen sehen wir am häufigsten:

• Falsch geschriebene Anweisungen, etwa eine Zeile Disallow ohne Doppelpunkt.
• Regelgruppen, die ohne Zeile User-agent beginnen.
• Unsichtbare Zeichen aus einem Textverarbeitungsprogramm.
• Eine Datei mit einer anderen Kodierung als UTF-8.

Warnungen machen nicht die ganze Datei ungültig. Trotzdem kann eine erwartete Sperre wirkungslos sein. Deshalb öffnen Sie jede Warnung und korrigieren die passende Zeile. Häufige Syntaxfehler finden Sie ausführlich in unserem Beitrag zu häufigen robots.txt Fehlern.

Warum ist die Größengrenze im Bericht wichtig?

Die Dokumentation von Google nennt für robots.txt eine Grenze von 500 KiB und sagt, dass Google Inhalte darüber ignoriert. Genau deshalb ist die Spalte Größe nützlich.

Zudem haben die meisten Unternehmenswebsites eine Datei mit wenigen Zeilen, weit unter der Grenze. Bei großen Shops im E-Commerce kann die Datei allerdings unkontrolliert wachsen, wenn jemand für jede Filterkombination eine Zeile ergänzt. Überschreitet die Datei die Grenze, verlieren die Regeln am Ende still ihre Wirkung.

Die Lösung ist meist, Regeln zusammenzufassen. Zum Beispiel schreiben Sie ein Muster mit Platzhalter statt Dutzender ähnlicher Zeilen. So bleibt die Datei kurz und gut lesbar. Strategien für gefilterte URLs behandeln wir im Beitrag zur Facettennavigation.

Wie greifen die Regeln der Datei auf URLs?

Wenn Sie den Dateiinhalt im Bericht öffnen, müssen Sie selbst ermitteln, welche Zeile welche URL betrifft. Die Dokumentation von Google definiert dafür einige einfache Grundsätze.

• Das Sternchen (*) steht für null oder mehr beliebige Zeichen.
• Das Dollarzeichen ($) markiert das Ende der URL.
• Ein Sternchen am Ende ignoriert Google.
• Der Pfadvergleich unterscheidet Groß und Kleinschreibung.

Beispielszenario: Ihre Datei enthält Disallow: /suche und Allow: /suche/ratgeber. Für die URL /suche/ratgeber ist die längere Übereinstimmung die Zeile Allow. Daher darf Google diese URL crawlen. Andererseits beginnt /Suche mit einem Großbuchstaben und passt deshalb zu keiner Regel.

Kurz gesagt erklären diese Details, warum Google manche Seiten nicht crawlt, obwohl der Bericht gut aussieht. Halten Sie die Regeln einfach, dann bleibt auch die Zuordnung vorhersehbar.

Wie hängen Cache und Prüfdatum zusammen?

Das Prüfdatum sorgt für die meiste Verwirrung. Laut Dokumentation speichert Google den Inhalt der robots.txt im Allgemeinen bis zu 24 Stunden im Cache. Bei Zeitüberschreitungen oder Serverfehlern kann dieser Zeitraum länger sein. Außerdem beeinflusst der Cache Control Header Ihres Servers die Lebensdauer des Cache.

Das Prüfdatum zeigt also das Alter der Version, die Google kennt. Haben Sie die Datei heute Morgen korrigiert und das Datum zeigt gestern, crawlt Google noch mit den alten Regeln.

In der Praxis gehen Sie so vor: Zunächst korrigieren Sie die Datei, dann prüfen Sie den neuen Inhalt im Browser, und schließlich warten Sie auf ein neues Datum. Im Notfall kann eine Anfrage zum erneuten Crawlen die Wartezeit verkürzen.

Nutzen Sie ein CDN, denken Sie daran, dass auch das CDN eine alte Kopie speichern kann. Dann leeren Sie zusätzlich den Cache des CDN. Sonst erhält Google weiterhin die alte Version.

Wann senden Sie eine Anfrage zum erneuten Crawlen?

Weil Google die robots.txt meist bis zu 24 Stunden im Cache hält, kann eine Korrektur einen Tag brauchen. Die Google Anleitung zum Aktualisieren der robots.txt empfiehlt die Funktion zum erneuten Crawlen im Bericht, wenn Sie den Cache schneller erneuern müssen.

Allerdings brauchen Sie sie nicht bei jeder kleinen Änderung. Wir nutzen sie in diesen Fällen:

• Sie haben eine Regel korrigiert, die versehentlich die ganze Website gesperrt hat.
• Sie haben einen wichtigen Bereich für das Crawling geöffnet.
• Ein längerer Serverfehler ist gerade behoben.

Sehen Sie die Funktion nicht als Zauberknopf. Google prüft die Anfrage und folgt dem eigenen Crawlingplan. Bei routinemäßigen Änderungen genügt es, auf die Erneuerung des Cache zu warten.

Prüfen Sie vor der Anfrage, ob die neue Datei wirklich live ist. Sonst ruft Google den alten Inhalt erneut ab, und Sie halten die Korrektur für gescheitert. Die Reihenfolge lautet daher immer: zuerst Datei, dann Browser, zuletzt Anfrage.

Wie prüfen Sie, ob eine einzelne URL gesperrt ist?

Der Search Console Robots Bericht zeigt die Datei selbst. Ob eine bestimmte Seite gesperrt ist, sehen Sie dagegen im Tool zur URL Prüfung. Beide Werkzeuge ergänzen sich also.

1. Geben Sie die vollständige URL oben in das Suchfeld der Search Console ein.
2. Öffnen Sie im Ergebnis die Details zum Crawling.
3. Lesen Sie die Zeile, die angibt, ob Google crawlen darf.
4. Sehen Sie eine Sperre, öffnen Sie im robots.txt Bericht die Datei des passenden Hosts und suchen die Regel.

Denken Sie dabei an die Vorrangregel von Google: Der längste passende Pfad gewinnt. Stehen eine Regel Allow und eine Regel Disallow gleicher Länge im Konflikt, wendet Google die weniger einschränkende an.

Warum erscheint eine gesperrte Seite trotzdem bei Google?

Diese Frage überrascht viele Leser des Berichts. Die Einführung von Google zu robots.txt sagt klar: robots.txt ist kein Mittel, um eine Seite aus Google herauszuhalten. Eine gesperrte Seite mit Links von anderen Websites kann trotzdem im Index landen.

Folglich kann eine solche Seite ohne Beschreibung in den Ergebnissen stehen. Wenn Sie eine Seite aus der Suche entfernen möchten, nutzen Sie daher noindex oder einen Passwortschutz.

Allerdings gibt es eine Falle. Google muss die Seite crawlen, um ein noindex zu sehen. Sperren Sie eine Seite und setzen gleichzeitig noindex, kann Google das Tag nie lesen. Beide Methoden vergleichen wir im Beitrag noindex, nofollow und robots.txt im Vergleich.

Wie erscheinen Subdomains und Protokolle im Bericht?

Laut Dokumentation gelten die Regeln nur für den Host, das Protokoll und den Port, auf dem die Datei liegt. Eine Datei für blog.example.com wirkt also nicht auf example.com. Ebenso behandelt Google die Versionen mit HTTP und HTTPS getrennt.

Deshalb lesen Sie jede Zeile im Bericht als eigene Datei. Zum Beispiel kann die Zeile der Hauptseite sauber aussehen, während eine alte Testumgebung auf einer Subdomain einen Status 404 oder einen Serverfehler zeigt.

Ist eine solche Subdomain öffentlich erreichbar, schützen Sie sie am besten mit Passwort oder Zugriffsbeschränkung. robots.txt allein genügt nicht, denn gesperrte URLs können wie gesehen trotzdem im Index landen.

Wie nutzen Sie den Search Console Robots Bericht zusammen mit Serverlogs?

Der Search Console Robots Bericht fasst den letzten Abruf von Google zusammen. Serverlogs zeigen dagegen jede einzelne Anfrage. Wer beide Quellen liest, erkennt zeitweise Fehler am zuverlässigsten.

Zum Beispiel kann ein einzelner Serverfehler im Bericht ein einmaliger Aussetzer sein. Zeigen die Logs aber häufig 5xx oder Zeitüberschreitungen bei den Anfragen des Googlebot an die robots.txt, ist das Problem dauerhaft.

1. Holen Sie die Zugriffslogs aus Ihrem Hostingpanel oder von Ihrem Technikteam.
2. Filtern Sie die Anfragen an die robots.txt Adresse.
3. Vergleichen Sie Statuscodes und Antwortzeiten.
4. Gleichen Sie die Fehlerzeiten mit Lastspitzen oder Wartungsfenstern ab.

Außerdem erkennen Sie so, ob Ihre Firewall den Googlebot versehentlich blockiert. Konkrete Uhrzeiten aus den Logs beschleunigen das Gespräch mit Ihrem Hoster. Bedenken Sie zudem, dass Fremde den Namen eines User Agent fälschen können; bei verdächtigem Traffic nutzen Sie daher die offizielle Verifizierungsmethode von Google.

Woher kommt die robots.txt bei fertigen Plattformen?

Allerdings kann der Inhalt im Bericht von der hochgeladenen Datei abweichen. Manche Content Management Systeme erzeugen die robots.txt selbst, wenn im Stammverzeichnis keine physische Datei liegt. WordPress liefert in diesem Fall zum Beispiel eine virtuelle Datei, und SEO Plugins können deren Inhalt verändern.

Überrascht Sie also der Inhalt im Bericht, suchen Sie zuerst die Quelle. Gibt es eine physische Datei im Stammverzeichnis, oder erzeugt das System sie? Kollidiert eine Pluginoption mit einer physischen Datei?

Ebenso liefern Shopsysteme und Baukästen oft eine Standarddatei und schränken die Bearbeitung ein. Dort bearbeiten Sie nur, was die Plattform erlaubt. Deshalb prüfen Sie nach jeder Änderung im Bericht, welchen Inhalt Google wirklich erhält.

Sobald die Quelle klar ist, verwalten Sie die Datei an genau einer Stelle. Zwei Quellen bedeuten bei jedem Update eine neue Überraschung.

Worauf achten Sie im Bericht nach einem Umzug der Website?

Vor allem Domainwechsel, Umstellungen auf HTTPS und Plattformumzüge sind die Momente, in denen Fehler in der robots.txt am häufigsten auftreten. Am Tag des Umzugs öffnen Sie den Bericht und suchen Antworten auf diese Fragen.

• Ruft Google die Datei des neuen Hosts ab, oder liefert sie 404 oder einen Serverfehler?
• Ist die Sperrregel der Testumgebung auf der Liveseite gelandet?
• Zeigt die Zeile Sitemap auf die neue Domain?
• Erreicht Google die Datei der alten Domain, ohne dass Weiterleitungen brechen?

Beispielszenario: Nach einem Umzug bleibt eine einzige Zeile Disallow: / live, und Google kann die neuen Seiten nicht crawlen. Ein Team, das den Bericht am ersten Tag prüft, behebt das innerhalb von Stunden. Für die Diagnose eines Einbruchs nach dem Umzug hilft zudem unser Beitrag zur Analyse eines Traffic Einbruchs in der Search Console.

Wie beheben Sie einen Fehler aus dem Bericht Schritt für Schritt?

Nach der Diagnose ist die Reihenfolge auf den meisten Websites gleich. Unser Team nutzt diesen Ablauf bei technischen Audits.

1. Notieren Sie im Bericht den betroffenen Host und den Abrufstatus.
2. Öffnen Sie die Datei URL in einem privaten Fenster und prüfen Sie die Serverantwort.
3. Erstellen Sie die Datei bei Bedarf mit dem robots.txt Generator neu und tragen Sie nur Pfade ein, die Sie wirklich sperren möchten.
4. Laden Sie die Datei als Klartext in UTF-8 ins Stammverzeichnis.
5. Prüfen Sie, ob der neue Inhalt im Browser erscheint.
6. Senden Sie bei dringenden Korrekturen eine Anfrage zum erneuten Crawlen.
7. Kontrollieren Sie einige wichtige URLs im Tool zur URL Prüfung.

Fügen Sie eine Zeile Sitemap hinzu, stellen Sie sicher, dass Google auch die Sitemap lesen kann. Bei einem Sitemapfehler hilft Ihnen unser Beitrag zum Fehler Sitemap konnte nicht abgerufen werden weiter.

Wie bestätigen Sie die Wirkung einer Änderung an der robots.txt?

Die Datei zu korrigieren ist nur die halbe Arbeit. Die andere Hälfte besteht darin, die Wirkung tatsächlich zu sehen. Der Bericht zeigt nur den Zustand der Datei, daher betrachten Sie mehrere Ansichten zusammen.

1. Prüfen Sie, ob das Prüfdatum nach Ihrer Änderung liegt.
2. Öffnen Sie den Inhalt und bestätigen Sie, dass die neuen Regeln in der Kopie von Google stehen.
3. Prüfen Sie einige wichtige, zuvor gesperrte URLs erneut im Tool zur URL Prüfung.
4. Beobachten Sie in den folgenden Tagen die Zahl der Anfragen in den Crawlingstatistiken.

Beispielszenario: Sie haben eine Regel entfernt, die Kategorieseiten versehentlich gesperrt hat. Nach dem neuen Prüfdatum zeigt die URL Prüfung, dass Google diese Seiten crawlen darf. Ihr Status im Indexierungsbericht ändert sich dann mit der Zeit. Allerdings hängt das von der Crawlingreihenfolge bei Google ab, und es gibt keine feste Frist.

Geduld zahlt sich in dieser Phase aus. Bei großen Websites kann das erneute Crawlen aller geöffneten Bereiche Tage oder Wochen dauern, und das ist kein Fehlerzeichen. Zudem empfehlen wir, jede Änderung mit Datum zu notieren. Dann wissen Sie Wochen später genau, welche Regel sich wann geändert hat.

Welche Fehler sollten Sie beim Lesen des Berichts vermeiden?

Der Bericht wirkt einfach, dennoch kommt es oft zu Fehldeutungen. Diese Irrtümer sehen wir in der Praxis am häufigsten.

Erstens die Annahme, ein erfolgreicher Abruf bedeute, dass alles in Ordnung ist. Google hat die Datei vielleicht erhalten, aber eine einzige Zeile Disallow darin sperrt womöglich einen wichtigen Ordner. Deshalb lesen Sie den Inhalt immer zusammen mit dem Status.

Zweitens die Erwartung, dass sich der Bericht Minuten nach einer Änderung aktualisiert. Wegen des Cache zeigt der Bericht den neuen Inhalt erst mit neuem Prüfdatum.

Drittens die Annahme, der Bericht zeige nur einen Host. Bei einer Domain Property öffnen Sie mehrere Zeilen nacheinander. Schließlich liegt nicht jedes Indexierungsproblem an der robots.txt. Andere Ursachen finden Sie in unserer Anleitung, um nicht indexierte Seiten zu finden.

Wie oft sollten Sie den Search Console Robots Bericht prüfen?

Der Search Console Robots Bericht braucht keine tägliche Kontrolle. Wir empfehlen, ihn nach jedem Release, Themewechsel, CDN Wechsel oder Update eines Sicherheitsplugins einmal zu öffnen.

Außerdem können Sie ihn in Ihre monatliche technische Checkliste aufnehmen. So wirkt ein unbemerkter Serverfehler oder eine versehentlich live gestellte Testdatei nicht lange nach.

Beispielszenario: Nach einem Umzug landet die Sperrdatei der Testumgebung auf der Liveseite. Ein Team, das den Bericht am Umzugstag öffnet, sieht das binnen Stunden. Ein Team ohne diese Routine bemerkt den Crawlingeinbruch erst Wochen später.

Wann holen Sie sich Unterstützung bei robots.txt und Crawling?

Für eine einfache Datei brauchen Sie selten einen Experten. Das Problem geht allerdings über robots.txt hinaus, wenn der Bericht dauerhaft Serverfehler zeigt, wenn Filter URLs in einem großen Shop das Crawling aufbrauchen oder wenn der Traffic nach einem Umzug sinkt.

In solchen Fällen betrachten Sie Crawling, Indexierung und Seitenarchitektur gemeinsam. Im Rahmen unserer SEO Beratung prüfen wir alle drei in einem technischen Audit. Wir versprechen keine Ergebnisse, wollen aber mit Belegen zeigen, wo das Problem liegt.

Bereiten Sie vor dem Kontakt einen Screenshot des Berichts, den aktuellen Dateiinhalt und das Startdatum des Problems vor. Diese drei Angaben beschleunigen die erste Diagnose deutlich. Zudem verrät eine Liste der jüngsten technischen Änderungen oft schon die Ursache.

Wenn Sie lieber selbst vorgehen, halten Sie neben der robots.txt auch Ihre Sitemap mit unserem XML Sitemap Generator aktuell. Zusammen helfen beide Google, Ihre Website richtig zu verstehen.

Grundlagen: Was ist Online Marketing? Arten, Beispiele und Vorgehen auf einer Seite, mit einem interaktiven Film durch das Gehirn.