Audit technique de site web : méthode et checklist

Un audit technique de site web vérifie si les moteurs peuvent découvrir, charger, comprendre, regrouper et réexplorer les bonnes pages sans rencontrer de contradiction. Il commence par les réponses HTTP et les directives d’exploration, puis contrôle les URL canoniques, le rendu JavaScript, les liens internes, la performance et les données structurées. Chaque alerte doit devenir une preuve reproductible, une décision et un test de validation.

Ce périmètre est plus étroit que celui d’un audit de site web complet, qui examine aussi l’offre, les contenus, l’expérience, l’accessibilité et la conversion. Une page peut être techniquement indexable sans répondre à une intention utile. À l’inverse, un excellent contenu peut rester invisible si le modèle qui le publie envoie une canonique incohérente ou ne produit aucun lien HTML explorable.

La bonne question n’est donc pas « combien d’erreurs le crawler a-t-il trouvées ? », mais « quelle décision cette erreur doit-elle changer ? ». Vous pouvez commencer avec notre grille d’auto-audit, puis utiliser le protocole ci-dessous pour approfondir les constats techniques.

Qu’est-ce qu’un audit technique de site web ?

Un audit technique enquête sur le chemin entre une URL publiée et sa présence exploitable dans un moteur. Il confronte le serveur, le navigateur, le crawler, Search Console et, si possible, les journaux serveur. Son objectif n’est pas de rendre tous les voyants verts, mais de répondre à des questions concrètes :

• les pages stratégiques renvoient-elles un contenu utilisable avec un statut cohérent ?
• les robots ont-ils le droit de les explorer et de les indexer ?
• les signaux de canonicalisation désignent-ils la même version d’une URL ?
• le contenu important et les liens existent-ils dans le HTML rendu ?
• les moteurs découvrent-ils les pages utiles sans combinaisons infinies ?
• les modèles restent-ils rapides, stables et vérifiables après correction ?

Séparez toujours observation, hypothèse, correction et validation. Un temps de réponse élevé est observé ; « le serveur limite l’exploration » reste une hypothèse sans logs, statistiques d’exploration ou test adapté.

Ce que l’audit technique inclut — et ce qu’il n’inclut pas

Le périmètre couvre normalement l’exploration, l’indexabilité, les statuts HTTP, les redirections, les URL canoniques, les sitemaps, le rendu, le maillage, les modèles de pages, les Core Web Vitals, les données structurées et les erreurs serveur observables.

Il ne remplace pas :

• une stratégie éditoriale et une recherche d’intentions complètes ;
• un test utilisateur ou un audit approfondi de conversion ;
• un audit d’accessibilité selon un référentiel et un échantillon formalisés ;
• un test d’intrusion ou une revue de sécurité applicative ;
• un plan de migration détaillé avec inventaire et règles de redirection ;
• une analyse exhaustive des liens externes ;
• une garantie d’indexation, de position ou de chiffre d’affaires.

Ces disciplines se rencontrent sans se confondre. Un formulaire bloqué par JavaScript est un défaut technique ; déterminer si ses questions découragent les prospects relève aussi de la conversion. Le prix d’un audit SEO varie donc avec le périmètre, la collecte et la restitution attendue.

Préparer l’audit : décider avant de crawler

Un crawl sans contexte trouve des écarts, mais ignore lesquels menacent l’activité. Documentez avant la collecte :

1. la décision attendue, sous forme d’une question réfutable, par exemple « pourquoi les nouvelles pages de service ne sont-elles pas découvertes ? » ;
2. le périmètre : domaines, langues, environnements, modèles, zones privées, paramètres utiles et anciens domaines ;
3. la ligne de base : date, URL par source, états d’indexation, requêtes, conversions et changements récents ;
4. les accès et limites : Search Console, CMS, analytics, code, CDN, logs et historique des déploiements.

Une exclusion intentionnelle ne doit pas devenir un incident. Un audit sans logs reste pertinent, mais il écrit « non observé » plutôt que de transformer l’absence de données en certitude.

Dans quel ordre réaliser un audit technique SEO ?

L’ordre compte. Inutile d’optimiser une donnée structurée sur une page qui renvoie une erreur serveur, ou de discuter d’un score de performance avant de vérifier que la bonne URL peut être indexée.

Étape 1 — Construire l’inventaire des URL

Croisez au minimum le sitemap, un crawl interne, le CMS et les pages connues de Search Console. Ajoutez les pages d’entrée de l’analytics et les logs disponibles.

Ne cherchez pas un total identique. Classez les écarts : URL publiée mais orpheline, URL du sitemap redirigée, ancienne page encore explorée, paramètre dupliqué ou contenu connu de Google mais retiré du CMS.

Associez chaque URL à un modèle, une finalité, un statut attendu et une priorité. Un échantillon représentatif vaut mieux qu’un export sans hiérarchie.

Pour une boutique, complétez cet inventaire par un échantillonnage propre aux catalogues e-commerce : catégories, produits, variantes, facettes, ruptures et contenus éditoriaux n’obéissent pas aux mêmes règles.

Étape 2 — Vérifier l’accès serveur, robots et indexation

Testez les URL importantes avec GET, puis inspectez HTTPS, statut final, redirections, en-têtes et contenu reçu. Un 200 n’est correct que s’il contient la page attendue. Une page d’erreur en 200 crée un « soft 404 » ; une ancienne URL supprimée peut légitimement répondre 404 ou 410.

Contrôlez ensuite :

• le fichier robots.txt et les règles propres aux agents concernés ;
• les balises meta robots dans le HTML ;
• les en-têtes X-Robots-Tag, notamment pour les fichiers non HTML ;
• les protections par authentification, pare-feu ou règle CDN ;
• la disponibilité des ressources nécessaires au rendu.

Google précise que robots.txt gère l’exploration, pas la suppression d’une URL des résultats. Une URL bloquée peut rester connue par ses liens, tandis qu’une directive noindex doit pouvoir être explorée pour être lue.

Étape 3 — Contrôler le sitemap et les signaux canoniques

Un sitemap doit contenir les URL canoniques à explorer, avec un statut final cohérent. Retirez redirections, erreurs, pages noindex, paramètres et URL abandonnées. Il facilite la découverte sans forcer l’indexation, comme le précise la documentation Google.

Pour chaque modèle, comparez :

1. l’URL demandée ;
2. l’URL après redirection ;
3. la balise rel="canonical" ;
4. l’URL incluse dans le sitemap ;
5. les cibles des liens internes ;
6. la canonique choisie par Google lorsqu’elle est visible dans Search Console.

Ces signaux doivent raconter la même histoire. Google décrit la redirection et rel="canonical" comme des signaux forts, le sitemap comme plus faible ; aucun n’est une commande absolue (guide officiel). Une canonique auto-référente ne corrige pas une génération infinie de filtres : traitez la cause.

Étape 4 — Comparer HTML source et rendu JavaScript

Comparez le HTML reçu sans JavaScript au DOM rendu : titre, description, canonique, H1, texte, images, données structurées et liens.

Google traite JavaScript, mais une interaction obligatoire, une erreur ou une ressource bloquée fragilise le contenu. Le guide SEO JavaScript détaille exploration, rendu et indexation.

Un bouton onclick n’équivaut pas à <a href="…">. Les bonnes pratiques sur les liens explorables demandent une ancre et une URL dans href. Le rendu côté serveur ou statique réduit la dépendance du contenu essentiel au JavaScript.

Étape 5 — Auditer le maillage comme un système de découverte

Pour chaque page canonique, vérifiez les liens entrants, leur contexte, leur ancre et le parcours. Cent liens de pied de page ne remplacent pas un lien éditorial qui explique la relation entre deux sujets.

Cherchez quatre situations :

• pages orphelines, présentes dans une source mais sans lien interne ;
• pages profondes accessibles uniquement après plusieurs filtres ou interactions ;
• liens dirigés vers des redirections ou des URL non canoniques ;
• groupes de pages très proches qui se partagent les mêmes ancres et intentions.

Le maillage doit rendre l’architecture compréhensible : pilier, approfondissement, service et action suivante. Une stratégie de visibilité et d’acquisition relie ainsi audit, contenus, landing pages, campagnes et mesure sans transformer chaque article en argumentaire.

Étape 6 — Mesurer la performance par modèle et par contexte

Séparez terrain et laboratoire. Le terrain décrit des visites réelles sur une période ; le laboratoire reproduit une page dans des conditions fixées. Un bon test ponctuel n’invalide pas un problème mobile, et l’absence de données terrain ne prouve rien.

Les Core Web Vitals actuels évaluent le chargement principal, la réactivité et la stabilité visuelle. Les seuils « bons » sont un LCP inférieur ou égal à 2,5 secondes, un INP inférieur ou égal à 200 ms et un CLS inférieur ou égal à 0,1, évalués au 75e percentile (méthode et seuils officiels).

Identifiez la cause par modèle : ressource LCP mal priorisée, image trop grande, police bloquante, JavaScript global, tâche longue, dimensions absentes, injection tardive ou script tiers. Ajoutez ensuite un budget de régression au processus de livraison.

Étape 7 — Vérifier les données structurées

Inventoriez les types et comparez leurs propriétés au contenu visible. Validez syntaxe, champs requis et éligibilité actuelle. Un balisage valide ne garantit pas un résultat enrichi.

Google recommande le JSON-LD et un balisage fidèle à la page (documentation officielle). Testez chaque modèle, puis son HTML en production. Ne marquez pas d’avis, prix ou auteurs invisibles.

Étape 8 — Lire les journaux serveur lorsqu’ils sont disponibles

Les logs montrent ce que Googlebot demande réellement : URL, statuts, fréquence, temps de réponse et périodes d’erreur.

Le user-agent peut être imité : suivez la procédure officielle de validation de Googlebot et excluez les données personnelles inutiles. Pour un petit site, Search Console et des tests ciblés peuvent suffire.

Cherchez des motifs : hausse de 5xx après déploiement, anciennes URL persistantes, paramètres inutiles ou pages prioritaires jamais demandées. Une absence de requête ne devient probante qu’avec le maillage, le sitemap et l’historique d’indexation.

Du symptôme à la validation : la matrice de preuve

Cette matrice évite de transformer un signal isolé en recommandation générale.

Symptôme	Preuve à réunir	Décision possible	Validation après correction
Page importante absente de l’index	GET, robots, canonique, liens, sitemap, inspection	Corriger le premier blocage prouvé	Réponse conforme et nouvelle exploration observée
Variantes concurrentes	URL, contenu, canonique, liens, paramètres	Consolider, rediriger ou différencier	Tous les signaux désignent la version décidée
Pages du menu introuvables	Source, DOM rendu, composant	Produire des liens HTML stables	Un nouveau crawl suit les liens
Modèle lent sur mobile	Terrain, laboratoire, trace	Corriger la ressource ou tâche causale	Seuil atteint sans régression fonctionnelle
Redirections dans le sitemap	Sitemap, statuts, canonique	Publier les URL finales indexables	Sitemap nettoyé et contrôlé
Page orpheline	CMS, sitemap, graphe de liens	La relier utilement ou la retirer	Un lien contextuel mène à l’URL
Hausse des 5xx Googlebot	Logs validés, déploiements	Traiter capacité, cache ou dépendance	Statuts durables et alerte active

Une nouvelle exploration ne garantit pas une meilleure position. Elle prouve seulement que l’obstacle contrôlé a été retiré ; contenu, concurrence et réputation comptent encore.

Comment prioriser les corrections techniques ?

Commencez par les dépendances : un modèle inaccessible passe avant une optimisation locale. Notez ensuite chaque constat de 0 à 3 selon :

• gravité : aucune conséquence démontrée, gêne, perte partielle ou blocage ;
• étendue : une URL secondaire, un groupe, un modèle important ou tout le site ;
• confiance : hypothèse, faisceau d’indices, reproduction ou preuve croisée ;
• effort : correction locale ou changement structurel risqué.

Une formule peut aider à trier, mais ne doit pas inventer de précision :

Priorité indicative = (gravité × étendue × confiance) ÷ effort

Ajoutez l’urgence métier. Chaque ticket précise modèle, état attendu, preuve, hypothèse, correction, responsable, retour arrière et test de fin. La qualité se mesure à la prochaine décision, pas au nombre d’alertes.

Scénario original : diagnostiquer un modèle invisible après une refonte

Le scénario suivant est fictif et construit pour expliquer la méthode ; il ne présente ni client ni résultat Zence.

Une PME B2B publie douze pages après une refonte. Elles répondent 200, figurent dans le sitemap et s’affichent, mais Search Console n’en connaît que deux.

Le crawl depuis l’accueil n’en découvre aucune. Dans le menu « Solutions », chaque entrée est un <div> cliquable sans <a href>. Le sitemap permet une découverte partielle, mais l’architecture ne produit aucun lien HTML.

Le composant de métadonnées génère aussi la même canonique /services/ sur les douze URL. Découverte et canonicalisation envoient donc des signaux convergents vers la mauvaise architecture.

La correction n’est pas « soumettre encore le sitemap ». Elle consiste à :

1. produire des liens <a href="…"> dans le HTML du menu et des pages parentes ;
2. générer une canonique auto-référente pour chaque page réellement distincte ;
3. conserver uniquement ces URL finales dans le sitemap ;
4. ajouter un test automatique sur un échantillon de chaque modèle ;
5. vérifier en production le code source, le rendu et l’inspection d’URL.

Le critère de fin reste technique : bon contenu, liens entrants explorables, signaux cohérents et rendu vérifié. La position future n’est ni prédite ni attribuée à cette intervention seule.

Pourquoi les outils d’audit se trompent-ils parfois ?

Un outil observe selon son user-agent, son rendu JavaScript, sa profondeur, sa vitesse et ses cookies. Deux crawlers peuvent produire des inventaires différents sans que l’un soit faux.

Les limites les plus fréquentes sont :

• un test laboratoire d’une page généralisé au site ;
• un crawler sans rendu face à un contenu côté client ;
• un sitemap confondu avec la navigation réelle ;
• toute redirection ou page noindex classée comme erreur ;
• Search Console interprétée comme une liste exhaustive ;
• une alerte de balisage confondue avec un défaut d’indexation.

Utilisez chaque outil pour ce qu’il mesure et croisez deux sources avant une correction risquée. Tests manuels, code et logs restent nécessaires pour les comportements conditionnels.

Checklist d’audit technique de site web

Cadrage et collecte

• La question de décision, le périmètre et les exclusions sont écrits.
• Les changements récents et une ligne de base sont conservés.
• Les URL du CMS, sitemap, crawl, Search Console et analytics sont comparées.
• Chaque URL est reliée à un modèle et à une priorité réelle.

Exploration et indexabilité

• Les pages retenues répondent avec le bon contenu et le statut attendu.
• Les redirections sont intentionnelles, directes et sans boucle.
• robots.txt, meta robots et X-Robots-Tag produisent l’effet décidé.
• Les ressources nécessaires au contenu et au rendu sont accessibles.
• Le sitemap ne contient que des URL finales, canoniques et indexables.
• Les canonicales, sitemaps et liens internes désignent les mêmes versions.

Rendu et architecture

• Le contenu essentiel existe dans le HTML rendu sans action utilisateur.
• Les liens importants utilisent un élément <a> avec un href exploitable.
• Aucune page stratégique n’est orpheline.
• Les paramètres, filtres et recherches internes ne créent pas un espace infini.
• Les pages très proches ont une intention distincte ou une règle de consolidation.

Performance et données structurées

• Les principaux modèles sont testés sur mobile et ordinateur.
• Les données de terrain sont distinguées des mesures de laboratoire.
• Les causes du LCP, de l’INP et du CLS sont identifiées par modèle.
• Les données structurées correspondent au contenu visible et au type de page.
• Un exemple de chaque modèle passe les tests officiels pertinents.

Exploitation et validation

• Les logs sont analysés lorsque leur accès et leur volume le justifient.
• Chaque constat distingue fait, hypothèse, décision et test de fin.
• Les corrections de modèle possèdent un test de non-régression.
• Les responsables, dépendances et plans de retour arrière sont connus.
• La mesure après mise en ligne est prévue avant la correction.

Plan d’action après l’audit : 30, 60 et 90 jours

Jours 0 à 30 — Rétablir une base fiable

Corrigez les blocages d’exploration et d’indexation démontrés, les erreurs serveur, les canonicales globalement fausses et les redirections critiques. Nettoyez le sitemap, fixez une ligne de base et instrumentez les contrôles qui manquent. Validez chaque changement sur un petit ensemble d’URL avant de l’étendre.

Jours 31 à 60 — Traiter les modèles, pas les symptômes

Regroupez les corrections qui partagent une cause : composant de lien, génération des métadonnées, gestion des filtres, ressource LCP ou balisage commun. Améliorez le maillage des pages prioritaires dans des parcours utiles. Ajoutez les tests de régression au déploiement afin qu’une prochaine évolution ne recrée pas le défaut.

Jours 61 à 90 — Observer et décider du lot suivant

Comparez des périodes cohérentes dans Search Console, les logs et les données de terrain. Vérifiez la nouvelle exploration, les états d’indexation et la qualité des pages d’entrée. Ne concluez pas trop vite qu’une variation de clics vient d’une seule correction. Décidez ensuite si le prochain investissement doit porter sur la technique, le contenu, l’offre, la conversion ou l’acquisition payante.

Zence relie ces disciplines dans son accompagnement en visibilité et acquisition afin que la correction technique serve un parcours complet plutôt qu’un score isolé. Si votre site présente une baisse, une refonte récente ou des pages durablement absentes, décrivez le symptôme, sa date et la décision à prendre. Nous pourrons déterminer si un contrôle ciblé suffit ou si un audit plus large est justifié.

Sources officielles

• Google Search Central — Présentation du fichier robots.txt
• Google Search Central — Comprendre les bases du SEO JavaScript
• Google Search Central — Spécifier une URL canonique
• Google Search Central — Qu’est-ce qu’un sitemap ?
• Google Search Central — Bonnes pratiques concernant les liens
• Google Search Central — Fonctionnement des données structurées
• Google Search Central — Validation de Googlebot
• web.dev — Définition des seuils Core Web Vitals