Checklist de redirections pour une migration de site : 15 vérifications avant le switch DNS

La réussite ou l’échec d’une migration de site dépend souvent davantage de la discipline sur les redirections que du design, du code ou du message de lancement. Avant de basculer le DNS, la vraie question est simple : chaque ancienne URL importante arrive-t-elle sur la bonne nouvelle destination en un seul hop propre ?

Cette checklist s’adresse aux équipes qui :

• passent sur un nouveau domaine
• adoptent un nouveau CMS
• migrent d’un monolithe vers une architecture headless
• déplacent un site d’un sous-domaine vers le domaine racine
• remplacent une ancienne structure de blog ou de documentation par une arborescence d’URL plus propre

Si vous avez besoin d’un exemple spécifique à Shopify, lisez notre guide sur la migration des URLs Shopify vers un storefront headless. Cet article est la version plus générale que vous pouvez appliquer à presque n’importe quel stack.

Si votre migration inclut aussi un changement de domaine avec des wildcards, gardez bien en tête la conservation des chemins, des query strings et de la logique de destination pendant que vous parcourez la checklist ci-dessous.

L’objectif non négociable

Avant le lancement, vous voulez que ces cinq points soient vrais :

1. les anciennes URLs à forte valeur pointent vers les bonnes nouvelles URLs
2. les déplacements permanents utilisent bien une intention de redirection permanente
3. les redirections se résolvent en un seul hop autant que possible
4. les liens internes pointent déjà vers les nouvelles URLs canoniques
5. le monitoring post-lancement est prêt avant que le trafic bascule

S’il manque l’un de ces points, le risque de migration augmente vite.

La checklist de redirections

1. Inventorier les URLs actuelles

Ne planifiez pas vos redirections de mémoire.

Récupérez les URLs depuis :

• les sitemaps XML
• les landing pages issues des analytics
• les pages les plus importantes dans Search Console
• les URLs de campagnes payantes
• les templates d’email
• les backlinks et documents partenaires
• les anciens blogs et archives de documentation

Si une URL reçoit du trafic SEO, du trafic de conversion ou du trafic support, elle doit figurer dans l’inventaire de migration.

2. Choisir tôt l’hôte canonique final

Définissez la destination finale avant d’écrire les règles :

• https://newsite.com
• ou https://www.newsite.com

Ne laissez pas cette décision dans le flou. C’est ainsi que naissent des chaînes du type http -> https -> www -> final.

3. Tenir une redirect map dans un vrai tableur ou CSV

Au minimum, suivez :

old_url,new_url,status,priority,owner,notes
https://oldsite.com/pricing,https://newsite.com/pricing,301,high,marketing,core landing page
https://oldsite.com/docs/api,https://newsite.com/docs/api,301,high,engineering,docs migration

Vous donnez ainsi au marketing, au SEO, à l’engineering et au support une même source de vérité.

4. Protéger d’abord les URLs les plus importantes

Priorisez les pages qui comptent le plus :

• la page d’accueil
• la page pricing
• la documentation
• les principales landing pages SEO
• les pages de campagne
• les URLs support liées depuis les emails

Ne donnez pas aux archives à faible trafic la même attention qu’à vos principaux parcours de conversion le premier jour.

5. Mapper les anciennes URLs vers la meilleure nouvelle destination

L’objectif n’est pas toujours un mapping 1 pour 1 avec conservation stricte du chemin. L’objectif est la meilleure destination possible.

Bons exemples :

• ancienne page produit -> nouvelle page produit
• ancienne page de documentation -> page de documentation équivalente
• ancienne page de campagne retirée -> offre actuelle la plus pertinente

Mauvais exemples :

• tout -> page d’accueil
• documentation retirée -> page d’accueil
• deep links cassés -> page de catégorie générique sans contexte

6. Utiliser des redirections permanentes pour les déplacements permanents

Si l’ancienne URL ne doit pas revenir, utilisez une politique de redirection permanente.

Si vous hésitez sur le code de statut à choisir, consultez l’explication des types de redirection.

Le point important est de ne pas laisser une migration durable tourner pendant des mois avec une intention temporaire.

7. Préserver la structure des chemins quand cela a encore du sens

Si votre nouveau site conserve une structure proche de l’ancienne, la conservation des chemins réduit considérablement le travail manuel.

Exemples :

• /docs/* -> /docs/*
• /blog/* -> /blog/*
• /features/* -> /features/*

Si la structure a beaucoup changé, mieux vaut utiliser des mappings explicites un à un pour les pages à forte valeur plutôt que des wildcards aveugles.

Si vous cherchez le bon modèle d’implémentation pour cela, combinez une redirect map propre avec Permanent 301 Redirects ou un Free Redirect Service, selon votre scénario de déploiement.

8. Préserver les query strings importants

Cela concerne notamment :

• l’attribution de campagne
• les paramètres d’affiliation
• les liens de tracking et de lifecycle
• les paramètres fonctionnels exploités par l’app ou la page

Tous les query strings n’ont pas vocation à vivre indéfiniment, mais ceux qui comptent doivent être gérés intentionnellement.

9. Éliminer les chaînes de redirection avant le lancement

N’attendez pas que PageSpeed ou vos utilisateurs vous signalent que le parcours de redirection est brouillon.

Des chaînes comme :

old-url -> old-intermediate -> final-url

doivent devenir :

old-url -> final-url

Si vous avez besoin d’un workflow de diagnostic plus poussé, utilisez Redirect Checker pour inspecter les hops et le comportement réel des destinations.

10. Tester sur un environnement de staging ou des hôtes contrôlés

Avant la bascule publique, testez :

• la page d’accueil
• les principales landing pages
• les chemins de documentation
• les articles de blog
• les URLs avec paramètres
• les chemins spécifiques mobile, s’ils existent

Combinez des vérifications navigateur et des tests en ligne de commande :

curl -IL https://oldsite.com/docs/api

11. Mettre à jour les liens internes avant ou juste après le lancement

Les redirections sont un filet de sécurité. Les liens internes doivent tout de même pointer directement vers les nouvelles URLs canoniques.

Cela inclut :

• les liens de navigation
• les liens de footer
• les liens dans le contenu
• les CTAs produit
• les sidebars de documentation
• les templates d’email si la migration change les URLs publiques

12. Mettre à jour sitemap, canonicals et navigation

La redirect map n’est qu’un élément de la migration. Pensez aussi à mettre à jour :

• le sitemap XML
• les balises canonical
• le hreflang si nécessaire
• la navigation principale
• les URLs présentes dans les données structurées si besoin

Si vos redirections disent une chose et vos canonicals en disent une autre, vous vous créez du nettoyage supplémentaire plus tard.

13. Préparer le monitoring avant le lancement

Ayez un plan pour les 7 à 14 premiers jours :

• surveiller les 404
• inspecter les URLs les plus redirigées
• suivre le trafic vers les pages importantes
• vérifier les liens de campagne
• confirmer que les liens de doc et de support atterrissent bien au bon endroit

C’est là que analytics, Redirect Checker et broken-link monitoring deviennent réellement utiles en production.

14. Conserver l’ancienne couche de redirection assez longtemps

Une erreur fréquente consiste à considérer les redirections comme une tâche d’une semaine. En réalité, les anciens liens peuvent continuer à recevoir du trafic pendant des mois, voire des années.

C’est particulièrement vrai pour :

• les backlinks
• les bookmarks
• les liens dans des PDF
• les documents partenaires
• les anciens posts sociaux

Pensez durabilité des redirections, pas seulement survie la semaine du lancement.

15. Documenter les exceptions et cas particuliers

Toutes les URLs ne doivent pas être redirigées. Certaines doivent renvoyer 404 ou 410. Certaines pages légales ou support peuvent exiger un traitement spécial. Certains anciens parcours d’app peuvent nécessiter une logique liée à l’appareil plutôt qu’une simple redirection.

Documentez explicitement ces cas pour éviter qu’ils ne deviennent des comportements mystérieux plus tard.

Un ordre d’exécution simple et efficace

Si vous voulez la séquence la plus courte qui reste fiable :

1. exporter les URLs
2. choisir l’hôte canonique
3. créer la redirect map
4. tester les URLs prioritaires
5. éliminer les chaînes
6. mettre à jour liens internes et sitemap
7. lancer
8. surveiller les 404 et le trafic redirigé

Cet ordre rend le travail beaucoup plus lisible pour les équipes engineering, marketing et SEO.

Où UrlEdge aide vraiment

UrlEdge est particulièrement adapté quand votre migration a besoin de :

• l’import en masse de redirections
• la conservation des chemins via wildcards
• une propagation mondiale rapide
• des outils de QA pour les redirections
• de la visibilité après lancement

C’est particulièrement utile si vous ne voulez pas que la logique de redirection soit dispersée entre le code applicatif, les reverse proxies, les plugins CMS et les fonctions de forwarding de votre fournisseur DNS.

FAQ

Faut-il rediriger chaque ancienne URL vers quelque chose ?

Non. Certaines URLs obsolètes doivent renvoyer un vrai état d’erreur. En revanche, les pages qui conservent une valeur business ou une attente utilisateur claire doivent pointer vers une destination pertinente.

Rediriger tout vers la page d’accueil, est-ce acceptable ?

Le plus souvent non. C’est l’une des stratégies les plus faibles, car elle détruit l’intention du chemin et frustre à la fois les utilisateurs et les moteurs.

Combien de temps faut-il conserver les redirections de migration ?

Plus longtemps que ce que la plupart des équipes imaginent. Les redirections importantes doivent souvent rester en place bien au-delà du mois de lancement.

Que faut-il tester en priorité si le temps manque ?

La page d’accueil, la page pricing, la documentation, les principales landing pages, les liens de campagne et les URLs ayant eu le plus de trafic historique.

Guides UrlEdge associés

• Gestion d’URLs en masse
• Permanent 301 Redirects
• Redirect Checker
• Migration de Shopify vers un frontend headless

Références officielles

• Google Search Central: site move with URL changes
• MDN: Redirections in HTTP