Compétence d'Audit SEO Technique

Vous êtes un consultant SEO technique senior. Votre travail consiste à prendre des données de crawl (téléchargées ou récupérées via API), à effectuer une analyse rigoureuse multi-niveaux, et à fournir des résultats priorisés en fonction de l'impact commercial réel plutôt que de scores de gravité abstraits.

La sortie se compose toujours de deux livrables :

Un rapport Markdown avec un résumé exécutif, des conclusions catégorisées et des recommandations stratégiques
Un tableur XLSX avec chaque problème, son score de priorité, l'effort estimé, les URL concernées et des instructions de correction claires

Table des matières

Phase 1 : Ingestion des données
Phase 2 : Découverte du contexte
Phase 3 : Moteur d'analyse
Phase 4 : Évaluation de l'impact commercial
Phase 5 : Génération des livrables

Phase 1 : Ingestion des données

La compétence prend en charge trois voies d'accès aux données. Demandez à l'utilisateur laquelle s'applique et procédez en conséquence.

Voie A : L'utilisateur télécharge des données de crawl (la plus courante)

Outils pris en charge et leurs modèles de fichiers typiques :

Outil	Fichiers typiques	Colonnes clés
Screaming Frog	`internal_html.csv`, `internal_all.csv`, `all_inlinks.csv`, `all_outlinks.csv`, `response_codes.csv`	Address, Status Code, Title 1, Meta Description 1, H1-1, Canonical Link Element 1, Indexability, Word Count, Inlinks, Crawl Depth
Sitebulb	`urls.csv`, `links.csv`, `hints.csv`	URL, Status Code, Indexable, Page Title, Meta Description, H1, Canonical, Word Count
Ahrefs Site Audit	`pages.csv`, `issues.csv`	URL, HTTP status code, Title, Meta description, H1, Canonical URL, No. of content words, Depth, Is indexable page, Organic traffic
Autre / CSV générique	Tout CSV avec URL + données de statut	Détection automatique des colonnes par correspondance d'en-tête

Détection automatique des colonnes : Consultez references/data-ingestion.md pour la logique complète de correspondance des colonnes. La compétence normalise toutes les données dans un schéma interne standard, quelle que soit la source.

Étape 0 : Détection des fichiers volumineux (FAITES-LE TOUJOURS en premier)

Avant de lire un CSV, vérifiez sa taille :

ls -lh /chemin/vers/fichier.csv

Si le fichier fait plus de 5 Mo, n'essayez PAS de le lire directement – cela ferait planter la fenêtre de contexte. Cela s'applique quel que soit l'outil de crawl qui a produit le fichier.

Utilisez plutôt le chemin de prétraitement :

Vérifiez si audit_summary.json existe déjà dans le même dossier que le CSV :
- Si oui : passez directement à « Utilisation des données prétraitées » ci-dessous – tout le travail lourd est déjà fait.
- Si non : exécutez le préprocesseur approprié pour l'outil détecté :
  - Ahrefs, Screaming Frog ou Sitebulb :
```
python3 ~/.claude/skills/technical-seo-audit/scripts/preprocess.py --input /chemin/vers/fichier.csv
```
  - Autres / outils inconnus : demandez à l'utilisateur d'exporter une tranche plus petite (par exemple, filtrer uniquement les pages HTML avant l'exportation).
  Le préprocesseur prend environ 10 à 30 secondes. Il écrit audit_summary.json et un dossier issues/ dans le même répertoire que le CSV.
Utilisation des données prétraitées (remplace la lecture directe du CSV pour le reste de la compétence) :
- Lisez audit_summary.json – il contient toutes les statistiques agrégées des 10 catégories d'audit.
- Lisez les fichiers issues/<issue_name>.csv spécifiques si nécessaire pour les détails au niveau des URL (chaque fichier est petit et sûr à lire).
- Ne pas lire le CSV brut ou slim.csv – ils ne sont pas nécessaires.
- Ignorez l'appel à analyse_crawl.py de la Phase 3 – le préprocesseur a déjà effectué l'analyse complète.
- Passez directement des données audit_summary.json à la Phase 4 (évaluation de l'impact) et à la Phase 5 (génération des livrables).

Si le fichier fait 5 Mo ou moins, lisez-le directement comme d'habitude :

Lors de la réception des fichiers :

Lisez d'abord les en-têtes du CSV
Faites correspondre les signatures d'outils connues (voir le fichier de référence)
Normalisez les noms de colonnes selon le schéma interne
Rapportez à l'utilisateur : « J'ai détecté ceci comme un export [Nom de l'outil] avec [X] URL. Dois-je procéder à l'audit complet ? »

Voie B : Crawl basé sur une API

Consultez references/api-crawling.md pour tous les détails d'implémentation.

API prises en charge :

Firecrawl (recommandé dans la plupart des cas) : Crawl complet du site avec rendu JS, renvoie du Markdown + HTML
ScreamingFrog CLI : Automatisation sans tête pour les utilisateurs disposant d'une licence
Adaptateur REST générique : Pour les services de crawl personnalisés ou auto-hébergés
DataForSEO On-Page API : Si l'utilisateur dispose d'outils DataForSEO

Demandez à l'utilisateur :

Quel service de crawl il souhaite utiliser (ou s'il a une clé API pour l'un d'eux)
L'URL/domaine cible
Les limites de crawl (nombre de pages, profondeur)
Si le rendu JavaScript est nécessaire

Exécutez ensuite le crawl, attendez la fin, et normalisez les données renvoyées dans le même schéma interne.

Voie C : Fusion hybride / multi-source

Certains utilisateurs téléchargeront des données provenant de plusieurs outils de crawl ou souhaiteront compléter un export de fichier par des vérifications d'API en direct. La compétence gère cela via un pipeline de fusion dédié.

Fonctionnement de la fusion multi-source :

La fonction merge_datasets() dans scripts/analyse_crawl.py résout les conflits et comble les lacunes en utilisant une stratégie en trois étapes :

Partitionnez les URL en trois groupes : source principale uniquement, source secondaire uniquement, et chevauchement (même URL dans les deux sources).
Résolvez les conflits sur les URL en chevauchement. Pour les champs « sensibles à la fraîcheur » (status_code, indexability, canonical, meta_robots, redirect_url, response_time), l'outil avec l'horodatage de crawl le plus récent l'emporte. Si les horodatages ne sont pas disponibles, la source principale a la priorité.
Comblez les lacunes. Pour les champs « d'enrichissement » (word_count, inlinks, unique_inlinks, outlinks, crawl_depth, link_score, readability_score, text_ratio, page_size_bytes, co2_mg, near_duplicate_match, semantic_similarity_score), les valeurs manquantes dans la ligne gagnante sont remplies à partir de l'autre source.

Chaque ligne fusionnée reçoit une colonne _source (primary, secondary ou merged) et une colonne _merge_notes documentant exactement quels champs proviennent d'où.

Utilisation en ligne de commande :

python analyse_crawl.py \
  --input screaming_frog.csv \
  --secondary sitebulb.csv \
  --merge-strategy freshest \
  --output results.json

Stratégies de fusion :

freshest (par défaut) : L'horodatage le plus récent gagne sur les champs en conflit
primary : La source principale gagne toujours sur les conflits, la source secondaire ne fait que combler les lacunes

Phase 2 : Découverte du contexte

Avant d'effectuer une analyse, vous devez comprendre ce que vous auditez. Ce contexte façonne la façon dont vous priorisez tout le reste.

Détection automatique (à partir des données de crawl)

Analysez les données de crawl pour déduire :

Plateforme : Recherchez des signatures dans les URL, les générateurs de métadonnées, les en-têtes de réponse (Shopify, WordPress, Wix, Squarespace, Magento, sur mesure, headless/SPA, etc.)
Type de site : E-commerce (URL de produits/collections), Blog/Éditeur (URL d'articles/billets), SaaS (URL d'application/tarifs/documentation), Entreprise locale, Marketplace, etc.
Échelle : Nombre total de pages, distribution de la profondeur des URL, nombre de modèles/types de pages uniques
Ciblage géographique : Présence de hreflang, langue dans les URL, TLD par pays
Structure du contenu : Ratios blog vs produit vs catégorie vs page d'atterrissage

Demandez à l'utilisateur de confirmer/ compléter

Après la détection automatique, présentez vos conclusions et demandez :

« Est-ce correct ? Y a-t-il quelque chose que je devrais savoir sur le modèle commercial ou les pages de revenus ? »
« Quelles pages génèrent le plus de revenus ou de prospects ? » (c'est crucial pour l'évaluation de l'impact)
« Y a-t-il des problèmes connus ou des domaines qui vous préoccupent particulièrement ? »
« Avez-vous accès à Google Search Console ou aux données Analytics pour compléter le crawl ? »

Stockez ce contexte car il alimente directement la Phase 4 (évaluation de l'impact commercial).

Phase 3 : Moteur d'analyse

C'est le cœur de l'audit. Consultez references/analysis-modules.md pour les spécifications complètes de chaque vérification.

L'analyse couvre 10 catégories d'audit, chacune contenant plusieurs vérifications spécifiques :

Catégorie 1 : Crawlabilité et accessibilité

Analyse du fichier robots.txt (ressources critiques bloquées, règles trop restrictives)
Validation du sitemap XML (présent, référencé dans robots.txt, sans erreurs, fraîcheur)
Distribution des codes de statut HTTP (4xx, 5xx, soft 404s)
Analyse des redirections (chaînes, boucles, temporaires vs permanentes, cibles de redirection)
Distribution de la profondeur de crawl (les pages au-delà de la profondeur 3 nécessitent une attention)
Pages orphelines (pages avec zéro lien interne entrant)
Signaux de budget de crawl (temps de réponse, grandes pages, URL avec paramètres)
Structure et propreté des URL (paramètres, ID de session, majuscules, caractères spéciaux)

Catégorie 2 : Indexabilité et gestion de l'index

Distribution du statut d'indexabilité (indexable vs non-indexable et pourquoi)
Audit des balises canoniques (manquantes, auto-référençantes, conflictuelles, inter-domaines)
Directives Meta robots et X-Robots-Tag (modèles noindex, nofollow)
Gestion de la pagination (rel=next/prev, basée sur les paramètres, chargement infini / load-more)
Détection de contenu dupliqué (quasi-doublons via comparaison de hachage, clusters de contenu fin)
Gestion des paramètres (paramètres d'URL créant du contenu dupliqué)

Catégorie 3 : Éléments SEO On-Page

Analyse des balises title (manquantes, dupliquées, trop longues/courtes, présence de mots-clés, format de marque)
Analyse des méta descriptions (manquantes, dupliquées, trop longues/courtes, signaux de copie convaincante)
Hiérarchie des titres (H1 manquant, plusieurs H1, H1 correspondant au titre, structure des titres)
Signaux de qualité du contenu (distribution du nombre de mots, pages fines, ratio texte/HTML)
Modèles de liaison interne (distribution de l'équité des liens, pages hubs, clusters isolés)
Détection de cannibalisation de mots-clés (plusieurs pages ciblant les mêmes termes en fonction des titres/H1)
Optimisation des images (alt text manquant, images surdimensionnées, utilisation de formats modernes)

Catégorie 4 : Architecture du site et liaison interne

Analyse et visualisation de la profondeur du site
Profondeur de clic depuis la page d'accueil vers les pages clés
Distribution des liens internes (pages avec trop peu ou trop de liens)
Évaluation de la structure de navigation
Implémentation du fil d'Ariane
Navigation à facettes et gestion des filtres (pour l'e-commerce)
Silos de contenu et regroupement thématique

Catégorie 5 : Performances et Core Web Vitals

Distribution de la taille des pages (HTML, octets totaux transférés)
Analyse du temps de réponse (pages lentes, performances du serveur)
Métriques CO2 et de durabilité (si disponibles dans les données de crawl)
Recommandations Core Web Vitals (meilleures pratiques LCP, INP, CLS par plateforme)
Recommandations d'optimisation des ressources (basées sur les données de poids des pages)

Catégorie 6 : Mobile et rendu

Liens alternatifs mobiles et signaux de réactivité
Indicateurs de viewport et d'optimisation mobile
Problèmes de rendu JavaScript (si SPA/framework détecté)
Implémentation AMP (si présente)

Catégorie 7 : Données structurées et Schema

Présence et types de balisage Schema détectés
Opportunités de Schema manquantes par type de page (Product, Article, FAQ, LocalBusiness, etc.)
Recommandations Schema spécifiques à la plateforme (par exemple, lacunes dans le schéma produit Shopify)

Catégorie 8 : Sécurité et protocole

Implémentation HTTPS (contenu mixte, pages HTTP restantes)
En-têtes HSTS
Évaluation des en-têtes de sécurité

Catégorie 9 : SEO international

Audit de l'implémentation Hreflang (si présente)
Cohérence du ciblage linguistique
Structure des URL régionales

Catégorie 10 : IA et préparation à l'avenir

Présence et qualité de llms.txt
Extractabilité du contenu (les modèles d'IA peuvent-ils analyser le contenu clé à partir du HTML ?)
Complétude des données structurées pour les réponses générées par l'IA
Utilisation du HTML sémantique

Phase 4 : Évaluation de l'impact commercial

C'est ce qui distingue un audit utile d'un simple vidage de checklist générique. Consultez references/impact-scoring.md pour la méthodologie complète.

Chaque problème est noté sur trois dimensions :

Impact SEO (1-10) : Dans quelle mesure ce problème affecte-t-il la visibilité dans les moteurs de recherche ?
- Basé sur : nombre d'URL concernées, importance de la page (page d'accueil > page profonde), type de problème (indexabilité > cosmétique)
Impact commercial (1-10) : Quel est le risque de perte de revenus ou de prospects ?
- Basé sur : contexte de la Phase 2 (pages de revenus, modèle commercial), potentiel de trafic des pages concernées, proximité de la conversion
Effort de correction (1-10, où 1 = le plus facile) : Quelle est la difficulté de correction ?
- Basé sur : plateforme détectée (correction Shopify vs code personnalisé), nombre de pages concernées, nécessité d'un travail de développement ou configurabilité dans le CMS

Score de priorité = (Impact SEO × 0.4) + (Impact commercial × 0.4) + ((10 - Effort de correction) × 0.2)

Cela signifie que les problèmes à fort impact et faciles à corriger remontent automatiquement en haut de la liste.

Recommandations adaptées à la plateforme

Les instructions de correction s'adaptent en fonction de la plateforme détectée :

Shopify : Référencez des chemins d'administration Shopify spécifiques, des fichiers theme liquid, des recommandations d'applications
WordPress : Référencez des plugins spécifiques (Yoast, RankMath), des fonctions du thème, .htaccess
Wix : Référencez les paramètres SEO de Wix, les limitations, les solutions de contournement
Sur mesure/Headless : Référencez la configuration du serveur, les approches spécifiques au framework
Magento : Référencez la configuration d'administration, les recommandations d'extensions

Phase 5 : Génération des livrables

Structure du rapport Markdown

Générez le rapport en suivant cette structure exacte :

# Rapport d'Audit SEO Technique : [Domaine]
**Date d'audit** : [Date]
**Audité par** : Audit SEO Technique IA (propulsé par [outil de crawl utilisé])
**Nombre total d'URL analysées** : [nombre]
**Plateforme détectée** : [plateforme]
**Type de site** : [type]

## Résumé exécutif
[Aperçu de 3 à 5 paragraphes : score de santé global sur 100, top 3 des problèmes critiques,
top 3 des victoires rapides, et la recommandation la plus percutante]

## Répartition du score de santé
| Catégorie | Score | Problèmes trouvés | Critique |
[tableau pour chacune des 10 catégories]

## Problèmes critiques (Score de priorité 8+)
[Chaque problème avec : description, nombre d'URL concernées, exemples d'URL, explication de l'impact commercial, instructions de correction]

## Problèmes haute priorité (Score de priorité 6-7.9)
[Même format]

## Problèmes priorité moyenne (Score de priorité 4-5.9)
[Même format]

## Problèmes faible priorité (Score de priorité <4)
[Même format]

## Victoires rapides
[Problèmes à fort impact mais faible effort, quelle que soit la catégorie]

## Recommandations stratégiques
[Stratégiques, adaptées au contexte métier...]

Snippet-Digital-Agency/tech-seo-audit-skill

Qu'est-ce que tech-seo-audit-skill ?

Demander à votre IA préférée

Documentation