Core update Google : mise à jour, panne ou IA ? Le tri en 5 tests
Votre trafic organique chute et tout le monde accuse la core update. Cinq tests, dans l'ordre, pour trancher entre mise à jour, panne technique et bascule vers l'IA, avant de réécrire quoi que ce soit.


Sommaire
Votre trafic organique chute un mardi matin et trois personnes vous écrivent « c’est la core update ». Parfois, oui. Souvent, la courbe raconte autre chose : un noindex oublié après une mise en production, un tag GA4 cassé, ou des impressions qui tiennent pendant que les clics fondent, parce que Google répond désormais lui-même à la question. Voici un tri en 5 tests, à dérouler dans l’ordre, avant de modifier une seule page après une core update Google.
Il intègre la vue « Generative AI » de la Search Console, disponible depuis le 31 août 2026, comme test de contrôle. Et comme chaque nouvelle update relance la même question, on maintient cet article sur une seule URL, mis à jour à chaque déploiement.
Core update Google : pourquoi ne rien toucher pendant le déploiement
Une core update est une révision large des systèmes de classement de Google. Le déploiement peut durer jusqu’à deux semaines, d’après la documentation officielle de Google. Avant d’agir, comparez la date de début de votre chute avec les dates de déploiement, attendez la fin du déploiement, puis laissez passer au moins une semaine de données complètes. Toute modification faite entre-temps brouille le diagnostic.
Le réflexe inverse est tentant : le trafic baisse le lundi, on réécrit les titres le mardi, on refond le maillage le jeudi. Trois semaines plus tard, impossible de dire ce qui a joué. Pendant le déploiement, les positions bougent encore, parfois dans les deux sens, et la Search Console n’affiche pas un état stable. Agir trop tôt revient à corriger un problème non identifié, et à perdre le seul outil pour l’identifier : un avant/après propre.
L’ordre des tests suit une logique d’élimination. On commence par ceux qui coûtent cinq minutes et qui écartent le plus d’hypothèses. L’analyse de fond ne vient qu’à la fin, si rien d’autre n’explique la baisse.
Test 1 et 2 : la date et le périmètre de la chute
Test 1, la date. Ouvrez le rapport Performances de la Search Console, passez en vue quotidienne et superposez la courbe des clics avec le calendrier des mises à jour. Google publie ces dates sur son Search Status Dashboard. Trois cas de figure :
- La chute démarre avant le début du déploiement : ce n’est probablement pas l’update. Cherchez du côté technique ou de la mesure.
- La chute démarre dans la fenêtre de déploiement : l’update reste candidate, sans être confirmée pour autant.
- La chute démarre à une date sans rapport avec aucune update : regardez votre propre historique de mises en production, de campagnes et de changements de CMS.
Évidemment, ce n’est pas magique : une concordance de dates ne prouve rien toute seule. Elle élimine des pistes, c’est son seul rôle.
Test 2, le périmètre. Une core update réévalue des pages et des requêtes. Une panne touche des gabarits ou des répertoires entiers. Segmentez donc la baisse par type de page (blog, fiches produit, pages services), par requête (de marque ou hors marque), par pays et par appareil.
La lecture est assez parlante :
- Les positions reculent sur plusieurs types de pages, de façon diffuse : signature d’une réévaluation de qualité.
- Tout s’effondre dans un seul répertoire ou un seul gabarit : signature d’un problème technique.
- Seul le mobile décroche : regardez le rendu, les Core Web Vitals, une bannière qui bloque l’écran.
- Seules les requêtes informationnelles perdent des clics, alors que leur position moyenne ne bouge presque pas : gardez cette piste pour le test 5.
Une update modifie des rangs, une SERP qui change d’affichage modifie ce qu’on clique à rang constant. Dans le premier cas la position moyenne baisse, dans le second elle reste stable et c’est le taux de clic qui s’érode.
Test 3 et 4 : écarter la panne technique et le bruit de mesure
Ces deux tests sont peu spectaculaires, mais ils écartent des causes internes (indexation, robots.txt, tags) avant toute analyse de fond sur Google.
Test 3, la panne technique. Passez en revue, dans cet ordre :
- Le rapport d’indexation des pages : une hausse brutale de pages « exclues » ou « explorées, actuellement non indexées » est un signal d’alerte.
- Le fichier robots.txt : une règle Disallow héritée d’un environnement de préproduction se glisse plus facilement qu’on ne le croit.
- Les balises noindex et canonical sur un échantillon de pages touchées, en regardant le code rendu, pas seulement le CMS.
- Les statistiques d’exploration : des erreurs serveur 5xx ou un temps de réponse qui explose réduisent l’exploration.
- Toute migration récente : changement de domaine, de structure d’URL, de thème, de CDN. Si une migration tombe dans la même fenêtre que la chute, elle passe avant l’update dans la liste des suspects.
Test 4, le bruit de mesure. Comparez les clics de la Search Console avec les sessions organiques de GA4 sur la même période. Les deux chiffres ne coïncideront jamais exactement, mais leur rapport doit rester à peu près stable. Si la Search Console reste plate pendant que GA4 plonge, le problème est dans votre mesure : un bandeau de consentement reparamétré, un tag supprimé, un regroupement de canaux modifié. Dans ce cas, aucun levier SEO n’a de sens, il faut réparer le tag.
À l’inverse, si les deux courbes baissent ensemble, la baisse est réelle et vous pouvez passer au test suivant.
Test 5 : l’IA, avec la vue Generative AI de Search Console
C’est le test qui n’existait pas il y a quelques mois. Depuis le 31 août 2026, la Search Console propose une vue « Generative AI » qui donne accès à des impressions liées aux réponses générées par l’IA, qui ne produisent pas de clics. Avant, impossible de distinguer une page perdue dans le classement d’une page vue sans être cliquée. Maintenant, on peut au moins poser la question avec des données.
La méthode tient en trois étapes :
- Exportez les impressions IA pour la France, au niveau des URL, sur la période de la baisse et sur la période précédente. Vérifiez dans votre propriété les dimensions réellement disponibles : la vue est récente et son périmètre peut évoluer.
- Croisez cet export avec les sessions organiques GA4 des mêmes URL.
- Isolez les pages dont la position moyenne tient, dont les impressions IA sont significatives et dont les sessions baissent.
Si ces pages concentrent l’essentiel de la perte, la bascule vers l’IA est une explication sérieuse. Si les pages perdantes n’ont presque aucune impression IA, l’hypothèse tombe et l’update ou la technique reprennent la main.
On ne va pas idéaliser non plus : cette vue mesure une exposition, pas une cause. Une page peut apparaître dans une réponse IA et perdre ses clics pour une autre raison. Le test sert à écarter une piste ou à la rendre plausible, rarement à la prouver seule. Un verdict mixte est fréquent : un peu d’update, un peu d’IA, parfois un problème technique par-dessus.
Sur l’opt-out, une règle simple : jamais par défaut. Limiter l’usage de vos contenus dans les réponses IA passe par des contrôles comme nosnippet ou max-snippet, qui réduisent aussi vos extraits dans les résultats classiques. Autrement dit, vous pouvez perdre de la visibilité pour récupérer des clics qui ne reviendront peut-être pas. On ne l’envisage qu’après un mois de données dans la vue Generative AI, et seulement avec une validation écrite du client, qui doit avoir compris la contrepartie. Pour mémoire, le jeton Google-Extended ne concerne pas la recherche Google, il ne règle donc pas ce sujet.
Que faire selon le verdict
Une fois les cinq tests passés, le verdict détermine l’action. Un diagnostic, pas une panique.
Verdict | Ce que vous observez | Action |
|---|---|---|
Core update | Positions en baisse sur plusieurs types de pages, chute dans la fenêtre de déploiement | Attendre la fin du déploiement plus une semaine, puis auditer contenu et autorité des pages les plus touchées |
Panne technique | Chute brutale sur un répertoire ou un gabarit, pages désindexées, noindex ou canonical erronés | Corriger, demander la réindexation, ne rien modifier d’autre |
Bruit de mesure | Search Console stable, GA4 en baisse | Réparer le tag ou le consentement, ne toucher ni au contenu ni au SEO |
Bascule IA | Positions stables, impressions IA élevées, taux de clic en baisse | Adapter le suivi (citations, requêtes à clic), pas d’opt-out par défaut |
Rien | Variation dans le bruit habituel de votre site | Noter dans le journal, surveiller deux semaines |
Le cas « rien » existe : un site varie naturellement d’une semaine à l’autre, et une baisse modeste qui ne sort pas de cette amplitude ne justifie pas un chantier.
Tenir un journal des updates
Tenez un journal daté : une ligne par update ou par événement, avec la date, la nature, ce que vous avez observé dans la Search Console et la décision prise. Ajoutez-y vos mises en production, vos migrations et vos changements de tags. Dans six mois, il vous évitera de rejouer le même diagnostic.
C’est aussi la raison pour laquelle cette page reste sur une seule URL : la date de dernière mise à jour y est visible, et chaque nouvelle update ajoute une ligne plutôt qu’un nouvel article qui dilue le sujet.
Prochaine étape : à la prochaine update, ajoutez une ligne au journal avant d’ouvrir la Search Console, puis comparez la date de la chute à cette ligne.
Articles similaires
En savoir plusPage non indexée Google : le diagnostic en 7 étapes (Search Console)
Quatre articles à zéro impression après 28 jours : voici la méthode en 7 étapes pour diagnostiquer une page non indexée Google, avec les écrans Search Console à vérifier.
Netlinking presse ou articles sponsorisés : coûts et risques (2026)
Un lien à 150 € sur un blog sans trafic et un lien dans un média reconnu ne pèsent pas pareil, ni pour Google ni pour ChatGPT. Coûts, risques et grille de décision par budget.
SEO IA : 6 livrables à exiger avant de signer (tarifs 2026)
Beaucoup d'offres « SEO IA » sont du SEO classique rebadgé. Voici les 6 livrables concrets à exiger avant de signer, avec les fourchettes de prix 2026.


