Aller au contenu
Accéder à la Press Room
SEO & GEO

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.

Martin
MartinCo-fondateur de 425PPM
8 min de lecture
Core update Google : mise à jour, panne ou IA ? Le tri en 5 tests
Résumer avec l’IA :ChatGPTPerplexityClaudeMistral
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 :

  1. Le rapport d’indexation des pages : une hausse brutale de pages « exclues » ou « explorées, actuellement non indexées » est un signal d’alerte.
  2. 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.
  3. Les balises noindex et canonical sur un échantillon de pages touchées, en regardant le code rendu, pas seulement le CMS.
  4. Les statistiques d’exploration : des erreurs serveur 5xx ou un temps de réponse qui explose réduisent l’exploration.
  5. 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 :

  1. 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.
  2. Croisez cet export avec les sessions organiques GA4 des mêmes URL.
  3. 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 plus