Crawl, indexation, récupération : les délais présentés par Gary Illyes à Barcelone

L’essentiel

• Il faudrait environ 20 heures pour découvrir une nouvelle URL et environ 24 heures pour traiter un sitemap.
• Une migration de site prendrait 1 à 3 mois, et plus d’un an dans les cas les plus lents.
• La récupération après une core update demanderait 3 à 6 mois, parfois un an.
• Google n’a publié aucun de ces chiffres : ils viennent des notes d’un participant.

Des chiffres connus par un compte rendu

Le Search Central Live Deep Dive Europe, l’événement de trois jours que l’équipe Search Relations de Google consacre aux SEO, tenait sa dernière journée à Barcelone le 2 octobre 2026. Gary Illyes y a montré, pour chaque étape du traitement d’une page, un délai typique et un délai maximal. C’est du moins ce que rapporte John Campbell, responsable innovation de l’agence ROAST, dans son compte rendu de la troisième journée, publié le jour même et illustré de photos de la diapositive.

La présentation comportait aussi une colonne « le plus rapide », que le compte rendu ne reprend pas. Gary Illyes a assorti ses chiffres d’une réserve : la plupart de ces processus dépendent les uns des autres. Tant qu’une page n’a pas été explorée, elle ne peut pas être indexée, et les retards se cumulent. Le compte rendu ne renvoie à aucun support publié par Google. On ignore aussi la méthode derrière ces valeurs : taille de l’échantillon, sens exact du délai « typique » (moyenne, médiane ou estimation).

Crawl : une vingtaine d’heures pour découvrir une URL

Côté exploration, une nouvelle URL serait découverte en 20 heures environ. Dans le pire des cas, il faut des semaines, ou elle ne l’est jamais. Une URL déjà connue serait réexplorée tous les 30 jours environ. Un sitemap serait traité en 24 heures environ, mais cela peut monter à 14 jours, voire ne jamais arriver, avec la mention « qualité » sur la diapositive. Une modification du robots.txt serait prise en compte en 24 heures environ, 25 au maximum.

La capacité de crawl peut, elle, chuter en quelques secondes quand Google lève le pied face à un serveur en difficulté. Sa remontée prendrait de 4 heures à 1 ou 2 semaines, et 1 à 3 semaines en phase de rétablissement. Pour rappel, Google a réécrit sa documentation sur le budget de crawl en juillet.

Indexation et affichage : le tableau récapitulatif

Le tableau ci-dessous retient les délais les plus utiles en pratique, tels que ROAST les a notés.

Étape	Délai typique	Délai le plus long
Découverte d’une nouvelle URL	environ 20 h	des semaines, ou jamais
Réexploration d’une URL connue	environ 30 jours	des semaines, ou jamais
Traitement d’un sitemap	environ 24 h	14 jours, ou jamais (qualité)
Indexation de bout en bout	environ 1 h 30	des mois, ou jamais (qualité)
Changement de canonique	1 à 3 semaines	des mois (signaux contradictoires)
Mise à jour des données structurées	quelques heures à 2 semaines	des semaines, ou jamais (qualité)
Migration de site	1 à 3 mois	6 mois à plus d’un an
Mise à jour du titre ou de l’extrait	1 à 2 jours	plusieurs semaines à plusieurs mois
Suppression demandée dans la Search Console	environ 2 h	24 h
Levée d’une action manuelle	1 à 2 semaines	4 à 6 semaines, bien plus pour un site dormant
Récupération après une core update	3 à 6 mois	6 mois à 1 an (core update suivante)
Effet d’une spam update	1 à 2 semaines (en continu)	des mois (rafraîchissements par lots)

Source : compte rendu de John Campbell (ROAST), 2 octobre 2026, d’après la présentation de Gary Illyes.

D’autres lignes détaillent l’indexation. Le rendu d’une page ne prendrait que quelques secondes, mais l’attente dans la file se compte en heures, parfois en jours ou en semaines. Images et vidéos seraient traitées en quelques heures à quelques jours. Le compte rendu note aussi qu’une core update se déploie en 2 à 4 semaines, contre 1 à 2 jours pour une spam update. D’où un décalage frappant : le déploiement dure un mois au plus, mais la récupération attendrait souvent la core update suivante.

Spam : l’IA mobilisée contre le contenu produit en masse

Le spam occupait une bonne partie de la journée. D’après ROAST, Gary Illyes a avancé un chiffre : Google filtre 40 milliards de pages de spam par jour. Il aurait ajouté que le contenu produit à grande échelle « devient un problème plus important que le spam de liens » (traduction). Duy Nguyen, Search Quality Analyst chez Google, aurait indiqué que son équipe se sert désormais de l’IA pour repérer davantage de spam. S’il y a eu plus de spam updates ces derniers temps, ce serait selon lui parce que le volume de contenus nouveaux a explosé.

Sur Discover, Eric Murillo, analyste Trust and Safety pour Discover chez Google, aurait tordu le cou à une idée reçue : il n’existe pas de robot dédié, Discover s’appuie sur l’index habituel de Google. Il aurait aussi reconnu que le contenu IA de faible qualité gagne du terrain dans le flux. Les signalements des utilisateurs servent de matière première aux nouveaux filtres anti-spam.

Ce que j’en retiens

Ces chiffres n’engagent pas Google. Ce sont des notes prises en salle, sans méthode publiée, et je les prends comme telles. Ils donnent malgré tout des ordres de grandeur que Google chiffre rarement en public, et ils aident à cadrer les attentes avant un chantier. Une refonte d’URL se suit sur trois mois au moins, pas trois semaines. Une baisse liée à une core update ne se rattrape pas en retouchant un article la semaine suivante. Le détail qui me frappe le plus, c’est la mention « jamais (qualité) » sur les sitemaps, l’indexation et les données structurées : sous un certain niveau de qualité, aucun réglage technique ne débloque la situation.

Si une page reste non découverte plusieurs semaines après sa mise en ligne, je regarderais donc la qualité du site avant de soumettre une nouvelle fois le sitemap. Côté serveur, c’est un point à vérifier dans le rapport Statistiques sur l’exploration de la Search Console : une capacité de crawl qui s’effondre en quelques secondes peut mettre des semaines à revenir.