Pourquoi un audit SEO naïf avec Claude Code ne marche pas
Tu as déjà essayé de demander à Claude Code « fais-moi un audit SEO de mon site » ? Si oui, tu as probablement été impressionné les 30 premières secondes, puis déçu en lisant le résultat. Une liste plate de 50 problèmes sans hiérarchie, des priorités absurdes (« corrige le H1 de la page /blog » alors que c’est une page hub sans enjeu SEO), et des suggestions dangereuses comme un désaveu de liens massif.
Ce n’est pas la faute de Claude Code. C’est la tienne. Ou plutôt, c’est la faute de ta méthode. Comme on le dit souvent : « Si tu lui donnes de la merde, il va automatiser de la merde. » Sans données réelles, Claude Code scrape robots.txt et le sitemap, invente des analyses à partir de 2-3 pages, et produit ce qu’on appelle un « bon audit de merde », un document qui te ferait passer pour un incompétent auprès d’un client.
Le problème est simple : tu demandes une analyse à une IA sans lui fournir les données pour la faire. C’est comme demander à un médecin de poser un diagnostic sans ausculter le patient. La bonne approche, c’est de construire un outil, pas de demander une analyse. Tu ne dis pas « fais-moi un audit », tu dis « construis-moi un outil qui va crawler mon site, évaluer chaque page, et produire un rapport classé par priorité ».
Dans cet article, je te montre la méthode exacte pour industrialiser un audit SEO complet avec Claude Code : crawl réel de 10 000 URLs, extraction des signaux critiques, priorisation P1-P4, et génération d’un rapport client en 15 minutes.
La méthode en 5 phases : de la data brute au rapport priorisé
Le pipeline complet se décompose en 5 étapes reproductibles. Chaque phase transforme une couche de données en décision actionnable. Voici la vue d’ensemble avant d’entrer dans le détail.
- Phase 1 : Crawl réel – Lancer un vrai crawl via une API (comme SeoLap.fr)
- Phase 2 : Grille d’évaluation – Forcer Claude à définir ses critères de qualité avant l’analyse
- Phase 3 : Enrichissement – Injecter les données de visibilité, backlinks et Google Search Console
- Phase 4 : Priorisation – Appliquer la grille P1-P4 pondérée par l’importance de chaque page
- Phase 5 : Rendu – Générer un rapport Markdown puis un PowerPoint exploitable
Ce qui distingue cette méthode d’une approche naïve, c’est que chaque phase produit des données structurées qui alimentent la suivante. Tu construis une chaîne de traitement, pas une analyse ponctuelle. L’automatisation est totale : une fois le workflow paramétré, tu peux le rejouer sur n’importe quel site à l’échelle.
Phase 1 : Lancer un crawl réel via une API
Un crawl simulé avec Screaming Frog en local ne suffit pas. Tu obtiens des données batch que tu dois exporter, traiter, puis réinjecter dans Claude Code. C’est chronophage et ça casse le flux de travail. La solution, c’est d’utiliser un service de crawl piloté par API, directement depuis la ligne de commande.
Voici la procédure exacte :
- Ouvre ton service de crawl et crée une clé API
- Copie la référence API complète dans Claude Code
- Demande à Claude de lancer le crawl du domaine cible avec une commande en langage naturel
- Attends la fin du crawl (profondeur max configurée dans le code)
Les données récupérées incluent : statuts HTTP, liens internes, balises canonical, profondeur, nombre de mots, et bien plus. Pour un site de taille moyenne (500 à 2 000 pages), le crawl est terminé en quelques minutes.
L’avantage de cette approche par API, c’est que Claude Code peut interroger les données en temps réel, sans export ni manipulation manuelle de fichiers. Le crawl devient une étape du pipeline, pas un prérequis déconnecté.
Phase 2 : Générer une grille d’évaluation avant l’analyse
C’est l’étape la plus sous-estimée, et pourtant la plus critique. Avant de demander à Claude Code d’analyser les données de crawl, tu dois lui faire définir sa propre grille de qualité. Le prompt est simple : « Qu’est-ce qui distingue un bon audit SEO d’un mauvais ? Donne-moi la grille que tu utiliseras pour évaluer. »
Cette technique force Claude à structurer son analyse avant d’exécuter. Il ne peut plus biaiser ses critères après coup ou inventer des priorités au fil de l’eau. La grille devient un contrat entre toi et l’agent IA.
Un bon audit, selon la grille auto-générée, pondère chaque finding par l’importance de la page, quantifie les impacts, et se base exclusivement sur les données de crawl réelles. Un mauvais audit produit une liste plate sans hiérarchie, avec des fetches unitaires et aucun contexte de page. La différence est radicale : une page à 500 visites mensuelles sans H1 n’est pas prioritaire ; une page stratégique avec une balise canonical manquante est un P1 immédiat.
Phase 3 : Injecter les données de visibilité et backlinks
Les données de crawl seules ne suffisent pas à prioriser correctement. Une page en 404 qui reçoit 0 visite n’est pas un problème urgent. Une page en 404 avec 200 backlinks externes, si. C’est là qu’intervient l’enrichissement avec les données de visibilité.
Connecte d’autres APIs (comme Haloscan ou SEObserver) à Claude Code. Les métriques récupérées incluent : backlinks, domaines référents, analyse des ancres, mots clés positionnés, trafic organique, etc. Tu peux aussi utiliser le MCP Google Search Console pour récupérer les clics, impressions et positions par page.
Le croisement crawl + données de visibilité est ce qui transforme un audit technique en audit stratégique. Sans les données de visibilité, tu aurais sprayé les corrections sur tout le site. Avec, tu concentres les efforts sur les pages qui génèrent du trafic et des backlinks.
Phase 4 : Prioriser les findings avec la grille P1-P4
Une fois les données de crawl et de visibilité injectées, Claude Code applique la grille d’évaluation pour prioriser chaque finding. Le framework P1-P4, issu des méthodologies d’audit classique, classe chaque problème par sévérité :
| Niveau | Critère | Exemples concrets |
|---|---|---|
| P1 | Bloque le crawl ou l’indexation | 0 balise canonical, noindex sur pages clés, redirections cassées |
| P2 | Impact direct sur les positions | Contenu mince, balises manquantes, liens internes insuffisants |
| P3 | Optimisations à moyen terme | Amélioration des ancres, enrichissement de contenu, UX |
| P4 | Nice-to-have | Micro-optimisations, enrichissements structurels |
Ce qui rend cette priorisation fiable, c’est que Claude Code pondère chaque finding par l’importance réelle de la page. Une page produit qui reçoit 3 000 visites organiques par mois et qui est en 404 reçoit un score bien plus élevé qu’une page de blog vieille de 3 ans sans trafic. Le résultat n’est pas une liste plate, mais une roadmap actionnable avec des recommandations classées par impact business.
Phase 5 : Générer le rapport final en Markdown puis PPTX
La dernière étape du workflow transforme les données priorisées en un livrable exploitable. Le format natif de sortie est le Markdown : idéal pour le versionnage, la réutilisation, et l’intégration dans un pipeline de suivi. Une fois le Markdown validé, tu demandes à Claude Code de générer un PowerPoint professionnel de 10 à 15 slides.
Le template agence suit une structure logique : slide 1 = résumé exécutif avec les chiffres clés, slides 2 à 5 = urgences P1, slides 6 à 8 = P2, et ainsi de suite. Chaque slide contient le problème, la preuve chiffrée, l’impact estimé, et la recommandation priorisée. Le design est basique mais structuré — suffisant pour un livrable client.
Alternatives possibles : export PDF, dashboard Notion, ou CSV pour alimenter un outil de suivi. L’avantage du Markdown comme format pivot, c’est que tu peux le transformer en n’importe quel autre format sans perdre la structure. La génération prend moins de 5 minutes une fois les données traitées.
Ce que les concurrents ratent : les signaux avancés que seul Claude Code peut extraire
La plupart des articles sur le sujet se contentent de décrire le workflow de base. Ils ne poussent pas jusqu’aux signaux avancés que Claude Code peut extraire grâce à sa capacité à croiser des sources de données et exécuter du code personnalisé. Voici ce qu’ils ratent.
- Détection des pages orphelines via croisement logs + crawl. En connectant les logs serveur (via analyse de logs) au crawl, tu identifies les pages que Google voit mais qui sont absentes de la structure du site. Ces pages orphelines gaspillent du budget de crawl et ne bénéficient d’aucun PageRank interne. Aucun outil du marché ne détecte ça nativement.
- Analyse des breadcrumbs comme signal architectural. Les breadcrumbs révèlent la vérité business de l’architecture d’un site, indépendamment de la structure des URLs. Claude Code peut extraire les breadcrumbs via XPath, les parser, et détecter les incohérences entre l’URL et la catégorisation business. Une page classée dans « Accueil > Produits > Catégorie A » avec une URL qui suggère « Catégorie B » ? C’est un signal de cannibalisation potentielle.
- Cannibalisation sémantique via embeddings. En utilisant l’API OpenAI (text-embedding-3-small) depuis Claude Code, tu calcules la similarité cosinus entre chaque paire de pages. Pour environ 5$ sur 50 000 URLs, tu obtiens une matrice de similarité qui détecte la cannibalisation sémantique, pas seulement lexicale. Deux pages sur le même sujet avec des mots différents ? Claude Code les identifie et propose une fusion ou une canonicalisation.
- Extraction custom XPath à grande échelle. Prix, disponibilité, notes produits, dates de publication, Claude Code peut extraire n’importe quelle donnée du DOM via XPath 3.x sur des milliers de pages en un seul passage. Les fonctions string-join(), distinct-values(), matches() et tokenize() sont disponibles nativement.
- PRic (PageRank Interne des pages Crawlées). Aucun outil du marché ne calcule le PRi nativement. Le PRi (PageRank Interne) est théorique : il suppose que Google crawl toutes les pages de la structure. Le PRic, lui, ne se calcule que sur les pages réellement crawlées par Googlebot. Claude Code peut filtrer les URLs crawlées, calculer le PR interne sur ce sous-ensemble, et identifier les pages importantes qui ne reçoivent pas assez de jus de lien.
Les pièges à éviter et les limites à connaître
La méthode que je viens de décrire est puissante, mais elle a ses limites. Voici les pièges à éviter pour ne pas te retrouver avec un audit qui fait plus de mal que de bien.
- Ne jamais faire confiance à un audit sans données réelles. C’est le piège numéro 1. Sans crawl réel, sans données de visibilité, sans backlinks, Claude Code hallucine. Il invente des problèmes, en rate d’autres, et produit des recommandations dangereuses.
- Le piège du skill non vérifié. Un skill Claude Code malveillant peut compromettre tes repos GitHub entiers. Accès au système de fichiers, lecture de clés API dans l’environnement, push de code malveillant. Ne jamais installer un skill provenant d’une source non vérifiée, même partagé par un pair. Traite les skills tiers comme du code tiers : revue obligatoire avant installation.
- Coût réel des sessions longues. Un audit complet consomme des tokens. Compte environ 5 à 10€ pour un audit complet avec enrichissement backlinks et génération PPTX. Les sessions longues (plus de 30 minutes de travail continu) peuvent faire grimper la facture. Utilise /clear entre les phases non liées et /compact pour optimiser la consommation de contexte.
- Ce que Claude Code ne fait pas. L’analyse de logs serveur bruts, l’interprétation stratégique (faut-il recréer la page ou la rediriger ?), le CRO (taux de conversion, UX). Claude Code est un outil d’analyse et de génération, pas un consultant SEO. La décision finale reste humaine.
- La trame humaine indispensable. Rappelons-le, il y a encore de la matière grise humaine importante. Ma méthode : construire une trame complète de A à Z (structure, méthode, critères) avant de confier l’exécution à Claude. Claude Code amplifie ce qu’on lui donne. Si ta trame est bonne, le résultat est excellent. Si ta trame est mauvaise, tu obtiens un désastre automatisé à grande échelle.
Si tu veux suivre l’aventure, abonne-toi !
