Audit technique SEO : la méthode complète d'un ex-Head of SEO

📌 POINTS À RETENIR

• La méthode exacte que j'applique en mission depuis dix ans, étape par étape
• Les trois indicateurs que je regarde en premier sur un site que je découvre
• Le bon usage des canoniques, des logs et du budget de crawl, sans approximations
• Le seul livrable qui se lit vraiment (et celui qui finit dans un tiroir)

⏱️ Temps de lecture : ~14 min

---

Quand je suis arrivé chez Doctolib en 2017, le site faisait un peu plus d'un million de visites organiques par mois. Trois ans plus tard, on en était à trente millions. Entre les deux, il y a eu beaucoup de contenu, beaucoup d'autorité gagnée — et surtout, sept ou huit audits techniques qui ont permis à cette croissance de ne pas se cogner contre un plafond technique invisible.

C'est ce travail-là, la méthode que j'applique aujourd'hui en mission chez mes clients indépendants, que je vais détailler ici.

Qu'est-ce qu'un audit technique SEO ? Un audit technique SEO consiste à vérifier que les moteurs de recherche peuvent crawler, indexer et comprendre votre site sans friction. C'est le diagnostic qui précède toute stratégie éditoriale ou de linkbuilding sérieuse.

Pas de théorie, pas de checklist gratuite recyclée des dix premiers résultats Google. Vous allez voir ce que je regarde, dans quel ordre, avec quels outils, et pourquoi.

Pourquoi un audit technique avant tout

Il y a un ordre dans le SEO et il n'a jamais changé. D'abord, Google doit pouvoir accéder à vos pages. Ensuite, il doit pouvoir les indexer. Ensuite, il doit pouvoir comprendre de quoi elles parlent. Ensuite seulement, on peut espérer qu'il les classe favorablement.

L'audit technique vérifie les trois premières étapes. Tant qu'elles ne sont pas propres, tout le reste est du gâchis : du contenu invisible, du linkbuilding qui pousse des pages canonisées ailleurs, des Core Web Vitals catastrophiques qui annulent les gains éditoriaux.

Sur les deux cents missions que j'ai menées depuis 2020, j'ai un chiffre en tête : environ 60% des problèmes de visibilité organique d'un site sont d'origine technique. Pas éditoriale, pas autoritaire. Technique. Cela veut dire qu'on peut souvent débloquer une croissance significative sans écrire un mot supplémentaire.

C'est aussi ce qui rend l'audit technique tellement rentable. Et pourtant, c'est l'étape que tout le monde veut sauter.

Étape 1 — Préparer le terrain

Avant de lancer le moindre crawl, je passe deux à trois heures à cadrer. C'est la partie la plus ingrate et la plus rentable de l'audit. Si vous la sautez, vous perdrez plus de temps en repasses qu'en l'ayant faite proprement.

Définir le périmètre

Un site, ce n'est pas une URL. C'est souvent plusieurs sous-domaines, plusieurs langues, parfois plusieurs CMS, et toujours quelques zones grises dont personne ne se souvient. La première question que je pose au client : donnez-moi la liste exhaustive des sous-domaines actifs, des environnements de staging accessibles publiquement, et des sites tiers qui hébergent du contenu lié à votre marque.

Vous seriez surpris de voir combien de fois la réponse contient une surprise. Un blog WordPress en blog.entreprise.com que personne n'a touché depuis quatre ans. Un site de recrutement sur un sous-domaine. Un environnement de staging laissé indexable. Tout ça compte dans l'audit.

Récupérer les accès

La liste minimale que je demande dès le brief :

• Google Search Console (accès complet, pas restreint)
• Google Analytics 4 ou équivalent (Plausible, Matomo)
• Accès admin au CMS et aux fichiers sources
• Logs serveur sur 30 à 90 jours selon la taille du site
• Comptes Ahrefs ou Semrush si l'entreprise en a, sinon les miens

Sans GSC complet, vous bossez à l'aveugle. Sans logs, vous ratez 30% des problèmes de crawl. Et sans accès au code, vous ne pourrez pas qualifier ce qui est faisable et ce qui ne l'est pas.

Établir la baseline

Avant de toucher à quoi que ce soit, je note dans un fichier dédié :

• Le nombre de pages indexées (GSC > Pages)
• Le nombre de pages crawlées dans les 90 derniers jours (GSC > Statistiques sur l'exploration)
• Le trafic organique mensuel (GSC > Performances, 12 derniers mois)
• Les top-50 pages en termes de clics organiques
• Les top-100 mots-clés positionnés

C'est ma photographie de départ. Sans elle, je ne pourrai jamais mesurer l'impact des chantiers proposés. Six mois après l'audit, c'est cette baseline qui prouve si on a fait du bon ou du mauvais boulot.

Étape 2 — Crawler le site

Le crawl, c'est le moment où je découvre vraiment le site. Pas la version marketing du site, la version réelle, celle que voit Googlebot.

Le bon outil pour le bon site

J'utilise principalement trois crawlers selon le contexte. Voici comment je les départage :

Quel crawler pour quel site

Critère	Screaming Frog	Sitebulb	Oncrawl
Volume confortable	500k URL	1M URL	Illimité
Analyse de logs	❌	❌	✅
Rendu JavaScript	✅	✅	✅
Visualisation d'architecture	Limitée	Excellente	Excellente
Prix annuel	239 € (licence)	~600 €/an	À partir de 5 000 €/an
Idéal pour	Sites < 100k URL, audit rapide	Mid-market, livrables visuels	Sites > 100k URL, e-commerce, logs

Pour 80% de mes missions, Screaming Frog suffit. Sitebulb prend le relais quand le client veut un livrable plus visuel ou quand le site dépasse les 100 000 URL. Oncrawl, je le sors uniquement sur les gros e-commerces et les marketplaces, là où l'analyse de logs croisée avec le crawl change tout.

Configurer le crawl correctement

Un crawl mal configuré donne des résultats inutilisables. Trois réglages à ne jamais zapper :

1. Activer le rendu JavaScript si le site utilise du SSR ou du SPA (vérifiable en désactivant JS dans le navigateur : si la page est vide, le rendu est nécessaire)
2. Respecter le robots.txt par défaut, mais lancer aussi un crawl en l'ignorant pour voir tout ce que Google pourrait techniquement atteindre
3. Limiter la concurrence à 5 threads max sur un site en production pour ne pas le saturer (j'ai déjà fait tomber un site client en lançant un crawl à 50 threads, on évite)

Je lance toujours deux crawls en parallèle : un en respectant le robots.txt et un en l'ignorant. La différence entre les deux me dit si des ressources critiques sont bloquées par erreur.

Ce que je regarde dans les résultats

Une fois le crawl terminé, je vais directement vers six points :

• Codes de statut : combien de 4xx, combien de 5xx, et où sont-ils linkés depuis ?
• Redirections : chaînes de plus de deux redirections, boucles, redirections en 302 qui devraient être en 301
• Profondeur de clic : combien de pages à plus de 4 clics depuis la home ?
• Pages orphelines : pages dans le sitemap mais non liées en interne (ou inversement)
• Title et meta description : duplications, vides, longueurs hors normes
• Hreflang : si le site est multilingue, conformité des balises et réciprocité

Le combo "pages à plus de 5 clics + pages orphelines" est généralement mon premier indicateur de fragilité d'architecture. Si vous avez plus de 15% de votre site dans cette zone, on a un problème.

Étape 3 — Auditer l'indexation

Le crawler vous dit ce qui est techniquement accessible. Google Search Console vous dit ce qui finit réellement dans l'index. Et entre les deux, il y a presque toujours un gouffre.

Comparer crawl et index

Mon premier réflexe : exporter la liste des pages indexées depuis GSC (rapport "Pages") et la croiser avec la liste des URL trouvées par le crawler. Trois cas de figure se dégagent :

• Pages crawlées et indexées — la zone saine
• Pages crawlées mais non indexées — la zone à diagnostiquer (raison : "Détectée, actuellement non indexée", "Explorée, actuellement non indexée", "Page en double sans canonique sélectionnée par l'utilisateur")
• Pages indexées mais non trouvées par le crawl — les fameuses pages orphelines, souvent issues d'anciennes versions du site, parfois liées depuis des emails ou des PDF externes

Le deuxième cas est celui qui m'occupe le plus. Quand Google a crawlé une page mais a refusé de l'indexer, il y a toujours une raison, et elle se cache dans le rapport GSC. C'est là qu'on identifie la qualité éditoriale insuffisante, le contenu trop similaire à une autre page, le mauvais signalement de canonique.

Lire les logs serveur

À partir de 50 000 URL, l'analyse de logs n'est plus optionnelle. C'est elle qui répond à des questions que GSC ne couvre pas :

• Quelle proportion de mon budget de crawl Googlebot consacre à des pages stratégiques ?
• Combien de hits Googlebot fait-il sur des pages 404 ou 301 ?
• Quelles pages reçoivent zéro hit Googlebot sur 90 jours ?

Pour un site qui fait moins de 100 000 URL, je passe par un script Python maison qui parse les logs Nginx ou Apache et croise les URL avec mon crawl. Au-delà, j'utilise Oncrawl ou Botify, qui font ça nativement avec des dashboards bien plus lisibles.

J'aborde plus en détail le sujet du budget de crawl dans un article dédié, parce que c'est un sujet qui mérite ses propres pages.

Pour aller plus loin sur l'usage avancé de la console, voir mon guide Google Search Console.

Étape 4 — Mesurer la performance

La performance, ce n'est pas une question de score PageSpeed. C'est une question de Core Web Vitals mesurées sur des données réelles d'utilisateurs (CrUX), pas sur les données de laboratoire que vous voyez dans Lighthouse.

Les trois métriques qui comptent

Depuis mars 2024, Google utilise trois Core Web Vitals pour évaluer l'expérience d'une page :

• LCP (Largest Contentful Paint) — temps avant l'affichage du plus gros élément visible, cible : moins de 2,5 secondes
• INP (Interaction to Next Paint) — délai entre une interaction utilisateur et la mise à jour de l'écran, cible : moins de 200 ms
• CLS (Cumulative Layout Shift) — instabilité visuelle pendant le chargement, cible : moins de 0,1

Source : web.dev/articles/vitals.

Le piège classique consiste à regarder le score Lighthouse dans Chrome DevTools et à se réjouir d'un 95/100. Sauf que Lighthouse vous donne des données de labo, sur la machine du SEO en fibre, pas sur le smartphone Android d'entrée de gamme avec 4G dégradée que vos vrais utilisateurs utilisent.

Le seul tableau de bord qui compte, c'est le rapport "Signaux web essentiels" de Google Search Console. Il agrège les données réelles remontées par Chrome (CrUX). C'est là que je regarde la vérité.

Le diagnostic concret

Sur les sites où le LCP est mauvais, dans 80% des cas, la cause est l'une de ces trois :

1. Une image principale non optimisée (format pas WebP/AVIF, pas de loading="eager", pas de fetchpriority="high")
2. Un blocking script en <head> (souvent un tag manager ou un A/B test)
3. Un serveur trop lent, avec un TTFB qui dépasse 600 ms

Pour le CLS, c'est presque toujours lié à des images sans dimensions explicites, des bannières publicitaires qui s'injectent après le chargement, ou des polices web qui provoquent un FOIT/FOUT mal géré.

L'INP est plus retors : il faut souvent profiler un parcours utilisateur dans Chrome DevTools (onglet Performance) et identifier les long tasks JavaScript qui bloquent le main thread.

Je détaille la méthodologie complète dans mon article dédié sur Core Web Vitals 2026 et sur PageSpeed Insights.

Étape 5 — Balises, canoniques, données structurées

C'est l'étape où on vérifie que Google comprend correctement chaque page. Trois zones à passer au peigne fin.

Les balises essentielles

Sur chaque template de page, je vérifie :

• Title présent, unique, entre 30 et 60 caractères, qui contient le mot-clé cible ou un proche
• Meta description présente, unique, entre 120 et 160 caractères, attractive (pas un copier-coller du title)
• H1 présent, unique sur la page, cohérent avec le title
• Hiérarchie H1 > H2 > H3 logique, sans saut de niveau

Un audit de surface vous dira que ces points sont triviaux. Sur une mission classique, je trouve toujours :

• Au moins un template (souvent les pages de catégorie ou les fiches produit) avec des titles dupliqués entre eux
• Au moins une page importante sans H1 (le développeur a mis un <div> au lieu d'un <h1> parce que "c'était plus joli")
• Souvent, un usage du H1 en logo dans le header, qui pollue la hiérarchie

J'aborde la balise title en détail dans un article dédié ainsi que la meta description.

Le piège des canoniques

C'est probablement la zone où je trouve le plus d'erreurs critiques. Une balise <link rel="canonical"> mal posée peut vider une page de sa visibilité organique sans que personne ne s'en rende compte.

Trois cas que je vois en boucle :

1. Canonique vers une page différente sans raison — souvent à cause d'un paramètre d'URL (filtre, tracking) qui canonise vers la version "propre" alors que la page filtrée a sa propre intention de recherche
2. Canonique absente sur des pages avec paramètres — Google se débrouille seul, mal
3. Canonique cross-domain — pointer une page de votre site vers un site tiers, par erreur de copier-coller dans un template

Le test : pour chaque template, ouvrez l'inspecteur, cherchez canonical, et vérifiez que l'URL correspond bien à la page actuelle (sauf cas explicite de variante).

Les données structurées

Schema.org est devenu indispensable, pas tellement pour le SEO direct, mais pour la lisibilité par les LLM (ChatGPT, Perplexity, Gemini) qui s'appuient lourdement dessus en 2026.

Les types que je déploie systématiquement selon le contexte :

• Article ou BlogPosting sur les contenus éditoriaux
• Product + Offer sur les fiches produit
• Organization et WebSite sur l'ensemble du site
• FAQPage sur les pages avec FAQ structurée
• BreadcrumbList partout où il y a un fil d'ariane

Source officielle : developers.google.com/search/docs/appearance/structured-data.

Je vérifie chaque type avec l'outil de test des résultats enrichis de Google et avec Schema.org Validator. Les deux sont gratuits et donnent des résultats légèrement différents — je passe par les deux. J'ai un article entier sur Schema.org en 2026.

Étape 6 — Architecture et maillage interne

L'architecture, c'est la façon dont les pages sont reliées entre elles. Et le maillage interne, c'est le levier SEO le plus sous-exploité que je connaisse.

Cartographier l'existant

Sitebulb et Oncrawl ont des modules de visualisation d'architecture qui permettent de voir, en un coup d'œil :

• Les pages très linkées (plus de 50 liens internes entrants)
• Les pages peu linkées (moins de 5 liens entrants)
• Les zones isolées (clusters faiblement reliés au reste du site)

Sur Screaming Frog, j'extrais les données via le rapport "Inlinks" et je les visualise dans un Notion ou un Looker Studio.

Les trois règles que j'applique

Après douze ans, j'en suis arrivé à trois règles simples :

1. Toute page stratégique doit recevoir au moins dix liens internes contextuels (pas depuis le footer ou la nav globale, depuis le corps d'autres articles)
2. Aucune page importante ne doit être à plus de trois clics de la home
3. Les liens internes doivent porter une ancre descriptive et variée, pas "cliquez ici" ni l'URL brute

C'est le sujet que je traite en profondeur dans maillage interne SEO — on parle de la méthode exacte que j'ai mise en place chez Doctolib.

Étape 7 — Prioriser et livrer

Vous avez maintenant entre 50 et 300 problèmes identifiés selon la taille du site. Le travail le plus important commence : trier.

La matrice impact / effort

Pour chaque problème, j'évalue deux dimensions :

• Impact estimé sur le trafic organique : faible / moyen / fort
• Effort de mise en œuvre : quelques heures / quelques jours / quelques semaines

J'obtiens neuf cases. Je commence toujours par les "fort impact / faible effort" — c'est là que se cachent les quick wins qui débloquent un client en deux semaines. Ensuite les "fort impact / fort effort" qui méritent un projet dédié. Et je documente, sans les prioriser, les "faible impact / fort effort" qui finiront probablement jamais traités.

Le livrable qui se lit vraiment

Sur mes premières missions, je livrais un PDF de 80 pages. Personne ne le lisait. J'ai changé de méthode : je livre désormais deux documents, jamais plus.

Document 1 : un fichier de priorisation au format tableau (Notion, Google Sheets ou Airtable selon le client). Une ligne par chantier, avec les colonnes :

Chantier	Impact	Effort	Owner	Deadline	Statut
Corriger canoniques pages catégorie	Fort	3 jours dev	Lead front	M+1	À faire
Optimiser images home (LCP)	Moyen	1 jour dev	Lead front	M+1	À faire
Refonte fil d'ariane	Moyen	2 semaines	Lead back	M+2	Backlog

Document 2 : un mémo de 6 à 10 pages qui explique les trois ou quatre chantiers majeurs en détail. Pourquoi c'est un problème, ce qu'on perd à ne pas le corriger, comment on le corrige précisément, quel est l'impact attendu.

C'est tout. Pas de PDF de 80 pages. Pas de capture d'écran de chaque erreur. Le livrable doit être actionnable, pas exhaustif.

Quelques erreurs à éviter

Pour terminer, voici les pièges que je vois encore beaucoup en 2026, même chez des SEO expérimentés :

• Lancer un crawl sans définir le périmètre — vous perdrez du temps en repasses
• Ignorer les logs sur les gros sites — vous raterez 30% des problèmes
• Confondre Lighthouse et Core Web Vitals — vous optimiserez pour la mauvaise métrique
• Oublier l'audit mobile — Google indexe en mobile-first depuis 2019, et la majorité de vos utilisateurs sont sur mobile
• Livrer 80 pages au lieu de 6 — personne ne lira

L'audit technique n'est pas une démonstration de virtuosité. C'est un outil de décision. Il vaut mieux un audit de cinq problèmes bien priorisés qu'un catalogue de cinquante.

FAQ — Audit technique SEO

Combien de temps prend un audit technique SEO complet ?

Pour un site de moins de 10 000 URL, comptez 3 à 5 jours de travail effectif, hors temps d'attente sur les crawls et les exports GSC. Pour un site de plus de 100 000 URL, on est plutôt sur 8 à 15 jours, avec une analyse de logs serveur indispensable. Le délai n'est pas la variable critique : la qualité du périmètre l'est.

Faut-il un crawler payant pour faire un audit technique sérieux ?

Pour un site de moins de 500 URL, la version gratuite de Screaming Frog suffit. Au-delà, oui, il faut un outil pro : Screaming Frog payant (239 € de licence annuelle), Sitebulb (~600 €/an) ou Oncrawl selon votre profil. L'analyse de logs (Botify, Oncrawl ou un script Python sur les logs bruts) reste indispensable au-delà de 50 000 URL.

Audit technique ou audit éditorial : par où commencer ?

Toujours par le technique. Si Google ne peut pas crawler, indexer ou comprendre votre site, le meilleur contenu du monde ne servira à rien. L'audit éditorial vient ensuite, une fois les fondations propres. C'est dans cet ordre que j'ai géré la croissance organique chez Doctolib et c'est dans cet ordre que je travaille en mission.

Quelle est l'erreur technique SEO la plus fréquente ?

Le mauvais usage des balises canoniques. Sur 200 audits, j'ai vu environ 4 sites sur 10 avec des canoniques qui pointent vers la page actuelle alors qu'elles devraient pointer vers une autre, ou qui sont absentes là où elles devraient désigner une variante de référence. C'est invisible pour l'utilisateur, mais ça coûte cher en visibilité.

Faut-il refaire l'audit régulièrement ?

Oui. Un audit complet tous les 12 à 18 mois si vous avez un site stable. Tous les 6 mois si vous êtes en hyper-croissance ou si l'équipe produit livre vite. Entre deux audits, un monitoring continu sur trois indicateurs : pages indexées dans GSC, Core Web Vitals, et taux de pages canonisées correctement.

Que livrer après un audit technique : un PDF de 80 pages ?

Surtout pas. Un livrable utile tient en deux documents : un fichier de priorisation (action, impact estimé, effort, owner, deadline) et un mémo de 6 à 10 pages qui explique le pourquoi des trois ou quatre chantiers majeurs. Le rapport de 80 pages, personne ne le lit, et c'est exactement pour ça qu'on continue de le produire.

Pour aller plus loin

Un audit technique bien mené, c'est rarement une fin en soi. C'est une cartographie qui ouvre trois ou quatre chantiers prioritaires. La vraie valeur vient ensuite, dans la mise en œuvre.

Si vous voulez creuser des sujets spécifiques, je vous recommande de lire dans cet ordre : Core Web Vitals 2026 si la performance est votre point faible, maillage interne SEO si l'architecture est en cause, et Google Search Console pour exploiter à fond le rapport "Pages".