Beaucoup de sites ont un problème technique SEO sans que ce soit visible au premier regard. Une page peut sembler correcte, mais être mal indexée, mal canonisée, trop profonde, ralentie par ses gabarits, ou soutenue par un maillage interne trop faible. L'audit technique sert justement à faire ressortir ces freins, puis à les classer par impact et effort.
Je préfère poser une nuance tout de suite : tout problème technique n'est pas prioritaire. Un bon audit ne consiste pas à tout corriger. Il consiste à repérer ce qui bloque vraiment vos pages importantes, puis à hiérarchiser. Sinon, on retombe dans le rapport de cinquante pages que personne n'exécute.
La version courte
- Un audit SEO technique clarifie crawl, indexation, signaux de page, structure et performance utile.
- Le but n'est pas de tout corriger, mais de traiter ce qui freine déjà les bonnes pages.
- Search Console, exploration du site, sitemap et architecture donnent souvent les premiers vrais signaux.
- La technique doit rester alignée avec l'intention de recherche et le rôle des URLs, pas vivre en silo.
Qu'est-ce qu'un audit SEO technique ?
Un audit SEO technique est une analyse des éléments qui influencent la capacité des moteurs à explorer, comprendre, indexer et servir correctement un site. Cela inclut souvent l' arborescence, les gabarits, les codes HTTP, les redirections, les balises canoniques, l'accès aux ressources (CSS, JS, images), le sitemap XML, les directives d'exploration, la cohérence mobile, et les signaux de performance perçus par les utilisateurs, pas seulement par un outil de lab.
Le but n'est pas seulement d'améliorer un score ou de « faire propre ». Le but est de voir si la technique empêche vos pages business et vos bons contenus de jouer leur rôle. Quand la technique est saine, le plafond suivant est souvent le ciblage, la qualité de page ou la concurrence : un audit SEO plus large aide à trancher où se situe le vrai blocage.
Crawl, indexation et classement : clarifier le périmètre
Je sépare mentalement trois étages. D'abord, Google doit pouvoir découvrir et récupérer les URLs (crawl). Ensuite, il doit décider ce qu'il garde dans son index et comment il canonicalise les variantes. Enfin intervient le classement, où la technique n'est qu'une partie du tableau, avec le contenu, les liens, l'intention et la qualité perçue.
Un audit technique utile traite surtout les deux premiers étages et les signaux de page qui brouillent la lecture (titres, directives, duplication évidente). Il ne promet pas de « gagner dix positions » juste en compressant une image si le fond du problème est ailleurs. En revanche, une page non crawlable, mal canonisée ou signalée comme doublon peut rester invisible malgré un excellent texte : c'est là que l'audit technique paie immédiatement.
Quand lancer un audit SEO technique ?
Je recommande souvent de le lancer quand le site stagne sans raison évidente, quand les pages importantes n'entrent pas correctement dans l'index, quand l'architecture est devenue confuse, ou quand une refonte, une migration ou une forte croissance de contenu a créé trop de complexité.
- les bonnes pages ne rankent pas alors qu'elles semblent sérieuses sur le fond ;
- Search Console remonte des exclusions, des duplications ou des anomalies répétées ;
- le site a grandi sans vraie structure ni règles d'URL claires ;
- la performance ou les gabarits dégradent l'usage sur mobile ;
- vous préparez une migration ou une refonte de CMS ;
- vous voulez savoir si le vrai sujet vient de la technique, du contenu ou du ciblage.
Ma checklist d'audit SEO technique (par familles)
Voici les familles de vérifications que je regarde le plus souvent. L'ordre exact change selon le site, mais cette base suffit déjà à sortir un diagnostic utile. Sur les grosses boutiques, je croise souvent ces points avec les enjeux de facettes et de duplication décrits côté SEO e-commerce.
| Bloc | Ce que je vérifie | Pourquoi c'est utile |
|---|---|---|
| Indexation | exclusions, doublons, canoniques, noindex, soft 404 | Une bonne page absente de l'index n'existe pas vraiment en SEO. |
| Crawl | liens internes, profondeur, orphelines, robots.txt, filet de liens vers l'important | Les URLs à enjeu doivent être atteignables et crawlables sans friction inutile. |
| Architecture | hiérarchie, gabarits, logique des sections, cannibalisation structurelle | Une structure confuse dilue la force des pages importantes. |
| Signaux de page | title, description, H1, canonical, hreflang si multilingue, redirections | Des incohérences brouillent la lecture et peuvent fusionner ou déclasser des URLs. |
| Performance utile | LCP, INP, CLS, stabilité mobile, poids des scripts tiers | L'expérience réelle compte pour les utilisateurs et pour les systèmes de qualité de page. |
| Sitemap et plans | contenu du XML, cohérence avec l'indexable, erreurs de soumission | Le sitemap doit aider Google, pas envoyer un inventaire bruité. |
Indexation : couverture, canoniques et « pourquoi pas indexé »
Le rapport de page indexing dans Search Console reste souvent le point de départ le plus honnête : il montre ce que Google dit avoir fait de vos URLs, avec des motifs d'exclusion qu'il faut lire avec prudence (une URL peut être « exclue » parce qu'une autre est canonique, ce qui est parfois normal). L'outil d'inspection d'URL permet de tester une page précise : fetch réussi, indexation autorisée ou non, canonical déclaré vs canonical choisi.
Je contrôle systématiquement les chaînes de redirections, les erreurs 5xx récurrentes, les pages en noindex involontaire (staging laissé ouvert, mauvais gabarit, mauvais environnement). Les doublons importants (HTTP/HTTPS, www/non-www, slash final, paramètres) doivent être résolus par des règles stables et des canoniques cohérentes, pas par des rustines page par page sans logique globale.
Quand plusieurs URLs ciblent la même intention sans stratégie, on glisse vers de la cannibalisation. L'audit technique recoupe alors le travail sur la structure et le maillage : ce n'est plus seulement une balise canonical, c'est une décision sur la page de référence.
Je contrôle aussi les versions du site servies aux utilisateurs et aux bots : HTTPS partout, pas de contenu mixte critique qui casse le chargement, certificat valide, et une seule version préférée (redirections propres entre HTTP et HTTPS, entre www et non-www). Des incohérences ici créent des duplications artificielles et des signaux de crawl inutiles. Sur les sites multilingues, je croise ces vérifications avec les règles hreflang et l'architecture décrite dans le service SEO international multilingue, pour éviter que chaque langue ne multiplie les variantes d'URL sans filet.
Crawl : robots.txt, liens, profondeur et ressources critiques
Le fichier robots.txt contrôle ce que Google peut demander au crawl, pas ce qu'il indexe à coup sûr. S'en servir pour « cacher une page sensible de l'index » est une erreur classique : si la page reçoit des liens externes, elle peut encore être indexée sans contenu crawlable. Pour les pages à exclure de l'index, on pense plutôt noindex, authentification, ou suppression selon le cas, toujours en respectant les bonnes pratiques officielles.
Je vérifie que les ressources nécessaires au rendu (CSS, JS, polices) ne sont pas bloquées par erreur pour Googlebot, surtout sur les stacks JavaScript lourdes. Les pages orphelines, seulement liées depuis des sitemaps sans lien interne, manquent souvent de contexte : le crawl peut être irrégulier et le classement plus fragile. D'où l'intérêt d'un maillage qui reflète la hiérarchie définie dans l' arborescence.
Sur les sites très profonds, je regarde aussi la pagination, les filtres et les URLs générées : est-ce que le crawl part dans des milliers de combinaisons inutiles ? Google documente des risques liés à la navigation à facettes ; l'audit doit proposer des règles (noindex ciblé, maîtrise des paramètres, canonicals, exclusion robots quand c'est approprié) alignées avec votre modèle métier.
Performance : Core Web Vitals et expérience réelle
Les Core Web Vitals résument une partie de l'expérience de chargement et d'interaction : LCP pour le chargement du contenu principal, INP pour la réactivité aux interactions, CLS pour la stabilité visuelle. Les seuils publics donnent une cible utile, mais je lis surtout les données terrain (Search Console, Chrome UX Report) plutôt qu'un seul test lab isolé.
Le guide Core Web Vitals SEO détaille comment éviter de transformer la performance en obsession de score. Dans un audit technique, je cherche les causes qui touchent beaucoup de pages (gabarit, hero image non optimisée, police qui bloque, script tiers, carrousel qui repousse le LCP) avant de polir des micro-gains sur une URL marginale.
JavaScript, rendu et SEO technique moderne
Dès qu'une partie du contenu ou des liens dépend du JavaScript, l'audit doit vérifier ce que voit
Google après rendu, pas seulement le HTML initial. Les problèmes fréquents : contenu injecté trop tard,
liens créés sans vraie balise <a href>, erreurs console qui cassent un module,
hydration incohérente entre mobile et desktop. Un crawler classique ne suffit pas toujours : il faut
parfois l'inspection d'URL, des captures après rendu, ou des tests sur des URLs échantillons.
Sur un lancement de site, je préfère verrouiller tôt le modèle de rendu (SSR, SSG, hydratation) et les gabarits critiques, plutôt que de découvrir à la mise en prod que les pages clés sont vides pour le bot.
Comment prioriser les correctifs
C'est souvent là que l'audit devient vraiment utile. Tous les problèmes techniques ne se valent pas. Je les classe selon trois questions : est-ce que cela touche une page importante, est-ce que cela bloque Google ou l'utilisateur, et est-ce que le correctif ouvre un palier visible une fois déployé ?
Ma règle simple
- corriger d'abord ce qui touche les pages business ou les URLs déjà prometteuses ;
- ensuite ce qui bloque l'indexation, le crawl ou sature inutilement les bots ;
- ensuite ce qui améliore l'expérience réelle sur des modèles de pages à fort trafic ;
- ensuite les enrichissements données structurées quand le fond est sain et éligible ;
- laisser de côté les détails sans impact tant que le reste n'est pas traité.
Cette logique est proche de celle que je décris dans ma méthode et dans l'article 0 à 100k : moins de tâches, mieux choisies, reliées au business.
À quoi ressemble un bon livrable d'audit technique
Un livrable utile commence par un résumé exécutif : ce qui bloque, pourquoi c'est important, et quelles trois à cinq actions sortent en premier. Ensuite viennent les preuves (captures, URLs exemples, extraits Search Console), puis les recommandations priorisées avec effort relatif et dépendances (SEO, dev, contenu). J'évite les tableaux de trois cents lignes sans colonne « impact ».
Chaque recommandation devrait répondre à « quelle URL ou quel gabarit est concerné », « comment le vérifier », et « comment valider après correction ». Pour les chantiers longs, un accompagnement SEO aide à faire tenir la priorisation dans le temps, surtout quand plusieurs équipes touchent au site.
Quels outils utiliser pour un audit SEO technique ?
Aucun outil ne remplace le jugement. En revanche, certains outils aident beaucoup à voir plus vite les problèmes. J'en parle aussi dans le guide outils SEO gratuits.
- Google Search Console pour l'indexation, la couverture, les CWV terrain, les sitemaps ;
- Screaming Frog (ou équivalent) pour crawler, voir statuts HTTP, balises, doublons évidents ;
- PageSpeed Insights / Lighthouse pour les pistes de performance (lab + parfois terrain) ;
- un navigateur pour regarder le site comme un utilisateur, mobile inclus ;
- votre CMS et vos logs serveur quand ils sont disponibles, pour relier causes et effets.
Je garde une règle utile : si un outil signale deux cents problèmes mais qu'aucun n'aide à prendre une décision, ce n'est pas encore un audit. C'est une exportation. La valeur est dans la traduction en priorités et en propriétaires (qui fait quoi).
Les erreurs fréquentes dans un audit SEO technique
- traiter chaque alerte d'outil comme une urgence absolue ;
- oublier les pages à enjeu business et corriger des URLs sans trafic ni enjeu ;
- séparer complètement technique, contenu, intention et architecture ;
- se focaliser sur les scores Lighthouse sans regarder l'indexation réelle ;
- utiliser robots.txt comme substitut à noindex ou à une vraie stratégie d'URL ;
- laisser le sitemap lister des pages non indexables, dupliquées ou sans intérêt ;
- ignorer le rendu JavaScript sur les parties critiques du site ;
- lancer une refonte sans plan SEO de bascule et de mesure.
Le SEO technique n'est pas un univers séparé. Il sert les pages, la structure, la conversion et la croissance du site. C'est pour cela que je le relie souvent à un audit SEO plus large ou à une intervention de SEO technique quand le plafond de verre est déjà clair. Quand le problème est surtout éditorial, la stratégie de contenu reprend le relais.
FAQ
Est-ce qu'un audit SEO technique suffit à lui seul ?
Non. Il peut lever des freins majeurs, mais il ne remplace ni le bon ciblage, ni des pages solides, ni une stratégie éditoriale cohérente. Après la technique, on regarde souvent le choix des mots-clés et la qualité des contenus.
Faut-il lancer un audit technique avant de produire du contenu ?
Pas toujours. Mais si le site a un vrai problème d'indexation, de structure ou de gabarits, produire plus sans le traiter peut juste ajouter du bruit et des URLs à gérer.
Le sitemap XML suffit-il à régler l'indexation ?
Non. Le sitemap aide à la découverte et à la priorisation, mais il ne remplace ni les liens internes, ni la qualité des pages, ni des règles propres sur les doublons. Voir le guide sitemap XML.
Faut-il auditer mobile et desktop séparément ?
Oui, au moins sur un échantillon. Google indexe en priorité avec l'exploration smartphone : des écarts de contenu, de balises ou de performance mobile peuvent cacher des problèmes invisibles sur desktop.
Les logs serveur sont-ils indispensables ?
Pas sur tous les sites, mais très utiles sur les gros catalogues ou quand Search Console et le crawl ne suffisent pas à expliquer un comportement étrange du bot. Ils montrent ce que Googlebot visite vraiment, à quelle fréquence, et quels codes il reçoit.
La suite logique après un audit technique
Une fois les freins identifiés, il faut soit lancer les correctifs techniques, soit revenir à la structure globale du site pour voir ce qui doit suivre : maillage, hubs, pages money, ou chantier migration. Pour le copy et les extraits une fois les gabarits stables, le guide améliorer le CTR peut compléter le travail sur les pages déjà bien servies techniquement.
Pour aller plus loin sur ce site : la méthode SEO, l'article refonte SEO, ma méthode pour passer de 0 à 100k, les services SEO, et les autres ressources. Un premier échange permet aussi de cadrer un audit sur votre contexte réel.