Un client m'appelle l'autre jour, un peu paniqué : "Mon site a perdu 40 % de trafic en deux semaines, Google m'a envoyé un mail avec des tas de codes d'erreur, tu peux regarder ?" Je jette un œil à la Search Console. 12 000 pages indexées pour un site qui en compte 800. Voilà le problème. Pas un problème de contenu, pas un problème de netlinking — un problème d'indexation qui remonte à une ancienne refonte dont personne n'avait nettoyé les dégâts.
Un audit SEO technique, c'est exactement ça : arrêter de deviner et aller voir sous le capot. Pas pour produire un PDF de 80 slides que personne ne lira, mais pour identifier les 5 à 10 chantiers qui débloquent réellement la machine. La méthodologie que je vais vous décrire, je l'ai rodée sur une bonne trentaine de sites — des PME, deux e-commerces, un média régional — et elle a pas mal changé depuis mes débuts, où je me contentais de lancer un crawl et de livrer la liste brute des erreurs.
Points clés à retenir
- Un audit technique se mène dans un ordre précis : accès aux données, crawl, croisement avec les logs, priorisation. Sauter une étape fausse le diagnostic.
- Les seuils qui comptent : LCP sous 2,5 s, INP sous 200 ms, CLS sous 0,1. En dehors, Google le voit.
- Un crawl seul ne suffit jamais : sans les logs serveur, vous auditez ce que Google pourrait voir, pas ce qu'il voit.
- La priorisation impact/effort vaut plus que la liste exhaustive. Un audit qui liste 400 erreurs sans hiérarchie est inutilisable.
- Le vrai livrable, c'est un tableau de tickets actionnables par vos développeurs, pas un rapport de consulting.
Un audit SEO technique, c'est une méthode, pas un outil
La tentation est forte de croire qu'un bon outil fait le travail. Spoiler : non. Screaming Frog, Sitebulb, Semrush ou Ubersuggest vous crachent des milliers de lignes. Encore faut-il savoir lesquelles regarder, dans quel ordre, et ce qu'elles racontent vraiment sur votre site.
Ce que j'appelle un audit SEO technique, c'est un enchaînement de six étapes où chaque étape nourrit la suivante. Vous ne pouvez pas analyser un problème d'indexation sans avoir d'abord crawlé le site. Vous ne pouvez pas prioriser un chantier de performance sans avoir mesuré les Core Web Vitals réels, pas ceux de votre machine de bureau.
Technique, contenu, popularité : où placer la frontière
Un audit SEO complet couvre trois familles : la technique, le contenu (sémantique, qualité, intention de recherche) et la popularité (backlinks, autorité). L'audit technique se concentre sur ce qui empêche Google de crawler, d'indexer ou de bien afficher vos pages. Si une page n'est pas indexée, aucun travail éditorial ne la sauvera. C'est pour ça que je commence toujours par là, même quand le client me demande d'abord une "stratégie de contenu".
J'ai fait l'erreur inverse une fois, sur un site de e-commerce. Trois semaines à retravailler les fiches produits, à réécrire les balises title, à ajouter des FAQ. Résultat : zéro. Le site avait un souci de rendu JavaScript qui empêchait Google de voir le contenu. Quand on a corrigé ça, le trafic a pris 60 % en un mois. Le contenu était bon depuis le début. Il était juste invisible.
Étape 1 : préparer les accès avant de toucher à un outil
Avant le moindre crawl, il vous faut trois choses. Sans elles, vous perdez une semaine à courir après les identifiants.
- Un accès en lecture à la Search Console, avec au moins trois mois d'historique. Le rapport "Couverture" et le rapport "Pages" vous donnent la liste des pages exclues de l'index. C'est de l'or.
- Un accès aux logs serveur (Apache, Nginx, ou un CDN type Cloudflare). Sans logs, vous ne saurez jamais si Googlebot passe réellement sur vos pages ou s'il s'arrête à la page d'accueil.
- Un accès en lecture au code source ou, à défaut, la possibilité de poser des questions à l'équipe technique. Un audit qui pointe un problème sans savoir comment le corriger est un audit mort-né.
Si le client n'a pas la Search Console configurée, c'est déjà un signal. Ça veut souvent dire que personne ne surveille le site. Je vérifie aussi s'il existe une propriété GA4 correctement branchée — utile pour croiser les données de comportement avec les problèmes techniques.
Quel outil pour quel usage ?
La question revient à chaque mission. Voici comment je m'organise aujourd'hui :
| Outil | Cas d'usage | Limite |
|---|---|---|
| Screaming Frog | Crawl complet, analyse des balises, codes HTTP, maillage interne | Version gratuite plafonnée à 500 URL |
| Search Console | Couverture d'indexation, requêtes réelles, Core Web Vitals terrain | Pas d'exploration de pages non soumises |
| Sitebulb | Crawl avec rapport hiérarchisé, très bon pour les gros sites | Payant, courbe d'apprentissage |
| Semrush / Ahrefs | Suivi des positions, backlinks, comparaison concurrents | Peu utile en phase purement technique |
| Ubersuggest | Premier survol, découverte de mots-clés | Trop léger pour un audit sérieux |
Ce tableau n'est pas une vérité gravée dans le marbre. Chacun a ses habitudes. L'essentiel est de ne pas confondre outils d'analyse et outils de suivi.
Étape 2 : crawler, puis analyser l'indexation
Le crawl produit des milliers de lignes. Ce que vous cherchez dedans, concrètement :
- Les codes de réponse anormaux — 404, 410, 500, 503. Une 500 récurrente sur un répertoire entier peut plomber le budget de crawl.
- Les redirections en chaîne. Deux sauts maximum, au-delà c'est déperditif.
- Les balises canonical incohérentes (canonical qui pointe vers une page en 404, ou vers une page différente de la version mobile).
- Les pages orphelines — présentes dans le sitemap mais absentes du maillage interne.
- Le noindex posé par accident. J'en ai trouvé sur une homepage entière une fois. Le stagiaire avait copié un template de staging. C'est arrivé un vendredi.
Une fois le crawl passé, direction la Search Console, rapport "Pages". Comparez le nombre de pages indexées avec le nombre de pages du sitemap. Un écart de 5 % est normal. Un écart de 40 % est un signal fort.
Quel taux d'indexation viser ?
Il n'y a pas de chiffre magique, mais un repère utile : sur un site sain, la majorité des pages utiles doit être indexée. Si votre sitemap contient 500 URL et que la Search Console en signale 200 indexées, sans exclusion volontaire de votre part, il y a un problème à creuser. Attention : ce ratio dépend du type de site. Un e-commerce avec des filtres à facettes peut légitimement exclure beaucoup de pages. Un site vitrine de 40 pages, non.
Étape 3 : l'analyse des logs, l'étape que tout le monde saute
Voilà le point où je vois la plus grosse différence entre un audit bâclé et un audit utile. Le crawl vous dit ce que Google peut voir. Les logs vous disent ce que Googlebot a vu réellement, et à quelle fréquence.
Ce que je cherche dans un fichier de logs :
- La fréquence de passage de Googlebot sur les pages stratégiques. Si votre page produit phare n'est visitée qu'une fois par mois tandis qu'une archive de tags l'est tous les jours, votre budget de crawl est mal réparti.
- Les pages jamais visitées. Il y en a toujours.
- Les URL visitées qui n'existent pas (404) — souvent des liens externes obsolètes ou des anciennes URL jamais redirigées.
- La part de trafic Googlebot par rapport au trafic total. Un ratio anormalement élevé sur une portion du site indique une boucle ou un piège à crawl.
L'analyse des logs demande un peu d'huile de coude : il faut parser le fichier et filtrer les requêtes par user-agent. Un script Python de 40 lignes suffit. Mais franchement, c'est cette étape qui m'a permis de résoudre les cas les plus retors.
Exemple concret : sur un site média que j'ai audité, le crawl ne signalait rien d'alarmant. Les logs, eux, montraient que Googlebot passait 80 % de son temps sur des pages de pagination infinie. Résultat : les articles récents n'étaient indexés qu'au bout de trois semaines. On a ajouté un noindex sur la pagination au-delà de la page 5. Délai d'indexation ramené à 48 heures.
Étape 4 : performance et maillage, dans cet ordre
Les Core Web Vitals sont un signal de classement — un parmi d'autres, pas le seul. Les seuils à viser :
LCP (Largest Contentful Paint) sous 2,5 secondes, INP (Interaction to Next Paint) sous 200 millisecondes, CLS (Cumulative Layout Shift) sous 0,1. Ces valeurs sont mesurées sur le terrain (données utilisateurs réelles), pas en laboratoire. La Search Console vous les donne dans le rapport "Signaux web essentiels".
Ce que je fais systématiquement : je croise les données terrain avec un test PageSpeed Insights sur les 10 pages les plus stratégiques. Si l'écart entre les deux est énorme, c'est souvent que les utilisateurs réels sont sur mobile avec une connexion médiocre — et là, il faut optimiser en priorité les images et le JavaScript bloquant.
Le maillage interne : le levier le plus sous-estimé
Une fois l'indexation éclaircie et la performance stabilisée, je regarde le maillage interne. Deux règles :
Aucune page stratégique ne doit être à plus de trois clics de la page d'accueil. Et chaque page importante doit recevoir au moins quelques liens internes contextuels, pas seulement depuis le menu. J'ai vu des sites où toutes les fiches produits étaient à cinq clics de profondeur. Google les indexait, mais lentement, et sans leur donner de poids.
Un truc simple à tester : prenez votre page la plus importante commercialement. Combien de liens internes pointent vers elle depuis des pages de contenu ? Si la réponse est zéro, vous avez un chantier.
Étape 5 : prioriser, puis livrer un document utilisable
La partie la plus difficile n'est pas de trouver les problèmes. C'est de décider lesquels corriger d'abord. J'utilise une matrice impact / effort :
- Fort impact, faible effort : à faire tout de suite. Exemple typique — corriger une balise canonical erronée sur 30 pages.
- Fort impact, fort effort : à planifier sur le trimestre. Exemple — migrer un site vers un rendu serveur pour les pages produit.
- Faible impact, faible effort : à glisser dans une passe de nettoyage.
- Faible impact, fort effort : à ignorer, ou à documenter pour plus tard. Ne perdez pas trois semaines à optimiser une balise meta sur une page que personne ne visite.
Le livrable final n'est pas un PDF. C'est un tableau avec, pour chaque ticket : la page concernée, le problème, la correction attendue, l'impact estimé, la personne responsable. J'ajoute une capture d'écran pour chaque cas non trivial — les développeurs me remercient, en général.
Combien de temps prend un audit SEO technique ?
Pour un site de moins de 500 pages avec les accès en main, comptez trois à cinq jours de travail effectif. Pour un site de plusieurs milliers de pages avec analyse de logs, deux à trois semaines. La phase de collecte des accès peut à elle seule ajouter une semaine si le client est mal organisé.
Faut-il refaire un audit tous les ans ?
Un audit technique complet, non — sauf refonte majeure ou chute de trafic. En revanche, un suivi mensuel des indicateurs clés (taux d'indexation, Core Web Vitals, erreurs de crawl) est indispensable. Un site ne reste jamais stable tout seul.
Ce qui reste quand on a tout corrigé
Un audit technique ne rend pas un site performant. Il enlève les obstacles. Une fois que Google voit vos pages, les indexe, les affiche rapidement, le travail éditorial et le netlinking reprennent leurs droits. C'est pour ça que je refuse les audits "one shot" sans suivi : vous corrigez les erreurs connues, et dans six mois une nouvelle refonte en crée dix autres.
La question que je pose toujours en fin de mission : "Qui, dans votre équipe, sera capable de relancer un crawl dans trois mois et de comprendre ce qu'il lit ?" Si la réponse est floue, tout ce travail s'évaporera. Un audit technique, en fin de compte, n'est pas un diagnostic. C'est un transfert de compétence — et ça, aucun outil ne le fera à votre place.
