Le tableau de bord de rapports d’audit SEO Lighthouse pour agences

Toute discussion sur les Core Web Vitals finit sur la même question : quelle page ? Ce rapport y répond en gardant deux mesures côte à côte. Le percentile terrain correspond à ce que les visiteurs ont réellement vécu — Largest Contentful Paint, Interaction to Next Paint et Cumulative Layout Shift au 75e percentile, comparés aux seuils bon et mauvais définis par Google. L’audit en laboratoire, lui, est ce que Lighthouse a mesuré sur chaque URL de la liste en conditions contrôlées, à la demande, le jour où un correctif part en production. Le premier dit si le site passe ; le second dit quel gabarit en est responsable.

Le tableau des pages auditées est l’endroit où cette association devient lisible. Chaque URL auditée porte ses quatre scores à côté de son LCP et de son CLS mesurés en laboratoire, et l’anneau d’évaluation compte les pages qui passent, celles à améliorer et celles qui échouent : « le site paraît lent » devient un ordre de travail qui nomme le gabarit, le trafic derrière lui et la métrique fautive. Les tendances au niveau du domaine et la répartition par appareil publiée par Google appartiennent au rapport Search Console ; cette page est le banc d’essai qui les sous-tend.

L’onglet des opportunités liste ce que l’audit a trouvé et ce que la correction rapporte — des millisecondes pour les ressources bloquant le rendu et le temps de réponse du serveur ; des kibioctets pour la livraison des images, le JavaScript inutilisé, le CSS non minifié et les durées de cache. Chaque ligne porte le domaine auquel elle appartient et une gravité déduite de l’ampleur du gain, si bien qu’une estimation de développeur et une priorité d’agence se discutent à partir de la même liste plutôt qu’à partir de deux exports différents.

Les diagnostics se tiennent à côté comme explication et non comme liste de tâches : taille du DOM, travail du thread principal, temps d’exécution du JavaScript, nombre de requêtes, poids transféré et les mesures de laboratoire qui les sous-tendent, comme First Contentful Paint, Largest Contentful Paint, Speed Index et Total Blocking Time. Chacun est présenté avec son seuil et une phrase simple sur son importance, ce qui sépare généralement un rapport qu’un client transmet à son développeur d’un rapport qui revient chargé de questions.

Les contrôles d’accessibilité automatisés sont regroupés selon la logique qui cadre réellement une remise à niveau : l’impact. Les constats critiques, tels que des champs de formulaire sans libellé ou des images sans texte alternatif, sont tenus à part des constats sérieux comme les contrastes insuffisants et les liens sans nom, eux-mêmes tenus à part des problèmes modérés tels que la taille des zones tactiles, l’ordre des titres et l’ordre de focus. Chaque ligne indique le nombre d’éléments concernés : un devis se construit à partir de volumes réels plutôt qu’à partir d’une vague promesse d’améliorer l’accessibilité.

Le rapport reste délibérément honnête sur ce que couvre un passage automatisé. Ces contrôles détectent une fraction des obstacles qu’une revue manuelle met au jour, et la page le dit clairement, ce qui protège une agence d’un client qui lirait un résultat propre comme un certificat de conformité. Bien utilisé, c’est le premier balayage le moins cher qui existe : il élimine les défauts mécaniques, laisse une trace documentée de ce qui a été corrigé et à quelle date, et laisse à un audit manuel une surface bien plus réduite à parcourir.

Dix contrôles d’exploration et de balisage s’affichent en liste réussi ou échoué, avec une phrase expliquant ce que l’exploration a trouvé : balises title, méta-descriptions, liens explorables, déclarations canoniques, annotations hreflang, fichier robots valide, attributs alt des images, tailles de police lisibles, espacement des zones tactiles et validité des données structurées. Un compteur placé au-dessus du tableau montre d’emblée combien des dix contrôles sont propres et combien restent du travail ouvert.

Il s’agit de l’audit on-page, pas du rapport d’indexation : ce qu’un robot peut analyser sur la page, et non ce que Google a choisi de conserver. Les deux répondent à des questions différentes et ont leur place à des endroits différents ; c’est pourquoi la couverture, les requêtes et les impressions vivent dans le rapport Search Console tandis que cette page reste sur le balisage. Les lire ensemble est l’usage habituel : corriger ce que l’audit signale ici, puis observer la couverture et la position réagir au fil des semaines suivantes.

Chaque audit est cadré sur un seul client via le sélecteur de l’espace de travail et présenté avec la marque de votre agence : la même structure porte la revue de janvier et celle de juin. Scores, vitals, opportunités, diagnostics, accessibilité et contrôles techniques gardent leur place d’une mission à l’autre, ce qui réduit la comparaison d’un mois sur l’autre à lire deux fois la même section, au lieu de rapprocher deux documents de formes différentes. L’espace de travail fournit la surface de revue ; la configuration des sources de données reste une étape distincte.

C’est cette répétition qui transforme un travail technique en prestation qu’un client renouvelle. Un développeur voit une liste de correctifs classée avec les gains estimés ; un responsable de compte voit quatre scores, un indice de santé et les pages qui les expliquent ; et tous deux regardent le même rapport. Les équipes passent leur temps à décider quoi corriger ensuite plutôt qu’à reconstruire une mise en page, et l’audit cesse d’être le livrable que personne n’a envie de rédiger.