Bericht zur Seitenindexierung (GSC)

TL;DR — Der Bericht zur Seitenindexierung in Google Search Console zeigt dir, wie viele deiner Seiten Google indexiert hat (sie können in der Suche erscheinen) und wie viele nicht indexiert sind. Bei den nicht indexierten Seiten nennt er den Grund. Früher hieß er Bericht zur Indexabdeckung. „Nicht indexiert“ klingt beunruhigend, ist es aber häufig nicht — viele dieser URLs sollen draußen bleiben.

Was der Bericht zur Seitenindexierung ist

Wenn du Google Search Console öffnest und im linken Menü unter Indexierung auf Seiten klickst, landest du im Bericht zur Seitenindexierung. Google beschreibt ihn knapp: Er lässt dich “see which pages Google can find and index on your site, and learn about any indexing problems encountered.” (Übersetzung) „Erkennen, welche Seiten Google auf deiner Website finden und indexieren kann, und mehr über aufgetretene Indexierungsprobleme erfahren.“

Er teilt alle Google bekannten URLs deiner Website in zwei Gruppen:

• Indexiert — diese Seiten können in der Google-Suche erscheinen.
• Nicht indexiert — diese Seiten sind nicht im Index, weil entweder etwas nicht funktioniert oder ein guter Grund vorliegt (Duplikat, Sperre, noindex und so weiter).

Darunter führt die Tabelle „Warum Seiten nicht indexiert werden“ die Gründe und die Anzahl der betroffenen URLs auf. Mit dieser Tabelle arbeitest du tatsächlich.

Warum „nicht indexiert“ meist keine Krise ist

Viele übersehen beim ersten Öffnen des Berichts: Nicht indexiert bedeutet nicht defekt. Google sagt es in der Hilfe ausdrücklich: “Not indexed is not necessarily bad.” (Übersetzung) „Nicht indexiert ist nicht zwangsläufig schlecht.“ Du solltest nicht erwarten, dass jede URL deiner Website indexiert wird. Tag-Seiten, gefilterte Produktlisten, alte weitergeleitete URLs und Duplikate auszulassen bedeutet oft, dass der Bericht genau das Richtige zeigt.

Gerate bei einer großen Zahl nicht indexierter Seiten deshalb nicht in Panik. Lies zuerst, welche Gründe dahinterstehen, bevor du etwas änderst.

Für die Prüfung einer einzelnen Seite ist es das falsche Werkzeug

Der Bericht ist eine Übersicht über deine gesamte Website. Wenn du wissen willst, ob eine bestimmte URL indexiert ist, nutzt du stattdessen die URL-Prüfung (die Suchleiste oben in Search Console). Google sagt das ausdrücklich. Der Bericht ist für Trends und Gruppen; die URL-Prüfung untersucht jeweils eine einzelne Seite.

Brauchst du ihn überhaupt?

Hat deine Website weniger als 500 Seiten, sagt Google, du “probably don’t need to use this report” (Übersetzung) „benötigst diesen Bericht wahrscheinlich nicht“ — eine Suche nach site:yoursite.com genügt für Stichproben. Bei größeren Websites, auf denen du nicht alles überblicken kannst, spielt der Bericht seine Stärke aus.

Möchtest du die vollständige Fassung — jede Spalte, alle 16 Status, die Funktionsweise von Fehlerbehebung überprüfen und die Diagnose eines plötzlichen Rückgangs indexierter Seiten? Wechsle zum Tab Advanced.

TL;DR — Der Bericht zur Seitenindexierung (früher Indexabdeckung; Seiten unter Indexierung in GSC) ist eine aggregierte Ansicht aller Google bekannten URLs deiner Property. Er teilt sie in Indexiert und Nicht indexiert und gruppiert Letztere in der Tabelle „Warum Seiten nicht indexiert werden“ nach Ursache. Für einzelne Seiten nutzt du die URL-Prüfung. Wichtig ist: Nicht indexiert ist nicht zwangsläufig schlecht — Canonical-/Duplikatseiten, noindex, robots.txt und beabsichtigte 404-Antworten sind korrekte Ergebnisse. Google erwartet nur deine Canonical-Seiten im Index. Filtere nach Quelle = Website, arbeite die vorsortierte Tabelle von oben nach unten ab und nutze Fehlerbehebung überprüfen (typisch etwa zwei Wochen), um einen neuen Crawl anzufordern. Der Bericht hängt der Realität hinterher. Websites unter 500 Seiten benötigen ihn wahrscheinlich nicht.

Was der Bericht tatsächlich ist (und wie er früher hieß)

Googles Ein-Satz-Definition ist am klarsten: Der Bericht lässt dich “see which pages Google can find and index on your site, and learn about any indexing problems encountered.” (Übersetzung) „Erkennen, welche Seiten Google auf deiner Website finden und indexieren kann, und mehr über aufgetretene Indexierungsprobleme erfahren.“ Genauer: Er “shows the Google indexing status of all URLs that Google knows about in your property.” (Übersetzung) „zeigt den Google-Indexierungsstatus aller URLs, die Google in deiner Property kennt.“ Er ist ein aggregierter, Property-weiter Bericht, kein Werkzeug für einzelne URLs.

Wer seit einigen Jahren SEO betreibt, kennt ihn als Bericht zur Indexabdeckung. Google benannte ihn 2022 in Seitenindexierung um (in der linken Navigation steht „Seiten“). Deshalb sprechen ältere Leitfäden und viele Menschen weiterhin von „Abdeckung“. Es ist derselbe Bericht. Das ist wichtig, damit Suchende unter dem alten Namen wissen, dass sie richtig sind. Die Umbenennung fiel erstmals in einer Demo auf der Google I/O 2022 auf und wurde später im Jahr ausgerollt. Bereits im Januar 2021 hatte ein Datenqualitäts-Update mehrere Status überarbeitet; darum stimmen alte Screenshots teilweise nicht mehr mit der heutigen Oberfläche überein.

So liest du den Bericht

Die Übersicht besteht aus einigen Teilen, die du vor dem Klicken verstehen solltest.

Indexiert und Nicht indexiert. Das sind die beiden Summen über dem Diagramm. Google nennt sie “complete and accurate from Google’s perspective, but small discrepancies can occur for various reasons” (Übersetzung) „aus Googles Sicht vollständig und genau, wobei aus verschiedenen Gründen kleine Abweichungen auftreten können“. Erwarte also nicht, dass sie exakt deiner URL-Anzahl entsprechen. Über „Daten zu indexierten Seiten ansehen“ erhältst du die historische Anzahl und eine Stichprobe von bis zu 1 000 indexierten URLs.

Die Tabelle „Warum Seiten nicht indexiert werden“. Sie ist das Herzstück. Laut Google “shows issues that prevented URLs from being indexed on your site,” (Übersetzung) „zeigt [sie] Probleme, die verhindert haben, dass URLs deiner Website indexiert wurden“. Die wichtigsten Probleme stehen oben. Beginne oben — die Reihenfolge ist bereits eine Prioritätenliste.

Die Spalte Quelle — dein Reparaturfilter. Jedes Problem stammt entweder von Google oder von der Website. Googles Anleitung ist eindeutig: “The Source value in the table shows whether the source of the issue is Google or the website. In general, you can fix only issues where the source is listed as ‘Website’.” (Übersetzung) „Der Quellenwert in der Tabelle zeigt, ob die Ursache des Problems Google oder die Website ist. Im Allgemeinen kannst du nur Probleme beheben, deren Quelle als ‚Website‘ angegeben ist.“ Quelle = Website zusammen mit dem Prüfstatus „Fehlgeschlagen“ oder „Nicht gestartet“ ist deine echte Aufgabenliste. Von Google verursachte Status — etwa ein von Google zusammengeführtes Duplikat — musst du meist nicht „beheben“.

Die Tabelle „Nutzerfreundlichkeit verbessern“. Eine gesonderte Tabelle für “issues that didn’t prevent page indexing, but we recommend that you fix them.” (Übersetzung) „Probleme, welche die Seitenindexierung nicht verhindert haben, deren Behebung wir aber empfehlen.“ Das sind Warnungen, keine Blocker.

Der Sitemap-Filter. Über dem Diagramm kannst du den Bericht auf Alle bekannten Seiten, Alle eingereichten Seiten, Nur nicht eingereichte Seiten oder eine bestimmte Sitemap beschränken. Hinweis: “A URL is considered to be submitted by a sitemap even if it was also discovered through some other mechanism.” (Übersetzung) „Eine URL gilt als über eine Sitemap eingereicht, auch wenn sie zusätzlich auf anderem Weg entdeckt wurde.“ Dieser Filter ist wirklich nützlich — dazu später mehr.

Die Beispiel-URL-Listen sind begrenzt. Öffnest du einen Status, ist die Stichprobe “limited to 1,000 items, and isn’t guaranteed to show all URLs in a given status, even when less than 1,000 items.” (Übersetzung) „auf 1 000 Elemente begrenzt und zeigt nicht garantiert alle URLs eines Status, selbst wenn es weniger als 1 000 Elemente gibt.“ Behandle die Beispiele als Stichprobe, nicht als vollständigen Export.

Triage in zehn Minuten. Beschränke den Bericht auf die Sitemap deines gewünschten URL-Inventars. Suche zuerst nach einer unerwarteten Änderung der Summen — ein Rückgang oder Anstieg ist dringlicher als ein stabiler Wert. Filtere auf Quelle = Website. Priorisiere dann Muster in geschäftskritischen Vorlagen vor Einzelfällen. Behebe das gesamte Muster, nicht nur eine URL, bevor du die Fehlerbehebung überprüfen lässt.

Bericht und URL-Prüfung — nutze das richtige Werkzeug

Google beschreibt den praktischen Unterschied klar: “This report isn’t used to investigate the index status of specific pages. To find the index status of a specific page, use the URL Inspection tool.” (Übersetzung) „Dieser Bericht dient nicht dazu, den Indexierungsstatus einzelner Seiten zu untersuchen. Nutze die URL-Prüfung, um den Indexierungsstatus einer bestimmten Seite zu ermitteln.“

• Bericht zur Seitenindexierung = aggregierte Trends und nach Grund gruppierte Daten für die gesamte Property.
• URL-Prüfung = Live- und Indexstatus einer URL, die von Google gewählte Canonical-URL und die Option „Live-URL testen“.

Wenn dich ein Status verwirrt, nimm eine Beispiel-URL und prüfe sie. Die Werkzeuge sind für den gemeinsamen Einsatz gedacht.

Hinweis zur Verzögerung — der Bericht hinkt hinterher

Der Bericht aktualisiert sich nicht in Echtzeit. Er spiegelt den letzten Crawl jeder URL wider und die Zahlen verändern sich bei erneuten Crawls. Google sagt, er “updates your instance count whenever it crawls a page with known issues, whether or not you explicitly requested fix validation” (Übersetzung) „aktualisiert deine Anzahl betroffener Instanzen bei jedem Crawl einer Seite mit bekannten Problemen, unabhängig davon, ob du ausdrücklich eine Überprüfung angefordert hast“. John Mueller beschrieb den Indexierungsbericht als verzögert: URLs erscheinen im Bericht und werden mit der Zeit indexiert, der Bericht holt also einen bereits veränderten Zustand nach. Reagiere nicht überstürzt auf möglicherweise veraltete Zahlen.

Eine Grenze des Live-Tests der URL-Prüfung: Er bestätigt, ob Google die URL aktuell crawlen und indexieren kann. Er sagt nicht, welche Canonical-URL Google aus einer Duplikatgruppe wählt. Die Canonical-Auswahl ist eine eigene Entscheidung auf Grundlage indexierter Daten. Bei Canonical-/Duplikatstatus ist deshalb das indexierte Ergebnis der URL-Prüfung — nicht der Live-Test — maßgeblich; auch dieses kann deiner letzten Änderung hinterherhinken.

Wohin als Nächstes — alle Status gruppiert

Die Tabelle „Warum Seiten nicht indexiert werden“ ist die Landkarte für den Rest dieses Bereichs. Jeder Status erhält eine eigene Vertiefung (auch in der Seitennavigation). Die Gruppierung folgt dem tatsächlichen Problem, denn je nach Gruppe musst du beheben, bestätigen oder gar nichts tun.

Nicht indexiert — Googles Entscheidung (oft nichts zu beheben)

• Gefunden – zurzeit nicht indexiert — Google kennt die URL, hat sie aber noch nicht gecrawlt. Meist ein Signal für Crawl-Nachfrage oder Website-Qualität, kein Fehler einer einzelnen Seite.
• Gecrawlt – zurzeit nicht indexiert — Google hat die Seite gecrawlt, aber (noch) nicht indexiert. Eine große Gruppe weist oft auf Qualitäts- oder Duplikatprobleme der gesamten Website hin.

Von dir blockiert (beabsichtigt — Absicht bestätigen)

• Durch robots.txt-Datei blockiert — deine robots.txt hat Google den Crawl untersagt.
• Durch „noindex“-Tag ausgeschlossen — Google fand beim Indexierungsversuch eine noindex-Anweisung.

HTTP-Fehler (meist beheben)

• Aufgrund nicht autorisierter Anforderung (401) blockiert — Googlebot sollte sich authentifizieren.
• Aufgrund unzulässiger Anforderung (403) blockiert — dem Crawler wurde der Zugriff verweigert.
• Aufgrund eines anderen 4xx-Problems blockiert — ein anderer benannter 4xx-Fehler.
• Serverfehler (5xx) — der Server lieferte beim Abruf einen 500er-Fehler.
• Nicht gefunden (404) — die URL antwortete mit 404.

Canonical und Duplikate (meist korrekt — gewählte Canonical-URL prüfen)

• Alternative Seite mit richtigem kanonischen Tag — die Seite verweist korrekt auf ihre indexierte Canonical-URL. Alles funktioniert wie vorgesehen.
• Duplikat – vom Nutzer nicht als kanonisch festgelegt — Google gruppierte die URL als Duplikat, wählte eine andere Canonical-URL und du hattest keine angegeben.
• Duplikat – Google hat eine andere Seite als der Nutzer als kanonische Seite bestimmt — du hast eine Canonical-URL angegeben, Google wählte eine andere. Die Lösung ist, deine Signale auszurichten, nicht ein „stärkeres“ Tag zu ergänzen.

Weiterleitungen (eine normal, eine fehlerhaft)

• Seite mit Weiterleitung — eine nicht kanonische URL leitet weiter. Das ist normal; indexiert wird das Ziel.
• Weiterleitungsfehler — eine zu lange Kette, Schleife, leere oder fehlerhafte Ziel-URL oder Überschreitung der maximalen URL-Länge. Diesen Fehler behebst du.

Warnungen (indexiert, aber prüfenswert)

• Indexiert, obwohl durch robots.txt blockiert — Links reichten für die Indexierung. Google kann den Inhalt und ein dort vorhandenes noindex nicht lesen: ein klassischer Unterschied zwischen Crawling und Indexierung.
• Seite ohne Inhalt indexiert — indexiert, obwohl Google keinen sinnvollen Inhalt lesen konnte, häufig wegen Rendering oder Cloaking-ähnlichem Verhalten.

Ich verwende die Statusnamen von Google, damit die Einzelartikel beim Veröffentlichen automatisch verlinkt werden. Das wiederkehrende Muster: Canonical-/Duplikat-, noindex-, robots.txt- und beabsichtigte 404-Gruppen sind häufig korrekt. Google sagt: “You should not expect all URLs on your site to be indexed, only the canonical pages.” (Übersetzung) „Du solltest nicht erwarten, dass alle URLs deiner Website indexiert werden, sondern nur die kanonischen Seiten.“ Verfolge vor allem HTTP- und Weiterleitungsfehler sowie unerwartet große Gruppen „gecrawlt/gefunden – zurzeit nicht indexiert“.

Beheben und überprüfen

Nachdem du echte Probleme mit Quelle = Website behoben hast, lässt du Google erneut prüfen:

1. Behebe zuerst alle Instanzen des Problems auf deiner Website.
2. Öffne die Problemdetails und klicke auf „Fehlerbehebung überprüfen“.
3. Klicke nicht erneut, bis die Prüfung erfolgreich war oder fehlgeschlagen ist.

Zur Dauer: “Validation typically takes up to about two weeks, but in some cases can take much longer, so please be patient.” (Übersetzung) „Die Überprüfung dauert in der Regel bis zu etwa zwei Wochen, in manchen Fällen aber deutlich länger; bitte habe Geduld.“ Die Anfrage durchläuft Nicht gestartet → Gestartet → Sieht gut aus → Bestanden oder Fehlgeschlagen; N/V bedeutet, dass Google die Behebung schon vorher gefunden hat. Du musst die Prüfung nicht anstoßen, denn Google erkennt Änderungen auch selbst, aber du erhältst damit ein nachverfolgbares Ergebnis.

Der Geschwindigkeitstrick: Prüfe eine Teilmenge. Reiche eine Sitemap nur mit deinen wichtigsten Seiten ein, filtere den Bericht danach und fordere dann die Prüfung an. Laut Google kann “a validation request against a subset of your affected URLs can complete faster.” (Übersetzung) „eine Überprüfungsanfrage für eine Teilmenge betroffener URLs schneller abgeschlossen werden“.

Rückgänge, Anstiege und „mehr nicht indexiert als indexiert“ diagnostizieren

Diese von Google genannten Muster prüfe ich zuerst:

• Indexierte Seiten sinken ohne neue Fehler. Vermutlich wurden bestehende Seiten blockiert — durch eine neue robots.txt-Regel, noindex oder eine Anmeldung. Suche nach einem passenden Anstieg in einem nicht indexierten Status.
• Mehr nicht indexiert als indexiert. Häufig blockiert robots.txt einen großen Bereich oder Filter-/Sortierparameter erzeugen viele Duplikate (?type=dress, ?color=green, ?sort=price). Das ist eher ein Problem mit facettierter Navigation und Canonicalisierung als mit der Indexierung.
• Plötzlicher Fehleranstieg. Oft änderte eine Vorlage viele URLs fehlerhaft oder eine eingereichte Sitemap enthält blockierte beziehungsweise mit noindex versehene URLs.

Was du auseinanderhalten solltest

• Indexiert ≠ Ranking. Indexiert bedeutet nur, dass eine Seite in der Suche erscheinen kann. Das Ranking hängt von der Suchanfrage und vielen weiteren Faktoren ab.
• 100 % Abdeckung sind nicht das Ziel. Google erwartet nur Canonical-Seiten im Index; eine gesunde Website hat viele absichtlich nicht indexierte URLs.
• Fehlerbehebung überprüfen indexiert nicht sofort neu. Die Funktion stellt bekannte URLs für einen erneuten Crawl an; plane ungefähr zwei Wochen ein.
• GSC-Daten haben Grenzen. Beispiellisten enden bei 1 000, Summen können leicht abweichen und der Bericht hinkt hinterher. Meine GSC-Datenstudie Anonymized Queries Make Up Nearly Half of GSC Traffic erinnert daran, dass Search Console mächtig, aber unvollständig ist.

Ein Satz zu Bing

Bing hat kein direktes Gegenstück zur „Seitenindexierung“. Am nächsten kommt der Website-Explorer in Bing Webmaster Tools: eine Ordneransicht deiner Website nach indexierten, fehlerhaften, gewarnten und ausgeschlossenen Seiten. Die URL-Prüfung von Bing deckt einzelne URLs ab. Nutze Website-Explorer für die Übersicht und URL-Prüfung für eine Seite.

Diese Seite ist der Hub zum Bericht zur Seitenindexierung; die Status-Vertiefungen liegen darunter. Für die gesamte Pipeline — Finden, Crawling, Rendering, Indexierung und Auslieferung — siehe den Cluster zur Funktionsweise der Suche.

KI-Zusammenfassung

Die Kurzfassung der Advanced-Version:

• Was es ist: der Google-Search-Console-Bericht zur Seitenindexierung (früher Indexabdeckung; „Seiten“ unter „Indexierung“). Er zeigt den Indexierungsstatus jeder Google bekannten URL deiner Property, aufgeteilt in Indexiert und Nicht indexiert.
• Aggregiert, nicht URL-bezogen. Nutze für eine einzelne Seite die URL-Prüfung — Google sagt, der Bericht “isn’t used to investigate the index status of specific pages.” (Übersetzung) „dient nicht dazu, den Indexierungsstatus bestimmter Seiten zu untersuchen“.
• Nicht indexiert ist nicht zwangsläufig schlecht. Canonical-/Duplikatseiten, noindex, robots.txt und beabsichtigte 404-Antworten sind korrekte Ergebnisse; Google erwartet nur Canonical-Seiten im Index.
• Die Tabelle “Why pages aren’t indexed” („Warum Seiten nicht indexiert werden“) ist nach Wichtigkeit vorsortiert. Arbeite sie von oben nach unten ab und filtere nach Quelle = Website, um tatsächlich behebbare Probleme zu sehen.
• 16 Status, gruppiert: Googles nicht indexierte Auswahl (gefunden/gecrawlt – zurzeit nicht indexiert); von dir blockiert (robots.txt, noindex); HTTP-Fehler (401, 403, andere 4xx, 5xx, 404); Canonical/Duplikate; Weiterleitungen (Seite mit Weiterleitung = normal, Weiterleitungsfehler = defekt); Warnungen (trotz robots.txt indexiert, ohne Inhalt indexiert).
• Beheben → Fehlerbehebung überprüfen (typisch etwa zwei Wochen). Beschleunigung: nach einer Sitemap mit deinen wichtigsten Seiten filtern und die Teilmenge prüfen.
• Der Bericht hinkt der Realität hinterher. Mueller bezeichnete ihn als Bericht, der mit der Zeit aufholt. Reagiere nicht überstürzt auf einen veralteten Wert.
• Diagnose: Rückgang indexierter Seiten ohne Fehler = etwas wurde blockiert; mehr nicht indexiert als indexiert = robots.txt-Sperre oder Parameterduplikate; Fehleranstieg = Vorlagenänderung oder fehlerhafte Sitemap.
• Kleine Websites (<500 Seiten) benötigen ihn wahrscheinlich nicht — eine site:-Suche reicht für Stichproben.
• Bing: kein direktes Gegenstück — Website-Explorer für die Übersicht, URL-Prüfung für eine einzelne Seite.

Offizielle Dokumentation

Primärdokumentation der Suchmaschinen.

Google

• Bericht zur Seitenindexierung — Search-Console-Hilfe zu Gruppen, Quellenspalte, allen Status, Sitemap-Filter und Fehlerprüfung.
• Verbesserungen an den Daten zur Indexabdeckung (Jan. 2021) — das Datenqualitäts-Update, das mehrere Status überarbeitete.
• Tool zur URL-Prüfung — das URL-bezogene Gegenstück zu diesem Bericht.

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — Bings URL-Ansicht für Index, SEO und Markup.
• Bing Webmaster Tools — Site Explorer (Refreshed Webmaster Tools) — das nächste aggregierte Gegenstück zum GSC-Bericht zur Seitenindexierung.

Zitate aus den Quellen

Öffentliche Aussagen von Google. Jeder Link springt zur zitierten Passage.

Google — Zweck und Inhalt des Berichts

• “See which pages Google can find and index on your site, and learn about any indexing problems encountered.” (Übersetzung) „Erkennen, welche Seiten Google auf deiner Website finden und indexieren kann, und mehr über aufgetretene Indexierungsprobleme erfahren.“ — Search-Console-Hilfe. Zum Zitat
• “The Page indexing report shows the Google indexing status of all URLs that Google knows about in your property.” (Übersetzung) „Der Bericht zur Seitenindexierung zeigt den Google-Indexierungsstatus aller URLs, die Google in deiner Property kennt.“ Zum Zitat

Google — Bericht oder Einzelseite und Zuständigkeit

• “This report isn’t used to investigate the index status of specific pages. To find the index status of a specific page, use the URL Inspection tool.” (Übersetzung) „Dieser Bericht dient nicht zur Untersuchung des Indexierungsstatus bestimmter Seiten. Nutze die URL-Prüfung, um den Indexierungsstatus einer bestimmten Seite zu ermitteln.“ Zum Zitat
• “The Source value in the table shows whether the source of the issue is Google or the website. In general, you can fix only issues where the source is listed as “Website”.” (Übersetzung) „Der Quellenwert in der Tabelle zeigt, ob die Ursache des Problems Google oder die Website ist. Im Allgemeinen kannst du nur Probleme beheben, deren Quelle als ‚Website‘ angegeben ist.“ Zum Zitat

Google — „nicht indexiert“ ist nicht zwangsläufig schlecht

• “Not indexed is not necessarily bad.” (Übersetzung) „Nicht indexiert ist nicht zwangsläufig schlecht.“ Zum Zitat
• “You should not expect all URLs on your site to be indexed, only the canonical pages.” (Übersetzung) „Du solltest nicht erwarten, dass alle URLs deiner Website indexiert werden, sondern nur die kanonischen Seiten.“ Zum Zitat

Google — wer den Bericht braucht und Dauer der Prüfung

• “If your site has fewer than 500 pages, you probably don’t need to use this report.” (Übersetzung) „Wenn deine Website weniger als 500 Seiten hat, musst du diesen Bericht wahrscheinlich nicht verwenden.“ Zum Zitat
• “Validation typically takes up to about two weeks, but in some cases can take much longer, so please be patient.” (Übersetzung) „Die Überprüfung dauert normalerweise bis zu etwa zwei Wochen, kann in manchen Fällen aber deutlich länger dauern. Bitte habe Geduld.“ Zum Zitat

Gary Illyes, Google — zu „gecrawlt – zurzeit nicht indexiert“ und Website-Qualität (SERP Conf 2024, wiedergegeben vom Search Engine Journal)

• “And the general quality of the of the site, that can matter a lot of how many of these crawled but not indexed you see in search console. If the number of these URLs is very high that could hint at general quality issues.” (Übersetzung) „Auch die allgemeine Qualität der Website kann stark beeinflussen, wie viele dieser gecrawlten, aber nicht indexierten Seiten du in Search Console siehst. Eine sehr hohe Anzahl solcher URLs könnte auf allgemeine Qualitätsprobleme hinweisen.“ Bericht lesen

John Mueller, Google — zur Verzögerung des Berichts (wiedergegeben vom Search Engine Journal)

• “It’s just a report that’s kind of lagging behind.” (Übersetzung) „Es ist einfach ein Bericht, der ein wenig hinterherhinkt.“ Bericht lesen Der Textfragmentanker lautet „more a matter of timing“.

Checkliste für den Bericht zur Seitenindexierung

Ein wiederholbarer Ablauf, mit dem du den Bericht triagierst, statt ihn nur anzustarren:

• Notiere die Summen Indexiert und Nicht indexiert sowie den Trend — bewegt sich etwas?
• Öffne „Warum Seiten nicht indexiert werden“ und arbeite die Tabelle von oben nach unten ab; sie ist nach Wichtigkeit sortiert.
• Konzentriere dich auf Quelle = Website — diese Probleme kannst du tatsächlich beheben.
• Ziehe für jedes echte Problem eine Beispiel-URL heran und prüfe sie mit der URL-Prüfung.
• Trenne beabsichtigte Status (noindex, robots.txt-Sperre, alternative Seite mit korrekter Canonical-URL, Weiterleitung) von defekten (5xx, unerwartete 404/4xx, Weiterleitungsfehler).
• Prüfe bei Canonical-/Duplikatstatus vor Änderungen die von Google gewählte Canonical-URL in der URL-Prüfung.
• Behandle große Gruppen gecrawlt/gefunden – zurzeit nicht indexiert als Signal für Website-Qualität/Crawl-Nachfrage, nicht als Fehler einer einzelnen Seite.
• Vergleiche einen Rückgang indexierter Seiten mit einem Anstieg eines nicht indexierten Status; vielleicht wurde etwas blockiert.
• Behebe alle Instanzen, klicke dann auf Fehlerbehebung überprüfen und klicke bis zum Ergebnis nicht erneut.
• Filtere für eine schnellere Prüfung nach einer Sitemap mit deinen wichtigsten Seiten und prüfe diese Teilmenge.
• Denke an die Verzögerung des Berichts — gib Änderungen etwa zwei Wochen.

Die Denkmodelle

1. Bericht = Aggregat; URL-Prüfung = einzelne Seite. Der Bericht zur Seitenindexierung zeigt Muster der Website. Die URL-Prüfung zeigt den Zustand einer URL (Live-Status, gewählte Canonical-URL, Rendering). Erkenne ein Muster im Bericht und bestätige die Ursache mit der URL-Prüfung.

2. Nicht indexiert ≠ defekt. Deine erste Reaktion auf eine große Zahl sollte „Gründe lesen“ und nicht „alles beheben“ sein. Canonical-/Duplikatseiten, noindex, robots.txt und beabsichtigt nicht gefundene Seiten sind korrekt. Google erwartet nur Canonical-Seiten im Index.

3. Quelle = Website ist deine Aufgabenliste. Die Quellenspalte trennt Googles Entscheidung von deiner. Du kannst nur die von der Website verursachten Probleme beeinflussen. Zusammen mit dem Prüfstatus Fehlgeschlagen/Nicht gestartet wird daraus eine handhabbare Liste.

4. Die Sortierung ist eine Prioritätenliste. Google sortiert „Warum Seiten nicht indexiert werden“ nach Wichtigkeit vor. Beginne oben und arbeite dich nach unten.

5. Fehlerbehebung überprüfen ist eine Crawl-Anfrage, kein Schalter. Du bittest Google, bekannte betroffene URLs erneut zu prüfen. Das dauert ungefähr zwei Wochen und kann fehlschlagen. Beschränke die Prüfung über eine Sitemap auf deine wichtigsten Seiten, um sie zu beschleunigen.

6. Der Bericht ist immer etwas verzögert. Er spiegelt pro URL den letzten Crawl wider und aktualisiert sich beim erneuten Crawl. Behandle einen einzelnen Messwert als verzögerten Schnappschuss, nicht als Live-Wahrheit.

Bericht zur Seitenindexierung — Spickzettel

Die beiden häufig verwechselten Berichte

Die 16 Status, gruppiert

Kurzfakten

• Alter Name: Bericht zur Indexabdeckung (2022 in Seitenindexierung umbenannt).
• Quelle = Website = Probleme, die du beheben kannst.
• Fehlerbehebung überprüfen ≈ zwei Wochen; beschränke die Prüfung über eine kleine Sitemap.
• Beispiel-URL-Listen enden bei 1 000; Summen können leicht abweichen; der Bericht hinkt hinterher.
• Indexiert ≠ Ranking — es bedeutet nur, dass die Seite erscheinen kann.
• <500 Seiten? Wahrscheinlich brauchst du den Bericht nicht; nutze eine site:-Suche.

Häufige Probleme

Symptom → wahrscheinliche Ursache → Lösung für die Muster, die Menschen tatsächlich in diesen Bericht zurückführen.

Anmelde-, Zugriff-verweigert- oder leere App-Seiten werden indexiert

Durchgearbeitetes Beispiel: /account/invoices/123 soll eine Anmeldung erfordern. Für einen abgemeldeten Crawler liefert die Route 200 OK, eine normal indexierbare robots-Anweisung und eine markengebundene HTML-Hülle, deren Hauptinhalt „Sign in to continue“ lautet. Interne Links oder eine alte Sitemap legen Tausende Rechnungs-URLs offen. Google umgeht die Anmeldung nicht — es indexiert die crawlbare 200-Hülle, welche die Anwendung absichtlich ausgeliefert hat.

Prüfe mehrere URLs im abgemeldeten Zustand und vergleiche HTTP-Status, Canonical-URL, robots-Anweisungen und gerenderten Hauptinhalt. Die Lösung liegt meist auf Vorlagenebene: Authentifizierung vor der Ressourcenauslieferung verlangen, passend zum Zugriffsmodell 401, 403, 404 oder 410 liefern, URLs aus Sitemaps und crawlbarer Navigation entfernen oder ein crawlbares noindex ausliefern, falls die öffentliche Hülle erreichbar bleiben muss. Prüfe sowohl Live-Antwort als auch Indexstatus; eine korrigierte Beispiel-URL beweist nicht, dass das Routenmuster korrigiert ist.

Anzahl indexierter Seiten sinkt, ohne dass neue Fehler erscheinen

• Symptom: Die Summe „Indexiert“ fällt, aber „Warum Seiten nicht indexiert werden“ zeigt keinen passenden Anstieg eines Fehlerstatus.
• Wahrscheinliche Ursache: Zuvor indexierte Seiten wurden blockiert — durch eine neue robots.txt-Disallow-Regel, ein vorlagenweites noindex oder eine neue Anmeldung/Paywall.
• Lösung: Suche nach dem passenden Anstieg eines Nicht-Fehler-Status (robots.txt, noindex oder gefunden/gecrawlt – zurzeit nicht indexiert), statt nur HTTP-Fehler zu prüfen. Bestätige eine Beispiel-URL mit der URL-Prüfung und kontrolliere die Live-Regeln mit robots-txt-tester (/tools/robots-txt-tester).

„Mehr nicht indexiert als indexiert“

• Symptom: Die Summe nicht indexierter Seiten ist größer als die indexierter Seiten, obwohl die Website nicht neu ist.
• Wahrscheinliche Ursache: Entweder blockiert robots.txt einen großen Bereich oder Filter-/Sortierparameter (?color=green, ?sort=price) erzeugen viele nahezu identische URLs, die Google als Duplikate gruppiert.
• Lösung: Vergleiche das Parametermuster mit den Canonical-Tags über canonical-checker (/tools/canonical-checker) und vergleiche anschließend den gerenderten Inhalt der betroffenen URLs. Das ist ein Problem mit facettierter Navigation/Canonicalisierung im Indexierungsgewand, kein Berichtsfehler.

Plötzlicher Anstieg eines HTTP-Fehlerstatus

• Symptom: 401-, 403-, 404- oder 5xx-Zahlen steigen nach einem Deployment auf vielen URLs gleichzeitig.
• Wahrscheinliche Ursache: Eine Vorlagenänderung hat eine gemeinsame Komponente beschädigt (Authentifizierung, Weiterleitung, Fehlerseite), oder eine neue Sitemap enthält blockierte, nicht indexierbare oder entfernte URLs.
• Lösung: Prüfe eine Stichprobe aus den Statusdetails mit http-status-checker (/tools/http-status-checker). Stammt das Problem aus der Sitemap, prüfe sie vor erneutem Einreichen mit sitemap-validator (/tools/sitemap-validator).

„Weiterleitungsfehler“ (nicht der normale Status „Seite mit Weiterleitung“)

• Symptom: Der Bericht zeigt Weiterleitungsfehler statt des erwarteten Status Seite mit Weiterleitung.
• Wahrscheinliche Ursache: zu lange Weiterleitungskette, Schleife, leere oder fehlerhafte Ziel-URL oder Überschreitung der maximalen URL-Länge.
• Lösung: Verfolge die Sprünge mit redirect-chain-mapper (/tools/redirect-chain-mapper) und verkürze sie auf einen Sprung zur endgültigen URL.

„Fehlerbehebung überprüfen“ endet mit Fehlgeschlagen

• Symptom: Du hast das Problem behoben und die Prüfung angestoßen, doch das Ergebnis lautet Fehlgeschlagen statt Bestanden.
• Wahrscheinliche Ursache: Die Behebung erreichte nicht alle betroffenen URLs (CDN-Cache, nur Staging oder übersehene URL-Muster), oder Google crawlete vor der vollständigen Ausbreitung.
• Lösung: Prüfe einige ursprünglich betroffene URLs direkt — Quelltext oder HTTP-/robots-Prüfung, nicht nur Browserdarstellung. Fordere danach erneut eine Prüfung an; wenn die zugrunde liegende Behebung live ist, musst du nicht auf einen vollständigen Zyklus warten.

Validierungstests

Diese Tests belegen, dass eine Behebung die zugrunde liegende Realität verändert hat und nicht nur der Bericht etwas anderes behauptet.

Prüfen, ob der Live-Status einer blockierten Seite der Absicht entspricht

• Test: http-status-checker (/tools/http-status-checker) oder curl -I für die betroffene URL.
• Erwartung: der beabsichtigte Status — 200 zum Entsperren oder bewusst 301/ 404 zum Entfernen.
• Fehlerinterpretation: Bleibt der alte Fehler (401/403/5xx), ist die Behebung nicht überall ausgerollt; prüfe CDN-Cache, Load Balancer und Umgebung.
• Beobachtungsfenster: sofort; der HTTP-Status ist live und nicht verzögert.
• Rollback-Auslöser: Der Status entspricht nach Cache-Leerung und einigen Minuten nicht der Absicht — Änderung zurücknehmen und vor einem neuen Produktionsversuch erneut diagnostizieren.

Prüfen, ob eine robots.txt-Änderung die URL wirklich freigibt

• Test: robots-txt-tester (/tools/robots-txt-tester) für den konkreten Pfad.
• Erwartung: Das Tool meldet die URL für Googlebot als zulässig.
• Fehlerinterpretation: Eine Sperre bedeutet, dass die Regel nicht entfernt wurde, eine spezifischere Regel greift oder die falsche robots.txt geprüft wurde.
• Beobachtungsfenster: sofort für die Datei; bis zum neuen GSC-Status einen normalen Crawl-Zyklus (Tage, nicht Stunden) einplanen.
• Rollback-Auslöser: Die URL bleibt blockiert, obwohl die Produktionsdatei robots.txt bestätigt wurde — als ungelöst behandeln und weiter diagnostizieren.

Prüfen, ob die Canonical-Behebung wie beabsichtigt aufgelöst wird

• Test: canonical-checker (/tools/canonical-checker) für die URL, danach die URL-Prüfung in GSC für Googles Canonical-Auswahl.
• Erwartung: <link rel="canonical"> entspricht der gewünschten URL, und Google stimmt in der URL-Prüfung zu.
• Fehlerinterpretation: Wählt Google weiterhin eine andere Canonical-URL, wurde das Tag korrigiert, nicht aber die Duplikatsignale; interne Links, Sitemap und Weiterleitungen müssen ebenfalls übereinstimmen.
• Beobachtungsfenster: zwei bis vier Wochen; Canonical-Auswahl stabilisiert sich vergleichsweise langsam.
• Rollback-Auslöser: Die Auswahl weicht nach mehr als vier Wochen und einem Prüfzyklus weiterhin ab — die zugrunde liegenden Signale bleiben widersprüchlich.

Prüfen, ob eine Weiterleitungsbehebung Kette oder Schleife entfernt hat

• Test: redirect-chain-mapper (/tools/redirect-chain-mapper) für die URL.
• Erwartung: genau ein Sprung zur endgültigen Ziel-URL mit 200.
• Fehlerinterpretation: Mehrere Sprünge oder Rücksprung zu einer früheren URL bedeuten, dass eine neue Regel über eine alte gelegt statt die alte ersetzt wurde.
• Beobachtungsfenster: sofort für die Kette; bis zum GSC-Update ein normaler Crawl-Zyklus.
• Rollback-Auslöser: Die Kette bleibt nach der Behebung länger als ein Sprung — zurücknehmen und Weiterleitungsregeln an der Quelle zusammenführen.

Prüfen, ob „Fehlerbehebung überprüfen“ bestanden wurde

• Test: Schaltfläche Fehlerbehebung überprüfen im betreffenden GSC-Status; für schnellere Ergebnisse auf eine Sitemap wichtiger URLs beschränken.
• Erwartung: Status Bestanden oder N/V, wenn Google die Behebung unabhängig bestätigt hat.
• Fehlerinterpretation: Fehlgeschlagen bedeutet, dass Google auf mindestens einigen URLs weiterhin das Problem fand. Behebe die Ursache statt nur erneut zu klicken.
• Beobachtungsfenster: laut Google normalerweise bis zu etwa zwei Wochen, teils länger.
• Rollback-Auslöser: zwei aufeinanderfolgende Fehlschläge trotz bestätigter Live-Behebung — prüfen, ob wirklich jedes URL-Muster und nicht nur die Stichprobe erreicht wird.

Erfolg messen

Diese dauerhaften Kennzahlen helfen, den Bericht über die Zeit zu beobachten.

Anzahl indexierter Seiten (Trend, nicht Momentaufnahme)

• Aussage: ob Googles indexierte Fläche deiner Website wächst, stabil bleibt oder schrumpft.
• Abruf: Summe „Indexiert“ oben im Bericht oder das Diagramm unter „Daten zu indexierten Seiten ansehen“.
• Benchmark / realistischer Bereich: keine universelle Zahl; sie hängt von der gewünschten Anzahl kanonischer URLs ab. Vergleiche den Trend mit deinem eigenen Canonical-Bestand statt 100 % Abdeckung anzustreben.
• Rhythmus: monatlich oder sofort nach großen Inhalts-/URL-Strukturänderungen.

Summe „Warum Seiten nicht indexiert werden“, Quelle = Website

• Aussage: Größe deiner tatsächlichen, von dir lösbaren Aufgabenliste.
• Abruf: Tabelle “Why pages aren’t indexed” („Warum Seiten nicht indexiert werden“) nach Quelle = Website filtern und URL-Anzahlen der Status mit „Fehlgeschlagen“ oder „Nicht gestartet“ summieren.
• Benchmark / realistischer Bereich: abhängig von Größe und Historie; es gibt keinen ehrlichen Universalwert. Lege beim nächsten vollständigen Durchgang eine eigene Basis fest und beobachte, ob sie sinkt.
• Rhythmus: für die meisten Websites monatlich, bei aktiver Bereinigung oder nach einer Migration wöchentlich.

Anzahl der HTTP-Fehlerstatus (401/403/404/5xx)

• Aussage: ob Seiten, die du ausliefern möchtest, für Googlebot defekt sind.
• Abruf: einzelne Statuszeilen, abgeglichen mit http-status-checker (/tools/http-status-checker) für eine Stichprobe.
• Benchmark / realistischer Bereich: Für beabsichtigt aktive Canonical-Seiten ist null das sinnvolle Ziel. Erwartete 404 auf entfernten Seiten sind normal und hängen vom Inhaltslebenszyklus ab.
• Rhythmus: nach jedem Deployment mit Routing-, Authentifizierungs- oder Vorlagenänderungen, sonst monatlich.

Erfolgsquote der Fehlerprüfung

• Aussage: ob Behebungen alle betroffenen URLs erreichen oder nur teilweise.
• Abruf: Ergebnis jeder Anfrage (Bestanden / Fehlgeschlagen / N/V) im Zeitverlauf erfassen.
• Benchmark / realistischer Bereich: kein fester Zielwert; gesund ist, wenn die meisten Anfragen beim ersten Versuch Bestanden oder N/V erreichen. Wiederholte Fehlschläge desselben Status sind das eigentliche Signal.
• Rhythmus: pro Behebungszyklus; etwa zwei Wochen nach jeder Anfrage prüfen.

Tools

Der Bericht nennt, was Google für fehlerhaft hält; diese Tools bestätigen und beheben die Ursache.

Tools dieser Website

• gsc-workbench (/tools/gsc-workbench) — eigene GSC-Daten über die Search Console API mit den Konzepten dieser Seite verarbeiten.
• gsc-regex-tester (/tools/gsc-regex-tester) — Regex-Filter für GSC-Leistungs- und Seitenindexierungsberichte erstellen und prüfen, um URL-Muster zu isolieren.
• http-status-checker (/tools/http-status-checker) — den Live-Statuscode (401/403/404/5xx) vor oder nach einer Behebung bestätigen.
• redirect-checker (/tools/redirect-checker) und redirect-chain-mapper (/tools/redirect-chain-mapper) — einzelne Weiterleitungen oder ganze Ketten bei Weiterleitungsfehlern prüfen.
• canonical-checker (/tools/canonical-checker) — das angegebene Canonical-Tag einer URL aus der Duplikatgruppe prüfen.
• robots-txt-tester (/tools/robots-txt-tester) — feststellen, ob eine URL tatsächlich blockiert ist.
• sitemap-validator (/tools/sitemap-validator) und xml-sitemap-generator (/tools/xml-sitemap-generator) — die Sitemap für eine beschleunigte Teilmengenprüfung prüfen oder neu erstellen.
• site-audit-lite (/tools/site-audit-lite) — crawlbasierte Plausibilitätsprüfung, wenn ein Muster die gesamte Website statt einzelner URLs betrifft.

Tools von Drittanbietern

• Google Search Console — der Bericht selbst und die URL-Prüfung für einzelne URLs.
• Bing Webmaster Tools — Website-Explorer für die Übersicht und URL-Prüfung für eine einzelne URL.
• Screaming Frog — die eigene Website ähnlich wie Googlebot crawlen, um Statuscodes, Weiterleitungen und Canonical-Tags im großen Maßstab gegenzuprüfen.

Lohnenswerte Ressourcen

Meine verwandten Artikel

• How to Fix “Discovered - currently not indexed” — Vertiefung eines der am häufigsten missverstandenen Status.
• How to Remove URLs From Google Search (5 Methods) — zur noindex- und Entfernungstool-Seite des Berichts.
• Anonymized Queries Make Up Nearly Half of GSC Traffic — meine GSC-Datenstudie und Erinnerung an die Grenzen von Search Console.
• The Beginner’s Guide to Technical SEO — Einordnung von Indexierung und GSC in das Gesamtbild.

Meine Vorträge

• How Search Works (SlideShare) — mein Überblick über Crawling, Rendering, Indexierung und Ranking, den Kontext dieses Berichts. Mein üblicher Vorbehalt gilt: “This is my understanding of systems… not going to be 100% complete or accurate.” (Übersetzung) „Dies ist mein Verständnis der Systeme … es wird nicht zu 100 % vollständig oder genau sein.“

Offiziell

• Google — Page indexing report und Index Coverage Data Improvements (2021).

Aus der Branche

• r/TechSEO — Community zur Fehlersuche bei Indexierung und Abdeckungsberichten.
• Google Explains Reasons For Crawled Not Indexed (Search Engine Journal) — Bericht über Gary Illyes bei der SERP Conf 2024 und hohe „gecrawlt, nicht indexiert“-Werte als mögliches Qualitätssignal.
• Mueller Asked About Lag in Google Search Console Indexing Report (Search Engine Journal) — John Mueller zur Verzögerung des Berichts.
• Google Search Console Coverage Report Renamed to Pages Report (Search Engine Roundtable) — Barry Schwartz’ erste Sichtung der Umbenennung bei der Google I/O 2022.
• Index Coverage Data Improvements (Google Search Central Blog) — das Januar-2021-Update, das Status änderte und Unterschiede alter Screenshots erklärt.
• Google Search Console Help — Page indexing report — Primärquelle zu Gruppen, Quellenspalte, Status, Sitemap-Filter und Prüfung.

Quiz

Teste, was du über den Bericht zur Seitenindexierung behalten hast.

Änderungsprotokoll