Audit SEO technique : les 10 points à contrôler

Les dix contrôles, dans l’ordre de priorité

1. 1.Accessibilité aux robots : robots.txt, en-têtes X-Robots-Tag, blocages d’exécution de ressources.
2. 2.Indexation : écart entre pages publiées, pages crawlées et pages indexées.
3. 3.Architecture : profondeur de clic, cohérence des URL, absence de paramètres inutiles.
4. 4.Performance : LCP, INP, CLS sur données de terrain, mobile en priorité.
5. 5.Compatibilité mobile : rendu, zones tactiles, absence de contenu masqué.
6. 6.Balisage : un H1 unique et descriptif, une hiérarchie de titres cohérente, des title et meta descriptions distincts.
7. 7.Données structurées : Organization, Breadcrumb, Article, FAQPage, validées sans erreur.
8. 8.Redirections et erreurs : chaînes de redirections, 404 reçues depuis des liens internes, codes 5xx.
9. 9.Contenus dupliqués : canoniques, pagination, versions imprimables, facettes.
10. 10.Internationalisation : hreflang réciproques, langue déclarée, ciblage géographique.

Les erreurs les plus fréquentes que nous rencontrons

• Un noindex oublié après une mise en ligne : la cause numéro un des chutes brutales de trafic.
• Une refonte sans plan de redirection : l’historique de positionnement est perdu en quelques semaines.
• Des balises canoniques pointées vers la page d’accueil sur l’ensemble du site.
• Un menu entièrement généré en JavaScript, qui prive le moteur de la structure du site.
• Des facettes de filtrage indexées produisant des milliers d’URL quasi identiques.

Ce qu’un audit doit produire

Un audit qui se contente de lister des anomalies est inutilisable. Le livrable attendu est une feuille de route hiérarchisée : chaque point associé à un impact estimé, une charge de correction et un responsable. Nous distinguons systématiquement les correctifs bloquants, les gains rapides et les chantiers de fond.

Un audit de quatre-vingts pages que personne n’applique vaut moins qu’une liste de dix actions réalisées.

Les outils que nous utilisons, et ce qu’ils ne voient pas

Un audit technique sérieux croise au minimum quatre sources : un crawler qui reparcourt le site comme un robot (Screaming Frog ou équivalent), les données réelles d’exploration remontées par la Search Console, les mesures de performance issues du terrain plutôt que du laboratoire, et une lecture manuelle du code des modèles de page. Aucune de ces sources ne suffit seule, et c’est précisément là que la plupart des audits achetés au forfait décrochent : ils recopient l’export d’un seul outil.

Le crawler vous dira qu’une page renvoie un code 200 et porte une balise title unique. Il ne vous dira pas que cette title est correcte techniquement mais commercialement absurde, ni que la page est indexable alors qu’elle n’aurait jamais dû l’être. La Search Console vous montrera les pages découvertes non indexées, mais elle échantillonne et retarde : une correction appliquée aujourd’hui peut mettre plusieurs semaines à apparaître dans ses rapports. Les scores de performance calculés en laboratoire, eux, dépendent tellement de la machine de test qu’ils servent à comparer deux versions du même site, jamais à établir une vérité absolue.

Ce que nous ajoutons systématiquement, et qu’aucun outil ne produit : la lecture des journaux du serveur. C’est la seule donnée qui dit ce que les robots font réellement, quelles zones du site absorbent leur budget d’exploration et lesquelles ne sont jamais visitées. Sur un site de quelques milliers d’URL, cette analyse révèle presque toujours qu’une part significative de l’exploration part dans des paramètres, des filtres ou des pages de pagination sans valeur.

Le cas particulier des sites rendus côté navigateur

Une part croissante des sites que nous auditons repose sur un rendu exécuté dans le navigateur : le serveur envoie une coquille vide, et le contenu apparaît une fois le code exécuté. Techniquement, les moteurs savent traiter ce cas. En pratique, cela introduit un délai, une consommation de ressources et une dépendance à l’exécution correcte du code, et chacun de ces trois points est un point de rupture.

Le contrôle est simple et nous le faisons toujours en premier : demander la page brute au serveur, sans exécuter le code, et regarder ce qu’elle contient. Si le titre, le texte principal et les liens internes sont absents de cette réponse brute, le site parie sur la bonne volonté du moteur. Cela peut fonctionner sur Google. Cela fonctionne beaucoup moins bien sur les autres robots, notamment ceux des moteurs génératifs, qui n’ont pas les mêmes moyens et se contentent souvent de la première réponse.

La conclusion n’est pas qu’il faut abandonner ces technologies, mais qu’il faut choisir consciemment : rendu côté serveur ou génération statique pour tout ce qui doit être trouvé, exécution côté navigateur pour tout ce qui relève de l’interaction. C’est une décision d’architecture, elle se prend avant le développement, et la corriger après coup coûte plusieurs fois le prix de l’avoir bien posée.

Ce que l’audit technique ne réglera jamais

Nous le disons à chaque restitution, parce que la déception vient presque toujours de là : la technique lève des freins, elle ne crée pas de demande. Un site techniquement parfait mais sans contenu répondant à une intention de recherche restera invisible. À l’inverse, nous voyons régulièrement des sites au diagnostic technique médiocre qui se positionnent, parce que le contenu et l’autorité compensent.

L’ordre est donc toujours le même : corriger ce qui empêche l’indexation ou la compréhension, puis passer au travail éditorial et à l’autorité. Un audit technique qui promet des positions est une promesse tenue par personne. Un audit technique qui identifie proprement les dix points bloquants, les chiffre et les priorise, vous fait gagner des mois sur la suite.