Cette checklist couvre l’accès des robots, l’indexation, les codes HTTP, les URL canoniques, le rendu JavaScript, l’architecture, les performances, les données structurées et la mesure. Elle convient à un contrôle initial ou à la préparation d’un cahier des charges. Sur un site complexe, chaque point doit être adapté à la technologie et aux risques réels.
Avant l’audit : définir le périmètre et les objectifs
Préparer les données nécessaires
Commencez par identifier les pages qui créent de la valeur : services, produits, catégories, prises de rendez-vous, ressources les plus consultées et marchés prioritaires. Notez aussi les événements récents, comme une migration, une refonte, un changement de CMS ou une chute de trafic.
Rassemblez au minimum :
- l’accès à Google Search Console et à l’outil d’analyse
- le sitemap XML et le fichier robots.txt
- une liste des modèles et sections du site
- les conversions et pages commerciales prioritaires
- les changements techniques récents
- les environnements, domaines et sous-domaines concernés
Enregistrer le point de départ
Enregistrez un point de départ : clics organiques, impressions, pages indexées, conversions, erreurs serveur et performances terrain. Sans référence initiale, la validation des corrections sera fragile.
1. Vérifier l’exploration
Contrôler robots.txt
Le fichier robots.txt indique aux robots les zones qu’ils peuvent explorer. Vérifiez qu’il répond avec un code 200, qu’il ne bloque pas les ressources nécessaires au rendu et qu’aucune règle générale n’interdit accidentellement les pages importantes.
Une interdiction d’exploration ne garantit pas la désindexation d’une URL déjà connue. Pour retirer une page des résultats, utilisez la méthode adaptée, comme noindex sur une page accessible, une authentification ou une suppression permanente. Google documente le fonctionnement de robots.txt (developers.google.com).
Rechercher les impasses d’exploration
Les robots suivent principalement les liens. Une page importante sans lien interne peut rester difficile à découvrir. Repérez les pages orphelines en comparant le crawl, le sitemap, Search Console, les données analytiques et la base du CMS.
Contrôlez aussi les calendriers infinis, filtres, paramètres et facettes qui génèrent un nombre excessif d’URL. Le budget d’exploration est surtout critique sur les grands sites, mais les pièges peuvent brouiller n’importe quelle architecture.
Examiner les journaux serveur si nécessaire
Les logs montrent ce que les robots demandent réellement. Ils sont utiles sur un grand site, après une migration ou lorsque le crawl théorique ne correspond pas à l’activité de Googlebot. Vérifiez la fréquence, les codes de réponse, les zones sur-explorées et les pages stratégiques rarement demandées.
2. Auditer l’indexation
Comparer les ensembles d’URL
Ne cherchez pas à indexer toutes les URL. Comparez plutôt les pages qui devraient apparaître avec celles que Google connaît. Le sitemap doit contenir uniquement des URL canoniques, indexables et répondant correctement.
Dans Search Console, analysez les motifs : pages exclues par noindex, doublons, pages explorées mais non indexées, redirections et erreurs. Inspectez des exemples représentatifs au lieu de traiter chaque statut comme une faute automatique.
Vérifier les directives meta et HTTP
Contrôlez les balises meta robots ainsi que les en-têtes X-Robots-Tag. Une directive noindex sur un modèle peut retirer des centaines de pages. Une directive contradictoire entre HTML et en-tête complique le diagnostic.
Vérifiez la version rendue et la réponse HTTP, pas seulement le code source initial. Un script ou un système de cache peut modifier les directives.
Diagnostiquer les pages non indexées
Une page accessible et indexable n’est pas automatiquement indexée. Google peut la juger dupliquée, peu utile, isolée ou insuffisamment importante. Examinez son contenu, ses liens internes, sa balise canonique, son rôle et les pages concurrentes sur le site.
3. Contrôler les codes HTTP et les redirections
Repérer les réponses qui interrompent le parcours
Chaque URL importante doit normalement répondre en 200. Les pages supprimées doivent utiliser un code approprié, généralement 404 ou 410. Une redirection permanente doit mener directement vers la destination la plus pertinente.
Recherchez :
- les erreurs 4xx et 5xx sur les liens internes
- les chaînes et boucles de redirection
- les redirections vers des pages sans rapport
- les redirections temporaires utilisées durablement
- les soft 404, c’est-à-dire les fausses pages d’erreur qui renvoient un code 200
- les variantes HTTP, HTTPS, avec ou sans www
Conserver une table de redirection
Après une migration, conservez une table d’ancienne URL vers nouvelle URL. Mettez aussi à jour les liens internes pour éviter de faire passer les utilisateurs et les robots par des redirections inutiles.
4. Vérifier les URL canoniques et les doublons
La balise canonique indique la version préférée parmi des pages identiques ou très proches. Elle constitue un signal, pas une instruction absolue. Pour être cohérente, l’URL choisie doit répondre en 200, être indexable, figurer dans le sitemap et recevoir les liens internes principaux.
Repérez les balises canoniques absentes, multiples, dirigées vers une redirection, une erreur ou une page non indexable. Contrôlez les variantes causées par les paramètres, filtres, majuscules, barres obliques finales et protocoles.
N’utilisez pas la balise canonique pour masquer une architecture incontrôlée. Supprimez les URL inutiles, consolidez le contenu et corrigez les liens lorsque c’est possible.
5. Tester le rendu JavaScript
Comparer le HTML initial et le DOM rendu
Sur un site JavaScript, comparez le HTML initial avec le DOM rendu. Vérifiez que le contenu principal, les titres, les liens internes, les balises canoniques, les données structurées et les directives restent présents après rendu.
Les problèmes courants comprennent :
- contenu chargé uniquement après une interaction
- liens construits sans attribut href exploitable
- erreurs JavaScript qui interrompent le rendu
- titres et balises canoniques modifiés côté client
- dépendance à des API bloquées ou lentes
- rendu côté client coûteux sur mobile
Tester les URL représentatives
Le rendu côté serveur ou la génération statique peut réduire certains risques, mais aucun modèle n’est automatiquement SEO. Testez les URL dans Search Console et avec les outils du navigateur. Comparez aussi l’expérience de Googlebot Smartphone.
6. Examiner l’architecture et les liens internes
Une bonne architecture permet d’atteindre les pages importantes en peu d’étapes et répartit les liens selon leur valeur. Cartographiez les profondeurs, les pages orphelines, les hubs, les ancres et les liens cassés.
Les liens internes doivent être éditoriaux et descriptifs. Une ancre comme « audit technique SEO » aide davantage qu’un « en savoir plus » répété. Évitez toutefois la répétition artificielle d’une ancre exacte.
Contrôlez la navigation mobile, le fil d’Ariane, la pagination et les liens ajoutés par JavaScript. Une page présente dans le sitemap mais absente de l’architecture reste faible.
7. Évaluer la structure des pages
Relier les balises à l’intention
Chaque page doit avoir un objectif, un title pertinent et un H1 principal clair. Les H2 et H3 structurent le sujet sans être utilisés comme décoration. Vérifiez les titres manquants, dupliqués, trop vagues ou déconnectés de l’intention.
Contrôlez aussi :
- la cohérence entre title, H1, contenu et requête
- la qualité des méta-descriptions, sans les traiter comme un facteur direct de classement
- le texte alternatif des images informatives
- les contenus identiques entre modèles
- les pages minces ou sans rôle distinct
- la cannibalisation entre plusieurs URL visant la même intention
Relier le diagnostic à la qualité de la réponse
Une page techniquement parfaite peut rester faible si elle ne répond pas au besoin. L’audit doit donc signaler les problèmes éditoriaux qui empêchent une décision technique correcte.
8. Contrôler les Core Web Vitals
Les trois métriques actuelles sont LCP, INP et CLS. Les seuils « bons » sont respectivement 2,5 secondes ou moins, 200 millisecondes ou moins et 0,1 ou moins au 75e centile.
Utilisez Search Console pour les groupes d’URL, PageSpeed Insights pour comparer terrain et laboratoire, puis DevTools pour trouver la cause. Le guide complet des Core Web Vitals détaille les corrections.
Priorisez les modèles commerciaux. Une image principale lente sur toutes les pages de service mérite plus d’attention qu’une alerte isolée sur une archive peu visitée.
9. Vérifier mobile, accessibilité et expérience
Google explore principalement avec un agent mobile. Assurez-vous que la version mobile contient les mêmes informations essentielles, liens, balises et données structurées. Testez les menus, formulaires, bandeaux de consentement et éléments tactiles.
L’accessibilité et le SEO ne sont pas identiques, mais ils partagent des fondations : HTML sémantique, titres cohérents, libellés, navigation au clavier et alternatives textuelles. Un audit technique doit signaler les obstacles évidents qui rendent une page difficile à utiliser.
10. Auditer les données structurées
Les données structurées décrivent certaines entités et relations dans un format interprétable. Vérifiez leur validité avec le test des résultats enrichis (search.google.com), puis contrôlez qu’elles correspondent exactement au contenu visible.
Recherchez les propriétés requises manquantes, les types inadaptés, les avis auto-attribués et les informations contradictoires. Un balisage valide ne garantit pas un résultat enrichi. Il ne remplace ni une page de qualité ni une information visible.
11. Contrôler les sitemaps XML
Un sitemap facilite la découverte des URL canoniques importantes. Il doit contenir des réponses 200, indexables, sans redirection et avec des dates de modification honnêtes.
Sur un grand site, séparez les sitemaps par type de page pour faciliter le diagnostic. Comparez le nombre soumis et indexé par section. Ne gonflez pas artificiellement lastmod à chaque génération si le contenu n’a pas changé.
12. Vérifier l’international et le hreflang
Pour un site multilingue ou multirégional, chaque page doit avoir une URL distincte et un contenu réellement localisé. Les annotations hreflang doivent être réciproques, utiliser des codes valides et pointer vers des URL canoniques indexables.
Ajoutez x-default lorsque cela correspond à la logique de sélection. Ne redirigez pas automatiquement tous les visiteurs selon leur adresse IP. Laissez un moyen clair de changer de langue ou de région.
13. Examiner HTTPS et la sécurité visible
Toutes les ressources et URL canoniques doivent utiliser HTTPS. Recherchez le contenu mixte, les certificats invalides et les liens internes HTTP. Vérifiez que les redirections vers HTTPS sont directes et cohérentes.
Les pages piratées, téléchargements dangereux et interstitiels trompeurs présentent des risques évidents pour les utilisateurs et la visibilité. Search Console peut signaler certains problèmes de sécurité.
14. Valider la mesure et les conversions
Un audit ne peut pas juger la valeur du SEO sans mesure fiable. Contrôlez que les balises d’analyse se déclenchent avec le consentement requis, que les conversions importantes sont définies et que les domaines ou sous-domaines ne cassent pas les sessions.
Testez les formulaires, appels, achats ou réservations. Distinguez les conversions primaires des micro-conversions. Notez les changements de configuration susceptibles de créer une hausse ou une baisse artificielle.
Transformer le crawl en plan d’action
Rédiger des tickets vérifiables
Classez chaque constat selon quatre critères : impact, étendue, confiance dans le diagnostic et effort. Une priorité élevée affecte généralement des pages à forte valeur, se reproduit sur un modèle et possède une cause vérifiable.
Chaque ticket doit contenir :
- le problème et les URL représentatives
- la preuve observée
- l’impact probable, sans exagération
- la correction attendue
- les critères d’acceptation
- la méthode de validation après déploiement
Séparer les corrections des investigations
Séparez les corrections immédiates, les projets structurels et les investigations. Toutes les alertes d’un crawler ne sont pas des erreurs. Une page noindex peut être intentionnelle, et une redirection peut être correcte.
Checklist de validation après correction
Après le déploiement :
- Refaire un crawl ciblé des URL concernées.
- Vérifier les réponses HTTP, directives et versions rendues.
- Tester les liens, formulaires et modèles sur mobile.
- Inspecter quelques URL dans Search Console.
- Surveiller les logs et erreurs serveur lorsque l’enjeu le justifie.
- Comparer les indicateurs au point de départ après un délai réaliste.
Ne fermez pas un ticket parce qu’un développeur a livré du code. Fermez-le lorsque le comportement attendu est vérifié en production.
Erreurs fréquentes lors d’un audit technique SEO
La première erreur est d’exporter les alertes d’un outil sans interprétation. La deuxième est de traiter toutes les URL comme équivalentes. La troisième est de corriger le symptôme sur une page au lieu du modèle.
Évitez aussi les recommandations vagues comme « améliorer la vitesse » ou « corriger les balises canoniques ». Un développeur doit savoir quoi changer et comment le résultat sera testé. Enfin, ne promettez pas qu’une correction entraînera mécaniquement une hausse de classement. Elle retire une contrainte, mais le contenu et la concurrence comptent toujours.
Questions fréquentes
Combien de temps prend un audit technique SEO ?
Cela dépend du nombre de modèles, de la technologie, des données disponibles et du risque. Un petit site peut être contrôlé rapidement. Un site international, JavaScript ou comportant des millions d’URL exige une analyse plus longue.
Quel outil suffit pour faire un audit ?
Aucun outil ne suffit seul. Un crawler montre la structure accessible, Search Console la relation avec Google, l’analyse les comportements, les logs l’exploration réelle et le navigateur le rendu.
À quelle fréquence refaire l’audit ?
Après une migration ou une refonte, contrôlez immédiatement les éléments critiques. Pour un site stable, mettez en place une surveillance régulière et un audit plus large lors de changements importants ou d’anomalies.
Un audit garantit-il une hausse de trafic ?
Non. Il identifie et hiérarchise les contraintes. Les résultats dépendent ensuite de la qualité de l’exécution, de la demande, du contenu, de l’autorité et de la concurrence.
Consultant SEO indépendant et ancien développeur front-end. Plus de huit ans d’expérience et plus de 50 clients au Royaume-Uni et en Europe.
