Un client m'appelle un mardi matin, paniqué. Son trafic a chuté de 40 % en trois semaines. Aucune pénalité dans Search Console, aucun message manuel, rien dans les alertes. On passe deux heures à regarder ses contenus, ses titres, ses backlinks. Rien. Puis je lance un crawl complet : 11 000 pages en noindex posées par erreur lors d'une migration de thème, six semaines plus tôt. Personne ne s'en était aperçu parce que personne ne faisait d'audit technique SEO régulier.
Ce genre d'histoire, je pourrais vous en raconter une dizaine. Et c'est précisément pour ça que je ne crois pas aux checklists qu'on coche une fois par an puis qu'on oublie. Un audit technique SEO, c'est un examen clinique. Il faut savoir quoi regarder, dans quel ordre, et surtout comment trancher entre cinquante corrections possibles quand on a trois jours de budget.
Points clés à retenir
- Un audit technique ne sert à rien s'il ne débouche pas sur un plan d'action priorisé et daté.
- Le crawl réel (logs serveur) révèle des problèmes que le crawl simulé ne voit jamais.
- Cinq familles de contrôles suffisent : indexation, architecture, performance, balisage, gouvernance.
- Priorisez toujours par impact × effort, pas par ordre de la checklist.
- Les crawlers IA sont devenus un paramètre à part entière du budget de crawl.
Audit technique SEO : la checklist qui survit au terrain
La plupart des checklists que je croise sur le web alignent 50 à 80 points. Elles sont correctes sur le fond et inutiles dans la pratique. Pourquoi ? Parce qu'elles ne disent jamais ce qu'on fait du résultat. Vous cochez, vous obtenez une liste de 47 problèmes, et vous êtes plus bloqué qu'avant.
Ma méthode tient en cinq blocs. Je les passe toujours dans cet ordre, et j'y consacre environ 70 % du temps aux deux premiers.
Bloc 1 — Indexation et crawl
C'est le socle. Si Google ne peut pas explorer ou indexer vos pages, tout le reste est décoratif.
- Vérifier le robots.txt : bloquage accidentel de répertoires entiers, directives obsolètes héritées d'anciens prestataires.
- Contrôler les balises noindex dans le code source, pas seulement dans l'interface d'administration (c'est exactement le bug de mon client).
- Croiser le nombre d'URL soumises au sitemap et le nombre réellement indexées. Un écart de plus de 30 % mérite une investigation.
- Chercher les pages orphelines : accessibles par URL directe, mais sans aucun lien interne pointant vers elles.
- Analyser la couverture dans la Search Console, page par page, pas seulement le graphique global.
Un détail que j'ai mis des mois à intégrer : le sitemap XML n'est pas une garantie d'indexation. J'ai vu des sites avec un sitemap impeccable et 60 % de pages exclues pour cause de contenu dupliqué généré par des filtres de navigation.
Bloc 2 — Le crawl réel contre le crawl simulé
Voilà le point que presque personne ne traite sérieusement. Un outil comme Screaming Frog vous montre ce qui pourrait être crawlé. Les logs serveur vous montrent ce qui est crawlé, à quelle fréquence, et par qui. Ce sont deux mondes différents.
Sur un projet e-commerce que j'ai repris, le crawl simulé remontait 8 000 URL propres. Les logs, eux, révélaient que Googlebot passait 62 % de son budget sur des URL de tri et de pagination sans valeur. Résultat : les fiches produits importantes étaient revisitées tous les 20 jours. On a corrigé en trois actions simples, et la fréquence de recrawl des fiches est passée à 4 jours.
Bloc 3 — Architecture et maillage interne
La règle des trois clics a ses limites, mais elle reste un bon révélateur. Si une page stratégique est à six clics de l'accueil, elle ne recevra presque aucune autorité interne.
Je trace systématiquement une carte de profondeur. Les pages à plus de quatre clics qui comptent commercialement sont un signal d'alarme. Et les pages orphelines ? Sur un site de 2 000 URL, j'en trouve régulièrement entre 5 et 12 %. Elles existent, elles sont parfois indexées, mais aucun lien ne les relie au reste.
Bloc 4 — Performance et Core Web Vitals
Les seuils sont connus : LCP sous 2,5 secondes, INP sous 200 millisecondes, CLS sous 0,1. Ce qui l'est moins, c'est où ça casse.
Dans la majorité des audits que j'ai menés, le LCP se dégrade à cause de deux choses : une image héros mal optimisée, ou une police chargée en bloque. Pas de mystère technique. J'ai passé une semaine entière à optimiser du JavaScript sur un site, pour découvrir que 80 % du gain venait en fait de la compression de trois images. Leçon retenue.
Bloc 5 — Balisage structuré et gouvernance
Les données structurées ne font pas ranker, mais elles améliorent l'affichage dans les résultats et nourrissent les moteurs génératifs. Vérifiez les types Schema.org présents, leur validité, et surtout leur cohérence avec le contenu visible.
Le volet gouvernance, lui, est trop souvent oublié. Qui met à jour le robots.txt ? Qui valide une redirection avant mise en production ? Sans réponse claire, vous referez le même audit dans six mois.
Comment prioriser les corrections quand tout semble urgent
Une liste de 47 problèmes n'est pas un livrable. Un plan d'action, oui. Ma grille tient sur une feuille.
| Criticité | Impact estimé | Effort | Délai conseillé |
|---|---|---|---|
| Bloquante | Perte d'indexation ou de trafic directe | Faible à moyen | 72 heures |
| Haute | Gain de crawl ou de visibilité mesurable | Moyen | 2 à 4 semaines |
| Moyenne | Optimisation progressive | Variable | Trimestre |
| Basse | Confort, dette technique | Élevé | Backlog |
Le piège classique : traiter d'abord ce qui est facile. Les redirections manquantes, les titles trop longs — ça se corrige vite et ça donne l'impression d'avancer. Sauf que pendant ce temps, une erreur d'indexation continue de vous coûter du trafic chaque jour.
Ma règle personnelle, et je la défendrai bec et ongles : on traite les problèmes bloquants avant tout le reste, même s'ils demandent trois fois plus d'effort.
Quels outils pour mener un audit technique SEO complet ?
Aucun outil ne fait le travail à votre place. Mais certains accélèrent énormément.
- Screaming Frog — le crawl simulé de référence, avec connexion à la Search Console
- Sitebulb — interface plus lisible sur les problématiques d'architecture
- Logs serveur — indispensable pour le crawl réel, aucune alternative sérieuse
- API Search Console — pour automatiser le suivi de couverture dans le temps
- Un tableur, tout simplement, pour la matrice de priorisation
Franchement, si vous ne devez retenir qu'un investissement : les logs. C'est là que se cachent les vérités que les interfaces ne montrent pas.
À quoi doit ressembler le livrable d'un audit ?
J'ai longtemps livré des rapports de 40 pages. Mes clients les ouvraient une fois. Désormais, je livre trois choses :
- Un tableau de bord d'une page avec les cinq problèmes prioritaires
- Un plan d'action daté, avec responsable et indicateur de suivi pour chaque correction
- Une annexe technique détaillée, pour l'équipe de développement
Et une revue à 30 jours, systématiquement. Parce qu'un audit sans vérification après correction, c'est un diagnostic sans ordonnance.
Et en 2026, qu'est-ce qui change vraiment ?
Les crawlers IA — GPTBot, ClaudeBot, PerplexityBot et consorts — consomment désormais une part non négligeable du budget de crawl sur certains sites. J'ai mesuré sur un projet récent : ils représentaient 18 % des requêtes de robots. Ça se gère dans le robots.txt, mais ça se décide consciemment. Bloquer ou autoriser ces agents, c'est un choix stratégique, pas un réglage par défaut.
Ce qui reste inchangé, en revanche : une base technique propre reste le préalable à tout le reste. Les moteurs génératifs citent les pages qu'ils peuvent lire correctement. Le balisage structuré, la clarté du contenu, la vitesse de chargement — tout ça compte encore, différemment.
L'audit technique n'est pas une case à cocher annuelle. C'est un réflexe. Ceux qui le traitent comme tel arrêtent de découvrir leurs problèmes par accident, un mardi matin, quand le téléphone sonne.
