Seo Geo Audit

---
name: seo-geo-audit
description: >
  Audit SEO + GEO complet d'un site web (code du repo + pages live), correction des problemes trouves,
  et redaction d'articles de blog optimises pour Google et pour les moteurs generatifs (ChatGPT,
  Claude, Perplexity, Google AI Overviews). Utilise ce skill des qu'on parle de SEO, GEO, AEO,
  referencement, audit de site, balises meta, sitemap, robots.txt, llms.txt, donnees structurees
  JSON-LD, Core Web Vitals, hreflang, canonical, maillage interne, mots-cles, contenu de blog,
  "pourquoi mon site n'est pas trouve", "etre cite par les IA", ou quand l'utilisateur lance
  /seo-audit, /seo-fix ou /seo-blog.
---

# SEO / GEO Kit

Trois modes. L'utilisateur en choisit un via une slash command, ou tu deduis le mode de sa demande.

| Commande | Mode | Ce que ca fait |
|---|---|---|
| `/seo-audit` | **ANALYSE** | Audite tout, ne touche a rien, produit un rapport note et priorise |
| `/seo-fix` | **CORRECTION** | Lit le dernier rapport, applique les correctifs, verifie, commit |
| `/seo-blog` | **CONTENU** | Ecrit un article de blog aligne sur le site, optimise SEO + GEO, et le cable |

Regle absolue : **ANALYSE ne modifie aucun fichier du projet** (a part le rapport dans `seo/`).
Si l'utilisateur lance `/seo-audit`, tu n'edites pas son code, meme si le fix est trivial. Tu le notes.

---

## 0. Contexte a etablir (tous les modes, ~2 min)

Avant tout, etablis ces faits. Ne les devine pas, verifie-les.

1. **Framework et version** : `package.json`, `next.config.*`, `astro.config.*`, `nuxt.config.*`,
   `gatsby-config.*`, `_config.yml`, `index.html`. Next.js App Router et Pages Router n'ont pas
   la meme API de metadata, ne confonds pas.
2. **URL de production** : dans l'ordre, `NEXT_PUBLIC_SITE_URL` / `SITE_URL` de `.env*`, un
   `lib/site.*` ou `config/site.*`, `package.json#homepage`, le README, `vercel.json`, la remote
   git. Si rien, **demande l'URL** : sans elle tu ne peux auditer que le code, pas le rendu.
3. **Langues** : mono ou multilingue ? Ou vivent les traductions ? Quelle langue par defaut ?
   Quelle strategie d'URL (`/fr`, `/en`, sous-domaine, domaine par langue) ?
4. **Inventaire des routes** : liste tous les fichiers de page (`app/**/page.tsx`, `pages/**`,
   `src/pages/**`, `content/**`). Compte les pages statiques, les routes dynamiques, les articles.
5. **Business** : que vend le site, a qui, dans quel pays ? Sans ca tu ne peux pas juger la
   pertinence des mots-cles ni la qualite du contenu. Lis la landing, le README, le CLAUDE.md.

Ecris ces 5 points en tete de rapport. Ils conditionnent toutes les recommandations.

---

## 1. Mode ANALYSE (`/seo-audit`)

### Methode

Travaille en 7 passes. Fais les passes de fetch en parallele quand elles sont independantes.

**Passe A. Fichiers racine (le socle).** Verifie l'existence ET le contenu de chacun :
`robots.txt`, `sitemap.xml` (+ index de sitemaps), `llms.txt`, `llms-full.txt`, `favicon.ico`,
`manifest.webmanifest`, `feed.xml` / `rss.xml`, `humans.txt`, `.well-known/security.txt`,
`ads.txt` si pub. Pour chacun : present ? valide ? a jour ? coherent avec les routes reelles ?
Un sitemap qui liste des 404 ou qui oublie la moitie des pages est pire que pas de sitemap.

**Passe B. Live crawl.** Recupere la home + 5 a 10 pages representatives (une par type : landing,
pricing, blog index, article, page legale, page appli). Pour chaque URL, note : code HTTP, temps de
reponse, taille du HTML, presence du contenu principal dans le HTML source (pas seulement apres
hydratation JS), `<title>`, `<meta name="description">`, canonical, `hreflang`, OG/Twitter,
JSON-LD, hierarchie H1/H2/H3, nombre de mots, liens internes sortants, liens externes.
Utilise `WebFetch` ou `curl -sSL -o - -w '\n%{http_code} %{time_total}s'`.
**Le rendu compte** : si le HTML source est vide et que tout arrive en JS, note-le en P0, les
crawlers d'IA n'executent generalement pas le JS.

**Passe C. Technique on-page (dans le code).** Voir `references/audit-checklist.md`, section
"Technique". Chaque finding doit pointer un `fichier:ligne`.

**Passe D. GEO / AEO.** C'est la moitie de la valeur de ce kit en 2026. Voir
`references/geo-playbook.md`. Ne te contente pas de "il manque un llms.txt".

**Passe E. Contenu et intentions.** Pour chaque page indexable : quelle requete elle vise, est-ce
que le contenu y repond, est-ce qu'une autre page vise la meme chose (cannibalisation), est-ce
qu'elle fait moins de 300 mots (thin content). Puis la carte des trous : quelles intentions du
marche ne sont couvertes par aucune page. C'est ce qui alimente `/seo-blog`.

**Passe F. Performance et Core Web Vitals (proxys statiques).** Voir checklist section
"Performance". Tu n'as pas de Lighthouse, donc tu audites les causes : images non optimisees,
fonts sans `display: swap` ni preload, pas de `priority` sur l'image LCP, absence de `width`/
`height` (CLS), JS client inutile, `dynamic = "force-dynamic"` la ou du statique suffirait,
absence de cache headers.

**Passe G. Autorite et confiance (E-E-A-T).** Auteur identifiable, page a-propos, coordonnees,
mentions legales, HTTPS, dates de publication et de mise a jour, sources citees, preuves sociales,
coherence NAP si local. Les moteurs generatifs preferent citer une source identifiable.

### Notation

Note sur 100, ponderee. Donne le detail par axe, pas juste le total.

| Axe | Poids | Ce qui fait perdre des points |
|---|---|---|
| Indexabilite et technique | 25 | 404, noindex accidentel, canonical casse, sitemap faux, rendu JS-only |
| Contenu et intentions | 25 | Thin content, cannibalisation, aucune profondeur, trous d'intention |
| GEO / citabilite IA | 20 | Pas de llms.txt, aucune reponse extractible, entite floue, pas de FAQ |
| Donnees structurees | 10 | JSON-LD absent, invalide, ou non aligne au contenu visible |
| Performance / CWV | 10 | Images lourdes, fonts bloquantes, LCP non prioritaire, CLS |
| International / hreflang | 5 | Reciprocite cassee, `x-default` absent, langue HTML fausse |
| Autorite / E-E-A-T | 5 | Pas d'auteur, pas de dates, pas de mentions legales |

Bareme : 90+ excellent, 75-89 solide, 60-74 correct mais des trous, 40-59 gros chantier,
sous 40 le site est quasi invisible.

Sois **severe et honnete**. Un rapport complaisant ne sert a rien. Si le site est nul, dis-le,
avec les preuves.

### Livrable

Ecris `seo/AUDIT-<YYYY-MM-DD>.md` a la racine du projet (cree `seo/` si besoin), au format de
`references/report-template.md`. Puis affiche dans le chat : le score global, les 5 items P0, et
la ligne de commande pour lancer la correction.

Chaque finding respecte ce format, sans exception :

```
### [P0] Titre court et factuel
**Ou** `app/blog/[slug]/page.tsx:42`
**Constat** ce qui est, verifie et cite (extrait de code ou de HTML)
**Impact** consequence concrete sur le referencement ou la citation IA
**Correctif** l'action exacte, prete a appliquer
**Effort** S / M / L
```

Priorites : **P0** ca casse l'indexation ou coute du trafic maintenant. **P1** gain net et
raisonnable a faire. **P2** confort, polish, marginal. Pas plus de 10 P0, sinon tu dilues.

---

## 2. Mode CORRECTION (`/seo-fix`)

1. **Trouve le rapport** : le plus recent dans `seo/`. S'il n'y en a pas, propose de lancer
   `/seo-audit` d'abord. Ne corrige jamais a l'aveugle.
2. **Selectionne** : par defaut tous les P0 + les P1 dont l'effort est S. L'argument filtre
   (`/seo-fix P1`, `/seo-fix sitemap`, `/seo-fix seo/AUDIT-2026-08-16.md`).
3. **Annonce le plan** avant d'editer : liste des items retenus, fichiers touches, ce que tu
   laisses de cote et pourquoi.
4. **Applique**, item par item, en respectant le style du repo : meme framework, memes helpers,
   memes conventions de nommage, meme langue de copie. Recettes pretes dans
   `references/fix-recipes.md`.
5. **Ne casse rien** : verification obligatoire apres chaque groupe. Typecheck (`tsc --noEmit`
   ou equivalent), build si le projet en a un, et un `curl` sur les routes touchees si un serveur
   de dev tourne. Si un correctif casse le build, **reverte ce correctif** et note-le.
6. **Coche** dans le rapport : passe chaque item traite en `- [x]` avec une ligne de resultat.
   Le rapport devient le journal.
7. **Commit** par groupe logique (`fix(seo): ...`, `feat(geo): ...`), pas un commit fourre-tout.
   **Ne pousse pas** sans que l'utilisateur le demande.

Ce que tu ne fais **jamais** en mode correction, meme si le rapport le suggere :
- bourrer des mots-cles dans du texte existant (keyword stuffing, ca penalise)
- inventer des avis, des notes, des chiffres ou des auteurs dans du JSON-LD (schema trompeur,
  c'est une violation des regles Google et ca peut couter une action manuelle)
- ajouter du balisage qui ne correspond pas a du contenu visible sur la page
- reecrire la voix editoriale du site sans qu'on te l'ait demande
- toucher aux redirections, au DNS ou au domaine sans validation explicite

---

## 3. Mode CONTENU (`/seo-blog`)

Objectif : un article qui merite d'exister, qui se positionne sur Google, et qui se fait citer
par les IA. Pas du remplissage.

1. **Comprends le site avant d'ecrire.** Lis la landing, 2 ou 3 articles existants, le CLAUDE.md.
   Releve : la voix, la longueur type, le format du front-matter, l'arborescence
   (`content/blog/{fr,en}/`, `posts/`, MDX, CMS), le systeme de tags, comment un article est cable
   au sitemap et au JSON-LD. **Tu copies ce format, tu n'en inventes pas un nouveau.**
2. **Choisis le sujet.** Si l'utilisateur donne un sujet, pars de la. Sinon, prends le premier
   trou d'intention du dernier audit. Verifie qu'aucun article existant ne le couvre deja
   (sinon tu crees de la cannibalisation, propose plutot une mise a jour de l'existant).
3. **Recherche reelle.** `WebSearch` sur la requete cible : qui se positionne, quel angle, quelle
   profondeur, quelles questions apparaissent en "autres questions posees". Tu dois savoir ce que
   tu dois battre. Note les sources, tu les citeras.
4. **Ecris** selon `references/blog-playbook.md` : une intention par article, la reponse dans les
   80 premiers mots, structure en H2 questions, blocs extractibles, exemples concrets et
   verifiables, FAQ finale, conclusion actionnable.
5. **Cable l'article** : front-matter complet (title, description, date, updated, author, tags,
   slug, altSlug si bilingue, image), JSON-LD `BlogPosting` + `BreadcrumbList`, 3 a 5 liens
   internes contextuels vers des pages qui convertissent, ajout au sitemap et au feed si ce
   n'est pas automatique, ajout a `llms.txt`, image OG.
6. **Version bilingue** si le site l'est : une vraie adaptation, pas une traduction mot a mot.
   Cross-link `hreflang` reciproque via `altSlug`.
7. **Verifie** : le build passe, l'URL repond en 200, le JSON-LD est valide, les liens internes
   pointent vers des pages qui existent.

Regles de qualite non negociables :
- **Zero hallucination.** Chaque chiffre, date, nom de produit ou prix cite doit venir d'une
  source que tu as lue, ou du repo. Dans le doute, tu n'ecris pas le chiffre.
- Pas de "dans le monde d'aujourd'hui", pas de "il est important de noter", pas d'intro qui
  tourne autour du pot pendant 3 paragraphes. Premiere phrase, premiere info.
- Pas de tirets cadratins ni de doubles tirets dans la copie (regle de style par defaut de ce
  kit, retire-la si tu la veux pas). Virgules, deux-points, points.
- Un article de 900 mots dense bat un article de 2500 mots dilue.

---

## Fichiers de reference

Charge-les quand tu en as besoin, pas tous d'un coup.

- `references/audit-checklist.md` : la checklist exhaustive, axe par axe. **Le coeur du mode ANALYSE.**
- `references/geo-playbook.md` : etre trouve et cite par ChatGPT, Claude, Perplexity, AI Overviews.
- `references/report-template.md` : le format exact du compte rendu.
- `references/fix-recipes.md` : correctifs prets a coller (Next.js App Router + generique).
- `references/blog-playbook.md` : structure et regles d'ecriture d'un article qui se classe.

## Pieges connus

- **Ne juge pas depuis le code seul.** Un site peut avoir un `metadata` parfait et servir un
  `noindex` via un header ou un middleware. Verifie le HTML et les headers reels.
- **Next.js ne fusionne pas `openGraph` en profondeur.** Une page qui redefinit `openGraph` perd
  les `images` du layout racine. Bug tres frequent, cherche-le systematiquement.
- **`robots.txt` en `Disallow: /` sur une preview** qui a ete copie en prod : verifie toujours.
- **Sitemap et routes desynchronises** des qu'il y a du contenu dynamique. Compare le nombre
  d'entrees du sitemap au nombre de routes reelles.
- **hreflang non reciproque** : si FR pointe EN, EN doit pointer FR. Sinon Google ignore tout.
- **Trailing slash** incoherent entre canonical, sitemap et liens internes : ca cree du duplicate.
- **Un score parfait ne fait pas du trafic.** Si le contenu ne repond a aucune intention reelle,
  dis-le franchement dans le rapport plutot que de sortir un 95/100 flatteur.