Faire un audit technique SEO : la checklist complète (2026)

La plupart des sites qui stagnent ne stagnent pas à cause de leur contenu. Ils stagnent parce qu'une partie de leurs pages n'est pas explorée, pas indexée, ou trop lente pour rassurer Google. Un audit technique sert exactement à ça : repérer, méthodiquement, ce qui empêche vos pages d'exister aux yeux des moteurs. Voici la marche à suivre, dans le bon ordre.

Pourquoi commencer par la technique

On a souvent le réflexe inverse : on veut « écrire du contenu qui rank » avant même de vérifier que le site est sain. C'est mettre la charrue avant les bœufs. La grande majorité des problèmes de classement ne viennent pas de textes trop courts ou mal écrits, mais d'un souci de crawl ou d'indexation : une page bloquée, une balise qui se contredit, un site trop lent que Google finit par explorer moins souvent.

Être visible de Google est le préalable à tout le reste. Tant qu'une page n'est pas correctement explorée puis indexée, elle ne peut se positionner sur aucun mot-clé — quel que soit son contenu. C'est pour ça qu'un audit démarre toujours par la technique. C'est le fondement de tout notre travail de SEO technique, avant même de parler stratégie éditoriale.

Phase 1 — Crawlabilité

La crawlabilité, c'est la capacité de Google à parcourir votre site. Si le robot ne peut pas atteindre une page, elle n'existe pas pour lui. On vérifie donc, dans l'ordre :

• Un fichier robots.txt propre — il ne doit bloquer que ce qui doit l'être. Une directive trop large peut couper l'accès à des sections entières sans que vous le sachiez.
• Les CSS et le JS non bloqués — Google a besoin de charger ces ressources pour « voir » votre page comme un internaute. Les bloquer fausse l'analyse et peut coûter des positions.
• Un sitemap XML à jour — il liste les URLs à explorer en priorité et doit être soumis dans la Search Console, sans pages mortes ni redirections.
• Un maillage interne qui rend les pages accessibles — une page sans lien entrant est une page orpheline, difficile à découvrir pour le robot.
• Un budget de crawl maîtrisé — sur les gros sites, Google alloue un nombre limité de pages explorées. On évite de le gaspiller sur des pages inutiles (paramètres d'URL, filtres, doublons).

C'est ici que se joue la première marche. Pour aller au fond du sujet, on détaille tout dans notre guide dédié au sitemap XML et robots.txt.

Phase 2 — Indexation

Une page explorée n'est pas forcément indexée. La phase 2 vérifie que Google range bien vos pages dans son index — et surtout qu'aucun signal ne l'en empêche par accident.

On contrôle trois choses : les balises noindex (une page importante ne doit jamais en porter), les canonical (elles doivent pointer vers la bonne version de chaque URL), et surtout les conflits entre les deux. Un noindex et une canonical qui se contredisent est l'un des tueurs d'indexation les plus silencieux : la page envoie deux ordres opposés à Google, qui tranche rarement en votre faveur. Ce type de conflit ne déclenche aucune alerte visible — il faut aller le chercher.

On finit par vérifier la couverture d'index dans la Search Console : combien de pages sont indexées, lesquelles sont exclues, et pour quel motif. C'est le juge de paix. Pour maîtriser ces balises sans vous piéger, lisez notre guide canonical et redirections.

Phase 3 — Performance

Une fois que Google peut explorer et indexer vos pages, on regarde à quelle vitesse elles se chargent. La performance n'est pas un détail de confort : elle influence directement l'expérience utilisateur et fait partie des signaux de classement.

Le cadre de référence, ce sont les Core Web Vitals : le LCP (temps d'affichage du contenu principal), l'INP (réactivité aux interactions) et le CLS (stabilité visuelle pendant le chargement). On mesure la vitesse générale, mais surtout les données terrain — celles issues des vrais visiteurs, plus fiables qu'un simple test en laboratoire. C'est le terrain qui décide.

On traite ce sujet en profondeur, réglage par réglage, dans notre article dédié aux Core Web Vitals.

Phase 4 — Mobile & sécurité

La performance réglée, on vérifie que le site tient la route là où l'essentiel du trafic se joue : sur mobile. Google applique l'indexation mobile-first, c'est-à-dire qu'il classe votre site à partir de sa version mobile, pas de la version bureau. Un contenu masqué sur téléphone, un menu cassé ou une mise en page qui saute, et ce sont vos positions qui trinquent — y compris pour les recherches faites sur ordinateur.

Trois points de contrôle :

• Indexation mobile-first — la version mobile doit contenir le même contenu que la version bureau, sans texte tronqué ni bloc caché.
• HTTPS partout — chaque URL doit être servie en sécurisé, sans contenu mixte (des ressources en HTTP sur une page en HTTPS).
• Pas de contenu masqué sur mobile — ce que voit l'internaute mobile doit être ce que voit Google. Un contenu replié dans des onglets peut passer, mais un contenu carrément absent est un vrai problème.

Phase 5 — Données structurées & signaux

Dernière phase : les signaux qui aident Google à comprendre et à mettre en valeur vos pages. Ce ne sont pas des correctifs d'urgence, mais des optimisations qui font la différence sur des sites déjà sains.

• Un balisage Schema.org valide — les données structurées décrivent explicitement le contenu (article, produit, FAQ, avis) et ouvrent la porte aux résultats enrichis. On vérifie qu'elles sont présentes et sans erreur.
• Un fil d'Ariane — il clarifie la structure du site pour l'internaute comme pour le moteur, et renforce le maillage interne.
• La cohérence des balises — title, meta description et hiérarchie des Hn (un seul H1, des H2/H3 logiques) doivent être uniques et cohérents sur chaque page.

À quelle fréquence auditer

Un audit technique n'est pas un one-shot. Le web bouge, votre site évolue, et les régressions arrivent souvent sans prévenir. Voici le rythme que nous recommandons :

• Un audit complet au moins tous les 6 mois — pour repartir sur une base saine et vérifier l'ensemble des cinq phases.
• Un audit ciblé avant et après tout changement majeur — migration, refonte, changement de CMS ou de domaine. Ce sont les moments où les problèmes techniques explosent.
• Un monitoring mensuel léger entre deux — stats de crawl, Core Web Vitals et couverture d'index suffisent à repérer une dérive tôt.
• Des audits trimestriels pour attraper les régressions avant qu'elles ne coûtent des positions.

La logique est simple : plus une régression est détectée tôt, moins elle coûte cher à corriger.

Les outils indispensables

Pas besoin d'un arsenal coûteux pour mener un audit sérieux. Trois outils couvrent l'essentiel :

• Google Search Console — la source de vérité pour la couverture d'index et les Core Web Vitals mesurés sur le terrain. Gratuite et indispensable.
• Un crawler type Screaming Frog — il simule le parcours de Google et remonte les pages orphelines, les redirections en chaîne, les balises manquantes ou en conflit.
• PageSpeed Insights — pour analyser la performance page par page et distinguer données de laboratoire et données terrain.

Combinés, ces trois outils suffisent à couvrir la quasi-totalité d'un audit technique. Le reste, c'est de la méthode et de l'interprétation.

Récap en checklist

Pour garder le cap, voici les cinq phases résumées. À dérouler dans l'ordre, sans en sauter une :

• Crawlabilité — robots.txt propre, CSS/JS non bloqués, sitemap XML à jour, maillage interne, budget de crawl maîtrisé.
• Indexation — balises noindex vérifiées, canonical correctes, aucun conflit entre les deux, couverture d'index contrôlée dans la Search Console.
• Performance — Core Web Vitals (LCP, INP, CLS), vitesse et données terrain au vert.
• Mobile & sécurité — indexation mobile-first, HTTPS partout, aucun contenu masqué sur mobile.
• Données structurées & signaux — Schema.org valide, fil d'Ariane, cohérence des title/meta/Hn.

Questions fréquentes