Am 3. Juli 2026 hat Google endlich den Page-Indexing-Report in der Google Search Console aktualisiert. Nach rund drei Wochen Stillstand — die letzten sichtbaren Daten stammten vom 11. Juni 2026 — zeigt der Report jetzt Daten bis zum 29. Juni. Für alle, die während dieser Zeit ein Indexierungs-Problem debuggen wollten: Die Sichtbarkeit ist zurück.
Das Timing ist heikel. Drei Wochen ohne Indexing-Insights sind für die meisten Sites nicht das Ende der Welt — aber für Sites, die in dieser Zeit einen Relaunch, eine Migration oder ein größeres Content-Update hatten, ist der jetzt sichtbare Zeitraum genau der Zeitraum, in dem die spannenden Signale entstanden sind. Genau hier lohnt sich eine strukturierte Analyse in den nächsten sieben Tagen.
Vertiefung: Technisches SEO für Crawling & Indexierung · Wenn WordPress KI-Crawler blockiert · Bings Such-Index im Wandel
Der Page-Indexing-Report in der Google Search Console war rund drei Wochen eingefroren und ist seit 3. Juli 2026 wieder aktuell. Der Delay war ein Reporting-Problem, kein Indexierungs-Problem – Rankings und Traffic waren nicht betroffen. Was jetzt zählt: strukturierte Debugging-Prüfung in den ersten sieben Tagen, Fokus auf „Discovered“- und „Crawled – currently not indexed“, Priorisierung nach Business-Impact statt Bulk-Requests. Für die Zukunft: eigene Reporting-Sicherung aufbauen, damit der nächste GSC-Ausfall keinen Blind-Spot erzeugt.
Google Search Console Page-Indexing-Report-Fix (3. Juli 2026): Nach rund drei Wochen Delay (letzte Daten vom 11. Juni) zeigt der Report jetzt Daten bis 29. Juni 2026. Der Delay war ein Reporting-Bug, kein Indexierungs-Problem – tatsächliche Indexierung und Rankings waren nicht betroffen. Wichtigste Indexing-Statuscodes: Discovered – currently not indexed (Crawl-Priorität zu niedrig), Crawled – currently not indexed (Google entschied gegen Indexierung), Duplicate without canonical, Excluded by noindex, Blocked by robots.txt. Sofort-Aktion: Chart-Kurve prüfen, Sitemap-Coverage, hochpriore URLs im URL-Inspection-Tool. Vermeiden: Bulk-Request-Reflex (Tages-Quota).
Geprüft: 5. Juli 2026 · Nächste Prüfung: beim nächsten GSC-Update
Was ist der Page-Indexing-Report genau?
Der Page-Indexing-Report in der Google Search Console (früher Coverage Report) zeigt, welche Seiten einer Website Google findet und indexiert. Er visualisiert indexierte Seiten (grün) und nicht indexierte Seiten (grau) als Zeitreihen-Chart, optional mit überlagerten Impressionen. Unter dem Chart werden die Gründe aufgelistet, warum bestimmte Seiten nicht indexiert werden – von technischen Blockaden bis zu qualitativen Entscheidungen von Google. Der Report ist der zentrale Debugging-Ort für Indexierungs-Probleme.
Der Report ist erreichbar über den Bereich Indexierung → Seiten in der Google Search Console. Er ist eines der wichtigsten Diagnose-Tools für technisches SEO — deshalb war der Drei-Wochen-Delay so schmerzhaft für Teams, die ein akutes Problem bearbeiten wollten.
Warum der Delay problematisch war (auch wenn Rankings nicht betroffen waren)
Der wichtigste Punkt zuerst: Der Delay hatte keinen Einfluss auf die tatsächliche Indexierung. Google hat weiter gecrawlt, weiter indexiert, weiter gerankt. Verzögert war nur die Sichtbarkeit dieser Prozesse im Report — nicht die Prozesse selbst. Wer in den letzten drei Wochen Traffic-Verluste hatte, sucht die Ursache woanders.
Teams, die während des Delays einen Website-Relaunch, eine URL-Migration, ein Content-Update oder ein Redirect-Setup fahren mussten, waren blind. Sie konnten weder in Echtzeit prüfen, ob neue URLs indexiert werden, noch ob alte URLs korrekt aus dem Index fallen. Genau für diese Teams ist der jetzt sichtbare Zeitraum das kritischste Analyse-Fenster der letzten Monate.
Die Timeline des Delays
Die 7-Punkt-Checkliste für die erste Woche nach dem Fix
1 · Chart-Kurve zwischen 11. und 29. Juni prüfen
Öffne den Report und fokussiere auf den Zeitraum 11. bis 29. Juni. Was zeigt die grüne Kurve der indexierten Seiten – konstant, wachsend oder gefallen? Prüfe die grauen (nicht indexierten) Balken: Gab es einen sichtbaren Sprung? Impressionen als Overlay einblenden — kombiniert zeigen beide, ob ein Indexierungs-Einbruch mit Traffic-Verlust korreliert.
2 · Die Not-indexed-Reasons-Tabelle im Detail durchgehen
Unter dem Chart listet Google alle Gründe, warum Seiten nicht indexiert sind. Sortiere nach Anzahl der betroffenen Seiten und nach Trend. Wichtiger als absolute Zahlen ist die Veränderung: Welche Kategorie ist neu, welche wächst, welche schrumpft? Ein Wachstum bei „Discovered – currently not indexed“ ist etwas anderes als bei „Duplicate without user-selected canonical“.
3 · Sitemap-Coverage prüfen
Der Report zeigt für jede eingereichte Sitemap, wie viele URLs indexiert wurden. Alle Money-Pages, Kategorie-Seiten und High-Intent-Landingpages müssen in einer aktiven Sitemap eingereicht sein und den Status „Indexed“ haben. Wenn nicht: erste Debugging-Priorität.
4 · Top-URLs mit dem URL-Inspection-Tool prüfen
Für die fünf bis zehn wichtigsten URLs des Business einzeln das URL-Inspection-Tool nutzen. Es zeigt je URL: ist sie indexiert, welche Version wurde als kanonisch gewählt, wann wurde sie zuletzt gecrawlt, welche Sitemap enthält sie, welche referrierenden Seiten hat Google gefunden. Für kritische Seiten: Live-Test vs. gespeicherten Google-Stand vergleichen.
5 · Relaunches, Migrationen und Redirects gezielt debuggen
Wer in den letzten drei bis vier Wochen eine URL-Migration oder einen Relaunch fahren musste: jetzt genau prüfen. Alte URLs sollten aus der Indexed-Kurve fallen, neue URLs dazukommen. Redirect-Ketten prüfen. Wenn alte URLs noch indexiert sind, der Redirect aber länger als zwei Wochen alt ist: Sitemap-Check und ggf. manuelle Reindexierung der 301-Zielseiten.
6 · Business-Impact-Priorisierung statt Report-Warnung
Der Report zeigt möglicherweise tausende nicht indexierte URLs. Nicht alle sind wichtig. Priorisiere nach: Bringt diese URL Umsatz, Leads oder Conversions? Wenn nein: wahrscheinlich ignorieren oder gezielt entfernen. Wenn ja: fixen. Die Menge nicht indexierter Junk-URLs ist selten das echte Problem.
7 · Kein Bulk-Request-Reflex
Nach dem Fix ist der Impuls stark, viele URLs manuell zur Indexierung einzureichen. Das URL-Inspection-Tool hat ein Tages-Limit für Indexing-Requests. Diese Quota für die fünf bis zehn wichtigsten URLs verwenden — nicht für jede zweifelhafte Seite. Google indexiert weiter automatisch. Manuelle Requests beschleunigen einzelne wichtige URLs, ersetzen aber keine strukturelle Fix-Arbeit.
Die wichtigsten Indexing-Statuscodes verstehen
Der Report zeigt Dutzende Statuscodes. Nicht alle sind gleich wichtig. Die folgenden sind die häufigsten und aussagekräftigsten:
| Statuscode | Was er bedeutet | Handlungsbedarf |
|---|---|---|
| Discovered – currently not indexed | Google kennt die URL, hat sie aber (noch) nicht gecrawlt. Crawl-Priorität zu niedrig. | Hoch bei Money-Pages: internes Linking stärken, Content-Qualität verbessern. |
| Crawled – currently not indexed | Google hat gecrawlt, aber gegen Indexierung entschieden. Qualität oder Duplikat-Signal. | Hoch: Content-Qualität, Uniqueness und Suchintention prüfen. |
| Duplicate without user-selected canonical | Google sieht mehrere URLs mit gleichem oder ähnlichem Inhalt und hat selbst kanonisch gewählt. | Mittel: Canonical-Tags setzen, um die Kontrolle zu übernehmen. |
| Alternate page with proper canonical tag | Duplicate-URL mit korrekt gesetztem Canonical. Normalzustand. | Kein Handlungsbedarf – ignorieren. |
| Excluded by ‚noindex‘ tag | Seite hat eine noindex-Anweisung. Google folgt der Instruktion. | Prüfen: Absicht oder Fehler? Bei wichtigen Seiten sofort fixen. |
| Blocked by robots.txt | Robots.txt verhindert das Crawling. Google kann die Seite nicht besuchen. | Prüfen: Absicht oder Fehler? Robots.txt-Regel überprüfen. |
| Page with redirect | URL leitet weiter. Google indexiert das Redirect-Ziel, nicht die URL selbst. | Bei alten URLs okay. Bei aktiven URLs: Redirect-Ketten prüfen. |
| Not found (404) | URL existiert nicht mehr. Google entfernt sie aus dem Index. | Prüfen: gewollt (410 ist sauberer) oder Redirect zur passenden Seite nötig? |
Was der Delay über GSC als Tool verrät
Der Drei-Wochen-Delay ist nicht der erste GSC-Ausfall und wird nicht der letzte sein. Google Search Console ist ein zentrales SEO-Tool — aber eines, das man nicht selbst kontrolliert. Wenn Google einen Reporting-Bug hat, hat man ihn mit. Für ernsthafte SEO-Arbeit heißt das: eigene Datensicherung ist keine Option, sondern Standard.
Ohne eigene Sicherung
Bei GSC-Ausfall komplett blind. Keine historischen Vergleichsdaten. Keine Möglichkeit, den Delay-Zeitraum später zu rekonstruieren. Der nächste Ausfall trifft dich mit den gleichen Konsequenzen.
Mit eigener Sicherung
Wöchentliche Screenshot- oder API-Exports, BigQuery-Integration für rohe Daten, Server-Logs als Alternativ-Signal für Crawling. Bei GSC-Ausfall bleibt die eigene Datenbasis intakt.
Erstens: monatlicher CSV-Export der wichtigsten Reports (Performance, Pages, Sitemaps). Zweitens: BigQuery-Integration einrichten, wenn Zugriff auf den GSC-Datenlake möglich ist. Drittens: Server-Log-Analyse aufsetzen — sie zeigt Crawling-Aktivität unabhängig von GSC. Viertens: Screaming-Frog- oder Sitebulb-Reports als Ergänzungs-Baseline. Nicht als Ersatz für GSC — als Vervollständigung.
Was der Delay über die Search-Ökonomie verrät
Reporting-Delays bei Google werden häufiger, nicht seltener. Google konzentriert Ressourcen auf KI-Features und Ranking-Systeme, während klassische Tools wie GSC in längeren Wartungs-Fenstern laufen. Für SEO-Teams heißt das: Die Erwartungshaltung gegenüber GSC-Reliabilität muss sich anpassen. Eigene Signal-Infrastruktur — Logs, Crawler-Tests, Third-Party-Rank-Tracking — wird von „nice to have“ zu „Kern der Arbeit“. Wer das jetzt aufbaut, ist beim nächsten Ausfall handlungsfähig.
Häufig gestellte Fragen
Was war mit dem Google-Search-Console-Indexing-Report los?
Der Page-Indexing-Report war rund drei Wochen lang eingefroren – die letzten sichtbaren Daten stammten vom 11. Juni 2026. Am 3. Juli 2026 hat Google den Report aktualisiert, jetzt sind Daten bis 29. Juni 2026 sichtbar. Während des Delays konnten SEOs keine neuen Indexierungs-Probleme über den Report debuggen.
Was zeigt der Page-Indexing-Report genau?
Der Report zeigt, welche Seiten Google findet und indexiert. Er unterscheidet indexierte Seiten (grün) und nicht indexierte Seiten (grau) mit einem Chart über die Zeit; Impressionen lassen sich überlagern. Unter dem Chart listet er alle Gründe, warum Seiten nicht indexiert werden.
Was sollte ich als erstes nach dem Fix prüfen?
Erstens die Chart-Kurve zwischen 11. und 29. Juni. Zweitens die Not-indexed-Reasons-Tabelle: Welche Kategorie ist gewachsen? Drittens die Sitemap-Coverage. Viertens hochpriore URLs einzeln im URL-Inspection-Tool prüfen.
Welche Indexing-Statuscodes sind besonders wichtig?
Discovered – currently not indexed, Crawled – currently not indexed, Duplicate without user-selected canonical, Alternate page with proper canonical tag (normal), Excluded by ‚noindex‘ tag und Blocked by robots.txt.
Warum ist „Discovered – currently not indexed“ problematisch?
Google weiß, dass die URL existiert, aber die Crawling-Priorität war zu niedrig. Häufige Ursachen: schwaches internes Verlinkungs-Signal, geringe wahrgenommene Content-Qualität, Crawl-Budget-Grenzen. Die Kategorie wächst überproportional bei dünnen Seiten oder schwacher Autorität.
Sollte ich URLs nach dem Fix manuell einreichen?
Nur für hochpriore Seiten. Das URL-Inspection-Tool hat ein Tages-Limit. Vor dem Einreichen prüfen: Hat die Seite ein Indexierungs-Problem? Ist sie in der Sitemap? Ist sie technisch indexierbar? Der Bulk-Request-Reflex verschwendet Quota.
Ändert der Delay etwas an meiner tatsächlichen Sichtbarkeit?
Nein. Der Delay war ein Reporting-Problem, kein Indexing-Problem. Google hat weiter gecrawlt und indexiert. Rankings, Traffic und Impressionen waren nicht betroffen. Traffic-Verluste in den letzten drei Wochen haben eine andere Ursache.
Was sollte ich für zukünftige GSC-Ausfälle vorbereiten?
Wöchentlicher Export der Indexing-Trend-Kurve, BigQuery-Export für eine rohe Daten-Sicherung und alternative Signale wie Server-Logs für Crawling-Aktivität. GSC ist zentral, aber nicht der einzige Kanal für Indexierungs-Daten.
Fazit: Der Report ist zurück, aber die Lehre bleibt
Der Fix am 3. Juli 2026 schließt einen 18-tägigen Reporting-Delay, der für viele Teams ein echter Blindflug war. In der ersten Woche nach dem Fix zählt strukturierte Debugging-Arbeit mehr als hektisches Klicken: Chart-Kurve prüfen, Not-indexed-Reasons priorisieren, Sitemap-Coverage validieren, Top-URLs inspizieren. Kein Bulk-Request-Reflex.
Die größere Lehre: GSC ist unverzichtbar, aber nicht unfehlbar. Wer den nächsten Ausfall — und der kommt — nicht wieder blind erleben will, baut jetzt seine eigene Reporting-Sicherung auf. Nicht als GSC-Ersatz, sondern als Vervollständigung. Das ist die Investition, die den Bug rückwirkend zur Chance macht.
Quellen
- Google Search Central – Page Indexing Report
- Google Search Central – URL Inspection Tool
- Google Developers – Crawling & Indexing
- YellowFrog-Praxisanalysen 2024–2026.
Allgemeine Information zum Google-Search-Console-Update. Google-Tools und -Reports entwickeln sich laufend weiter; konkrete Ansichten und Features können sich ändern. Keine Rechts- oder Implementierungs-Beratung im Einzelfall. Stand: Juli 2026.
YellowFrog
Sichtbarkeit ist kein Zufall.
Lassen Sie uns gemeinsam prüfen, wie Ihre Marke in Google – und in KI-Antworten – sichtbarer wird. Konkret, messbar, ohne Buzzword-Bingo.
Weiterlesen & passende Leistungen
Verwandte Beiträge
Passende Leistungen