Florent Perez montre comment automatiser un audit de duplicate content : Screaming Frog piloté en CLI, via Claude Code. Le prompt, qui couvre l'enchaînement de bout en bout, orchestre le crawl, l'extraction HTML avec un fallback Python en cas d'échec, une analyse à plusieurs niveaux (lexicale et sémantique), puis la production de rapports Excel et Markdown. L'auteur ne survend rien. La méthode n'est pas optimale, mais elle suffit à pré-mâcher le travail. La validation humaine reste indispensable.
La démonstration part d'un besoin simple. Florent Perez automatise l'audit de duplicate content en pilotant Screaming Frog via son interface CLI avec Claude Code. Tout tient dans un prompt structuré qui orchestre le workflow de bout en bout : crawl, extraction HTML, analyse multi-niveaux (lexicale + sémantique), scoring, puis génération de rapports exploitables.
Le cas pratique porte sur le site de Saint-Étienne Métropole. Pas de solution clé en main, donc, mais une méthode reproductible pour déléguer à l'IA une tâche chronophage sans lâcher le contrôle analytique.
Plusieurs paris soutiennent l'approche. Que Screaming Frog en CLI soit stable, que Claude Code gère correctement les dépendances Python sans supervision, et surtout que la détection duplicate content, même "non optimale" selon l'auteur, reste assez fiable pour prioriser l'analyse humaine.
Le vrai levier, c'est le gain de temps sur la phase de data processing : au lieu d'exporter, de nettoyer et de calculer à la main des similarités, on récupère des clusters et des scores prêts à examiner. L'arbitrage se résume à accepter une précision moindre contre une vélocité supérieure. Reste une limite : on ne sait rien des seuils de similarité retenus, ni de la pondération entre détection lexicale et sémantique.
Opinion L'auteur répète que sa méthode de détection n'est "clairement pas optimale" mais "largement suffisante". Posture saine, selon moi : trop de SEO poursuivent la perfection algorithmique alors qu'un tri basique règle déjà 80 % du problème. L'absence totale de transparence sur le scoring, en revanche, pose problème (quels seuils ? quelle distance de Levenshtein ou cosinus ?) et rend la solution difficile à calibrer sur des sites critiques.
À vérifier Le volume de pages attendu est estimé via site: dans Google. L'approximation est connue pour être imprécise : pages désindexées, canonicalisées, bloquées. Sur un gros site, l'écart peut atteindre 30 %. Un croisement avec les logs serveur ou Search Console vaudrait mieux.
Vécu Excellente recommandation, celle de créer des sous-dossiers crawl/ et output/. J'ai vu trop d'audits où Claude mélange fichiers temporaires et livrables finaux, ce qui rend l'historisation impossible. Cette discipline de nommage devrait être systématique dans tout workflow IA.
Le prompt fonctionne comme un cahier des charges séquentiel. Première étape : créer l'arborescence de travail, avec deux dossiers distincts (crawl/ pour les données brutes, output/ pour les livrables). Claude Code doit contrôler en amont que les dépendances Python sont bien présentes. Ce contrôle préventif évite les interruptions en cours d'exécution.
Méthode Screaming Frog doit être piloté en CLI (ligne de commande) et non via l'interface graphique : le prompt le précise explicitement, ce qui permet à Claude Code de scripter l'interaction directement. Le prompt fournit des "précisions concernant la manière dont Screaming Frog doit être utilisé". L'auteur ne détaille pas ces consignes, mais on devine des paramètres de crawl (profondeur, exclusions, stockage HTML).
Une estimation du volume du site à crawler figure aussi dans le prompt, obtenue via la commande site:domaine.fr dans Google. À vérifier La méthode donne un ordre de grandeur, pas un décompte précis : Google n'indexe pas toutes les pages découvertes, et certaines pages indexées peuvent être canonicalisées. L'auteur juge cela suffisant pour dimensionner le crawl.
Le prompt prévoit deux stratégies d'extraction et laisse Claude Code choisir selon le contexte. Première option : si Screaming Frog parvient à stocker correctement le HTML des pages crawlées, Claude Code exploite ces fichiers directement. C'est le chemin nominal.
Vécu "Ce n'est pas toujours le cas", précise l'auteur. Screaming Frog peut échouer à sauvegarder le HTML (problème de droits, de mémoire, de timeouts). La seconde option prend alors le relais : Claude Code bascule sur du scraping Python pour récupérer le contenu manquant. Redondance critique. Sans elle, l'audit s'arrête net à la première anomalie de crawl.
L'analyse repose sur quatre niveaux successifs :
Opinion L'auteur prévient : "ce n'est clairement pas une version optimale" de détection. Il le répète deux fois. Pour l'exemple traité, c'est selon lui "largement suffisant" et "déjà beaucoup mieux qu'un simple score basé sur l'étude de deux textes". Traduction : un compromis vitesse/précision, pas une référence pour des audits critiques.
Le site étant en français, le prompt demande à Claude Code d'employer des stop words français au pré-traitement. La détection lexicale y gagne en pertinence, puisqu'on élimine articles, conjonctions et mots-outils qui fausseraient les scores de similarité.
Deux fichiers sortent à la fin de l'audit :
Outil Un rapport Excel (.xls) contenant les données structurées. C'est le format à privilégier pour l'exploitation : filtres, tris. L'auteur y voit la "solution la plus utile" quand on veut traiter les résultats.
Outil Un fichier Markdown synthèse, deux pages maximum. Ce document offre une "vision en un clin d'œil de l'état du site". Il traduit en langage naturel les grandes conclusions : volumes, pourcentages, priorités. Couche de présentation, donc, pour non-praticiens ou pour une revue rapide.
L'auteur ouvre le fichier et en commente la structure. Le premier onglet liste les pages en duplicate strict versus duplicate proche. Dès les premières lignes de duplicate strict apparaissent des URLs quasi identiques avec des numéros qui changent à la fin, typiquement des pages de pagination ou des entrées d'agenda (concerts, événements) générées automatiquement.
Le deuxième onglet présente des clusters de pages similaires. Chaque cluster associe une "URL source" à un groupe de pages satellites, et le fichier affiche les titles de chaque URL pour faciliter l'identification visuelle. Vécu "Au vu des URLs, c'est potentiellement possible" que ces regroupements soient pertinents, note l'auteur, mais "il faudrait creuser". Claude Code pré-mâche le travail ; l'analyse humaine reste indispensable.
Un troisième onglet, non demandé dans le prompt, recense les pages à thin content (contenu maigre). L'auteur repère des pages avec "deux mots seulement". Opportunités d'enrichissement évidentes.
Le fichier Markdown affiche des métriques globales : nombre de pages visitées, nombre de pages en duplicate, et ces volumes traduits en pourcentages. Chiffre Ces ratios disent vite si "la situation est catastrophique ou pas hyper préoccupante".
Claude Code a aussi repéré les clusters prioritaires où concentrer d'abord l'effort de déduplication. Méthode La priorisation suit une logique 80/20 : traiter en premier les groupes de pages les plus problématiques pour maximiser l'impact avec un budget temps limité.
Vécu Sans qu'on le lui demande, Claude Code a généré une section "problèmes SEO" nourrie d'observations qualitatives : slugs contenant des numéros (signe de génération automatique mal maîtrisée), double catégorisation (une même URL accessible via /concert/ et /spectacle-concert/), et d'autres anomalies structurelles.
Un plan d'action priorisé clôt le document. Opinion L'auteur met en garde : "Ne posez pas votre cerveau en faisant confiance directement à Claude. Prenez le temps d'analyser tout ça." Les recommandations IA peuvent se tromper, tant sur la priorisation que sur les solutions proposées. Point de départ, pas vérité absolue.
Méthode Une règle revient sans cesse : une fois les rapports générés, vérifier manuellement chaque page signalée. Pour chaque ligne du tableau Excel, ouvrir l'URL source et l'URL cible, puis comparer visuellement le contenu réel. Claude Code détecte des patterns, pas la réalité éditoriale.
Cette validation est présentée comme non négociable. Le workflow complet : (1) Claude Code filtre et classe les milliers de pages, (2) l'humain examine les cas remontés, (3) décision et action corrective. L'IA réduit le périmètre d'analyse de 100 % à 5-10 %. Elle ne remplace pas le jugement.
Aucun détail sur les seuils de similarité retenus pour classifier "duplicate strict" vs "duplicate proche". Rien sur la pondération entre détection lexicale et sémantique dans le score final. Le modèle d'embedding utilisé pour l'analyse sémantique n'est pas précisé (sentence-transformers ? OpenAI ? Claude natif ?). Pas de chiffre non plus sur le temps d'exécution du crawl et de l'analyse pour le site de Saint-Étienne Métropole, ni de retour sur les faux positifs rencontrés ou le taux de précision observé après vérification manuelle. Les coûts ne sont jamais évoqués (tokens Claude, licence Screaming Frog CLI). Reste la question de la reproductibilité : le prompt fonctionne-t-il tel quel sur d'autres CMS, d'autres volumes, d'autres langues ?
Florent PEREZ