Un site e-commerce qui perd des positions sur ses fiches produits après une mise à jour Google, sans modification de contenu : on a tous vu ce scénario. Le réflexe courant consiste à retravailler les textes ou à chercher de nouveaux liens. Mais dans la majorité des cas, le problème se situe dans le code source des pages elles-mêmes.
C’est précisément ce que couvre un audit technique SEO on-page : l’analyse de tout ce qui, dans la structure HTML et le comportement d’une page, influence son indexation et son classement par Google.
A lire aussi : Comment faire une optimisation SEO ?
Ce que couvre réellement un audit on-page (et ce qu’il ne couvre pas)
On confond souvent audit technique et audit SEO global. L’audit on-page se concentre sur les éléments présents sur chaque page du site : balises title, meta description, structure des titres Hn, maillage interne, temps de chargement, balisage de données structurées. Il ne traite ni la popularité externe (backlinks), ni la stratégie éditoriale au sens large.
Concrètement, on inspecte ce que Googlebot voit quand il accède à une URL. Si le rendu HTML est incomplet, si une balise canonical pointe au mauvais endroit, ou si le contenu principal est masqué derrière du JavaScript mal configuré, la page peut disparaître des résultats sans qu’aucune pénalité manuelle ne soit en cause.
Lire également : Qu'est-ce qu'un cocon sémantique ?
L’audit on-page est aussi le seul levier qui dépend uniquement de vous. Contrairement au netlinking, il ne nécessite aucun partenaire externe. Corriger une balise prend quelques minutes, récupérer un lien perdu prend des semaines.
INP et Core Web Vitals : la métrique que beaucoup d’audits ignorent encore
Depuis le 12 mars 2024, Google a remplacé le FID (First Input Delay) par l’INP (Interaction to Next Paint) dans ses Core Web Vitals. Une checklist d’audit qui ne contrôle encore que le FID est obsolète. L’INP mesure la réactivité de la page pendant l’ensemble de la visite, pas seulement lors de la première interaction.
Ce changement a un impact direct sur la méthode d’audit. L’INP oblige à tester des scénarios d’interaction réels : cliquer sur un filtre de recherche, ouvrir un menu déroulant, soumettre un formulaire. Un score Lighthouse correct en laboratoire ne garantit rien si les données terrain racontent autre chose.
Le rapport Core Web Vitals de Google Search Console s’appuie sur des données utilisateurs réelles, agrégées sur une période de 28 jours via le Chrome UX Report. Lighthouse seul ne suffit pas à établir le diagnostic d’une page. On doit croiser les deux sources pour chaque URL stratégique.
Checklist d’audit on-page : les points de contrôle concrets
Plutôt qu’une liste interminable, on se concentre sur les vérifications qui génèrent le plus de corrections à fort impact. Voici les points que nous contrôlons systématiquement lors d’un crawl.
- Balises title et meta description : unicité par URL, présence du mot-clé cible, longueur adaptée à l’affichage dans les résultats de recherche Google
- Structure Hn : un seul H1 par page, hiérarchie logique (H2 puis H3), pas de saut de niveau qui brouille la compréhension du contenu par les moteurs
- Balises canonical : vérifier qu’elles pointent vers la bonne URL, surtout sur les sites avec des paramètres de tri, de pagination ou de filtres
- Données structurées (schema.org) : cohérence entre le balisage et le contenu visible, validation sans erreur dans le test de résultats enrichis Google
- Rendu JavaScript : s’assurer que Googlebot accède au contenu final, en comparant le HTML brut et le DOM rendu via l’outil d’inspection d’URL de la Search Console
Chaque point génère une action corrective précise. Un audit qui produit un rapport de 40 pages sans priorisation ne sert à rien sur le terrain.
Analyse du crawl et indexation des pages web
Le crawl, c’est la façon dont un robot de moteur de recherche parcourt votre site. Si Googlebot ne peut pas accéder à une page, elle n’existe pas dans les résultats. On utilise un crawler (Screaming Frog, Sitebulb ou équivalent) pour simuler ce parcours et détecter les blocages.
Les problèmes les plus fréquents ne sont pas spectaculaires. Une directive noindex oubliée dans un fichier robots.txt, une chaîne de redirections qui rallonge le temps de réponse, des pages orphelines qui ne reçoivent aucun lien interne. Ces erreurs passent inaperçues sans un crawl complet du site.
On vérifie aussi la couverture dans la Search Console. Le rapport « Pages » indique précisément quelles URL sont indexées, exclues ou en erreur. Croiser ces données avec le crawl permet de repérer les écarts entre ce que vous souhaitez indexer et ce que Google retient réellement.
Compatibilité mobile et rendu sur appareil réel
Google a retiré son outil Mobile-Friendly Test et le rapport Mobile Usability de la Search Console en 2023. Un audit technique SEO on-page actuel doit donc vérifier le rendu mobile avec un navigateur réel ou Lighthouse, plutôt que de s’appuyer sur des rapports qui n’existent plus.
Sur le terrain, les retours varient sur ce point : certains sites s’affichent correctement dans l’émulateur Chrome DevTools mais présentent des problèmes de tap targets ou de texte tronqué sur un smartphone réel. Tester sur au moins un appareil physique reste la méthode la plus fiable pour valider l’expérience utilisateur mobile.
Données structurées et visibilité dans les résultats enrichis
Le balisage schema.org ne fait pas partie du contenu visible, mais il influence directement la façon dont Google affiche vos pages. FAQ, avis, fil d’Ariane, produits : chaque type de données structurées peut déclencher un résultat enrichi qui améliore le taux de clic.
La documentation Google précise que les données structurées doivent être cohérentes avec le contenu de la page. Baliser une FAQ qui n’apparaît pas dans le texte visible, ou déclarer un prix différent de celui affiché, génère des erreurs dans la Search Console et peut entraîner la suppression du résultat enrichi.
Un audit on-page vérifie que chaque balisage correspond exactement au contenu réel de la page. C’est un contrôle rapide, mais que beaucoup de sites négligent après la mise en ligne initiale.
L’audit technique on-page n’a rien d’un exercice théorique. C’est un diagnostic opérationnel qui produit une liste d’actions classées par priorité. Les corrections les plus rentables portent presque toujours sur des détails techniques (une canonical mal configurée, un script qui bloque le rendu) plutôt que sur de grands chantiers de refonte. Commencer par un crawl complet et un passage en revue du rapport Search Console donne déjà une vision claire de l’état réel de vos pages.
