Core update Google : les 5 questions à poser avant d'accuser l'update

Un core update est annoncé, votre courbe descend, et la conclusion s'impose toute seule : Google vous a sanctionné. C'est presque toujours une conclusion trop rapide, et le coût de cette précipitation est réel. On refond des pages qui allaient bien, on abandonne un chantier qui commençait à produire, on passe six semaines à réparer quelque chose qui n'était pas cassé.

Pour trancher autrement qu'à l'intuition, on a mesuré 16 propriétés Search Console sur 492 jours, du 21 avril 2025 au 25 août 2026, et confronté leurs séries quotidiennes de clics au catalogue officiel des updates de Google. 9 entrées Ranking tombent dans cette fenêtre, regroupées en 8 lignes parce que les deux updates de mars 2026 sont indissociables, et 6 sont réellement mesurables.

Trois résultats, dont deux qu'on n'attendait pas.

• Sur les 6 fenêtres, la part médiane de propriétés lisibles qui ne bougent pas au-delà de leur propre bruit de fond est de 70,8 %.
• Les 41 plus grandes ruptures de ces 16 mois tombent dans une fenêtre de déploiement 24,4 % du temps, alors que ces fenêtres occupent 25,2 % du calendrier.
• Le plus grand mouvement d'ensemble de la période n'appartient à aucun update du catalogue.

D'où la grille qui suit. Elle ne sert plus à mesurer l'impact d'un update, comme on l'avait prévu : elle sert à écarter méthodiquement tout le reste avant de l'accuser.

Ce qu'on a mesuré, et comment

Séries quotidiennes de clics, d'impressions et de position moyenne, surface web, via l'API searchAnalytics de la Search Console. 13 propriétés couvrent toute la fenêtre, 3 ont un historique plus court. Zéro erreur d'API, zéro propriété perdue, zéro jour manquant à l'intérieur des plages couvertes.

Pour chaque update, on compare la médiane des clics des 14 jours qui précèdent le début du déploiement à la médiane des 14 jours qui suivent sa fin. Pas début contre début : un déploiement dure de 3 à 28 jours dans notre relevé, et comparer 14 jours après le début reviendrait à comparer l'avant à un déploiement en cours.

Trois garde-fous, sans lesquels les chiffres ne veulent rien dire.

• Le plancher. Sous 10 clics par jour en médiane sur la fenêtre avant, aucune variation relative n'est calculée : elle serait le bruit d'un tirage.
• La correction du panel. Chaque écart est publié deux fois, brut et net de l'écart médian du panel aux mêmes dates.
• Le bruit propre. Le même calcul est rejoué sur des dates sans déploiement, avec la même géométrie de fenêtre, propriété par propriété. Le 90e centile sert de seuil.

Un mot sur le dénominateur, parce qu'il compte. 13 propriétés sont mesurables sur chaque fenêtre, mais l'une d'elles a un bruit propre supérieur à 100 % à toutes les durées de déploiement, et jusqu'à 1 028 % sur les fenêtres de 28 jours. Elle n'est pas immobile, elle est hors de portée de la mesure : on la classe « illisible » et on la retire du dénominateur au lieu de la ranger avec les stables. Il reste 12 propriétés lisibles, et tous les pourcentages qui suivent sont calculés sur 12.

Enfin, le panel n'est pas 16 sites indépendants. Une propriété de domaine englobe 4 sous-domaines du même éditeur, qui pèsent 73,4 % de ses clics. La médiane de référence est donc calculée sur 12 propriétés sans recouvrement.

Résultat 1 : la plupart des sites ne bougent pas

Voici les six fenêtres mesurables, plus les quatre updates dont les dates officielles sont connues mais dont l'impact est hors de portée de la rétention de 16 mois de la Search Console.

La lecture est monotone : la barre est majoritairement grise, partout. La part médiane de propriétés qui ne sortent pas de leur propre bruit est de 70,8 %, et de 83,3 % sur les deux seules fenêtres qui n'enjambent aucun effet de calendrier connu, mars 2026 et le spam update de juin 2026.

Deuxième constat, aussi net : aucun update ne pousse le panel dans un seul sens. Chaque fenêtre qui bouge quelque chose produit des hausses ET des baisses. Quand il y a mouvement, il est franc : de +23,2 % à +68,3 % côté hausses selon l'update, de -16,0 % à -65,6 % côté baisses. Mais il ne va jamais dans une direction commune.

Attention au piège de lecture, et il est sérieux. « Hausse » et « baisse » portent ici sur l'écart net, c'est-à-dire l'écart à ce que le reste du panel a fait aux mêmes dates. Une propriété du panel est classée « baisse » sur le spam update d'août 2025 alors que ses clics bruts ont augmenté de 10,3 % : elle a simplement moins monté que les autres. C'est pour ça que l'écart brut est affiché à côté de l'écart net sur chaque ligne, et qu'il faut lire les deux.

Le corollaire, c'est qu'il ne faut jamais moyenner les deux sens. Sur le core update de juin 2025, la médiane signée des quatre écarts nets sortis du bruit vaut +2,1 %, un chiffre qui se lirait comme un impact quasi nul alors qu'il est le milieu entre deux hausses de 27 et 41 % et deux baisses de 23 et 28 %. Les amplitudes sont donc publiées séparément, hausses d'un côté, baisses de l'autre.

Résultat 2 : les plus grosses ruptures ne tombent pas sur les updates

Celui-là, on ne l'attendait pas, et il est plus dérangeant que le premier.

Le script balaie toutes les dates avant de regarder le calendrier de Google. Il retient les 3 plus grandes ruptures par propriété, espacées d'au moins 14 jours, au-dessus du plancher de 10 clics par jour : 41 ruptures au total. Ensuite seulement il mesure leur distance au déploiement le plus proche.

Résultat : 24,4 % des ruptures tombent dans une fenêtre de déploiement, alors que ces fenêtres occupent 25,2 % du calendrier. À plus ou moins 7 jours, 46,3 % contre 47,4 %. À plus ou moins 14 jours, 63,4 % contre 66,5 %. Autrement dit : les plus grands décrochages de ces 16 mois tombent sur un update à peu près aussi souvent que le hasard les y mettrait.

L'objection évidente est que la correction du panel aurait pu effacer un signal commun. Un classement témoin, calculé sur l'écart brut sans aucune correction, donne 29,3 %, 51,2 % et 73,2 % contre les mêmes parts de calendrier : un excédent minuscule, qui ne se distingue pas du bruit d'échantillonnage sur 41 ruptures. Aucun test statistique n'est calculé ici, et l'excédent est trop faible pour qu'un test change quoi que ce soit.

Résultat 3 : le plus gros mouvement de la période n'est dans aucun catalogue

Le mouvement d'ensemble le plus net de ces 16 mois n'est pas une variation de clics. C'est un déplacement de la position moyenne rapportée par la Search Console.

Médiane du panel de référence : 18,67 sur mai à août 2025, 13,17 sur octobre 2025 à janvier 2026, soit 5,5 places d'écart entre les deux périodes. 12 propriétés sur 12 vont dans le même sens, avec un déplacement médian par propriété de 6,16 places, concentré sur septembre 2025. Aucune entrée du catalogue Ranking de Google ne couvre ce mouvement.

Sa cause n'est pas déterminée, et on ne va pas la deviner : ces données ne permettent pas de distinguer un reclassement réel d'un changement dans ce que la Search Console compte comme impression. Ce qui est certain, c'est la conséquence pratique, et elle mord dès maintenant : toute comparaison de position moyenne qui enjambe septembre 2025 compare deux choses différentes. Ça vaut pour toute comparaison annuelle faite en 2026 : un bilan SEO 2026 qui oppose ses positions moyennes à celles de 2025 enjambe ce déplacement, et un tableau de bord qui affiche une progression de position sur douze mois aussi. La position moyenne de la Search Console est un indicateur fragile pour d'autres raisons encore, qu'on détaille dans notre article sur les limites du suivi de positions.

La grille en 5 questions

Ces trois résultats donnent l'ordre des opérations. La grille ne mesure pas l'impact d'un update : elle écarte les autres causes, une par une, jusqu'à ce qu'il ne reste que lui, ou pas.

Reprise en clair, dans l'ordre où il faut les poser :

1. La rupture tombe-t-elle vraiment dans la fenêtre de déploiement, du début à la fin ? La date d'annonce n'est pas la date d'effet. Un déploiement dure de 3 à 28 jours dans notre relevé, et la source, c'est l'historique du produit Ranking sur le Search Status Dashboard, pas un fil de discussion.
2. Est-ce que tout le monde a bougé aux mêmes dates ? Quatre de nos six fenêtres portent une dérive de calendrier nette ou forte : -13,7 % sur la seconde quinzaine de juillet, +55,5 % à la rentrée, -32,3 % sur la semaine du Nouvel An, +14,7 % après les ponts de mai.
3. L'écart dépasse-t-il votre propre bruit de fond ? Rejouez le calcul sur des dates sans update, avec la même géométrie de fenêtre. Sur une propriété du panel, le seuil vaut 12,7 % pour un déploiement de 3 jours et 24,4 % pour un déploiement de 28 jours : sans cet appariement, on serait laxiste sur les updates courts et sévère sur les longs.
4. Vos positions ont-elles bougé, ou vos impressions ont-elles disparu ? C'est le discriminant le plus utile de la grille, et le plus rapide à lire.
5. Qu'avez-vous changé, vous, dans les 60 jours autour de la rupture ? Refonte, migration, redirections, robots.txt, fin de campagne, changement de CMS. Rien de tout ça n'apparaît dans la Search Console, et c'est souvent là que se trouve la réponse.

La question 4 vaut à elle seule le détour

La plus grosse baisse de tout le portefeuille sur une fenêtre d'update mérite d'être racontée, parce qu'elle est exemplaire.

Une propriété perd 91,9 % de ses clics sur la fenêtre du core update de mai 2026. C'est spectaculaire, c'est daté, ça tombe pile sur un core update : le dossier semble bouclé. Sauf que ses impressions ont chuté de 87,9 % pendant que sa position moyenne s'améliorait de 2,58 places. Le balayage à l'aveugle date la rupture du 27 mai : la médiane des clics tombe de 81,5 à 11,5 en quatorze jours, pendant que la médiane de la position moyenne passe de 14,51 à 11,93.

Une position stable ou meilleure avec des impressions qui s'effondrent, ce n'est pas un déclassement. C'est le motif d'une disparition de pages de l'index. Le travail à faire n'est pas éditorial, il est technique, et il commence par l'inspection d'URL : nous listons les causes possibles dans notre article sur les pages non indexées. Le plus gros drame apparent du portefeuille sur une date d'update n'était pas un problème d'update.

Et si les cinq questions désignent bien l'update ?

Ça arrive : sur nos six fenêtres, entre 1 et 8 propriétés sur 12 sortent de leur bruit à chaque fois. Dans ce cas, trois choses.

Un core update n'est pas une pénalité. Il n'y a pas d'infraction à corriger, pas de formulaire de réexamen à remplir. C'est une réévaluation, et le vocabulaire de la sanction est le meilleur moyen de s'engager dans les mauvais travaux. À ne pas confondre non plus avec les actions manuelles, ni avec les questions de contenu généré, qu'on traite dans notre article sur le contenu IA et Google.

Descendez au niveau de la page et de la requête. Notre mesure est au niveau du site, et c'est sa limite la plus gênante : un site peut voir la moitié de ses pages s'effondrer et l'autre progresser sans que le total bouge d'un pouce. La Search Console vous donne les deux dimensions, servez-vous en avant de conclure quoi que ce soit sur l'ensemble du site.

Ne réagissez pas pendant le déploiement. Sur nos six fenêtres, le déploiement dure en médiane 17 jours. Modifier un site pendant qu'un update se déploie, c'est rendre les deux effets indémêlables pour toujours. Attendez la fin annoncée, puis les 14 jours qui suivent, et mesurez à ce moment-là. Ce qu'il faut alors regarder, ce sont les indicateurs sur lesquels on décide, pas la courbe de trafic à la journée. Sur le fond, les signaux qui tiennent d'un update à l'autre sont ceux de l'expérience et de l'expertise démontrées, qu'on a essayé de rendre mesurables plutôt que déclaratifs.

Ce que cette mesure ne dit pas

La liste est longue, et elle fait partie du résultat.

• Aucune causalité. Une rupture qui tombe dans une fenêtre de déploiement coïncide avec elle, rien de plus. Un changement de site, une saisonnalité métier, une refonte ou un incident technique produisent la même signature.
• Aucun test statistique, aucune p-valeur. Les seuils sont des repérages descriptifs sur le bruit propre à chaque propriété, et le bruit est mesuré sur des fenêtres jointives, donc autocorrélées. Un sous-échantillon espacé de 14 jours donne des valeurs proches, ce qui rassure sans transformer le repérage en test.
• Un panel étroit et connoté. 12 propriétés lisibles, très majoritairement du B2B francophone. Aucun site média, aucun e-commerce grand public, aucun site à fort volume éditorial. Les updates dits « helpful content » visent en priorité ce type de site : ce panel ne dit rien de leur effet sur eux.
• Le Discover update de février 2026 n'est pas mesurable ici. Discover n'est pas dans la surface web, et relevée à part la propriété la mieux dotée compte 594 impressions Discover en 16 mois. Aucun effet n'en est déduit, ni positif ni nul.
• Le spam update d'août 2026 n'a pas de chiffre. Déploiement achevé le 21 août, dernière date consolidée le 25 : la fenêtre de 14 jours après n'existe pas encore.
• Aucune comparaison à l'année précédente. La rétention de la Search Console est de 16 mois : il n'existe pas de décembre 2024 dans ces données pour corriger la saisonnalité de fin d'année.
• Rien sur ce qui a changé sur les sites. C'est la limite qui fait la question 5.

Un dernier aveu, à nos dépens. vydera.com fait partie du panel, avec une médiane de 6 clics par jour. Sur les 6 fenêtres, 3 sont antérieures au début de son historique, 2 le trouvent sous le plancher de 10 clics, et la seule où il est mesurable le classe « hausse » sur un passage de 10 à 12,5 clics quotidiens en médiane. Voilà à quoi ressemble un site trop petit pour que la question soit posée. Si c'est votre cas, l'update n'est pas votre sujet.

Refaire la mesure chez vous

Tout est reproductible sans outil payant. L'API searchAnalytics de la Search Console rend les séries quotidiennes de clics, d'impressions et de position sur 16 mois, propriété par propriété. Les dates officielles se lisent sur le Search Status Dashboard de Google, historique du produit Ranking, et le flux incidents.json du même service porte les dates de fin.

La recette tient en cinq lignes : relever la série quotidienne, prendre la médiane des 14 jours avant le début et des 14 jours après la fin, calculer le même écart sur des dates sans update pour obtenir le seuil, retrancher ce que fait le reste de votre parc aux mêmes dates, et publier l'écart brut à côté de l'écart net. Comptez une demi-journée pour un parc de quinze sites.

Le vrai gain n'est pas le tableau. C'est de pouvoir répondre, la prochaine fois qu'un update est annoncé, autre chose que « on surveille ».