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 Seiten-Bericht, gruppierst die betroffenen URLs nach dem Grund, den Google nennt (ausgeschlossen durch noindex, blockiert durch robots.txt, Weiterleitung, nicht gefunden, gecrawlt aber nicht indexiert, Duplikat ohne gewähltes Canonical), behebst die Ursache auf der Seite und klickst dann auf Fehlerbehebung überprüfen. Der Haken ist das Timing: die Search Console meldet das verzögert und nur für eine Stichprobe an URLs, der Fehler, den du heute siehst, ist also seit Wochen live. Deltio überwacht die On-Page-Ursachen, noindex, Canonical, robots.txt, in Echtzeit und warnt dich an dem Tag, an dem sie sich ändern, bevor Google den Bericht erstellt. Ab £20 pro Monat, mit 14 Tagen kostenloser Testphase.

Der Seiten-Bericht (früher der Index-Coverage-Bericht) ist die Stelle, an der du erfährst, welche URLs nicht im Index sind und warum. Er ist unverzichtbar, aber er ist ein Rückspiegel: er sagt, was schon passiert ist, im Takt von Google, für einen Bruchteil der Website. Für eine Agentur ist der Abstand zwischen Änderung und Bericht der Abstand, in dem der Traffic eines Kunden still ausblutet.

Die Fehler, die du wirklich siehst, und ihre Ursachen

• Durch noindex-Tag ausgeschlossen. Ein Meta-Robots-noindex in einem Template oder ein Überbleibsel aus Staging. Der schädlichste, weil die Seite absichtlich draußen gehalten wird. Siehe wie du ein noindex in der Produktion findest.
• Durch robots.txt blockiert. Eine Disallow-Regel, die URLs abdeckt, die du indexiert haben willst. Hier steht, wie du die robots.txt prüfst, Zeile für Zeile.
• Duplikat, ohne vom Nutzer ausgewähltes Canonical. Google fand nahezu identische Seiten und wählte ein Canonical, das du nicht wolltest. Meist ein Canonical-Problem, kein Content-Problem.
• Seite mit Weiterleitung. Die URL macht eine 301 woanders hin. In Ordnung, wenn gewollt, ein Leck, wenn ein Canonical oder ein interner Link noch darauf zeigt.
• Nicht gefunden (404) / Soft 404. Eine entfernte Seite, die noch verlinkt oder noch in der Sitemap ist.
• Gecrawlt, aktuell nicht indexiert / Erkannt, nicht indexiert. Google hat die Seite gesehen und sich gegen die Indexierung entschieden, oder ist noch nicht dazu gekommen. Oft dünner Content oder Crawl-Budget, das für Duplikate draufgeht.

Wie du den Seiten-Bericht abarbeitest

1. Öffne die Search Console, geh zu Indexierung, dann Seiten. Lies die Gründe unter "Warum Seiten nicht indexiert werden".
2. Klick auf einen Grund, um die URL-Liste zu bekommen. Exportiere sie.
3. Gruppiere nach Ursache. Ein noindex auf 40 URLs ist eine Template-Korrektur, nicht 40 Aufgaben.
4. Behebe die Ursache auf der Seite: entferne das noindex, korrigiere die robots.txt-Zeile, repariere das Canonical, stelle die 404 wieder her oder leite sie weiter.
5. Klick auf Fehlerbehebung überprüfen. Google prüft in Tagen erneut, nicht in Minuten.
6. Schick eine betroffene URL durch das URL-Prüftool, um den Live-Zustand zu bestätigen, bevor du validierst.

Warum der Bericht immer zu spät ist

Die Search Console ist eine Stichprobe und eine Verzögerung. Sie crawlt nicht in deinem Takt, sie meldet eine Teilmenge an URLs, und die Validierung dauert Tage. So funktioniert ein globaler Index. Aber ein am 1. ausgeliefertes noindex kann am 20. als Fehler auftauchen, und erst dann startet die mehrtägige Validierung. Drei Wochen lang eine Seite außerhalb des Index, auf einer Kundenwebsite, zeigt sich als Ranking-Einbruch, bevor sie sich in einem Bericht zeigt. Es ist derselbe blinde Fleck wie bei stillen SEO-Änderungen: die Ursache steht auf der Seite, lange bevor die Folge messbar ist.

Schließ die Lücke: überwache die Ursache, nicht das Symptom

Coverage-Fehler sind Symptome. Die Ursachen, noindex, robots.txt, Canonical, leben im HTML, und das HTML kannst du fortlaufend prüfen. Wenn du den Moment kennst, in dem ein noindex auftaucht oder ein Canonical sich ändert, behebst du es am selben Tag und der Coverage-Fehler bekommt gar nicht erst die Chance, zu entstehen. Das ersetzt die Search Console nicht, es kommt ihr zuvor.

Wie Deltio das macht

Deltio verbindet sich nicht mit der Search Console und zeigt dir nicht Googles Index-Status: dafür ist der Seiten-Bericht die Quelle. Was Deltio tut, ist die On-Page-Ursachen zu überwachen, die zu Coverage-Fehlern werden. Der SEO-Scanner prüft noindex, Canonical, lang und hreflang auf jeder URL und vergleicht aufeinanderfolgende Scans, ein auftauchendes noindex oder ein geändertes Canonical wird also als Änderung gemeldet, statt Wochen später in der GSC aufzutauchen. Eine robots.txt-Änderung löst sofort einen Alert aus, mit zeilengenauem Diff dessen, was hinzugefügt oder entfernt wurde. Tägliche Sitemap-Snapshots zeigen hinzugefügte oder entfernte URLs, wo "nicht gefunden"-Fehler beginnen, siehe aus der Sitemap entfernte Seiten. Scans laufen automatisch, manuelle Scans bis zu 3 pro Tag im Starter, 10 im Professional und unbegrenzt im Enterprise. Alerts kommen per E-Mail und Slack, in deiner Sprache.

Nutze beide, in dieser Reihenfolge

Behalte den Seiten-Bericht für das, was nur Google dir sagen kann: was tatsächlich indexiert ist. Ergänze das Echtzeit-Monitoring für das, was Google dir zu spät sagt: die On-Page-Änderung, die es verursacht hat. Nimm eine Kundenwebsite auf, lass die ersten Scans eine Baseline bilden, und das nächste verrutschte noindex oder Canonical erreicht dich am selben Tag. Die 14 Tage kostenlose Testphase reichen dafür.