Ce que vous apprendrez
Une baisse de trafic ou de classement est un signal, pas un diagnostic. Elle peut être causée par le suivi des changements, les changements de demande, la saisonnalité, l'indexation ou les problèmes canoniques, un déploiement, un changement de contenu, une panne, un concurrent, un changement de mix de requêtes ou un problème de qualité réel. Les bons opérateurs réduisent le problème à une question datée et segmentée et testent d'abord l'échec plausible le plus précoce.
Pourquoi ce travail est important : Diagnostiquer les baisses, les changements de test et surveiller les mises en production
La panique crée de mauvaises solutions : réécriture de centaines de pages, modification de modèles à plusieurs reprises, désavouer des liens non liés ou blâmer une mise à jour d'algorithme sans preuve. Ces actions rendent le problème initial plus difficile à comprendre et peuvent nuire aux clients pendant que l'équipe essaie de se rétablir.
Une version peut être techniquement réussie et créer toujours une recherche ou une régression client. La surveillance avant, pendant et après le lancement fait du référencement une partie de la fiabilité normale des produits plutôt qu'un audit séparé après l'action.
Idées clés : Diagnostiquer les gouttes, tester les changements et surveiller les rejets
Intégrité de la mesure
Les balises d'analyse, le comportement de consentement, le regroupement des canaux, les exportations de données, les filtres et les définitions du tableau de bord peuvent changer sans problème de site Web. Commencez par vérifier la collecte et comparez les sources indépendantes avant d'attribuer une cause.
Utilisez-le quand : Au moins deux sources de données pertinentes montrent-elles un changement compatible dans le même segment ?
Segmentation
Un graphique à l'échelle du site peut masquer le modèle. Divisez le changement par classe de requête, marque par non-marque, modèle de page, répertoire, pays, appareil, fonction de recherche, date de publication et parcours utilisateur. La forme de la perte réduit l'hypothèse.
Utilisez-le quand : Quelle cohorte spécifique a changé en premier et le plus fortement ?
Modifier la chronologie
Enregistrer les déploiements, les versions de contenu, les changements de CMS, les redirections, les règles des robots, les changements CDN ou WAF, les changements de flux de données, les pannes, les campagnes de marketing, la saisonnalité et les événements externes connus. Une chronologie transforme de vagues soupçons en hypothèses testables.
Utilisez-le quand : Qu'est-ce qui a changé immédiatement avant le déménagement de la cohorte affectée ?
Canari et retour en arrière
Une version canarie applique un changement à un ensemble limité et représentatif avant un déploiement plus large. Un retour en arrière rétablit un bon état connu lorsque le client ou un dommage technique apparaît. Les deux nécessitent une préparation, pas d'improvisation lors d'un incident.
Utilisez-le quand : L'équipe peut-elle inverser ou corriger cette version sans créer un deuxième incident ?
Étapes pratiques : Diagnostiquer les baisses, tester les modifications et surveiller les rejets
- 01
Déclarez l'incident avec précision
Notez la métrique, la ligne de référence, la date de changement, la cohorte affectée, l'ampleur, la conséquence commerciale et la confiance. Évitez les étiquettes telles que "pénalité Google" jusqu'à ce que les preuves les justifient.
- 02
Vérifier la collecte et la demande
Vérifiez les implémentations d'analyse, les modifications de consentement, les journaux du serveur, la console de recherche, les résultats du CRM, les données publicitaires et les indicateurs de demande. Exclure le tableau de bord et les livrables de saisonnalité avant de changer de page.
- 03
Segmenter la perte
Comparez la marque et la non-marque, le pays, l'appareil, l'intention de la requête, le modèle, le répertoire, l'état de l'index et la qualité de la conversion. Préservez les segments et les filtres dans le dossier d'incident.
- 04
Inspectez la chronologie
Versions de superposition, incidents d'état, déploiements de contenu, changements de crawl, redirections, comportement canonique, changements de données structurées, campagnes et événements externes. Classez les hypothèses par timing et preuve.
- 05
Testez la plus petite réparation prise en charge
Corrigez un modèle ou un sous-ensemble représentatif, validez le statut, le rendu, le canon, les liens et le parcours utilisateur, et comparez avec une cohorte inchangée dans la mesure du possible. Évitez les interventions multiples simultanées.
- 06
Surveiller et documenter
Surveiller les indicateurs techniques, la visibilité, le comportement des clients, les résultats qualifiés et les taux d'erreur pendant une période convenue. Enregistrez la résolution, l'incertitude restante, le travail de prévention et les contrôles de mise en production qui attraperont la récurrence.
Atelier guidé
Diagnostiquer un changement de trafic de recherche sans passer à une histoire
Votre livrable : Une chronologie des incidents qui sépare les changements de données confirmés, les événements de publication, les cohortes de pages, les conditions externes, les hypothèses, les expériences, les actions de récupération et la communication.
Scénario de pratique
Scénario pratique : Un détaillant voit une baisse de 30 % d'une semaine sur l'autres des clics de recherche déclarés. Quelqu'un blâme une mise à jour de l'algorithme. Une autre personne veut réécrire le titre de chaque catégorie. Un examen plus approfondi montre une configuration de suivi modifiée, un sous-ensemble de pages de catégories mobiles a été publié et la période comprend un changement de demande saisonnière.
L'équipe crée un calendrier d'incident. Il place les changements de la source de données, les versions, les cohortes d'URL, les segments de requête, les changements de marché, les erreurs de serveur, les rapports clients et les événements externes connus sur une seule séquence. Il confirme ce qui s'est passé avant d'affirmer pourquoi cela s'est produit.
La première action n'est pas une réécriture à l'échelle du site. L'équipe vérifie si la cohorte de catégorie mobile a perdu l'accès, si la vue du rapport a changé et si le parcours client fonctionne toujours. Il corrige les défauts confirmés, surveille la récupération et garde les explications non confirmées visibles mais séparées.
Construisez-le étape par étape
Vérifiez les données avant de diagnostiquer
Vérifiez la propriété, les filtres, le fuseau horaire, la comparaison des dates, le décalage du rapport, les effets du consentement, la configuration de l'analyse et si le même mouvement apparaît dans une autre source fiable. Enregistrez les limites connues.
- Enregistrement
- Une note de vérification des données
- Décision qu'il soutient
- Si le changement est suffisamment réel pour enquêter
- Risque à vérifier
- Commencer une réponse technique à partir d'un graphique non vérifié
Segmenter le changement
Divisez le mouvement par cohorte de page, type de requête, marché, appareil, marque par rapport à non-marque, modèle, chemin de conversion et date. Cherchez le plus petit groupe qui explique la plus grande part du mouvement.
- Enregistrement
- Une vue de changement segmentée
- Décision qu'il soutient
- Où inspecter en premier
- Risque à vérifier
- En utilisant un total à l'échelle du site comme diagnostic complet
Construire un journal d'événements ordonné chronométré
Ajoutez des versions, des migrations, des temps de déploiement, des changements de flux, des redirections, des modifications de robots ou de CDN, des modifications de contenu, des campagnes, des pannes, la saisonnalité et des événements externes. Marquez chaque élément comme confirmé ou possible.
- Enregistrement
- Un calendrier d'incident
- Décision qu'il soutient
- Quels événements méritent des tests causaux ?
- Risque à vérifier
- Raconter une histoire à partir de dates sans les documenter
Vérifiez directement le client et les chemins techniques
Inspectez les URL affectées pour la réponse, le rendu, les directives, le comportement canonique, les liens, le contenu de la page, les flux, les itinéraires de paiement ou de formulaire et les rapports des clients. Stabiliser un défaut actif avant de poursuivre des théories plus larges.
- Enregistrement
- Un paquet de preuves de chemin critique
- Décision qu'il soutient
- Si une page confirmée ou un problème de voyage nécessite une correction immédiate
- Risque à vérifier
- En attente d'une explication complète pendant qu'un itinéraire client est rompu
Testez une hypothèse à la fois
Écrivez l'observation attendue, la cohorte affectée, la méthode de test, le responsable et la règle de décision. Utilisez des changements ou des comparaisons contrôlés lorsque cela est possible et conservez les preuves pour un examen ultérieur.
- Enregistrement
- Une carte de test d'hypothèse
- Décision qu'il soutient
- Quelle preuve renforcerait ou affaiblirait l'explication ?
- Risque à vérifier
- Changer plusieurs facteurs majeurs et appeler le résultat un diagnostic
Communiquer avec des étiquettes de confiance
Partagez les faits confirmés, le risque client actif, l'action en cours, les hypothèses ouvertes, le responsable et la prochaine heure de mise à jour. Cela aide les dirigeants à comprendre les progrès sans créer de fausse certitude.
- Enregistrement
- Une mise à jour de l'incident
- Décision qu'il soutient
- Comment garder les décisions calmes et fondées sur des preuves
- Risque à vérifier
- Annoncer une cause avant que l'équipe ne l'ait testée
Modèle de travail
- Vérification des données : Source d'enregistrement, filtres, dates, décalage, modifications de configuration et limitations de comparaison. Un analyste devrait être en mesure de reproduire la vue.
- Cohorte affectée : Définissez des pages, des requêtes, des marchés, des appareils, des modèles ou des parcours montrant le mouvement. Un responsable technique doit savoir quoi inspecter en premier.
- Événement chronologique : Énumérez l'horodatage, la version ou l'événement externe, la source et l'étiquette de confiance. Un réviseur doit distinguer les événements confirmés des suppositions.
- Preuve directe : Capturez la réponse, le rendu, les contrôles, les rapports clients ou les observations du chemin de conversion. Le responsable de l'incident devrait être en mesure de donner la priorité aux dommages immédiats.
- Test d'hypothèse : Indiquez l'observation attendue, la méthode, le responsable et la règle de décision. L'équipe devrait savoir quel résultat modifierait le plan.
- Mise à jour : Résumez les faits confirmés, les questions ouvertes, les actions, le risque et l'heure du prochain examen. Les parties prenantes devraient recevoir une clarté utile sans trop de confiance.
Examen de la qualité avant l'expédition
- Gelez l'observation initiale : dates, URL affectées, marché, appareil, source et plage de comparaison. Cela empêche l'enquête de changer de définition chaque fois qu'un nouveau tableau de bord ou une nouvelle opinion apparaît.
- Testez une explication à la fois et enregistrez le résultat. Une baisse du trafic peut impliquer la demande, le suivi, les changements de version, les échecs d'accès, les changements de contenu ou les conditions externes ; nommer plusieurs causes n'est pas un diagnostic.
- Communiquez l'incertitude tôt. Les parties prenantes doivent savoir ce qui est confirmé, ce qui est plausible, ce qui est vérifié ensuite et quand elles recevront une mise à jour plus qu'elles n'ont besoin d'une théorie instantanée.
Règles de décision pour le monde réel
Une baisse de trafic s'aligne sur une mise en production
Faire : Inspectez la cohorte concernée et le parcours du client avant de supposer que la version est à l'origine de chaque changement.
Éviter : Sautez pas la validation des données et des pages car le timing semble convaincant.
La source de données a changé
Faire : Documentez la pause de mesure et construisez une vue comparable avant d'évaluer la performance.
Éviter : Contrairement aux définitions des rapports, ne comparez pas comme s'il s'astait de la même série.
Un défaut confirmé est trouvé
Faire : Stabiliser, corriger, retester et communiquer immédiatement le chemin de récupération.
Éviter : Ne retardez pas la protection des clients tout en étudiant des théories plus larges.
Aucune cause claire n'apparaît
Faire : Continuez à surveiller, rétrécissez la cohorte et choisissez la prochaine plus petite action de collecte de preuves.
Éviter : N'inventez pas une explication algorithmique pour clôturer l'incident.
Notes de l'entraîneur
- Un bon processus d'incident est calme parce qu'il distingue ce qui est connu de ce qui est seulement plausible.
- La meilleure première question est souvent la suivante : quelle route client est réellement affectée ?
- Un calendrier empêche l'équipe d'oublier une configuration silencieuse ou de signaler un changement.
Un éditeur diagnostique une baisse soudaine du trafic mobile
Un éditeur voit une baisse de 35 % des sessions organiques mobiles lundi. L'équipe éditoriale veut réécrire les titres. L'analyste vérifie d'abord la console de recherche et constate que les impressions sont stables, tandis que l'analyse ne montre que la baisse des sessions mobiles. Une version de vendredi a déplacé la bannière de consentement et a retardé la balise d'analyse jusqu'à l'interaction pour certains visiteurs.
L'équipe restaure le comportement de mesure prévu, le valide sur plusieurs appareils et chemins de consentement, et annote le tableau de bord. Il passe également en revue la version parce que la bannière couvrait partiellement un bouton d'abonnement sur les petits écrans. Aucune réécriture de contenu n'est nécessaire. L'enregistrement de l'incident ajoute une analyse de pré-version et un test d'interaction mobile pour les lancements futurs.
Améliorer le résultat : Diagnostiquer les gouttes, les changements de test et surveiller les mises en production
Utilisez soigneusement les comparaisons de cohortes
Une cohorte de maintien ou de modèle inchangé peut améliorer la confiance, mais elle doit être suffisamment similaire en termes de demande, de saisonnalité et de conditions commerciales. Expliquez où la comparaison est imparfaite.
Surveiller les principaux indicateurs techniques
Alerte sur les changements inattendus de robots, les changements de code d'état, les changements canoniques, les baisses de sitemap, les erreurs de rendu, les pics de crawl, les échecs d'alimentation et les différences de modèle. Ils révèlent souvent un problème de publication avant les rapports de revenus.
Récupération séparée du rebond
Une métrique peut augmenter parce que la demande revient, qu'un problème de suivi est résolu ou qu'un système se recycle naturellement. Signalez le calendrier et les explications alternatives au lieu d'attribuer tous les mouvements à l'intervention de l'équipe.
Pratiquer la communication des incidents
Les parties prenantes ont besoin de la portée affectée, des faits connus, de l'impact sur le client, de l'atténuation actuelle, de l'heure de la prochaine mise à jour et des décisions requises. Ils n'ont pas besoin de théories non prises en charge ou d'un flux de captures d'écran d'outils non filtrées.
Note de champ actuelle
Enquêtez sur une goutte avant de prescrire une solution
Une baisse du trafic peut résulter de la demande, de la saisonnalité, de l'accès technique, d'une migration, de problèmes de données ou d'une modification des résultats concurrents. Commencez par la cohorte affectée et comparez comme avec comme avant de changer de site.
- Enregistrez la date de début, les pages concernées, les requêtes, les pays, les appareils, les types de recherche et les versions récentes.
- Vérifiez l'indexation, le crawl, l'action manuelle et les signaux de sécurité avant de réécrire le contenu ou d'apporter des modifications techniques générales.
- Écrivez chaque hypothèse avec des preuves à l'appui et contradictoires, puis testez la plus petite réponse sûre.
Référence officielle : Google : Débogage du trafic de recherche baisse ↗
livrable de leçon
Calendrier des incidents de trafic de recherche
Rédigez un plan de réponse d'une page pour un déclin hypothétique de 20 % sans marque.
Signal : Définissez la mesure, la cohorte, la base de référence et le risque commercial affectés.
Vérification : Énumérez les sources de données indépendantes et les contrôles de mesure.
Segments : Choisissez les dimensions qui pourraient révéler le modèle de perte.
Chronologie : Énumérez les versions, les pannes, les modifications de données et les facteurs externes à annoter.
Hypothèses : Classez trois causes plausibles en vous basant sur les preuves disponibles.
Réparation contrôlée : Décrivez le plus petit test de sécurité et la condition de retour en arrière.
Surveillance : Définissez des mesures techniques, de visibilité, des clients et commerciales avec une cadence de mise à jour.
Avant de passer à autre chose
- L'incident indique une mesure, un segment, une référence, une date et une conséquence client.
- La collecte de données et les changements de demande sont vérifiés avant le début des changements de page ou de lien.
- Les changements de sortie, de panne, de contenu et d'infrastructure sont visibles sur une seule chronologie.
- La réparation est limitée, réversible et testée par rapport à des pages ou des cohortes représentatives.
- La surveillance post-mise en production enregistre à la fois le résultat observé et l'incertitude qui reste.
Progression de la leçon
Vous avez terminé cette leçon ?
Enregistrez votre progression sur cet appareil pour reprendre facilement là où vous vous êtes arrêté.
Cette leçon n'est pas encore marquée comme terminée.
Mettez la leçon en pratique.
Créez un compte Spacebrain gratuit et utilisez la suite SEO avec vos propres fournisseurs de données.