Le 2 octobre 2026, à Barcelone, Gary Illyes a montré à l’écran des tableaux internes que Google n’avait jamais présentés sous cette forme : des ordres de grandeur temporels pour une dizaine d’étapes du crawl et de l’indexation, de la découverte d’une page neuve jusqu’à la récupération après une mise à jour majeure. L’événement s’appelle le Search Central Live Deep Dive Europe, et c’est sa troisième journée, consacrée à l’indexation et à la récupération, qui livre le détail le plus complet. Le compte-rendu le plus riche vient de John Campbell, responsable innovation chez l’agence ROAST, présent dans la salle : son récapitulatif en trois volets détaille des délais pour le traitement du sitemap, la mise à jour du robots.txt, la capacité de crawl ou l’indexation de bout en bout, un niveau de granularité que les reprises presse françaises et américaines n’ont pas repris en entier.
Un point mérite d’être posé avant les chiffres eux-mêmes : ces tableaux ont été montrés à l’oral, en conférence, pas publiés comme une documentation officielle. Campbell lui-même précise ne pas connaître la méthode exacte derrière ces chiffres (moyenne, médiane, taille de l’échantillon), et les slides ne figurent pas sur la page officielle des événements Search Central au moment de la rédaction. Ce sont des repères donnés par Google à l’oral, pas des délais garantis.
Table des matières
Avant l’indexation, tout commence par le crawl
La première série de chiffres couvre ce qui se passe avant même qu’une page entre dans l’index : sa découverte, sa relecture, et les signaux qui gouvernent la fréquence de passage de Googlebot.
- Découverte d’une URL neuve : environ 20 heures en cas typique, de plusieurs semaines à jamais si le crawl est lent.
- Recrawl d’une URL déjà connue : environ 30 jours en cas typique, là aussi jusqu’à jamais en cas lent.
- Traitement d’un sitemap : environ 24 heures en cas typique, jusqu’à 14 jours ou jamais en cas lent.
- Mise à jour du fichier robots.txt : environ 24 heures en cas typique, 25 heures en cas lent, l’écart le plus resserré de toute la liste.
- Mise à jour de la capacité de crawl allouée au site : de 4 heures à 1-2 semaines en cas typique, 1 à 3 semaines si Google doit la faire remonter après une baisse.
Le robots.txt est à part dans cette liste : son délai de prise en compte est quasiment fixe (24 à 25 heures), ce qui en fait l’un des rares leviers de cette chaîne où l’on peut prédire l’effet d’une modification avec une marge de quelques heures. Pour tout le reste, l’écart entre le cas typique et le cas lent se compte en semaines, parfois en « jamais ».
Une fois crawlée, une page suit encore six étapes
Le crawl n’est qu’une porte d’entrée. Une fois une page récupérée, Google doit encore la rendre, l’annoter, puis décider de l’indexer, avant que le moindre changement de canonicalisation ou de structure du site ne produise un effet visible.
- Rendu de la page : quelques secondes de calcul, mais des heures d’attente en file selon la charge, et jusqu’à plusieurs semaines en cas lent.
- Annotations meta (noindex, canonical déclaré) : 45 à 90 minutes en cas typique, 1 à 4 jours en cas lent.
- Annotations de liens : de quelques minutes à 1-3 semaines en cas typique, plusieurs mois en cas lent.
- Indexation de bout en bout : environ 1h30 en cas typique, des mois ou jamais en cas lent.
- Suppression ou changement de canonicalisation : 1 à 3 semaines en cas typique, plusieurs mois en cas lent.
- Migration d’un site : 1 à 3 mois en cas typique, de 6 mois à plus d’un an en cas lent.
Le chiffre qui surprend le plus est sans doute l’indexation de bout en bout : 1h30 en cas typique, un délai bien plus court que l’image, répandue chez les éditeurs de sites, d’une indexation qui prendrait systématiquement plusieurs jours. Le problème n’est presque jamais cette étape finale, il est presque toujours en amont, dans le crawl ou dans les signaux qui le conditionnent.
Pourquoi un retard en amont coûte plus cher qu’il n’y paraît
Campbell souligne un point que les reprises presse ont peu développé : ces étapes sont chaînées, pas indépendantes. Une page ne peut pas être indexée avant d’avoir été crawlée, et elle ne peut pas être crawlée si le robots.txt la bloque ou si le sitemap qui la référence met deux semaines à être traité. Chaque retard pris en amont se répercute sur la suite, et les retards s’additionnent au lieu de se compenser.
Prenons un artisan plombier qui publie une nouvelle page de service, « débouchage de canalisation à Lyon ». Si son sitemap est à jour et son robots.txt correctement réglé, la page suit le chemin rapide : découverte en moins d’une journée, puis indexation en une heure et demie une fois crawlée, soit un délai total de l’ordre d’une journée. Si en revanche le sitemap n’a pas été régénéré après la publication, ou si une règle du robots.txt bloque par erreur le répertoire des pages de service, la page attend d’abord le prochain passage de Googlebot sur une URL qu’il ne sait pas encore chercher, avant même d’entrer dans le compte à rebours de l’indexation. Le même contenu, publié de la même façon, peut ainsi mettre un jour ou plusieurs semaines à apparaître, selon une seule case cochée ou non en amont.
Le mot « jamais » n’est pas une panne à corriger
Le mot « jamais » revient dans plusieurs lignes du tableau de Google : une URL découverte, recrawlée, traitée par sitemap ou indexée « jamais ». Gary Illyes relie explicitement ce cas à un problème de qualité du contenu, pas à une panne d’infrastructure. Une page que Google ne crawle ni n’indexe jamais n’est, la plupart du temps, pas victime d’un bug technique : elle n’a tout simplement pas convaincu Google qu’elle méritait la dépense de ressources que représente son traitement. C’est le même mécanisme que celui déjà détaillé sur ce blog à propos de la perte de confiance d’un site aux yeux de Google : en dessous d’un certain niveau de confiance, certaines pages cessent purement et simplement d’être traitées.
Ce que ces chiffres ne sont pas
Deux reprises indépendantes, chez abondance.com et Search Engine Journal, confirment les chiffres les plus parlants de ce tableau (découverte, recrawl, migration, récupération), ce qui écarte l’hypothèse d’une erreur de transcription isolée. Mais aucune des deux ne lève l’incertitude sur la méthode : on ignore si ces durées sont des moyennes ou des médianes, sur quel échantillon de sites elles ont été calculées, et quelle définition Google retient pour le cas « typique ». Transformer un chiffre typique en promesse serait un contresens : écrire qu’une page sera indexée en 1h30 reviendrait à ignorer qu’une partie des cas se compte en mois, voire jamais. Ces chiffres sont des repères d’ordre de grandeur, pas un engagement de délai.
La récupération après une core update, le délai le plus long
Le chiffre le plus lourd de conséquences pour un site qui a perdu du trafic concerne la récupération après une mise à jour majeure de l’algorithme (une core update) : 3 à 6 mois en cas typique, et de 6 mois à un an en cas lent, le temps, dans ce dernier cas, qu’une nouvelle mise à jour majeure vienne réévaluer le site. C’est un délai bien plus long que celui de l’indexation d’une page isolée, logique puisqu’il s’agit ici d’une réévaluation de l’ensemble d’un site, pas du traitement d’une seule URL. Une boutique en ligne qui a vu son trafic chuter après une core update de printemps ne doit donc pas s’attendre à un retour avant l’été au mieux, et parfois pas avant la core update suivante.
Ce qu’il faut vérifier avant de s’inquiéter
Face à une page qui met du temps à apparaître, l’ordre de vérification suit la chaîne plutôt que de sauter directement à l’indexation. D’abord le fichier robots.txt, à tester avec l’outil d’inspection d’URL de la Google Search Console pour confirmer qu’aucune règle ne bloque la page. Ensuite le sitemap XML, qui doit lister la page concernée et avoir été soumis après sa publication, pas seulement généré. Enfin le rapport de couverture d’index, qui indique si Google a effectivement tenté de crawler la page et pour quelle raison il ne l’a pas indexée, le cas échéant. Si la page est bien accessible, bien référencée dans le sitemap, et qu’elle reste malgré tout hors de l’index après plusieurs semaines, la question à se poser n’est plus technique : c’est celle de savoir ce que cette page apporte de plus que les milliers d’autres qui traitent le même sujet.
Crédits photo : Pixabay/JESHOOTS-com, Pixabay/cookieone, Pixabay/StartupStockPhotos.
