Le sitemap que Google a refusé de lire pendant six mois, et la correction de 14 secondes

Si Google Search Console affiche votre index de sitemap comme Succès alors que les Pages découvertes restent à zéro, et que les sitemaps enfants restent bloqués sur « Impossible à récupérer » peu importe combien de fois vous les renvoyez, vous ne regardez probablement pas un problème de serveur. Vous regardez un backoff par URL à l'intérieur du planificateur de sitemaps de Google. Le moyen le plus rapide de le prouver est de renvoyer le fichier identique sous une URL légèrement différente et regarder ce qui se passe.

Ce diagnostic m'a pris six mois, cinq audits séparés et quatre modèles IA différents. Le test qui l'a finalement confirmé a pris 14 secondes.

Point clé : un index de sitemap peut afficher Succès alors que chaque sitemap enfant qu'il contient est invisible pour Google. Si vos journaux edge ne montrent aucune requête de Googlebot pour un enfant « Impossible à récupérer », l'échec vient de Google, pas de vous. Renvoyer le même fichier sous une URL versionnée comme /sitemap/0.xml?v=20260815 contourne le backoff et traite en secondes.

Ce que « Succès » rapportait réellement

Le site est Deluxe Astrology, la plateforme d'astrologie védique de mes parents et la plus grande chose que je gère : environ 240 000 URL dans 30 langues, publiées depuis Supabase et servies comme un index de sitemap avec 63 sitemaps enfants. J'écris sur l'architecture qui le sous-tend sur la page du projet Deluxe Astrology.

Les pages indexées baissaient depuis des semaines. Les impressions se sont effondrées fin juin. Et le système dont tout le travail est de remettre une liste d'URL frais à Google affichait une coche verte.

Ouvrez l'index de sitemap dans Search Console et il dit « Index de sitemap traité avec succès ». Cliquez dessus et le tableau Sitemaps lus dit 0-0 sur 0. Google avait récupéré l'index trois fois en trois semaines, l'avait correctement analysé comme un index, et n'avait enregistré aucun de ses enfants. Pas un seul sitemap enfant n'avait jamais été récupéré. Quand j'en ai soumis trois directement, ils sont restés sur « Impossible à récupérer » pendant des heures.

C'est le piège. Le statut sur un index de sitemap est une déclaration sur le fichier index uniquement. Il vous dit que le XML a été analysé et que les URL enfants avaient l'air bien formées. Il ne vous dit rien sur si Google est jamais allé les lire. Cette distinction est enterrée dans un tableau que la plupart des gens ne font jamais défiler, et c'est tout l'enjeu sur tout site assez grand pour avoir besoin d'un index de sitemap.

Tout sur le serveur a été validé, cinq fois séparément

Si vous avez rencontré « Impossible à récupérer », vous savez comment l'heure suivante va se passer. Vous faites un curl de l'URL. Vous vérifiez robots.txt. Vous vérifiez le firewall. Vous vérifiez le cache CDN. Vous exécutez le test en direct dans l'Inspection d'URL. Tout revient en ordre. Alors vous vous dites le mensonge classique de Search Console : il faut juste du temps, revenez dans 24 à 72 heures.

Au fil des mois, cela est devenu une véritable enquête approfondie, et pas seulement de ma part. J'ai soumis le problème à plusieurs modèles de pointe en tant qu'auditeurs indépendants : Claude, Kimi, GLM et quelques agents personnalisés, chacun avec accès à la base de code, aux données Search Console et aux journaux edge. J'ai écrit avant sur le nombre de modèles IA qui valent réellement la peine d'exécuter en même temps, et c'était le cas qui l'a testé le plus durement.

Ils ont convenu sur presque tout, et ils avaient raison sur presque tout :

• L'index de sitemap actif servait un <sitemapindex> valide avec tous les 63 enfants, type de contenu correct, pas de marque d'ordre d'octet, pas d'URL entre hôtes.
• Chaque enfant servait un <urlset> valide avec les nombres d'URL attendus.
• La récupération en direct de Googlebot de l'index et d'un enfant, via l'inspection des URL, a retourné le vrai XML. « L'URL est disponible pour Google. »
• Les logs edge ont montré des requêtes Googlebot réelles à l'index autorisées et servies 200 depuis le cache.
• Rien dans robots.txt, les middlewares, les redirections ou la config CDN n'a touché aux chemins du sitemap.

Une erreur antérieure était réelle et avait déjà été corrigée. Une limite de débit par IP sur le WAF, ajoutée des mois plus tôt pour combattre une ferme de bots qui explosait ma facture d'hébergement, avait pendant un temps défié le trafic des crawlers. Cette règle a été corrigée. Après la correction, chaque audit a tiré la même conclusion : le serveur est propre, Google a besoin de temps, vérifiez dans 24 à 72 heures.

Cinq audits. Même verdict. Même recommandation. Les chiffres n'ont jamais bougé.

L'indice était une absence, pas une erreur

Le fait inconfortable se cachait dans les logs edge, dans ce qui n'y était pas. Après avoir soumis trois sitemaps enfants, il n'y a eu aucune requête Googlebot pour aucun d'eux. Pas une autorisée, pas une défiée, pas une refusée. Google ne les récupérait pas en échec. Google choisissait de ne pas essayer.

Vous ne pouvez pas diagnostiquer cela du serveur, par construction. Rien n'arrive à inspecter. Chaque outil du kit standard est conçu pour expliquer une requête qui a mal tourné, et il n'y avait pas de requête. C'est la seule classe de problème que l'analyse des fichiers journaux résout par omission plutôt que par preuve : vous cherchez les hits, et la réponse est l'ensemble de résultats vide.

Le test en direct de Search Console aggrave les choses, car il contourne le scheduler qui fait ce choix. Il récupère à la demande, depuis un chemin de code différent, et rapporte joyeusement « disponible » pour une URL que le sous-système sitemap ne mettra pas en file d'attente. Un test en direct vert n'est pas la preuve que le pipeline sitemap ne touchera jamais le fichier.

L'API disait la vérité que l'UI ne dirait pas

L'API Search Console Sitemaps a donné le premier signal honnête. L'UI dit « Impossible à récupérer », ce qui se lit comme un échec avec une cause. L'API retourne isPending: true avec errors: 0 et aucun timestamp lastDownloaded du tout.

Ce sont des affirmations différentes. « Impossible à récupérer » implique une tentative qui a échoué. isPending avec zéro erreur signifie aucune tentative n'a jamais été faite. Six mois de débogage avaient visé un échec qui n'existait pas.

Si vous gérez quelque chose à l'échelle, mettez l'API en place avant d'en avoir besoin. C'est une portée OAuth et quelques lignes de code, et c'est la différence entre une chaîne de statut conçue pour rassurer et l'état réel de l'enregistrement. Je m'en appuie fortement dans mon workflow d'audit Claude Code SEO pour exactement cette raison.

L'expérience contrôlée

Plutôt que de faire un sixième audit, j'ai fait un contrôle.

D'abord, une baseline. J'ai soumis un sitemap que Google n'avait jamais vu, un petit pour une section annexe du site. Il a été téléchargé et traité 34 secondes après la soumission. Le pipeline était donc sain, l'hôte était accessible, et Google était disposé à récupérer les sitemaps de ce domaine en ce moment.

Ensuite le vrai test. J'ai resomis un des enfants bloqués, octet pour octet identique, servi par la même route sur le même serveur, avec exactement une différence : une query string à la fin. /sitemap/0.xml?v=20260815.

Même fichier. Même serveur. Mêmes octets. Chaîne différente. L'un était invisible depuis deux heures et demie et le compte continue, l'autre a été lu en 14 secondes.

C'est tout le diagnostic, et c'est la raison pour laquelle je continue d'affirmer qu'un test contrôlé vaut mieux qu'une nouvelle vérification. Chaque audit avait confirmé des faits sur le serveur. Aucun n'avait fait varier le seul paramètre qui s'avérait important.

Ce qui s'est réellement passé

Le système de sitemap de Google maintenait ces 63 URLs exactes dans un backoff d'échec par URL.

Des mois auparavant, chaque lecture de l'index déclenchait une rafale de 63 accès enfants depuis une seule adresse IP Google en quelques secondes. C'est un comportement normal de Googlebot pour un index : il lit le parent, puis va chercher les enfants plus ou moins en même temps. La limite de débit par IP sur le WAF, dimensionnée pour le trafic humain moyen, a vu une rafale de 63 requêtes depuis une adresse et a fait ce pour quoi elle était configurée. Elle les a défiées. À chaque cycle. Pendant des semaines.

La seule requête d'index elle-même passait toujours, car une requête ne constitue pas une rafale. C'est pourquoi l'index affichait constamment « Succès » tandis que ses enfants n'ont jamais existé. La règle était parfaitement conçue pour bloquer exactement les URLs que j'avais le plus besoin que Google lise, tout en laissant intacte l'URL qui en rend compte.

Corriger le pare-feu n'a pas effacé la mémoire de Google des URLs qui avaient échoué. Cela a seulement arrêté la création de nouveaux échecs. Le backoff sur ces 63 chaînes spécifiques a survécu à la correction, et rien concernant l'attente ne l'aurait expiré sur une échelle de temps que je pouvais observer.

La correction : 63 soumissions, zéro déploiements

Via l'API Search Console, j'ai soumis à nouveau les 63 enfants avec la chaîne de requête de version. En environ deux minutes, chacun d'eux avait été récupéré et traité : 155 545 URLs enregistrées chez Google, zéro erreur, zéro avertissement. Les pages découvertes, qui affichaient zéro depuis six mois, se sont remplies sous mes yeux.

La correction durable est une modification de deux lignes dans la prochaine version : faire en sorte que l'index du sitemap émette les URLs enfants avec version, pour que l'index et robots.txt pointent vers des URLs que Google est disposé à lire. Augmentez le token de version chaque fois que la logique de génération change et vous obtenez gratuitement un mécanisme de cache-busting propre.

Une véritable mise en garde. L'indexation n'est pas la découverte. Google explore cet hôte au ralenti après des mois de méfiance, et 155 000 URLs ne sont pas balayées en une semaine. La découverte fonctionnant à nouveau est la condition préalable, pas le résultat. Si votre crawl budget est déjà réduit, corriger le sitemap est là que le travail commence.

Pourquoi cinq audits ont convergé vers la mauvaise réponse

C'est la partie sur laquelle je reviens constamment.

Les modèles étaient excellents pour la vérification. Donnée une affirmation sur le type de contenu, les en-têtes de cache, les directives robots ou les middlewares, ils l'ont vérifiée avec précision et l'ont rapportée honnêtement. Ce qu'aucun d'eux n'a fait, de lui-même, était de proposer de soumettre le même fichier sous un nom différent pour voir ce qui se passerait.

La convergence sur un point aveugle partagé ressemble exactement à un consensus. Cinq auditeurs lisant la même preuve avec la même supposition, qu'un échec de récupération implique une tentative de récupération, produiront cinq accords confiants et zéro progrès. L'accord a l'impression d'une confirmation. C'est en réalité une corrélation entre les auditeurs, pas entre les auditeurs et la réalité.

Ce qui a dénoué l'impasse n'était pas un autre audit. C'était de décider que six mois « attendez 72 heures » était une hypothèse plutôt qu'un plan, et de concevoir un test où la seule variable était la chaîne d'URL. C'est un travail humain, et je ne pense pas que ça cesse d'en être un de sitôt.

Les cinq règles que j'en ai tiré

• Le succès d'un index de sitemap dépend du fichier index, pas des enfants. Allez à « Sitemaps lus ». Si le nombre est zéro, la coche verte est purement cosmétique.
• « Impossible de récupérer » dans l'interface signifie « pas encore traité » dans l'API. Lisez l'API. isPending et lastDownloaded sont ce que vous avez réellement besoin de connaître, et l'interface ne vous montre ni l'un ni l'autre.
• Google se souvient de vos erreurs d'infrastructure plus longtemps que vous. Un limite de débit qui a ralenti le crawler pendant quelques semaines peut laisser des URLs spécifiques en backoff bien longtemps après la suppression de la règle. Attendre n'efface pas cela de façon fiable. Versionner l'URL, oui.
• Dimensionnez les limites de débit pour les rafales du crawler, pas le trafic moyen. Une lecture d'index déclenche N requêtes enfants depuis une seule IP en quelques secondes. Toute limite par IP inférieure à N va mettre en backoff exactement les URLs que vous voulez le plus que Google lise, tandis que l'index lui-même passe et rapporte un succès.
• Quand plusieurs modèles s'accordent à dire que le serveur est propre et que vous devez attendre, ils ont probablement raison sur le serveur et tort sur l'attente. Lancez un contrôle au lieu d'un sixième audit.

Si vous pensez avoir le même problème

Progressez dans cet ordre. Cela prend environ quinze minutes et cela sépare proprement un problème de serveur d'un backoff côté Google.

• Ouvrez l'index de sitemap dans Search Console et lisez le nombre Sitemaps lus, pas le statut. Zéro enfants lus sur un index sain, c'est la signature.
• Tirez les mêmes sitemaps par l'API Search Console. Notez isPending, errors et lastDownloaded pour chacun.
• Cherchez dans vos logs edge ou CDN les requêtes Googlebot vers les chemins enfants spécifiques au cours des 30 derniers jours. Aucune requête du tout, quel que soit le statut, signifie que le problème n'est pas sur votre serveur.
• Soumettez une URL de sitemap complètement nouvelle que Google n'a jamais vue. Si elle se traite en moins d'une minute, votre hôte et votre pipeline vont bien.
• Resoumettez un enfant coincé avec une chaîne de requête de version. Si cela se traite et que l'URL simple ne se traite pas, vous avez votre réponse et le remède en même temps.
• Auditez vos limites de débit WAF contre le comportement en rafales, pas les moyennes, pour que le backoff ne se reconstruise pas. Ensuite, vérifiez le reste de vos fondamentaux d'indexation sur les gros sites.

Pour la documentation de référence derrière tout cela, le guide de Google sur la construction et la soumission d'un sitemap et le protocole sitemaps.org restent les deux seuls documents qui comptent. Aucun ne mentionne le backoff par URL, ce qui explique en partie pourquoi cela a pris si longtemps.

Si vous gérez un site au-delà de 100 000 URLs et que vous êtes bloqué sur le même symptôme, c'est le genre de chose que je fais dans ma vie : SEO technique sur les gros sites, y compris les constructions de SEO programmatique où les sitemaps cessent d'être une formalité et deviennent tout le canal de distribution. J'ai les scripts API, la séquence de diagnostic et l'expérience.

FAQ

Pourquoi mon index de sitemap dit Succès mais affiche zéro pages découvertes ?

Parce que le statut ne concerne que le fichier index. Google a analysé votre <sitemapindex> et trouvé des URLs enfants bien formées, c'est tout ce que « Succès » affirme. Le fait qu'il ait ensuite récupéré ces enfants est rapporté séparément dans la table Sitemaps lus. Zéro lus sur un index valide signifie que les enfants n'ont jamais été traités, et la coche verte ne vous dit rien d'utile.

Que signifie réellement « Impossible de récupérer » dans Search Console ?

Moins que cela n'en a l'air. Dans l'API Search Console, le même sitemap retourne généralement isPending: true avec errors: 0 et pas de valeur lastDownloaded, ce qui signifie que Google n'a pas tenté la récupération plutôt que l'avoir tenté et échoué. Vérifiez l'API avant de consacrer du temps à déboguer un échec qui n'a peut-être jamais eu lieu.

Combien de temps dois-je attendre avant de supposer qu'un sitemap est vraiment bloqué ?

Un sitemap que Google est disposé à lire se traite généralement en secondes ou minutes, pas en jours. Si un sitemap enfant est en attente depuis plus de 24 heures environ tandis qu'une toute nouvelle URL de sitemap sur le même hôte se traite immédiatement, attendre plus longtemps n'est pas une stratégie. Exécutez plutôt le test de resoumission versionnée.

Ajouter une chaîne de requête à une URL de sitemap cause-t-il du contenu dupliqué ou d'autres problèmes SEO ?

Non. Un sitemap est un fichier de découverte, pas une page indexable, et les URL qu'il contient sont inchangées. Google traite /sitemap/0.xml et /sitemap/0.xml?v=20260815 comme deux ressources de sitemap distinctes, ce qui est précisément la propriété que vous exploitez. Pointez votre index et robots.txt vers les URL versionnées pour qu'il y ait un seul ensemble canonique en jeu.

Un limiteur de débit WAF peut-il bloquer la découverte de sitemap sans casser autre chose ?

Oui, et c'est ce qui rend si difficile à détecter. La lecture d'un index de sitemap déclenche une rafale de récupérations enfants à partir d'une seule adresse IP Google en quelques secondes, donc une limite par adresse IP dimensionnée pour le trafic humain mettra en défi les enfants tandis que la requête d'index unique passe. Tout le reste du site, y compris les tests d'inspection d'URL en direct, continue de fonctionner parfaitement.

Corriger le sitemap restaurera-t-il immédiatement les impressions perdues ?

Non. La découverte et l'indexation sont des étapes distinctes. Faire enregistrer 155 000 URL restaure l'entrée au pipeline, mais le taux de crawl sur un hôte qui a échoué pendant des mois se rétablit graduellement, et les décisions d'indexation suivent le crawling. Attendez-vous à des semaines, et utilisez ce temps pour vous assurer que les pages découvertes valent la peine d'être indexées.