Stress-test staging SEO : checklist technique pré-launch

Un e-commerce mode de 22 000 pages migre de Magento 2 vers une stack headless Next.js + Shopify. Le staging est impeccable visuellement. L'équipe QA valide. Le go-live tombe un mardi matin. Jeudi, Google Search Console affiche une chute de 34% des impressions. Les canonical pointent toutes vers le staging. Les hreflang ont disparu. Le sitemap référence encore les anciennes URLs. Trois semaines de récupération, 180K€ de chiffre d'affaires perdus.

Ce scénario n'est pas hypothétique. C'est le pattern classique d'un stress-test staging bâclé — ou inexistant. Helen Pollitt a récemment abordé le sujet dans sa chronique Ask An SEO sur Search Engine Journal, en posant les bases méthodologiques. Cet article va plus loin : scripts d'audit automatisés, configs serveur, scénarios de crawl massif, et la méthodologie exacte pour transformer votre staging en filet de sécurité.

Préparer le staging comme un miroir de production fidèle

Le premier piège est de croire que votre staging reflète la production. Dans la majorité des cas, ce n'est pas le cas — et les écarts sont précisément là où les régressions SEO se cachent.

Le problème des données tronquées

Un staging avec 500 produits quand la production en compte 18 000 ne teste rien du tout en matière de SEO. Les problèmes de pagination, de faceted navigation, de crawl depth, de temps de génération des sitemaps — tout cela n'apparaît qu'à l'échelle réelle.

Exportez un dump complet de la base de production (anonymisé pour le RGPD) et injectez-le dans le staging. Si la volumétrie rend ça impossible (certaines bases e-commerce dépassent les 50 Go), prenez au minimum un échantillon représentatif : toutes les catégories L1/L2, un ratio réaliste de produits actifs/inactifs, et l'intégralité des redirections 301 existantes.

Bloquer les robots tout en permettant l'audit

Le staging doit être invisible pour Google mais crawlable par vos outils. La méthode la plus fiable combine authentification HTTP et un robots.txt permissif derrière cette auth :

# Configuration Nginx pour le staging
server {
    listen 443 ssl;
    server_name staging.votresite.fr;

    # Auth HTTP basique — bloque tous les crawlers publics
    auth_basic "Staging Environment";
    auth_basic_user_file /etc/nginx/.htpasswd;

    # Headers anti-indexation en doublon de sécurité
    add_header X-Robots-Tag "noindex, nofollow" always;

    # Permettre le crawl interne une fois authentifié
    location /robots.txt {
        auth_basic off;  # robots.txt accessible sans auth
        return 200 "User-agent: *\nDisallow: /\n";
    }

    # Le reste de la config...
    location / {
        proxy_pass http://backend:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Le X-Robots-Tag en header HTTP est votre filet de sécurité si quelqu'un désactive l'auth ou si un lien staging fuite. Les deux mécanismes se complètent.

Point critique : vérifiez que votre crawleur (Screaming Frog, Sitebulb) supporte l'authentification HTTP. Dans Screaming Frog, c'est dans Configuration > Authentication > Forms Based / HTTP Basic. Si vous utilisez une auth par cookie ou OAuth, configurez un custom header ou un cookie persistant dans les paramètres du crawler.

Aligner les variables d'environnement

Les frameworks modernes utilisent des variables d'environnement pour switch entre staging et production. C'est là que les canonical, les URLs de sitemap et les balises OG partent en vrille.

Vérifiez ces variables en priorité :

# Variables critiques à auditer dans le .env du staging
# Recherchez toute référence au domaine de production

grep -rn "votresite.fr\|NEXT_PUBLIC_SITE_URL\|CANONICAL_BASE\|SITEMAP_HOST" \
  .env .env.staging .env.local next.config.js nuxt.config.ts

# Résultat attendu : toutes les URLs doivent pointer vers staging.votresite.fr
# Si vous voyez www.votresite.fr dans le staging, c'est un bug pré-launch

Dans un projet Next.js, le piège classique est NEXT_PUBLIC_SITE_URL utilisé pour générer les canonical et les URLs OG. Si cette variable pointe vers la production dans le build staging, vos tests valident des canonical corrects... qui ne le seront plus après le flip DNS.

Auditer les balises SEO critiques à l'échelle

Le test manuel de 10 pages ne suffit pas. Vous avez besoin d'un crawl complet du staging, comparé au crawl de production, avec un diff automatisé.

Crawl comparatif production vs staging

Lancez un crawl Screaming Frog sur la production ET sur le staging. Exportez les deux en CSV, puis comparez avec un script :

import pandas as pd
import sys

def compare_crawls(prod_csv: str, staging_csv: str, output: str):
    """
    Compare les crawls production et staging.
    Détecte : titles modifiés, canonical manquants, meta robots changés,
    status codes différents, hreflang supprimés.
    """
    prod = pd.read_csv(prod_csv, usecols=[
        'Address', 'Status Code', 'Title 1', 'Meta Description 1',
        'Canonical Link Element 1', 'Meta Robots 1', 'Indexability',
        'H1-1', 'Word Count'
    ])
    staging = pd.read_csv(staging_csv, usecols=[
        'Address', 'Status Code', 'Title 1', 'Meta Description 1',
        'Canonical Link Element 1', 'Meta Robots 1', 'Indexability',
        'H1-1', 'Word Count'
    ])

    # Normaliser les URLs pour comparer (retirer le domaine)
    prod['path'] = prod['Address'].str.replace(
        r'https?://[^/]+', '', regex=True
    )
    staging['path'] = staging['Address'].str.replace(
        r'https?://[^/]+', '', regex=True
    )

    merged = prod.merge(staging, on='path', suffixes=('_prod', '_staging'))

    # Détecter les régressions critiques
    regressions = []

    # 1. Title disparu ou modifié
    title_changes = merged[
        merged['Title 1_prod'] != merged['Title 1_staging']
    ]
    for _, row in title_changes.iterrows():
        regressions.append({
            'path': row['path'],
            'type': 'TITLE_CHANGED',
            'prod_value': row['Title 1_prod'],
            'staging_value': row['Title 1_staging'],
            'severity': 'HIGH'
        })

    # 2. Canonical manquant ou modifié
    canonical_changes = merged[
        merged['Canonical Link Element 1_prod'] != merged['Canonical Link Element 1_staging']
    ]
    for _, row in canonical_changes.iterrows():
        regressions.append({
            'path': row['path'],
            'type': 'CANONICAL_CHANGED',
            'prod_value': row['Canonical Link Element 1_prod'],
            'staging_value': row['Canonical Link Element 1_staging'],
            'severity': 'CRITICAL'
        })

    # 3. Page devenue non-indexable
    indexability_loss = merged[
        (merged['Indexability_prod'] == 'Indexable') &
        (merged['Indexability_staging'] != 'Indexable')
    ]
    for _, row in indexability_loss.iterrows():
        regressions.append({
            'path': row['path'],
            'type': 'INDEXABILITY_LOST',
            'prod_value': 'Indexable',
            'staging_value': row['Indexability_staging'],
            'severity': 'CRITICAL'
        })

    # 4. Pages production manquantes dans le staging (404/disparues)
    prod_paths = set(prod['path'])
    staging_paths = set(staging['path'])
    missing = prod_paths - staging_paths
    for path in missing:
        regressions.append({
            'path': path,
            'type': 'PAGE_MISSING_IN_STAGING',
            'prod_value': 'EXISTS',
            'staging_value': '404 or GONE',
            'severity': 'CRITICAL'
        })

    results = pd.DataFrame(regressions)
    results = results.sort_values('severity')
    results.to_csv(output, index=False)
    
    # Résumé
    print(f"\n{'='*60}")
    print(f"STAGING REGRESSION REPORT")
    print(f"{'='*60}")
    print(f"Total régressions détectées : {len(regressions)}")
    print(f"  CRITICAL : {len(results[results.severity == 'CRITICAL'])}")
    print(f"  HIGH     : {len(results[results.severity == 'HIGH'])}")
    print(f"Pages manquantes : {len(missing)}")
    print(f"Rapport exporté : {output}")

if __name__ == '__main__':
    compare_crawls(sys.argv[1], sys.argv[2], sys.argv[3])

Exécution : python compare_crawls.py crawl_prod.csv crawl_staging.csv report.csv

Ce script détecte quatre catégories de régressions. En pratique, sur une migration d'un site de 15 000 pages, attendez-vous à trouver entre 200 et 2 000 écarts. La plupart seront bénins (légères modifications de title intentionnelles), mais les CRITICAL — canonical cassés, pages disparues, indexability perdue — doivent être résolus avant toute mise en production.

Focus sur les pages à fort trafic

Toutes les pages ne méritent pas le même niveau d'attention. Croisez votre rapport de régressions avec les données Search Console pour prioriser :

Exportez les pages avec le plus d'impressions/clics depuis Search Console (Performance > Pages > Export). Les 200 premières pages représentent souvent 70-80% du trafic organique. Si une régression touche l'une d'elles, c'est un showstopper.

Valider le rendering et le JavaScript côté SEO

Les migrations vers des frameworks JavaScript (React, Vue, Angular, ou leurs variantes SSR) introduisent un risque spécifique : le contenu visible dans le navigateur peut être invisible pour Googlebot. Le staging est le moment de le vérifier — pas après le launch.

Comparer le HTML servi vs le DOM rendu

Pour chaque template type (page produit, catégorie, article, landing page), comparez le HTML retourné par le serveur (ce que reçoit un curl) avec le DOM après exécution JavaScript :

# 1. Récupérer le HTML brut (ce que voit le serveur)
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  "https://staging.votresite.fr/categorie/chaussures-homme" \
  -o raw_html.html

# 2. Récupérer le DOM rendu via Puppeteer / Chrome headless
npx puppeteer-core --no-sandbox << 'EOF' > rendered_dom.html
const browser = await require('puppeteer').launch({
  args: ['--no-sandbox']
});
const page = await browser.newPage();
await page.setUserAgent('Mozilla/5.0 (compatible; Googlebot/2.1)');
await page.goto('https://staging.votresite.fr/categorie/chaussures-homme', {
  waitUntil: 'networkidle0',
  timeout: 30000
});
// Attendre le rendering complet
await page.waitForTimeout(5000);
const content = await page.content();
console.log(content);
await browser.close();
EOF

# 3. Comparer les balises critiques
echo "=== TITLE ===" 
echo "Raw:"  && grep -oP '<title>[^<]+</title>' raw_html.html
echo "Rendered:" && grep -oP '<title>[^<]+</title>' rendered_dom.html

echo "=== H1 ==="
echo "Raw:"  && grep -oP '<h1[^>]*>[^<]+</h1>' raw_html.html
echo "Rendered:" && grep -oP '<h1[^>]*>[^<]+</h1>' rendered_dom.html

echo "=== CANONICAL ==="
echo "Raw:" && grep -oP '<link[^>]*rel="canonical"[^>]*>' raw_html.html
echo "Rendered:" && grep -oP '<link[^>]*rel="canonical"[^>]*>' rendered_dom.html

echo "=== META ROBOTS ==="
echo "Raw:" && grep -oP '<meta[^>]*name="robots"[^>]*>' raw_html.html
echo "Rendered:" && grep -oP '<meta[^>]*name="robots"[^>]*>' rendered_dom.html

Si le H1 ou le contenu principal n'apparaissent que dans le DOM rendu et pas dans le HTML brut, vous avez un problème de CSR (Client-Side Rendering). Google peut indexer du contenu CSR, mais avec un délai (la file d'attente de rendering peut prendre des jours voire des semaines) et un risque d'indexation partielle.

L'outil de test intégré : URL Inspection

L'outil d'inspection d'URL de Google Search Console ne fonctionne pas sur un staging protégé par auth. Utilisez plutôt le Rich Results Test de Google — il accepte du code HTML collé directement, ce qui permet de tester le HTML brut de votre staging sans l'exposer.

Pour un test plus réaliste, l'onglet Rendering de Screaming Frog (Configuration > Spider > Rendering > JavaScript) simule le rendering Chromium et vous montre exactement ce que le crawler voit. Activez-le pour votre crawl staging.

Tester les redirections à l'échelle

Sur une migration, les redirections 301 sont le nerf de la guerre. Un fichier de mapping de 8 000 lignes contient forcément des erreurs. Le staging est le moment de les trouver.

Validation bulk des redirections

Exportez votre fichier de mapping (ancien URL → nouveau URL) et testez chaque ligne :

#!/bin/bash
# redirect_test.sh — Tester un fichier de mapping de redirections
# Format attendu du CSV : old_url,new_url (sans header)

INPUT_FILE="redirect_mapping.csv"
STAGING_DOMAIN="https://staging.votresite.fr"
ERRORS=0
TOTAL=0

echo "URL_ancienne,URL_attendue,Status_Code,URL_effective,Résultat" > redirect_report.csv

while IFS=',' read -r old_path new_path; do
    TOTAL=$((TOTAL + 1))
    
    # Suivre la redirection et capturer le status + destination
    RESPONSE=$(curl -s -o /dev/null -w "%{http_code}|%{redirect_url}" \
        -A "Googlebot" \
        "${STAGING_DOMAIN}${old_path}")
    
    STATUS=$(echo "$RESPONSE" | cut -d'|' -f1)
    REDIRECT_TO=$(echo "$RESPONSE" | cut -d'|' -f2)
    
    # Normaliser l'URL de destination (retirer le domaine pour comparer)
    EFFECTIVE_PATH=$(echo "$REDIRECT_TO" | sed "s|${STAGING_DOMAIN}||")
    
    if [ "$STATUS" = "301" ] && [ "$EFFECTIVE_PATH" = "$new_path" ]; then
        RESULT="OK"
    elif [ "$STATUS" = "301" ] && [ "$EFFECTIVE_PATH" != "$new_path" ]; then
        RESULT="WRONG_DESTINATION"
        ERRORS=$((ERRORS + 1))
    elif [ "$STATUS" = "302" ]; then
        RESULT="302_NOT_301"
        ERRORS=$((ERRORS + 1))
    elif [ "$STATUS" = "200" ]; then
        RESULT="NO_REDIRECT"
        ERRORS=$((ERRORS + 1))
    else
        RESULT="ERROR_${STATUS}"
        ERRORS=$((ERRORS + 1))
    fi
    
    echo "${old_path},${new_path},${STATUS},${EFFECTIVE_PATH},${RESULT}" >> redirect_report.csv
    
    # Afficher les erreurs en temps réel
    if [ "$RESULT" != "OK" ]; then
        echo "❌ ${old_path} → Status: ${STATUS}, Got: ${EFFECTIVE_PATH} (Expected: ${new_path})"
    fi

done < "$INPUT_FILE"

echo ""
echo "=== RÉSULTAT ==="
echo "Total testé : ${TOTAL}"
echo "Erreurs : ${ERRORS}"
echo "Taux de succès : $(( (TOTAL - ERRORS) * 100 / TOTAL ))%"

Les erreurs les plus fréquentes :

302 au lieu de 301 : le serveur utilise des redirections temporaires. Fréquent avec certains CDN (Cloudflare, Fastly) qui transforment les 301 en 302 en mode "orange cloud" ou en développement.
Chaînes de redirections : l'ancienne URL redirige vers une URL intermédiaire qui redirige vers la finale. Ajoutez -L --max-redirs 5 à curl et vérifiez que la chaîne ne dépasse pas 2 sauts.
Redirections vers des 404 : la destination du 301 n'existe pas dans la nouvelle arborescence. C'est le pire scénario — vous perdez l'equity des backlinks.

Le cas spécifique des trailing slashes

Un classique sous-estimé : /categorie/chaussures vs /categorie/chaussures/. Si votre ancien site utilisait des trailing slashes et le nouveau non (ou l'inverse), chaque URL devient techniquement une redirection manquante. Testez les deux variantes dans votre script.

Stress-test de performance et de crawlability

La performance du staging sous charge simule ce qui se passera quand Googlebot crawlera votre site à plein régime après le launch. Un site qui met 4 secondes à répondre sous charge verra son crawl rate plafonné par Google.

Simuler la charge de crawl

Utilisez un outil de load testing pour envoyer des requêtes concurrentes sur les URLs les plus critiques :

# Avec Apache Bench (ab) — test rapide
# 100 requêtes, 10 en parallèle, sur une page catégorie lourde
ab -n 100 -c 10 -H "User-Agent: Googlebot" \
  https://staging.votresite.fr/categorie/chaussures-homme/

# Avec k6 pour un test plus réaliste (crawl de multiples URLs)
# Installez k6 : brew install k6 (macOS) / snap install k6 (Linux)

Visez un TTFB (Time To First Byte) sous les 200ms pour les pages HTML en conditions de charge. Au-delà de 500ms, Googlebot ralentit significativement son crawl. Au-delà de 2 secondes, vous avez un problème d'infrastructure qui impactera directement l'indexation post-launch.

Vérifier le comportement des caches

Le staging tourne souvent sans cache (Varnish, Redis, CDN) ou avec un cache mal configuré. C'est un faux positif massif : les temps de réponse en staging ne reflètent pas la production.

Inversement, si vous activez le cache sur le staging, vérifiez que les pages de test ne sont pas servies depuis un cache périmé. Un piège fréquent : vous corrigez un canonical, mais le CDN staging sert encore la version cachée pendant 24h. Purgez systématiquement le cache entre chaque itération de test.

Crawl budget et découvrabilité

Lancez un crawl Screaming Frog en mode "List" (avec la liste complète de vos URLs de production) ET en mode "Spider" (en laissant le crawler découvrir les pages par les liens internes). Comparez les deux :

Les URLs présentes en mode List mais absentes en mode Spider sont des pages orphelines — aucun lien interne n'y mène. Si ces pages avaient du trafic en production, elles le perdront.
Les URLs découvertes en mode Spider mais absentes de votre sitemap doivent y être ajoutées (ou bloquées via robots.txt si elles ne doivent pas être indexées).

Sur un site de 22 000 pages, cette comparaison révèle typiquement 5 à 15% de pages orphelines après une migration. C'est souvent lié à une refonte de la navigation (mega menu, filtres de catégories) qui a supprimé des chemins de liens sans que personne ne s'en rende compte.

Automatiser les tests avec une CI/CD pipeline

Les tests manuels ne scalent pas. Si votre migration implique des déploiements quotidiens sur le staging pendant 3 mois, vous avez besoin de tests SEO automatisés dans votre pipeline CI/CD.

Tests SEO dans GitHub Actions / GitLab CI

Intégrez des vérifications SEO basiques comme étape de votre pipeline de déploiement :

# .github/workflows/seo-checks.yml
name: SEO Regression Tests

on:
  push:
    branches: [staging, develop]

jobs:
  seo-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Wait for deployment
        run: |
          echo "Waiting for staging deployment..."
          sleep 60
          # Vérifier que le staging répond
          STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
            -u "${{ secrets.STAGING_USER }}:${{ secrets.STAGING_PASS }}" \
            https://staging.votresite.fr/)
          if [ "$STATUS" != "200" ]; then
            echo "Staging not responding (HTTP $STATUS)"
            exit 1
          fi

      - name: Check critical pages SEO tags
        run: |
          ERRORS=0
          
          # Liste des pages critiques (top 20 trafic)
          PAGES=(
            "/"
            "/categorie/chaussures-homme"
            "/categorie/chaussures-femme"
            "/produit/nike-air-max-90"
            "/guide/taille-chaussures"
          )
          
          for PAGE in "${PAGES[@]}"; do
            HTML=$(curl -s \
              -u "${{ secrets.STAGING_USER }}:${{ secrets.STAGING_PASS }}" \
              "https://staging.votresite.fr${PAGE}")
            
            # Vérifier la présence d'un title
            if ! echo "$HTML" | grep -q '<title>'; then
              echo "FAIL: Missing <title> on ${PAGE}"
              ERRORS=$((ERRORS + 1))
            fi
            
            # Vérifier la présence d'un canonical
            if ! echo "$HTML" | grep -q 'rel="canonical"'; then
              echo "FAIL: Missing canonical on ${PAGE}"
              ERRORS=$((ERRORS + 1))
            fi
            
            # Vérifier que le canonical ne pointe PAS vers staging
            if echo "$HTML" | grep -q 'canonical.*staging\.'; then
              echo "FAIL: Canonical points to staging on ${PAGE}"
              ERRORS=$((ERRORS + 1))
            fi
            
            # Vérifier l'absence de noindex
            if echo "$HTML" | grep -q 'noindex'; then
              echo "FAIL: noindex found on ${PAGE}"
              ERRORS=$((ERRORS + 1))
            fi
            
            # Vérifier la présence d'un H1
            if ! echo "$HTML" | grep -q '<h1'; then
              echo "FAIL: Missing H1 on ${PAGE}"
              ERRORS=$((ERRORS + 1))
            fi
          done
          
          if [ "$ERRORS" -gt 0 ]; then
            echo "SEO CHECK FAILED: ${ERRORS} issues found"
            exit 1
          fi
          echo "All SEO checks passed"

      - name: Validate sitemap
        run: |
          SITEMAP=$(curl -s \
            -u "${{ secrets.STAGING_USER }}:${{ secrets.STAGING_PASS }}" \
            "https://staging.votresite.fr/sitemap.xml")
          
          # Vérifier que le sitemap est du XML valide
          echo "$SITEMAP" | xmllint --noout - 2>&1
          if [ $? -ne 0 ]; then
            echo "FAIL: sitemap.xml is not valid XML"
            exit 1
          fi
          
          # Compter les URLs
          URL_COUNT=$(echo "$SITEMAP" | grep -c '<loc>')
          echo "Sitemap contains ${URL_COUNT} URLs"
          
          # Alerter si le nombre chute significativement
          # (stockez le count attendu en variable d'env ou fichier)
          EXPECTED_MIN=18000
          if [ "$URL_COUNT" -lt "$EXPECTED_MIN" ]; then
            echo "FAIL: Sitemap has ${URL_COUNT} URLs, expected at least ${EXPECTED_MIN}"
            exit 1
          fi

Ce pipeline bloque le déploiement si une page critique perd son title, son canonical, ou si un noindex apparaît accidentellement. C'est un filet de sécurité minimal mais efficace.

Pour aller plus loin, des outils de monitoring continu comme Seogard détectent automatiquement ces régressions entre deux crawls, avec des alertes en temps réel. L'avantage par rapport à un script CI/CD maison : la couverture s'étend à l'ensemble du site, pas seulement aux pages que vous avez pensé à lister.

Les edge cases qui piègent les équipes expérimentées

Même avec une méthodologie solide, certains problèmes ne se révèlent qu'en conditions spécifiques.

Le piège du DNS et des certificats SSL

Le jour du launch, le flip DNS change la résolution de votre domaine. Mais les CDN, les certificats SSL et les configurations HSTS ont des caches propres. Testez le parcours complet :

Le certificat SSL du staging couvre-t-il le domaine de production ? Si vous utilisez un certificat wildcard *.votresite.fr, pas de problème. Avec Let's Encrypt et un certificat dédié, vous devrez le provisionner avant le flip.
Les en-têtes HSTS du staging correspondent-ils à ceux de la production ? Un max-age trop court sur le staging qui se propage en production peut temporairement casser le HTTPS.

Les contenus conditionnels

Certains sites affichent du contenu différent selon la géolocalisation IP, le device, ou des cookies. Si votre staging ne réplique pas ces conditions, vous ne testez qu'une fraction du site. Vérifiez en particulier :

Les variantes mobile/desktop si vous utilisez du dynamic serving (rare aujourd'hui, mais encore présent sur des sites legacy)
Les pages localisées servies via IP geolocation plutôt que hreflang
Les messages de consentement cookies qui injectent du JavaScript bloquant le rendering

Le timing post-launch

Après le go-live, certains problèmes n'apparaissent qu'au moment où Google recrawle effectivement les pages — ce qui peut prendre 24 à 72 heures pour les pages les plus crawlées, et plusieurs semaines pour les pages profondes. Ne déclarez pas victoire le jour du launch. Surveillez quotidiennement les rapports Coverage/Indexing de Search Console pendant au minimum 4 semaines. Si des problèmes identifiés en staging comme les soft 404 ou les erreurs d'indexation n'ont pas été corrigés, les conséquences sur le trafic peuvent être drastiques.

Les structured data oubliées

Les données structurées (Product, Article, BreadcrumbList, FAQ, Organization) sont souvent générées dynamiquement et facilement cassées lors d'une migration. Validez-les sur le staging avec le Rich Results Test pour chaque template. Google a d'ailleurs récemment retiré les résultats enrichis FAQ de la recherche pour la plupart des sites — vérifiez si vos schemas FAQ sont encore pertinents avant de dépenser de l'énergie à les migrer.

Scénario complet : migration e-commerce 18K pages

Pour rendre la méthodologie concrète, voici le déroulé d'un stress-test staging sur un cas réel.

Contexte : site e-commerce outdoor, 18 200 pages indexées, migration de PrestaShop 1.7 vers Shopify Plus avec un thème custom. Trafic organique mensuel : 340 000 sessions. Top 3 catégories représentant 62% du trafic.

Semaine 1 — Setup : import de la base produit complète dans le staging Shopify. Configuration de l'auth HTTP via le proxy Cloudflare Workers. Crawl de référence production avec Screaming Frog (18