Migration de site : checklist SEO des redirections

Le vrai coût d'une migration mal préparée

Un site e-commerce de 18 000 pages migre de Magento 1 vers Shopify. Trois semaines après le switch DNS, le trafic organique a chuté de 47 %. Le coupable : 4 200 URLs de fiches produits qui retournent un 404, et 1 800 redirections qui pointent vers la homepage au lieu de la page équivalente. Six mois plus tard, le site n'a toujours pas retrouvé son niveau d'avant migration. Ce scénario est d'une banalité affligeante — et il est évitable à 100 % avec un plan de redirection rigoureux.

La redirection est le nerf de la guerre d'une migration. Le reste — nouvelle arborescence, refonte design, changement de CMS — peut être corrigé après coup. Les redirections ratées, elles, déclenchent une cascade de dégâts : perte d'équité de liens, désindexation massive, signaux de qualité dégradés. Ce qui suit est le plan de bataille complet, étape par étape, pour éviter ça.

Phase 1 : inventaire exhaustif des URLs source

Avant de toucher quoi que ce soit, vous devez savoir exactement ce que vous avez. Pas "à peu près 12 000 pages". Exactement.

Crawl complet du site actuel

Lancez Screaming Frog (ou Sitebulb, ou un crawler custom) sur l'intégralité du site en production. Configuration critique :

Crawl depth : illimité. Si votre site a des pages orphelines accessibles uniquement via le sitemap, le crawler ne les trouvera pas par le crawl seul.
Respect robots.txt : désactivé pour cet audit. Vous devez voir tout, y compris les pages bloquées au crawl que Google pourrait avoir indexées via des liens externes.
Inclusion du sitemap : injectez tous vos sitemaps XML dans le crawl pour capturer les URLs qui ne sont pas liées dans la navigation.

Exportez la liste complète des URLs avec leur status code, leur canonical, leur indexabilité (meta robots), et le nombre de liens internes entrants.

Compléter avec les données d'indexation réelle

Le crawl seul ne suffit pas. Google indexe des URLs que votre crawler ne voit pas — anciennes URLs encore en index, pages accessibles uniquement via des backlinks externes.

Récupérez les données de Google Search Console (Performance > Pages) pour les 16 derniers mois. Exportez également le rapport de couverture d'index. Croisez ces données avec votre crawl :

# Extraire les URLs uniques de Search Console et du crawl, identifier les écarts
comm -23 <(sort gsc_urls.txt) <(sort crawl_urls.txt) > urls_in_gsc_not_in_crawl.txt
wc -l urls_in_gsc_not_in_crawl.txt
# Résultat typique sur un site de 18K pages : 800 à 2000 URLs fantômes

Ces "URLs fantômes" — présentes dans l'index Google mais absentes de votre crawl — sont exactement celles que la plupart des plans de migration oublient. Elles représentent souvent d'anciennes pages produits supprimées, des URLs avec paramètres, des versions paginées. Si elles reçoivent du trafic ou des backlinks, elles doivent être redirigées.

Données backlinks

Récupérez vos backlinks depuis Ahrefs, Majestic, ou la Search Console (Liens > Liens externes). Identifiez toutes les URLs de destination qui reçoivent au moins un lien externe. Ces URLs sont prioritaires dans votre plan de redirection — chaque 404 sur une URL avec des backlinks détruit de l'équité de lien de manière irréversible.

Le livrable de cette phase : un fichier CSV consolidé avec chaque URL source, son status actuel, sa canonical, son trafic organique mensuel moyen, et son nombre de backlinks. C'est votre bible de migration.

Phase 2 : construire le mapping de redirection

Le mapping est l'opération la plus chronophage et la plus critique. C'est ici que les équipes font le plus d'erreurs, souvent par manque de temps ou par excès de confiance dans des scripts automatiques.

Règle d'or : chaque URL source doit pointer vers la page la plus pertinente

Pas vers la homepage. Pas vers la catégorie parente "par défaut". Vers la page qui répond à la même intention utilisateur. Si /chaussures-homme/nike-air-max-90-blanc-42 disparaît et que le produit existe encore sous /homme/sneakers/nike-air-max-90?couleur=blanc&taille=42, c'est cette URL la cible. Si le produit n'existe plus du tout, redirigez vers la sous-catégorie la plus proche (/homme/sneakers/nike/), pas vers /homme/ et encore moins vers /.

Google le dit explicitement dans sa documentation sur les migrations de site : les redirections vers la homepage sont traitées comme des soft 404.

Automatiser le matching, valider manuellement

Sur un site de 18 000 pages, le mapping manuel n'est pas viable. Utilisez un script de matching par similarité d'URL et de contenu :

import csv
from difflib import SequenceMatcher

def similarity(a, b):
    return SequenceMatcher(None, a.lower(), b.lower()).ratio()

# Chargement des URLs source et destination
with open('source_urls.csv') as f:
    sources = [row['url'] for row in csv.DictReader(f)]

with open('destination_urls.csv') as f:
    destinations = [row['url'] for row in csv.DictReader(f)]

mappings = []
for src in sources:
    best_match = max(destinations, key=lambda dst: similarity(src, dst))
    score = similarity(src, best_match)
    mappings.append({
        'source': src,
        'destination': best_match,
        'confidence': round(score, 3),
        'review': 'AUTO' if score > 0.75 else 'MANUAL'
    })

with open('redirect_mapping.csv', 'w', newline='') as f:
    writer = csv.DictWriter(f, fieldnames=['source', 'destination', 'confidence', 'review'])
    writer.writeheader()
    writer.writerows(mappings)

# Résultat : chaque mapping avec un score de confiance
# Tout ce qui est en dessous de 0.75 → vérification manuelle obligatoire

Ce script est un point de départ. Pour un matching plus robuste, comparez aussi les title tags, les H1, et le contenu textuel principal entre source et destination. Sur notre migration Magento → Shopify de 18 000 pages, ce type d'approche a permis de mapper automatiquement 72 % des URLs avec un score de confiance supérieur à 0.85. Les 28 % restants ont nécessité une revue manuelle — principalement des produits discontinués et des pages de contenu dont la structure avait radicalement changé.

Type de redirection : 301, pas 302

Sauf cas exceptionnel (migration temporaire pour A/B test, par exemple), utilisez des redirections 301. Une migration est un changement permanent. La 301 transfère l'équité de lien. La 302, en théorie aussi selon Google, mais pourquoi prendre le risque ? La doc officielle recommande explicitement la 301 pour les changements d'URL permanents.

Gérer les cas particuliers

Pages paginées : si /category/page/2 n'existe plus parce que vous avez implémenté un infinite scroll, redirigez vers /category/. Les stratégies de pagination SEO ont évolué, mais les anciennes URLs paginées doivent être couvertes.

Pages avec paramètres : /produits?cat=homme&sort=prix → mappez au moins les combinaisons de paramètres qui ont du trafic ou des backlinks. Les autres peuvent être redirigées vers l'URL canonique de la catégorie.

Pages noindex : vous pourriez penser qu'une page noindex n'a pas besoin de redirection. Faux. Si elle a des backlinks, l'équité de lien passe quand même. Redirigez-la. Pour comprendre les implications, consultez le guide sur meta robots noindex/nofollow.

Phase 3 : implémentation technique des redirections

Le mapping est prêt. Passons à l'implémentation. Le choix de l'implémentation dépend de votre stack technique.

Implémentation serveur (Nginx)

Pour un site de volume significatif, les redirections au niveau serveur sont plus performantes que les redirections applicatives. Elles s'exécutent avant que le framework ne soit chargé — temps de réponse minimal.

# /etc/nginx/conf.d/migration-redirects.conf
# Généré automatiquement à partir du mapping CSV

# Redirections exactes — les plus performantes
map $request_uri $redirect_uri {
    default "";
    /ancien-chemin/produit-a.html   /nouveau/produit-a;
    /ancien-chemin/produit-b.html   /nouveau/produit-b;
    /blog/ancien-article             /articles/ancien-article;
    # ... 15 000 lignes générées par script
}

server {
    listen 443 ssl;
    server_name shop.example.fr;

    # Appliquer les redirections exactes
    if ($redirect_uri != "") {
        return 301 $redirect_uri;
    }

    # Règles regex pour les patterns systématiques
    # Ex : toutes les anciennes URLs de catégorie suivaient /cat/{id}/{slug}
    # Nouvelles URLs : /categories/{slug}
    location ~ ^/cat/\d+/(.+)$ {
        return 301 /categories/$1;
    }

    # Fallback : anciennes URLs qui n'ont pas de mapping → 410 Gone
    # Mieux qu'un 404 : signale explicitement à Google que la page n'existe plus
    location /ancien-chemin/ {
        return 410;
    }

    # ... reste de la config
}

Quelques points techniques importants :

La directive map de Nginx utilise une table de hash en mémoire. 15 000 entrées consomment environ 2-3 Mo de RAM — négligeable. Les performances restent constantes quel que soit le nombre d'entrées, contrairement à une cascade de rewrite.
Préférez les matches exacts via map aux regex quand c'est possible. Chaque regex est évaluée séquentiellement ; 15 000 regex seraient un désastre de performance.
Les règles regex (bloc location ~) sont réservées aux patterns systématiques qui couvrent des centaines d'URLs avec une seule règle.

Implémentation applicative (Next.js / Vercel)

Si votre migration cible un framework JS avec SSR/SSG, les redirections se configurent souvent dans le fichier de config du framework. Sur Next.js :

// next.config.js
const redirects = require('./redirects.json');
// redirects.json contient le mapping généré : [{ source, destination, permanent }]

module.exports = {
  async redirects() {
    return redirects.map(({ source, destination }) => ({
      source,
      destination,
      permanent: true, // 301
    }));
  },
};

Attention : sur Vercel, le fichier next.config.js est limité à 1024 redirections par défaut. Au-delà, utilisez un middleware Edge ou le fichier vercel.json avec les redirections au niveau de la plateforme. Pour un site de 18 000 pages, l'approche middleware est souvent nécessaire :

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

// Map chargée en mémoire au démarrage de l'Edge Function
const redirectMap: Record<string, string> = {
  '/ancien-chemin/produit-a.html': '/nouveau/produit-a',
  '/ancien-chemin/produit-b.html': '/nouveau/produit-b',
  // ... généré depuis le CSV
};

export function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl;
  const destination = redirectMap[pathname];

  if (destination) {
    return NextResponse.redirect(
      new URL(destination, request.url),
      301
    );
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/ancien-chemin/:path*', '/cat/:path*', '/blog/:path*'],
};

Le matcher est essentiel : sans lui, le middleware s'exécute sur chaque requête, y compris les assets statiques. Limitez-le aux patterns d'URLs sources pour minimiser la latence.

Le choix entre SSR, SSG et ISR pour le nouveau site a un impact direct sur la façon dont Google crawlera vos pages post-migration. Si ce sujet vous concerne, l'article sur les modes de rendering et leur impact SEO détaille les trade-offs.

Éviter les chaînes de redirections

Un piège classique lors des migrations successives : l'URL A redirige vers B (migration de 2023), et maintenant B doit rediriger vers C (migration de 2026). Résultat : A → B → C, une chaîne à deux sauts. Google suit jusqu'à 10 redirections, mais chaque saut ajoute de la latence et dilue potentiellement l'équité de lien.

Avant d'implémenter vos nouvelles redirections, vérifiez que les cibles ne sont pas elles-mêmes des redirections. Si A → B existait déjà, mettez à jour vers A → C directement. Les chaînes de redirections sont un ennemi silencieux qui s'accumule au fil des migrations.

Phase 4 : validation pré-déploiement

Ne déployez jamais un plan de redirection en production sans l'avoir testé en staging.

Test automatisé du mapping complet

Écrivez un script qui vérifie chaque ligne du mapping. L'objectif : 100 % de couverture, zéro exception.

#!/bin/bash
# test_redirects.sh — Valide l'intégralité du mapping sur l'environnement de staging
STAGING="https://staging.shop.example.fr"
ERRORS=0
TOTAL=0

while IFS=',' read -r source destination; do
    TOTAL=$((TOTAL + 1))
    # -o /dev/null pour ignorer le body, -s pour mode silencieux
    STATUS=$(curl -s -o /dev/null -w "%{http_code}" -L --max-redirs 1 "${STAGING}${source}")
    FINAL_URL=$(curl -s -o /dev/null -w "%{url_effective}" -L --max-redirs 5 "${STAGING}${source}")

    # Vérifier le code de réponse
    if [ "$STATUS" != "301" ] && [ "$STATUS" != "200" ]; then
        echo "FAIL [${STATUS}] ${source} → expected 301"
        ERRORS=$((ERRORS + 1))
    fi

    # Vérifier la destination finale
    if [[ "$FINAL_URL" != *"${destination}"* ]]; then
        echo "FAIL ${source} → landed on ${FINAL_URL}, expected ${destination}"
        ERRORS=$((ERRORS + 1))
    fi
done < redirect_mapping.csv

echo "Tested: ${TOTAL} | Errors: ${ERRORS}"
exit $ERRORS

Intégrez ce script dans votre pipeline CI/CD. La migration ne passe pas tant que ERRORS n'est pas à zéro.

Vérification des edge cases

Au-delà du mapping principal, testez manuellement :

Trailing slashes : /ancien-chemin/produit/ vs /ancien-chemin/produit — les deux doivent résoudre.
Casse des URLs : /Ancien-Chemin/Produit-A.html → certains serveurs sont case-sensitive.
Encodage : /catégorie/été-2025 → vérifiez le comportement avec les caractères encodés (%C3%A9t%C3%A9).
Protocole : si vous migrez aussi de HTTP vers HTTPS (ou inversement), les redirections doivent couvrir les deux variantes.
Avec/sans www : www.shop.example.fr/ancien et shop.example.fr/ancien doivent tous deux atteindre la bonne destination.

Phase 5 : le jour J et la première semaine

Checklist de déploiement (jour J)

Déployer les redirections en premier, avant de basculer le DNS ou de changer l'applicatif. Testez les redirections sur la nouvelle infra.
Mettre à jour le sitemap XML : le nouveau sitemap ne doit contenir que les nouvelles URLs. Retirez les anciennes. Soumettez-le immédiatement dans Search Console. Consultez les bonnes pratiques du sitemap XML pour la structure optimale.
Vérifier les meta tags sur les nouvelles pages : titles, descriptions, canonicals, meta robots. Une migration est le moment où les meta tags critiques se perdent le plus facilement. Un canonical qui pointe vers l'ancienne URL est un désastre silencieux.
Soumettre un changement d'adresse dans Search Console si le domaine change (via l'outil Changement d'adresse).
Forcer un recrawl des pages les plus importantes via l'API URL Inspection ou manuellement dans Search Console.

Monitoring de la première semaine

Les 7 premiers jours sont critiques. Google va recrawler massivement votre site suite aux redirections et au nouveau sitemap.

Ce qu'il faut surveiller quotidiennement :

Taux de crawl dans Search Console (Paramètres > Statistiques d'exploration). Un pic de crawl dans les 24-48h est normal et souhaitable. Une chute est un signal d'alarme.
Erreurs 404/410 dans le rapport de couverture. Si le nombre explose, votre mapping a des trous.
Pages indexées : le nombre total ne devrait pas chuter de plus de 5-10 % temporairement. Une chute de 30 %+ signale un problème systémique. Un excès de pages indexées peut aussi devenir un problème — c'est le sujet de l'index bloat.
Trafic organique : une baisse de 10-15 % la première semaine est normale. Au-delà de 25 %, investiguez immédiatement.
Positions sur vos top keywords : vérifiez quotidiennement les 50 mots-clés qui génèrent le plus de trafic.

Un outil de monitoring comme SEOGard détecte automatiquement les régressions de meta tags, les canonicals cassés et les pages qui passent subitement en noindex — exactement le type d'anomalie qui passe sous le radar lors d'une migration et qui détruit le trafic en silence.

Phase 6 : post-migration — les 3 mois suivants

La migration ne se termine pas le jour J. La phase de consolidation dure 2 à 3 mois.

Semaine 2 à 4 : traquer les URLs orphelines

Analysez les logs serveur pour identifier les URLs qui reçoivent encore du trafic bot (Googlebot, Bingbot) sans être redirigées. Ce sont les trous de votre mapping.

# Extraire les URLs qui retournent 404 à Googlebot depuis les access logs
grep "Googlebot" /var/log/nginx/access.log \
  | grep " 404 " \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn \
  | head -50

Chaque URL qui apparaît dans cette liste est une page que Google essaie encore de crawler. Si elle a de la valeur (backlinks, ancien trafic), ajoutez-la au mapping de redirection. Si elle n'en a aucune, un 410 Gone explicite accélérera sa suppression de l'index.

Mois 1 à 3 : surveiller la récupération du trafic

Comparez le trafic organique semaine par semaine avec la même période de l'année précédente (pas avec le mois précédent — vous risquez de comparer avec des variations saisonnières).

Modèle de récupération typique pour une migration bien exécutée :

Semaine 1 : -10 à -20 % (normal, Google réévalue)
Semaine 2-3 : stabilisation, début de récupération
Semaine 4-6 : retour à 90-95 % du trafic pré-migration
Mois 2-3 : retour complet, voire amélioration si la nouvelle structure est meilleure

Si vous stagnez en dessous de 80 % après 6 semaines, les causes les plus fréquentes sont :

Redirections vers la homepage traitées comme soft 404 par Google — vérifiez avec l'outil d'inspection d'URL.
Canonicals qui pointent vers les anciennes URLs — une erreur de templating qui affecte des milliers de pages.
Pages critiques passées en noindex par erreur — un header X-Robots-Tag: noindex oublié en staging qui fuite en production.
Rendu JavaScript cassé — si votre nouveau site est un SPA ou utilise du SSR, vérifiez que Google voit le contenu. Le problème de page blanche sur les SPA est amplifié lors d'une migration.

Quand supprimer les redirections ?

La réponse courte : ne les supprimez pas. La réponse nuancée : vous pouvez supprimer les redirections d'URLs qui ne reçoivent plus aucun crawl (bot ou humain) depuis 6 mois minimum, ET qui n'ont aucun backlink externe. En pratique, le coût de maintenance de 15 000 règles de redirection dans une directive map Nginx est quasi nul. Le risque de supprimer une redirection encore utile est bien plus élevé que le bénéfice de "faire le ménage".

Retour sur le cas e-commerce : ce qui aurait changé

Reprenons notre site Magento de 18 000 pages. Avec ce processus appliqué rigoureusement :

Phase 1 aurait identifié les 2 000 URLs fantômes en index (absentes du crawl mais avec du trafic).
Phase 2 aurait mappé les 4 200 fiches produits manquantes au lieu de les laisser en 404.
Phase 3 aurait implémenté les 1 800 redirections "homepage" vers les bonnes sous-catégories.
Phase 4 aurait détecté les 340 redirections cassées (cibles 404) avant la mise en production.
Phase 5 aurait permis de corriger les 120 URLs oubliées identifiées dans les logs Googlebot dès la première semaine.

Résultat réaliste : une baisse de trafic contenue à 12-15 % la première semaine, avec un retour complet en 5 à 6 semaines, au lieu de 47 % de perte et 6 mois de galère.

Le plan de redirection est le plan de migration

Tout le reste — design, performance, nouvelles fonctionnalités — n'a aucune importance si Google ne retrouve pas vos pages. Le mapping URL-par-URL, aussi fastidieux soit-il, est l'investissement qui sépare une migration réussie d'un désastre SEO. Automatisez ce qui peut l'être, validez manuellement ce qui doit l'être, et monitorez en continu les 3 mois qui suivent. Un outil comme SEOGard rend cette surveillance post-migration systématique au lieu d'espérer qu'aucune régression ne passe entre les mailles du filet.