lcrvl2 seo-audit-manual — Vérifications manuelles SEO
Couvre l'intégralité de la méthode (references/process.md, copie fidèle de la spec phase 6). Produit findings/manual.json.
Architecture hybride — deux couches, aucun process omis
- Couche script (
scripts/analyze.py) : les vérifs HTTP/parsing mécanisables — code 404 / soft 404 (6.6-6.7), SSL/TLS négocié via socket (6.8), redirect HTTP→HTTPS (6.9), viewport mobile + indices responsive (6.10), robots.txt/sitemap accessibilité + validation XML + nb URLs, pages HTTP/sensibles/5xx depuis le crawl. Vérifs réelles (pas un comptage du crawl local). - Couche agent (CE SKILL.md) : les search operators (6.1-6.4, via WebSearch sur l'index Google réel) et les jugements (sévérité d'un staging exposé, UX de la page 404, contenu de robots/sitemap). Listés dans
to_judgeavec les requêtes exactes prêtes à lancer.
Le script ne peut pas interroger l'index Google (
site:/inurl:) → il prépare les requêtes exactes et l'agent les lance. Il ne marque jamais tout staging/dev en critique : la sévérité est un jugement agent (contenu dupliqué/données sensibles = critique ; outil interne = moyen ; beta public = faible).
Procédure de l'agent
Étape 1 — Lancer le socle script
python seo/skills/seo-audit-manual/scripts/analyze.py <slug>
python seo/skills/seo-audit-manual/scripts/analyze.py <slug> --offline # sans vérifs HTTP/TLS
Étape 2 — Exécuter les to_judge
6.1 Staging/dev/test/beta (site:domain inurl:staging etc.) : lancer chaque requête (WebSearch), lister les URLs indexées. Évaluer la sévérité par URL : CRITIQUE si contenu dupliqué de la prod OU données sensibles (clés API, identifiants, docs internes, dashboards) ; MOYEN si outil interne indexé (Storybook…) ; FAIBLE si beta public intentionnel ou déjà noindex. Ne PAS tout marquer critique.
6.2 Admin/login (inurl:admin etc.) : lister les URLs ; déterminer si elles devraient être en noindex/nofollow ; évaluer le risque d'exposition.
6.3 Contenu daté (intitle:[année-1/-2/-3], années déjà calculées dans to_judge) : par URL → encore pertinent (année-1) / à mettre à jour (année-2) / obsolète (année-3). Si evergreen, recommander de retirer l'année du titre.
6.4 URLs à paramètres (inurl:? inurl:utm_ etc.) : si trouvées, recommander canonical ou param handling GSC.
6.5 Page 404 UX : WebFetch une URL inexistante. PASS (404 custom avec branding + nav + recherche + lien accueil) / PARTIAL (404 basique) / FAIL (soft 404 ou pas de page custom). Le code HTTP est déjà vérifié par le script.
robots.txt / sitemap content : depuis checks.robots_txt/checks.sitemap, juger le contenu : pages importantes bloquées ?, staging/dev bloqués ?, sitemap référencé (déjà détecté) ?, bots LLM gérés (cross-ref avec geo) ?, URLs du sitemap à jour ?.
Étape 3 — (Quand DataForSEO SERP est branché) SERP live 6.12-6.13
Tant que collecte_a_brancher, affiché "à venir". Quand branché : top 5 KW par clics (GSC) → serp_organic_live_advanced (depth 20). Position live vs GSC (écart), featured snippet + owner, PAA + inclusion client, local pack + inclusion, rangs concurrents 1/2/3. Flags : client > tous concurrents ; concurrents ont une SERP feature pas le client ; concurrent page 1 et client absent. Fallback directionnel : WebSearch.
Étape 4 — Émettre les findings de jugement
Pour chaque problème jugé (staging critique exposé, 404 FAIL, contenu obsolète…), ajoute un finding au format unifié dans manual.json. Conserve les id stables du script.
Données requises
- Crawl (raw.json) : obligatoire.
- Vérifs HTTP/TLS live : socket + urllib (sauf
--offline). - WebSearch : pour les search operators (l'agent l'exécute).
- DataForSEO SERP live : 6.12-6.13 →
collecte_a_brancher(WebSearch en fallback).
Contrat
Entrée : réserve crawl + vérifs live. Sortie : findings/manual.json (checks + to_judge + findings). Voir references/process.md et seo-os/references/data-contract.md.
Sur Hermes
Profil-worker seo-manual, carte parents=[seo-collect], parallèle aux autres analyses. Les search operators (WebSearch) et le jugement UX tournent dans le worker.