Plan de redirection SEO : le guide étape par étape, de l'inventaire aux tests

Un plan de redirection SEOSearch Engine Optimization. Ensemble des techniques visant à améliorer le positionnement d'un site web dans les résultats naturels des moteurs de recherche. est le fichier qui donne à chaque ancienne URLUniform Resource Locator. Adresse unique d'une page web. Une URL optimisée est courte, descriptive et contient le mot-clé. d'un site sa réponse après une refonteModification majeure du design ou de la structure d'un site. Risque SEO si mal gérée. ou une migration : une 301Redirection permanente transférant le jus SEO de l'ancienne URL vers la nouvelle. vers la page qui répond à la même requête, ou une 404Code HTTP indiquant qu'une page n'existe pas. Trop d'erreurs 404 nuisent au crawl budget. ou une 410 si rien ne la remplace. Il se construit en cinq étapes : inventaire, mapping, règles, tests avant la bascule, contrôle après.

Ce guide s'adresse à la personne qui tient le fichier pendant le projet, en général le responsable SEO, face à une équipe technique qui pose les règles. Il donne les colonnes du fichier, l'ordre des méthodes de correspondance, la règle à appliquer à chaque cas et deux scripts de test : le premier vérifie le fichier, le second interroge la préproduction puis la production.

Ce que contient un plan de redirection, et quand il en faut un

Un plan de redirection est un tableur à une ligne par ancienne URL, qui garde sa destination, son code HTTP, la méthode qui l'a trouvée et le résultat du test. Le serveur n'en lira que deux colonnes. Les autres servent à décider et à contrôler.

Toute migration n'en demande pas un complet. Un changement d'hébergeur ou le passage à un CDN, qui ne touche pas les URL visibles, n'en demande aucun. Google le dit aussi pour le cas suivant : si seul l'hôte change (de example.com à example.net), une redirection générique côté serveur suffit, sans liste d'URL. Le passage en HTTPS garde les chemins : une règle qui envoie chaque URL HTTP vers sa version HTTPS suffit.

Dès que les chemins bougent, avec une nouvelle arborescence, un CMS qui réécrit les URL ou une fusion de deux sites, il faut une décision par URL. Le plan de redirection est alors une pièce du projet, dont les autres étapes (préproduction, déclaration dans la Search Console, suivi) sont dans la checklist de migration SEO.

Les colonnes à prévoir, et l'étape où chacune se remplit :

La colonne methode paraît accessoire. Elle permet de contrôler chaque méthode sur un échantillon et de reprendre toutes ses lignes d'un coup si elle se trompe trop souvent.

Étape 1 : inventorier toutes les anciennes URL

L'inventaire croise plusieurs sources parce que chacune rate des URL que les autres voient. Un crawlProcessus par lequel les robots des moteurs de recherche parcourent et analysent les pages web. donne les pages liées depuis le site, et passe à côté d'une page orphelinePage sans aucun lien interne pointant vers elle, difficilement accessible pour les moteurs. qui reçoit encore des clics ou des liens.

Pour dépasser la limite des 1 000 lignes, passez par l'API de la Search Console, qui sert jusqu'à 50 000 lignes par jour, par type de recherche et par propriété. L'export groupé vers BigQuery va plus loin, mais il ne remonte pas l'historique antérieur à son activation : lancez-le dès que le projet est décidé. Côté logs, Google conseille une période qui tienne compte de la saisonnalité de votre trafic.

Ajoutez trois familles que les sources ci-dessus voient mal. Les fichiers d'abord : Google demande d'inclure dans le plan les images, vidéos, fichiers JavaScriptLangage de programmation web. Son mauvais usage peut bloquer l'indexation par les moteurs de recherche. et CSS, et rappelle que les images et les PDF peuvent recevoir du trafic de recherche ou des liens. Pour ces images, le nouveau gabarit doit aussi conserver les réglages qui les rendent visibles dans Google, balise img et texte alternatifAttribut HTML décrivant le contenu d'une image pour les moteurs de recherche et l'accessibilité. compris. Les sitemaps et la liste de contenus du CMS ensuite, que Google cite aussi.

Puis les redirections déjà en place, dans l'ancien fichier de règles ou le plugin du CMS. Elles entrent dans le plan comme des lignes à part entière. Une URL qui redirigeait déjà vers une page elle-même déplacée crée une chaîne au jour J.

Sur une marketplace où chaque produit vendu est redirigé, le stock de redirections héritées devient énorme. C'est un des risques relevés sur la migration de Tradesy vers Vestiaire Collective : des boucles possibles sur les annonces éphémères.

Avant toute correspondance, normalisez la colonne url_source : protocole et hôte ramenés à la forme canonique, slash final harmonisé, paramètres de suivi retirés (utm_, identifiants de session). Dédoublonnez, puis rattachez à chaque URL ses impressions et clics sur 16 mois, ses backlinks et ses passages de Googlebot. Une jointure sur une clé mal normalisée donne une ligne à zéro clic pour une page qui en fait des centaines.

Étape 2 : associer chaque ancienne URL à sa nouvelle page

Le mapping se fait du plus sûr au moins sûr : chaque méthode apparie ce qu'elle sait apparier, la suivante reprend le reste, et le temps humain va aux URL qui portent le trafic.

Prioriser avant d'apparier

Les colonnes de l'étape 1 donnent la priorité. Les pages qui font des clics, du chiffre d'affaires ou reçoivent des backlinks passent en P1 et se vérifient à la main, quelle que soit la méthode qui les a trouvées. Les catégories principales aussi : elles servent de repli au reste. Le seuil se fixe sur vos propres données.

Sur la migration de Tradesy vers la version américaine de Vestiaire Collective, que nous avons accompagnée, le seuil était d'au moins 2 clics sur 16 mois. Il retenait déjà plus de 160 000 URL. À 30 secondes par URL, un traitement manuel aurait demandé plus de 1 300 heures. D'où la cascade qui suit, et la repasse humaine réservée aux pages qui comptent.

La cascade de correspondance

1. Un identifiant commun. Identifiant produit, référence, SKU : quand les deux sites le partagent, la correspondance est exacte. Sur Tradesy, elle a produit plus de 60 000 redirections d'un coup.
2. Un motif d'URL. Un slugPartie de l'URL identifiant une page spécifique, généralement après le nom de domaine. conservé ou un dossier renommé permet une règle pour toute une famille de pages. Les deux sites de cette fusion n'avaient aucun motif d'URL commun.
3. Le contenu. Le mot-clé qui amenait le trafic sur l'ancienne URL, cherché sur le nouveau site, désigne souvent la bonne destination. Un score de similarité entre les titles et H1Balise HTML du titre principal d'une page. Il ne doit y en avoir qu'un seul par page. des deux crawls propose aussi des candidats : sur la fusion de Yakarouler dans Carter Cash, un script TF-IDFTerm Frequency-Inverse Document Frequency. Méthode statistique évaluant l'importance d'un terme dans un document. faisait partie des méthodes. Le score classe les candidats, la repasse tranche.
4. La catégorie parente. Pour une page sans équivalent direct, le fil d'Ariane de l'ancienne page donne sa catégorie mère, à rediriger vers la catégorie correspondante du nouveau site si elle répond encore à la requête d'origine. Ce repli suppose que les catégories principales soient déjà appariées. Il fonctionne d'autant mieux que l'arborescence est hiérarchisée, comme dans un site organisé en silos thématiques.
5. La repasse manuelle. Toutes les P1, plus un échantillon de chaque méthode pour les P2.

Quand le contenu d'une ancienne page a été éclaté en plusieurs nouvelles pages, visez celle qui répond à la requête qui amenait le trafic. Les requêtesTerme ou expression que les utilisateurs saisissent dans un moteur de recherche. Base de toute stratégie SEO. de la Search Console pour cette URL tranchent mieux que l'arborescence.

Au total, 800 000 URL ont été redirigées en six mois sur ce projet, selon l'article publié par l'équipe de Vestiaire Collective en avril 2023. Le même article note un écart : les marques absentes du nouveau catalogue et les dressings sans correspondance ont été redirigés vers la page d'accueil, le schéma que Google déconseille (voir l'étape 3). Le cas client Tradesy et Vestiaire Collective résume le projet, et l'étude de cas de la migration de Tradesy déroule chaque méthode de correspondance, de l'identifiant produit à la repasse manuelle.

Étape 3 : une règle par cas, puis le format des redirections

Chaque ligne reçoit une décision selon ce que devient son contenu, puis les lignes se regroupent en règles que le serveur peut appliquer. Le choix du code lui-même, permanent ou temporaire, est détaillé dans le guide des redirections SEO et des codes 3xx.

La décision, ligne par ligne

• Le contenu existe à une nouvelle adresse : 301 vers elle. C'est le cas simple.
• Plusieurs anciennes pages ont été regroupées : Google accepte de les rediriger toutes vers la page qui les rassemble.
• Un produit sort du catalogue : redirection vers son remplaçant, ou vers la catégorie si elle répond au même besoin. Un produit en simple rupture garde sa fiche en 200, signalée en rupture dans la page et dans les données structuréesCode ajouté au HTML pour aider les moteurs à comprendre le contenu et générer des rich snippets., comme l'explique le guide de la fiche produit SEO.
• Le contenu disparaît sans équivalent, et sa catégorie parente ne répond pas au même besoin : 404 ou 410, que Google traite de la même façon, l'URL sort de l'index. Le choix entre les deux est détaillé dans le guide pour désindexer une URL de Google.
• L'URL n'a aucune valeur : ni impression sur 16 mois, ni backlink, ni passage de Googlebot. Pas de règle, elle finit en 404. Les tris, filtresSystème de filtres (taille, couleur, prix) générant de nombreuses URLs. Nécessite une gestion SEO. et paramètres de session tombent souvent ici.

Reste un piège : la page d'accueil comme destination par défaut. Google déconseille de rediriger en masse les anciennes URL vers une même page : l'internaute est perdu, et ce schéma peut être traité comme une soft 404.

Pour une migration, écartez la 302Redirection temporaire ne transférant pas le jus SEO. À utiliser avec précaution., et pour une autre raison que le PageRankAlgorithme historique de Google évaluant l'importance d'une page selon ses backlinks. Toujours utilisé en interne., que Google dit préservé par les redirections permanentes. Une redirection temporaire laisse l'ancienne URL dans les résultats, sauf si d'autres signaux de canonisation désignent la nouvelle. Une 302 oubliée après une refonte laisse donc le choix de l'URL affichée dépendre de ces signaux.

Du tableur aux règles du serveur

Google laisse le choix du stockage : une base de données, ou des règles de réécriture qui couvrent les formats courants. En pratique, les lignes du plan se rangent en trois familles.

• Les lignes individuelles, une ancienne URL vers une nouvelle. Le cas des pages P1 et de tout ce qui n'a pas de motif.
• Les règles de dossier, qui déplacent un chemin entier en gardant la suite de l'URL. Une telle règle attrape aussi les URL du dossier que vous avez mappées ailleurs : vérifiez que les lignes individuelles l'emportent, par leur ordre ou par la priorité que votre serveur donne aux correspondances exactes.
• Les règles par motif, en expression régulière, pour une famille d'URL au format fixe. Ancrez le motif au début et à la fin, échappez les points, et passez la règle sur la liste complète des URL avant de la poser.

Au-delà de quelques milliers de lignes individuelles, une table de correspondance tient mieux que des milliers de directives. Sur nginx, le module map associe une valeur à une autre et charge ses valeurs depuis un fichier, soit vos colonnes source et cible. Sur une table volumineuse, nginx peut réclamer au démarrage une hausse de map_hash_max_size ou de map_hash_bucket_size : sa documentation conseille d'augmenter d'abord la première.

Sur Apache, RewriteMap fait le même travail, mais se déclare dans la configuration du serveur ou de l'hôte virtuel, jamais dans un .htaccess. Son format dbm, indexé, est beaucoup plus rapide qu'un simple fichier texte.

Sur une plateforme sans accès au serveur, le plan doit tenir dans les outils et les quotas de l'éditeur : pour Salesforce Commerce Cloud, le guide SEO de SFCC détaille les mappings statiques et dynamiques et leurs limites.

Les syntaxes Apache, nginx, PHP et CMS, avec leurs pièges, sont dans le guide de la redirection 301 et de sa mise en place. Retenez un détail de stack pour la recette : Next.js répond en 308 aux redirections déclarées permanent, un code que Google traite comme un 301. Inscrivez dans la colonne code celui que votre serveur renvoie vraiment.

Étape 4 : tester le plan avant la bascule

Le plan se teste deux fois : le fichier d'abord, avant d'écrire une seule règle, puis le serveur de préproduction, ligne par ligne contre la colonne url_cible.

Tester le fichier : chaînes et boucles

Une chaîne naît quand une destination est elle-même une source du plan, souvent à cause d'une redirection héritée. Googlebot suit jusqu'à 10 sauts, mais Google recommande de viser directement la destination finale, et à défaut de rester à 3 sauts au plus, en tout cas sous 5. Exportez trois colonnes du plan (source, cible, code) dans un CSV sans en-tête, séparé par des virgules : Google Sheets le fait par défaut, un Excel en français met des points-virgules, à remplacer à l'export ou en repassant par Sheets. Puis lancez ce script Python :

import csv, sys

plan, sans_cible = {}, set()
with open(sys.argv[1], newline='', encoding='utf-8-sig') as f:
    for source, cible, code in csv.reader(f):
        if code.strip() in ('301', '308'):
            plan[source] = cible
        else:
            sans_cible.add(source)

for source, cible in plan.items():
    chemin = [source]
    while cible in plan and cible not in chemin:
        chemin.append(cible)
        cible = plan[cible]
    if cible in chemin:
        print('BOUCLE :', ' -> '.join(chemin + [cible]))
    elif cible in sans_cible:
        print(f'VERS 404/410 : {source} -> {cible}')
    elif len(chemin) > 1:
        print(f'CHAINE ({len(chemin)} sauts) : {source} -> {cible}')

Chaque ligne CHAINE donne la source et sa destination finale : c'est la correction à reporter dans le plan. Une ligne BOUCLE montre le cycle complet, à casser en choisissant la bonne destination. Une ligne VERS 404/410 redirige vers une URL que le plan supprime : choisissez une autre destination. Pas de sortie, pas de chaîne dans le fichier.

L'encodage utf-8-sig retire l'en-tête invisible (BOM) qu'ajoute un export « CSV UTF-8 ». Le script ne voit que ce qui est dans le plan : les règles générales du serveur (HTTPSProtocole sécurisé de transfert de données. Facteur de ranking depuis 2014., www, slash final) ajoutent leurs propres sauts, que seul le test du serveur révèle.

Croisez aussi la colonne url_cible avec le crawl de la préproduction. Google cite parmi les erreurs fréquentes les redirections vers des URL qui n'existent plus sur le nouveau site : une cible absente du crawl est une 404 programmée.

Tester le serveur : la recette contre le plan

Google conseille l'outil d'inspection d'URL pour quelques URL, et des scripts ou la ligne de commande pour un grand nombre. Ce script lit le même CSV et compare, pour chaque ligne, ce que répond le serveur à ce que prévoit le plan :

while IFS=, read -r source cible attendu || [ -n "$source" ]; do
  attendu=${attendu%$'\r'}
  source=${source#$'\xEF\xBB\xBF'}
  premier=$(curl -so /dev/null -w '%{http_code}' "$source")
  read -r sauts code finale < <(curl -sLo /dev/null -w '%{num_redirects} %{http_code} %{url_effective}\n' "$source")
  if [ "$premier" = "$attendu" ] &ampAccelerated Mobile Pages. Framework Google pour créer des pages mobiles ultra-rapides (moins utilisé aujourd'hui).;& { [ "$sauts" = 0 ] || { [ "$sauts" = 1 ] && [ "$code" = 200 ] && [ "$finale" = "$cible" ]; }; }
  then statut=OK; else statut=KO; fi
  echo "$statut,$source,$premier,$sauts,$code,$finale"
done < plan.csv > recette.csv
grep -c '^OK' recette.csv
grep '^KO' recette.csv

Une ligne passe OK si le premier code est celui du plan, puis, pour une redirection, si elle arrive en un saut sur la bonne URL en 200. Une ligne en 404 ou 410 passe OK sans saut.

Le reste sort en KO, avec de quoi diagnostiquer : un premier code à 302 ou 308 quand le plan attend 301, deux ou trois sauts quand des règles générales s'empilent, une destination finale en 404. Les deuxième et troisième lignes du script retirent le retour chariot et l'en-tête invisible (BOM) que laisse un CSV exporté d'Excel, sans quoi aucune ligne ne serait conforme. La fin de la première ligne (|| [ -n "$source" ]) lit aussi une dernière ligne sans saut de ligne final, que read ignorerait sinon.

Le CSV contient les URL de production. Pour la préproduction, remplacez l'hôte dans les deux colonnes, par exemple sed 's#https://www.exemple.fr#https://preprod.exemple.fr#g' plan.csv > plan-preprod.csv, et ajoutez -u identifiant:motdepasse aux deux appels curl si elle est protégée par mot de passe. Source et cible s'écrivent en URL complètes, protocole compris : une cible relative ne sera jamais égale à l'URL finale. Écrivez aussi la cible telle que le serveur l'envoie : accents encodés (%C3%A9 pour é, avec la casse de votre serveur) et slash après un nom de domaine seul (https://www.exemple.fr/). Une ligne KO dont l'URL finale ne diffère de la cible que par cet encodage ou ce slash est une redirection juste.

Un code final 403 ou 429 sur toutes les lignes, ou une page de défi, signale un pare-feu qui bloque curl, sans rien dire des redirections : le site de Vestiaire Collective répond ainsi 301 puis 403 à curl. Faites autoriser l'adresse IP de la machine de test le temps de la recette. Changer le user-agent pour celui de Googlebot n'y change rien quand le CDNContent Delivery Network. Réseau de serveurs distribuant le contenu depuis le serveur le plus proche de l'utilisateur. vérifie aussi l'IP.

Sur un gros volume, Screaming FrogLogiciel de crawl permettant d'auditer techniquement un site web. donne les mêmes mesures en mode liste, présenté dans notre tutoriel Screaming Frog : cochez « Always Follow Redirects », exportez le rapport « All Redirects », puis rapprochez URL finale et nombre de sauts de la colonne url_cible dans le tableur.

Étape 5 : contrôler après la mise en ligne

Après la bascule, le plan devient l'outil de suivi : la même recette sur la production le jour J, puis les logs et la Search Console pendant les semaines qui suivent.

Le jour J, relancez le script de recette avec les URL de production. Vérifiez au passage ce que Google demande de faire pointer vers les nouvelles adresses : liens internesEnsemble des liens entre les pages d'un même site. Distribue le jus SEO et guide les utilisateurs., balises canonical, sitemapFichier XML listant toutes les URLs d'un site pour faciliter leur découverte par les moteurs de recherche.. Chaque lien interne vers une ancienne URL coûte un saut à l'internaute et à Googlebot, et le plan sert de table de remplacement.

Les semaines suivantes, trois sources parlent :

• Les logs serveur. Googlebot repasse sur les anciennes URL et doit recevoir le code du plan. Une ancienne URL en 404 qui n'était pas prévue est une ligne oubliée : ajoutez-la au plan avec sa décision, puis à la règle.
• Le rapport d'indexation des pages. Le statut « Page avec redirection » est normal pour une ancienne URL. Celui à surveiller est « Erreur liée à des redirections », qui signale les chaînes trop longues et les boucles. L'outil d'inspection d'URL ne suit pas les redirections : testez la destination à part.
• Les deux sitemaps. Celui des anciennes URL voit son nombre de pages indexées descendre vers zéro, celui des nouvelles monte d'autant. La Search Console peut afficher des avertissements de redirection sur l'ancien sitemap : c'est normal.

Google compte en général quelques semaines pour la majorité des pages d'un site de petite ou moyenne taille, davantage pour un gros site.

Les redirections, elles, restent plus longtemps. Au moins un an : c'est le temps qu'il faut à Google pour transférer tous les signaux vers les nouvelles URL, liens des autres sites compris. Du point de vue des internautes, Google conseille même de les garder indéfiniment. Demandez aux sites qui vous envoient le plus de liens de mettre l'adresse à jour.

Archivez le plan final avec ses résultats de recette. À la prochaine refonte, ses lignes seront vos redirections héritées, et le script de chaînes les reprendra dès l'inventaire. Si vous préférez confier le mapping et la recette, c'est le cœur de notre accompagnement SEO de refonte et de migration, mené par notre agence SEO.

Questions fréquentes

Sources

• Migrations de sites (avec modification d'URL), Google Search Central
• [GA4] Rapport "Requêtes" - Ordinateur, Aide Google
• Exporter des données, Aide Google
• Rapport sur l'indexation des pages, Aide Google
• Rapport sur les liens, Aide Google
• Exporter les données de la Search Console à l'aide de l'API Search Console, Aide Google
• Start a new bulk data export, Aide Google
• SEO Case Study: Migrating Tradesy to Vestiaire Collective in 6 Months (Medium, Vestiaire Connected, 20 avril 2023) : medium.com/vestiaire-connected/a-comprehensive-case-study-migrating-tradesy-com-to-us-vestiairecollective-com-in-6-months-9432e70c326e
• Désactiver ou suspendre temporairement un site Web, Google Search Central
• Effet des codes d'état HTTP sur les robots d'exploration Google, Google Search Central
• Redirections et recherche Google, Google Search Central
• Module ngx_http_map_module, nginx.org : nginx.org/en/docs/http/ngx_http_map_module.html
• Using RewriteMap, Apache HTTP Server 2.4 : httpd.apache.org/docs/2.4/rewrite/rewritemap.html
• redirects, next.config.js (Next.js)
• curl man page : curl.se/docs/manpage.html
• csv, Python documentation : docs.python.org/3/library/csv.html
• How To Audit Redirects In A Site Migration Using The SEO Spider, screamingfrog.co.uk
• Changement d'hébergement, Google Search Central
• Setting up hashes, nginx.org : nginx.org/en/docs/hash.html