Les impressions chutent un vendredi soir, la personne SEO n’est pas disponible et l’astreinte possède une page remplie de liens vers des outils. Elle ouvre Search Console, compare une URL, relance une indexation puis purge le cache, sans savoir quel geste a un rapport avec le symptôme. Le problème n’est pas l’absence d’expertise dans l’instant ; c’est une procédure qui documente des ressources au lieu d’exécuter une décision.
Un runbook utile commence par ce que l’opérateur observe, impose un paquet de preuves, guide vers des branches limitées et indique quand s’arrêter. Il ne cherche pas à transformer chaque collaborateur en expert du classement. Le vrai enjeu consiste à contenir une régression connue, préserver les faits et transmettre un dossier assez précis pour que le spécialiste reprenne sans recommencer l’enquête.
Vous allez voir comment écrire cet arbre, choisir les actions sûres et tester la compréhension avec une personne extérieure au sujet. L’accompagnement SEO technique de Dawap peut intégrer ce dispositif aux alertes, aux contrats de templates et aux processus d’incident de votre produit.
La promesse reste volontairement bornée : accélérer le triage et la mitigation sur des scénarios préparés. Une situation inconnue, une action destructive ou une décision éditoriale exige toujours une escalade. Cette limite protège la production, réduit le coût caché des gestes contradictoires et évite qu’un test positif soit interprété comme une garantie d’indexation ou de récupération.
Savoir dans quels cas l’autonomie reste sûre
Autoriser des gestes précis dans un périmètre précis
L’opérateur doit pouvoir identifier la cohorte touchée, vérifier les signaux déterministes, appliquer une mitigation préautorisée et escalader avec des preuves. Il ne doit pas modifier les canonicals de masse, supprimer des URL ou changer une règle de robots sur intuition. La frontière entre action autonome et validation experte apparaît dès le début du document.
Chaque rôle possède les accès nécessaires et un remplaçant. Le runbook mentionne la personne qui coordonne, celle qui peut approuver un élargissement et celle qui reçoit l’escalade. Si la procédure suppose un compte personnel ou une connaissance orale, elle échouera précisément hors horaires. L’autonomie se mesure à la qualité de la reprise, pas au nombre de boutons que l’on autorise à cliquer.
Une matrice d’autorisation complète cette frontière. Elle classe lecture des logs, inspection du HTML, désactivation d’un canary, invalidation ciblée et modification de configuration. Pour chaque geste, elle indique le rôle et le niveau de validation. Cette préparation évite qu’une personne hésite devant une action sûre ou, au contraire, applique une commande large parce que la documentation ne distingue pas les portées.
Commencer par un symptôme observable
Les entrées prennent la forme de faits : hausse de 5xx sur un template, contenu principal absent, canonical différente, chute de clics limitée à une cohorte ou augmentation des pages non indexées. « Google pénalise le site » n’est pas une entrée, car cette phrase mélange observation et cause supposée. Le choix initial doit être reproductible par deux personnes.
La première branche reprend les familles du guide Google consacré aux baisses de trafic : problèmes techniques, évolutions algorithmiques, saisonnalité, changements de demande, sécurité et spam. Cette diversité impose de séparer le type de courbe et le périmètre avant toute correction. Une baisse seule ne prouve pas une régression technique.
Le symptôme contient toujours une fenêtre et un niveau d’agrégation. « Clics en baisse » devient « clics web en baisse sur les fiches françaises depuis le 12 août, impressions stables ». Cette précision permet de choisir les contre-tests. Elle empêche également la position moyenne du domaine de masquer une cohorte ou, inversement, une URL volatile de déclencher une crise globale.
Constituer le paquet de preuves minimal
Capturer avant de modifier
Le paquet contient l’heure, la source de l’alerte, la période comparée, les templates et URL exemples, la version déployée, le statut, les headers, le HTML pertinent, une capture du rendu et les erreurs de ressources. Une seconde URL témoin permet de savoir si le problème est local ou partagé. Les données sensibles sont masquées avant partage.
Le document propose des commandes ou liens préremplis, mais l’opérateur doit conserver les sorties brutes. Une capture d’écran sans URL ni période perd rapidement sa valeur. Inversement, une exportation massive retarde le triage. Le minimum est celui qui permet de vérifier le symptôme, comparer un état sain et reprendre l’analyse après la mitigation.
Pour un incident de rendu, le paquet ajoute source HTML, DOM hydraté, erreurs JavaScript, ressources et mode SSR, SSG ou ISR. Pour une anomalie de cache, il conserve Age, validateurs, TTFB, région et version. Pour une canonical, il capture balise, header, sitemap et liens internes. Le formulaire adapte donc les preuves à la branche au lieu d’imposer le même export à tous les scénarios.
- Deux URL touchées et une URL témoin du même template.
- Dernier état sain et premier état dégradé horodatés.
- Version, statut, canonical, robots et contenu principal.
- Liste des actions déjà effectuées et de leurs résultats.
Séparer demande, données et incident technique
Si clics et impressions baissent ensemble, le runbook vérifie d’abord le périmètre et la demande ; si les impressions restent stables mais les clics diminuent, il examine l’apparence et le contexte concurrentiel ; si les erreurs de crawl ou le contenu rendu se dégradent, la branche technique devient prioritaire. Ces règles sont des orientations, pas des diagnostics automatiques.
Les anomalies connues des outils doivent être consultées avant d’engager une action radicale. Une erreur de collecte peut produire une courbe inquiétante sans impact réel. En revanche, un noindex reproductible ou une indisponibilité serveur exige une mitigation immédiate même si Search Console n’a pas encore bougé. Le runbook distingue ainsi signal retardé et preuve déterministe.
Les données d’analytics complètent l’analyse côté visiteur sans devenir la source de vérité de Search. Une rupture de tracking peut faire disparaître les sessions alors que clics et impressions restent stables. À l’inverse, une baisse organique réelle peut être masquée par un changement de consentement ou de canal. Le triage confronte les sources et cherche d’abord quel système a produit chaque mesure.
Construire un arbre de décision borné
Chaque nœud pose une question binaire ou propose un petit nombre de réponses observables. « Le statut attendu est-il reçu ? » fonctionne ; « la page est-elle bonne pour le SEO ? » exige trop de jugement implicite. Chaque branche mène à un nouveau contrôle, une action autorisée, une sortie sans action ou une escalade. Les boucles et retours au début sont évités.
Le niveau de détail suit le risque. Un diagnostic de canonical peut demander source, header et version indexée ; un incident 5xx commence par template, origine et dernière release. Si plus de cinq questions sont nécessaires avant une première orientation, le scénario peut être divisé. La simplicité permet à l’opérateur de conserver sa lucidité sous pression et réduit les interprétations divergentes.
Contrairement à ce que laisse croire une documentation exhaustive, ajouter toutes les possibilités ne rend pas la décision plus sûre. Un arbre efficace exclut explicitement les cas inconnus et les envoie vers l’escalade. Il approfondit uniquement les branches dont les preuves et actions ont été testées, afin que l’opérateur ne confonde jamais une hypothèse plausible avec une procédure autorisée.
Chaque branche possède un identifiant stable que les alertes peuvent ouvrir directement. Une notification sur les statuts de fiches mène au nœud correspondant avec template, version et fenêtre préremplis. Cette intégration réduit les copier-coller et les erreurs de filtre. Si l’alerte ne connaît pas encore le contexte suffisant, le premier nœud explique comment le récupérer sans supposer la cause.
Comparer version indexée et test live
L’outil Google d’inspection d’URL affiche des informations sur la version indexée et permet un test live. La documentation précise que ces vues diffèrent : le test live vérifie une accessibilité actuelle, ne couvre pas tous les états d’indexation et ne prédit pas la canonical choisie. Un résultat valide ne garantit pas l’inclusion dans l’index.
Le runbook indique donc quelle vue utiliser. Après un correctif, le live confirme statut, ressources et rendu ; la vue indexée sert à comprendre ce que Google connaissait lors de son dernier traitement. La demande d’indexation n’est pas un bouton de réparation universel. Pour de nombreuses pages, sitemap et recrawl naturel sont plus adaptés, et aucune soumission ne promet un délai.
Une table de lecture évite les faux verdicts : « URL accessible en live » signifie que le test a pu la récupérer, « canonical choisie » appartient à la version indexée, et « indexation demandée » confirme seulement l’entrée dans une file. Si ces états sont recopiés dans le ticket, leur date accompagne la valeur. Sans horodatage, l’équipe risque de comparer un ancien index à une production tout juste corrigée.
Associer chaque branche à une action réversible
Mitiger le mécanisme connu, pas la courbe
Une action autonome peut désactiver un feature flag, retirer une règle canary, revenir à une configuration validée ou ouvrir un circuit de maintenance prévu. Elle possède un périmètre, un test de réussite et un chemin de retour. Purger tout le CDN, modifier toutes les canonicals ou soumettre des milliers d’URL ne sont pas des premières actions sûres.
Google SRE recommande dans son guide de gestion des incidents des playbooks à jour pour accélérer diagnostic et mitigation. L’application au SEO consiste à préparer les scénarios déterministes. Si la cause demeure inconnue, alors l’action doit préserver le système et augmenter l’observabilité plutôt que provoquer plusieurs changements simultanés.
Un exemple concret : une règle edge ajoute noindex aux fiches actives depuis la dernière release. La mitigation autorisée retire cette règle uniquement sur le template et conserve une URL témoin. La QA vérifie header, HTML, cache froid et cache chaud avant élargissement. En revanche, une chute sans directive reproductible n’autorise pas la même action ; elle suit la branche d’investigation.
Écrire les critères d’arrêt et d’escalade
Le critère d’arrêt protège contre l’acharnement : preuve contradictoire, action qui dépasse la cohorte, absence de sauvegarde, données irréversibles, accès insuffisant ou temps maximal écoulé. L’escalade inclut le paquet de preuves et l’étape atteinte. Elle ne demande pas simplement « peux-tu regarder ? », ce qui obligerait le spécialiste à recommencer.
Les seuils ne sont pas universels. Une plateforme définit ses limites selon trafic, valeur, capacité de repli et astreinte. Un faible volume peut être critique s’il concerne une page de conversion. À l’inverse, une fluctuation de position moyenne sans autre signal peut attendre. Les règles sont révisées après les incidents et les changements d’architecture.
L’escalade distingue urgence et expertise. Une indisponibilité majeure appelle immédiatement l’incident commander ; une divergence de données structurées peut rejoindre l’équipe du template ; une hypothèse de mise à jour algorithmique attend l’analyse SEO. Le destinataire, le canal et le délai sont écrits. Une chaîne générique qui notifie tout le monde disperse l’attention et retarde la responsabilité.
Préserver les éléments d’analyse de cause
Google SRE souligne dans Managing Incidents l’importance de restaurer le service tout en préservant les éléments nécessaires à la recherche de cause. Pour le SEO, une purge, une régénération ou une nouvelle soumission peut effacer l’état qui expliquait le problème. La capture précède donc toute mitigation.
Les preuves sont horodatées, liées à la release et stockées hors du service susceptible d’être indisponible. L’opérateur note chaque action et son effet. Une fois le trafic protégé, l’équipe peut distinguer cause, facteur aggravant et symptôme. Cette trace nourrit la mise à jour du runbook et les tests de pipeline, au lieu de produire un post-mortem fondé sur des souvenirs.
La rétention suit la sensibilité et l’utilité. Les captures temporaires sont supprimées selon la politique interne, tandis que les conclusions et scénarios anonymisés restent disponibles pour l’apprentissage. Un identifiant relie incident, commit correctif, test ajouté et dette résiduelle. Cette chaîne montre si le même mécanisme revient et si les actions de prévention ont réellement été exécutées.
Protéger accès et données sensibles
Une procédure ne doit jamais contenir mot de passe, token, cookie personnel ou URL d’administration secrète en clair. Elle renvoie vers le gestionnaire d’accès et décrit le rôle requis. Les exports Search Console, logs et captures peuvent contenir des requêtes, chemins internes ou identifiants ; leur partage suit les règles de confidentialité de l’organisation.
Les actions dangereuses utilisent une double validation et une portée explicite. Une commande avec variable non résolue, un wildcard ou une zone entière n’est pas copiée aveuglément. Le runbook privilégie les contrôles en lecture seule, puis les gestes récupérables et ciblés. Si l’accès d’urgence n’a jamais été testé, l’exercice doit le révéler avant une vraie panne.
Les outils externes reçoivent le minimum d’information. Une URL publique peut être testée, mais un header d’authentification, un cookie ou un extrait de log ne quitte pas l’environnement approuvé. Les captures partagées masquent les identifiants et requêtes sensibles. Cette contrainte fait partie du scénario de test, afin que l’opérateur n’ait pas à arbitrer confidentialité et vitesse sous pression.
Tester la procédure avec un non-spécialiste
La simulation part d’un incident déjà résolu et retire les informations que l’opérateur n’aurait pas reçues. Une personne produit ou support suit les étapes sans aide orale. On mesure le temps jusqu’à la bonne branche, les questions ambiguës, les preuves manquantes et les gestes inutiles. La réussite signifie une orientation correcte et une escalade complète, pas nécessairement une résolution autonome.
Le processus de monitoring HTTP par template fournit de bons scénarios : 404 attendu, 404 inattendu et 200 vide. Après chaque exercice, la procédure est raccourcie, les liens morts retirés et les seuils ajustés. Une version trop longue peut être scindée en triage commun et fiches de mitigation.
La simulation évalue aussi la communication. L’opérateur doit produire un message court avec impact, faits, action et prochaine mise à jour. Un canal séparé conserve les détails techniques. Google SRE recommande de structurer la gestion d’incident et de pratiquer les rôles ; cette discipline réduit les sollicitations parallèles et permet au diagnostic de continuer sans devoir réexpliquer constamment la situation.
Erreurs fréquentes dans un runbook SEO
La première erreur liste des outils sans ordre de décision. La deuxième commence par une cause supposée. Viennent ensuite les seuils sans source, les actions destructives, l’absence de témoin, la confusion entre test live et version indexée, ou la promesse qu’une demande d’indexation réparera la visibilité.
Il faut également éviter un document dépendant d’un expert nommé, des captures obsolètes et des procédures sans date de test. Un runbook qui couvre tous les incidents devient abstrait ; un runbook limité à une URL précise devient périssable. Le bon niveau associe un type de symptôme à des contrats de templates et à des actions bornées.
Plan d’action pour une première version
Transformer un incident connu en procédure testée
Semaine 1. D’abord, sélectionnez trois incidents déterministes. Les entrées du contrat décrivent symptôme et dépendances ; ses sorties fixent responsabilité, action et escalade. Définissez le paquet de preuves minimal, les gestes autorisés et leur portée, puis nommez le coordinateur.
Semaine 2. Ensuite, construisez l’arbre et l’instrumentation. Le monitoring fournit seuil et alerte ; le repli ou rollback ciblé possède sa validation. Documentez les limites de Search Console, du crawl et des logs. Pour chaque action, inscrivez résultat attendu et critère d’arrêt.
Semaine 3. Puis, faites exécuter les scénarios par une personne non spécialiste dans un environnement contrôlé. Interdisez l’aide orale et observez les hésitations. Corrigez le vocabulaire, préremplissez les requêtes sûres et supprimez les étapes qui ne changent aucune décision.
Semaine 4. Enfin, publiez une version datée, testez les accès d’urgence et reliez le document aux alertes. Programmez un exercice trimestriel et une revue après chaque utilisation réelle. Les changements de template, d’outil ou de responsabilité déclenchent une mise à jour avant la prochaine release. La validation finale exige une exécution sans aide orale, une action sûre ou une escalade complète, puis une trace de toutes les étapes ; les scénarios non couverts restent explicitement hors périmètre.
- D’abord, documenter un symptôme avant toute hypothèse.
- Ensuite, conserver un témoin et le dernier état sain.
- Puis, tester uniquement des actions bornées et récupérables.
- Enfin, ouvrir l’escalade avec un dossier complet dès la limite atteinte.
Lectures complémentaires
La procédure gagne en précision lorsque chaque template possède un contrat et un responsable. La méthode d’attribution des sorties SEO par template explique comment répartir canonical, schema, maillage et performance sans diluer la décision.
Pour préparer les retours à l’état sain, le dossier sur la restauration du rendu après une migration distingue la couche applicative du système d’URL et protège les invariants pendant l’urgence.
- Définir les responsables de sortie avant d’écrire l’escalade.
- Préparer les retours ciblés avant de les autoriser en incident.
Conclusion : rendre le diagnostic transmissible
Un bon runbook ne remplace pas l’expert. Il empêche l’improvisation, collecte les preuves, contient les scénarios connus et transmet une situation lisible lorsque le spécialiste doit reprendre la main.
Sa valeur se mesure pendant les exercices : une personne non spécialiste atteint la bonne branche, applique uniquement les gestes autorisés et produit une escalade complète. Les ambiguïtés observées deviennent des corrections de procédure ou de monitoring avant le prochain incident.
Si vos incidents SEO dépendent encore d’une personne ou de gestes non documentés, Dawap peut accompagner vos équipes dans la construction des procédures SEO produit, les relier aux alertes et aux contrats de rendu, puis les éprouver jusqu’à une exécution sûre en conditions réelles.
