URL wegen eines anderen 4xx Problems blockiert: Ursachen und Lösung

Was bedeutet „URL wegen eines anderen 4xx Problems blockiert“ in der Search Console?

„URL wegen eines anderen 4xx Problems blockiert“ (englisch: Blocked due to other 4xx issue) ist ein Status im Bericht zur Seitenindexierung der Search Console. Google hat die URL angefragt, und Ihr Server hat einen 4xx Clientfehler geliefert, der kein eigenes Label wie 401, 403 oder 404 hat. Google indexiert eine URL in diesem Zustand nicht.

Zunächst beschreibt die offizielle Hilfe den Status als Sammelkategorie. Laut Hilfeseite zum Bericht zur Seitenindexierung ist auf dem Server ein 4xx Fehler aufgetreten, der keinem anderen dort beschriebenen Problemtyp entspricht. Das Label ist also keine Diagnose, sondern ein Hinweis: Es gab irgendeine 4xx Antwort, und der Bericht kann sie nicht beim Namen nennen.

Die Folge ist daher eindeutig. Die Dokumentation von Google Search Central zu HTTP Statuscodes sagt, dass Google URLs mit einem 4xx Statuscode nicht indexiert. Außerdem entfernt Google bereits indexierte URLs aus dem Index, sobald sie einen 4xx liefern. Die entscheidende Frage lautet daher: Soll diese URL existieren und indexierbar sein, oder nicht?

Kurz gesagt: Dieser Leitfaden behandelt nur dieses eine Label. Das Gesamtbild finden Sie in unserer Anleitung, wie Sie nicht indexierte Seiten in der Search Console finden. Die Nachbarlabels haben wir in eigenen Beiträgen erklärt: 401 Fehler, 403 und WAF Regeln und Soft 404. Deshalb wiederholen wir sie hier nicht.

Welche 4xx Antworten landen unter diesem Label?

Zunächst führt die Search Console einige Clientfehler unter eigenen Namen auf. Dann landet alles, was übrig bleibt, in der Sammelkategorie. Das heißt: 4xx Antworten außer 401, 403 und 404 bekommen dieses Label. Auch Soft 404 Seiten haben übrigens ein eigenes Label.

Die Hilfeseite veröffentlicht für diese Sammelkategorie keine Liste mit einzelnen Codes. In der offiziellen Dokumentation haben wir keine eindeutige Aussage gefunden. Deshalb behaupten wir nicht, dass ein bestimmter Code wie 400 oder 405 immer hier erscheint. Stattdessen zeigen wir Ihnen, wie Sie den echten Code Ihrer eigenen URL herausfinden.

Ist „wegen eines anderen 4xx Problems blockiert“ ein echtes Problem oder können Sie es ignorieren?

Konkret hängt das von der URL ab. Sollte die Adresse ohnehin verschwinden, ist der Status korrekt, und Sie müssen nichts tun. Ist die Adresse eine Seite, die in den Suchergebnissen erscheinen soll, liegt ein echtes Problem vor, und Sie müssen es beheben.

Sortieren Sie zunächst die Beispiel URLs in zwei Gruppen. Die erste Gruppe enthält Adressen, die nicht existieren sollen: alte Testseiten, defekte Links und Datenmüll von Bots. Zudem enthält die zweite Gruppe Seiten, die Sie aktiv ranken lassen wollen.

• Gruppe eins: Bestätigen Sie, dass die Antwort Absicht ist, und bereinigen Sie danach interne Links und Sitemap Einträge, die noch auf diese Adressen zeigen.
• Gruppe zwei: Finden Sie den echten Statuscode, beheben Sie die Ursache und starten Sie die Prüfung.
• Gemischte Signale: Taucht eine normale Seite hier auf, vermuten Sie eine Serverregel, eine Firewall oder ein Plugin statt Google.

Der Bericht hat außerdem eine Spalte Quelle. Konkret zeigt sie, ob die Ursache auf Ihrer Website oder in den Systemen von Google liegt. Bei diesem Status liegt die Ursache fast immer bei Ihnen, denn das Label beschreibt, was Ihr Server geliefert hat.

Wie behandelt Google 4xx Antworten ganz allgemein?

In der Praxis behandelt Google fast alle 4xx Codes gleich. Die Dokumentation zu HTTP Statuscodes sagt, dass jeder 4xx Fehler außer 429 dem nächsten Verarbeitungssystem meldet, dass der Inhalt nicht existiert. Anders gesagt: Die genaue Nummer ändert am Ergebnis der Indexierung kaum etwas.

Trotzdem ist das Label im Bericht wichtig. Es verrät Ihnen nämlich, nach welcher Art von Antwort Sie suchen sollten. Ein 403 deutet zum Beispiel auf Zugriffsregeln, ein 404 auf eine fehlende Seite, und die Sammelkategorie auf etwas Selteneres.

Allerdings ist der Code 429 die Ausnahme. Google wertet ihn als Signal, dass der Server überlastet ist, und behandelt ihn wie einen Serverfehler. Folglich gehört ein 429 normalerweise in einen anderen Teil des Berichts und nicht zu diesem Label.

Außerdem hilft diese Unterscheidung bei der Priorisierung. Sehen Sie in den Beispielen nur seltsame Adressen, ist die Ursache vermutlich harmlos. Sehen Sie dagegen Ihre besten Landingpages, haben Sie ein Zugriffs- oder Konfigurationsproblem, das Crawling und Indexierung blockiert.

Was löst „wegen eines anderen 4xx Problems blockiert“ typischerweise aus?

Zunächst lassen sich die Ursachen in wenige Gruppen einteilen. Manche sind harmlos; allerdings kosten andere Traffic. Die Tabelle zeigt, was wir zuerst prüfen, und die folgenden Abschnitte erklären jede Gruppe.

Beachten Sie, dass die mittlere Spalte übliches Verhalten beschreibt und kein Versprechen ist. Denn Ihr technischer Aufbau entscheidet, was zurückkommt. Bestätigen Sie daher immer den tatsächlichen Code, bevor Sie etwas ändern.

Können fehlerhafte oder parameterlastige URLs diesen Status auslösen?

Ja, das können sie. Server antworten mit einem Clientfehler, weil die Anfrage ungültig aussieht. Zum Beispiel sind kaputte Kodierungen, überzählige Zeichen am Ende eines Links oder ungewöhnliche Parameter typische Auslöser. Folglich kann Googlebot einen 4xx für eine Adresse erhalten, die nie ein Mensch besucht.

Woher stammen diese Adressen? Meist aus einer von vier Quellen:

• Interne Links mit Tippfehlern oder kopierten Tracking Fragmenten.
• Alte Sitemap Einträge, die nie bereinigt wurden.
• Backlinks anderer Seiten, die Ihre Adresse abschneiden oder verlängern.
• Filter oder Suchseiten, die endlose Parameterkombinationen erzeugen.

Allerdings braucht jede Quelle ein anderes Mittel. Interne Links korrigieren Sie zunächst selbst. Bei externen Links genügt dann oft eine Weiterleitung auf die saubere Adresse. Bei endlosen Parameterkombinationen erklärt unser Beitrag zu Facettennavigation, Canonical und robots.txt, wie Sie Crawler fokussiert halten.

Sehen die Beispiele nach zufälligem Müll aus, lesen Sie unseren Beitrag zu unbekannten Spam URLs mit 404. Die Logik ist dieselbe: Jagen Sie nicht jeder Müll URL hinterher, aber stellen Sie sicher, dass keine davon in Ihrer Sitemap oder in internen Links steht.

Kann eine Firewall oder Serverregel nur für Googlebot einen 4xx liefern?

Ja. Sicherheitsplugins, Web Application Firewalls und CDN Regeln behandeln Crawler manchmal anders als Besucher. Folglich lädt die Seite in Ihrem Browser problemlos, während Googlebot einen Fehler erhält. Das ist daher einer der häufigsten Gründe, warum wichtige Seiten unter diesem Label auftauchen.

Konkret gehören zu den typischen Regeltypen Ratenlimits, Filter nach User Agent, Länderfilter und Prüfseiten. Eine Regel, die unbekannte Bots blockiert, kann zum Beispiel auch Googlebot erwischen, wenn ihre Liste veraltet ist. Ebenso kann Ihr Hostinganbieter ein Schutzregelwerk aktivieren, ohne es Ihnen zu sagen.

1. Fragen Sie zunächst Ihren Hostinganbieter oder den Hersteller des Sicherheitsplugins, welche Regeln für die betroffenen URLs ausgelöst haben.
2. Suchen Sie danach in den Serverlogs nach Anfragen von Googlebot und notieren Sie den Statuscode jeder Anfrage.
3. Vergleichen Sie dann diese Zeilen mit Anfragen normaler Besucher auf dieselben URLs.
4. Passen Sie schließlich die Regel so an, dass echte Googlebot Anfragen durchkommen.

Allerdings sollten Sie beim Prüfschritt sorgfältig sein. Jeder kann einen Googlebot User Agent fälschen, also geben Sie nicht allein nach dem Namen frei. Google dokumentiert, wie Sie seine Crawler verifizieren; nutzen Sie diese Methode, bevor Sie eine Regel lockern. Die Mechanik solcher Regeln erklärt unser Beitrag zu ModSecurity und WAF.

Spielt die HTTP Methode bei einem 4xx im Bericht eine Rolle?

Sie kann eine Rolle spielen. Crawler rufen Seiten normalerweise mit einer einfachen Leseanfrage ab. Manche Endpunkte, etwa Formularverarbeitung oder Schnittstellen einer Anwendung, akzeptieren dagegen nur andere Anfragetypen. Ein solcher Endpunkt kann auf einen normalen Seitenaufruf mit einem Clientfehler antworten, und diese Antwort kann hier erscheinen.

In der Praxis passiert das häufiger, als man denkt. Ein Link auf eine Formularaktion, einen Warenkorb Helfer oder eine Rückruf Adresse landet manchmal in einem Template. Dann folgt Googlebot dem Link, erhält eine Ablehnung und meldet den Status.

• Finden Sie zunächst das Template oder Menü, das den Link erzeugt.
• Ersetzen Sie den Link danach durch eine echte Seitenadresse oder entfernen Sie ihn.
• Muss der Endpunkt dennoch bleiben, halten Sie ihn aus Navigation und Sitemap heraus.

Eine offizielle Google Aussage, die einen bestimmten Methodenfehler diesem Label zuordnet, können wir nicht nennen. Sehen Sie diesen Abschnitt daher als praktischen Hinweis, und bestätigen Sie ihn immer mit dem unten beschriebenen Live Test.

Erscheint eine absichtliche 410 Antwort unter diesem Label?

In der offiziellen Dokumentation haben wir keinen eindeutigen Satz gefunden, der 410 dieser Sammelkategorie oder der 404 Kategorie zuordnet. Deshalb legen wir uns in keine Richtung fest. Wir können nur sagen, wie Google 4xx Codes allgemein behandelt: Laut Dokumentation sind alle außer 429 gleich zu behandeln, als Signal, dass der Inhalt nicht existiert.

Der praktische Rat hängt also nicht vom Label ab. Haben Sie den Inhalt absichtlich entfernt und gibt es keinen Ersatz, ist eine Antwort „gone“ oder „nicht gefunden“ legitim. Dann lassen Sie sie stehen, aber entfernen Sie alle Links darauf.

Gibt es einen Ersatz, leiten Sie die alte Adresse auf die passendste neue Seite weiter. Unser Beitrag zu ausverkauften Produktseiten und 404, 410 und 301 führt Shops durch diese Entscheidung; dieselbe Logik gilt für jeden Seitentyp.

Merken Sie sich außerdem: Eine entfernte Seite gehört nicht in Ihre Sitemap. Sonst sendet eine Sitemap mit Fehler URLs widersprüchliche Signale und macht den Bericht unübersichtlich.

Wie finden Sie den echten Statuscode hinter diesem Label?

Nutzen Sie zunächst das Prüftool für URLs (URL Inspection Tool). Öffnen Sie den Bericht, klicken Sie beim Beispiel auf das Prüfsymbol und lesen Sie die Details zu Crawling und Indexierung. Die Hilfeseite zur URL Prüfung erklärt, dass das Tool die indexierte Version anzeigt und einen Live Test erlaubt.

1. Öffnen Sie zunächst den Bericht zur Seitenindexierung und wählen Sie „Blocked due to other 4xx issue“.
2. Wählen Sie danach eine Beispiel URL aus der Liste und öffnen Sie ihre Prüfdetails.
3. Sehen Sie sich außerdem den Status des Seitenabrufs und das Datum des letzten Crawls an.
4. Starten Sie dann den Live Test, um zu sehen, wie sich die URL jetzt verhält.
5. Öffnen Sie zuletzt die Ansicht der gecrawlten Seite und den Bereich mit weiteren Infos, um die HTTP Header zu lesen.

Allerdings gibt es eine Grenze. Die Hilfeseite dokumentiert die Header Ansicht, beschreibt aber nicht genau, wie der Hauptbericht den numerischen Code zeigt. Deshalb empfehlen wir, den Code mit einer zweiten Methode zu bestätigen; der nächste Abschnitt zeigt das.

Außerdem können sich Menünamen mit der Zeit ändern. Sieht Ihre Oberfläche anders aus, suchen Sie nach den entsprechenden Optionen für Prüfung und Live Test statt nach einem bestimmten Schaltflächentext.

Wie testen Sie die URL außerhalb der Search Console?

Eine zweite Meinung ist günstig und schnell. Weil der Bericht der Realität hinterherhinken kann, zeigt eine frische Prüfung, was Ihr Server heute tut. Verwenden Sie daher mindestens zwei der folgenden Methoden.

• Unser Redirect Checker zeigt den Statuscode und die Weiterleitungskette für jede Adresse.
• Die Entwicklertools Ihres Browsers zeigen außerdem im Netzwerk Tab den Status jeder Anfrage.
• Ihre Server oder CDN Logs zeigen schließlich, was Googlebot erhalten hat. Unsere Logfile Analyse hilft Ihnen beim Lesen.

Vergleichen Sie danach die Ergebnisse. Liefert der Redirect Checker eine normale Seite, die Logs zeigen aber einen Fehler für Googlebot, behandelt eine Regel Crawler anders. Zeigen also alle Methoden denselben 4xx, liegt die Ursache bei der Seite selbst oder ihrer Adresse.

Testen Sie exakt die Adresse aus dem Bericht, einschließlich Protokoll, www Präfix, Schrägstrich am Ende und Parametern. Schon ein kleiner Unterschied in der Adresse kann daher die Antwort verändern.

Wie beheben Sie „wegen eines anderen 4xx Problems blockiert“ Schritt für Schritt?

Gehen Sie jedes Mal in derselben Reihenfolge vor. Sonst ändern Sie womöglich Regeln, bevor Sie die Ursache kennen.

1. Kopieren Sie zunächst die Beispiel URLs und sortieren Sie sie in „soll existieren“ und „soll nicht existieren“.
2. Finden Sie danach für jede Gruppe den echten Statuscode mit dem Live Test und einem zweiten Werkzeug.
3. Beheben Sie dann bei Seiten, die existieren sollen, die Ursache: eine Regel, ein Plugin, ein defektes Template oder eine falsche Adresse.
4. Entfernen Sie bei Seiten, die nicht existieren sollen, interne Links und Sitemap Einträge, und belassen Sie dann den Fehler oder leiten Sie auf einen Ersatz weiter.
5. Wiederholen Sie danach den Live Test bei einigen korrigierten URLs und bestätigen Sie eine normale Antwort.
6. Starten Sie schließlich die Prüfung im Bericht und beobachten Sie das Ergebnis.

Überspringen Sie den fünften Schritt nicht. Die Validierung prüft nur, was Google sehen kann, also scheitert eine Korrektur, die bei Ihnen funktioniert, bei Googlebot aber nicht, erneut. Daher sind Live Test und Logs Ihr Sicherheitsnetz.

Verwalten Sie viele Seiten, dokumentieren Sie jede Änderung. Eine kurze Notiz mit Datum, Regel und betroffenem Muster spart Stunden, wenn später ein ähnlicher Status auftaucht.

Was machen Sie mit URLs, die verschwinden sollen?

Zunächst sollten Sie die Entfernung sauber durchführen. Ein absichtlicher Fehler ist in Ordnung, aber nur, wenn nichts mehr darauf zeigt. Suchen Sie die Adresse in Navigation, Inhalt, Sitemap und strukturierten Daten.

• Entfernen Sie zunächst interne Links auf die alte Adresse.
• Löschen Sie danach die Adresse aus jeder XML Sitemap.
• Richten Sie eine dauerhafte Weiterleitung ein, wenn es einen nahen Ersatz gibt.
• Sonst belassen Sie die Fehlerantwort, wenn es keinen Ersatz gibt.

Weiterleitungen werfen die Anschlussfrage auf: Wie lange sollen sie bleiben? Unser Beitrag dazu: Wie lange 301 Weiterleitungen bleiben sollten. Außerdem hilft Ihnen unser Tool zum Zuordnen von Weiterleitungen, alte und neue Adressen zuzuordnen, wenn Sie viele Seiten auf einmal stilllegen.

Erwarten Sie schließlich nicht, dass der Status sofort verschwindet. Google muss die Adresse erneut crawlen, bevor sich der Bericht ändert, und das hängt davon ab, wie oft Google Ihre Website besucht.

Wie bestätigen Sie die Korrektur im Bericht zur Seitenindexierung?

Öffnen Sie nach der Korrektur das Problem im Bericht und klicken Sie auf „Fehlerbehebung überprüfen“. Die Hilfeseite beschreibt, was dann passiert. Google prüft zunächst Beispielseiten. Besteht der Fehler dort weiter, bricht die Prüfung daher ab. Andernfalls wechselt sie in den Status „gestartet“ und reiht die betroffenen URLs ein.

Einzelne URLs durchlaufen dann diese Zustände:

• Ausstehend: Google hat die URL noch nicht geprüft.
• Bestanden: Das Problem ist auf der Seite nicht mehr erkennbar.
• Fehlgeschlagen: Das Problem besteht weiterhin.
• Sonstige: Die URL war nicht erreichbar oder das Element existiert nicht mehr.

Schlägt die Prüfung fehl, korrigieren Sie die übrigen URLs und starten Sie eine neue Prüfung. Laut Dokumentation prüft sie dann die URLs mit dem Zustand ausstehend oder fehlgeschlagen erneut. Achten Sie außerdem auf die Spalte mit dem letzten Crawl: Eine Korrektur nach diesem Datum ist womöglich noch nicht sichtbar.

Die Beispielliste ist eine Stichprobe und enthält nicht unbedingt jede betroffene URL. Daher beweist ein bereinigtes Beispiel nicht, dass alle Adressen repariert sind. Nutzen Sie also die Logs, um den Rest zu bestätigen.

Warum bleibt der Status nach der Korrektur im Bericht stehen?

Meist, weil Google die Adresse noch nicht erneut gecrawlt hat. Denn der Bericht spiegelt den letzten Crawl wider, nicht den aktuellen Zustand Ihres Servers. Deshalb kann eine richtige Korrektur eine Weile unverändert aussehen.

Einen verlässlichen Zeitraum können wir nicht nennen, und die offizielle Dokumentation verspricht keinen. Warten Sie also nicht blind, sondern prüfen Sie drei Dinge.

1. Zeigt der Live Test jetzt eine normale Antwort?
2. Verlinken Sie die URL noch aus Sitemap oder Navigation, sodass Google weiter dem alten Problem begegnet?
3. Zeigen die Logs Googlebot Besuche nach Ihrer Korrektur, und mit welchem Status?

Sieht dann alles gesund aus, holt der Bericht auf. Zeigen die Logs für Googlebot dennoch weiter Fehler, ist die Korrektur unvollständig. Gehen Sie dann zurück zu den Prüfungen von Firewall und Plugins.

Vermeiden Sie es, neue Properties anzulegen oder URLs zu duplizieren, um den Bericht „zurückzusetzen“. Denn das löst die Ursache nicht und macht Ihre Daten schwerer lesbar.

Können Sonderzeichen, Domains und Weiterleitungen einen 4xx erzeugen?

Ja, das ist möglich. Adressen mit nicht lateinischen Buchstaben oder Umlauten brauchen die richtige Kodierung. Ein Link mit fehlerhafter Kodierung kann eine Antwort „ungültige Anfrage“ auslösen, während die korrekte Form funktioniert. Unser Beitrag zu Umlaut Domains, IDN und Punycode erklärt, wie solche Adressen funktionieren und was Sie prüfen sollten.

Zudem können auch Weiterleitungen Ärger machen. Eine Weiterleitung, die Crawler auf einen anderen Host, einen geschützten Bereich oder eine entfernte Seite schickt, endet in einem Fehler. Folglich kann die ursprüngliche Adresse gemeldet sein, obwohl Sie nie auf das Ziel verlinkt haben.

• Prüfen Sie zunächst, dass jede Weiterleitung auf einer Seite mit normaler Antwort endet.
• Vermeiden Sie lange Weiterleitungsketten, denn eine direkte Weiterleitung ist sauberer.
• Testen Sie schließlich die Version mit und ohne Schrägstrich am Ende getrennt.

Diese kleinen Details erklären viele Fälle, in denen eine Adresse im Browser einwandfrei aussieht. Der Browser folgt zum Beispiel Weiterleitungen und korrigiert manche Fehler still. Googlebot meldet dagegen genau das, was er erhalten hat.

Was sollten Sie bei der Behebung dieses Status vermeiden?

Allerdings machen manche Abkürzungen alles schlimmer. Die Tabelle nennt die häufigsten und den Grund, warum sie scheitern.

Streben Sie stattdessen saubere, ehrliche Antworten an. Anders gesagt: Eine Seite, die existiert, liefert eine normale Antwort. Eine Seite, die weg ist, liefert einen Fehler oder eine Weiterleitung. Hilfe zur robots.txt Seite finden Sie in unserem Beitrag zu häufigen robots.txt Fehlern.

Welche URLs sollten Sie zuerst angehen?

Nicht jede Beispiel URL hat dieselbe Priorität. Schauen Sie daher zuerst auf die Adressen mit der größten Wirkung. Ist die Zeit knapp, hilft also eine feste Reihenfolge.

1. Adressen in Ihrer Sitemap: Sie haben sie Google selbst empfohlen, deshalb ist ein Fehler dort widersprüchlich.
2. Adressen, die aus Menü, Footer oder Startseite verlinkt sind: Sehr viele Seiten verweisen darauf.
3. Conversion Seiten wie Verkauf, Formular oder Kontakt: Ein Fehler kostet hier direkt Umsatz.
4. Adressen mit Backlinks von anderen Seiten: Erwägen Sie eine Weiterleitung, damit der Wert der Links nicht verpufft.
5. Übrige Müll URLs: Behandeln Sie sie zuletzt und bereinigen Sie nur ihre Quellen.

Somit entsteht selbst bei Hunderten Adressen ein klarer Plan. Zudem liefert Ihre Prüfung schneller ein Ergebnis, weil Sie zuerst eine kleine, aber wichtige Gruppe korrigieren.

Beispielszenario: Was passiert, wenn ein Sicherheitsplugin Googlebot ausbremst?

Das Folgende ist kein echter Kundenfall, sondern ein Beispielszenario. Auf einer Unternehmensseite sperrt ein Sicherheitsplugin Besucher vorübergehend, die in kurzer Zeit viele Anfragen senden. Dann läuft an einem Tag mit intensivem Crawling auch Googlebot in dieses Limit.

Folglich erhalten Kategorieseiten aus Sicht von Google einen Clientfehler. Sie selbst öffnen die Seite im Browser ohne Probleme, weil Ihre Anfragerate niedrig ist. Nach einigen Tagen sammeln sich die betroffenen Adressen in der Search Console unter diesem Label.

• Symptom: Wichtige Seiten stehen im Bericht, öffnen sich im Browser aber normal.
• Hinweis: In den Serverlogs erhalten einige Googlebot Anfragen einen Fehler, Besucheranfragen nicht.
• Lösungsrichtung: Ratenlimit und Ausnahmeliste des Plugins prüfen und das Limit für echten Googlebot lockern.

Schnelles Handeln ist hier wichtig. Allerdings ist es keine Lösung, jede Sperre aufzuheben, denn das Plugin schützt Sie auch vor echten Angriffen. Stattdessen ist der richtige Weg, die Regel einzugrenzen und echtem Googlebot Raum zu geben.

Wie unterscheiden Sie dieses Label von 401, 403, 404 und Soft 404?

Ein kurzer Entscheidungsweg verhindert Verwechslungen. Lesen Sie zuerst die Antwort im Prüftool für URLs und gehen Sie danach die folgende Reihenfolge durch.

• Verlangt die URL eine Anmeldung, geht es um 401; dafür gibt es ein eigenes Label.
• Versteht der Server die Anfrage und lehnt sie ab, geht es um 403; dafür gibt es ein eigenes Label.
• Wird die Seite nicht gefunden, geht es um 404; dafür gibt es ein eigenes Label.
• Sieht die Seite wie ein Fehler aus, liefert aber eine normale Antwort, geht es um Soft 404; dafür gibt es ein eigenes Label.
• Trifft nichts davon zu, zeigt das Label meist auf die Sammelkategorie.

Allerdings können Label im Bericht und aktuelle Serverantwort auseinanderliegen. Der Bericht zeigt den letzten Crawl, der Live Test dagegen den Moment. Sehen Sie also einen Unterschied, hat sich die Antwort Ihres Servers womöglich inzwischen geändert; verlassen Sie sich dann auf die neue Antwort.

Wie verhindern Sie, dass dieser Status zurückkommt?

Vorbeugung ist größtenteils Routine. Prüfen Sie den Bericht zur Seitenindexierung regelmäßig und werfen Sie früh einen Blick auf die Sammelkategorie, bevor eine Regeländerung viele Seiten betrifft.

• Prüfen Sie zunächst Firewall und Sicherheitsplugin Regeln nach jedem Update.
• Crawlen Sie danach Ihre eigene Website und vergleichen Sie die Antwortcodes mit Ihrer Sitemap.
• Führen Sie außerdem eine Logfile Analyse für Googlebot Anfragen mit Fehlern durch.
• Pflegen Sie schließlich eine Weiterleitungsliste, wenn Sie Seiten entfernen oder umbenennen.

Testen Sie außerdem neue Templates vor dem Livegang. Ein Menü oder Footer mit einem ungewöhnlichen Endpunkt vervielfacht das Problem auf jeder Seite. Deshalb spart eine einzige Prüfung auf einer Testkopie später viel Aufräumarbeit.

Schließlich sollten Sie Ausschläge als Signal verstehen. Ein plötzlicher Sprung bei den betroffenen URLs folgt meist auf ein Deployment, ein Plugin Update oder einen Hostingwechsel. Vergleichen Sie dann das Datum des Sprungs mit Ihrem Änderungsverlauf.

Wann sollten Sie sich Unterstützung holen?

Holen Sie sich daher Hilfe, wenn die betroffenen URLs wichtige Seiten enthalten und Sie die Ursache nicht in ein oder zwei Stunden finden. Serverregeln, CDN Einstellungen und Anwendungscode greifen oft ineinander. Ein zweites Augenpaar spart Zeit.

Talha Aslan und sein Team arbeiten seit 2012 im Feld und sind Google Partner. Konkret lesen wir Logs, testen Live Antworten und prüfen Regeln gemeinsam mit Ihrem Entwickler oder Hostinganbieter. Unsere SEO Beratung deckt genau diese Art technischer Diagnose ab.

Wir versprechen nicht, dass ein Status an einem festen Datum verschwindet, denn das erneute Crawling liegt bei Google. Wir können aber die Ursache finden, sie sauber beheben und Ihnen belegen, dass der Server jetzt korrekt antwortet.

Dieser Beitrag ist allgemeine Information und keine Garantie für Ihre Website. Labels und Menüs in der Search Console können sich ändern, also prüfen Sie die verlinkten offiziellen Seiten auf den aktuellen Wortlaut.