Google Search Console Fehler

Die Meldungen im Bericht „Seitenindexierung“ der Google Search Console wirken oft wie Fehler, sind aber nicht immer ein Problem. Manche weisen auf technische Defekte hin, andere dokumentieren bewusst ausgeschlossene Seiten oder Entscheidungen von Google. Entscheidend ist daher nicht die Anzahl der gemeldeten URLs, sondern ob wichtige Seiten betroffen sind und ob der jeweilige Status beabsichtigt ist.

Dieser Artikel erklärt die wichtigsten Gründe verständlich: Was die Meldung technisch bedeutet, wann Handlungsbedarf besteht und welche Ursachen typischerweise dahinterstehen. Zu jedem Status finden Sie außerdem konkrete Praxistipps und Schritte zur direkten Selbsthilfe – von der Prüfung in der Search Console über Browser-Entwicklertools bis zu den Einstellungen in CMS, Server und robots.txt.

Liste alle Fehlercodes

Fehlercode	Quelle
Durch robots.txt-Datei blockiert	Website
Umleitungsfehler	Website
Seite mit Weiterleitung	Website
Wegen nicht autorisierter Anforderung (401) blockiert	Website
Wegen Zugriffsverbot (403) blockiert	Website
Nicht gefunden (404)	Website
Soft 404	Website
Wegen eines anderen 4xx-Problems blockiert	Website
Serverfehler (5xx)	Website
Duplikat – vom Nutzer nicht als kanonisch festgelegt	Website
Alternative Seite mit richtigem kanonischen Tag	Website
Durch „noindex“-Tag ausgeschlossen	Website
Indexiert, obwohl durch robots.txt-Datei blockiert	Website
Seite ohne Inhalt indexiert	Website
Duplikat – Google hat eine andere Seite als der Nutzer als kanonische Seite bestimmt	Website / Google-Systeme
Gecrawlt – zurzeit nicht indexiert	Google-Systeme
Gefunden – zurzeit nicht indexiert	Google-Systeme

Durch robots.txt-Datei blockiert

Was es bedeutet
Der Googlebot wollte die URL abrufen. Eine Disallow-Regel in Ihrer robots.txt hat dies verhindert. Die Seite wurde nie gecrawlt und kann deshalb nicht in den Index aufgenommen werden. Entscheidend ist die Reihenfolge: Google liest die robots.txt vor dem Seitenabruf. Ein „noindex” im Head-Bereich bleibt dadurch unsichtbar, weil Google diesen Bereich nie zu Gesicht bekommt.

Wie gefährlich ist der Fehler?
Im Normalfall harmlos. Warenkorb, Checkout, interne Suchergebnisse und Adminbereiche sollen bewusst nicht gecrawlt werden. Auch in Shops und/oder durch ältere CMS, die noch mit Parametern in der URL arbeiten, kann die Zahl hoch sein und dennoch nicht zu Nachteilen führen.

Kritisch wird es in zwei Fällen: wenn Seiten mit Umsatz- oder Leadrelevanz in der Liste stehen oder wenn die Zahl der betroffenen URLs sprunghaft steigt. Dann ist meist eine Regel zu breit gefasst oder eine Testkonfiguration live gegangen.

Was Sie selbst tun können

• Rufen Sie ihredomain.de/robots.txt auf und lesen Sie jede Disallow-Zeile einzeln.
• Gehen Sie die Beispiel-URLs in der Search Console durch und sortieren Sie: gewollt blockiert oder nicht?
• Entfernen oder verengen Sie die betreffende Regel. Eine Regel gilt für alles, was mit dem angegebenen Pfad beginnt – Disallow: /pro sperrt auch /produkte/.
• Soll eine Seite nicht in den Index, aber gecrawlt werden dürfen: noindex im Head setzen und die robots.txt-Sperre entfernen. Beides zusammen funktioniert nicht.
• Nach der Korrektur die URL in der Search Console prüfen und zur Indexierung anfordern.

Typische Ursachen und Seitentypen
Ein häufigste Auslöser ist ein Disallow: / aus der Staging-Umgebung, das beim Relaunch mitkopiert wurde. Ebenso häufig sind Wildcard-Regeln wie Disallow: /*?, die auch legitime Parameterseiten trifft. In WordPress schreiben SEO-Plugins und öfters auch Caching- und Sicherheitsplugins eigene Regeln in die Datei. Betroffen sind vor allem Shops mit Filternavigation und große Portale, die aktiv Crawl-Steuerung betreiben.

Tools

• Browser: ihredomain.de/robots.txt direkt aufrufen
• Search Console → URL-Prüfung → „Live-URL testen“: zeigt unter „Crawling“, ob der Abruf erlaubt ist
• Search Console → Einstellungen → robots.txt-Bericht: zeigt die zuletzt gelesene Version und Syntaxfehler
• Entwicklertools (F12) → Netzwerk → Seite neu laden: Statuscode und ausgelieferter Inhalt der robots.txt

Umleitungsfehler

Was es bedeutet
Der Googlebot hat eine Weiterleitung gefunden, konnte ihr jedoch nicht bis zum Ziel folgen. Die Seite bleibt damit unerreichbar. Es gibt vier mögliche Gründe:

• eine Schleife,
• eine zu lange Kette,
• eine überlange Ziel-URL oder
• eine leere bzw. ungültige URL in der Kette.

Wie gefährlich ist der Fehler?
Es gibt zwei Möglichkeiten: Entweder handelt es sich um einzelne URLs die aus irgendeinem Grund diesen Fehler liefern. Das ist weniger kritisch und sollte bei Zeiten reparierte werden. Es kann auch ein allgemeiner Fehler in einer Umleitungslogik sein. Im diesem Fall würde ich den Fehler als kritisch einschätzen. Hier wird die Anzahl der gemeldeten Fehler ein gutes Indiz sein.

Was Sie selbst tun können

• Rufen Sie die URL im Browser auf. Die Meldung ERR_TOO_MANY_REDIRECTS bestätigt eine Schleife sofort.
• Verfolgen Sie jede Station der Kette und notieren Sie Quelle und Ziel.
• Suchen Sie nach doppelten Regelsätzen: Weiterleitungen können in der .htaccess, im CMS und durch Plugins ausgelöst werden. Verschaffen Sie sich einen überblick über die möglichen Quellen.
• Ziel ist ein einziger Sprung pro URL, direkt auf das Endziel. Zwischenstationen entfernen.
• Bei „HTTP / HTTPS“- und „mit ohne www“-Regeln: Am besten durch eine Weiterleitung in der .htaccess festlegen und nicht sequentiell.

Typische Ursachen und Seitentypen
Die klassische Schleife entsteht, wenn zwei Ebenen gegeneinander arbeiten – der Server erzwingt HTTPS, ein Plugin erzwingt www, und beide schreiben die URL zurück. Ketten wachsen historisch: Nach dem dritten Relaunch führt eine alte URL über vier Stationen zum Ziel. Häufig auch nach Domainumzügen, wenn die alte Domain weiterleitet und am Ziel erneut eine interne Weiterleitung greift. Betroffen sind gewachsene Firmenseiten und Shops mit Migrationshistorie. Neue Projekte zeigen den Fehler fast nur bei fehlerhafter HTTPS-Konfiguration.

Tools

• Entwicklertools (F12) → Netzwerk, Haken bei „Protokoll beibehalten“ setzen, dann URL aufrufen: jede Station erscheint als eigene Zeile mit Statuscode
• Entwicklertools → Netzwerk → betroffene Zeile anklicken → „Header“ → „Location“: zeigt das jeweilige Weiterleitungsziel
• Search Console → URL-Prüfung → „Live-URL testen“: nennt die vom Googlebot tatsächlich erreichte URL
• Browser mit deaktiviertem Cache testen (Entwicklertools offen → „Cache deaktivieren“), da alte 301 im Browser gespeichert bleiben

Seite mit Weiterleitung

Was es bedeutet
Die URL leitet auf eine andere URL weiter. Google indexiert deshalb nicht sie, sondern das Ziel. Das ist eine Statusmeldung, kein Fehler. Bei größeren Websites ist diese Liste praktisch nie leer.

Wie gefährlich ist der Fehler?
Geringe Gefahr. Handlungsbedarf besteht in drei Konstellationen: Die weitergeleitete URL steht noch in der XML-Sitemap. Interne Links zeigen weiter auf die alte URL statt auf das Ziel. Oder die Weiterleitung führt pauschal auf die Startseite statt auf eine inhaltlich passende Seite – das wertet Google häufig als Soft 404, und die Weiterleitung verliert ihre Wirkung.

Wegen nicht autorisierter Anforderung (401) blockiert

Was es bedeutet
Der Server verlangt eine Anmeldung, bevor er die Seite ausgibt. Da der Googlebot sich nie anmeldet, übergibt er keine Zugangsdaten und akzeptiert keine Cookies. Die Seite bleibt für ihn verschlossen und ist somit nicht im Index enthalten. Der Unterschied zum Statuscode 403: Beim Statuscode 401 fehlt die Anmeldung, beim Statuscode 403 nützt auch eine Anmeldung nichts.

Wie gefährlich ist der Fehler?
Das ist kritisch bei jeder Seite, die öffentlich sein soll. Ein häufiger Grund ist ein Passwortschutz nach einem Relaunch – dadurch kann die ganze Seite aus dem Index verschwinden. Unkritisch sind hingegen Kundenkonten, Intranets und Mitgliederbereiche. Prüfen Sie also zuerst, welche URLs betroffen sind und/oder ganze Pfade.

Was Sie selbst tun können

• Rufen Sie die URL in einem privaten Fenster auf. Erscheint ein Anmeldedialog des Browsers, greift ein serverseitiger Passwortschutz.
• Sollen die Seiten öffentlich sein: Schutz für den Live-Bereich aufheben, danach die URL in der Search Console zur Indexierung anmelden.
• Sollen sie geschützt bleiben: URLs aus der Sitemap entfernen und interne Links darauf abbauen.¹

Typische Ursachen und Seitentypen
Fast immer HTTP-Basisauthentifizierung auf Server- oder Verzeichnisebene, seltener ein Wartungsmodus oder ein Plugin mit „Website vorübergehend sperren“. Betroffen sind vor allem frisch relaunchte Firmenseiten, Testumgebungen unter erreichbaren Subdomains sowie Portale mit Mitgliederbereich.

Tools

• Browser im privaten Fenster: Der Anmeldedialog ist das eindeutige Symptom
• Entwicklertools (F12) → Netzwerk: Statuscode 401 in der ersten Zeile, im Antwortheader steht WWW-Authenticate
• Search Console → URL-Prüfung → „Live-URL testen“: zeigt den Statuscode, den Google erhält
• Search Console → Bericht „Seiten“: Beispiel-URLs auf gemeinsames Pfadmuster prüfen

Wegen Zugriffsverbot (403) blockiert

Was es bedeutet
Der Server hat die Anfrage des Googlebots verstanden und bewusst abgelehnt. Der Statuscode 403 bedeutet, dass die Ressource existiert, der Anfragende sie aber nicht sehen darf. Im Gegensatz zu einer robots.txt-Sperre wird die Ablehnung nicht durch eine Crawling-Regel, sondern durch den Server selbst ausgeführt. Bei 401 fehlt dem Googlebot die Anmeldung bei 403 nützt auch eine Anmeldung nichts – der Zugriff ist grundsätzlich verboten.

Wie gefährlich ist der Fehler?
Das ist besonders kritisch, wenn öffentlich zugängliche Seiten betroffen sind. Ein 403-Fehler kann zur Deindexierung führen, ohne dass es die Besucher oder der Betreiber merkt – sie kommen ja durch. Genau das macht die Meldung tückisch: Sie testen im Browser und alles scheint zu funktionieren, trotzdem bleibt die Seite draußen. Unkritisch ist die Meldung bei Kundenkonten, internen Bereichen und Downloads für angemeldete Nutzer. Alarmierend ist ein plötzlicher Anstieg über viele URLs hinweg, da dann meist eine Schutzfunktion den Googlebot flächendeckend blockiert.

Was Sie selbst tun können

• Rufen Sie die Seite in der Search Console ab „Live Vorschau“. Vergewissern Sie sich über den aktuellen Stand.
• Rufen Sie die betroffene URL im Browser auf. Funktioniert sie dort, aber nicht für Google, blockiert der Server gezielt den Bot.
• Wiederholen Sie den Aufruf in einem privaten Fenster ohne Anmeldung. Erscheint jetzt der 403, liegt eine Zugangsbeschränkung vor.
• Rufen Sie die URL mit dem User-Agent des Googlebots ab. Erscheint nur dann ein 403, filtert eine Firewall oder ein Sicherheitsmodul nach User-Agent.
• Prüfen Sie, ob eine Sicherheits- oder Firewall-Erweiterung aktiv ist. Deaktivieren Sie sie testweise und rufen Sie die Seite erneut mit Bot-Kennung ab.

Typische Ursachen und Seitentypen
Der häufigste Grund ist ein Schutzmechanismus, der zu scharf eingestellt ist: Bot-Erkennung, Rate Limiting oder ein Regelwerk, das viele Anfragen in kurzer Zeit als Angriff wertet – genau das Muster, das ein Crawler erzeugt. Zweiter Klassiker sind Zugangsbeschränkungen nach IP oder Land, etwa wenn nur deutsche Adressen zugelassen sind und der Googlebot aus den USA anfragt. Dazu kommen Verzeichnisse ohne Indexdatei bei abgeschalteter Auflistung, falsch gesetzte Dateirechte nach einem Servermove und Hotlink-Schutz, der Bilder für externe Abrufe sperrt. Ebenso möglich sind API Schnittstellen, die versehentlich öffentlich sind oder vom Googlebot gefunden und jetzt gcrawled werden.

Betroffen sind besonders Mitgliederbereiche und Portale mit Anmeldepflicht, Newsseiten mit harter Bezahlschranke, Shops mit Kundenkonten sowie alle Websites hinter einer aktiv konfigurierten Web Application Firewall. Bei einfachen Firmenseiten tritt der 403 meist punktuell auf – etwa bei PDF-Ordnern oder Verzeichnissen, die versehentlich verlinkt wurden.

Tools

• Search Console → URL-Prüfung → „Live-URL testen“: Unter „Crawling“ steht der Statuscode, den Google in diesem Moment erhält
• Entwicklertools (F12) → Netzwerk → Seite laden: Die erste Zeile zeigt den Statuscode; unter „Header“ sehen Sie in „Antwortheader“, welches System geantwortet hat
• Entwicklertools → Netzwerk → Drei-Punkte-Menü → „Netzwerkbedingungen“ → User-Agent-Auswahl auf „Googlebot“ umstellen, dann Seite neu laden: reproduziert die Bot-Anfrage
• Browser im privaten Fenster: trennt Zugangsbeschränkung von genereller Sperre
• Search Console → Bericht „Seiten“ → Beispiel-URLs exportieren und auf gemeinsames Muster im Pfad prüfen

Nicht gefunden (404)

Was es bedeutet
Der Server hat die Anfrage mit dem Statuscode 404 beantwortet und damit mitgeteilt, dass unter dieser URL keine Ressource existiert. Google kennt die URL trotzdem – entweder aus einem internen oder externen Link, aus einer Sitemap oder aus dem eigenen Index, da die Seite früher existiert hat. Ein 404-Statuscode ist kein Defekt, sondern die technisch korrekte Antwort auf eine ungültige Anfrage. Google entfernt solche URLs nach mehreren erfolglosen Crawl-Versuchen aus dem Index, versucht es aber über Monate hinweg in abnehmender Frequenz erneut.

Wichtig ist die Abgrenzung zum Statuscode 410 (Gone): Dieser signalisiert eine bewusste, endgültige Löschung und führt in der Regel zu einer schnelleren Deindexierung. Der Standard in fast allen CMS ist 404. Man muss also mit Absicht und tlw. mit Aufwand einen 410 senden. Am Ergebnis ändert dies jedoch nichts.

Wie gefährlich ist der Fehler?
Für sich genommen sind sie gering. 404-Antworten sind ein normaler Zustand jeder gewachsenen Website und beeinflussen das Ranking auf Domainebene nicht. Google straft eine Website nicht dafür ab, dass sie gelöschte Seiten gelöscht hat.

Vorsicht ist geboten in diesen drei Szenarien:

• Erstens: Der Anteil der 404 steigt sprunghaft an. Das ist selten organisches, sondern fast immer ein technischer Defekt.
• Zweitens: Die URL sammelt externe Backlinks. Dann verpufft eingehende Linkkraft, weil sie auf eine Sackgasse trifft.
• Drittens: Die URL wird intern verlinkt. Dann verliert der Crawler bei jedem Durchlauf Budget an tote Pfade, und schlimmer: Nutzer landen in einer Fehlerseite.

Was Sie selbst tun können

• Exportieren Sie die betroffenen URLs und prüfen Sie in der Search Console pro URL die Referrer unter „Verweisende Seiten“. Nur so trennen Sie interne Fehlverlinkung von externen Quellen.
• Bei internen Links: Korrigieren Sie die Verlinkung an der Quelle. Eine Weiterleitung ist hier nur ein Pflaster – der falsche Link bleibt im Quelltext stehen.
• Bei externen Links auf entfernte Inhalte: Setzen Sie einen 301 auf die inhaltlich nächstliegende bestehende Seite. Kein Pauschal-Redirect auf die Startseite, das wertet Google als Soft 404.
• Bei bewusst gelöschten Inhalten ohne Ersatz: 404 stehen lassen oder auf 410 wechseln. Nichts weiter tun ist hier die richtige Maßnahme.
• Entfernen Sie tote URLs aus der XML-Sitemap. Eine Sitemap mit 404 darin ist ein Qualitätssignal gegen Sie.
• Prüfen Sie, ob die Fehlerseite tatsächlich Statuscode 404 liefert und nicht 200 mit Fehlertext im Body – das wäre ein Soft 404 und ein anderes Problem.

Typische Ursachen und Seitentypen
Technisch dominieren Ursachen. Erstens gelöschte oder umbenannte Inhalte ohne Weiterleitungskonzept, besonders nach Migrationen. Zweitens fehlerhaft generierte URLs im Template: relative Pfade, die je nach Verzeichnisebene falsch auflösen, oder Links, in die eine ID nicht sauber eingesetzt wurde. Drittens Encoding-Probleme bei Sonderzeichen und Umlauten, wenn Zeichen doppelt kodiert im Pfad landen. Viertens veraltete Sitemaps, die von Plugins nicht aktualisiert werden.

Nach Seitentyp: Shops erzeugen 404 laufend durch Auslistungen und saisonale Produkte – hier gehört ein automatisiertes Regelwerk auf Kategorieebene hin. Newsseiten und Magazine durch Archivierung und geänderte Slugs. Wikis und Dokumentationen durch Umbenennungen in der Seitenhierarchie, wobei dort interne Links besonders schnell brechen. Firmenseiten zeigen 404 überwiegend punktuell und relaunchbedingt, dann aber gehäuft auf einmal.

Tools

• Search Console → Bericht „Seiten“ → „Nicht gefunden (404)“ → URL anklicken → „Verweisende Seiten“: zeigt die Quelle der Verlinkung
• Search Console → URL-Prüfung → „Live-URL testen“: bestätigt den aktuellen Statuscode
• Entwicklertools (F12) → Netzwerk → Seite laden: Statuscode der Hauptanfrage in der ersten Zeile. Eine gestylte Fehlerseite mit Status 200 erkennen Sie nur hier
• Entwicklertools → Konsole: meldet 404 bei nachgeladenen Ressourcen wie Bildern, Schriften und Skripten, die im Seitenbericht nicht auffallen

Soft 404

Was es bedeutet
Der Server liefert den Statuscode 200 (OK), doch Googles Bewertung des Inhalts lautet: „Hier ist nichts oder etwas ist kaputt.” Diese Diskrepanz zwischen technischer Antwort und tatsächlichem Inhalt ist das Problem. Google erkennt Soft 404 durch eine automatische Analyse des gerenderten Inhalts. Typischerweise werden Fehlermeldungen im Text („Seite nicht gefunden”, „Kein Ergebnis”) sowie nahezu leere Seiten und Seiten, deren Hauptinhalt ausschließlich aus Navigation und Footer besteht, erkannt.

Ein zweiter, weniger bekannter Fall ist eine Weiterleitung auf eine Seite, die inhaltlich nichts mit der Quell-URL zu tun hat, etwa eine pauschale Weiterleitung auf die Startseite. Auch das wertet Google als Soft 404, obwohl technisch ein sauberer 301 vorliegt.

Die Konsequenz ist dieselbe wie bei einem echten 404-Fehler: Die Seite wird nicht indexiert. Der Unterschied liegt im Ressourcenverbrauch: Google muss die Seite abrufen, rendern und bewerten, bevor die Ablehnung feststeht. Ein echter 404 kostet dagegen nur einen Request.

Wie gefährlich ist der Fehler?
Mittel bis hoch und deutlich größer als bei einem echten 404, denn bei Beim 404 wissen Sie, dass die Seite weg ist. Beim Soft 404 hingegen gehen Sie fälschlicherweise davon aus, dass alles funktioniert, da Server und Browser den Status 200 melden. Dadurch bleibt der Fehler oft monatelang unentdeckt.

Besonders kritisch wird es, wenn inhaltlich vollwertige Seiten fälschlich als Soft 404 eingestuft werden. Dadurch werden Ihre Inhalte gar nicht erst indexiert und können demnach auch niemals in Google gefunden werden. Dies kann bei

• sehr dünnen Seiten,
• bei Inhalten, die erst clientseitig nachgeladen werden, sowie
• bei Seiten mit hohem Boilerplate-Anteil der Fall sein.

Weniger kritisch, und erst ab einer sehr großen Zahl relevant: Soft 404 aus Filterkombinationen ohne Treffer. Sie schaden nicht direkt, verbrauchen aber Crawl-Budget für Seiten, die nie indexiert werden.

Was Sie selbst tun können

• Exportieren Sie die URLs aus der Search Console und versuchen Sie die Liste in zwei Gruppen zu teilen: Seiten, die inhaltlich leer sind, und Seiten, die mit dem Inhalt ranken sollen.
• Bei inhaltlich leeren Seiten: Auf echten 404 oder 410 umstellen. Eine Fehlerseite muss den passenden Statuscode 404 liefern, nicht nur so aussehen.
• Bei leeren Ergebnislisten und Filterkombinationen ohne Treffer: 404 senden statt einer 200-Seite mit „Keine Ergebnisse“. Alternativ die Kombinationen gar nicht erst crawlbar machen.
• Bei Seiten mit Inhalt: Prüfen, ob der Hauptinhalt im ausgelieferten HTML steht oder erst per JavaScript entsteht. Google bewertet die gerenderte Seite, aber Rendering kann scheitern oder verzögert erfolgen.
• Verhältnis von Hauptinhalt zu Navigation prüfen. Eine Seite mit drei Sätzen Text und einer 200 Links langen Navigation sieht für Google aus wie eine leere Seite.
• Pauschale Weiterleitungen auf die Startseite auflösen und durch inhaltlich passende Ziele ersetzen. Wo es kein passendes Ziel gibt, ist der 404 die richtige Antwort.
• Nach der Korrektur die URL erneut prüfen und zur Indexierung anfordern.

Beispiel aus der Praxis: Die URL wird per 302 auf eine „Werk nicht gefunden“ Seite geleitet und diese liefert einen Statuscode 200 OK. Der Inhalt der Seite besteht aus der Meldung „Es wurde kein Werk mit dem Identifier ‚hier-stand-ein-zahlencode‘ gefunden. Bitte prüfen Sie noch einmal Ihre Eingabe.“

Wegen eines anderen 4xx-Problems blockiert

Was es bedeutet
Diese Meldung ist die Sammelkategorie für alle clientseitigen Fehler, die Google nicht bereits als 401, 403 oder 404 separat ausweist – in der Praxis vor allem 400 (Bad Request), 405 (Method Not Allowed), 410 (Gone), 414 (URI Too Long) und 429 (Too Many Requests). Der Server hat die Anfrage jeweils abgelehnt und den Grund im Statuscode benannt; Google fasst diese Fälle nur deshalb zusammen, weil sie einzeln zu selten vorkommen.

Technisch stecken meist fehlerhaft konstruierte URLs dahinter: doppelt kodierte Sonderzeichen, ins Unendliche wachsende Parameterketten aus Filternavigationen oder Session-IDs im Pfad, die der Server nicht mehr verarbeiten kann. Ein 429 ist der Sonderfall – dort blockt ein Rate Limit den Crawler ab, weil er als Lastquelle erkannt wurde.

Wie gefährlich ist der Fehler?
Bei niedriger Fallzahl unkritisch und oft Folge fremder Fehlverlinkung, bei steigendem Volumen jedoch ein Symptom für ein strukturelles URL-Problem im Template oder in der Serverkonfiguration.

Serverfehler (5xx)

Was es bedeutet
Der Googlebot hat die URL angefragt, der Server hat die Anfrage angenommen, aber bei der Verarbeitung ist er gescheitert. Ein Statuscode 5xx bedeutet, dass der Fehler nicht bei der Anfrage, sondern auf der Serverseite liegt. Relevant sind vor allem die folgenden Codes:

• 500 (Internal Server Error) als Sammelantwort bei Applikationsfehlern,
• 502 (Bad Gateway) und
• 504 (Gateway Timeout) bei Problemen zwischen vorgelagertem Webserver und Anwendung sowie
• 503 (Service Unavailable) für temporäre Nichtverfügbarkeit.

Der 503 hat dabei einen Sonderstatus: Er ist der einzige 5xx-Code, den Google als bewusstes Signal versteht. Google verlangsamt daraufhin das Crawling und behält die betroffene Seite zunächst im Index. Zusammen mit einem Retry-After-Header ist er die korrekte Antwort für geplante Wartungsfenster. Alle anderen 5xx wertet Google als ungeplanten Ausfall.

Wie gefährlich ist der Fehler?
Die Gefahr ist groß, und zwar unabhängig von der Anzahl betroffener URLs. Im Gegensatz zu 4xx-Meldungen liegt hier ein Defekt vor, der auch den Besuchern angezeigt wird. Jeder 5xx-Fehler bedeutet einen verlorenen Nutzer.

Kurze Ausfälle von wenigen Minuten verkraftet Google problemlos – er versucht es später erneut. Hält der Zustand über Tage an, werden betroffene URLs aus dem Index entfernt. Zur Reproduzierbarkeit des Fehlers: Sporadische 5xx unter Last sind ein Kapazitätsproblem und deuten auf eine Website, die bei Traffic-Spitzen ausfällt. Konstante 5xx auf bestimmten URLs sind ein Programmier- oder Konfigurationsfehler und meist leichter zu finden.

Besonders unangenehm ist der Fall, in dem 5xx nur beim Googlebot auftreten, nicht im Browser. Dann ist die Website für Menschen erreichbar und für Google defekt – das fällt ohne Blick in die Search Console niemandem auf.

Was Sie selbst tun können

• Rufen Sie die betroffene URL im Browser auf. Tritt der Fehler dort nicht auf, prüfen Sie den Zeitpunkt: 5xx unter Crawl-Last verschwinden bei Einzelaufrufen.
• Sehen Sie das Errorlog des Webservers (z.B. Apache oder nginx) nach, das ist meistens der beste Einstieg. Dort finden Sie Hinweise wie PHP-Fatals, .htaccess-Fehler, fehlende Dateien/Rechte, mod_rewrite-Probleme oder Probleme mit PHP-FPM. Typische Meldungen sind etwa AH..., Permission denied, Invalid command, End of script output before headers oder ein PHP-Fehler, den Apache übernommen hat.
• Prüfen Sie, ob die Fehler zeitlich gebündelt auftreten. Ein Muster deutet auf Cronjobs, Backups oder Importe, die den Server periodisch auslasten.
• Grenzen Sie Applikations- von Infrastrukturfehlern ab: 502 und 504 entstehen zwischen Webserver und Anwendung, 500 innerhalb der Anwendung.
• Für geplante Wartung: 503 mit Retry-After ausliefern, nicht die Seite einfach abschalten und auch keine Weiterleitung auf eine Wartungsseite mit Status 200 setzen.

Typische Ursachen und Seitentypen
Technisch dominieren Ressourcengrenzen: erschöpftes Speicherlimit, überschrittene maximale Ausführungszeit, ausgereizte Datenbankverbindungen. Auf Shared Hosting kommen Limits des Anbieters hinzu, die bei Crawl-Wellen greifen. Die zweite große Gruppe sind Applikationsfehler nach Änderungen und Updates, Plugin-Konflikte, ein Syntaxfehler im Deployment etc. Dritte Gruppe: fehlkonfigurierte Reverse Proxies und Load Balancer, die 502 erzeugen, wenn die dahinterliegende Anwendung nicht antwortet.

Tools

• Entwicklertools (F12) → Netzwerk → Seite laden: Statuscode der Hauptanfrage in der ersten Zeile, im Antwortheader steht das antwortende System
• Search Console → URL-Prüfung → „Live-URL testen“: zeigt den Statuscode, den Google in diesem Moment erhält
• Search Console → Einstellungen → Crawling-Statistiken: Verlauf der Serverantwortzeiten und Anteil der 5xx über die Zeit. Die zentrale Stelle, um Ausfallmuster zu erkennen
• Server-Errorlog über die Verwaltungsoberfläche des Hosters: enthält bei 500 die konkrete Fehlermeldung
• Entwicklertools → Konsole: zeigt 5xx bei nachgeladenen Ressourcen und API-Aufrufen, die im Hauptdokument nicht sichtbar werden

Duplikat – vom Nutzer nicht als kanonisch festgelegt

Was es bedeutet
Google hat mehrere URLs mit identischem Inhalt gefunden und musste selbst entscheiden, welche davon in den Index aufgenommen wird. Sie haben diese Entscheidung nicht getroffen, denn entweder steht auf der betroffenen URL steht kein Canonical-Tag oder er zeigt auf die URL selbst, während eine andere URL denselben Inhalt ausliefert. Google hat eine Version als kanonisch bestimmt und die übrigen als Duplikate eingestuft. Indexiert wird nur die von Google ausgewählte Version.

Die Kanonisierung stützt sich dabei nicht nur auf das rel=canonical. Google wertet auch interne Verlinkung, Sitemap-Einträge, Weiterleitungen, hreflang-Angaben und die URL-Struktur selbst aus. Ein fehlendes Canonical bedeutet also nicht, dass keine Signale vorliegen – es bedeutet, dass das stärkste Signal fehlt und die schwächeren entscheiden.

Wichtig für die Abgrenzung zu den benachbarten Meldungen: Hier fehlt Ihre Angabe. Bei „Alternative Seite mit richtigem kanonischen Tag“ haben Sie eine Angabe gemacht und Google folgt ihr. Bei „Google hat eine andere Seite als kanonische Seite bestimmt“ haben Sie eine Angabe gemacht und Google überstimmt sie.

Wie gefährlich ist der Fehler?
Die Gefahr hängt davon ab, ob es sich um wenige URLs handelt oder ob es sich um ein grundsätzliches Problem in der URL/canonical Logik handelt. Im letzteren Fall sollten Sie das Problem dringend lösen, denn eine Seite ohne sauberes Indexierungsmanagement wird zwangsläufig weitere Probleme bekommen.

Es gibt drei kritische Konstellationen. Erstens bei großem Volumen: Jede Duplikatsgruppe kostet Crawl-Budget, da Google alle Varianten abrufen und vergleichen muss, bevor eine Entscheidung getroffen werden kann. Zweitens bei schwankender Auswahl, wenn Google die kanonische Version im Laufe der Zeit wechselt, schwanken auch die Rankings. Und drittens, wenn die Duplikate keine echten Duplikate sind. Werden inhaltlich unterschiedliche Seiten fälschlich zusammengefasst, kann eine Seite komplett aus dem Index verloren gehen. Das passiert bei Varianten, die sich nur in wenigen Details unterscheiden, etwa bei Produktseiten mit gleicher Beschreibung und abweichender Größe oder Farbe.

Unkritisch ist die Meldung bei bekannten technischen Duplikaten, die ohnehin nicht ranken sollen – Druckansichten, Sortiervarianten, Tracking-Parameter.

Was Sie selbst tun können

• Prüfen Sie zuerst über die URL-Prüfung, welche URL Google als kanonisch gewählt hat. Stimmt sie mit Ihrer Wunsch-URL überein, ist nichts zu tun.
• Setzen Sie auf jeder Seite ein selbstreferenzierendes Canonical. Damit entfällt der Interpretationsspielraum für alle URLs, die per Parameter angehängt werden.
• Bei Parametervarianten: Canonical der Variante auf die parameterlose Basis-URL zeigen lassen.
• Prüfen Sie interne Links auf Konsistenz. Wenn Sie an einer Stelle die Kurz-URL und an anderer die Variante mit Parameter verlinken, senden Sie widersprüchliche Signale.
• Nehmen Sie ausschließlich die kanonische Version in die XML-Sitemap auf.
• Prüfen Sie bei vermeintlichen Duplikaten mit echtem Eigenwert, ob sich die Seiten inhaltlich ausreichend unterscheiden. Zwei Produktseiten mit identischem Beschreibungstext sind für Google dasselbe Dokument, auch wenn Artikelnummer und Größe abweichen.
• Sperren Sie Duplikate nicht per robots.txt. Google muss das Canonical lesen können, um es zu befolgen. Eine Sperre verhindert genau das.
• Setzen Sie kein noindex auf Duplikate, wenn deren Signale auf die Hauptversion übergehen sollen – dafür ist das Canonical zuständig.

Typische Ursachen und Seitentypen
Technisch entstehen die meisten Fälle durch URL-Varianten derselben Ressource: Parameter für Tracking, Sortierung, Ansicht oder Session, Groß- und Kleinschreibung im Pfad, URLs mit und ohne abschließenden Schrägstrich, Erreichbarkeit über mehrere Verzeichnispfade. Dazu kommen inhaltliche Dubletten: Produkte in mehreren Kategorien mit jeweils eigener URL, Paginierungsseiten mit identischem Einleitungstext, Druck- und AMP-Versionen sowie Standortseiten, die sich nur im Ortsnamen unterscheiden.

Ein häufig übersehener Auslöser sind CMS-Konfigurationen, die dieselbe Seite unter mehreren Routen ausliefern – etwa unter der ID und unter dem sprechenden Slug.

Nach Seitentyp: Shops sind mit Abstand am stärksten betroffen, durch Filter, Sortierung, Paginierung und Produktvarianten. Immobilien-, Job- und Fahrzeugportale durch Suchergebnisseiten mit Parameterkombinationen. Firmenseiten mit vielen Standort- oder Leistungsseiten, wenn diese aus einem Template mit ausgetauschtem Ortsnamen entstehen. Newsseiten und Wikis eher selten, dort dominieren die Paginierungs- und Archivfälle.

Tools

• Search Console → URL-Prüfung → Abschnitt „Indexierung“: Zeigt „Vom Nutzer angegebene kanonische URL“ und „Von Google ausgewählte kanonische URL“ direkt untereinander. Das ist die entscheidende Gegenüberstellung
• Entwicklertools (F12) → Elemente → Strg+F → nach canonical suchen: zeigt, ob und wohin ein Canonical gesetzt ist
• Quelltext vergleichen: Rechtsklick → Seitenquelltext anzeigen bei beiden URLs, dann das Canonical im Head prüfen. Weicht der gerenderte DOM vom Quelltext ab, wird das Canonical per JavaScript gesetzt – ein bekanntes Risiko
• Entwicklertools → Netzwerk → Antwortheader: Canonicals können auch als HTTP-Header ausgeliefert werden, dann stehen sie nicht im HTML
• Browser: URL-Varianten manuell durchtesten – mit und ohne Schrägstrich, mit Großbuchstaben im Pfad, mit angehängtem ?test=1. Liefert jede Variante Status 200 mit identischem Inhalt, haben Sie das Duplikat reproduziert
• Search Console → Bericht „Seiten“ → Beispiel-URLs: Muster in den Parametern zeigen, welche Variantenart die Masse erzeugt

Der Test mit ?test=1 gehört an den Anfang jeder Prüfung. Liefert die URL mit erfundenem Parameter denselben Inhalt und kein Canonical auf die Basis-URL, kann jeder beliebige Link mit Tracking-Parameter ein neues Duplikat erzeugen.

Alternative Seite mit richtigem kanonischen Tag

Was es bedeutet
Diese URL hat einen Canonical Tag, der auf eine andere URL zeigt. Google hat das gelesen, für plausibel befunden und befolgt. Indexiert wird die angegebene Zielseite, nicht diese hier. Das System arbeitet also exakt so, wie Sie es eingestellt haben.

Der Unterschied zu den beiden benachbarten Meldungen liegt allein in der Frage, wer entschieden hat und ob Google zustimmt. Hier haben Sie entschieden und Google folgt. Bei „Duplikat – vom Nutzer nicht als kanonisch festgelegt“ haben Sie nichts angegeben. Bei „Google hat eine andere Seite als kanonische Seite bestimmt“ haben Sie eine Seite angegeben und Google widerspricht, bzw. folgt Ihrer Angabe nicht.

Wichtig für das Verständnis der Zahlen im Bericht: Diese Liste wächst mit der Website. Bei jedem Shop mit Filternavigation und selbstreferenzierenden Canonicals stehen hier zwangsläufig Tausende URLs. Die absolute Zahl sagt nichts über die Qualität aus.

Wie gefährlich ist der Fehler?
Es ist kein Fehler. Die Meldung steht im Bericht unter den nicht indexierten Seiten und wird deshalb regelmäßig für ein Problem gehalten – sie ist aber der dokumentierte Normalzustand einer korrekt kanonisierten Website. Der praktische Prüfansatz ist deshalb nicht „Wie viele URLs stehen hier?“, sondern „Steht hier eine URL, die eigentlich im Index sein sollte?“.

Drei Konstellationen lohnen die Prüfung. Erstens: Das Canonical zeigt pauschal auf die Startseite. Das ist ein kritischer Konfigurationsfehler, bei dem Sie ganze Seitenbereiche freiwillig aus dem Index nehmen. Zweitens: Zwei inhaltlich eigenständige Seiten werden zusammengefasst, weil ein Template dasselbe Canonical für eine ganze Kategorie ausgibt. Dann verlieren Sie eine Seite, die eigentlich ranken sollte. Drittens: Die Zielseite des Canonicals ist selbst nicht indexierbar – sie trägt ein noindex, liefert einen 404 oder leitet weiter. In diesem Fall zeigt das Canonical ins Leere, und Google muss die Kanonisierung neu bewerten.

Durch „noindex“-Tag ausgeschlossen

Was es bedeutet
Google hat die URL abgerufen, gecrawlt und dabei die Anweisung gefunden, diese Seite nicht in den Index aufzunehmen. Das unterscheidet diese Meldung grundlegend von der robots.txt-Sperre: Dort findet kein Abruf statt, hier findet er statt und die Anweisung wird gelesen.

Der noindex kann aus zwei Quellen stammen, die technisch gleichwertig sind, aber an völlig verschiedenen Stellen liegen:

Quelle 1: Meta-Tag im HTML-Head. <meta name="robots" content="noindex"> im Kopfbereich des Dokuments. Die Variante <meta name="googlebot" content="noindex"> richtet sich ausschließlich an Google und übersteuert die allgemeine Angabe. Diese Quelle ist im Seitenquelltext sichtbar und wird meist vom CMS oder einem SEO-Plugin erzeugt. Wichtig: Der Tag muss im Head stehen. Ein noindex im Body wird ignoriert – außer der Browser oder Parser verschiebt ihn beim Rendering nach oben, was bei fehlerhaftem HTML vorkommt.²

Quelle 2: X-Robots-Tag im HTTP-Antwortheader. X-Robots-Tag: noindex wird vom Webserver mitgeschickt, bevor überhaupt Inhalt ausgeliefert wird. Diese Quelle steht nicht im Quelltext und ist beim normalen Betrachten der Seite unsichtbar. Sie wird typischerweise in der Serverkonfiguration gesetzt, per .htaccess, in der nginx-Konfiguration oder programmatisch in der Anwendung. Der Header ist die einzige Möglichkeit, Nicht-HTML-Dokumente wie PDF, Bilder oder XML mit noindex zu versehen – dort existiert kein Head, in den ein Meta-Tag passen würde.

Beide Quellen können gleichzeitig aktiv sein. Wenn sie sich widersprechen, gilt die restriktivere Angabe: Ein noindex im Header setzt sich gegen ein index im Meta-Tag durch. Deshalb reicht der Blick in den Quelltext nicht aus, um einen noindex auszuschließen.

Wie gefährlich ist der Fehler?
Kritisch ist der Einzelfall: Eine Seite mit noindex kann unter keinen Umständen ranken. Es gibt keine Teilwirkung, keine schwächere Position, kein gelegentliches Auftauchen. Die Seite ist weg. Wenn eine wichtige Seite in dieser Liste steht, ist das der wirkungsvollste Einzelfehler, den technische SEO kennt.

Kritisch ist auch ein schnelles Anwachsen des Fehlers. Wenn es sich nicht um eine geplante Maßnahme handelt, dann führt das Deindexieren sehr wahrscheinlich zu Rankingverlusten.

Was Sie selbst tun können

• Gehen Sie die Liste durch und markieren Sie jede URL, die eigentlich ranken soll. Alles andere ist Normalzustand.
• Prüfen Sie beide Quellen getrennt. Erst den Quelltext auf das Meta-Tag, dann den HTTP-Antwortheader auf X-Robots-Tag. Der Quelltext allein beweist nichts.
• Suchen Sie in der .htaccess oder Serverkonfiguration nach X-Robots-Tag. Achten Sie auf Regeln, die per Dateityp oder Verzeichnis greifen
• Prüfen Sie in WordPress unter Einstellungen → Lesen, ob „Suchmaschinen davon abhalten, diese Website zu indexieren“ aktiv ist. Diese eine Checkbox setzt den noindex global.
• Kontrollieren Sie die Einstellungen des SEO-Plugins auf Ebene des Inhaltstyps. Ein noindex für „alle Beiträge dieses Typs“ wirkt sich auf hunderte Seiten aus, ohne dass es in der Einzelansicht auffällt.

Wichtig: Sperren Sie eine noindex-Seite nicht zusätzlich per robots.txt. Google muss die Seite abrufen können, um den noindex überhaupt zu lesen. Bei gleichzeitiger Sperre bleibt eine bereits indexierte Seite im Index. Mehr dazu im nächsten Abschnitt „Indexiert, obwohl durch robots.txt blockiert“

Tools

• Entwicklertools (F12) → Elemente → Strg+F → noindex: findet das Meta-Tag im gerenderten DOM
• Entwicklertools → Netzwerk → erste Zeile anklicken → „Header“ → „Antwortheader“: Hier steht der X-Robots-Tag. Das ist die einzige Stelle im Browser, an der er sichtbar wird
• Rechtsklick → Seitenquelltext anzeigen und mit dem DOM vergleichen: Weicht beides ab, wird der noindex per JavaScript gesetzt oder entfernt – Google bewertet den gerenderten Stand
• Search Console → URL-Prüfung → „Live-URL testen“: Der Abschnitt „Indexierung“ nennt die Sperre und deren Herkunft, ohne dass Sie beide Quellen einzeln prüfen müssen
• Search Console → URL-Prüfung → „Gecrawlte Seite ansehen“ → HTTP-Antwort: zeigt die vollständigen Header, die Google beim letzten Abruf erhalten hat
• Browser: Bei PDF und anderen Nicht-HTML-Dateien führt ausschließlich der Weg über die Antwortheader zum Ziel – ein Quelltext existiert dort nicht

Bei jedem Verdachtsfall gilt dieselbe Reihenfolge: erst (gerenderter) Quelltext, dann Header.

Indexiert, obwohl durch robots.txt-Datei blockiert

Was es bedeutet
Die URL steht im Index, obwohl Google sie momentan nicht abrufen darf. Das klingt widersprüchlich, folgt aber der Systemlogik: Die robots.txt steuert das Crawling, nicht die Indexierung. Google hat die URL aus anderen Quellen kennengelernt – über interne oder externe Links, eine Sitemap oder eine ältere Indexierung – und hält sie für relevant genug, um sie aufzunehmen, obwohl der Inhalt unbekannt ist.

Google kennt nur die URL selbst, den Ankertext der eingehenden Links und ihr Umfeld. Es gibt keinen Title aus dem Dokument, keine Meta Description, keinen bewerteten Inhalt. In den Suchergebnissen erscheint deshalb häufig ein aus der URL abgeleiteter Title und statt der Description ein Hinweis, dass keine Informationen verfügbar sind.

Wie gefährlich ist der Fehler?
Die Meldung steht im Bericht unter den indexierten Seiten mit Warnung, nicht unter den Fehlern. In vielen Fällen ist der Zustand kosmetisch. Wenn Sie jedoch Seiten wissentlich deindexieren möchten, dann muss Google diese Seiten auch aufrufen und auswerten.

Was Sie selbst tun können

• Ziel: Seite soll ranken. Sperre in der robots.txt entfernen, damit Google den Inhalt lesen kann. Danach Indexierung anfordern.
• Ziel: Seite soll aus dem Index verschwinden. Sperre in der robots.txt entfernen und stattdessen noindex setzen. Google muss die Seite abrufen dürfen, um die Anweisung zu lesen. Nach der Deindexierung kann die Sperre wieder gesetzt werden – vorher nicht.
• Ziel: Seite soll weder gecrawlt noch gefunden werden. Zugriff serverseitig unterbinden, etwa per Authentifizierung. Die robots.txt ist kein Schutzmechanismus, sondern eine Bitte.
• Entfernen Sie gesperrte URLs aus der XML-Sitemap. Ein Sitemap-Eintrag ist ein Indexierungssignal und widerspricht der Sperre direkt.
• Für dringende Fälle, z.B. bei rechtlichen Gründen: Das Tool zum Entfernen von URLs in der Search Console blendet die Seite für rund sechs Monate aus. Das verschafft Zeit das Problem suchmaschinenkonform zu lösen.
• Prüfen Sie, ob die Sperre überhaupt nötig ist. In vielen Fällen ist ein noindex das passendere Werkzeug und die robots.txt-Regel historisch gewachsen.

Typische Ursachen und Seitentypen
Technisch steht am Anfang fast immer die Verwechslung der beiden Steuerungsebenen: robots.txt für Crawling, Meta-Robots für Indexierung. Wer beides gleichsetzt, produziert diesen Zustand zwangsläufig.

Der zweite Klassiker ist die Reihenfolge bei Aufräumarbeiten. Eine Seite ist indexiert, soll weg, und wird per robots.txt gesperrt. Damit ist der noindex, der oft gleichzeitig gesetzt wird, für Google unlesbar. Das Ergebnis ist genau diese Meldung – und sie löst sich nie von selbst.

Dritte Ursache sind Sperren auf Verzeichnisebene, die stark verlinkte Bereiche treffen. Ein Disallow: /suche/ bei gleichzeitig prominenter interner Verlinkung auf Suchergebnisse führt dazu, dass Google massenhaft URLs kennt, die er nicht lesen darf.

ools

• Google-Suche: site:ihredomain.de/pfad/ zeigt die betroffenen URLs so, wie Nutzer sie sehen. Der fehlende Description-Text ist das eindeutige Erkennungsmerkmal
• Search Console → URL-Prüfung: Der Abschnitt „Crawling“ nennt die blockierende Regel, der Abschnitt „Indexierung“ bestätigt gleichzeitig die Aufnahme in den Index
• Search Console → Einstellungen → robots.txt-Bericht: zeigt die aktuell gültige Datei und ihre Regeln
• Browser: ihredomain.de/robots.txt aufrufen und die betreffende Disallow-Zeile lokalisieren
• Entwicklertools (F12) → Elemente → Strg+F → noindex: prüft, ob ein noindex existiert, den Google wegen der Sperre gar nicht lesen kann. Diese Kombination ist der eigentliche Auslöser
• Search Console → Bericht „Seiten“ → Beispiel-URLs exportieren und nach Pfadmuster gruppieren, um die verantwortliche Regel zu identifizieren

Seite ohne Inhalt indexiert

Was es bedeutet
Google hat die URL abgerufen, in den Index aufgenommen – und beim Rendern keinen verwertbaren Inhalt vorgefunden. Anders als bei der robots.txt-Sperre lag hier kein Zugriffshindernis vor. Der Abruf war erfolgreich, das Ergebnis war leer.

Technisch führen drei verschiedene Zustände zu dieser Meldung, die sauber auseinandergehalten werden müssen:

Erstens: Das Dokument ist tatsächlich leer. Der Server liefert Status 200, das ausgelieferte HTML enthält aber keinen Hauptinhalt. Typisch bei Platzhalterseiten, fehlgeschlagenen Datenbankabfragen, die statt eines Fehlers eine leere Hülle zurückgeben, oder Templates, die ohne den erwarteten Datensatz aufgerufen werden.

Zweitens: Der Inhalt entsteht erst clientseitig und das Rendering scheitert. Das initiale HTML enthält nur ein leeres Container-Element, der Inhalt wird per JavaScript nachgeladen. Google rendert zwar, aber nicht garantiert vollständig: Ein Skriptfehler, eine per robots.txt gesperrte JavaScript-Datei, ein Timeout oder ein API-Aufruf, der beim Crawl-Zeitpunkt nicht antwortet, führen dazu, dass der gerenderte Stand leer bleibt.

Drittens: Das Format ist nicht lesbar. Google konnte das Dokument nicht interpretieren, weil es fehlerhaft ausgeliefert wird. Häufige Fälle: ein falscher Content-Type-Header, eine als HTML deklarierte Datei, die tatsächlich etwas anderes ist, oder ein PDF, dessen Text ausschließlich als Bild vorliegt und ohne Texterkennung keine auslesbaren Zeichen enthält.

Wie gefährlich ist der Fehler?
Hoch, sobald eine Seite betroffen ist, die ranken soll. Eine indexierte Seite ohne Inhalt hat keine Signale außer der URL selbst und den eingehenden Links. Sie steht damit faktisch außerhalb des Wettbewerbs, taucht aber in der Search Console unter den indexierten Seiten auf.

Geführlich ist auch Szenario 2: Die Seite funktioniert im Browser einwandfrei, Sie sehen den Text, Besucher sehen den Text, nur Google sieht ihn nicht. Ohne Blick auf die gerenderte Version bleibt das unentdeckt. Trifft der Zustand ein ganzes Template, betrifft er sofort alle Seiten dieses Typs – also potenziell den gesamten Produktkatalog oder das komplette Blog.

Was Sie selbst tun können

• Öffnen Sie die betroffene URL im Browser. Sehen Sie Inhalt, liegt Zustand 2 oder 3 vor. Sehen Sie keinen, ist es Zustand 1.
• Vergleichen Sie ausgelieferten Quelltext und gerendertes DOM. Steht der Haupttext nur im DOM, entsteht er clientseitig – genau der kritische Fall.
• Deaktivieren Sie JavaScript und laden Sie die Seite neu. Was übrig bleibt, entspricht grob dem, was Google im ersten Schritt sieht.
• Prüfen Sie, ob JavaScript- und CSS-Dateien per robots.txt gesperrt sind. Eine gesperrte Skriptdatei verhindert das Rendering vollständig.
• Prüfen Sie die Konsole auf Skriptfehler. Ein Fehler vor dem Rendern des Hauptinhalts lässt die Seite leer.

Typische Ursachen und Seitentypen
Die dominierende technische Ursache ist clientseitiges Rendering ohne serverseitigen Fallback – Single-Page-Anwendungen und Frontends auf JavaScript-Basis, bei denen das initiale HTML nur ein Gerüst enthält. Erschwerend wirken Abhängigkeiten von externen Diensten: Wenn der Inhalt aus einer API stammt, die beim Crawl-Zeitpunkt langsam oder nicht erreichbar ist, bleibt die Seite leer.

Zweite Gruppe sind Ausgabefehler im Backend: Templates, die bei fehlendem Datensatz eine leere Seite statt eines Fehlers rendern, sowie Caching-Schichten, die versehentlich eine leere Antwort speichern und ausliefern.

Dritte Gruppe sind Zugriffsschranken, die keinen Statuscode setzen: Cookie-Banner oder Bezahlschranken, die den Inhalt per JavaScript überlagern oder aus dem DOM entfernen, ohne dass der Server einen 401 oder 403 sendet.

Tools

• Search Console → URL-Prüfung → „Live-URL testen“ → „Gerenderte Seite testen“: Screenshot und gerendertes HTML zeigen exakt das, worauf Googles Bewertung beruht. Das ist der zentrale Test bei dieser Meldung
• Search Console → URL-Prüfung → „Weitere Informationen“ → „Seitenladeprobleme“: listet Ressourcen, die beim Rendern nicht geladen werden konnten, inklusive Grund
• Rechtsklick → Seitenquelltext anzeigen und mit Entwicklertools (F12) → Elemente vergleichen: Die Differenz zwischen beiden zeigt, wie viel Inhalt erst clientseitig entsteht
• Entwicklertools → Einstellungen (Zahnrad) → JavaScript deaktivieren, dann neu laden: simuliert den Zustand vor dem Rendering
• Entwicklertools → Konsole: Skriptfehler, die das Rendering abbrechen
• Entwicklertools → Netzwerk → Antwortheader → Content-Type: prüft, ob das Dokument korrekt als HTML deklariert ist
• Entwicklertools → Netzwerk → Filter „Fetch/XHR“: zeigt, ob der Inhalt über einen nachgelagerten Aufruf kommt und ob dieser erfolgreich ist

Duplikat – Google hat eine andere Seite als der Nutzer als kanonische Seite bestimmt

Was es bedeutet
Sie haben ein Canonical Tag gesetzt, Google hat ihn gelesen und ist ihm nicht gefolgt. Stattdessen wurde eine andere URL als kanonische Version bestimmt und indexiert. Ihr Wunsch wurde damit überstimmt.

Das ist gewollt: Das rel=canonical ist ein HInweis, keine Anweisung. Google gewichtet es zusammen mit anderen Signalen – interne Verlinkung, Sitemap-Einträge, hreflang-Angaben, Weiterleitungen, URL-Struktur, externe Links und die Frage, welche Version inhaltlich vollständiger ist. Widersprechen sich diese Signale, entscheidet die Gesamtlage, nicht der Tag allein.

Ein Widerspruch entsteht typischerweise so: Sie kanonisieren Seite A auf Seite B, verlinken intern aber überwiegend A, führen A in der Sitemap und lassen externe Links auf A zeigen. Alle Signale außer dem Canonical sprechen dann für A – und Google folgt der Mehrheit.

Wie gefährlich ist der Fehler?
Niedrig bis mittel. In der harmloseren Variante hat Google schlicht die bessere Version gewählt, etwa die parameterlose statt der getrackten URL. Der Effekt ist dann identisch mit Ihrer Absicht, nur auf anderem Weg erreicht.

Was Sie selbst tun können

• Prüfen Sie zuerst über die URL-Prüfung, welche URL Google gewählt hat. Entspricht sie Ihrer Absicht, ist kein Eingriff nötig – nur Ihre Konfiguration ist dann überflüssig.
• Prüfen Sie, ob Ihr Canonical technisch überhaupt lesbar ist: genau ein Tag im Head, absolute URL, kein zweites Canonical im gerenderten DOM, kein widersprechender HTTP-Header.
• Räumen Sie die Signallage auf, statt den Tag zu wiederholen. Ein zweites Canonical ändert nichts, wenn die übrigen Signale dagegenstehen.
• Verlinken Sie intern ausschließlich die Wunsch-URL. Interne Verlinkung ist nach dem Canonical das stärkste Signal und lässt sich vollständig kontrollieren.
• Nehmen Sie ausschließlich die Wunsch-URL in die Sitemap auf.
• Prüfen Sie, ob die Wunsch-URL überhaupt indexierbar ist. Trägt sie noindex, liefert sie einen Fehlercode oder leitet sie weiter, wird Google ihr nicht folgen können.

Typische Ursachen und Seitentypen
Technisch dominieren vier Muster.

• Erstens widersprüchliche interne Signale: Canonical zeigt auf B, alles andere auf A.
• Zweitens Canonicals in Ketten oder Kreisen – A zeigt auf B, B zeigt auf C oder zurück auf A. Google löst solche Konstruktionen eigenständig auf, meist nicht in Ihrem Sinn.
• Drittens Canonicals, die per JavaScript gesetzt oder überschrieben werden, sodass Quelltext und gerenderter Stand abweichen.
• Viertens Verweise auf ungeeignete Ziele: eine URL mit noindex, eine weiterleitende URL, eine 404-Seite oder eine Seite mit deutlich weniger Inhalt.

Tools

• Search Console → URL-Prüfung → Abschnitt „Indexierung“: „Vom Nutzer angegebene kanonische URL“ und „Von Google ausgewählte kanonische URL“ stehen dort direkt untereinander. Weichen sie ab, ist der Widerspruch bestätigt
• Entwicklertools (F12) → Elemente → Strg+F → canonical: prüft das Ziel im gerenderten DOM und deckt gleichzeitig auf, ob mehrere Canonicals vorhanden sind. Bei zwei Tags ignoriert Google in der Regel beide
• Rechtsklick → Seitenquelltext anzeigen und mit dem DOM vergleichen: zeigt clientseitig gesetzte oder überschriebene Canonicals
• Entwicklertools → Netzwerk → Antwortheader auf Link: rel="canonical" prüfen: ein Header-Canonical kann dem HTML-Tag widersprechen
• Browser: die im Canonical genannte Ziel-URL aufrufen und prüfen, ob sie Status 200 liefert, indexierbar ist und ein selbstreferenzierendes Canonical trägt
• Entwicklertools → Elemente → Strg+F → nach der Wunsch-URL suchen: zeigt, ob die Seite intern tatsächlich so verlinkt wird, wie sie kanonisiert ist
• Google-Suche: site:ihredomain.de mit einem Textfragment der Seite zeigt, welche Version tatsächlich im Index steht

Gefunden – zurzeit nicht indexiert

Google kennt die URL, hat sie jedoch noch nicht abgerufen. Der Crawl war geplant, wurde aber zurückgestellt. Es liegt kein Fehler vor, es gibt weder ein Statuscode-Problem noch eine Sperre oder ein noindex. Google hat sich lediglich entschieden, diese URL vorerst nicht zu besuchen.

Die Meldung setzt eine Stufe früher an als „Gecrawlt – zurzeit nicht indexiert“. Dort wurde der Inhalt gelesen und bewertet, hier gibt es noch keinen Inhalt zu bewerten – Google kennt nur die URL selbst und ihr Umfeld.

In der Dokumentation nennt Google zwei Gründe: Entweder hätte der Abruf den Server überlastet oder die Warteschlange war zu voll. Beide Gründe verweisen auf dasselbe Konzept, nämlich die Crawl-Kapazität, die Google einer Domain zuweist. Diese ergibt sich aus zwei Faktoren: Einerseits, wie viel Last der Server verträgt, gemessen an Antwortzeiten und Fehlerquote, und andererseits, wie viel Aufmerksamkeit Google der Domain zutraut, abgeleitet aus Aktualität, Qualität und Nachfrage. Der erste Faktor stellt eine technische Grenze dar, der zweite eine inhaltliche Gesamtbewertung.

Wie gefährlich ist der Fehler?
Bei niedriger Zahl und frischen URLs unkritisch. Neue Seiten durchlaufen diesen Zustand regelmäßig für Stunden oder Tage, bevor der Crawl erfolgt. Kritisch wird es in drei Szenarien:

• Erstens bei der Dauer: Steht eine URL Wochen später unverändert in dieser Liste, war es keine Verzögerung, sondern eine Entscheidung. Google hat die URL dann faktisch abgewertet.
• Zweitens beim Anteil: Betrifft die Meldung einen erheblichen Teil der Website, liegt fast immer ein strukturelles Problem vor. Entweder ist der Server zu langsam, oder es existieren deutlich mehr URLs, als die Domain an Crawl-Kapazität rechtfertigt. Der zweite Fall ist bei Shops und Portalen der Normalfall – Filterkombinationen erzeugen beliebig viele URLs, die Kapazität wächst nicht mit.
• Drittens beim Inhaltstyp: Betrifft die Meldung neue Produkte oder aktuelle Artikel, entsteht ein direkter Umsatz- oder Reichweitenverlust, weil die Inhalte in ihrem relevanten Zeitfenster nicht auffindbar sind.

Was Sie selbst tun können

• Prüfen Sie zuerst das Alter der URLs. Alles unter zwei Wochen ist regulär und braucht keine Maßnahme.
• Sehen Sie in die Crawling-Statistiken. Steigende durchschnittliche Antwortzeiten sind die häufigste technische Ursache und lassen sich direkt beheben.
• Reduzieren Sie Serverantwortzeiten. Unter 200 Millisekunden für das HTML-Dokument ist ein realistisches Ziel; alles über 600 Millisekunden bremst den Crawl messbar.
• Zählen Sie Ihre indexierbaren URLs und vergleichen Sie sie mit der Zahl der Seiten, die Sie tatsächlich im Index haben wollen. Weichen beide um ein Vielfaches ab, ist die URL-Menge das Problem, nicht die Kapazität.
• Reduzieren Sie die crawlbare URL-Menge: Filterkombinationen sperren, Parametervarianten kanonisieren, Sortierseiten aus der Verlinkung nehmen. Weniger URLs bedeuten mehr Kapazität pro URL.
• Verbessern Sie die interne Verlinkung der betroffenen Seiten. URLs, die nur in der Sitemap stehen und sonst nirgends verlinkt sind, haben die geringste Priorität.

Tools

• Search Console → Einstellungen → Crawling-Statistiken: Die zentrale Stelle. Zeigt Crawl-Anfragen pro Tag, durchschnittliche Antwortzeit und Antwortverteilung. Sinkende Anfragen bei steigender Antwortzeit sind das eindeutige Muster
• Search Console → Crawling-Statistiken → „Nach Antwort“ und „Nach Zweck“: trennt Abrufe für Erkennung von Abrufen zur Aktualisierung und zeigt, wie viel Kapazität in Fehler fließt
• Search Console → Bericht „Seiten“ → Beispiel-URLs exportieren und nach Pfadmuster gruppieren: identifiziert, welcher Bereich die Masse erzeugt
• Entwicklertools (F12) → Netzwerk → Spalte „Zeit“ beim Hauptdokument: misst die Serverantwortzeit, die Google bewertet
• Entwicklertools → Netzwerk → „Timing“ beim Hauptdokument → Wert „Warten (TTFB)“: der eigentlich relevante Messwert, unabhängig von Bildern und Skripten
• Browser: ihredomain.de/sitemap.xml aufrufen und die enthaltene URL-Menge mit der Zahl indexierter Seiten vergleichen
• Google-Suche: site:ihredomain.de als grober Abgleich, wie viele URLs tatsächlich im Index stehen

Der Unterschied zur Nachbarmeldung entscheidet über die Maßnahme: „Gefunden“ ist ein Kapazitätsproblem und wird technisch gelöst – schnellerer Server, weniger URLs, bessere Verlinkung. „Gecrawlt“ ist ein Bewertungsproblem und wird inhaltlich gelöst.

Gecrawlt – zurzeit nicht indexiert

Was es bedeutet
Google hat die URL abgerufen, den Inhalt gelesen, gerendert und bewertet – und entschieden, sie nicht in den Index aufzunehmen. Technisch ist alles in Ordnung: Statuscode 200, kein noindex, keine Sperre, kein Duplikatskonflikt. Die Entscheidung fiel nach der Bewertung des Inhalts.

Das ist die schwierigste Meldung im gesamten Bericht, weil sie keine technische Ursache benennt. Google nennt keinen Grund und stellt keine Diagnose bereit. Die Meldung sagt lediglich: geprüft und für nicht aufnahmewürdig befunden – zumindest im Moment.

Wie gefährlich ist der Fehler?
Abhängig vom Anteil und davon, welche Seiten betroffen sind. Ein Grundrauschen ist normal. Jede gewachsene Website hat Seiten mit geringem Eigenwert – Tag-Übersichten, dünne Archivseiten, Varianten mit minimalem Unterschied. Dass diese nicht indexiert werden, ist eine sinnvolle Entscheidung und kein Handlungsauftrag.

Kritisch wird es in drei Konstellationen.

Erstens, wenn Kerninhalte betroffen sind: Produktseiten, Leistungsseiten, redaktionelle Artikel mit Rechercheaufwand. Hier bewertet Google Inhalte als verzichtbar, in die Sie investiert haben.

Zweitens, wenn der Anteil an der Gesamtzahl hoch ist. Ein signifikanter Teil der Website unter dieser Meldung deutet auf ein systematisches Qualitäts- oder Strukturproblem hin, nicht auf Einzelfälle. Häufig steckt dahinter Skalierung ohne Substanz – hunderte Seiten aus einem Template mit ausgetauschten Variablen.

Drittens, wenn die Zahl über Monate steigt. Das ist ein Bewertungstrend und betrifft dann meist auch die Rankings der indexierten Seiten.

Diese Meldung ist häufig eine verdeckte Duplikatsmeldung. Wenn eine Seite inhaltlich zu nah an einer bereits indexierten liegt, ohne formal als Duplikat eingestuft zu werden, landet sie hier. Das erklärt viele Fälle, in denen der Inhalt für sich betrachtet ordentlich wirkt.

Was Sie selbst tun können

• Schließen Sie zuerst die technischen Kandidaten aus. Prüfen Sie die gerenderte Version: Steht der Hauptinhalt tatsächlich dort, wo Google ihn sieht? Ein leerer gerenderter Stand erklärt die Nichtindexierung sofort.
• Sortieren Sie die Liste nach Seitentyp. Betrifft die Meldung eine Kategorie geschlossen, liegt es am Template und nicht am Einzeltext.
• Suchen Sie gezielt nach Kerninhalten in der Liste. Nur diese rechtfertigen Aufwand.
• Prüfen Sie auf Ähnlichkeit zu bestehenden Seiten. Nehmen Sie einen charakteristischen Satz und suchen Sie ihn per site:-Abfrage auf Ihrer eigenen Domain. Mehrere Treffer zeigen die verdeckte Dublette.

Tools

• Search Console → URL-Prüfung → „Live-URL testen“ → „Gerenderte Seite testen“: Der erste Schritt. Schließt die technische Ursache aus, bevor Sie inhaltlich suchen
• Search Console → Bericht „Seiten“ → Beispiel-URLs exportieren und nach Pfadmuster gruppieren: trennt Template-Probleme von Einzelfällen
• Google-Suche: site:ihredomain.de "charakteristischer Satz" deckt verdeckte Dubletten auf der eigenen Domain auf
• Entwicklertools (F12) → Elemente: Umfang des Hauptinhalts im Verhältnis zu Navigation und Footer beurteilen
• Rechtsklick → Seitenquelltext anzeigen, Vergleich mit dem DOM: zeigt, wie viel Inhalt erst clientseitig entsteht
• Entwicklertools → Strg+F im DOM nach der URL suchen, ausgehend von thematisch verwandten Seiten: prüft, ob die Seite intern überhaupt verlinkt ist
• Search Console → Leistung → Seiten: Vergleich, welche ähnlichen Seiten stattdessen Impressionen erhalten

1. Auch hier: Es kommt auf die Inhalte an, ggf. können die Seite auch mit „noindex“ sauber deindexiert werden. [↩]
2. Oder ein Script schreibt die noindex-Information nach dem rendern in den <head> [↩]