Le mois dernier, un client m'appelle, paniqué. Son site marchait « nickel » en janvier, et là, en juillet 2026, il avait perdu 40 % de son trafic organique. Pas de pénalité apparente, pas de message dans la Search Console. Juste une chute. Je lance un crawl sur les 4 200 URLs du domaine. Huit minutes plus tard, le verdict tombe : 1 800 pages bloquées par un robots.txt modifié par erreur en mars. Un stagiaire pensait exclure un dossier de test. Il a exclu la moitié du catalogue.
Voilà pourquoi un audit technique SEO ne se joue pas sur les grandes théories. Il se joue sur des détails bêtes, répétables, et qu'on ne voit que si on cherche au bon endroit. Je vais vous montrer comment je procède, dans quel ordre, avec quoi, et — surtout — ce que je ne regarde plus.
Points clés à retenir
- Un audit technique commence par le crawl, jamais par les outils de performance front-end.
- Trois familles de problèmes font 80 % des dégâts : indexation, redirections, rendu JavaScript.
- Les Core Web Vitals comptent, mais un LCP à 4 secondes est un problème de business, pas d'ego technique.
- Un audit se refait. Un site vivant se dégrade tout seul, en 60 à 90 jours.
- Priorisez par impact sur le chiffre d'affaires, pas par difficulté de correction.
Audit SEO technique : par où commencer sans y passer trois semaines
La première erreur, que j'ai commise pendant deux ans, c'est de lancer Lighthouse fébrile sur la page d'accueil et de croire qu'on a « audité » quelque chose. Non. La page d'accueil, tout le monde la soigne. Elle se comporte bien. Le problème est toujours ailleurs : dans la pagination de la catégorie 47, dans les facettes filtrées, dans les 900 fiches produit générées automatiquement.
L'ordre que j'utilise (et pourquoi il change tout)
Je crawle d'abord. Toujours. Avant d'ouvrir le moindre outil de mesure de performance.
- Crawl complet du domaine, avec un outil qui exécute le JavaScript (hélas, la moitié des crawlers gratuits ne le font pas — et vous ratez alors tout ce que votre framework rend côté client).
- Comparaison crawl vs. index réel via la Search Console : quelles URLs Google connaît, lesquelles il ignore, lesquelles il a découvertes mais pas indexées.
- Cartographie des redirections — chaînes, boucles, redirections vers du 404.
- Analyse des balises canoniques et des directives noindex, une par une sur les gabarits critiques.
- Performance sur les 20 URLs les plus rentables, pas les plus visitées.
Cette nuance — les plus rentables, pas les plus visitées — m'a fait gagner un temps fou. Une page à 50 visites par mois qui convertit à 8 % vaut plus qu'une page à 15 000 visites qui convertit à 0,1 %.
Les cinq contrôles qui révèlent le plus de dégâts
Sur les douze derniers audits que j'ai menés — PME, e-commerce, sites médias — neuf avaient un problème d'indexation accidentelle. Neuf sur douze. Ce n'est pas une statistique, c'est mon carnet de notes. Mais la régularité m'a marqué.
- Un noindex laissé en staging et déployé en prod (le classique absolu)
- Une balise canonique auto-générée qui pointe vers la page d'accueil, quel que soit l'URL
- Un sitemap.xml qui liste des URL en 301 ou en 404 depuis la refonte de l'année précédente
- Une pagination sans
rel="next"correctement gérée — et oui, ça compte encore - Des paramètres d'URL (filtres, tris, sessions) indexés en masse, qui créent du contenu dupliqué à la pelle
Indexation, crawl, redirections : la base qu'on saute toujours
Le robots.txt est un fichier de 15 lignes. Il peut tuer un site entier. Je le lis intégralement à chaque audit, ligne par ligne. Je vérifie aussi qu'aucune règle n'entre en conflit avec la Search Console, qui a sa propre logique de priorité (la règle la plus restrictive gagne, mais pas toujours de la manière qu'on imagine).
Les chaînes de redirections, ce poison lent
Une redirection en 301, c'est propre. Trois redirections en cascade, c'est du gaspillage : le crawler consomme son budget de crawl, la latence s'accumule, et la transmission de signal s'affaiblit à chaque saut. J'ai vu des sites avec des chaînes de 5 sauts sur 600 URLs. Corrigé en une après-midi chez un client : +12 % de pages indexées en trois semaines. Rien d'autre n'avait bougé.
Ce que je regarde, concrètement :
| Contrôle | Outil type | Fréquence | Impact typique |
|---|---|---|---|
| Crawl complet + JS | Crawler avec moteur de rendu | Mensuelle | Élevé |
| Chaînes de 301 | Export de crawl + script maison | Trimestrielle | Moyen à élevé |
| Core Web Vitals | Données terrain | Mensuelle | Moyen |
| Données structurées | Validateur | À chaque mise en prod | Variable |
| Sitemap à jour | Génération automatique | Hebdomadaire | Faible mais cumulatif |
Core Web Vitals : ce qui a vraiment changé côté mesure
On m'envoie souvent des rapports Lighthouse tout verts en me disant « la perf est bonne ». Sauf que Lighthouse simule. Google, lui, mesure du terrain — de vraies visites, sur de vrais appareils, souvent des téléphones d'entrée de gamme sur du réseau 4G dégradé. Les deux courbes ne se ressemblent presque jamais.
L'indicateur INP a remplacé le FID depuis un moment, et c'est celui qui pose le plus de problèmes aux sites riches en JavaScript. Une interaction qui met plus de 200 ms à répondre, sur mobile, c'est une interaction ratée. Et un formulaire de contact qui « rame » à l'ouverture d'un menu, ce n'est pas un problème de SEO. C'est un problème de vente.
Mon LCP est lent : je fais quoi en premier ?
La cause la plus fréquente n'est presque jamais l'image elle-même. C'est l'ordre de chargement. Une police web qui bloque le rendu, un script tiers injecté en haut de page, une bannière de cookies qui pousse le contenu réellement visible vers le bas. J'ai corrigé un LCP passé de 4,8 s à 1,9 s rien qu'en retirant un script analytics mal placé et en préchargeant la police principale. Aucune image touchée.
Trois vérifications avant d'optimiser quoi que ce soit :
- La ressource qui déclenche le LCP est-elle préchargée ?
- Y a-t-il un script tiers bloquant dans le
<head>? - Le CLS vient-il d'un élément inséré dynamiquement (pub, cookie, bandeau promo) sans dimensions réservées ?
Votre site est en JavaScript : le piège du rendu côté client
Documentation officielle, évidemment. Mais je vais vous dire ce qu'elle ne dit pas clairement : Googlebot rend le JavaScript, mais avec du retard et parfois incomplètement. Sur un site Next.js en SSR, ça va. Sur un site full-CSR sans pré-rendu, vous jouez à la loterie sur les pages à forte densité de données.
Le test que je fais systématiquement : je désactive le JavaScript dans mon navigateur et je regarde ce qui reste. Si je vois une page blanche là où Google devrait voir du contenu, j'ai ma réponse. Chez un client l'an dernier, 30 % des fiches produit étaient invisibles au premier crawl pour cette raison exacte. Le trafic est revenu en six semaines après passage en rendu serveur sur ces gabarits.
Quels outils utiliser — et lequel je ne lâche plus
Le marché des outils SEO est un bazar. J'en ai testé une quinzaine. Trois ou quatre suffisent, à condition de savoir ce qu'on leur demande.
Ma pile d'outils, honnêtement
Un crawler qui exécute le JS pour la découverte. La Search Console pour la réalité de l'index (c'est gratuit et aucun outil tiers ne la remplace). Un outil de suivi des Core Web Vitals sur données terrain. Un script maison de 40 lignes pour détecter les chaînes de redirections, parce qu'aucun outil gratuit ne le fait proprement. Et un tableur. Oui, un tableur.
Pour ce qui est des outils « tout-en-un » qui promettent un audit complet en un clic : méfiance. Ils remontent 300 alertes dont 280 sont du bruit. Le vrai travail est de trier ce bruit — et ça, aucun outil ne le fera à votre place. J'ai perdu trois mois, une fois, à corriger tout ce qu'un rapport automatique listait. Résultat : aucune amélioration mesurable. Zéro. J'avais corrigé 200 broutilles et loupé le seul noindex qui bloquait 400 URLs.
Trois erreurs que je vois dans presque tous les audits
Erreur n°1 : auditer sans baseline. Si vous ne notez pas les chiffres avant de toucher à quoi que ce soit, vous ne saurez jamais si vous avez amélioré quelque chose. Position moyenne, pages indexées, taux de conversion par gabarit. Trois lignes dans un tableur, relevées le jour J.
Erreur n°2 : corriger tout en même temps. J'ai fait ça. On corrige 30 choses d'un coup, le trafic bouge, et impossible de savoir laquelle a servi. Un changement par semaine, mesuré à 30 jours. Ça paraît lent. C'est en réalité plus rapide, parce que vous saurez quoi refaire.
Et la troisième, la plus vicieuse : croire qu'un audit est un événement. Ce n'est pas un événement. Un site qui publie, qui change son template, qui installe une extension, se dégrade en continu. Un crawl mensuel et un rapport trimestriel, c'est le minimum vital. Pas un luxe de grande entreprise.
Ce que je fais en premier sur un site que je ne connais pas
Je me pose une question bête : « si je devais casser ce site en une ligne, je ferais quoi ? » Puis je vérifie si c'est déjà le cas. Dans 7 audits sur 10, la réponse est oui. Souvent quelque chose de trivial — une règle dans le robots.txt, un paramètre d'URL indexé, un noindex oublié.
L'audit technique SEO n'est pas un examen de perfection. C'est une chasse aux fuites. Les grosses fuites sont peu nombreuses, rarement spectaculaires, et presque toujours liées à un déploiement récent que personne n'a relu.
La prochaine fois que votre trafic baisse sans explication, ne commencez pas par le contenu. Ouvrez le robots.txt. Vérifiez la date de dernière modification. On se parle dans dix minutes.
