Une core update ne vous punit pas, elle vous recompare

Premier réflexe à corriger : une mise à jour principale de l'algorithme, ce que tout le monde appelle une core update, n'est pas une sanction. Google en déploie plusieurs par an, et chacune revoit la façon dont ses systèmes évaluent la pertinence et la qualité des pages. Personne n'a examiné votre site.

Ce qui se passe est plus banal, et franchement plus vexant : le classement est relatif. Quand Google affine ce qu'il considère comme la meilleure réponse à une requête, certaines pages montent et d'autres descendent mécaniquement, parce qu'il n'y a que dix places en première page. Google le dit avec une image de restaurants : ceux qui reculent dans une liste remise à jour ne sont pas forcément mauvais, d'autres ont simplement été jugés plus méritants.

Ça ne veut pas dire qu'il n'y a rien à faire. Ça veut dire qu'il n'y a pas de bug à corriger, pas de case à décocher. Le travail porte sur le fond.

Relier la chute à la mise à jour : la date, puis la forme de la courbe

Commencez par l'historique des mises à jour de classement publié par Google sur son tableau de bord d'état de la recherche. Chaque mise à jour principale y figure avec une date de début et une date de fin. Notez les deux. Le déploiement s'étale de quelques jours à plusieurs semaines, et votre chute peut tomber n'importe où dans cette fenêtre, pas forcément le premier jour.

Ensuite, ouvrez la Search Console, rapport Performances, et affichez clics, impressions et position moyenne sur plusieurs mois. Une core update dessine typiquement une marche d'escalier : la courbe décroche pendant la fenêtre de déploiement, puis se stabilise à un niveau plus bas. Une glissade lente sur un trimestre, ou une baisse qui commence avant la date de début, raconte une autre histoire.

Méfiez-vous des coïncidences. J'ai vu passer des sites « victimes de la core update » qui avaient en réalité poussé une refonte la même semaine, ou dont le robots.txt bloquait soudain un répertoire entier. Avant de tout mettre sur le dos de l'algorithme, prenez quelques minutes pour vérifier si votre site est pénalisé par Google et écarter les causes techniques. Une action manuelle, un piratage ou un noindex oublié se soignent tout autrement.

Dernier test, tout simple : votre trafic venant de Bing a-t-il chuté en même temps ? Si oui, le problème est probablement chez vous, pas dans l'algorithme de Google.

Une semaine après la fin, pas avant

Je sais, c'est frustrant. Mais pendant le déploiement, les positions bougent d'un jour à l'autre, parfois dans les deux sens, et ce que vous constatez le mardi peut être démenti le jeudi. Analyser à chaud, c'est prendre des décisions sur du bruit.

Google recommande lui-même d'attendre au moins une semaine complète après la fin du déploiement, puis de comparer cette semaine avec une semaine située avant le début de la mise à jour. Dans la Search Console, l'option Comparer du sélecteur de dates fait exactement ça.

Mesurer l'ampleur, page par page

Une fois la comparaison posée, passez sur l'onglet Pages et triez par différence de clics. Puis même exercice côté Requêtes. Vous cherchez à répondre à trois questions :

  • tout le site recule-t-il, ou seulement une section, un type de contenu, une thématique ?
  • les pages perdent-elles des positions, ou seulement des clics à position égale (ce qui peut venir d'un changement d'affichage de la page de résultats) ?
  • de combien de places reculent-elles ?

Ce dernier point change tout. Google fait lui-même la distinction dans sa documentation sur les mises à jour principales : passer de la deuxième à la quatrième position ne justifie aucune action radicale, et il déconseille même de retoucher un contenu qui fonctionne encore bien. Tomber de la quatrième à la vingt-neuvième place, en revanche, appelle une analyse de fond.

Concrètement, je trie mes pages en deux paniers. Les légers reculs, je les laisse tranquilles. Les vrais décrochages, ceux qui sortent de la première page, passent un par un à l'étape suivante.

Regardez qui vous a doublé

C'est l'étape que presque tout le monde saute, et c'est la plus instructive. Prenez la requête principale d'une page qui a décroché, tapez-la dans Google en navigation privée et ouvrez les trois ou quatre résultats qui sont désormais devant vous.

Deux pages web imprimées comparées côte à côte, l'une annotée au feutre vert avec une loupe posée entre les deux

Puis posez-vous des questions honnêtes. Répondent-ils plus vite à la question ? Apportent-ils une expérience vécue, des tests, des captures originales, là où votre page reformule ce qu'on trouve partout ? Sait-on qui les a écrits, et pourquoi on devrait les croire ?

Regardez aussi le format. Parfois, Google n'a pas jugé votre page moins bonne : il a révisé ce qu'il pense que l'internaute veut. Des forums à la place des blogs, des comparatifs à la place des définitions. Dans ce cas, réécrire le même format en mieux ne sert à rien, il faut changer d'angle.

Pour le reste, la grille d'auto-évaluation des consignes de Google sur le contenu utile reste la meilleure base, idéalement avec l'avis de quelqu'un qui n'a pas travaillé sur le site : vous êtes le plus mal placé pour juger vos propres pages. Les signaux de fiabilité y pèsent lourd, et si vous ne voyez pas encore bien ce qu'est l'EEAT de Google, c'est le moment de combler ce trou.

Réagir sans tout casser

La tentation, après une chute, c'est le grand chambardement : réécrire tous les articles d'un coup, changer de thème, acheter des liens en urgence, supprimer la moitié du blog. Google déconseille explicitement les corrections express, et je le rejoins. Ces mouvements de panique vous empêchent ensuite de savoir ce qui a marché.

Ce qui fonctionne, dans cet ordre :

  1. retravailler en profondeur les pages qui ont le plus décroché, en partant de ce que la comparaison avec les concurrents vous a appris ;
  2. fusionner les contenus qui traitent le même sujet en se marchant dessus, plutôt que d'en garder trois moyens ;
  3. rendre visibles l'auteur, sa compétence et vos sources là où elles manquent ;
  4. laisser intactes les pages qui tiennent leur position.

Pour chaque page touchée, vous allez vite devoir choisir entre mettre à jour un vieil article et en écrire un nouveau. Après une core update, je penche presque toujours pour la mise à jour de l'URL existante, qui garde son historique et ses liens.

Une core update se rattrape en améliorant réellement les pages qui ont décroché, pas en multipliant les retouches cosmétiques sur tout le site.

Combien de temps avant de remonter ?

Réponse honnête : personne ne peut vous donner de date, et Google ne s'y engage pas. Sa documentation indique que certains changements peuvent produire un effet en quelques jours, mais que cela peut aussi prendre plusieurs mois. Et si rien ne bouge malgré vos améliorations, il faut parfois attendre la mise à jour principale suivante pour que la réévaluation ait lieu.

Entre deux core updates, Google déploie aussi des ajustements plus discrets, non annoncés, qui peuvent faire remonter un site progressivement. Rien ne garantit pour autant un retour aux positions d'avant. Mon conseil de vieux développeur : tenez un journal daté de chaque changement. Le jour où la courbe repart, vous saurez pourquoi.