audit — l'audit trimestriel

audit — le crawl trimestriel

analysis voit le dépôt ; audit voit ce qu'un visiteur et un crawler voient : le HTML en direct, les vrais codes de statut, les redirections, le sitemap tel qu'il est servi. Tout ce qu'il trouve devient soit un élément de backlog que le skill fix peut exécuter mécaniquement, soit une ligne dans la liste des propriétaires pour les choses qu'aucun skill ne doit toucher (navigation, mises en page, pages de tarification et juridiques, hébergement). Il ne modifie jamais un article et n'ouvre jamais de PR.

Scripts : ${CLAUDE_PLUGIN_ROOT}/scripts/{crawl,inventory,sitecheck}.js. Définissez P=${CLAUDE_PLUGIN_ROOT}.

Arguments : --origin <url> (par défaut : https://<domain> depuis seo/brand.json, sinon l'hôte de la ligne Preview), --max <n> pages (500), --external <n> liens externes à vérifier (200), --cwv (interroger PageSpeed Insights pour la page d'accueil et les hubs de cluster ; nécessite un accès réseau à googleapis.com, PAGESPEED_API_KEY facultatif), --no-items (rapport uniquement, rien n'écrit dans le backlog), --dry-run (crawl et rapport, rien n'est commité).

0. Préconditions

Racine du dépôt produit ; git status --porcelain vide ; sur la branche par défaut ; seo/strategy.md et le bloc ## SEO agent existent. node $P/scripts/inventory.js --root . d'abord pour que le crawl puisse mapper les chemins vers les fichiers et les types. Pas besoin de gh.

1. Crawl

PREV=$(ls seo/data/crawl/*.json 2>/dev/null | sort | tail -1)
node $P/scripts/crawl.js --root . --origin <origin> --max <n> --external <n> [--cwv] --save seo/data/crawl ${PREV:+--diff $PREV} --quiet

Lisez le JSON : summary (pages, constats par code, truncated), findings[] (code, severity fix|report, path, file, msg, to), sitemap (count, error, missing), external[], cwv[], diff (new, resolved depuis l'audit précédent). Une clé error au niveau supérieur ou sitemap.error → dites-le et arrêtez ; un site qui est hors ligne est le problème du propriétaire, pas un élément de backlog. truncated: true → dites que le crawl a atteint --max et quels chemins étaient encore en file d'attente.

Exécutez aussi node $P/scripts/sitecheck.js --root . : il voit la source (arguments Blade, routes, frames) que le HTML en direct cache, et les deux ensemble donnent une image complète.

2. Triage

Trois catégories, dans cet ordre :

1. Éléments fix — constats avec severity: fix (codes title, description, canonical, alt, link, sitemap) sur une page dont l'entrée d'inventaire a un file de type guide, article ou outil. Un élément par page, exactement comme écrits dans analysis §1c, avec deux différences : - evidence: audit <date>: <n> findings et chaque ligne fixes: se termine par (audit <date>) pour que fix sache le confirmer sur le site en direct plutôt que via sitecheck :

   ### [B-nnn] fix: <path>
   - type: fix
   - target: <path>
   - score: <n> (potential <p> × ease 10 × fit <f>)      ← potential 3, ou le gsc_potential de la page depuis le dernier seo/data/gsc snapshot ; fit depuis la priorité du cluster
   - evidence: audit <date>: <n> findings
   - status: open
   - fixes:
     link: internal link /old-path redirects to /new-path: link the final URL (audit <date>)
     description: no meta description (audit <date>)
   

   Une page qui a déjà un élément fix ouvert/claimé/en revue → ajoutez les nouvelles lignes fixes: (ignorez les lignes déjà présentes par code + to). Une page possédée par un élément refresh ouvert → owned by B-nnn, pas d'élément fix. Un constat que sitecheck rapporte aussi (même page, même code) est listé une fois, depuis l'audit, avec la balise (audit <date>).
2. Éléments link — constats orphan sur les pages articles : un élément link par cluster (format $P/skills/analysis/SKILL.md §1c, lignes - links: /hub → /orphan (orphan, audit <date>)) ; un cluster avec un élément link ouvert voit les paires ajoutées. Les orphelins sans cluster (aucun hub correspondant) vont dans la liste des propriétaires.
3. Liste des propriétaires — tout le reste : broken-external, redirect-chain, duplicate-title/duplicate-description, noindex-in-sitemap, sitemap-404, thin, h1, mixed-content, slow, server-error, chaque constat sur une page non article (accueil, tarification, juridique, mises en page), sitemap.missing, et les lignes CWV. Groupez par code, du pire au meilleur, ≤ 3 chemins d'exemple par code ; nommez le fichier quand l'inventaire le connaît. thin sur un article est un signal de rafraîchissement, pas un correctif : dites-le et laissez-le à analysis.

--no-items → catégorie 3 seulement, avec le décompte des éléments qui auraient été créés.

3. Commit

Sauf si --dry-run : git add seo/data/crawl/<date>.json seo/backlog.md et commitez seo: audit <date> — <pages> pages, <findings> findings, <k> fix items, <m> link items sur la branche par défaut (les fichiers de planification sont commités directement) ; poussez si la branche a un amont. Pas de PR.

4. Rapport (≤ 15 lignes)

• audit <date>: <pages> pages crawled (<html> html, <truncated?>), <findings> findings (<fixable> fixable) ; sitemap <count> URLs, <missing> manquantes ou en échec
• Constats par code, une ligne, compteurs
• Diff vs <previous> : <new> nouveaux, <resolved> résolus (nommez les nouveaux si ≤ 5)
• Éléments : ids fix avec chemins ; ids link avec clusters ; notes owned by / already open
• Liste des propriétaires : ≤ 8 lignes, du pire au meilleur (une 5xx ou une chaîne de redirection dans la navigation avant une description longue)
• Tableau CWV quand --cwv : chemin, LCP, CLS, INP, perf, source
• Suivant : fix exécute les éléments le vendredi (ou /seo-agent:fix maintenant) ; le prochain audit est dû dans 3 mois

Règles strictes

• Lecture seule sur le site : GET/HEAD avec l'agent utilisateur seo-agent-audit, une origine, --max pages, --delay entre les requêtes ; ne jamais soumettre de formulaires, ne jamais se connecter, ne jamais crawler un autre hôte
• Ne jamais éditer d'articles, de mises en page ou le sitemap ; ne jamais ouvrir de PR ; écrire uniquement dans seo/data/crawl/ et seo/backlog.md
• Éléments de backlog uniquement pour les pages article que le skill fix peut éditer ; tout le reste est la responsabilité du propriétaire
• Déterministe : les constats proviennent de crawl.js ; aucun constat n'est ajouté en lisant le HTML à l'œil
• thin n'est jamais un élément fix