# CDC v1.3 — Analyse Sémantique SERP Pondérée > Statut : **VERSION COURANTE DE RÉFÉRENCE** (remplace v1.2, consolidée — intègre v1.0 + v1.1 + v1.2) > Évolution majeure : résolution des 8 conflits identifiés sur la v1.2 (scoring BM25F, extraction par archétype, mobile-first, fallback headless, intention auto, multilinguisme, curation d'URLs, guide d'écriture) > Périmètre : **fonctionnel uniquement**. Stack, orchestration, architecture → document de design technique séparé (Phase B). --- ## 0. Changements v1.2 → v1.3 | # | Conflit v1.2 | Résolution v1.3 | Section | | --- | --- | --- | --- | | 1 | Formule linéaire ET BM25 « en parallèle » (vulnérable au stuffing) | **BM25F** : saturation appliquée sur la fréquence pondérée par zone ; le linéaire disparaît | §2.2 | | 2 | Extraction Readability aveugle (purge les grilles e-commerce) | Extraction **par archétype de page** (éditorial vs transactionnel) | §3.0 | | 3 | Zones imbriquées non tranchées (`

`) | Zones **mutuellement exclusives**, le poids max l'emporte, jamais de cumul | §2.2 | | 4 | User-Agent non spécifié (angle mort mobile-first) | **UA mobile type Googlebot Smartphone par défaut** | §3.0 | | 5 | Pages JS exclues + « Top 3 incomplet = unreliable » = combo mortel | **Fallback headless ciblé Top 5** | §3.0, §5 | | 6 | Courbe d'intention choisie manuellement | **Auto-détection** par archétypes Schema.org, choix manuel = override | §2.1 | | 7 | Stemming/stop-words non liés à la langue | Pilotés par `` (+ détection fallback) | §3.7 | | 8 | Slug absent, prominence DOM ambiguë, pas de garde-fou d'intention au Gap | Zone **slug** (1.5), métrique renommée `kw_first_position_dom` et assumée, **empreinte d'archétype + alerte `intent_mismatch`** | §2.2, §3.7, §4.2 | | + | (ajouts produit) | Curation manuelle des URLs, politique de rétention 6 h, guide d'écriture type « brief YTG » | §6, §3.8, §4.3 | --- ## 1. Vision Produit Un outil qui ingère une SERP (mot-clé + URLs concurrentes + positions) et produit un **profil sémantique et structurel pondéré** de ce qu'il faut pour ranker, avec un mode **Gap Analysis** comparant la page du client à ce profil, et un **guide d'écriture** actionnable par un rédacteur. **Principe fondateur :** ce qui compte est ce que font les pages les mieux classées. Chaque donnée extraite est pondérée par la position SERP de sa source. **Utilisateurs cibles :** consultants SEO, équipes contenu, intégration dans un dashboard analytique existant. --- ## 2. Modèle de Scoring ### 2.1 Pondération par position (le « Modèle de Puissance ») | Position SERP | CTR estimé | Poids normalisé | | ------------- | ---------- | --------------- | | 1 | ~31.7% | 1.00 | | 2 | ~24.7% | 0.77 | | 3 | ~18.6% | 0.58 | | 4–5 | 13–9% | 0.40–0.28 | | 6–10 | < 6% | 0.15–0.05 | - Fallback mathématique : $W_P = 1/\log_2(P+1)$ - **Mode calibré** par données Search Console du client (position/CTR réels) **Sélection de la courbe (nouveau v1.3) — auto-détection, override manuel :** - Par défaut, l'intention est **inférée** depuis les archétypes de page extraits (§3.0) : - ≥ 60 % du Top 10 en archétype transactionnel (`Product`, `Offer`, `CollectionPage`, `ItemList`) → courbe **transactionnelle** ; - dominance `Article` / `NewsArticle` / `BlogPosting` / `FAQPage` + questions dans les Hn → courbe **informationnelle** ; - aucune dominance ≥ 60 % → courbe **standard** + flag `mixed_intent` dans le rapport. - Les features SERP propagées par l'API d'entrée (PAA, shopping pack, local pack…) affinent la détection quand disponibles. - Le choix manuel du profil (`standard` / `informationnelle` / `transactionnelle` / `navigationnelle` / courbe personnalisée) reste possible en **override**. - Le rapport indique toujours l'intention retenue et son mode : `inferred` / `manual` / `calibrated`. ### 2.2 Scoring BM25F (rang × zone, saturation intégrée) Le score d'un terme est un **BM25F** (variante par champs de BM25) — la formule linéaire de la v1.2 est supprimée : 1. **Fréquence pondérée par zone** : $ftf(T, C_i) = \sum_z Freq(T, C_i, z) \times W_z$ 2. **Saturation + normalisation de longueur** (BM25F : paramètre $k_1$, normalisation sur la longueur pondérée du document). Le keyword stuffing d'un concurrent plafonne au lieu d'exploser — il ne contamine plus le profil ni le Gap Analysis. 3. **Pondération par rang, puis agrégation** : $Score(T) = \sum_i W_{P_i} \times BM25F(T, C_i)$ La **densité brute** et les **fréquences brutes par zone** restent exportées comme indicateurs descriptifs (table `terms`, guide d'écriture §4.3) — jamais comme score. **Zones mutuellement exclusives (résolution des imbrications) :** chaque occurrence de texte est comptée **une seule fois**, dans la zone au poids le plus fort qui la contient, selon la précédence `Title > H1 > H2/H3 > alt > ancre > meta description > body`. Exemple : `

mot-clé

` → compté en H2 (×1.5) uniquement. L'ancre alimente toujours l'analyse de maillage (§3.3) : **analyse ≠ scoring**, pas de double comptage. | Zone | Poids par défaut (paramétrable) | | --------------------- | ------------------------------- | | Title | 3.0 | | H1 | 2.5 | | H2 / H3 | 1.5 | | **Slug URL** (nouveau) | **1.5** — tokenisé (split `-`, `/`, `_`) ; sémantiquement fort mais court, un poids supérieur surpondérerait mécaniquement 3-4 tokens | | Attributs `alt` | 1.3 | | Ancres de liens | 1.2 | | Meta description | 1.2 | | Body | 1.0 | | Meta keywords | **0.0** (extraite, jamais scorée) | ### 2.3 Fondations statistiques - **Médiane pondérée** en plus de la somme ; détection et flag des **outliers** sémantiques - Comparatif systématique **Top 3 vs Top 10** sur toutes les métriques --- ## 3. Matrice d'Extraction de Données ### 3.0 Fetch & stratégie d'extraction (nouveau v1.3) **Mobile-first.** Le fetch utilise un **User-Agent mobile type Googlebot Smartphone par défaut** (paramétrable ; mode `desktop` disponible en config, jamais par défaut). Word count, arbre des Hn, lazy-loading : tout reflète ce que Google évalue réellement (indexation mobile-first). **Fallback headless ciblé.** - Fetch léger (HTTP simple) pour toutes les pages. - Page détectée `js_rendered_suspected` sur une position **Top 5** → second passage en **rendu headless** (même UA mobile). Le HTML rendu remplace le HTML thin ; la page est scorée normalement, flaggée `js_rendered: true`. - Positions 6-10 suspectées JS : pas de rendu — exclusion du scoring + flag (leur poids est faible, le coût d'un rendu ne se justifie pas). - **Contrainte de conception — interchangeabilité** : le rendu headless est spécifié comme une interface (URL + UA → HTML rendu + flags), implémentable en local (navigateur piloté) ou via API de pre-rendering, sans impact sur le fonctionnel. **Extraction par archétype de page.** Le pipeline détecte d'abord un **archétype**, puis choisit sa stratégie : - **Détection** (dans cet ordre) : Schema.org dominant (`Product`/`CollectionPage`/`ItemList`/`Offer` → transactionnel ; `Article`/`NewsArticle`/`BlogPosting`/`FAQPage` → éditorial), puis heuristique structurelle en fallback (blocs répétitifs image+lien+prix, densité de `
` vs grilles de `
  • `). - **Éditorial** → extraction type Readability stricte (nav/footer/sidebar exclus). - **Transactionnel/listing** → extracteur large : la grille de produits **est** le contenu principal ; titres de fiches, prix, labels de filtres et onglets d'avis sont conservés. Nav/footer exclus par sélecteurs structurels (`