Un client m'envoie un jour un rapport d'audit de 87 pages. Score global : 61/100. Trois mois plus tard, son trafic n'avait pas bougé d'un iota. Pourquoi ? Parce que sur les 412 « erreurs » listées, 340 concernaient des balises méta sur des pages qui n'existaient plus depuis deux ans. Voilà le problème avec la plupart des audits SEO qu'on voit circuler : ils listent, ils ne hiérarchisent pas.
Un audit SEO technique complet d'un site web ne vaut que par l'ordre dans lequel il vous fait agir. Pas par le nombre de lignes de son tableur. C'est cette conviction qui guide tout ce qui suit, et je vais vous montrer comment je procède concrètement, chiffres à l'appui, y compris sur les points où je me suis planté.
Points clés à retenir
- Un audit technique se juge à sa capacité à produire un plan d'action séquencé, pas à son exhaustivité.
- Le crawl et l'indexation passent avant la performance : inutile d'optimiser une page que Google n'explore jamais.
- La matrice impact × effort évite de passer trois semaines sur des correctifs à 0,2 % de gain.
- Les audits gratuits en ligne donnent une photo utile mais partielle : ils ne voient pas l'architecture ni le rendu JavaScript.
- Un site que je suivais plafonnait à cause d'un simple paramètre de canonique mal configuré — invisible sur tous les scanners automatiques.
Un audit SEO technique, à quoi ça sert vraiment ?
La question qu'on me pose le plus souvent, ce n'est pas « quels outils utiliser » mais « pourquoi mon site ne décolle pas alors que je publie régulièrement ». Et dans sept cas sur dix que j'ai traités, la réponse n'était pas éditoriale. Elle était technique.
Un audit technique répond à trois interrogations, dans cet ordre :
- Est-ce que Google peut explorer mon site ? (crawl, robots.txt, sitemap, budget d'exploration)
- Est-ce qu'il peut l'indexer correctement ? (canoniques, balises noindex, doublons, rendu JS)
- Est-ce qu'il valorise ce qu'il indexe ? (performance, structure interne, données structurées)
Si la première réponse est non, les deux autres n'ont aucune importance. C'est bête à dire, mais je vois régulièrement des prestataires envoyer des recommandations de Core Web Vitals à des sites dont la moitié des pages est bloquée par un Disallow oublié dans le robots.txt. On ne repeint pas les murs d'une maison dont la porte est murée.
Pourquoi parle-t-on d'un audit « complet » et pas seulement technique ?
Parce qu'un audit purement technique passe à côté de la moitié du problème. Un site peut être une horloge côté crawl et se planter parce que quinze pages se disputent le même mot-clé. La cannibalisation, c'est du contenu, mais ça se diagnostique avec des données techniques (croisement Search Console × crawl).
Mon découpage habituel ressemble à ça :
| Volet | Ce qu'on vérifie | Temps typique |
|---|---|---|
| Technique | Crawl, indexation, performance, statuts HTTP, mobile | 40 % de l'audit |
| Sémantique | Cannibalisation, intentions de recherche, maillage interne | 25 % |
| Contenu | Couverture thématique, fraîcheur, qualité rédactionnelle | 20 % |
| Popularité | Profil de liens, ancres, toxicité éventuelle | 15 % |
Ce tableau, je l'impose à chaque mission. Pas parce que les proportions sont magiques, mais parce qu'il force à ne pas passer trois semaines sur le robots.txt en oubliant de regarder ce que le site raconte.
Comment réaliser un audit SEO technique dans le bon ordre
Voilà où la majorité des guides vous perdent. Ils vous donnent une liste de 40 points à vérifier. Aucun ne vous dit par quoi commencer. Je vais être direct : l'ordre compte plus que la liste.
Étape 1 : le crawl, avant tout le reste
Je lance toujours un crawl complet avant d'ouvrir le moindre outil d'analyse de performance. Sur un site de 5 000 URLs, ça prend une à deux heures avec un crawler de bureau. Objectif : voir exactement ce que Googlebot voit.
Ce que je cherche dans les résultats bruts :
- Les codes de réponse anormaux (404 en masse, 500 récurrents)
- Les redirections en chaîne (plus de 2 sauts = problème)
- Les pages orphelines (présentes dans le sitemap mais liées nulle part)
- Les paramètres d'URL générant des doublons infinis
Sur un e-commerce que j'ai audité, le crawl a remonté 18 000 URLs pour un catalogue de 2 100 produits. La cause : des filtres de tri combinables sans balise canonique. Google dépensait l'essentiel de son budget d'exploration sur des pages vides. Une fois les paramètres exclus du crawl, l'indexation des vraies fiches produit est passée de 62 % à 94 % en six semaines.
Étape 2 : l'indexation et les canoniques
Une fois le crawl propre, je compare le nombre d'URLs crawlées au nombre d'URLs réellement indexées (via Search Console, rapport « Pages »). L'écart raconte une histoire.
Franchement, c'est l'étape où je me suis le plus planté au début. Je me contentais de cocher « pas de noindex accidentel » et je passais à la suite. Jusqu'au jour où un site client plafonnait à la position 14 sur son mot-clé principal. Aucun outil ne signalait d'erreur. En creusant, j'ai trouvé une balise canonique pointant vers une URL en HTTP au lieu de HTTPS, sur 200 pages environ. Google voyait deux versions de chaque page et ne savait pas laquelle mettre en avant. Correctif appliqué : +38 % de clics organiques en deux mois. Aucun scanner ne l'avait vu, parce qu'il faut comparer le contenu de la balise aux URLs réellement servies.
Étape 3 : performance et rendu mobile
Ici, un avertissement. Les scores de performance affichés par les outils grand public sont des indicateurs, pas des objectifs. Un site que j'ai suivi affichait 54/100 sur mobile et se classait très bien sur ses requêtes cibles. Pourquoi ? Parce que le contenu utile s'affichait en moins de deux secondes, et que le reste concernait des scripts tiers non bloquants.
Ce qu'il faut regarder, concrètement :
- Le LCP (Largest Contentful Paint) : viser sous 2,5 secondes sur mobile
- Le CLS (décalage de mise en page) : sous 0,1, sinon l'expérience est pénible
- Le poids des images non compressées — c'est la cause n°1 que je rencontre, loin devant le JavaScript
- Le rendu réel en mobile, pas seulement le score
Et surtout : vérifier que le contenu principal est bien rendu côté serveur ou pré-rendu. Un site entièrement en JavaScript côté client, sans SSR, c'est une bombe à retardement pour l'indexation. J'en ai vu un dont la moitié du contenu n'apparaissait tout simplement pas dans le HTML initial.
Comment prioriser les correctifs quand tout semble cassé
Un audit qui remonte 300 problèmes ne sert à rien s'il ne dit pas lesquels traiter cette semaine. C'est là que la plupart des rapports échouent. Ils classent par « sévérité » technique, pas par impact business.
Ma méthode tient en une matrice simple :
| Impact estimé | Effort faible | Effort élevé |
|---|---|---|
| Fort | À faire immédiatement | À planifier au trimestre |
| Moyen | Rapide, à glisser dans le sprint | À évaluer sérieusement |
| Faible | Si le temps le permet | À ignorer |
Sur un audit que j'ai livré récemment, la moitié des recommandations tombaient dans la case « faible impact / effort élevé ». Elles concernaient des optimisations de balisage sur des pages à très faible trafic. Je les ai volontairement laissées de côté. Le client m'a demandé pourquoi elles figuraient quand même dans le rapport : parce qu'elles sont documentées, mais explicitement rangées en bas de pile. Un audit honnête dit aussi ce qu'il ne faut pas faire.
Le critère d'impact que j'utilise : cette correction peut-elle toucher une page qui génère déjà du trafic ou des conversions ? Si la réponse est non, elle attend.
Un audit SEO gratuit suffit-il ?
Pour un premier diagnostic, oui, partiellement. Les outils d'audit gratuits en ligne vous donnent une photo utile : erreurs d'indexation de base, performance, quelques alertes de balisage. Sur un petit site vitrine de dix pages, ça peut même suffire à identifier les deux ou trois chantiers prioritaires.
Le problème, c'est ce qu'ils ne voient pas. Un scanner gratuit ne crawle généralement qu'une poignée d'URLs, ignore le rendu JavaScript, ne détecte pas les canoniques incohérentes et ne croise jamais les données avec Search Console. Autrement dit : il vous dit qu'il y a un mur, mais pas où est la porte.
Mon conseil : utilisez un audit gratuit pour la mise en jambe, puis complétez avec un crawl manuel et les données de Search Console. C'est le seul moyen de comprendre pourquoi une page n'est pas indexée, pas seulement qu'elle ne l'est pas.
Quelle différence entre un audit automatisé et un audit « exemple PDF » ?
Un rapport d'audit automatisé est une sortie brute : des lignes, des scores, des alertes. Un rapport d'audit rédigé, celui qu'on trouve parfois sous forme de PDF dans les résultats de recherche, ajoute ce qui manque à l'automatisation : le raisonnement, la priorisation, la mise en contexte.
La différence est celle entre une prise de sang et une consultation. La prise de sang vous donne des chiffres ; le médecin vous dit ce qu'ils signifient pour votre cas précis. Et c'est exactement ce que je reproche aux rapports que je reçois parfois d'autres prestataires : une avalanche de données, zéro décision.
Un bon rapport contient, à mon sens :
- Un résumé exécutif de deux pages maximum
- Un plan d'action ordonné par impact, avec des délais
- Les preuves chiffrées avant/après pour chaque chantier
- Et une section honnête sur les limites de l'audit
Les erreurs que je vois tout le temps (et que j'ai commises)
Il y a une chose que j'ai apprise à la dure : optimiser pour le score, pas pour l'utilisateur. Je me suis acharné, sur un projet, à faire passer un site de 68 à 92 sur mobile. Résultat : aucune amélioration de positionnement mesurable. J'avais passé cinq semaines sur un indicateur qui ne reflétait pas la vraie expérience de chargement.
Les erreurs les plus fréquentes que je croise :
Confondre crawl et indexation. Un crawl propre ne garantit rien. Il faut vérifier ce que Google a réellement gardé. Ignorer le budget d'exploration. Sur les gros sites, chaque URL inutile crawlée est une URL utile non explorée. Traiter les balises méta comme des priorités. Une description mal rédigée n'a jamais empêché un site de se classer. Une canonique cassée, si.
Et puis il y a la communication. Un audit technique complet, c'est aussi un document que votre développeur doit comprendre sans être expert SEO. Si votre rapport technique n'est pas lisible par celui qui va coder les correctifs, il finira dans un tiroir. Le mien commence toujours par deux pages en français simple, avant les tableaux.
Ce qu'il faut retenir sur l'audit SEO technique complet
Un audit ne se mesure pas au nombre de problèmes qu'il trouve, mais à la clarté du chemin qu'il trace. Crawl d'abord, indexation ensuite, performance enfin, et priorisation par impact business à chaque étape. Voilà la colonne vertébrale.
Si je devais résumer en une phrase : un bon audit vous dit quoi faire cette semaine, quoi planifier ce trimestre, et ce qu'il faut laisser tomber. Le reste, c'est de la décoration.
Et une dernière chose, peut-être la plus utile. Après chaque audit, je pose une question au client : « Quelle est LA page dont vous êtes le plus fier ? » Neuf fois sur dix, c'est une page que l'audit technique a trouvée mal indexée ou mal reliée. L'audit révèle rarement un désastre ; il révèle surtout que les meilleurs contenus d'un site sont souvent les plus mal servis par sa technique. C'est là qu'il faut commencer.
