Audit SEO technique : la méthode, étape par étape

Pourquoi commencer par la réconciliation des sources

Trois systèmes connaissent les URL de votre site, et ils ne sont jamais d’accord :

• le crawl connaît ce qui est atteignable en suivant les liens depuis la page d’accueil ;
• le sitemap déclare ce que vous estimez important ;
• Search Console connaît ce que Google a réellement découvert, y compris par des liens externes ou d’anciennes URL.

Les écarts entre ces trois ensembles décrivent précisément vos problèmes :

Écart observé	Ce que cela signifie
Dans le crawl, absente du sitemap	Le sitemap est incomplet, ou la page ne devrait pas être indexable
Dans le sitemap, absente du crawl	Page orpheline : déclarée importante, mais non maillée
Connue de Search Console, absente du crawl	URL héritée, souvent une ancienne page ou une URL paramétrée
Dans le sitemap, mais en redirection ou en 404	Signal contradictoire envoyé au moteur

Sur ce domaine, cette réconciliation a produit un inventaire de 404 URL, dont une majorité de contenus hérités sans rapport avec la nouvelle thématique. Sans cet inventaire, la refonte aurait traité le corpus en bloc.

Phase 1 — Collecter, et dater les sources

Avant toute analyse, consignez quelle source a été utilisée et à quelle date. Un audit dont on ne sait plus d’où viennent les chiffres n’est pas vérifiable.

• export Search Console sur une fenêtre explicite, requêtes et pages ;
• crawl complet, en notant l’agent utilisé et le respect ou non du robots.txt ;
• logs serveur si disponibles, avec la période couverte ;
• données terrain Core Web Vitals publiques, quand elles existent pour le site.

Piège fréquent : un export Search Console annoncé sur trois mois peut ne contenir que soixante jours. Sur ce domaine, l’écart a été constaté et conservé dans le rapport plutôt que lissé. Vérifiez toujours la première et la dernière ligne de date de vos exports.

Phase 2 — Contrôler l’indexabilité

Pour chaque gabarit, vérifiez la cohérence de ces quatre signaux. Ils se contredisent plus souvent qu’on ne le croit :

1. le code de statut HTTP réellement renvoyé ;
2. robots.txt — exploration autorisée ou non ;
3. la directive robots, en balise meta ou en en-tête X-Robots-Tag ;
4. l’URL déclarée en canonical.

Les combinaisons problématiques les plus courantes :

• URL bloquée dans robots.txt et portant un noindex : le moteur ne peut pas lire le noindex, donc il ne l’applique pas ;
• canonical pointant vers une URL qui redirige, ou vers une URL en noindex ;
• sitemap listant des URL non indexables.

Phase 3 — Mesurer ce qui est réellement servi

Récupérez le HTML brut, sans exécuter le JavaScript, et comparez-le au DOM final. L’écart indique ce qui dépend du rendu client.

Ce qui doit impérativement figurer dans la réponse serveur d’une page indexable :

• le title, la meta description et la canonical ;
• un h1 unique ;
• le contenu principal, sous forme de texte ;
• les liens de navigation, en balises <a href>.

C’est exactement ce que fait l’extracteur de balises publié ici : il lit le HTML servi sans l’exécuter, ce qui rend l’écart immédiatement visible.

Phase 4 — Évaluer le budget de crawl

Avec des logs, répartissez les hits des robots par type d’URL et par code de statut. Sans logs, approchez le problème par le nombre d’URL explorables regroupées par motif.

Le signal d’alerte est simple : si le nombre d’URL explorables dépasse largement le nombre de pages utiles, l’exploration des pages importantes se raréfie. Les générateurs habituels sont les facettes combinées, les tris, les calendriers, la recherche interne et les paramètres de session.

Phase 5 — Vérifier les redirections

Pour chaque redirection : code de statut, destination, nombre de sauts. Les trois défauts à corriger sont :

• les chaînes de plus d’un saut ;
• les boucles ;
• les destinations répondant 404.

Le mapping de ce domaine applique une règle stricte : une 301 n’est posée que vers un équivalent réel. Les contenus sans équivalent passent en 404 ou en 410 assumé, et aucune redirection de masse ne pointe vers la page d’accueil. La documentation de Google sur les migrations est explicite sur ce point : une redirection doit mener vers une page équivalente.

Phase 6 — Transformer les constats en contrôles

C’est l’étape que la plupart des audits omettent, et c’est celle qui empêche le travail de se perdre. Chaque correctif doit s’accompagner d’un contrôle automatisable :

Correctif	Contrôle associé
canonical auto-référente sur les pages indexables	Script : chaque page indexable porte une canonical égale à son URL
h1 unique par page	Script : compte des h1 par page, échec si différent de 1
Aucun lien interne cassé	Script : résolution de tous les liens internes contre les pages générées
Destinations de redirection existantes	Script : chaque destination déclarée correspond à une page publiée
Données structurées valides	Script : parsing de chaque bloc JSON-LD

Ces cinq contrôles sont ceux qui bloquent la publication de ce site. Ils tournent en ligne de commande avant chaque mise en production : un correctif obtenu une fois reste acquis, au lieu de disparaître à la prochaine évolution du thème.

Modèle de ligne de rapport

Pour que l’audit soit applicable, chaque constat tient sur une ligne structurée :

Constat     : les URL de facettes sont explorables et indexables
Preuve      : 14 312 URL /catalogue/?filtre= dans le crawl, 212 pages utiles
Maillon     : crawl
Impact      : élevé — l'exploration des catégories est diluée
Effort      : moyen — modification du thème + règle de canonical
Correctif   : ne pas générer le lien ; canonical vers la catégorie parente
Vérification: re-crawl, le nombre d'URL explorables doit retomber sous 1 000

Un rapport composé de lignes de cette forme est exécutable par une équipe technique. Une liste de recommandations génériques ne l’est pas.