Audit technique SEO : la checklist complète pour tout vérifier

Un client m'appelle un mardi matin, paniqué. « On a perdu 40 % de trafic en trois semaines. On a relu tous nos articles, tout est bon. » Je demande à voir la Search Console. Deux minutes plus tard, j'avais la réponse : un stagiaire avait déployé une nouvelle version du site en laissant le fichier robots.txt de la préprod en production. Trois lignes de texte. Quatre semaines de trafic envolé.

Voilà pourquoi un audit technique SEO ne se résume jamais à une liste de cases à cocher : c'est un diagnostic, avec un ordre de priorité. La checklist complète que je vous donne ici, je l'utilise sur des sites qui vont de la PME de 200 pages à des plateformes à 800 000 URLs. Elle n'est pas exhaustive dans l'absolu — elle est exhaustive dans ce qui compte vraiment.

L'audit technique SEO : la checklist complète dans le bon ordre

La plupart des checklists que je croise sur le web listent les points par catégorie, sans hiérarchie. C'est une erreur de conception. Si vous corrigez le CLS d'une page avant d'avoir vérifié qu'elle est indexable, vous perdez du temps. L'ordre compte.

Ma règle : on descend d'un niveau à chaque étape validée. Crawl → indexation → architecture → contenu technique (canonical, hreflang, balisage) → performance. On ne saute jamais d'étape.

Étape 1 : vérifier que le robot voit ce qu'il doit voir

Le premier réflexe, c'est d'aller regarder le fichier robots.txt. Pas pour le lire en diagonale : pour vérifier qu'il ne bloque rien d'essentiel. J'ai vu récemment un site e-commerce avec la ligne Disallow: /catalog — le catalogue entier, invisible pour Google depuis la mise en prod d'il y a huit mois. Le client n'avait rien vu parce que les pages étaient toujours accessibles aux visiteurs.

Ensuite, le sitemap. Est-il déclaré en Search Console ? Contient-il bien les URLs canoniques et uniquement celles-là ? J'ai récupéré un projet où le sitemap comptait 12 000 entrées pour un site qui n'avait que 3 100 pages réellement indexables : le reste était des paramètres de tri et des pages de pagination. Résultat, Google passait son temps à crawler du vide.

• Vérifier robots.txt avec l'outil de test d'URL de la Search Console (et pas seulement à l'œil)
• Contrôler que le sitemap XML ne contient ni redirections, ni 404, ni noindex
• Chercher des balises meta name="robots" résiduelles dans les environnements de préprod
• Compter les URLs soumises vs les URLs indexées : un écart de plus de 30 % mérite une investigation

Étape 2 : le rapport de couverture, votre meilleur indicateur

Le rapport « Indexation des pages » de la Search Console est sous-exploité. Tout le monde regarde le nombre de pages indexées. Presque personne ne regarde le motif des exclusions. Pourtant, c'est là que tout se joue.

Le filtre qui m'intéresse le plus est « Explorée, actuellement non indexée ». Quand ce chiffre grimpe sur un site dont la qualité ne change pas, ça veut dire une chose : Google a exploré vos pages et a décidé qu'elles ne valaient pas la peine. Soit leur contenu est trop proche d'une autre, soit elles sont trop pauvres, soit l'architecture les enterre sous des centaines de clics. C'est un signal indirect de qualité de contenu, mais il se lit dans un rapport technique.

Et là, la vraie question : avez-vous un moyen de savoir si ce chiffre augmente ? Autrement dit, avez-vous un historique. Je recommande fortement d'exporter ces rapports tous les mois dans un tableur, ne serait-ce que pour voir les tendances. Sur un projet média que j'ai suivi, ce simple suivi mensuel a permis de détecter une dégradation de 18 % de la couverture en deux mois, avant que la courbe de trafic ne plonge. On a corrigé à temps.

Architecture et maillage interne : la partie que tout le monde saute

La profondeur de clic reste, à mon avis, le point le plus négligé d'un audit. Et celui qui coûte le plus cher sur les sites de taille moyenne.

Une page clé qui se trouve à six clics de l'accueil n'a aucune chance de rivaliser avec une concurrente à deux clics, même si son contenu est meilleur. J'ai fait un test sur un site de 4 500 pages : j'ai rapproché une catégorie de produits de l'accueil via un menu secondaire et deux liens contextuels dans des articles existants. En six semaines, la requête principale de cette catégorie est passée de la position 22 à la position 8. Aucun contenu n'avait changé. Seule la distance a changé.

Comment détecter les pages orphelines

Une page orpheline est une page accessible par URL directe mais vers laquelle aucun lien interne ne pointe. Elle existe, elle répond en 200, elle n'est référencée nulle part. Google la trouvera peut-être via un sitemap, mais elle n'aura aucun signal interne. Pour la détecter :

1. Extraire toutes les URLs du sitemap
2. Crawler le site et lister toutes les URLs découvertes via les liens
3. Faire la différence entre les deux ensembles
4. Vérifier pour chaque orpheline si elle mérite d'être liée, redirigée ou supprimée

Oui, c'est artisanal. Non, il n'y a pas d'outil magique qui règle ça à votre place avec certitude. Et le pire, c'est que la plupart des orphelines que je trouve sont d'anciennes pages de contenu qui généraient du trafic avant un refonte. On les a « oubliées » parce qu'elles n'étaient plus dans le menu.

Core Web Vitals : ce qu'il faut mesurer, et à quel moment

Une nuance qui revient souvent dans mes échanges avec des équipes produit : les Core Web Vitals ne sont pas un facteur de positionnement majeur. Ils le sont devenus un facteur d'arbitrage quand deux pages se disputent un classement, mais ils ne vous feront jamais passer de la 20e à la 3e position. En revanche, un LCP catastrophique tue l'expérience utilisateur, et ça, Google le voit.

Les seuils que je cible :

Métrique	Ce qu'elle mesure	Seuil acceptable	Priorité dans un audit
LCP	Délai d'affichage du plus grand élément	Moins de 2,5 s	Haute
INP	Réactivité aux interactions	Moins de 200 ms	Moyenne
CLS	Stabilité visuelle	Moins de 0,1	Moyenne
TTFB	Temps de première réponse serveur	Moins de 800 ms	Haute sur gros sites

Le LCP est celui qui pose le plus de problèmes dans mon expérience, et presque toujours pour la même raison : une image hero mal optimisée ou un script tiers chargé avant le contenu. Sur un site de presse, on a récupéré 1,4 seconde de LCP en passant simplement les polices en font-display: swap et en décalant une bannière publicitaire. Je n'ai touché ni au serveur ni au code applicatif.

Attention à la différence entre données de terrain et données de laboratoire

Le rapport de performance de la Search Console s'appuie sur des données de terrain (des utilisateurs réels), tandis que Lighthouse mesure en laboratoire, dans des conditions contrôlées. Les deux ne racontent pas la même histoire. Un site peut avoir un LCP excellent sur Lighthouse et médiocre sur le terrain, parce que la majorité de ses visiteurs sont sur mobile avec une connexion moyenne. Quand les deux divergent, fiez-vous au terrain. C'est ce que Google utilise.

Gros sites : quand le crawl budget devient le vrai sujet

Au-delà de quelques milliers d'URLs, les priorités changent complètement. Un site de 200 pages n'a pas de problème de budget de crawl. Un site de 500 000, si.

Sur ces plateformes, trois chantiers reviennent systématiquement :

• Les facettes et paramètres de tri, qui génèrent des milliers d'URLs quasi identiques. On les gère par canonicalisation vers l'URL de base, ou par blocage via robots.txt quand la canonicalisation ne suffit pas — arbitrage à faire au cas par cas.
• La pagination. Les pages 2, 3, 4 d'une liste ont-elles un intérêt ? Parfois oui (navigation), souvent non (contenu dupliqué). Le rel="next/prev" n'est plus pris en compte par Google depuis des années, mais la logique reste : ne pas gaspiller le crawl sur des pages sans valeur ajoutée.
• Le hreflang sur les sites multilingues. Une erreur de hreflang, et vous vous retrouvez avec deux versions concurrentes qui se cannibalisent. J'ai corrigé un cas où la version française pointait vers elle-même en hreflang alors qu'elle aurait dû pointer vers l'anglais : six mois de confusion dans les résultats.

Sur ces sites, l'analyse des logs serveur devient incontournable. C'est la seule façon de voir combien de fois Googlebot passe, sur quelles URLs, avec quelle fréquence. Une extraction de logs bien filtrée vous dit en une heure ce qu'aucun outil tiers ne peut vous dire : est-ce que le robot visite les pages qui comptent, ou est-ce qu'il s'épuise sur des pages sans intérêt ? Sur un projet, l'analyse des logs a montré que 60 % des passages du robot allaient vers des pages de résultats de recherche internes. Une fois ces pages bloquées, le trafic sur les pages produit a progressé de 12 % en un mois.

Prioriser : impact × effort, sans négociation

Un audit qui livre une liste de 140 anomalies sans hiérarchie est un audit raté. Le client va en corriger trois au hasard, se décourager, et ne jamais finir.

Ma méthode tient en une grille simple. Chaque anomalie reçoit deux notes de 1 à 5 : l'impact estimé sur le trafic et la difficulté de correction. On multiplie l'impact par l'inverse de l'effort, et on trie. Ce qui sort en tête, ce sont les corrections à fort impact et faible effort : un noindex oublié, un sitemap cassé, des redirections en chaîne, un titre dupliqué sur les pages de catégorie. Ce sont ces corrections-là qui, dans mon expérience, font bouger les courbes dans les premières semaines.

Ce qui sort en bas, c'est le refonte de l'architecture, la migration de CDN, l'optimisation des requêtes base de données. On les planifie, mais on ne commence pas par ça.

Et un détail qui compte : notez toujours l'état « avant » avec des chiffres. Le nombre de pages indexées, le trafic organique, le nombre d'erreurs de couverture. Sans point de comparaison, impossible de savoir si vos corrections ont servi à quelque chose trois mois plus tard. J'ai fait l'erreur une fois de lancer un chantier sans baseline. Six semaines de travail, aucune preuve du résultat. On a dû tout remesurer à partir de zéro. Total waste.

Ce qui change en 2026 (et ce qui ne change pas)

La grande question qu'on me pose depuis un an : est-ce que l'IA générative et les réponses enrichies dans les résultats changent l'audit technique ? La réponse honnête : à la marge, oui. Sur le fond, non.

Ce qui change : les pages sans valeur ajoutée, celles qui ne servaient qu'à capter un clic, sont désormais ignorées. Un site qui indexait 3 000 pages de « listes de produits sans contenu » va voir ces pages sortir naturellement. Ça ne se corrige pas techniquement, ça se corrige éditorialement. Mais l'audit technique doit le signaler : ces pages inutiles consomment du crawl, et si vous ne les traitez pas, elles continuent de peser sur le budget.

Ce qui ne change pas : un robots.txt mal configuré reste une catastrophe. Une balise canonical mal placée continue de cannibaliser vos pages. Une redirection en boucle reste une redirection en boucle. Les fondamentaux techniques n'ont pas bougé, et ils restent la base de tout.

Je dirais même que la technicité devient plus discriminante. Quand tout le monde a accès aux mêmes outils d'IA pour produire du contenu, la différence se joue sur la propreté de l'infrastructure. Un site rapide, bien indexé, avec une architecture claire, aura toujours l'avantage sur un site qui rame et dont la moitié des pages sont orphelines.

Deux ou trois questions qu'on me pose souvent

Combien de temps prend un audit technique SEO complet ?

Sur un site de moins de 500 pages, comptez deux à trois jours si vous avez les accès (Search Console, logs, CMS, serveur). Sur un site de plusieurs milliers de pages avec du multilingue et des facettes, une semaine minimum, parfois deux. Ce qui prend le plus de temps n'est jamais l'analyse : c'est le recueil des accès et la compréhension de la façon dont le site est construit. J'ai déjà passé une journée entière à comprendre pourquoi une page de catégorie n'était pas indexable, pour découvrir au final qu'un module de blog générait une balise noindex sur tous les templates de catégorie. Un problème de configuration du CMS, pas de SEO.

Faut-il un outil payant pour faire un audit technique ?

Non. La Search Console, un outil de crawl gratuit (Screaming Frog en version plafonnée à 500 URLs), et un tableur suffisent pour un site de taille moyenne. Les outils payants apportent du confort sur les gros volumes et l'historisation, mais je préfère de loin une analyse manuelle des logs à n'importe quel tableau de bord payant. Les données brutes racontent toujours ce que le tableau de bord résume.

À quelle fréquence faut-il refaire un audit ?

Un audit complet une fois par an, et un contrôle de suivi léger tous les trimestres. Le suivi trimestriel, c'est simplement vérifier que rien n'a cassé : le robots.txt, les redirections principales, le nombre de pages indexées, les erreurs 500. C'est une heure de travail qui évite les catastrophes. Le vrai danger n'est pas l'absence d'audit : c'est de ne pas recommencer après une refonte ou une migration.

La semaine dernière, j'ai relancé un crawl sur un site que j'avais audité il y a deux ans. La configuration du robots.txt avait été modifiée trois fois depuis, dont deux fois pour « tester un truc ». La dernière version bloquait l'ensemble des pages de blog. Le responsable n'avait pas pensé à prévenir personne.

Voilà pourquoi je ne crois pas aux checklists qu'on remplit une fois. Une checklist technique, c'est un rituel, pas un document. Le jour où vous arrêtez de la dérouler, c'est le jour où le stagiaire déploie la préprod en production.