Index-Coverage-Fehler in der Search Console beheben (und ihnen zuvorkommen)

Um Index-Coverage-Fehler in der Google Search Console zu beheben, öffnest du den Bericht „Seiten“, sortierst die betroffenen URLs nach dem Grund, den Google angibt, behebst die Ursache auf der Website und klickst anschließend auf „Fehlerbehebung überprüfen“. Die meiste Arbeit steckt im dritten Schritt, denn derselbe Grund kann aus einem Template, einer Plugin-Einstellung oder einer Serverregel stammen, und der Bericht verrät dir nicht, woher.

Der Bericht, den Google früher Index Coverage (Indexabdeckung) nannte, liegt heute unter Indexierung > Seiten. Das Diagramm oben teilt die URLs in „Indexiert“ und „Nicht indexiert“, und die Tabelle darunter, „Warum Seiten nicht indexiert werden“, listet jeden Grund mit der Anzahl betroffener Seiten. Sie beschreibt, was Google bei seinen letzten Besuchen vorgefunden hat. Das Problem, das du heute siehst, kann also schon vor Wochen begonnen haben.

Index-Coverage-Fehler im Seiten-Bericht und ihre typischen Ursachen

Grund in der GSC	Häufige Ursache	Wo die Lösung meist liegt
Durch „noindex“-Tag ausgeschlossen	<meta name="robots" content="noindex"> oder ein X-Robots-Tag: noindex-Header, übrig aus dem Staging oder in einem Template gesetzt	Template, SEO-Plugin, Serverkonfiguration
Durch robots.txt-Datei blockiert	Eine Disallow-Regel, die URLs abdeckt, die gecrawlt werden sollen	robots.txt
Duplikat – vom Nutzer nicht als kanonisch festgelegt	Nahezu identische URLs (Parameter, Slash am Ende, http und https) ohne Canonical	rel="canonical" auf den Varianten ergänzen
Duplikat – Google hat eine andere Seite als der Nutzer als kanonische Seite bestimmt	Dein Canonical widerspricht internen Links, Weiterleitungen oder der Sitemap	Alle diese Signale auf dieselbe URL ausrichten
Seite mit Weiterleitung	Die URL leitet per 301 woandershin	Oft in Ordnung; Sitemap und interne Links auf die Ziel-URL aktualisieren
Nicht gefunden (404) und Soft 404	Eine entfernte Seite ist noch verlinkt oder gelistet, oder eine leere „Keine Ergebnisse“-Seite liefert 200	Wiederherstellen, weiterleiten oder einen echten 404 bzw. 410 ausliefern
Gecrawlt – zurzeit nicht indexiert, Gefunden – zurzeit nicht indexiert	Google hat sich (noch) nicht für die Indexierung entschieden, oft bei dünnen oder fast doppelten Seiten	Inhalte verbessern oder zusammenführen, interne Verlinkung stärken

Nicht jede Zeile muss behoben werden. „Seite mit Weiterleitung“ und „Alternative Seite mit richtigem kanonischen Tag“ beschreiben oft eine Website, die genau so funktioniert wie gewollt. Sorgen machen solltest du dir um die Zeilen, in denen URLs stehen, die ranken sollen.

Die noindex-Zeile richtet den größten Schaden an, weil die Seite auf Anweisung der Website selbst draußen gehalten wird und im Browser nichts falsch aussieht. Woher so ein Tag typischerweise kommt, erklärt wie du ein noindex in der Produktion findest. Für die robots.txt-Zeile gehst du deine robots.txt Zeile für Zeile durch. Denk dabei daran, dass Google ein noindex auf einer URL, die es nicht crawlen darf, gar nicht lesen kann.

Den Bericht Schritt für Schritt abarbeiten

1. Geh in der Search Console zu Indexierung > Seiten und scroll zu „Warum Seiten nicht indexiert werden“.
2. Öffne einen Grund. Die Beispielliste ist auf 1.000 URLs begrenzt. Auf einer großen Website exportierst du sie deshalb und suchst nach Mustern, statt jede einzelne URL abzuarbeiten.
3. Gruppiere die URLs nach Template oder Verzeichnis. Vierzig Produktseiten mit noindex sind normalerweise ein Template oder eine Plugin-Einstellung und keine vierzig einzelnen Aufgaben.
4. Behebe die Ursache. Auf WordPress prüfst du unter Einstellungen > Lesen die Option „Suchmaschinen davon abhalten, diese Website zu indexieren“ und die Sichtbarkeitseinstellung pro Seite in Yoast oder Rank Math, bevor du irgendeinen Code anfasst.
5. Füge eine betroffene URL in die URL-Prüfung ein und starte „Live-URL testen“. Du siehst, ob die Indexierung erlaubt ist und welches Canonical auf der Live-Seite angegeben ist. So weißt du, dass der Fix wirklich ausgeliefert wird und nicht hinter einem CDN-Cache hängt.
6. Geh zurück zum Grund und klick auf „Fehlerbehebung überprüfen“. Laut Google-Dokumentation dauert die Validierung meist bis zu etwa zwei Wochen, manchmal länger, und die Search Console informiert dich per E-Mail über den Fortschritt.

Warum der Fehler, den du siehst, schon alt ist

Die Search Console läuft nach Googles Crawl-Zeitplan, nicht nach deinem. Eine Template-Änderung, die am 1. live geht, muss erst auf genügend URLs neu gecrawlt und verarbeitet werden, bevor sie als Ausschlag im Seiten-Bericht erscheint, und der Bericht selbst wird mit mehreren Tagen Verzögerung aktualisiert. Wenn ein Grund sprunghaft ansteigt, sind Seiten womöglich schon aus dem Index gefallen, und die Validierung bringt noch einmal ihre eigene Wartezeit mit. Es ist derselbe blinde Fleck wie bei stillen SEO-Änderungen: Die Ursache steht auf der Seite, lange bevor sich ihre Folgen messen lassen.

Die Search Console kann diese Lücke nicht schließen, weil sie nur meldet, was Google schon verarbeitet hat. Du kannst es, indem du das HTML und die robots.txt direkt beobachtest, denn dort beginnen die meisten dieser Gründe.

Den Ursachen zuvorkommen, bevor sie im Bericht landen

Deltio verbindet sich nicht mit der Search Console und kann dir nicht sagen, was Google indexiert hat. Dafür bleibt der Seiten-Bericht die Quelle. Deltio prüft die On-Page-Ursachen, die später zu Zeilen in diesem Bericht werden. Einmal täglich liest es die Sitemap und die Seiten jeder Website und vergleicht sie mit dem vorherigen Check. Ein neu auftauchendes noindex, ein geändertes Canonical oder eine neue robots.txt-Regel wird dir also noch am Tag der Entdeckung per Slack und E-Mail für die betreffende Website gemeldet. Auch URLs, die aus der Sitemap fallen, werden gemeldet, und genau dort beginnen oft die Zeilen „Nicht gefunden (404)“; mehr dazu unter aus der Sitemap entfernte Seiten. Nachdem du etwas behoben hast, bestätigt ein manueller SEO-Scan, dass die Seite sauber ist, bevor du auf „Fehlerbehebung überprüfen“ klickst.

Weil der Check täglich läuft, kann eine Änderung bis zu einem Tag ungemeldet bleiben. Verglichen mit einem Bericht, der Wochen hinterherhinkt, bleibt meist genug Zeit, sie zurückzunehmen, bevor viele URLs neu gecrawlt werden. Gründe, die von Googles Einschätzung abhängen statt von einem Tag, etwa „Gecrawlt – zurzeit nicht indexiert“ oder ein von Google selbst gewähltes Canonical, brauchen weiterhin die Search Console.

Wenn du beide Sichten auf eine Kunden-Website haben willst, kannst du Deltio 14 Tage kostenlos testen.