Un e-commerce mode de 18 000 pages migre de Magento 1 vers Shopify. Recette validée, design approuvé, Go Live un vendredi soir. Le lundi matin, le trafic organique a chuté de 63%. Cause : 4 200 redirections 301 manquantes, un noindex global resté dans le thème Shopify, et des URLs de catégories complètement restructurées sans mapping. Trois mois pour revenir au niveau d'avant.
Ce scénario se reproduit chaque semaine. Voici les 20 vérifications qui l'auraient empêché.
Avant la refonte : préparer le terrain
1. Crawl complet du site existant
Avant de toucher quoi que ce soit, vous avez besoin d'un instantané exhaustif de l'état actuel. Pas un export Search Console partiel — un crawl complet avec Screaming Frog ou Sitebulb qui capture chaque URL, son status code, son title, sa meta description, ses canonicals, ses hreflang, son contenu indexable.
Pour un site de 18 000 pages, configurez Screaming Frog avec un crawl respectueux mais complet :
# Export CLI Screaming Frog — crawl complet avec sauvegarde
cd /Applications/Screaming\ Frog\ SEO\ Spider.app/Contents/MacOS/
./ScreamingFrogSEOSpiderLauncher \
--crawl https://www.monsite-ecommerce.fr \
--headless \
--save-crawl /exports/pre-migration-crawl.seospider \
--export-tabs "Internal:All,Response Codes:All,Page Titles:All,Meta Description:All,Canonicals:All,Directives:All,Hreflang:All" \
--output-folder /exports/pre-migration/ \
--max-crawl-depth 0Ce fichier .seospider est votre assurance vie. Vous y reviendrez à chaque anomalie post-migration. Exportez les données en CSV et versionnez-les dans Git — vous aurez besoin de comparer avant/après sur chaque dimension.
2. Identifier les pages à forte valeur SEO
Toutes les pages ne se valent pas. Croisez trois sources pour établir votre liste de pages critiques :
- Search Console : pages avec impressions > 100/mois sur 12 mois (pas 3 mois — vous voulez capturer la saisonnalité)
- Analytics : pages avec trafic organique > 0 sur 12 mois
- Backlinks : pages avec au moins un domaine référent (export Ahrefs ou Majestic)
L'union de ces trois ensembles constitue vos pages "intouchables". Chacune doit avoir une URL de destination mappée dans la nouvelle architecture. Si une page à 200 backlinks disparaît sans redirection, vous perdez toute l'autorité accumulée.
3. Cartographier le mapping de redirections
C'est le travail le plus chronophage et le plus critique. Chaque ancienne URL doit pointer vers la meilleure correspondance sur le nouveau site. Pas vers la homepage — vers la page sémantiquement la plus proche.
Pour un site de 18 000 pages, le mapping manuel est irréaliste. Automatisez la base avec un script qui matche par slug similarity :
import csv
from difflib import SequenceMatcher
def best_match(old_url, new_urls, threshold=0.6):
old_path = old_url.split('/')[-1]
best = None
best_ratio = 0
for new_url in new_urls:
new_path = new_url.split('/')[-1]
ratio = SequenceMatcher(None, old_path, new_path).ratio()
if ratio > best_ratio:
best_ratio = ratio
best = new_url
return best if best_ratio >= threshold else None
# Charger les URLs
with open('old_urls.csv') as f:
old_urls = [row['url'] for row in csv.DictReader(f)]
with open('new_urls.csv') as f:
new_urls = [row['url'] for row in csv.DictReader(f)]
# Générer le mapping
with open('redirect_map.csv', 'w', newline='') as f:
writer = csv.writer(f)
writer.writerow(['old_url', 'new_url', 'confidence'])
for old in old_urls:
match = best_match(old, new_urls)
confidence = 'auto' if match else 'MANUAL_REVIEW'
writer.writerow([old, match or '', confidence])Résultat : un CSV avec les matchs automatiques (confidence auto) et les URLs sans correspondance (confidence MANUAL_REVIEW). Les MANUAL_REVIEW passent entre les mains d'un humain qui connaît le catalogue. Ce script couvre typiquement 60-70% des cas sur un e-commerce dont les slugs produits sont conservés. Les 30-40% restants — catégories renommées, pages CMS restructurées — nécessitent un mapping manuel.
4. Auditer les backlinks entrants
Exportez le profil de liens complet. Identifiez les pages qui reçoivent des backlinks et qui changent d'URL. Ces pages sont priorité absolue dans le mapping de redirections. Un lien du Monde.fr ou d'un blog influent de votre secteur qui atterrit sur une 404 est une perte sèche d'autorité.
Vérifiez aussi les backlinks qui pointent vers des URLs déjà en 404 ou en redirect chain sur le site actuel. La refonte est l'occasion de nettoyer ces chaînes.
5. Documenter la structure technique actuelle
Notez tout ce qui n'est pas visible dans un crawl standard :
- Règles de réécriture dans
.htaccessou la config Nginx - Redirections existantes (il y en a souvent des centaines accumulées au fil des années)
- Configuration des canonicals (sont-ils gérés côté app, côté serveur, ou par un plugin ?)
- Sitemaps : combien, quelle fréquence de mise à jour, quelles URLs incluent-ils ?
- Fichier
robots.txtexact - Headers HTTP custom (X-Robots-Tag, cache headers)
Tout cela doit être reproduit ou consciemment modifié sur le nouveau site.
Pendant le développement : les contrôles en staging
6. Environnement de staging bloqué aux robots
Avant toute chose : votre environnement de staging ne doit pas être indexable. Ça paraît évident, mais c'est une source classique de contenu dupliqué. Deux protections complémentaires :
# nginx.conf — staging
server {
listen 443 ssl;
server_name staging.monsite-ecommerce.fr;
# Protection par mot de passe
auth_basic "Staging";
auth_basic_user_file /etc/nginx/.htpasswd;
# Blocage robots en backup
add_header X-Robots-Tag "noindex, nofollow" always;
location /robots.txt {
return 200 "User-agent: *\nDisallow: /\n";
}
}Le auth_basic est la protection la plus fiable : Googlebot ne peut pas crawler un site protégé par mot de passe HTTP. Le X-Robots-Tag et le robots.txt sont des filets de sécurité supplémentaires. N'utilisez jamais une simple balise meta noindex en staging — le jour du Go Live, quelqu'un oubliera de la retirer. C'est exactement ce qui s'est passé dans le scénario d'introduction.
7. Vérifier le rendu côté serveur (SSR)
Si vous migrez vers un framework JavaScript (Next.js, Nuxt, SvelteKit), le SSR est non-négociable pour le SEO. Googlebot peut exécuter du JavaScript, mais avec des limites de rendu, un délai de queue, et des cas d'échec silencieux.
Testez chaque template type avec curl pour vérifier que le HTML contient le contenu critique :
# Vérifier que le H1 est dans le HTML servi (pas injecté par JS)
curl -s https://staging.monsite-ecommerce.fr/robes/robe-longue-fleurie \
| grep -o '<h1[^>]*>.*</h1>'
# Vérifier la présence de la meta description
curl -s https://staging.monsite-ecommerce.fr/robes/robe-longue-fleurie \
| grep -o '<meta name="description"[^>]*>'
# Comparer le DOM servi vs DOM après exécution JS (via Puppeteer)
npx puppeteer-cli screenshot \
--url https://staging.monsite-ecommerce.fr/robes/robe-longue-fleurie \
--full-page \
--output ssr-check.pngSi le curl ne retourne pas le H1 et la meta description, votre SSR est cassé ou inexistant. C'est le type de régression qu'un outil comme Chrome DevTools permet de diagnostiquer en inspectant la source vs le DOM rendu. Pour un monitoring continu, un outil comme Seogard détecte automatiquement la disparition de balises critiques entre deux crawls.
Si vous migrez vers un headless CMS, portez une attention particulière à la façon dont le contenu est servi : un front découplé qui fetch tout en client-side est invisible pour les crawlers qui n'exécutent pas le JavaScript.
8. Valider les balises meta sur chaque template
Crawlez votre staging avec Screaming Frog. Comparez les titles, meta descriptions et canonicals entre ancien site et nouveau site pour chaque catégorie de page (homepage, catégorie, produit, article, page CMS). Les problèmes les plus fréquents :
- Title générique type "Mon Site | Page" au lieu du title optimisé
- Meta description vide ou identique sur toutes les pages d'un même template
- Canonical qui pointe vers l'URL de staging au lieu de la production
- Canonical auto-référent manquant
9. Contrôler la pagination et l'infinite scroll
Si la nouvelle version remplace la pagination par de l'infinite scroll ou du "Load More", chaque page de résultats doit rester accessible via une URL crawlable. Sans cela, les produits au-delà de la première "page" deviennent invisibles pour Googlebot. Le sujet est suffisamment complexe pour justifier un traitement dédié — référez-vous à notre guide complet sur l'infinite scroll et le SEO.
10. Tester les données structurées
Si votre ancien site avait des données structurées (Product, Article, BreadcrumbList, FAQ), vérifiez qu'elles sont reproduites sur le nouveau site. Utilisez le test Rich Results de Google sur les URLs staging. Comparez le nombre de types de données structurées entre ancien et nouveau. Une migration qui fait disparaître les rich snippets produit un effet immédiat sur le CTR dans les SERPs.
11. Vérifier la performance (Core Web Vitals)
Une refonte qui dégrade les Core Web Vitals annule souvent les gains esthétiques. Testez avec Lighthouse CI sur vos templates principaux :
# Lighthouse CI — test de performance sur les templates critiques
npx lhci autorun --config=lighthouserc.json
# lighthouserc.json
{
"ci": {
"collect": {
"url": [
"https://staging.monsite-ecommerce.fr/",
"https://staging.monsite-ecommerce.fr/robes/",
"https://staging.monsite-ecommerce.fr/robes/robe-longue-fleurie",
"https://staging.monsite-ecommerce.fr/blog/guide-tailles"
],
"numberOfRuns": 3
},
"assert": {
"assertions": {
"categories:performance": ["error", {"minScore": 0.8}],
"first-contentful-paint": ["warn", {"maxNumericValue": 2000}],
"largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
"cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}]
}
}
}
}Intégrez ces checks dans votre pipeline CI/CD. Un LCP qui passe de 1.8s à 4.2s parce que le nouveau thème charge des images non optimisées, ça se détecte avant la mise en production — pas après. Pour aller plus loin sur l'intégration de ces vérifications dans votre workflow de déploiement, consultez notre article sur l'automatisation des checks SEO dans le CI/CD.
12. Vérifier le robots.txt et les sitemaps
Comparez le robots.txt actuel et celui du nouveau site. Vérifiez que les sitemaps sont générés, valides et contiennent les bonnes URLs (nouvelles URLs, pas les anciennes). Un sitemap qui référence les anciennes URLs après migration envoie Googlebot dans une boucle de redirections.
13. Auditer le maillage interne
Comparez le nombre de liens internes moyen par page entre ancien et nouveau site. Les refontes graphiques cassent souvent le maillage : un footer qui contenait 50 liens de catégories est remplacé par un design minimaliste avec 8 liens. Le mega-menu à 3 niveaux devient un hamburger menu. Résultat : des pages profondes qui passaient de 2 clics à 6 clics de la homepage.
Exportez le rapport "Inlinks" de Screaming Frog pour les deux versions. Si des pages stratégiques perdent plus de 50% de leurs liens entrants internes, corrigez l'architecture ou ajoutez des blocs de liens contextuels.
14. Contrôler le contenu thin et dupliqué
Une refonte est l'occasion de nettoyer les pages à faible valeur. Identifiez les pages avec moins de 300 mots de contenu unique, les pages quasi-dupliquées (filtres de catégories qui génèrent des centaines de combinaisons d'URL). Ces pages diluent le crawl budget et nuisent au SEO global — le problème du thin content est amplifié quand la nouvelle architecture multiplie les URLs paramétrées.
Le jour J : Go Live et vérifications immédiates
15. Déployer et tester les redirections
Le plan de redirections doit être actif dès la première seconde du Go Live. Testez immédiatement un échantillon de 50-100 URLs à forte valeur :
#!/bin/bash
# test-redirects.sh — vérifier le mapping de redirections post-deploy
while IFS=, read -r old_url new_url; do
status=$(curl -o /dev/null -s -w "%{http_code}" -L "$old_url")
final_url=$(curl -o /dev/null -s -w "%{url_effective}" -L "$old_url")
if [ "$status" != "200" ]; then
echo "ERREUR: $old_url → status $status"
elif [ "$final_url" != "$new_url" ]; then
echo "MISMATCH: $old_url → $final_url (attendu: $new_url)"
else
echo "OK: $old_url → $new_url"
fi
done < redirect_sample.csvCherchez spécifiquement :
- Les 404 (redirection manquante)
- Les redirect chains (301 → 301 → 200 : chaque maillon perd un peu de PageRank)
- Les redirect loops (301 → 301 → 301 → timeout)
- Les redirections vers la mauvaise page
Si vous migrez aussi le protocole (HTTP vers HTTPS), les redirections s'empilent. Notre checklist migration HTTPS couvre les pièges spécifiques à cette couche.
16. Retirer les blocages de staging
Vérification critique que tout le monde pense faire et que quelqu'un oublie toujours :
- Le
robots.txtde production autorise le crawl - Aucun
X-Robots-Tag: noindexn'est envoyé en production - Aucune balise
<meta name="robots" content="noindex">n'est présente dans le<head> - Le
auth_basicest désactivé
Testez en production, pas seulement dans votre code. Un reverse proxy, un CDN, ou un middleware peut injecter des headers que votre application ne contrôle pas. Si vous utilisez un CDN avec des edge functions, vérifiez que les règles de modification des réponses HTTP au niveau CDN ne bloquent pas les crawlers.
17. Soumettre les nouveaux sitemaps dans Search Console
Dès le Go Live :
- Ajoutez la propriété du nouveau site dans Search Console (si changement de domaine ou de protocole)
- Soumettez le sitemap mis à jour
- Utilisez l'outil "Inspection de l'URL" sur 10-15 pages stratégiques pour demander une indexation
- Si changement de domaine : utilisez l'outil "Changement d'adresse" dans Search Console
Ne supprimez pas l'ancienne propriété Search Console. Vous en aurez besoin pour comparer les données pendant au moins 6 mois. Les rapports souvent ignorés de Search Console sont particulièrement utiles dans cette phase pour détecter les problèmes d'indexation émergents.
18. Surveiller les erreurs de crawl en temps réel
Dans les 48 heures post Go Live, surveillez :
- Le rapport "Pages" (ex "Couverture") de Search Console : explosion des 404, des pages "explorées mais non indexées"
- Les logs serveur : Googlebot qui crawle des URLs anciennes et reçoit des 404
- Le taux de crawl : une chute brutale du crawl rate peut indiquer que Googlebot rencontre trop d'erreurs et ralentit
L'analyse de logs est le signal le plus rapide. Search Console a un délai de 24-48h minimum. Les logs, eux, sont en temps réel.
Après la refonte : monitoring post-migration
19. Comparer les KPIs semaine par semaine
Ne paniquez pas si le trafic baisse la première semaine — c'est normal le temps que Google recrawle et réindexe. Mais au-delà de 2-3 semaines, une baisse persistante indique un problème non résolu.
Suivez ces indicateurs dans Search Console et votre outil d'analytics, semaine par semaine :
- Nombre de pages indexées (doit revenir au niveau d'avant + les nouvelles pages)
- Impressions organiques par section du site (homepage, catégories, produits, blog)
- Position moyenne par groupe de mots-clés
- Taux de crawl Googlebot (logs serveur)
- Nombre de 404 crawlées par Googlebot
Si vous perdez 30% d'impressions sur les pages catégories mais que les pages produits sont stables, le problème est localisé : le mapping de redirections des catégories est probablement défectueux, ou le nouveau maillage interne ne pousse plus assez ces pages. Pour structurer ce suivi, notre guide sur les KPIs SEO technique à suivre détaille les métriques pertinentes et comment les automatiser.
20. Recrawl complet post-migration et comparaison différentielle
Deux semaines après le Go Live, lancez un crawl complet identique à celui du point 1. Comparez :
- Nombre total d'URLs crawlées (ancien vs nouveau)
- Distribution des status codes
- Pages avec title manquant ou changé de façon non intentionnelle
- Pages avec canonical incorrect
- Pages avec
noindexnon prévu - Pages orphelines (présentes dans le sitemap mais sans lien interne)
Cette comparaison différentielle est le filet de sécurité final. Sur un site de 18 000 pages, des régressions passent toujours entre les mailles — un template de page marque qui a perdu sa meta description, une redirection de catégorie saisonnière oubliée, un paramètre de filtre qui génère des milliers de pages dupliquées.
C'est précisément ce type de monitoring continu — détecter qu'une meta description a disparu ou qu'un canonical a changé entre deux crawls — que Seogard automatise. Plutôt que de lancer manuellement des crawls comparatifs, vous recevez une alerte dès qu'une régression apparaît.
Scénario complet : migration e-commerce Magento → Shopify
Pour rendre tout cela concret, voici le déroulé réel d'une migration bien exécutée :
Contexte : e-commerce de prêt-à-porter, 15 200 pages indexées (8 400 produits, 320 catégories, 180 articles blog, le reste en pages CMS et filtres). Trafic organique : 145 000 sessions/mois. Migration de Magento 1.9 vers Shopify Plus.
Semaine -8 à -4 : crawl complet Screaming Frog (durée : 4h12 pour 15 200 pages). Export backlinks Ahrefs : 2 340 domaines référents, dont 890 pointant vers des pages produits spécifiques. Identification de 3 200 pages à forte valeur (trafic + backlinks). Mapping automatisé : 67% des URLs matchées par slug similarity. 33% en revue manuelle (3 jours de travail à deux personnes).
Semaine -4 à -1 : développement sur staging protégé par auth_basic. Crawl du staging : détection de 48 pages avec meta description manquante (bug template collection), correction du thème Liquid. Test SSR : N/A (Shopify gère le rendu). Lighthouse : LCP moyen à 2.1s (acceptable). Données structurées Product validées sur 20 URLs échantillon.
Jour J (mardi 10h) : déploiement des 15 200 redirections via app Shopify (bulk import CSV). Test automatisé de 200 redirections : 3 erreurs détectées et corrigées en 30 minutes. Soumission sitemap. Vérification robots.txt. Monitoring logs : Googlebot commence à crawler à 11h47, taux normal.
Semaine +1 : baisse de 18% du trafic organique. Normal — Google recrawle et réévalue. 47 nouvelles 404 détectées dans Search Console (pages avec paramètres UTM ou URLs non nettoyées). Ajout de redirections complémentaires.
Semaine +3 : trafic revenu à 94% du niveau pré-migration. Les 6% manquants correspondent à des pages thin content qui n'ont intentionnellement pas été migrées.
Semaine +8 : trafic à 103% du niveau pré-migration, grâce à l'amélioration des Core Web Vitals et au nettoyage du contenu thin.
Le vrai coût d'une vérification manquée
Chaque point de cette checklist semble individuellemement simple. Le danger d'une refonte, c'est l'accumulation : un noindex oublié ici, 200 redirections manquantes là, un maillage interne appauvri, des canonicals qui pointent vers le staging. Chaque défaut pris isolément est mineur. Combinés, ils provoquent l'effondrement du trafic organique.
La clé : automatiser tout ce qui peut l'être (redirections, tests de régression, monitoring), et réserver le temps humain aux décisions qui nécessitent du jugement (mapping sémantique, arbitrages d'architecture, priorisation des pages). Intégrez vos vérifications SEO dans le pipeline CI/CD, crawlez votre staging aussi souvent que votre production, et mettez en place un monitoring différentiel permanent post-migration. C'est la seule façon de transformer une refonte d'un risque SEO en opportunité.