Un client nous appelle parce qu'un assistant annonce un tarif qu'il a abandonné il y a huit mois. La page a été corrigée. Elle est en ligne, propre, à jour. Et la réponse générée, elle, n'a pas bougé.
Ce décalage n'est pas un bug. C'est la conséquence d'une chaîne que presque aucun conseil GEO ne décompose : entre votre modification et la phrase qu'un assistant produit, il y a trois délais successifs, chacun avec sa propre durée, ses propres leviers, et pour deux d'entre eux aucune documentation publique. Il y a aussi une quatrième couche qui, elle, ne bougera pas avant plusieurs mois quoi que vous fassiez.
Cet article traite de ce qui est réellement documenté sur ces délais, de la différence entre une mise à jour qui déplace une réponse et une mise à jour qui ne fait rien, et d'une méthode simple pour mesurer votre latence réelle plutôt que de la deviner.
Ce que Google dit vraiment des dates
Commençons par écarter le réflexe le plus répandu, celui qui consiste à changer la date affichée pour signaler de la fraîcheur.
Les règles de Google pour les pages d'articles sont explicites. Le centre d'aide Publisher Center autorise la remise à jour d'une date quand le fond change, puis pose la limite : « If an article has been substantially changed, it can make sense to give it a fresh date and time. However, it's against our guidelines to artificially freshen a story when the publisher didn't add significant information or demonstrated a compelling reason. » Le même document interdit la manœuvre voisine : « It's also against our guidelines to create a very slightly updated story from a previously published one, then delete the old story and redirect to the new one. »
La documentation sur les dates de publication ajoute deux points utiles. D'abord, la cohérence est une exigence : « Ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values. » Ensuite, et c'est ce qui ruine la stratégie du balisage seul, Google déclare ne pas se fier à une source unique : « Google doesn't depend on a single date factor because all factors can be prone to issues. » Autrement dit, votre dateModified est un signal parmi plusieurs, confronté au texte de la page et à ce que le moteur a lui-même observé lors de ses passages précédents.
Le même principe gouverne le lastmod de votre sitemap. La documentation de Google sur les sitemaps le dit sans détour : « Google uses the <lastmod> value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate. » Et elle précise ce qui compte comme changement : « An update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not. »
Retenez la mécanique derrière ces trois citations. Un moteur compare ce que vous déclarez à ce qu'il constate. Un site qui remonte tous ses lastmod chaque nuit n'obtient pas des recrawls plus fréquents, il obtient un signal que le moteur cesse de lire.
Trois délais, et une couche qui ne bougera pas
Voici la chaîne réelle, telle qu'elle se décompose quand on cherche à comprendre pourquoi une correction n'apparaît pas.
| Couche | Ce qui s'y passe | Ce qui est documenté | Ce que vous pouvez faire |
|---|---|---|---|
| 1. Recrawl | Un robot revient chercher la page modifiée | Google : « several days to several months » | Sitemap exact, liens internes, IndexNow hors Google |
| 2. Réindexation | La page est redécoupée, ses vecteurs recalculés | Rien, chez aucun moteur | Rendre le changement substantiel |
| 3. Génération | La réponse est produite, parfois depuis un cache | Rien, chez aucun moteur | Rien |
| 4. Poids du modèle | Ce que le modèle « sait » sans chercher | Dates de coupure des modèles | Attendre la version suivante |
Le seul chiffre officiel de ce tableau vient du guide Google sur les fonctionnalités IA, et il mérite d'être lu littéralement : « Remember that crawling can take anywhere from several days to several months, depending on how often our systems determine a page needs to be refreshed. » Plusieurs mois, c'est bien dans la fourchette annoncée par Google lui-même, pour son propre crawl, sur son propre index. Le même document rappelle la condition d'entrée aux surfaces génératives : « To be eligible to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet, fulfilling the Search technical requirements. »
Les couches 2 et 3 sont un trou noir documentaire. Aucun moteur ne publie le délai entre le passage de son robot et la disponibilité de la nouvelle version pour la génération, ni la durée de vie de ses caches de réponse. Nous n'avons pas d'estimation à vous proposer, et il faut se méfier de celles qui circulent : elles sont presque toujours obtenues sur un seul site, sur une seule requête, sans contrôle.
La couche 4 est celle que l'on confond le plus souvent avec les autres. Quand un modèle répond de mémoire, sans consulter le web, il restitue ce qu'il a appris à l'entraînement. Aucune correction sur votre site ne change cela avant la génération suivante du modèle. C'est le mécanisme qui explique la persistance des erreurs les plus tenaces, et nous le détaillons dans notre article sur les hallucinations IA à propos d'une marque.
Ce que chaque moteur fait de votre mise à jour
L'état de la documentation, moteur par moteur, au 21 août 2026. La colonne de droite est celle qui compte : elle dit ce que vous pouvez vérifier vous-même.
| Moteur | Robot de recherche | Cadence de recrawl publiée | Vérifiable de votre côté |
|---|---|---|---|
| Google, AI Overviews et AI Mode | Googlebot | Fourchette « days to months » | Oui, date de dernier crawl dans la Search Console |
| Microsoft Copilot | Bingbot | Non publiée | Oui, Bing Webmaster Tools et soumission IndexNow |
| ChatGPT | OAI-SearchBot | Non publiée | Partiellement, par les logs serveur |
| Claude | Claude-SearchBot | Non publiée, Crawl-delay accepté |
Partiellement, par les logs serveur |
| Perplexity | PerplexityBot | Non publiée | Partiellement, par les logs serveur |
Un détail documenté par OpenAI donne un ordre de grandeur intéressant sur la vitesse de propagation de ses systèmes. Sa page sur les robots précise, à propos d'un changement de robots.txt, qu'« it can take ~24 hours from a site's robots.txt update for our systems to adjust ». C'est un délai sur une règle d'accès, pas sur du contenu, donc il ne dit rien de votre correction de tarif. Mais il indique que l'ordre de grandeur des cycles internes se compte en jours, pas en heures.
Deux moteurs se distinguent par ce qu'ils vous montrent. Google expose une date de dernier crawl par URL. Microsoft, comme nous l'expliquons dans notre article sur le référencement Copilot, est le seul à donner une visibilité directe sur ses citations. Pour les autres, votre journal serveur est la seule source de vérité disponible.
Le seul accélérateur documenté ne fonctionne pas chez Google
Il existe un protocole conçu exactement pour le problème de la couche 1 : IndexNow. Le principe est une notification push, votre serveur signale au moteur qu'une URL a changé, au lieu d'attendre son prochain passage.
Les chiffres publiés par Microsoft dans son bilan d'adoption de décembre 2024 donnent l'échelle du dispositif : « There are currently over 3.5 billion URLs submitted per day », et les URL soumises par ce canal représentaient alors « 18% of all new URLs clicked in web search results ». Ces chiffres viennent de l'éditeur du protocole et concernent le web entier, pas votre site : ils établissent que le canal est massivement utilisé, pas qu'il produira un effet chez vous.
Le protocole est consommé par Bing, Yandex, Naver, Seznam et Yep. Google ne le consomme pas. C'est la limite décisive, et elle est structurante pour un plan de mise à jour : sur les surfaces Google, qui sont celles où se joue l'essentiel du volume en France, vous n'avez pas d'accélérateur push. Vous avez un sitemap exact, des liens internes qui pointent vers la page modifiée, et la patience.
Il faut aussi tenir compte de la chaîne d'approvisionnement des index. Le crawl de Bing alimente Copilot, ce qui rend IndexNow indirectement utile sur cette surface. Pour les autres moteurs, la relation entre un index et un assistant change au fil des accords commerciaux, et nous nous refusons à publier des affirmations sur ce point : nous les traitons moteur par moteur, avec leurs sources, dans nos articles sur le référencement Claude et le référencement Mistral.
La mise à jour qui ne change rien
Vient maintenant la partie la plus coûteuse en temps pour les équipes, et la plus mal comprise.
Une mise à jour ne se juge pas au nombre de caractères modifiés, mais à son effet sur les vecteurs qui représentent vos passages. Un moteur génératif ne compare pas des pages, il compare des blocs de quelques centaines de mots transformés en vecteurs, comme nous le détaillons dans notre article sur le chunking. Or un remplacement de synonymes, une phrase de transition reformulée ou une date changée en en-tête déplacent ces vecteurs de manière infinitésimale. Le bloc reste à la même distance de la même question. La réponse ne change pas.
Trois interventions très répandues n'ont aucune raison mécanique de déplacer une citation :
- Le rafraîchissement de la date seule. Il ne modifie aucun bloc. Et selon les propres règles de Google citées plus haut, il expose à un jugement défavorable s'il est systématique.
- La réécriture cosmétique. Reformuler pour « améliorer le style » sans ajouter d'information change le texte sans changer ce qu'il affirme. Rien dans la réponse générée n'a de raison de bouger.
- L'ajout d'une FAQ générique en pied de page. Trois questions dont les réponses figurent déjà dans le corps de la page produisent des blocs redondants, en concurrence avec les vôtres.
À l'inverse, ce qui déplace réellement une réponse partage une caractéristique : le nouveau texte affirme quelque chose que l'ancien n'affirmait pas. Un chiffre inédit, une comparaison qui n'existait pas, une contrainte réglementaire nouvelle, un cas limite documenté. Ce critère est vérifiable avant publication, et il tranche : si vous ne pouvez pas nommer la phrase nouvelle que votre mise à jour rend citable, cette mise à jour ne rendra rien citable.
Ce qui mérite une mise à jour, par ordre de rendement
Dans nos audits, les gains les plus nets viennent toujours des mêmes catégories, et dans cet ordre.
- Les entités renommées. Un produit, une marque ou un outil qui change de nom laisse derrière lui des pages qui parlent d'un objet qui n'existe plus. Le marché de l'IA en fournit deux exemples récents, Bard devenu Gemini et Le Chat remplacé par Vibe chez Mistral. Chaque page qui garde l'ancien nom devient un bloc qui répond à une question que plus personne ne pose.
- Les chiffres sans année. Un tarif, un délai, un taux, un effectif : une fois extrait de sa page, un chiffre sans date est invérifiable. C'est la raison pour laquelle nous recommandons de dater la donnée à l'intérieur du bloc, et non dans un en-tête de page qui ne voyagera pas avec elle.
- Les prix et les paliers. Ce sont les informations les plus recherchées et les plus vite obsolètes. Ce sont aussi celles qu'un assistant restitue avec le plus d'assurance, y compris quand elles sont fausses.
- Les liens sortants morts. Une source disparue transforme une affirmation sourcée en affirmation nue, et affaiblit exactement le signal de crédibilité que nous décrivons dans notre article sur l'E-E-A-T.
- Les captures et les copies d'écran. Elles vieillissent plus vite que le texte, et un lecteur humain qui constate un écran obsolète cesse de faire confiance au reste.
Une précision de périmètre s'impose ici. Mettre à jour vos pages ne corrige pas ce que les tiers écrivent de vous. Un comparateur, un annuaire ou un article de presse qui affiche votre ancien tarif reste dans le corpus, et il pèse souvent plus lourd que votre propre site : c'est le mécanisme que nous documentons dans notre article sur les sources tierces. Le chantier de fraîcheur commence chez vous, il ne s'y termine pas.
Savoir si un moteur vous a relu : la méthode du canari
Plutôt que de spéculer sur des délais que personne ne publie, mesurez les vôtres. Trois contrôles, du plus simple au plus instructif.
La date de dernier crawl. L'outil d'inspection d'URL de la Search Console affiche, selon sa documentation, « the last time this page was crawled by Google, in your local time », avec une précision qui vaut d'être retenue : « All information shown in this tool is derived from this last crawled version. » Tant que cette date précède votre modification, Google raisonne encore sur l'ancienne page, et il n'y a rien à diagnostiquer d'autre.
Le journal serveur, filtré par robot. C'est la seule mesure disponible pour ChatGPT, Claude et Perplexity. Une ligne par user-agent suffit à savoir qui est passé, quand, et sur quelles URL. Sur un serveur classique :
grep -Ei 'OAI-SearchBot|Claude-SearchBot|PerplexityBot|Bingbot' access.log | awk '{print $1, $7}' | tail -50
Le canari. C'est le seul test qui mesure la chaîne complète, des quatre couches jusqu'à la phrase générée. Au moment de la mise à jour, insérez dans la page une donnée factuelle, utile au lecteur, et formulée de manière suffisamment distinctive pour n'exister nulle part ailleurs : un chiffre précis avec son unité et sa date, une valeur de seuil, un délai exact. Puis interrogez les moteurs, tous les trois ou quatre jours, avec une question dont la réponse exige ce passage précis. Le jour où le canari apparaît dans une réponse, vous connaissez votre latence réelle de bout en bout, pour ce moteur et pour ce type de page.
Deux règles rendent ce test honnête. Le canari doit être une vraie information, pas un marqueur artificiel : truffer une page de balises inutiles au lecteur pour tracer un robot est une pratique que nous ne recommandons pas, et qui dégrade la page. Et un seul relevé ne conclut rien, car les réponses génératives varient d'une exécution à l'autre : c'est le problème de volatilité que nous détaillons dans notre article sur la mesure de la visibilité IA. Comptez trois interrogations par point de mesure.
Un rythme tenable
La fraîcheur n'est pas une vertu uniforme, elle dépend de la vitesse à laquelle l'information de la page se périme. Voici la cadence que nous appliquons, à défaut de toute donnée publique sur le sujet.
| Type de page | Révision | Ce qu'on y vérifie |
|---|---|---|
| Prix, offres, disponibilités | À chaque changement, le jour même | Cohérence avec le réel, sitemap et IndexNow |
| Comparatifs d'outils et de moteurs | Tous les mois | Noms des produits, fonctionnalités, tarifs cités |
| Pages de service | Tous les trimestres | Périmètre annoncé, exemples, chiffres datés |
| Articles de fond | Deux fois par an | Sources mortes, données non datées, captures |
| Pages institutionnelles | Une fois par an | Mentions légales, effectifs, adresses |
Ce tableau contient une hiérarchie implicite qui est le vrai conseil de cet article : il vaut mieux corriger vingt chiffres faux que réécrire un article entier. La première opération crée vingt passages exacts et vérifiables. La seconde consomme une semaine et laisse le corpus dans le même état.
Ce qu'il ne faut pas en conclure
La fraîcheur n'est pas un levier de visibilité autonome. Une page à jour sur un site qu'aucun modèle ne connaît ne sera pas citée davantage parce qu'elle est à jour. La sélection des marques nommées se joue en amont, sur la notoriété et sur la présence dans les corpus tiers, et une page fraîche mais inaccessible aux robots reste invisible : nous détaillons ces deux préalables dans nos articles sur les crawlers IA et le rendu JavaScript.
Il ne faut pas non plus en tirer une politique de mise à jour permanente. Republier sans cesse coûte du temps de production, brouille les signaux de date que Google déclare croiser, et ne crée aucun passage nouveau. Le contenu réécrit pour être réécrit produit exactement le défaut que nous décrivons dans notre article sur le contenu généré par IA : de la substituabilité.
Ce que la fraîcheur explique, en revanche, c'est un écart précis : celui entre l'état réel de votre site et l'état que les assistants décrivent. Cet écart se mesure, page par page, et il se réduit par des corrections ciblées dont l'effet devient visible en quelques semaines.
Deux prolongements selon votre situation. Si vous voulez d'abord savoir quelles réponses sont périmées vous concernant, c'est l'objet d'un audit GEO, dont le relevé porte sur ChatGPT, Perplexity, Gemini et les AI Overviews de Google, et dont nous publions les fourchettes de prix. Si le sujet est plutôt de suivre l'évolution dans le temps, y compris le délai entre vos corrections et les réponses, c'est ce que couvre notre suivi de visibilité IA. Le cadre de travail complet est décrit sur nos pages agence de référencement IA et agence SEO et GEO, et le partage des rôles avec un consultant GEO y est détaillé.