📚 Best Practices SEO

Pourquoi cet ordre est critique

L'ordre d'exécution d'un plan SEO n'est PAS arbitraire. Chaque phase a une raison
d'être positionnée à son endroit :

1️⃣ Diagnostic (en premier)

- Cadrer avant d'agir
- Identifier les vrais problèmes
- Éviter de "patcher" des symptômes

2️⃣ Refonte de fond (le gros chantier)

- `update_post`, `merge_posts`, `expand_thin_content`
- Modifier le contenu en profondeur
- Doit précéder l'optimisation de surface (sinon les meta seront écrasées)

3️⃣ Surface (après refonte)

- `update_meta`, `schema_inject`, `set_canonical`
- Optimiser les balises HTML
- Si fait avant la refonte : balises écrasées

4️⃣ Maillage interne (après que les pages cibles soient stables)

- `internal_links_update`
- Pointer vers des pages dans leur version finale
- Sinon : ancres pointent vers du contenu obsolète

5️⃣ Création (en parallèle de cleanup)

- Nouveaux articles via `brief`
- Indépendant de la refonte des pages existantes

6️⃣ Cleanup (avant indexation)

- `redirect_301`, `trash_post`, `unpublish_post`
- Faire le ménage final
- Doit précéder le submit GSC pour éviter d'indexer du 404

7️⃣ Indexation (TOUJOURS en dernier)

- `submit_gsc`
- Demander à Google de venir crawler
- **Idéalement 24h-7j après les modifs**, pour laisser cache + sitemap se synchroniser

Pourquoi attendre avant submit_gsc

5 raisons techniques :

1. Cache (WP Rocket / CDN / browser)

- WP Rocket page-cache de 24h par défaut
- Cloudflare edge cache 4-24h
- Browser cache 1h via Cache-Control

→ Si submit_gsc juste après update_post, Google récupère **l'ancienne version cachée**.
Auto-fix dans le pipeline : `purge_wp_rocket_cache` + `flush_cache` + `trigger_preload`
sont automatiquement appelés (cf Chantier 3).

2. Sitemap lastmod

- RankMath/Yoast met à jour `<lastmod>` avec un délai (5-30 min)
- Le tag doit être à jour pour que Google priorise le re-crawl

3. Quotas API Google Indexing

- URL Inspection API : 2000 req/jour, 600/min
- Indexing API : 200 req/jour
- Espacer évite les rate-limits

4. Algorithme de fraîcheur Google

- Google compare avec sa version cachée → si pas de différence (cache stale) →
considère que tu as menti sur la fraîcheur
- Risque léger de dévalorisation du signal "freshness"

5. Refonte profonde (cas pillars)

- Google doit "réapprendre" la page
- Pousser 5 submits sur 5 pillars simultanément peut être traité comme "site relaunch"
- Risque de **temporairement déranker** pendant 1-2 semaines

Recommandation pratique : étaler sur 7-14 jours

          
        
          J+0  : Refonte pillars enfants (DSI, CTO, RSSI) + auto-purge cache

          
        
          J+1  : Vérif visuelle, ajustements

          
        
          J+2  : Refonte pillar parent + intégration

          
        
          J+3  : Phase Surface (meta + schema)

          
        
          J+5  : Phase Maillage (après stabilisation)

          
        
          J+7  : Phase Indexation (submit_gsc)

          
        
          J+14 : Mesure KPIs (positions, CTR)

          
        
          
            
          
        
          

          
        
      

update_meta vs update_post : ordre critique

`update_post` modifie le **contenu HTML** d'une page WP. Selon le plugin SEO utilisé :
- **RankMath / Yoast** : les balises meta sont stockées séparément (postmeta), donc
update_post ne les touche pas
- **Mais** : si update_post inclut un `<title>` dans le contenu HTML, ou si le thème
recalcule la meta_description depuis le content (Elementor par exemple) → les
meta peuvent être écrasées

→ **Best practice safe** : faire update_post d'abord (phase 2), puis update_meta (phase 3).

Exception : si tu ne touches PAS au contenu

Si tu fais juste un `update_meta` sans update_post sur la même page, pas de problème.

Pourquoi maillage après refonte

`internal_links_update` ajoute/modifie des liens internes vers des pages cibles
spécifiques (ex: pages villes → pillar /dsi-de-transition/).

Si tu maille AVANT la refonte des pages cibles :
1. Les ancres et le contexte des liens correspondent à l'ancien contenu
2. Si le H1 ou la sémantique de la page cible change après la refonte, les ancres
peuvent devenir inappropriées
3. Google va re-crawler les pages source qui pointent vers la page cible →
risque de signal contradictoire

→ Best practice : finaliser la refonte (phase 2 + 3) PUIS faire le maillage (phase 4).

Auto-fixes invisibles (Sprint Ask v3 — Chantier 3)

Quand tu cliques **▶ Approuver et exécuter** sur un strategic_task de type
`update_post` ou `update_meta`, le pipeline déclenche automatiquement (sans que tu fasses rien) :

1. **`autopilot_purge_wp_rocket_cache(site)`** : vide le cache de la page modifiée
2. **`autopilot_flush_cache(site)`** : vide le cache global
3. **`autopilot_trigger_wp_rocket_preload(site)`** : re-cache la nouvelle version
4. **Vérification HTTP** : `curl GET <url>` + check des headers (X-Cache, X-Powered-By)

Le résultat est loggé dans `autopilot_result_json.post_execute_hooks` :

          
        
          {

          
        
            "post_execute_hooks": {

          
        
              "all_ok": true,

          
        
              "duration_ms": 2890,

          
        
              "steps": [

          
        
                {"step": "purge_wp_rocket_cache", "ok": true, ...},

          
        
                {"step": "flush_wp_cache", "ok": true, ...},

          
        
                {"step": "trigger_wp_rocket_preload", "ok": true, ...},

          
        
                {"step": "verify_http_served", "ok": true, "http_status": 200,

          
        
                 "url": "https://www.transicio.com/dsi-de-transition/", ...}

          
        
              ]

          
        
            }

          
        
          }

          
        
          
            
          
        
          

          
        
          → Si une étape échoue (ex: cache plugin pas installé), `all_ok=false` mais

          
        
          l'exécution principale n'est PAS rollback. Juste un signal pour vérification.

          
        
          

          
        
      

GSC Index planifiable (Chantier 5)

Quand un item `submit_gsc` est créé via "🚀 Lancer le plan", il est ajouté à la
queue `gsc_index_queue` avec un `scheduled_at` calculé à **J+7 par défaut**.

Pourquoi 7 jours ?

- Laisse le temps au cache de se vider (auto-fix Chantier 3 + cycle natural 24h)
- Laisse Google indexer naturellement les changements via crawl régulier
- Évite le pattern "modif + push immédiat" qui peut être détecté comme thin
- Évite de griller le quota API GSC

Pour modifier la date

Sur l'item submit_gsc d'un plan, champ "Indexer dans X jours" → tu peux entrer 0
(immédiat), 1, 7, 14, etc.

Comportement du worker GSC

Le cron worker pioche les URLs avec :

          
        
          SELECT * FROM gsc_index_queue

          
        
           WHERE status='pending'

          
        
             AND (scheduled_at IS NULL OR scheduled_at <= NOW())

          
        
          
            
          
        
          Donc si scheduled_at est dans le futur, l'URL n'est pas piochée jusqu'à la date.

          
        
          

          
        
          
Cas d'usage : urgence
          
        
          Si tu veux submit immédiatement (pas attendre 7j), édite `scheduled_at = NULL` dans

          
        
          la DB OU change la valeur en "0 jours" dans l'UI.