Vérifier les affirmations et les preuves de votre audit SEO

Un audit peut repérer une anomalie juste et proposer une mauvaise décision. Avant de financer une correction, il faut relier le constat à une page, une preuve et un résultat attendu. Voici une méthode de lecture utilisable en réunion avec son équipe ou son prestataire…

Le rapport arrive avec ses scores, ses graphiques et une liste d’urgences. Une ligne attire l’attention : « Les pages de services ne sont pas correctement indexées. » La recommandation suit : revoir les balises canoniques. Pour le responsable marketing, la question est immédiate : faut-il engager le chantier ?

Cette situation est un exemple fictif. Elle illustre un problème très concret : une phrase peut réunir une observation technique, une interprétation et une décision sans montrer comment on passe de l’une à l’autre. Le bon réflexe consiste à demander ce qui a réellement été observé avant de discuter du budget. Pour éviter de corriger à l’aveugle, il est indispensable de comprendre d’abord pourquoi Google n’indexe pas vos pages et quelles erreurs corriger afin d’isoler le vrai problème technique (blocage robots.txt, directive noindex ou problème de contenu).

Transformer le diagnostic en question vérifiable

« Le site est mal indexé » décrit trop vaguement le problème. Une formulation exploitable précise les URL concernées, leur fonction et la situation attendue. Par exemple : « Sur les douze pages de services destinées à apparaître dans Google, trois déclarent une autre URL canonique que celle retenue dans le plan de migration. »

Cette seconde phrase ne démontre toujours pas un défaut d’indexation. Elle identifie un désaccord contrôlable entre une intention et une configuration. On peut demander la liste des trois pages, la version du plan et les relevés correspondants. Le prestataire sait quoi expliquer ; le décideur sait ce qu’il approuve.

L’intention mérite elle aussi d’être vérifiée. Une page de campagne temporaire, un filtre de catalogue ou une version d’impression n’a pas nécessairement vocation à être indexée séparément. Corriger toutes les alertes selon la même règle pourrait annuler un choix volontaire. C’est d’ailleurs en croisant ces alertes techniques avec les données d’exploration réelles que la méthode permet de devenir un pro du maillage interne et d’orienter efficacement les robots de Google vers les pages stratégiques du site.

Demander la pièce qui soutient la conclusion

Reprenons le cas des balises canoniques. Un outil peut relever une adresse dans le HTML reçu. Un navigateur peut afficher une autre valeur après exécution du JavaScript. Google peut avoir conservé une version plus ancienne ou sélectionné une autre page comme canonique. Ces observations répondent à des questions différentes.

La documentation de Google sur la consolidation des URL dupliquées décrit les signaux qui aident à désigner une URL canonique. Une déclaration présente dans une page ne suffit pas à établir que Google a retenu cette URL.

Pour examiner une affirmation sur l’indexation, il faut donc demander une preuve adaptée. L’outil d’inspection d’URL de Search Console distingue notamment les informations de la version connue par Google et le test de la page en direct. La date de dernière exploration compte : une correction faite ce matin ne peut pas expliquer un état enregistré avant sa mise en ligne.

Si l’équipe n’a pas accès à Search Console, elle peut documenter ce que le serveur délivre et ce que le navigateur rend. Elle doit alors laisser la sélection effective par Google indéterminée. Le manque d’accès devient une limite du diagnostic, avec une demande précise pour la lever.

Une affirmation d’audit doit relier une attente, un constat daté, une preuve et une décision dont les limites restent explicites. Crédit : Bertrand Morel / Edikka.

Conserver les conditions du contrôle

Une capture isolée peut être difficile à interpréter quelques semaines plus tard. Quel environnement a été testé ? Avec quel appareil ? La page était-elle authentifiée ? Le résultat dépendait-il d’un consentement, d’un cache ou d’un script bloqué ?

Pour une ligne importante, conserver une fiche courte suffit souvent. Elle indique l’URL exacte, l’environnement, la date avec le fuseau horaire, l’outil et sa version, la procédure, le résultat brut et la personne qui a interprété le résultat. Le fichier de preuve porte un nom stable, repris dans le rapport.

Ce niveau de précision évite aussi les comparaisons trompeuses. Un test mobile effectué sur une page de préproduction ne constitue pas le « avant » d’un test de bureau sur la production. Les deux mesures peuvent être utiles, mais elles ne permettent pas d’attribuer l’écart à la correction.

La présentation des Web Vitals par Google distingue les mesures de laboratoire des données de terrain. Un test Lighthouse aide à diagnostiquer une page dans certaines conditions ; il ne remplace pas l’observation de l’expérience réelle des visiteurs. Dans un audit, ces deux sources doivent garder leurs noms et leurs périmètres.

Lire une ligne complète plutôt que le score général

Voici comment pourrait se présenter notre exemple fictif une fois la preuve remise en ordre.

L’attente est que la page de service française conserve sa propre URL canonique après une migration. Le constat est qu’une capture du HTML reçu contient l’URL anglaise. La preuve est le fichier HTML daté, accompagné de la réponse HTTP et de la règle attendue dans le plan de migration. L’interprétation est qu’il existe un désaccord de configuration. La sélection actuelle par Google reste inconnue tant que l’inspection appropriée manque.

La décision peut alors être proportionnée : faire confirmer la destination prévue, corriger la configuration si elle est effectivement erronée, puis vérifier la réponse servie. Un suivi séparé examinera la prise en compte par Google. Le rapport ne promet ni date de réindexation ni hausse de position.

Le score global devient secondaire. Une moyenne satisfaisante peut coexister avec une anomalie sur une page qui reçoit les demandes de devis. À l’inverse, de nombreux avertissements sur des pages volontairement exclues peuvent ne justifier aucune correction. La priorité dépend du parcours touché, du risque et de la solidité de la preuve.

Distinguer absence de défaut et absence de mesure

Un rapport utile doit permettre de reconnaître au moins quatre situations : l’attente est vérifiée, elle est contredite, les éléments disponibles ne permettent pas de conclure, ou le contrôle ne s’applique pas à cette page. Ce vocabulaire peut varier ; la distinction doit rester visible.

« Indéterminé » n’est pas une note moyenne. Ce statut indique une question ouverte. Il doit préciser la pièce ou l’accès manquant. De même, « non applicable » demande une raison liée au périmètre. Une page ne sort pas du contrôle uniquement parce qu’elle produit un mauvais résultat.

Pour les décisions sensibles, demander une seconde lecture est utile. La personne qui la réalise doit pouvoir retrouver la preuve et la règle sans dépendre de l’explication orale de l’auteur. Un document détaillé mais impossible à rejouer reste difficile à transmettre lors d’un changement de prestataire.

Définir la preuve de correction avant les travaux

Avant d’ouvrir un ticket, écrire ce qui permettra de le fermer. « Optimiser les canoniques » est une tâche. « Vérifier la destination déclarée sur les douze URL convenues après déploiement, conserver les réponses et expliquer les exceptions » est un critère de réception.

La recette doit aussi protéger ce qui fonctionnait. Une modification peut rétablir une balise et casser une redirection, une version linguistique ou une interaction utile. Les contrôles liés au parcours restent donc dans la vérification finale. Le succès d’une correction locale et son effet sur Google sont enregistrés séparément.

Pour structurer cette lecture à l’échelle d’un audit, un guide d’audit SEO avec méthode et preuves peut servir de support. L’essentiel reste transportable : chaque recommandation doit pouvoir être discutée à partir d’une attente explicite et de pièces accessibles.

À la prochaine restitution, choisissez une seule recommandation prioritaire et demandez à suivre son raisonnement jusqu’à la preuve. Si cette lecture permet de décider quoi corriger, pourquoi et comment vérifier le résultat, le rapport commence à remplir son rôle.

À propos de l’auteur

Bertrand Morel est le fondateur d’Edikka, agence digitale indépendante créée en 2004. Il travaille sur la qualité des sites web, le SEO et la visibilité dans les réponses d’IA, avec des méthodes et des preuves consultables.