Audit de site web : une preuve par problème

Un audit de site web utile doit déboucher sur des décisions vérifiables. Une liste de 300 alertes sans URL, preuve ni conséquence ne dit pas quelle correction faire en premier. Voici une méthode courte à exécuter, mais assez précise pour distinguer un défaut qui touche tout le site d’une erreur présente sur une seule page.

Définir la question et la période de départ

Écrivez ce que l’audit doit expliquer : baisse de clics organiques, pages absentes de l’index, erreurs après migration, demandes commerciales en recul ou parcours d’achat défaillant. Chaque question exige des preuves différentes. Notez la période analysée et un point de comparaison qui tient compte de la saisonnalité.

Rassemblez le sitemap, les pages de destination des outils d’analyse, les données Pages et Requêtes de Search Console, les modèles de pages, les pages qui reçoivent des liens externes et les conversions importantes. Une donnée absente doit rester « inconnue ». Ne la transformez pas en zéro ni en certitude.

Choisir un échantillon qui représente le site

Prenez au moins une URL de chaque type réellement utilisé : accueil, service, catégorie, produit, article, pagination, résultat de filtre et ancienne page redirigée. Ajoutez les pages qui concentrent les clics, les demandes ou les liens. Huit URL bien choisies peuvent révéler une erreur de modèle ; elles ne prouvent pas que les centaines d’autres pages sont saines.

Pour chaque URL, consignez l’adresse complète, le type de page, le statut HTTP, la destination finale après redirection, la canonical, la présence dans le sitemap, les liens internes et l’objectif de la page. Une feuille simple suffit tant que les tests sont reproductibles.

Vérifier l’accès, l’indexation et les canonicals

Demandez la page comme le ferait un visiteur ou un robot : répond-elle en 200, en 301, en 404 ou en erreur serveur ? Une redirection permanente doit conduire vers une page pertinente ; une chaîne ou une boucle mérite une correction. Vérifiez ensuite si la page est bloquée par robots.txt ou marquée noindex et si sa canonical désigne l’URL voulue.

Le sitemap doit lister les URL canoniques que vous souhaitez voir découvertes. Sa présence ne garantit pas l’indexation. À l’inverse, une page absente du sitemap peut être trouvée par un lien interne. Comparez donc le sitemap aux liens internes et aux données Search Console. La documentation Google sur les sitemaps décrit leur rôle dans la découverte.

Si plusieurs variantes affichent le même contenu, choisissez une version principale cohérente pour les liens internes, les canonicals et le sitemap. Google décrit les signaux de consolidation des URL dupliquées. Une canonical est un signal de préférence, pas une solution magique à un contenu vide ou trompeur.

Examiner ce que la page apporte réellement

Une page techniquement accessible peut répondre mal à la recherche. Lisez son titre, son introduction, ses informations pratiques et sa prochaine étape. Vérifiez qu’elle explique le sujet promis, qu’elle précise les limites et qu’elle offre une preuve utile : démonstration, procédure, exemple chiffré contrôlable, capture ou source primaire pertinente.

Comparez quelques requêtes qui amènent des impressions à la page réelle. Si une page sur un tarif n’explique pas ce qui fait varier le prix, enrichir dix paragraphes génériques ne résoudra pas le problème. Il faut traiter la question du visiteur. Le guide de démarrage SEO de Google insiste sur une structure compréhensible et des contenus utiles aux personnes.

Repérez aussi les pages quasi identiques créées pour des mots clés proches. La bonne réponse peut être une page centrale plus forte, des pages distinctes si leurs besoins diffèrent réellement, ou la suppression de pages sans utilité. Ne décidez pas d’après le seul taux de similarité automatique.

Relier chaque anomalie à une décision

Pour chaque problème, notez : URL touchées, méthode de reproduction, preuve, effet probable sur le visiteur ou la recherche, ampleur, responsable, correction proposée et test de clôture. Séparez les faits observés des hypothèses. « Canonical vers l’ancienne URL sur 24 produits » est vérifiable ; « Google nous pénalise » ne l’est pas sans autre preuve.

Priorisez d’abord les erreurs qui empêchent l’accès ou la conversion sur les pages importantes, puis les défauts de modèle, puis les améliorations éditoriales. Une anomalie mineure sur une page sans trafic ni fonction commerciale ne passe pas devant un formulaire cassé sur un service demandé.

Exemple fictif : un crawl signale 300 URL de filtres. L’échantillon montre que deux combinaisons apportent des visites pertinentes et que le reste n’a pas de contenu distinct. L’équipe traite d’abord les deux pages utiles et leurs liens internes, puis définit une règle cohérente pour les autres variantes.

Retester et mesurer

Après correction, rejouez exactement le test initial sur l’URL concernée. Si un modèle a changé, testez plusieurs pages de ce modèle. Gardez la date de publication et la preuve du nouveau résultat. Suivez ensuite les clics, impressions, demandes ou ventes des pages concernées sur une période comparable. Une hausse ne prouve pas nécessairement que la seule correction en est la cause ; d’autres facteurs peuvent varier.

Le livrable final n’est pas une note sur 100. C’est un tableau de décisions avec des preuves et un propriétaire pour chaque correction. Commencez par un échantillon représentatif, puis étendez le contrôle là où il révèle un défaut partagé.

Exemple de fiche d’anomalie

Imaginez une catégorie de boutique qui apparaît dans le sitemap, mais dont la canonical désigne une ancienne catégorie désormais redirigée. La fiche d’anomalie doit conserver les deux URL, la réponse HTTP de chacune, la balise canonical visible dans le code source et le lien du sitemap. Le risque supposé est que le moteur choisisse une adresse différente de celle que l’équipe veut promouvoir. La correction proposée consiste à pointer la canonical vers la catégorie finale et à vérifier que les liens internes et le sitemap utilisent cette même adresse.

Le test de clôture ne se limite pas à voir le changement dans l’éditeur du site. Rechargez l’URL publique, vérifiez sa réponse et son code HTML, puis contrôlez une seconde catégorie du même modèle. Ensuite seulement, observez l’évolution dans Search Console. Si les données de Search Console tardent à changer, le test HTTP et HTML confirme la correction technique, tandis que l’effet sur la recherche reste à mesurer.

Pour une page qui perd des clics sans erreur technique, la fiche sera différente. Notez les requêtes qui baissent, la période, les modifications éditoriales intervenues et les pages concurrentes qui répondent au même besoin. La prochaine action peut être une meilleure réponse à la question posée, pas une nouvelle balise ou une redirection.