seo-audit — Audit SEO de base
Une compétence d'agent SEO légère conçue pour des audits SEO rapides par page unique par défaut. Propulsée par OpenClaw. Adaptée pour des vérifications de page initiales ou lorsqu'une évaluation rapide est nécessaire sans profondeur technique complète.
Quand utiliser cette compétence
Utilisez seo-audit lorsque :
- L'utilisateur dit : « audite cette page », « vérifier le SEO », « analyser mon URL », « vérification SEO rapide », « qu'est-ce qui ne va pas avec ma page »
- Aucune profondeur spécifique n'est demandée — c'est le point d'entrée par défaut
- L'utilisateur a besoin d'un résumé rapide et lisible plutôt que d'une analyse technique complète
Si l'utilisateur souhaite plus de profondeur, passez à seo-audit-full :
Astuce : Pour des audits techniques approfondis, un SEO on-page avancé ou des rapports complets, utilisez la compétence
seo-audit-full.
Entrée attendue
| Entrée | Requis | Notes |
|---|---|---|
| URL de la page | Oui | La page à auditer |
| HTML brut ou contenu de la page | Optionnel | Permet une analyse on-page plus précise |
| Données GSC / analytics | Optionnel | Non requis pour l'audit de base |
Si seule une URL est fournie et qu'aucun code source ou donnée de crawler n'est disponible, indiquez clairement :
Limitation : Cet audit est basé uniquement sur le contenu visible de la page et les signaux disponibles publiquement. Le code source, les données GSC, les journaux de crawl et les métriques de performance ne sont pas disponibles pour cet audit.
Sortie
Produisez un Rapport d'audit SEO de base en remplissant le modèle à assets/report-template.html, puis enregistrez-le dans un fichier — n'imprimez jamais le HTML brut dans le terminal.
Nom du fichier : reports/<hostname>-<slug>-audit.html
https://example.com/blog/best-tools → reports/example-com-blog-best-tools-audit.html
https://example.com/ → reports/example-com-audit.html
Après l'enregistrement, dites à l'utilisateur :
✅ Rapport enregistré → reports/example-com-audit.html
L'ouvrir maintenant ? (oui / non)
Si oui → exécutez : open reports/example-com-audit.html
Emplacements réservés du modèle — remplissez chacun indépendamment :
| Emplacement | Contenu |
|---|---|
{{summary_verdict}} | Une phrase : nombre total de contrôles exécutés, combien d'échecs/avertissements/réussites |
{{summary_critical_html}} | <li> par élément critique (échec), ou <li class="summary-empty">Aucun</li> |
{{summary_warnings_html}} | <li> par élément d'avertissement, ou <li class="summary-empty">Aucun</li> |
{{summary_passing_html}} | <li> par contrôle réussi, ou <li class="summary-empty">Aucun</li> |
Scripts
Exécutez ces scripts avant de rédiger des conclusions. Ils produisent du JSON structuré — utilisez le JSON directement comme preuve ; ne refetch pas les mêmes URLs manuellement.
Dépendances : pip install requests (l'analyse HTML utilise la bibliothèque standard Python)
# Étape 1 : contrôles au niveau du site (robots.txt + sitemap.xml)
python scripts/check-site.py https://example.com
# Étape 2 : contrôles au niveau de la page (H1, titre, méta description, canonical)
python scripts/check-page.py https://example.com
# Avec mot-clé principal (recommandé — active la vérification de la présence du mot-clé dans le H1)
python scripts/check-page.py https://example.com --keyword "running shoes"
# Optionnel : récupérer le HTML brut de la page pour une inspection plus poussée
python scripts/fetch-page.py https://example.com --output page.html
# Étape 3 : validation du schéma JSON-LD
python scripts/check-schema.py https://example.com
# Ou à partir du HTML précédemment récupéré (évite une récupération redondante) :
python scripts/check-schema.py --file page.html
Chaque script se termine avec le code 0 (tout passe/avertissement) ou 1 (tout échec/erreur).
PÉRIMÈTRE STRICT — n'ajoutez aucun contrôle non listé ci-dessous. Aucune exception.
Contrôles autorisés au niveau du site (dans {{site_checks_html}}) :
- robots.txt · sitemap.xml · Gestion 404 · Canonicalisation d'URL · i18n / hreflang
Contrôles E-E-A-T autorisés (dans {{eeat_checks_html}}) :
- À propos · Contact · Politique de confidentialité · Conditions d'utilisation · Médias/Partenaires (uniquement si présents)
Contrôles autorisés au niveau de la page (dans {{page_checks_html}}), sortie dans cet ordre exact :
Slug URL · Balise Titre · Méta Description · Balise H1 · Balise Canonical · Texte Alt des images · Nombre de mots · Placement des mots-clés · Structure des titres · Liens internes · Schema (JSON-LD)
Logique du Texte Alt des images :
- Analyser les balises <img> du HTML statique
- Réussi : toutes les images ont un alt non vide (les images décoratives avec alt="" sont OK)
- Avertissement : toute image de contenu sans attribut alt
- Non vérifié (statut-info) : 0 images trouvées dans le HTML statique → probablement générées par JS, impossible de vérifier
⛔ RÈGLE ABSOLUE — Sortez UNIQUEMENT les lignes de contrôle définies dans report-template.html. Si un contrôle ne figure pas dans les listes autorisées ci-dessus, ne le sortez PAS — même si vous trouvez des problèmes. Aucune exception. Pas de contrôles "bonus". Pas d'improvisation. Le modèle est la source unique de vérité. Traitez-le comme une liste blanche stricte.
Toujours INTERDITS (appartiennent à seo-audit-full) : balises OG · Twitter Card · Balises sociales · Poids de la page · Core Web Vitals · Robots Meta
Comment utiliser la sortie JSON :
- Mappez chaque
statusde champ →pass/warn/fail/errordirectement dans le tableau de contrôle du rapport - Utilisez la chaîne
detailde chaque champ comme point de départ pour la ligne de Preuve dans les conclusions - Ne contredisez pas la sortie du script à moins d'avoir des preuves observables supplémentaires
- Séparez les groupes de contrôle avec
<div class="subsection-label">Étiquette</div>à l'intérieur de{{site_checks_html}}:Explorabilité·Canonicalisation d'URL·i18n / hreflang·Schema (JSON-LD)et<div class="subsection-label">Pages de confiance E-E-A-T</div>avant{{eeat_checks_html}}
Révision LLM — obligatoire lorsque llm_review_required: true :
Le script signale les champs qui nécessitent un jugement sémantique ou de qualité qu'il ne peut pas effectuer.
Ne laissez jamais llm_review_required: true non résolu — faites toujours un appel de jugement explicite.
H1 — déclenché lorsque keyword_match == "partial" :
h1_text : (from h1.values[0])
keyword : (the --keyword passed to the script)
Jugez : Ce H1 couvre-t-il sémantiquement l'intention de recherche du mot-clé ?
- Considérez les synonymes, les variantes naturelles, la couverture du sujet
- oui → rétrogradez à "pass", notez la variante
- non → gardez "warn" ou passez à "fail", expliquez l'écart
Titre — déclenché lorsque keyword_match == "partial" OU keyword_position != "start" :
title : (from title.value)
keyword : (the --keyword passed)
Jugez :
1. Le titre couvre-t-il sémantiquement l'intention de recherche du mot-clé ?
2. Le titre est-il grammaticalement correct et naturellement lisible ?
3. Position du mot-clé — appliquez des normes différentes selon le type de page :
- Page d'accueil : Marque + mot-clé principal est correct (ex. "Acme | Automatisation de flux de travail IA")
Ne signalez PAS la marque en premier comme un problème.
- Pages internes : Le mot-clé principal doit être en tête (ex. "Automatisation de flux de travail IA pour les équipes — Acme")
Signalez si le mot-clé est enfoui au milieu du titre sans bonne raison.
IMPORTANT — ne signalez PAS ces éléments comme négatifs :
- Années (ex. "2026") → signal de fraîcheur, augmentent le CTR — considérez comme positif à moins que
la page soit explicitement un contenu permanent où la datation nuirait à la longévité.
- Chiffres (ex. "5 meilleurs", "Top 10", "3 étapes") → établissent des attentes claires,
surpassent constamment les titres non numériques en CTR — toujours considérer comme un plus.
- Qualificatifs spécifiques ("Open-Source", "Auto-hébergé", "Gratuit") → réduisent l'intention
et attirent des clics de meilleure qualité — ne pénalisez pas.
Slug URL — déclenché lorsque keyword_match != "full" ou is_homepage == false :
slug : (from url_slug.slug)
keyword : (the --keyword passed)
Jugez :
1. Le slug contient-il le mot-clé principal ou une variante naturelle ?
2. La hiérarchie du chemin est-elle logique ? (/catégorie/mot-clé est idéal)
3. Est-il concis et lisible par l'homme ?
Page d'accueil (is_homepage: true) : passez — aucun jugement nécessaire.
Méta Description — toujours déclenchée lorsque le contenu est présent :
meta_description : (from meta_description.value)
keyword : (the --keyword passed)
Jugez les quatre :
1. Phrase(s) complète(s) ? (1-2 phrases, pas de fragments)
2. Mentionne un résultat concret — pas de blabla vague ?
Bon : "Réduisez le temps de conception de 60 % avec des modèles alimentés par l'IA"
Mauvais : "Le meilleur outil pour tous vos besoins de conception"
3. Mot-clé ou synonyme naturel utilisé une fois — pas de bourrage ?
4. Plus spécifique que ce qu'un concurrent typique écrirait ?
IMPORTANT — ne signalez PAS ces éléments comme négatifs :
- Années (ex. "2026") → signal de fraîcheur, améliorent le CTR pour les requêtes temporelles.
Notez l'année uniquement si la page est explicitement un contenu permanent où la datation nuit.
- Chiffres (ex. "5 meilleurs", "3 étapes") → spécificité concrète, signal fort de CTR.
- "et plus." à la fin → note de style mineure au plus, jamais un Avertissement ou un Échec.
Flux de travail recommandé
Suivez ces étapes dans l'ordre :
-
Reconnaître la portée — confirmez qu'il s'agit d'un audit de base ; notez toute donnée manquante
-
Déduire le mot-clé principal — récupérez la page avec
fetch-page.py, puis déterminez le mot-clé principal :- Si l'utilisateur a explicitement fourni un mot-clé → utilisez-le directement
- Sinon → lisez le H1 de la page, le titre et le premier paragraphe, puis déduisez l'expression de mot-clé cible la plus probable (que taperait un internaute pour trouver cette page ?)
- Indiquez explicitement le mot-clé déduit avant d'exécuter les contrôles :
"Mot-clé principal déduit : alternatives open source à claude"
-
Exécutez
check-site.py— analysez la sortie JSON pour robots, sitemap, gestion 404 et canonicalisation d'URLContrôle 404 : récupérez
<origin>/this-page-definitely-does-not-exist-seo-audit-check- Renvoie 404 → Réussi · Renvoie 200 (soft 404) → Échec · Renvoie 301 vers la page d'accueil → Avertissement
Contrôles de canonicalisation d'URL (chacun est un sous-contrôle distinct) :
- HTTP→HTTPS : récupérez
http://<host>— doit rediriger 301 vershttps://. Renvoie 200 → Échec. - Cohérence www : récupérez
https://www.<host>ethttps://<host>— l'un doit rediriger 301 vers l'autre. Les deux renvoient 200 → Avertissement. - Slash final : comparez l'URL réellement servie avec la balise canonical de la page. Discordance → Avertissement.
- Correspondance canonical : l'attribut href de la balise canonical doit correspondre exactement à l'URL finale après toutes les redirections. Discordance → Avertissement.
-
Contrôle de l'infrastructure E-E-A-T — pour chaque page de confiance ci-dessous, vérifiez deux niveaux :
- Niveau 1 — Existe : récupérez l'URL, vérifiez le statut HTTP (200 = existe, 404/redirection = manquant)
- Niveau 2 — Accessible : récupérez le HTML de la page d'accueil, vérifiez si le pied de page ou la navigation contient un lien vers cette page
Page Requis À propos Oui Contact Oui Politique de confidentialité Oui Conditions d'utilisation Oui Médias / Partenaires Non — inclure uniquement si présent Règles de statut :
- Page manquante (non-200) → Échec
- La page existe mais n'est pas liée dans le pied de page/la navigation → Avertissement
- La page existe et est liée dans le pied de page/la navigation → Réussi
- Page optionnelle manquante → passez, n'incluez pas de ligne
-
Exécutez
check-page.py --keyword "<mot_clé_déduit>"— analysez la sortie JSON pour H1, titre, méta description, canonical et slug URL -
Contrôle i18n / hreflang — exécutez uniquement si la page contient des balises hreflang ou si
<html lang>suggère un multilinguisme :- Ignorer complètement (N/A) si aucune balise hreflang trouvée et que le site semble monolingue
- Si des balises hreflang sont présentes, vérifiez :
- Symétrie réciproque : chaque URL référencée doit renvoyer vers toutes les autres variantes — tout lien rompu = Échec
- Codes de langue : doivent être valides BCP 47 (ex.
zh-CNpaszh,en-USpasen-us) — code erroné = Avertissement - x-default : devrait être présent pour les pages de sélection de langue ou de repli — manquant = Avertissement
- Attribut html[lang] : doit correspondre au hreflang principal de la page — discordance = Avertissement
- Structure d'URL : modèle recommandé — langue par défaut (généralement
en) à la racine sans préfixe, autres langues sous des sous-chemins (/zh/,/es/)./page(en) +/zh/page+/es/page→ Réussi/en/page+/zh/page→ Avertissement (le préfixe en est redondant, gaspille la profondeur de crawl)- Signalez uniquement si le schéma est clairement incohérent ou si en est préfixé inutilement
-
Exécutez
check-schema.py— analysez la sortie JSON pour les types de schéma et la validation des champspython scripts/check-schema.py https://example.com # Ou à partir du HTML précédemment récupéré : python scripts/check-schema.py --file page.htmlLe script extrait les blocs JSON-LD, valide
@typeet les champs requis selon la spécification Schema.org.llm_review_required: trueest toujours défini — confirmez queinferred_page_typecorrespond au contenu réel de la page.Type de page → référence
@typeattendue :Type de page @type attendu Champs minimaux requis Page d'accueil WebSite + Organization name, url, logo Blog / Article Article ou BlogPosting headline, datePublished, author, image Produit Product name, image, offers (price, priceCurrency) FAQ FAQPage mainEntity[].name, acceptedAnswer.text Comment faire HowTo name, step[].text Entreprise locale LocalBusiness name, address, telephone Page d'atterrissage générique — N/A — passez, aucun type largement pris en charge - Réussi : @type correct présent, tous les champs requis valides, pas de conflits
- Avertissement : @type présent mais champs recommandés manquants
- Échec : @type attendu totalement absent
- N/A : page d'atterrissage générique — ne pénalisez pas
-
Résumez les conclusions — chaque conclusion doit suivre le format Preuve / Impact / Correction
-
Actions prioritaires — listez les 3 principales corrections à fort impact
-
Générez le rapport — enregistrez dans
reports/<hostname>-<slug>-audit.html, puis demandez à l'utilisateur d'ouvrir -
Invite de mise à niveau — si des problèmes au-delà de la portée de base sont trouvés, suggérez
seo-audit-full
Règles de rédaction des détails du rapport
La cellule Détail dans les tableaux de contrôle doit suivre ces règles — aucune exception :
Réussi → une phrase courte. Pas de listes, pas d'élaboration.
Bon : "Jeu d'URLs XML valide · 104 URLs · référencé dans robots.txt."
Mauvais : "Jeu d'URLs XML valide avec 104 URLs. Correctement référencé dans robots.txt.
Les articles de blog sont probablement indexés via ce sitemap."
Avertissement → un <div class="detail-issue"> avec ≤2 points. Un <div class="detail-fix"> avec la correction.
Bon :
<div class="detail-issue">· Titre 48 caractères — 2 en dessous du minimum. · L'année "2026" va dater la page.</div>
<div class="detail-fix">Étendez à 50–60 caractères ; supprimez l'année si le contenu est permanent.</div>
Mauvais : une prose de trois phrases expliquant ce qu'est une balise titre et pourquoi la longueur est importante.
Échec → comme Avertissement. Commencez par l'échec exact. Pas d'explications de fond.
N'expliquez PAS ce qu'est un contrôle, NE répétez PAS les informations déjà visibles dans le badge de statut, ne traitez PAS le lecteur comme peu familier avec les bases du SEO.
Format obligatoire des conclusions
Chaque conclusion importante doit suivre cette structure :
**Conclusion : [Titre de la conclusion]**
- **Preuve :** [Ce qui a été observé — citation directe, référence de capture d'écran ou données mesurables]
- **Impact :** [Pourquoi cela est important pour le SEO ou l'UX]
- **Correction :** [Recommandation spécifique et actionnable]
Ne rédigez pas de conclusions vagues. Si les preuves sont insuffisantes, mentionnez explicitement les hypothèses.
Invite de mise à niveau
Incluez ceci à la fin de chaque rapport d'audit de base :
Vous voulez une analyse plus approfondie ? Ceci était un audit SEO de base couvrant les signaux au niveau du site et les contrôles on-page essentiels. Pour un SEO technique avancé, une notation de la qualité du contenu, une analyse des données structurées et des conclusions complètes basées sur le crawl, utilisez la compétence
seo-audit-full.
Fichiers de référence
- Portée de l'audit détaillée et définitions des champs : references/REFERENCE.md
- Modèle de rapport HTML final : assets/report-template.html
- Script de contrôle au niveau du site : scripts/check-site.py
- Script de contrôle au niveau de la page : scripts/check-page.py
- Récupérateur de page brute : scripts/fetch-page.py
- Script de validation de schéma : scripts/check-schema.py


