Die Sitemap, die Google sechs Monate lang nicht lesen wollte, und die 14-Sekunden-Lösung

Wenn Google Search Console deinen Sitemap-Index als „Success" anzeigt, während „Entdeckte Seiten" bei null liegt, und die Child-Sitemaps unabhängig davon, wie oft du sie erneut einreichst, bei „Couldn't fetch" steckenbleiben, siehst du wahrscheinlich kein Serverproblem. Du siehst ein Pro-URL-Backoff in Googles Sitemap-Scheduler. Der schnellste Weg, das zu beweisen, ist, dieselbe Datei unter einer leicht anderen URL erneut einzureichen und zu beobachten, was passiert.

Diese Diagnose hat mich sechs Monate, fünf separate Audits und vier verschiedene KI-Modelle gekostet. Der Test, der es endlich klärte, dauerte 14 Sekunden.

Wichtigste Erkenntnis: Ein Sitemap-Index kann „Success" melden, während jede Child-Sitemap darin für Google unsichtbar ist. Wenn deine Edge-Logs keinen Googlebot-Request für ein „Couldn't fetch"-Child zeigen, liegt der Fehler auf Googles Seite, nicht auf deiner. Das erneute Einreichen derselben Datei unter einer versionierten URL wie /sitemap/0.xml?v=20260815 umgeht das Backoff und wird in Sekunden verarbeitet.

Was „Success" wirklich meldete

Die Site ist Deluxe Astrology, die vedische Astrologie-Plattform meiner Eltern und das größte Projekt, das ich betreibe: etwa 240.000 URLs über 30 Sprachen, publiziert aus Supabase und als Sitemap-Index mit 63 Child-Sitemaps darunter bereitgestellt. Die Architektur dahinter beschreibe ich auf der Deluxe Astrology project page.

Indexierte Seiten waren wochenlang gesunken. Impressionen fielen Ende Juni steil ab. Und das eine System, dessen gesamte Aufgabe es ist, Google eine Liste frischer URLs zu geben, zeigte einen grünen Haken.

Öffne den Sitemap-Index in Search Console und er sagt „Sitemap-Index erfolgreich verarbeitet". Klick hinein und die Tabelle „Sitemaps" zeigt 0-0 von 0. Google hatte den Index dreimal über drei Wochen hinweg abgerufen, ihn korrekt als Index geparst und keine seiner Children registriert. Keine einzige Child-Sitemap war je abgerufen worden. Als ich drei davon direkt einreichte, blieben sie stundenlang bei „Couldn't fetch".

Das ist die Falle. Der Status eines Sitemap-Index ist eine Aussage nur über die Index-Datei. Er sagt dir, dass das XML geparst wurde und die Child-URLs gut formatiert aussahen. Er sagt dir nichts darüber, ob Google sie je gelesen hat. Diese Unterscheidung ist in einer Tabelle vergraben, in die die meisten Menschen nie scrollen, und sie ist das ganze Spiel auf jeder Site, die groß genug ist, um einen Sitemap-Index zu brauchen.

Alles auf dem Server war in Ordnung, fünfmal überprüft

Wenn du auf „Couldn't fetch" gestoßen bist, weißt du, wie die nächste Stunde läuft. Du curlst die URL. Du checkst robots.txt. Du checkst die Firewall. Du checkst den CDN-Cache. Du führst den Live-Test in der URL-Inspektion aus. Alles kommt sauber zurück. Also sagst du dir die klassische Search-Console-Lüge: Das braucht einfach Zeit, schau in 24 bis 72 Stunden nach.

Über die Monate hinweg wurde das zu einer wirklich gründlichen Untersuchung, und nicht nur von mir. Ich habe das Problem mehrere Frontier-Modelle als unabhängige Auditors durchlaufen lassen: Claude, Kimi, GLM und ein paar Custom Agents, jeder mit Zugriff auf die Codebase, die Search-Console-Daten und die Edge-Logs. Ich habe zuvor darüber geschrieben, wie sinnvoll es ist, mehrere KI-Modelle gleichzeitig zu laufen, und das war der Fall, der es am härtesten testete.

Sie waren sich über fast alles einig, und sie hatten über fast alles recht:

• Der Live-Sitemap-Index lieferte einen gültigen <sitemapindex> mit allen 63 untergeordneten Elementen, korrektem Content-Type, keiner Byte-Order-Mark und keinen Cross-Host-URLs.
• Jedes untergeordnete Element lieferte einen gültigen <urlset> mit den erwarteten URL-Anzahlen.
• Googlebots eigener Live-Abruf des Index und eines untergeordneten Elements durch URL Inspection lieferten das echte XML. „URL ist für Google verfügbar."
• Die Edge-Logs zeigten echte Googlebot-Anfragen an den Index, die zulässig waren und mit 200 aus dem Cache bedient wurden.
• Nichts in robots.txt, Middleware, Umleitungen oder CDN-Konfiguration berührte die Sitemap-Pfade.

Ein früherer Fehler war real und wurde bereits behoben. Ein Pro-IP-Rate-Limit auf der WAF, das Monate zuvor hinzugefügt wurde, um eine Bot-Farm zu bekämpfen, die meine Hosting-Rechnung in die Höhe trieb, hatte eine Zeit lang Crawler-Traffic herausgefordert. Diese Regel wurde korrigiert. Nach der Korrektur kam jedes Audit zu derselben Schlussfolgerung: Die Serverseite ist sauber, Google braucht Zeit, prüfen Sie in 24 bis 72 Stunden nach.

Fünf Audits. Das gleiche Ergebnis. Die gleiche Empfehlung. Die Zahlen bewegten sich nie.

Das Merkmal war eine Abwesenheit, kein Fehler

Die unbequeme Wahrheit verbarg sich in den Edge-Logs, in dem, was nicht dort war. Nach der Einreichung von drei untergeordneten Sitemaps gab es keine Googlebot-Anfrage für eines von ihnen. Nicht eine zulässige, nicht eine herausgeforderte, nicht eine abgelehnte. Google konnte die untergeordneten Elemente nicht abrufen. Google wählte, es nicht zu versuchen.

Sie können das vom Server aus nicht diagnostizieren, konstruktionsbedingt. Nichts kommt an zum Überprüfen. Jedes Werkzeug im Standard-Kit ist dazu gedacht, eine Anfrage zu erklären, die schief gelaufen ist, und es gab keine Anfrage. Dies ist die eine Klasse von Problemen, die Log-Datei-Analyse durch Auslassung statt durch Beweis löst: Sie suchen nach den Treffern, und die Antwort ist die leere Ergebnismenge.

Der Live-Test der Search Console macht es schlimmer, weil er jeden Planer umgeht, der diese Entscheidung trifft. Er ruft auf Anfrage ab, über einen anderen Code-Pfad, und berichtet freudig „verfügbar" für eine URL, die das Sitemap-Subsystem nie einreihen wird. Ein grüner Live-Test ist kein Beweis dafür, dass die Sitemap-Pipeline die Datei jemals berühren wird.

Die API sagte die Wahrheit, die die Benutzeroberfläche nicht sagte

Die Search Console Sitemaps API lieferte das erste ehrliche Signal. Die Benutzeroberfläche sagt „Konnte nicht abrufen", was wie ein Fehler mit einer Ursache klingt. Die API gibt isPending: true mit errors: 0 und überhaupt keinen lastDownloaded-Zeitstempel zurück.

Das sind unterschiedliche Aussagen. „Konnte nicht abrufen" impliziert einen Abrufversuch, der fehlgeschlagen ist. isPending mit null Fehlern bedeutet, dass nie ein Versuch unternommen wurde. Sechs Monate Debugging zielten auf einen Fehler ab, der nicht vorhanden war.

Wenn Sie etwas im großen Maßstab betreiben, lassen Sie die API verkabeln, bevor Sie sie brauchen. Es ist ein OAuth-Scope und ein paar Codezeilen, und es ist der Unterschied zwischen einer Statuszeichenfolge, die für Beruhigung gedacht ist, und dem tatsächlichen Status des Eintrags. Ich nutze sie intensiv in meinem Claude Code SEO-Audit-Workflow genau aus diesem Grund.

Das kontrollierte Experiment

Statt ein sechstes Audit durchzuführen, führte ich eine Kontrolle durch.

Zuerst eine Baseline. Ich reichte eine Sitemap ein, die Google noch nie zuvor gesehen hatte, eine kleine für einen Seitenabschnitt der Website. Sie wurde 34 Sekunden nach der Einreichung heruntergeladen und verarbeitet. Also war die Pipeline gesund, der Host erreichbar, und Google war bereit, Sitemaps von dieser Domain zu diesem Zeitpunkt abzurufen.

Dann der eigentliche Test. Ich reichte eines der steckengebliebenen untergeordneten Elemente erneut ein, Byte für Byte identisch, bedient von der gleichen Route auf dem gleichen Server, mit genau einem Unterschied: eine Query-Zeichenfolge am Ende. /sitemap/0.xml?v=20260815.

Dieselbe Datei. Derselbe Server. Derselben Bytes. Anderer String. Eine war zweieinhalb Stunden lang unsichtbar und länger, die andere wurde in 14 Sekunden gelesen.

Das ist die gesamte Diagnose, und das ist der Grund, warum ich immer wieder argumentiere, dass ein kontrollierter Test eine weitere Überprüfungsrunde schlägt. Jedes Audit hatte Fakten über den Server bestätigt. Keines hatte die einzige Variable verändert, die sich am Ende als entscheidend herausstellte.

Was tatsächlich geschah

Googles Sitemap-System hielt diese exakten 63 URLs in einem Pro-URL-Fehler-Backoff fest.

Monate zuvor hatte jedes Auslesen des Index einen Schub von 63 Kinder-Abrufen von einer einzelnen Google-IP innerhalb von Sekunden ausgelöst. Das ist normales Googlebot-Verhalten für einen Index: Es liest das übergeordnete Element, dann holt es die untergeordneten Elemente mehr oder weniger auf einmal. Das Pro-IP-Ratenlimit der WAF, bemessen für durchschnittlichen menschlichen Datenverkehr, sah einen Schub von 63 Anfragen von einer Adresse und tat das, wofür es konfiguriert war. Es stellte sie in Frage. Jeden Zyklus. Wochenlang.

Die einzelne Index-Anfrage selbst kam immer durch, weil eine Anfrage kein Schub ist. Das ist, warum der Index weiterhin „Erfolg" anzeigte, während seine untergeordneten Elemente nie in Existenz kamen. Die Regel war perfekt geformt, um genau die URLs zu unterbrechen, die Google am meisten lesen musste, während die eine URL, die über sie berichtet, unberührt blieb.

Das Beheben der Firewall löschte nicht Googles Erinnerung an die URLs, die fehlgeschlagen waren. Es stoppte nur die Erzeugung neuer Fehler. Das Backoff für diese 63 spezifischen Strings überstand die Reparatur, und nichts über das Warten würde es in einem für mich beobachtbaren Zeitrahmen ablaufen lassen.

Die Reparatur: 63 Einreichungen, null Deployments

Über die Search Console API reichte ich alle 63 Kinder mit der Versions-Query-String neu ein. Innerhalb von etwa zwei Minuten war jede einzelne abgerufen und verarbeitet worden: 155.545 URLs bei Google registriert, null Fehler, null Warnungen. Entdeckte Seiten, die ein halbes Jahr lang null angezeigt hatten, wurden während des Beobachtens aufgefüllt.

Die dauerhafte Lösung ist eine Zwei-Zeilen-Änderung in der nächsten Version: Den Sitemap-Index so ausgeben, dass er die versionierten Kinder-URLs ausgibt, sodass der Index und robots.txt auf URLs verweisen, die Google lesen wird. Erhöhen Sie das Versions-Token, sobald sich die Generierungslogik ändert, und Sie erhalten einen Cache-Busting-Mechanismus kostenlos.

Ein ehrlicher Vorbehalt. Indexierung ist nicht Entdeckung. Google durchsucht diesen Host nach Monaten des Misstrauens im Schneckentempo, und 155.000 URLs werden in einer Woche nicht erfasst. Dass die Entdeckung wieder funktioniert, ist die Voraussetzung, nicht das Ergebnis. Wenn Ihr Crawl-Budget bereits knapp ist, ist das Beheben des Sitemaps der Ort, an dem die Arbeit beginnt.

Warum fünf Audits bei der falschen Antwort konvergierten

Das ist der Teil, zu dem ich immer wieder zurückkomme.

Die Modelle waren hervorragend bei der Überprüfung. Bei einer Aussage über Inhaltstyp, Cache-Header, Robots-Direktiven oder Middleware überprüften sie es genau und meldeten es ehrlich. Was keiner von ihnen von selbst tat, war, dieselbe Datei unter einem anderen Namen einzureichen, um zu sehen, was passiert.

Konvergenz auf einen gemeinsamen blinden Fleck sieht genau wie Konsens aus. Fünf Prüfer lesen dieselben Evidenzen mit derselben Annahme – dass ein fehlgeschlagener Abruf einen Abrufversuch impliziert – und werden fünf selbstbewusste Übereinstimmungen und null Fortschritt produzieren. Die Übereinstimmung fühlt sich wie Bestätigung an. Sie ist tatsächlich Korrelation zwischen den Prüfern, nicht zwischen den Prüfern und der Realität.

Was den Stillstand durchbrach, war nicht eine weitere Prüfung. Es war die Entscheidung, dass sechs Monate „72 Stunden warten" eine Hypothese statt ein Plan sind, und die Gestaltung eines Tests, bei dem die einzige Variable die URL-Zeichenkette war. Das ist menschliche Arbeit, und ich glaube nicht, dass sie bald aufhört, eine zu sein.

Die fünf Regeln, die ich mitnahm

• Der Erfolg bei einem Sitemap-Index geht um die Indexdatei, nicht um die untergeordneten Dateien. Scrolle zu „Sitemaps read". Wenn dort null steht, ist der grüne Haken dekorativ.
• „Couldn't fetch" in der UI bedeutet „noch nicht verarbeitet" in der API. Lies die API. isPending und lastDownloaded sind das, was du tatsächlich wissen willst, und die UI zeigt dir beides nicht.
• Google erinnert sich an deine Infrastrukturfehler länger als du. Eine Rate Limit, die den Crawler ein paar Wochen lang herausforderte, kann bestimmte URLs lange nachdem die Regel weg ist in Backoff halten. Zu warten beseitigt es nicht zuverlässig. Eine Versionierung der URL tut es.
• Bemesse Rate Limits für Crawler-Bursts, nicht für durchschnittlichen Traffic. Ein Indexabruf löst N untergeordnete Abrufe von einer IP innerhalb von Sekunden aus. Jedes Pro-IP-Limit unterhalb von N wird genau die URLs herausfordern, die Google am meisten lesen muss, während der Index selbst passiert und Erfolg meldet.
• Wenn mehrere Modelle übereinstimmen, dass der Server sauber ist und du warten solltest, haben sie wahrscheinlich Recht zum Server und Unrecht zum Warten. Führe stattdessen ein Kontrollexperiment durch als eine sechste Prüfung.

Wenn du denkst, dass du dasselbe Problem hast

Arbeite dich in dieser Reihenfolge durch. Es dauert etwa fünfzehn Minuten und es trennt ein Serverproblem von einem Google-seitigen Backoff sauber.

• Öffne den Sitemap-Index in Search Console und lies die Anzahl „Sitemaps read", nicht den Status. Null untergeordnete Dateien gelesen auf einem gesunden Index ist die Signatur.
• Ziehe dieselben Sitemaps durch die Search Console API. Notiere isPending, errors und lastDownloaded für jede.
• Durchsuche deine Edge- oder CDN-Logs nach Googlebot-Anfragen zu den spezifischen untergeordneten Pfaden in den letzten 30 Tagen. Überhaupt keine Anfragen, mit irgendeinem Status, bedeutet, dass das Problem nicht auf deinem Server ist.
• Reiche eine brandneue Sitemap-URL ein, die Google nie zuvor gesehen hat. Wenn sie in unter einer Minute verarbeitet wird, sind dein Host und deine Pipeline in Ordnung.
• Reiche eine festgefahrene untergeordnete Datei mit einer Versionsabfragezeichenkette erneut ein. Wenn diese verarbeitet wird und die einfache URL nicht, hast du deine Antwort und das Mittel im gleichen Schritt.
• Prüfe deine WAF-Rate-Limits gegen Burst-Verhalten, nicht gegen Durchschnitte, damit sich der Backoff nicht selbst wieder aufbaut. Dann überprüfe die übrigen deiner Indexierungsfundamentale bei großen Sites.

Für das Referenzmaterial hinter all dem sind Googles eigener Leitfaden zum Erstellen und Einreichen einer Sitemap und das sitemaps.org-Protokoll immer noch die einzigen zwei Dokumente, die zählen. Keines erwähnt Pro-URL-Backoff, was teilweise erklärt, warum es so lange dauerte.

Wenn du eine Site mit über 100.000 URLs betreibst und du sitzt auf demselben Symptom fest, ist das die Art von Dingen, die ich beruflich mache: technische SEO auf großen Sites, einschließlich der Programmatic-SEO-Builds, wo Sitemaps aufhören, eine Formalität zu sein, und anfangen, der ganze Verteilungskanal zu sein. Ich habe die API-Skripte, die Diagnosesequenz und die Narbengewebe.

FAQ

Warum sagt mein Sitemap-Index „Success", zeigt aber null erkannte Seiten an?

Weil sich der Status nur auf die Indexdatei bezieht. Google hat dein <sitemapindex> geparst und wohlgeformte untergeordnete URLs gefunden, das ist alles, was „Success" behauptet. Ob es diese untergeordneten Dateien dann abgerufen hat, wird separat in der Tabelle „Sitemaps read" gemeldet. Null gelesen auf einem gültigen Index bedeutet, dass die untergeordneten Dateien nie verarbeitet wurden, und der grüne Haken sagt dir nichts Nützliches.

Was bedeutet „Couldn't fetch" eigentlich in der Search Console?

Weniger, als es klingt. In der Search Console API gibt die gleiche Sitemap normalerweise isPending: true mit errors: 0 und keinen lastDownloaded-Wert zurück, was bedeutet, dass Google den Abruf noch nicht versucht hat, anstatt ihn versucht und fehlgeschlagen zu sein. Prüfen Sie die API, bevor Sie Zeit mit dem Debugging eines Fehlers verbringen, der möglicherweise nie aufgetreten ist.

Wie lange sollte ich warten, bevor ich davon ausgehe, dass eine Sitemap wirklich steckengeblieben ist?

Eine Sitemap, die Google bereit ist zu lesen, wird normalerweise in Sekunden bis Minuten verarbeitet, nicht in Tagen. Wenn eine untergeordnete Sitemap länger als etwa 24 Stunden ausstehend ist, während eine brandneue Sitemap-URL auf dem gleichen Host sofort verarbeitet wird, ist Warten keine Strategie. Führen Sie stattdessen den Test zur versionierten erneuten Übermittlung durch.

Führt das Hinzufügen einer Query-Zeichenkette zu einer Sitemap-URL zu doppeltem Inhalt oder anderen SEO-Problemen?

Nein. Eine Sitemap ist eine Erkennungsdatei, keine indexierbare Seite, und die URLs darin sind unverändert. Google behandelt /sitemap/0.xml und /sitemap/0.xml?v=20260815 als zwei unterschiedliche Sitemap-Ressourcen, was genau die Eigenschaft ist, die Sie nutzen. Zeigen Sie Ihren Index und Ihre robots.txt auf die versionierten URLs, damit ein kanonischer Satz im Einsatz ist.

Kann eine WAF-Ratenbegrenzung die Sitemap-Erkennung unterbrechen, ohne etwas anderes zu beeinträchtigen?

Ja, und das macht es so schwer zu erkennen. Das Lesen eines Sitemap-Index löst einen Ausbruch von untergeordneten Abrufen von einer einzelnen Google-IP innerhalb von Sekunden aus, sodass eine Pro-IP-Grenze für menschlichen Traffic die untergeordneten Anfragen herausfordert, während die einzelne Index-Anfrage durchgeht. Alles andere auf der Website, einschließlich Live-URL-Inspektionstests, funktioniert perfekt.

Wird die Behebung der Sitemap verlorene Impressionen sofort wiederherstellen?

Nein. Erkennung und Indexierung sind separate Phasen. Das Registrieren von 155.000 URLs stellt die Eingabe in der Pipeline wieder her, aber die Crawl-Rate auf einem Host, der seit Monaten ausfällt, wird schrittweise wiederhergestellt, und Indexierungsentscheidungen folgen dem Crawling. Rechnen Sie mit Wochen, und nutzen Sie die Zeit, um sicherzustellen, dass die erkannten Seiten indexiert werden sollten.