Runbook de réponse aux mises à jour d'algorithme

Une réponse à une mise à jour d’algorithme est une enquête d’incident, pas un sprint éditorial. Sa première règle est simple : confirmez que la baisse est réelle et qu’elle vous concerne avant de réagir. « Réelle » signifie que la baisse persiste dans des données complètes et comparables. « Vous concerne » signifie qu’elle reflète la visibilité de recherche de votre site plutôt qu’une mesure défaillante, une demande réduite, un changement de mise en page des résultats ou une mise à jour qui n’a pas affecté vos pages.

Liste de vérification : Réponse aux mises à jour d’algorithme. Cadre temporel : 60 à 90 minutes pour le triage le premier jour ; 2 à 4 heures pour la segmentation au cours de la première semaine ; une décision formelle agir-ou-attendre après sept jours complets, sauf défaut technique vérifié nécessitant une réparation immédiate. Responsable : le responsable SEO est chargé de l’incident et du journal des décisions ; un analyste valide les données ; l’ingénierie est responsable des défauts techniques ; les propriétaires de contenu approuvent les modifications de pages.

Utilisez ce runbook lorsqu’un déclin de recherche important coïncide avec une mise à jour d’algorithme Google confirmée ou suspectée, c’est-à-dire un changement des systèmes de classement de Google. Il est également approprié lorsqu’aucune mise à jour n’a été confirmée mais que de nombreuses URL évoluent ensemble et que la cause n’est pas claire.

Pourquoi cette phase, et pourquoi ici

Cette liste de vérification consomme la mesure de référence datée, les annotations de publication, la carte de propriété des pages, l’inventaire des modèles, la classification des intentions, les analytics, les données de Search Console et les définitions de conversion établis plus tôt dans le processus. Sans ces entrées, une équipe peut voir qu’une ligne a bougé mais ne peut pas établir ce qui a changé, où cela a changé, ni si cela importe pour l’entreprise.

L’ordre est important car les défauts de mesure et les défauts de site peuvent imiter des pertes d’algorithme. Un changement de consentement peut supprimer des sessions d’analytics. Un déploiement peut ajouter noindex, choisir la mauvaise canonique, ou masquer des liens internes. La saisonnalité peut réduire les recherches tandis que les classements restent stables. Diagnostiquez ces cas avant d’attribuer le déclin à un système externe.

Exécuter une remédiation avant la segmentation pose un second problème : l’attribution disparaît. Si l’équipe réécrit les titres, restructure les modèles, supprime des pages et modifie les liens internes la même semaine, toute récupération ou tout déclin ultérieur a plusieurs causes plausibles. La réponse doit donc passer de la vérification à l’isolement du motif, puis à une décision documentée agir-ou-attendre, et ensuite seulement à une intervention contrôlée.

Entrées et sorties

Le registre de décision est le contrat avec l’étape suivante. « Google a changé quelque chose » n’est pas un livrable ; un motif délimité, une décision explicite et des preuves qu’un autre relecteur peut inspecter le sont.

La liste de vérification

1. Confirmer que la baisse est réelle et qu’elle vous concerne

Quoi : vérifiez la perte à travers des mesures indépendantes avant d’attribuer une cause. Pourquoi : des rapports incomplets, des défaillances de suivi, les week-ends, la saisonnalité, les cycles d’actualité et l’évolution de la demande peuvent créer une fausse alerte convaincante. Le trafic organique désigne les visites non payantes provenant des résultats de recherche ; il peut diminuer même lorsque les classements ne changent pas. Comment : utilisez des journées complètes, comparez des périodes équivalentes alignées sur les mêmes jours de la semaine, vérifiez les clics et impressions de Search Console par rapport aux sessions et conversions des analytics, inspectez le contexte d’une année sur l’autre là où la saisonnalité existe, et notez la dernière date de finalisation de chaque source. Outil : données de performance de recherche, analytics, rapports de conversion, journaux de disponibilité et calendrier des publications. Terminé quand : au moins deux signaux indépendants concordent sur la direction, les trois derniers jours complets restent en dessous de la référence choisie, l’actualité des données est enregistrée, et le rapport indique si la perte concerne la visibilité, la demande, le suivi, la conversion ou un mélange.

2. Exclure les causes que vous contrôlez

Quoi : testez les défauts de site, de suivi, de sécurité et d’indexation. Pourquoi : un défaut vérifié mérite une réparation immédiate, alors qu’attendre la fin d’une mise à jour prolongerait une perte évitable. L’indexabilité est la capacité d’une page à être incluse dans l’index d’un moteur de recherche. Comment : inspectez les URL affectées et non affectées pour le statut de réponse, les directives robots, la canonique, le rendu, les liens internes, la présence dans le sitemap, les avis d’actions manuelles et les événements analytics ; alignez tout changement avec son moment de publication. Outil : inspection d’URL, journaux de serveur et de déploiement, sortie du crawler, débogueur analytics, moniteur de disponibilité et registre des changements. Terminé quand : chaque défaut candidat est transmis, réfuté ou attribué avec un responsable ; tout défaut correspondant au début est étiqueté « réparer maintenant » et séparé des hypothèses d’algorithme.

3. Segmenter par répertoire, modèle et intention

Quoi : construisez une matrice d’impact au lieu de juger la moyenne globale du site. Pourquoi : un total général peut cacher le véritable motif : les pages produits peuvent chuter tandis que les guides progressent, un modèle peut perdre des clics mobiles, ou les requêtes informationnelles peuvent évoluer tandis que la demande de marque reste stable. L’intention de recherche est la tâche qu’une personne souhaite accomplir avec une requête. Comment : calculez les variations avant-après pour les clics, impressions, position, conversions et URL affectées ; regroupez d’abord par répertoire, puis par modèle, intention principale, appareil, pays, classe de requête et rôle commercial. Incluez les groupes stables ou en progression comme témoins. Utilisez des totaux absolus pondérés ainsi que des pourcentages, afin que dix clics perdus sur un petit segment ne l’emportent pas sur dix mille clics perdus sur un grand. Outil : rapports de répertoire, page, requête, déplacements d’URL et de mots-clés, plus un tableur ou un carnet d’analyse. Terminé quand : la matrice couvre au moins 95 % des clics de recherche, montre les segments affectés et témoins, enregistre les groupes à faible volume comme non concluants, et nomme le motif reproductible le plus étroit soutenu par les données.

4. Inspecter les gagnants et perdants représentatifs

Quoi : examinez les pages et requêtes qui représentent le mieux chaque segment affecté et témoin. Pourquoi : les agrégats localisent les dégâts mais ne les expliquent pas. Une page de résultats de moteur de recherche peut remplacer les listes classiques par des unités shopping, des résultats locaux, des vidéos ou des réponses IA ; ce changement peut réduire les clics sans montrer de défaut de page corrigeable. Comment : sélectionnez au moins cinq perdants à fort impact et cinq témoins stables ou en progression lorsque le segment contient suffisamment d’URL. Comparez la satisfaction de l’intention, l’originalité, les preuves, la paternité, la charge commerciale, l’historique des mises à jour, le routage interne, les changements d’extrait et les formats de résultats concurrents. Enregistrez les observations comme des hypothèses, pas comme des affirmations de facteurs de classement. Outil : examen des résultats en direct, rendu de page, enregistrement source, pages concurrentes, données de recherche et inventaire de contenu. Terminé quand : chaque hypothèse cite des exemples de perdants et de témoins, les preuves contradictoires sont conservées, et aucune recommandation ne repose sur une seule page ou une seule requête.

5. Geler les modifications de panique pendant la première semaine

Quoi : interdisez les changements larges et spéculatifs tout en poursuivant le diagnostic. Pourquoi : les réécritures massives de titres, les modifications de dates de publication, la suppression de pages, les objectifs de nombre de mots à l’échelle du site, les refontes de modèles et le brassage de liens modifient plusieurs variables à la fois. Ils peuvent endommager des pages qui n’étaient pas affectées et rendre tout mouvement ultérieur impossible à attribuer. Comment : créez une fenêtre de changement de sept jours complets à partir du début observé. Autorisez uniquement les réparations vérifiées, les corrections juridiques ou factuelles, les travaux de sécurité et les lancements déjà approuvés dont le report comporterait un plus grand risque ; annotez chaque exception. Conservez des copies des pages actuelles et des exportations. Outil : calendrier des publications, permissions CMS, journal des incidents et système d’annotation. Terminé quand : le périmètre du gel, le début, la fin, l’approbateur et les exceptions sont visibles par les éditeurs et les ingénieurs ; zéro expérience SEO non enregistrée n’est publiée dans la fenêtre.

6. Choisir agir, attendre ou réparer maintenant

Quoi : prenez une décision à un point de contrôle nommé. Pourquoi : une observation sans fin laisse de véritables défauts non traités, tandis qu’une action réflexe transforme l’incertitude en changement incontrôlé. Comment : choisissez « réparer maintenant » pour un défaut technique ou de mesure reproduit ; choisissez « agir » lorsqu’une perte matérielle persiste, se concentre dans un segment cohérent, et qu’une faiblesse de page ou de système explique à la fois les perdants et les témoins ; choisissez « attendre » lorsque le déploiement, le décalage des données, la saisonnalité, un faible volume ou des segments contradictoires empêchent une cause défendable. Enregistrez les alternatives rejetées et les preuves qui changeraient la décision. Outil : rapport d’incident, matrice d’impact, examen représentatif, évaluation des risques commerciaux et approbateur. Terminé quand : le registre contient une décision, un niveau de confiance, un responsable, une date de révision, des liens vers les preuves et un déclencheur pour le rouvrir.

7. Mener une intervention contrôlée

Quoi : traduisez une décision « agir » en une réparation ou une expérience délimitée. Pourquoi : une hypothèse et un ensemble de changements cohérents préservent la possibilité d’apprendre ; des changements simultanés à l’échelle du site ne le permettent pas. Comment : définissez la cohorte affectée, le groupe de comparaison intact lorsque c’est possible, la faiblesse précise, l’amélioration visée pour le lecteur, la métrique attendue, la fenêtre d’observation, le seuil d’acceptation et la procédure de retour arrière. Pour les pages dégradées, utilisez la liste de vérification pour l’actualisation de contenu plutôt que de modifier les dates ou d’étendre le contenu aveuglément. Outil : rapport d’action, inventaire de pages, CMS, dossier QA, responsable de publication et annotations. Terminé quand : chaque URL modifiée correspond au motif diagnostiqué, l’intervention a passé la QA, les témoins restent inchangés ou les écarts sont enregistrés, et l’annotation de publication indique ce qui doit bouger et dans quel délai.

8. Mesurer, documenter et clore ou itérer

Quoi : évaluez l’intervention séparément du récit de la mise à jour. Pourquoi : la récupération après une publication est une association, pas une preuve que la publication en est la cause ; la mise à jour peut encore être en cours de déploiement, les concurrents peuvent changer et la demande peut revenir. Comment : comparez la fenêtre postérieure déclarée avec la référence gelée, conservez la même segmentation, inspectez les témoins et les conversions, et enregistrez les facteurs de confusion. Classez le résultat comme positif, neutre, négatif ou non concluant. Outil : résultats d’annotations, rapports de déplacements, analytics, rapports de conversion et registre d’incident. Terminé quand : les résultats réels par rapport aux résultats attendus sont joints, la confiance et les limites sont énoncées, le responsable choisit de clore, prolonger l’observation, annuler ou lancer une nouvelle hypothèse délimitée, et la date de prochaine révision est fixée.

Outils dans AmICited

AmICited rend le diagnostic reproductible en préservant les périodes, les segments et les interventions. Il ne prouve pas ce qu’un algorithme récompense ; utilisez les rapports pour localiser les motifs et tester les décisions.

1. Ouvrir le Classement Organique avec le Rapport de Classement Organique pour comparer la demande, la position moyenne et les clics sur les canaux de recherche connectés. Utilisez-le pour déterminer si l’incident est large ou spécifique à un canal.
2. Ouvrir les Mouvements de Position d’URL avec Mouvements de Position d’URL pour identifier les pages créant la perte, comparer les périodes et répartir les mouvements par appareil et section.
3. Ouvrir les Mouvements de Position de Mot-clé avec Mouvements de Position de Mot-clé pour séparer les changements de classement des requêtes de la perte de demande et trouver des motifs au niveau de l’intention.
4. Ouvrir les Répertoires de Recherche Google avec Répertoires de Recherche Google pour descendre de l’ensemble du site vers les répertoires où les clics ou impressions ont changé.
5. Utilisez Pages de Recherche Google avec Pages de Recherche Google et Requêtes de Recherche Google avec Requêtes de Recherche Google pour valider les URL représentatives et les recherches exactes qu’elles servaient.
6. Ouvrir les Résultats d’Annotations avec Résultats d’Annotations pour enregistrer l’intervention, l’attente, le point de contrôle et le résultat. Considérez un résultat évalué comme une preuve d’association, pas de causalité.

Règles de décision

Ce sont des valeurs par défaut de contrôle d’incident, pas des affirmations sur la façon dont Google note les pages. Leur objectif est d’empêcher à la fois la surréaction au bruit et l’inaction lors d’un échec matériel. Remplacez-les uniquement par un seuil documenté basé sur la volatilité établie du site et le risque commercial.

Les pourcentages seuls sont insuffisants. Un déclin de 50 %, passant de deux clics à un, n’est pas équivalent sur le plan opérationnel à un déclin de 15 % impliquant des milliers de visites. Conservez toujours le volume absolu, l’exposition aux conversions et la confiance à côté du changement relatif.

Livrable : le dossier d’incident de mise à jour d’algorithme

Remettez un dossier daté ou un enregistrement d’incident, pas une diapositive disant « impact de mise à jour core ». Il contient :

1. Un rapport d’incident d’une page avec le début, la sévérité, la mise à jour suspectée, l’actualité des données, l’exposition commerciale, le responsable et la décision actuelle.
2. Des exportations figées ou des liens vers les rapports pour les périodes de référence et d’incident, incluant les filtres et le fuseau horaire.
3. Une matrice d’impact par répertoire, modèle, intention, appareil, pays, page et requête, avec les cohortes affectées et témoins.
4. Un journal d’exclusion des causes couvrant la mesure, la demande, les publications, le crawling, l’indexation, le rendu, la sécurité et les changements de mise en page des résultats.
5. Des examens représentatifs des perdants et des témoins, avec des preuves favorables et contradictoires pour chaque hypothèse.
6. La décision agir/attendre/réparer, les alternatives rejetées, l’approbateur, la date de prochaine révision et les preuves qui rouvriraient l’incident.
7. Pour une intervention, la cohorte d’URL exacte, le cahier des charges du changement, le dossier QA, la procédure de retour arrière, l’annotation de publication, le point de contrôle et le résultat final.

Utilisez un tableau lisible par machine pour la matrice d’impact et un résumé lisible par un humain pour la décision. Le dossier est complet lorsqu’un autre analyste peut reproduire le motif affecté sans demander quels filtres ont été utilisés, et qu’un éditeur peut voir exactement ce qui est approuvé sans interpréter un graphique.

Ce qui peut mal tourner

La mise à jour devient l’explication de tout

Une annonce et une baisse de trafic se produisent à proximité l’une de l’autre, donc l’équipe cesse de tester des alternatives. La solution est de maintenir un journal d’exclusion et d’exiger une corroboration. Le timing établit une hypothèse, pas la propriété de la perte.

Les moyennes du site cachent des mouvements opposés

Les guides gagnent tandis que les pages catégories perdent, mais un total plat donne l’impression que l’événement est inoffensif. Ou un grand répertoire chute et donne l’impression que tous les modèles sont faibles. Segmentez les mêmes données par répertoire, modèle, intention, appareil et pays, et conservez les groupes stables comme témoins.

Les modifications de la première semaine détruisent l’attribution

Les équipes réécrivent des pages parce qu’agir semble plus sûr qu’attendre. Une récupération ne peut alors plus être séparée de l’achèvement du déploiement, de la demande, des changements des concurrents ou des modifications elles-mêmes. Gelez le travail spéculatif pendant sept jours complets et annotez chaque exception.

Les changements en pourcentage exagèrent les petits échantillons

Un groupe à faible volume passe de quatre clics à deux et devient le premier « perdant » à 50 %. Associez toujours le changement relatif aux clics absolus, aux impressions, au nombre d’URL affectées et à la valeur commerciale. Marquez les segments faibles comme indicatifs.

Les témoins sont choisis après le résultat

Si les pages stables ne sont sélectionnées qu’après avoir vu lesquelles sont restées stables, la comparaison flatte l’explication préférée. Déclarez la logique des témoins avant l’intervention : même modèle mais intention différente, même intention mais modèle différent, ou pays/appareil non affecté au sein de la même cohorte.

Plusieurs correctifs sont livrés en un seul ensemble

Les titres, le corps du texte, la navigation, le schéma et les modèles changent ensemble. Même un résultat positif n’enseigne pas grand-chose. Séparez les causes en interventions distinctes lorsque c’est opérationnellement possible ; lorsqu’elles ne peuvent pas être séparées, enregistrez l’ensemble et réduisez la confiance dans l’attribution.

La récupération est présentée comme une preuve

La métrique s’améliore après une publication, donc l’action est déclarée causale. Rapportez la séquence avec précision : le changement a été suivi d’une récupération, les témoins se sont comportés d’une manière indiquée, et des facteurs de confusion connus subsistent. Ce langage est plus utile qu’une certitude que les preuves ne peuvent pas étayer.

Phase suivante

Un défaut technique vérifié est transféré immédiatement à son responsable ingénierie, avec la cohorte affectée et la condition de re-test jointes. Un problème de qualité de page diagnostiqué entre dans le flux de travail d’actualisation de contenu. Un incident non concluant retourne en observation avec une date de révision nommée plutôt que d’entrer dans un backlog indéfini.

La phase continue d’actualisation et itération continues a besoin de quatre éléments de ce runbook : la cohorte affectée, l’hypothèse acceptée ou rejetée, l’enregistrement de l’action et de l’annotation, et la prochaine date de mesure. Elle utilise ces sorties pour prioriser le travail sans traiter chaque fluctuation de classement comme une dégradation.

FAQ

Le responsable de l’incident doit publier les réponses aux FAQ du front matter dans le composant FAQ de la page et les maintenir alignées sur les règles de décision ci-dessus. Le principe directeur reste le même pour chaque réponse : vérifier, segmenter, décider, modifier un système délimité et mesurer.

Répondez avec des preuves, pas avec l’urgence

Ouvrez le rapport Organic Rank , figez les dates de comparaison et créez le premier rapport d’incident avant de modifier une page. La réponse utile la plus rapide est une décision que l’équipe pourra expliquer plus tard.