Post-mortem
Chute de trafic après une mise à jour centrale : rédiger le post-mortem
Tout le monde se pose la même question à 8 h : est-ce Google, est-ce nous, ou est-ce le suivi ? Un post-mortem répond dans cet ordre et refuse de deviner.
Commencez par la chronologie, pas par la théorie
Une chute a une date de début. Trouvez-la avant de lire un seul fil de forum sur une chute de trafic après une mise à jour centrale.
Google a confirmé des mises à jour centrales en mars 2024, août 2024, décembre 2024, mars 2025 et juin 2025, et chacune s'est étalée sur environ deux semaines, donc une chute le troisième jour d'un déploiement peut ne pas encore refléter la situation finale. Superposez votre propre journal des modifications à ces dates : versions, migrations, modifications de modèles, changements de robots.txt.
Si rien de votre côté n'a bougé et que votre graphique Search Console se courbe dans une fenêtre de déploiement, vous avez un candidat. Si votre propre déploiement a eu lieu la veille, vous en avez un meilleur. Dans les deux cas, la chute de trafic après la semaine de mise à jour centrale mérite une chronologie écrite. Notez-la.
Causes classées par rapidité d'élimination
| Suspect | Comment vérifier | Temps pour écarter |
|---|---|---|
| Suivi cassé | Comparez GA4 avec les clics Search Console pour les mêmes pages ; un écart apparu du jour au lendemain est révélateur | 10 minutes |
| Indexation ou sitemap | Rapport d'indexation des pages Search Console, plus une vérification ponctuelle avec site: sur les URLs en chute | 20 minutes |
| Version technique | Différenciez robots.txt, canonicals, codes d'état et redirections par rapport au crawl de la semaine dernière | 1 heure |
| Liens perdus ou gagnés | Différenciez deux snapshots refdomains ; voir liens perdus | 30 minutes |
| Cannibalisation | Deux de vos URLs qui échangent leur place pour la même requête dans le rapport de performance | 1 heure |
| Changement SERP | Ouvrez les résultats en direct : AI Overview, fils de forum, listes de grands sites où vous étiez habituellement classé | 30 minutes |
| Réévaluation de la qualité | Ce qui reste après que chaque autre ligne est claire | Jours à semaines |
Preuve de lien : une comparaison
Extrayez les domaines référents pour le site en chute à deux dates et imprimez ce qui est parti et ce qui est arrivé. L'index se rafraîchit environ mensuellement, donc choisissez des snapshots de part et d'autre de la mise à jour.
import json
old = {r['domain'] for r in json.load(open('2026-09-01.json'))['rows']}
new = {r['domain'] for r in json.load(open('2026-10-01.json'))['rows']}
print('lost :', len(old - new))
print('gained:', len(new - old))
print('sample lost:', sorted(old - new)[:20])
# Field names ('rows', 'domain') vary by action: print one response first.
Exemple de rédaction (chiffres hypothétiques)
Ceci est un exemple inventé, pas un vrai client. Il montre le ton que nous viserions.
Impact. Les clics organiques ont chuté de 38 % sur neuf jours pour un site de recettes fictif avec 140 pages. Détection. Une exportation hebdomadaire Search Console a déclenché une alerte de baisse de 25 % d'une semaine sur l'autre. Cause. Les domaines référents sont passés de 410 à 402, ce qui élimine les liens comme principal moteur. Deux pages ont échangé leur classement pour la même requête, ce qui est du cannibalisme.
Actions. Fusionnez les deux pages avec une 301, mettez à jour les liens internes, revérifiez dans quatre semaines. Pas de disavow. Pas de réécriture de tout le site.
Pannes de mesure et d'indexation qui ressemblent à une mise à jour
Certaines chutes ne sont pas des classements. Le suivi est un suspect courant. Un tag cassé, une propriété modifiée ou un sitemap réduit peuvent ressembler exactement à une mise à jour centrale dans les graphiques. Une chute de trafic après une mise à jour centrale peut cacher l'une de ces causes, donc vérifiez-les en premier.
Le test le plus rapide consiste à comparer vos analyses avec Search Console pour les mêmes pages et les mêmes jours. Si l'écart s'est ouvert du jour au lendemain, traitez-le comme une erreur de mesure jusqu'à preuve du contraire.
Les erreurs d'indexation suivent la même logique. Les pages qui disparaissent de l'index sont un problème différent des pages qui restent indexées et descendent dans les résultats.
Que faire si les clics sont tombés à zéro du jour au lendemain ?
Vérifiez d'abord la propriété Search Console. Un protocole modifié, une nouvelle propriété ou une perte de vérification peut diviser les données, donc l'ancienne propriété ne montre rien tandis que la nouvelle détient le trafic. Seulement après cela, regardez les pages elles-mêmes.
Pourquoi les pages cesseraient-elles d'être indexées après une mise à jour ?
Extrayez le rapport d'indexation pour les URLs concernées. Les classements peuvent glisser pour une page qui reste indexée. Une page qui disparaît de l'index a une cause différente, souvent une directive robots, un changement canonical ou un noindex déployé avec une version.
Un sitemap cassé pourrait-il causer la chute ?
Oui, si le sitemap liste soudainement seulement une petite partie de vos URLs. Un sitemap court est facile à corriger, mais Google trouve toujours les pages via les liens internes, donc traitez-le comme un suspect parmi plusieurs plutôt que comme le verdict. Comparez le nombre d'URLs avec votre nombre réel de pages.
Notre position
Ne réécrivez pas le site la première semaine
Les mises à jour centrales réévaluent la qualité sur plusieurs semaines. Modifiez ce que vous pouvez prouver être cassé, puis attendez la fin du déploiement avant de toucher au contenu.
- Corrigez immédiatement les erreurs de mesure et techniques.
- Fusionnez les pages cannibalisées une fois que vous avez des preuves.
- Laissez la stratégie de contenu de côté jusqu'à la fin du déploiement.
Que rédiger dans le document
Six titres suffisent : impact, chronologie, détection, cause, ce que nous avons écarté, actions. La liste des causes écartées est la partie que votre futur vous remerciera d'avoir écrite.
Gardez les preuves à côté de l'affirmation. Une ligne comme « liens écartés, 402 vs 410 domaines référents » survit mieux à un manager sceptique que « les liens semblaient bons ».
Si la réponse s'avère être les liens, les règles d'alerte pour les concurrents et la recette du diff hebdomadaire vous éviteront les surprises la prochaine fois.
La première semaine après le début d'un déploiement
- 1
Gélez les modifications de contenu
Ne réécrivez pas les pages pendant que le déploiement est en cours. Les modifications faites en milieu de déploiement brouillent la comparaison avant-après dont vous aurez besoin plus tard.
- 2
Journalisez chaque version
Notez chaque déploiement, modification de modèle, redirection et édition de robots.txt avec sa date, afin que la chronologie contienne des entrées réelles plutôt que des souvenirs.
- 3
Exécutez les vérifications de mesure
Comparez les analyses avec Search Console, puis vérifiez le rapport d'indexation pour les URLs en chute. Les deux vérifications tiennent en une demi-heure.
- 4
Ouvrez le dossier avec la chronologie
Commencez le post-mortem avec les dates dont vous disposez, même si la cause est encore ouverte. Un document partiel est plus facile à terminer qu'un document vide.
- 5
Définissez une date de révision
Choisissez une date après la fin du déploiement et réexaminez les preuves à ce moment-là, pas le jour où le graphique se courbe.
Présenter le cas à la direction pour montrer que le problème est technique
La direction lit souvent une chute de trafic comme un verdict sur le contenu. C'est une réaction légitime, et c'est aussi celle qui gaspille le plus de semaines lorsque la faute est un modèle cassé ou un tag manquant.
Présentez la chronologie et le tableau des causes, pas une théorie. Un tableau avec un temps pour écarter chaque suspect permet à un manager de voir que l'équipe travaille sur une liste, pas qu'elle devine.
Soyez honnête sur ce que le tableau ne peut pas prouver. Si une réévaluation de la qualité est encore en cours, dites-le, et indiquez ce qui changerait votre avis.
Comment montrer que c'est un problème de dev et pas de contenu ?
Pointez vers un changement daté qui s'aligne avec le début de la chute, comme une version de modèle ou un changement robots. Une faute que vous pouvez reproduire, avec l'URL et l'en-tête qui ont changé, a plus de poids que n'importe quel graphique de moyennes.
Que dire quand ce n'est pas technique du tout ?
Dites que les vérifications de liens, d'indexation et de suivi sont propres, et que le suspect restant est la réévaluation de la qualité. Cette réponse est plus lente et moins satisfaisante, mais elle est précise, et elle indique à l'équipe où le travail sur le contenu devrait se concentrer.
Rédigez la récupération, pas seulement la chute
Un post-mortem n'est pas terminé quand le trafic revient. La deuxième moitié de la rédaction enregistre ce qui a changé, quand cela a changé et quels suspects vous avez définitivement écartés.
Réexaminez le document après la prochaine mise à jour centrale. Un motif qui se répète sur plusieurs déploiements vous en apprend plus sur votre site qu'une seule chute.
Gardez la liste des causes écartées séparée des causes. Les lecteurs futurs demanderont d'abord ce qui a été écarté, et une liste manquante les renvoie au début.
Qu'est-ce qui compte comme une récupération ?
Définissez-le avant de regarder. Un retour au niveau ancien de clics est une définition, et un retour des pages les plus importantes en est une autre. Choisissez-en une, notez-la et rapportez-vous-y, au lieu de déplacer la barre quand le graphique bouge.
Combien de temps faut-il attendre pour la révision ?
Assez longtemps pour que le déploiement se termine et que deux semaines normales de données apparaissent. La récupération vient généralement lentement, donc une révision précoce trouve surtout du bruit, tandis qu'une révision ultérieure a une chance de trouver la réponse.
Questions que nous entendons après chaque mise à jour
Puis-je me remettre d'une chute de mise à jour centrale ?
Souvent partiellement, et rarement du jour au lendemain. La récupération nécessite généralement une mise à jour ultérieure pour réévaluer le site, donc attendez-vous à des mois, pas à des jours. Personne ne peut le promettre. Ce que vous pouvez faire, c'est supprimer les vraies fautes et continuer à publier des pages dignes d'être citées.
Pourquoi les classements ont-ils tenu tandis que le trafic est tombé ?
La page de résultats a changé autour de vous. AI Overviews, fils de forum et blocs shopping peuvent pousser la même position plus bas sur l'écran. Comparez le taux de clics pour les mêmes requêtes avant et après, pas seulement la position moyenne.
Les backlinks perdus causent-ils une chute après une mise à jour ?
Parfois seulement, et Rankift ne peut pas vous dire quelle mise à jour a fait quoi. Une perte de liens suffisamment importante pour avoir un impact se traduit par une baisse claire des domaines référents entre deux snapshots. Une rotation mineure de quelques pourcents n'explique rarement une chute de trafic de 30 %.
Combien de temps dois-je attendre avant d'agir ?
Jusce que Google marque le déploiement comme terminé sur son tableau de bord d'état, à moins que vous ne trouviez une erreur technique claire. Corrigez les erreurs immédiatement, mais maintenez les modifications de contenu. Modifier pendant un déploiement brouille les preuves dont vous aurez besoin plus tard.
