Le mois dernier, un client m'envoie un message paniqué : « Mon trafic a chuté de 40 % en trois semaines, je ne comprends pas. » Je demande l'accès à sa Search Console. Cinq minutes plus tard, j'ai ma réponse. Une balise noindex posée par erreur sur le gabarit des articles de blog. Le développeur avait déployé une mise à jour, personne n'avait vérifié, et Google avait proprement retiré 200 pages de son index.
Un audit SEO technique, c'est exactement ça : trouver la panne invisible avant qu'elle ne coûte votre chiffre d'affaires. Pas un rapport de 80 pages que personne ne lit. Pas une liste de « bonnes pratiques » copiée-collée. Un diagnostic qui répond à une seule question : qu'est-ce qui empêche réellement votre site d'être bien positionné, et dans quel ordre régler le problème ?
Je fais ce travail depuis assez longtemps pour avoir un avis tranché sur la question. Et la plupart des articles sur le sujet passent à côté de l'essentiel.
Points clés à retenir
- Un audit SEO technique ne commence jamais par les outils, mais par les logs serveur et la Search Console.
- L'ordre d'analyse compte plus que l'exhaustivité : indexation d'abord, performance ensuite.
- Trois familles de problèmes bloquent la quasi-totalité des sites que j'audite : indexation, duplication, vitesse.
- Un audit sans priorisation par impact/effort est un document mort.
- Le crawl automatique rate systématiquement les pages orphelines — les logs les révèlent.
- Corriger 5 problèmes critiques vaut mieux que corriger 200 problèmes mineurs.
Audit SEO technique : ce que c'est vraiment (et ce que ce n'est pas)
Un audit SEO technique, c'est l'analyse de la capacité d'un site à être exploré, compris et indexé par les moteurs de recherche. Rien de plus, rien de moins. Le contenu, le netlinking, la stratégie éditoriale : tout ça vient après. Si Googlebot ne peut pas accéder à vos pages, ou s'il les juge trop lentes, aucun travail rédactionnel ne sauvera la mise.
Ce n'est pas non plus un audit de mots-clés déguisé. J'ai vu passer des « audits » à 1 500 € qui n'étaient qu'une liste de requêtes cibles avec un vague commentaire sur les balises title. Ça n'a rien à voir.
Audit technique, audit sémantique, audit de popularité : la vraie frontière
Les trois se confondent souvent. Pourtant leur périmètre est net.
- Technique : crawl, indexation, canonicalisation, vitesse, mobile, structure d'URL, données structurées, gestion du rendu JavaScript.
- Sémantique : couverture des intentions de recherche, qualité des balises, maillage interne, cannibalisation de mots-clés.
- Popularité : profil de backlinks, ancres, qualité des domaines référents, désaveux éventuels.
Quand un client me demande « combien ça coûte », ma réponse dépend toujours de la même variable : la taille du site et le niveau de désordre accumulé. Sur un site de 50 pages bien tenu, deux jours suffisent. Sur un e-commerce de 15 000 références avec un historique de migrations ratées, comptez une semaine pleine.
Comment faire un audit SEO technique : la méthode pas-à-pas que j'utilise
Je vais vous donner le workflow exact. Pas une liste de 14 étapes théoriques dont on ne sait jamais laquelle appliquer en premier.
Étape 1 : la Search Console avant tout outil payant
C'est l'étape que 80 % des débutants sautent. Erreur monumentale. La Search Console vous donne ce qu'aucun crawler ne peut produire : ce que Google a réellement vu, indexé et servi. Le rapport « Pages » vous montre les URL exclues, et la raison de l'exclusion est écrite noir sur blanc.
Mon réflexe systématique : filtrer les pages exclues par « Explorée, actuellement non indexée ». Si vous en avez des centaines, vous avez un problème de qualité ou de budget de crawl. Si vous voyez « Détectée, actuellement non indexée », c'est fréquemment un souci de vitesse de serveur ou de contenu dupliqué.
Étape 2 : le crawl comparatif
Deux crawls valent mieux qu'un. Je lance toujours une première passe sur l'ensemble du site pour cartographier l'existant, puis une seconde après avoir exclu les paramètres d'URL parasites. La comparaison révèle les surprises.
Ce que je cherche en priorité :
- Les balises title et meta description dupliquées sur plusieurs URL distinctes.
- Les chaînes de redirections (une redirection qui pointe vers une autre redirection : perte de jus garantie).
- Les boucles de redirection, qui bloquent purement et simplement l'exploration.
- Les pages renvoyant un code 200 alors qu'elles devraient être en 404 ou 410.
- La profondeur de clic : toute page à plus de 4 clics de l'accueil est suspecte.
Étape 3 : les logs serveur, le seul juge de paix
Voilà ce que personne ne vous dit. Un crawler vous montre ce que vous avez détecté. Les logs serveur vous montrent ce que Googlebot a vraiment visité, à quelle fréquence, et combien de temps il a passé sur chaque page.
Sur le site d'un client dont je tairai le nom, le crawl remontait 3 400 URL propres. Les logs en révélaient 11 000 visitées par Googlebot, dont la moitié étaient des paramètres de tri du catalogue. Résultat : un budget de crawl littéralement dilapidé sur des pages sans valeur. On a fermé l'accès aux paramètres via robots.txt, et en six semaines la fréquence de passage sur les pages produits a doublé.
Étape 4 : performance et Core Web Vitals
Je ne m'attarde pas sur les scores bruts de Lighthouse, qui varient trop selon la machine qui exécute le test. Ce que je regarde, ce sont les données de terrain : le LCP réel, l'INP réel, le CLS réel. Un site peut afficher 95 sur PageSpeed Insights et ramer à mort chez ses utilisateurs réels.
Étape 5 : prioriser par impact et par effort — l'étape qui sauve un audit
Un audit qui liste 200 problèmes sans dire par quoi commencer est un audit raté. Je classe toujours chaque action dans une matrice simple : impact estimé sur l'indexation ou le positionnement, d'un côté ; effort de mise en œuvre, de l'autre. Les correctifs à fort impact et faible effort passent en premier, toujours.
| Type d'anomalie | Impact typique | Effort de correction | Outil principal |
|---|---|---|---|
| Balise noindex accidentelle | Critique : pages retirées de l'index | Faible (5 minutes) | Search Console |
| Contenu dupliqué massif | Élevé : dilution du signal | Moyen (jours) | Crawl + canonicals |
| Chaînes de redirections | Moyen : perte de crawl budget | Faible à moyen | Logs serveur |
| Pages orphelines | Élevé : invisibles pour Google | Faible (maillage) | Logs + crawl |
| Temps de réponse serveur > 1 s | Élevé : chute du taux de crawl | Variable selon l'hébergeur | Monitoring terrain |
| Données structurées absentes | Faible à moyen : perte de rich snippets | Moyen | Validateur |
Un exemple concret de ce que révèle un audit
Avouons-le : les rapports PDF d'exemple qu'on trouve en ligne sont souvent génériques et interchangeables. Je vous donne donc un cas réel, anonymisé, tel que je l'ai traité.
Un site B2B de services, environ 120 pages, trafic en chute de 30 % sur deux trimestres. Voici ce que l'audit a remonté :
- 42 pages en contenu dupliqué quasi intégral, avec seulement la ville modifiée dans le texte.
- Un « & » mal encodé dans le sitemap XML, qui empêchait sa lecture complète par Google.
- L'accueil en
noindexdepuis une réécriture de la page d'atterrissage six mois plus tôt. - Un temps de réponse serveur oscillant entre 0,8 et 4 secondes selon les heures.
La correction du noindex a suffi à faire remonter le trafic organique de 18 % en un mois. Le reste a pris du temps. Mais notez la logique : on a traité d'abord ce qui bloquait l'indexation, ensuite le reste.
Un audit SEO gratuit, est-ce vraiment possible ?
Techniquement, oui. La Search Console est gratuite, elle contient déjà 60 % des réponses. Un crawler en version gratuite vous donnera les balises dupliquées, les codes de statut et la structure des liens internes. Les données de vitesse de terrain sont accessibles sans rien payer.
Ce qui n'est pas gratuit, c'est le jugement. Savoir que 3 000 pages sont « non indexées » ne sert à rien si vous ne savez pas lesquelles sont légitimes et lesquelles révèlent un problème. J'ai vu des entreprises fermer des pages parfaitement saines parce qu'un rapport les signalait en rouge. Enfin, « gratuit » ne veut pas dire « fiable » : méfiez-vous des outils qui notent votre site sur 100 sans expliquer leurs critères.
Sur les outils d'audit : mon avis sans détour
Semrush, Ahrefs, Screaming Frog, Sitebulb. J'ai utilisé les quatre. Franchement, pour un audit technique pur, Screaming Frog est le meilleur rapport qualité-prix du marché, et je défendrai cette position bec et ongles. Sa licence annuelle coûte moins qu'un mois d'abonnement aux suites complètes, et il fait le travail sale — le crawl massif — mieux que les autres.
Semrush reste imbattable pour le suivi de position et l'analyse concurrentielle. Ahrefs pour le profil de backlinks. Mais aucun de ces outils ne remplacera l'analyse des logs. C'est la limite que je répète à chaque formation : aucun outil ne pense à votre place.
Les trois erreurs que je commets le plus souvent… et comment les éviter
Je vais être honnête : j'ai raté des audits. Au début, je me focalisais sur la technique pure et j'oubliais une dimension évidente.
La première erreur, c'est d'ignorer le rendu JavaScript. Sur un site en React sans SSR, j'ai perdu trois jours à m'acharner sur les balises alors que le problème était que Googlebot ne voyait tout simplement pas le contenu. Depuis, je vérifie systématiquement la version rendue, pas le code source brut.
La deuxième : produire un rapport trop long. Un client m'a avoué un jour qu'il n'avait même pas ouvert le PDF qu'il avait payé. Aujourd'hui, je livre une page de synthèse avec cinq actions priorisées, et le détail en annexe. Le taux d'exécution a explosé.
La troisième : sous-estimer l'impact du mobile. Plus de la moitié du trafic de la plupart des sites que j'audite vient du téléphone, et je vois encore des balises canonical différentes entre versions desktop et mobile. C'est une faute qui coûte cher.
Ce qui distingue un bon audit d'un mauvais
La différence se résume rarement au nombre de problèmes détectés. Elle se joue sur l'ordonnancement. Un bon audit technique vous dit quoi faire en premier, quoi reporter, et surtout quoi ignorer — parce que tout n'a pas la même valeur.
La prochaine fois que vous recevez un rapport avec 300 alertes rouges, posez une seule question : « Lesquelles bloquent réellement l'indexation ou la performance ? » Si votre prestataire hésite, vous avez votre réponse.
Et cette balise noindex posée par erreur sur les articles de blog ? Elle existe encore sur des centaines de sites, quelque part. La question n'est pas de savoir si vous en avez une. C'est de savoir si vous le découvrirez avant votre client.