Derniers événements

Plus de vidéos
Fil d'actualités / Une panne serveur de quelques heures peut coûter trois semaines de crawl : les délais internes dévoilés par Google

Publié le 08/10/2026 à 09:17:14 par Neper

Une panne serveur de quelques heures peut coûter trois semaines de crawl : les délais internes dévoilés par Google

Le 2 octobre 2026 à Barcelone, Gary Illyes a projeté devant les participants du Search Central Live Deep Dive des estimations internes de Google sur les délais nécessaires pour l’exécution d’une vingtaine de processus, du crawl à l’affichage dans les résultats.

Ces chiffres sont beaucoup repris par de nombreux SEOs, mais sans forcément expliquer ce qui est nouveau, ou ce qui est actionnable.

Essayons de faire le tour des vraies informations utiles apportées par les slides de Gary Illyes.

Des estimations, et des moyennes : votre cas peut donner des délais très différents

Les trois slides présentées par Illyes (crawl, indexation, affichage) donnent pour chaque processus un délai minimum, un délai typique et une borne haute, sur une échelle qui va de la seconde à l’année.

Les cas extrêmes, dont tous les « never », sont tracés en pointillés et désignés comme corner cases. Chaque slide porte la même mention : des estimations fondées sur une analyse interne.

Illyes a lui-même relativisé l’exercice auprès de Barry Schwartz (Search Engine Roundtable) : il s’agissait de vérifier si la salle se reconnaissait dans des chiffres tirés de données internes ou s’ils étaient étonnés par ces résultats. Aucune méthodologie n’a été présentée, aucune segmentation par taille ou par type de site non plus.

Une précision d’Illyes conditionne la lecture de tout le reste : les processus sont chaînés. Une page ne peut pas être indexée avant d’avoir été crawlée, et un title ne peut pas changer dans les résultats avant que la page modifiée ait été recrawlée puis retraitée. Les délais s’additionnent.

Le recrawl est (beaucoup) plus lent que la découverte d’une url

Le refresh d’une URL connue prend environ 30 jours en valeur typique, contre environ 20 heures pour la découverte d’une URL nouvelle. Une mise à jour de contenu peut donc rester invisible pendant un mois si rien ne pousse Googlebot à repasser. Corriger une page existante est plus lent que publier une page neuve.

Ces 30 jours sont une valeur typique tous sites confondus, tirée par la masse des URL à faible valeur que Google recrawle rarement. Vos pages stratégiques sont probablement revisitées bien plus souvent. Le rapport Statistiques sur l’exploration de la Search Console et vos logs vous donneront la fréquence réelle, page par page.

Pour raccourcir le délai sur les pages qui comptent :

  • tenez un lastmod exact dans vos sitemaps, mis à jour seulement quand le contenu change. Google traite un sitemap en environ 24 heures, jusqu’à 14 jours dans les cas lents ;
  • placez des liens vers les pages modifiées depuis les pages que Googlebot visite le plus souvent ;
  • utilisez l’inspection d’URL pour les quelques pages prioritaires.

Mesurez ensuite l’effet d’une modification à partir du recrawl constaté dans les logs, pas à partir de la date de mise en ligne.

Quel délai de prise en compte pour vos modifications ?

Une fois la page recrawlée, chaque type de modification a son propre délai de prise en compte. Le tableau ci-dessous reprend les valeurs typiques et propose une fenêtre d’observation avant de tirer une conclusion.

ModificationDélai typique après recrawlFenêtre d’observation conseillée
Title, snippet1 à 2 jours2 semaines
Image du résultat texte1 à 2 semaines3 semaines
Canonique1 à 3 semaines4 semaines
Données structuréesquelques heures à 2 semaines3 semaines
Déménagement de site1 à 3 mois3 mois au minimum

Le délai du title porte sur l’affichage, pas sur le choix : Google peut recrawler votre page en deux jours et continuer à réécrire votre title.

Une panne de quelques heures : des semaines avec un crawl réduit

...