SEO Strategy

seo-strategy : sur quoi écrire, dans quel ordre

La stratégie part des OFFRES, jamais des mots. Les piliers de contenu ne sont pas découverts par ressemblance de mots-clés : ce sont les prestations que le client vend (le cerveau), et chaque requête collectée vient se ranger sous l'offre qu'elle sert. Une requête qui ne sert aucune offre est du hors-sujet, pas un "petit cluster".

Règles dures : aucun métier/secteur/concurrent hardcodé (tout vient du cerveau et des données) ; mode client uniquement ; exercice fait UNE FOIS puis re-run quasi annuel (la boucle hebdo funnel/refresh/monitoring vit entre-temps) ; l'existant (garder/optimiser/couper) est le périmètre de seo-content-pruning, pas d'ici.

Le pipeline

socle (agent, cerveau) -> seeds.json (agent) -> collect (script, DataForSEO + GSC)
  -> jugement par lots (agent : offre + rôle par groupe) -> assemble (script : clusters,
  vagues, couloirs) -> strategy.md (agent : narratif) -> seeding du board (couloirs)

Procédure

Étape 1 : charger le contexte COMPLET, puis le socle

Lire TOUS les docs de contexte pertinents à la stratégie (clients/<slug>/context/), pas seulement les fichiers du socle : product-value.md (qu'est-ce qu'on vend, priorités), positioning-messages.md (contre qui, national/local), audiences-personas.md (à qui, et à qui PAS), proof-points.md (ce qu'on a le droit d'affirmer, borne les angles), vocabulary.md (les mots du client + NAP), linking-clusters.md (l'architecture éditoriale existante). Une stratégie trop complète vaut mieux qu'une stratégie trouée : chaque décision aval (seeds, assignation, conscience, type de contenu) s'appuie sur cette lecture.

Puis le socle : si outputs/socle.json existe (déposé par seo-content-pruning), le relire et ne re-juger que le delta. Sinon le construire. Si les offres ne sont pas nettes : NE PAS deviner, remonter au owner et s'arrêter.

Éligibilité géo : le play local découle de la localisation physique réelle (NAP) et rayonne sur la zone ADJACENTE uniquement (ex Paris 16 → Paris 16, 17, 8, Neuilly). Pas d'adresse visitable = pas de zones. Proposer la liste, ne jamais l'inventer en silence.

Étape 2 : écrire outputs/keyword/seeds.json

Comment marchent les seeds : l'API de recherche fonctionne par EXPANSION. Une seed est une expression de départ ; l'API renvoie des centaines de requêtes réelles qui la contiennent ou en dérivent, avec volume et difficulté (ex : "comptabilité sci" → "logiciel comptabilité sci familiale", "combien coute un comptable pour une sci", "obligation comptable sci à l'is"…). La couverture de l'univers collecté dépend ENTIÈREMENT des seeds : une seed unique = un univers troué. Donc 2-4 seeds PAR OFFRE, sous des angles différents : la prestation elle-même, le tarif ("tarif "), le problème que se pose le persona (vocabulaire des personas), et les variantes du vocabulaire client (vocabulary.md).

Règle de hauteur (dure) : formuler les seeds À HAUTEUR DE L'AUTORITÉ du client, jamais les têtes de marché génériques du secteur ("<métier> en ligne", "meilleur <métier>", "<métier>" seul) quand le client est petit : ces requêtes sont le champ de bataille des gros acteurs, ET leurs suggestions héritent de ce champ de bataille, donc une seule seed tête de marché pollue tout l'univers collecté. Le pré-filtre KD écarte les têtes après coup, mais il ne répare pas un univers biaisé. Partir du spécifique : la prestation précise, la niche, l'intention de changement ("changer de <métier>"), le problème concret. Relisibles par le owner avant collecte :

{
  "metier": "expert-comptable",
  "offers": [
    {"name": "Comptabilité SCI", "priority": 1,
     "seeds": ["comptabilité sci", "expert comptable sci", "tarif comptable sci"],
     "sectors": ["SCI familiale", "SCI à l'IS"],
     "zones": ["Paris 16", "Paris 17"]}
  ]
}

Les secteurs s'intègrent DANS les seeds (ex "comptable sci familiale") ; zones seulement si l'éligibilité géo est validée. 2-4 seeds par offre suffisent.

Étape 3 : collect (script)

python seo/skills/seo-strategy/scripts/strategy.py collect <slug> [--per-seed 100] [--serp-budget 40]

Le script : autorité du site → plafond KD (escalade au mérite) ; suggestions + volumes + KD par offre ; pairs d'autorité (keyword gap) ; croisement GSC (positions réelles, depuis le dernier export déposé dans data/gsc/ : celui du pruning convient) ; SERP réelle des groupes les plus lourds (top 10 + signaux de faiblesse, budget) ; pré-groupage par racine et découpe en lots de 20 groupes triés par enjeu décroissant → outputs/keyword/<date>/candidates.json.

Les pairs d'autorité (--peers, défaut 5) : les 3-5 sites qui rankent sur les mêmes requêtes que le client ET dont les backlinks sont dans une bande comparable (0,3× à 3× nos referring domains : les mastodontes sortent mécaniquement, zéro liste codée en dur). Leurs mots-clés positionnés ≤ 20 rejoignent le pool de candidats avec la preuve attachée (peer_domain@position). Doctrine : s'ils peuvent ranker avec notre niveau d'autorité, on peut ranker ; un mot-clé au-dessus du plafond KD mais où un pair est top 10 n'est PAS relégué en ambition (la preuve pair bat le pré-filtre théorique). Les pairs sont AUTO-détectés par la donnée : ce ne sont PAS les concurrents business du client.json (notion distincte, fournie par le client pour les audits). Surcharge possible : "peers": ["domaine1.fr", ...] dans seeds.json. Les mots-clés pairs passent le MÊME jugement agent que les autres (offre + rôle, hors-ICP écarté) : un pair peut ranker sur du hors-sujet, la preuve d'atteignabilité ne vaut pas pertinence.

Credentials : DATAFORSEO_USERNAME/DATAFORSEO_PASSWORD en env. Pas d'export GSC déposé = le croisement positions est vide : le signaler et préférer déposer un export d'abord.

Étape 4 : le jugement par lots (agent) : le cœur

Assigner chaque GROUPE de candidates.json : une offre du socle, un rôle, un niveau de conscience, un type de contenu :

• Rôle : transactionnel (la requête achète : prestation, tarifs, déclinaisons secteur/zone) / soutien (la question d'AVANT l'achat, TOFU rattaché à l'offre) / hors_icp (ne sert aucune offre ou vise un public non voulu : écarté).
• Niveau de conscience (les 5 niveaux d'Eugene Schwartz, pilotent le taux de conversion attendu) :

• Type de contenu + drilldown : content_type (Landing Page / Blog article / Guide / Page prestation) et content_drilldown (How-to, Listicle, Top tools, Comparatif, Statistiques, Exemples…). Découle du rôle + de la conscience + de ce que la SERP réelle montre (le format qui ranke).

Le jugement se fait contre le cerveau COMPLET (offres, personas, proof-points pour les angles défendables), en s'aidant des données du groupe (la SERP réelle : des forums/annuaires = prenable ; que des sites nationaux à forte autorité = juger serp_locked: true).

Protocole anti-effondrement (OBLIGATOIRE) :

1. Juger lot par lot (20 groupes), dans l'ordre des lots (déjà triés par enjeu décroissant).
2. Écrire assignments.json après CHAQUE lot (jamais une passe unique en mémoire) :

{"assignments": [{"group_id": 0, "offer": "Comptabilité SCI", "role": "transactionnel",
                  "awareness": "Most Aware", "content_type": "Page prestation",
                  "content_drilldown": "Tarifs", "serp_locked": false}],
 "splits": [{"group_id": 7, "keyword": "…", "offer": "…", "role": "soutien", "awareness": "Problem Aware"}],
 "lanes": {"money": "…", "momentum": "…"}}

(splits : pour éclater un groupe hétérogène, mot-clé par mot-clé ; lanes : optionnel, sinon le script propose.) 3. Auto-contrôle final : re-juger à froid ~10 groupes pris au MILIEU des lots ; plus de 2 divergences = la passe a dérivé, reprendre les lots concernés.

Étape 5 : assemble (script) : du trafic au CA

python seo/skills/seo-strategy/scripts/strategy.py assemble <slug>

Construit les clusters par offre avec : momentum (requêtes du cluster où le site est déjà 5-20), vagues d'escalade (vague 1 = satellites KD ≤ 20 ; vague 2 = KD ≤ plafond ; ambition = au-dessus du plafond ou SERP verrouillée), pages prestation à créer, les deux couloirs, et le scoring conversion (logique CA, pas trafic) :

• Uplift de clics : volume × CTR à la position cible (courbe CTR, cible par défaut position 3) moins les clics actuels (GSC). Déjà à/au-dessus de la cible = uplift 0.
• Uplift de leads : uplift de clics × taux visite→lead de la matrice rôle × niveau de conscience. C'est ce qui fait passer la priorisation d'une logique de trafic à une logique de devis/CA.
• Gap de backlinks (collect --rd-budget) : RDs médians des pages du top 10 vs la page du client, les DEUX mesurés par la même source (API Backlinks DataForSEO : le rapport Liens de la GSC n'est pas exposé par son API) → rds_diff et flag enough_backlinks.
• Tri des vagues (doctrine petits sites) : sur un client à faible trafic, l'uplift est quasi maximal partout, il DIMENSIONNE l'enjeu mais ne trie pas. La traction existante choisit le terrain (couloir momentum), puis le GAP DE BACKLINKS trie à l'intérieur (la concurrence la plus simple d'abord), l'uplift de leads départage, la difficulté ensuite.

La matrice de conversion est une HYPOTHÈSE par défaut (écrite dans le plan comme telle) tant que outputs/keyword/scoring-config.json n'est pas calibré avec les conversions réelles du client (format : target_position, ctr_curve, visit_to_lead par rôle × conscience). Dès que le client a des données (devis par page GA4/CRM), les y mettre : tout le scoring se recalcule au prochain assemble.

Étape 6 : le livrable ATOMISÉ (personne ne lit un pavé)

Le script sort un livrable en 3 niveaux, chacun pour son consommateur. L'agent ne produit qu'UN document rédigé : strategie.md.

Doctrine à énoncer dans strategie.md (en une phrase chacune) : les pages prestation sont des pages commerciales créées d'office (nav, footer, hub) ; jamais plus de 2 clusters ouverts, masse critique = hub + 4-6 satellites ; les satellites longue traîne rankent en semaines et prouvent l'intérêt ; l'ambition attend que l'autorité monte (le re-run annuel relève le plafond). Valider ou corriger les couloirs proposés par le script et JUSTIFIER par les données.

Jamais : promettre des positions ou du trafic, ranger une requête sous une offre par simple partage de mots (c'est l'intent qui décide), ouvrir plus de deux clusters, inclure du contenu orphelin (sans offre).

Tools (harness-aware)

Le socle passe par les scripts (REST direct, credentials env). En Claude Code, pour un export GSC frais : ToolSearch: "select:mcp__gsc-mcp__get_search_analytics". Autres harness : l'accès GSC équivalent.

Contrat

Sur Hermes

Run ponctuel au démarrage d'un client (après seo-content-pruning), re-run quasi annuel ou au changement de régime signalé par le monitoring. Le premier run d'un client est relu par le owner avant d'être montré au client.