Configurez votre audit SEO technique en 9 étapes

Un audit SEO technique ne commence pas avec un outil ouvert ni avec un PDF de 80 pages que personne ne lit. Il commence par une question dérangeante : qu’est-ce qui empêche Google de crawler, de rendre et d’indexer correctement votre site corporate ? Si vous ne pouvez pas y répondre avec des données, ce que vous avez est une liste de tâches, pas un audit.

Cet article décrit la séquence exacte de configuration que j’applique dans des projets B2B comptant des centaines ou des milliers d’URL, ordonnée par dépendances : chaque étape produit la donnée qui alimente la suivante. Si vous sautez l’ordre, vous finirez par collecter des métriques que vous ne pouvez pas interpréter.

Étape 0 : définir le périmètre avant de toucher à un outil

Dans une entreprise avec plusieurs lignes de métier, l’erreur la plus coûteuse est d’auditer « tout le domaine ». Avant de configurer quoi que ce soit, délimitez :

• Sous-domaines inclus : blog, boutique, espace client, help center. Décidez si l’espace privé entre dans le périmètre (normalement non, mais il convient de le documenter).
• Langues et versions régionales : si vous avez /es/, /mx/ et /ar/, chacune nécessite sa propre révision hreflang.
• Parties prenantes : celui qui approuve les changements de template se trouve généralement dans l’IT, pas au marketing. Identifiez-le à cette phase ou le reste du processus se bloque.

Un cas réel : une entreprise de services industriels avec 4 langues a découvert lors de la phase de périmètre que son help center vivait sur un sous-domaine avec un CMS différent et sans accès aux logs. Cela a complètement changé la méthodologie du reste de l’audit : sans logs, l’analyse de crawl a dû se baser sur des échantillons de Search Console et sur des crawls avec le user-agent de Googlebot.

Étape 1 : configurer l’accès aux données sources

Sans cette base, tout audit est spéculatif. Il vous faut, au minimum :

Search Console

Vérifiez la propriété par préfixe d’URL chaque fois que possible (cela permet de segmenter par sous-répertoire) et conservez la propriété de domaine comme secours. Vérifiez que l’utilisateur que vous utiliserez dispose d’une autorisation complète, et non restreinte : l’autorisation restreinte masque des données de performance et d’index dont vous aurez besoin par la suite.

Analytics

Si vous utilisez GA4, assurez-vous que le flux de données web est actif depuis au moins 90 jours. Avec moins d’historique, toute comparaison de trafic organique avant/après un changement technique n’est que du bruit. Configurez un segment de trafic organique qui exclut les domaines de référence internes et les paramètres de campagne qui faussent l’attribution.

Logs du serveur

Demandez l’accès aux fichiers d’accès (Apache ou Nginx) avec un minimum de 30 jours. Selon la documentation officielle de Google sur le crawl, l’analyse de logs est la seule source qui montre avec certitude quelles URL Googlebot visite réellement, par rapport à celles que vous croyez qu’il visite.

Accès au CMS et au dépôt

Vous devrez pouvoir lire les templates d’en-tête, les règles de redirection et le fichier robots.txt. Si vous n’avez pas accès au dépôt, demandez à l’équipe technique d’exporter la configuration du .htaccess ou du middleware de redirections.

Étape 2 : préparer le crawler avec précision

La configuration du crawler détermine la qualité de toutes les constatations ultérieures. Des réglages qui font la différence :

• User-agent : utilisez celui de Googlebot pour simuler le crawl mobile (Googlebot Smartphone). Beaucoup de différences de contenu n’apparaissent qu’avec cet agent.
• Rendu JavaScript : activez-le uniquement si votre site en a besoin. Sur les sites à fort contenu dynamique, le rendu fait exploser le temps de crawl et peut épuiser les crédits de l’outil. Sur un projet de 12 000 URL, activer le rendu complet a obligé à diviser le crawl en segments par section.
• Limite de vitesse : ne dépassez pas 2-3 requêtes par seconde en production sans prévenir l’IT. Un crawl agressif peut déclencher le WAF et fausser les résultats avec des erreurs 403.
• Authentification : s’il existe du contenu derrière un login pertinent pour le SEO (par exemple, des fiches produit avec des prix masqués), configurez des cookies ou des en-têtes d’authentification.

Enregistrez la configuration du crawl. Vous en aurez besoin à l’identique pour comparer les résultats après les changements.

Étape 3 : valider la santé du crawl avec robots.txt et sitemaps

Avant de vérifier quoi que ce soit d’autre, confirmez que Google peut atteindre vos URL :

1. Examinez robots.txt ligne par ligne. Cherchez les blocages de ressources CSS/JS (ils cassent le rendu) et de paramètres qui génèrent bien du contenu unique.
2. Vérifiez que le sitemap XML ne contient que des URL canoniques, avec un statut 200 et non bloquées. Un sitemap avec des redirections ou des 404 est un signe de négligence que Google ignore progressivement.
3. Vérifiez dans Search Console → Sitemaps que le fichier est traité sans erreurs et que les URL découvertes correspondent à celles que vous attendez.
4. Utilisez l’outil d’inspection d’URL pour les 10 pages les plus importantes par activité et confirmez « L’URL est sur Google » et que la version crawlée est la canonique.

Limite honnête : si votre site compte plus de 50 000 URL, l’inspection manuelle ne passe pas à l’échelle. Dans ce cas, priorisez l’inspection par template (une URL représentative par type) et complétez avec le rapport « Pages » de Search Console.

Étape 4 : cartographier les codes de statut et les redirections

Exportez du crawl toutes les URL dont le statut diffère de 200 et classez-les :

• 301/302 : vérifiez que les chaînes de redirection ne dépassent pas un saut et identifiez les boucles. Un schéma courant en entreprise après les migrations : /produit → /produit/ → /es/produit/ → 404. Chaque saut perd du signal et ajoute de la latence.
• 404/410 : croisez la liste avec Search Console pour détecter les URL qui reçoivent encore des liens externes. Ce sont celles qui ont besoin d’une redirection ou d’une récupération, pas celles qui existent simplement.
• 5xx : si elles apparaissent dans le crawl, arrêtez. Un serveur instable invalide toute autre analyse.

Documentez chaque redirection avec son origine, sa destination et son motif. Ce registre est ce qui permettra à l’IT d’exécuter les changements sans interprétations.

Étape 5 : résoudre les canoniques et les duplications

Configurez la révision en trois couches :

1. Canoniques déclarées : comparez la balise rel=canonical avec l’URL finale après redirections. Une canonique qui pointe vers une URL redirigée est une erreur fréquente dans les CMS avec des plugins SEO mal configurés.
2. Paramètres : identifiez ceux qui génèrent des doublons (tri, filtres, pagination) et choisissez entre canonique, noindex ou blocage. Attention : bloquer dans robots.txt une URL avec canonique empêche Google de lire cette canonique.
3. Variantes d’URL : majuscules, barre finale, http/https, www/non-www. Forcez une seule version avec des redirections au niveau du serveur, pas depuis le CMS.

Cela ne fonctionne pas de la même manière dans tous les cas : en ecommerce avec des filtres à facettes, la canonique seule ne résout pas le problème si les filtres reçoivent des liens internes. Là, il vous faut en plus un contrôle du maillage interne et, parfois, un rendu conditionnel des liens de filtre.

Étape 6 : auditer le rendu et le JavaScript

Comparez le HTML initial avec le DOM rendu sur les templates clés. Cherchez :

• Du contenu principal qui n’apparaît qu’après l’exécution de JavaScript (risque élevé s’il n’y a pas de rendu côté serveur).
• Des liens internes générés par JS que le crawler ne découvre pas sans rendu.
• Des métadonnées (title, canonical, hreflang) injectées par JS et qui pourraient ne pas se refléter dans le HTML servi.

Selon la documentation officielle sur le rendu, Google peut exécuter JavaScript, mais avec un budget de crawl limité et sans garantie que tous les scripts s’exécutent. La conclusion pratique : si un lien ou une canonique n’existe qu’après JS, traitez-le comme non fiable.

Étape 7 : mesurer les Core Web Vitals avec des données de terrain

Ne vous contentez pas de Lighthouse. Configurez la révision avec des données réelles :

1. Exportez le rapport Core Web Vitals de Search Console par type d’appareil et regroupement d’URL.
2. Identifiez quels templates échouent sur LCP, INP ou CLS, et non quelles pages isolées.
3. Priorisez par impact : un template de fiche produit avec des milliers d’URL et un LCP déficient pèse plus que la page d’accueil.

Nuance importante : les données de terrain ont de la latence (28 jours dans le rapport de Search Console). Si vous venez d’optimiser des images, ne vous attendez pas à voir le changement la même semaine. Et si votre trafic est faible, il se peut qu’il n’y ait pas suffisamment d’échantillons pour évaluer un template précis ; dans ce cas, combinez laboratoire et terrain, et dites-le dans le rapport.

Étape 8 : consolider le rapport et prioriser par dépendances

Le livrable n’est pas une liste d’erreurs. C’est une séquence d’exécution avec des dépendances :

• Bloquants : 5xx, robots.txt qui bloque des ressources, redirections cassées. Sans cela, le reste n’a pas d’importance.
• Structurels : canoniques, duplications, architecture de maillage interne.
• Performance : Core Web Vitals par template.
• Améliorations : données structurées, hreflang, optimisation des images.

Chaque tâche doit indiquer l’URL ou le template concerné, l’équipe responsable et comment le changement sera vérifié (par exemple, « recrawl des 200 URL du template X et comparaison des codes de statut »).

Erreurs de configuration que je vois se répéter

• Auditer avec le user-agent de bureau sur des sites où le mobile sert un contenu différent. Les constatations ne correspondent pas à ce que Google indexe.
• Se fier à la couverture de Search Console sans croiser avec les logs. Il y a des URL crawlées qui n’apparaissent jamais dans les rapports et d’autres qui apparaissent comme « exclues » sans motif apparent.
• Modifier robots.txt et les canoniques en même temps. Si quelque chose s’aggrave, vous ne saurez pas ce qui l’a causé. Un changement par itération, avec date enregistrée.
• Ignorer l’espace client dans le robots.txt et découvrir des mois plus tard que Googlebot consomme du budget de crawl sur des URL de session.

Ce que cette méthodologie ne couvre pas

Un audit technique ne règle pas un problème d’intention de recherche ni de qualité de contenu. Si votre site crawle et indexe correctement mais que les pages ne répondent pas à ce que l’utilisateur cherche, les données techniques seront propres et le trafic restera plat. Il ne remplace pas non plus une révision des liens toxiques ni de l’autorité de domaine : ce sont des disciplines distinctes qui se complètent, sans se chevaucher.

Et un dernier avertissement : aucun audit ne garantit des améliorations de positionnement. Ce qu’il garantit, c’est que vous éliminez des obstacles mesurables. Le reste dépend de facteurs que vous ne contrôlez pas depuis le serveur.