Page-Indexing-Bericht in Search Console repariert
Google hat den Page-Indexing-Bericht in der Google Search Console wiederhergestellt und aktualisiert. Nach mehr als drei Wochen mit Ausfällen, Verzögerungen und unvollständigen Daten liefert das Reporting-Tool erneut belastbare Einblicke in den Indexierungsstatus einzelner URLs. Für SEO-Teams, die täglich auf Search-Console-Daten angewiesen sind, markiert die Wiederherstellung ein wichtiges Signal: Technische Probleme bei zentralen Diagnosewerkzeugen können Audit-Zyklen, Priorisierungen und Eskalationen an Entwicklungsteams spürbar verzögern.
Der Page-Indexing-Bericht gehört zu den meistgenutzten Bereichen der Search Console. Er zeigt, welche URLs Google indexiert hat, welche ausgeschlossen wurden und aus welchem Grund Seiten nicht in den Index gelangen. Anders als reine Crawl-Statistiken fokussiert der Bericht auf den Endzustand der Indexierung – ein entscheidender Unterschied für Technical SEO, Content-Strategie und die Bewertung von Migrationen oder Relaunches.
Was während der Ausfallphase passierte
Über einen Zeitraum von mehr als drei Wochen war der Bericht betroffen: Daten erschienen verspätet, Aktualisierungen blieben aus oder wirkten inkonsistent. In dieser Phase mussten viele Teams auf alternative Signale auswerten – etwa den URL-Inspektionstool-Ergebnissen, serverseitigen Logfiles oder Drittanbieter-Crawlern. Das erhöht den Aufwand und erschwert den Vergleich historischer Trends, weil zentrale KPIs nicht mehr zuverlässig aus einer Quelle stammen.
Gerade bei größeren Websites mit tausenden Unterseiten fehlt ohne den Page-Indexing-Bericht die Übersicht über systematische Muster. Einzelne Fehler lassen sich zwar manuell prüfen, doch Cluster wie „Crawled – currently not indexed“, „Discovered – currently not indexed“ oder „Excluded by noindex tag“ lassen sich nur im aggregierten Bericht effizient priorisieren. Die Ausfallzeit fiel damit in eine Phase, in der viele Properties ohnehin mit Indexierungs-Schwankungen nach Core-Updates oder Template-Änderungen kämpften.
Die Wiederherstellung im Detail
Laut Beobachtungen aus der SEO-Community wurde der Bericht kurz nach Veröffentlichung einer entsprechenden Meldung wieder funktionsfähig. Wer den Report regelmäßig überwacht, konnte die Korrektur nahezu in Echtzeit nachvollziehen – ein Hinweis darauf, wie sensibel Google auf öffentliche Aufmerksamkeit reagieren kann, wenn zentrale Werkzeuge für Webmaster ausfallen. Ob es sich um einen geplanten Rollout, einen Hotfix oder eine Reaktion auf gemeldete Probleme handelte, ließ sich aus Nutzersicht nicht eindeutig ableiten.
Für die Praxis bedeutet die Aktualisierung vor allem: Historische Lücken sollten nun nachgezogen werden. Teams sollten prüfen, ob zwischenzeitlich getroffene Maßnahmen – etwa das Entfernen von noindex-Tags, Anpassungen der robots.txt oder Canonical-Korrekturen – in den aktualisierten Zahlen sichtbar werden. Ein direkter Vergleich der letzten 28 oder 90 Tage mit dem Zeitraum vor der Störung hilft, echte Indexierungsveränderungen von Reporting-Artefakten zu trennen.
Warum der Bericht für Technical SEO unverzichtbar ist
Der Page-Indexing-Bericht bündelt technische und inhaltliche Ausschlussgründe an einem Ort. Typische Statuswerte umfassen indexierte Seiten, Seiten mit Weiterleitungen, Seiten blockiert durch robots.txt, Duplicate-URLs ohne ausgewählte Canonical-Version und Seiten mit Soft-404-Signalen. Für Audits ist diese Aggregation wertvoller als das isolierte Testen einzelner URLs, weil sie Muster auf Template-Ebene sichtbar macht.
Häufige Status und ihre Bedeutung
„Crawled – currently not indexed“ deutet darauf hin, dass Google die Seite gesehen hat, sie aber (noch) nicht indexiert. „Discovered – currently not indexed“ signalisiert, dass die URL bekannt ist, der Crawl aber aussteht oder Google die Indexierung zurückhält. „Blocked by robots.txt“ oder „Blocked due to unauthorized request (401)“ weisen auf klare technische Barrieren hin. Jeder Status erfordert eine andere Priorisierung in Roadmaps und Ticket-Queues.
| Status | Typische Ursache | Erster Schritt |
|---|---|---|
| Crawled – not indexed | Qualität, Duplikate, Crawl-Budget | Content und interne Verlinkung prüfen |
| Discovered – not indexed | Crawl-Priorität, Sitemap, Links | Discovery-Signale stärken |
| Excluded by noindex | Meta-Robots oder HTTP-Header | Tag gezielt entfernen |
| Duplicate without canonical | Fehlende oder widersprüchliche Canonicals | Canonical-Strategie bereinigen |
Empfohlene Schritte nach der Wiederherstellung
Sobald der Bericht wieder stabil läuft, lohnt ein strukturierter Nachcheck. Zuerst sollten Teams den Gesamtstand der indexierten URLs mit dem erwarteten Umfang des sichtbaren Inventars abgleichen. Anschließend empfiehlt sich ein Drill-down in die größten Ausschluss-Cluster. URLs mit hohem Business-Wert, die weiterhin nicht indexiert sind, verdienen eine gezielte Inspektion über das URL-Prüftool und ggf. eine manuelle Indexierungsanfrage – sofern die technischen Voraussetzungen erfüllt sind.
Parallel sollten Sitemap-Einreichungen, interne Verlinkung und Server-Antwortcodes erneut validiert werden. Gerade nach längeren Reporting-Lücken können veraltete Annahmen aus der Ausfallphase zu unnötigen Änderungen geführt haben. Ein dokumentierter Before-After-Snapshot erleichtert die Kommunikation mit Stakeholdern und verhindert Doppelarbeit. Auch die Abstimmung mit Content- und Dev-Teams profitiert, wenn klar ist, welche Statuswerte sich seit der letzten zuverlässigen Messung tatsächlich verändert haben.
- Page-Indexing-Bericht für 28 und 90 Tage neu exportieren und mit Vorwerten vergleichen.
- Größte Ausschluss-Cluster nach URL-Mustern und Templates gruppieren.
- Kritische Money-Pages einzeln im URL-Inspektionstool verifizieren.
- Zwischenzeitliche Maßnahmen gegen aktuelle Statuswerte validieren.
- Monitoring-Alerts für künftige Datenverzögerungen einrichten.
Die Wiederherstellung des Page-Indexing-Berichts entlastet SEO- und Dev-Teams, die in den vergangenen Wochen mit blinden Flecken in der Indexierungsdiagnose arbeiten mussten. Wer den Bericht jetzt systematisch neu auswertet, kann versäumte Priorisierungen nachholen und technische Schulden schneller identifizieren – solange die Datenlage als verlässlich gilt und regelmäßig gegen Stichproben geprüft wird.