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
lastmodexact 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.
| Modification | Délai typique après recrawl | Fenêtre d’observation conseillée |
|---|---|---|
| Title, snippet | 1 à 2 jours | 2 semaines |
| Image du résultat texte | 1 à 2 semaines | 3 semaines |
| Canonique | 1 à 3 semaines | 4 semaines |
| Données structurées | quelques heures à 2 semaines | 3 semaines |
| Déménagement de site | 1 à 3 mois | 3 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
La slide sur le crawl donne une asymétrie nette. La crawl capacity, c’est-à-dire le volume de requêtes que Googlebot s’autorise sur votre serveur, peut chuter en quelques secondes quand le serveur répond mal. Le retour à la normale prend une à trois semaines.
Un incident de quelques heures, une mise en production qui fait monter les temps de réponse ou une vague d’erreurs 5xx se paient donc en semaines de crawl ralenti, avec un effet direct sur le délai de 30 jours décrit plus haut.
Trois réflexes en découlent :
- surveillez les erreurs 5xx et les temps de réponse servis à Googlebot, pas seulement ceux des utilisateurs ;
- pendant une maintenance programmée, renvoyez un code 503 plutôt qu’une page d’erreur en 200 ou une 404, et indiquez une durée avec l’en-tête
Retry-After; - présentez ce chiffre à votre DSI : une à trois semaines de crawl dégradé est un coût qu’elle peut mettre en regard d’un investissement d’infrastructure.
Supprimer vite ou supprimer durablement
L’outil de suppression de la Search Console masque une URL en environ 2 heures, et au plus en 24 heures selon la slide. Un noindex ou une 404 demandent une à trois semaines.
Les deux ne font pas la même chose. L’outil de suppression masque temporairement l’URL, pendant environ six mois selon l’aide de la Search Console. Le noindex ou la 404 la sortent définitivement de l’index une fois la page recrawlée.
En cas d’urgence (fuite de données, contenu juridiquement litigieux, page publiée par erreur), utilisez l’outil pour faire disparaître la page dans l’heure, et posez en même temps le noindex ou la 404 pour que la suppression tienne au-delà des six mois.
Updates : les délais à poser dans un plan de remédiation
Sur la slide d’affichage, le déploiement d’une update constitue le minimum de la ligne : rien ne bouge avant qu’il soit terminé. Comptez deux à quatre semaines pour une core update, un à deux jours pour une spam update.
La récupération après une core update prend typiquement trois à six mois, et jusqu’à un an quand il faut attendre la core update suivante. Ce délai vaut pour les sites qui récupèrent. Il ne dit rien de la probabilité de récupérer.
Pour les spam updates, la slide distingue deux cas. Si le système qui vous a touché fonctionne en continu, une correction produit ses effets en une à deux semaines. S’il procède par rafraîchissements groupés, il faut attendre plusieurs mois. La levée d’une action manuelle prend une à deux semaines après acceptation de la demande de réexamen, nettement plus pour un site resté inactif.
Ces durées sont celles à inscrire dans un plan de remédiation présenté à un client, avant qu’il ne vous demande des résultats au bout d’un mois.
Quand rien ne bouge, c’est la qualité
Le mot « never » revient quatre fois sur les slides : pour la découverte, le refresh, le traitement des sitemaps et l’indexation. Pour les sitemaps et l’indexation, Google l’associe explicitement à la qualité. Ces cas sont tracés en pointillés, comme des exceptions.
Une page bloquée durablement en « Explorée, actuellement non indexée », alors que le crawl fonctionne et que rien ne l’empêche techniquement, a été jugée par Google et écartée. Aucun réglage de sitemap, de maillage ou de demande d’indexation n’y changera rien. Le même jour, Illyes indiquait que Google filtre 40 milliards de pages de spam par jour, et que le contenu produit à grande échelle pose désormais plus de problèmes que le spam de liens.
Pourquoi prendre ces chiffres avec des pincettes
Les chiffres donnés par Gary Illyes sont des agrégations de délais sur de nombreux sites et de nombreux cas. D’ailleurs on ne sait pas s’il nous donne des moyennes, des médianes, des moyennes pondérées, calculées sur un percentile ou non.
Car derrière tout cela, se cache une grande variabilité.
Donc ne vous basez pas sur ces estimations qui ne vous concernent pas forcément, mais essayez d’établir les délais réels pour votre site pour les sujets qui comptent : délai de découverte, de recrawl, d’indexation, de prise en compte des modifs etc… Et vous pourrez les comparer avec les chiffres de Gary (ce sera instructif) mais surtout vous connaîtrez à quelle vitesse crawle, indexe et affiche réellement votre contenu.
Et si certains délais sont trop longs, vous saurez où agir.
Sources
- How long does it take to crawl, index and serve: slides de Gary Illyes (photos), via Search Engine Roundtable
- Google Search Central Live Deep Dive, Barcelona, Day 3 Recap (We Are ROAST, John Campbell)
- Google Search Central : gestion du budget de crawl pour les sites volumineux
- Google Search Central : réduire la fréquence d’exploration de Googlebot
- Google Search Central : interprétation des spécifications robots.txt
- Google Search Central : déplacer un site avec modification des URL
- Google Search Central : les core updates de la recherche Google
- Aide Search Console : outil de suppressions