Les anciennes URL marcheront-elles encore après une refonte ou une migration ?

Une refonte ou un passage à une nouvelle plateforme, c'est enthousiasmant — mais fait sans précaution, cela réduit votre visibilité dans les moteurs de recherche et casse chaque lien entrant dont l'URL a changé. Les moteurs ont passé des années à apprendre vos URL actuelles, et d'autres sites, e-mails et favoris pointent vers elles. Changez ces adresses sans rien pour rattraper les anciennes, et les visiteurs tombent sur des erreurs pendant que les moteurs perdent le fil qui relie les liens et l'historique des anciennes pages à leurs remplaçantes.

Inventoriez, puis faites la carte — avant le lancement

L'étape la plus importante se joue pendant que l'ancien site existe encore. Construisez un inventaire d'URL aussi complet que possible — depuis le CMS, les sitemaps actuels et historiques, les journaux du serveur, les statistiques, les données de la Search Console, les relevés de liens entrants et une exploration du site. Aucune source ne contient toutes les anciennes URL ; les pages orphelines et celles à paramètres échappent à la plupart.

Ensuite :

• Laissez inchangées les URL qui ne changent pas. Une URL qui survit à la refonte doit continuer à servir son contenu à la même adresse — seules les URL modifiées reçoivent une redirection.
• Faites correspondre chaque URL modifiée à sa nouvelle page la plus pertinente, pas à un fourre-tout — et incluez les variantes de paramètres qui comptent (/product.php?id=7 est une page à part entière ; notez que les #fragments n'atteignent jamais le serveur et ne peuvent pas être redirigés).
• Quand une page n'a vraiment aucun équivalent, ne forcez pas de redirection : renvoyez un vrai 404, ou 410 pour ce qui est retiré définitivement, avec une page d'aide qui ramène vers le site. Envoyer une URL orpheline vers une page parente sans rapport ou vers l'accueil peut être traité comme un soft 404 — l'accueil n'est une cible légitime que s'il est vraiment l'équivalent le plus proche.

Cette carte est le contrat entre votre ancien site et le nouveau. Construisez-la posément plutôt que de découvrir les trous après le lancement.

Utilisez des redirections permanentes — avec précision

Mettez en œuvre chaque correspondance comme une redirection permanente 301 (pour les pages ordinaires ; 308 quand une méthode de requête doit survivre). Une 301 signale que le déménagement est définitif et aide les moteurs à fusionner l'ancienne URL avec la nouvelle ; une 302 dit « temporaire », donc l'ancienne adresse reste en général la principale. Testez les règles avant le grand déploiement — les redirections permanentes sont mises en cache, les erreurs s'incrustent.

RedirectMatch 301 "^/old-services/web-design/?$" "https://www.example.com/services/websites"

(Notez la correspondance ancrée : le simple Redirect d'Apache est une correspondance de préfixe qui attrape aussi en silence /old-services/web-design/anything, en ajoutant le reste — parfois voulu, souvent non.)

Mettez aussi à jour le reste des signaux : des liens internes pointant droit vers les nouvelles URL (une redirection inutile, c'est une requête en plus pour chaque visiteur et robot), les annotations canoniques et hreflang sur leurs nouvelles adresses, un sitemap des URL définitives — et enlevez tout noindex ou blocage d'exploration hérité de la phase de développement.

Vérifiez après le lancement et gardez la carte pendant des années

Une migration n'est pas finie le jour du lancement. Testez directement l'inventaire des anciennes URL : chaque URL modifiée doit faire un seul saut permanent vers son adresse HTTPS finale prévue — pas de boucles, pas de chaînes, pas de redirections vers des pages manquantes. Explorez ensuite le nouveau site, examinez toute hausse des erreurs 404 (redirections oubliées, liens internes cassés, ressources manquantes — ou de simples sondes de robots), et surveillez votre Search Console dans les semaines qui suivent : réponses « Introuvable » inattendues, erreurs de redirection, anciennes URL qui s'attardent là où les remplaçantes devraient apparaître. Attendez-vous à quelques fluctuations temporaires de visibilité, même quand tout est en ordre.

Gardez la carte de redirections en place indéfiniment — et pour un changement de domaine, gardez l'enregistrement, le DNS et le certificat de l'ancien domaine en état de marche tant que les redirections comptent, car un domaine expiré ne répond rien.

Ce qu'il faut faire

1. Avant le lancement, construisez l'inventaire des anciennes URL depuis le CMS, les sitemaps (historiques compris), les journaux, les statistiques, la Search Console et les données de liens entrants, plus une exploration.
2. Laissez en place les URL inchangées ; faites correspondre chaque URL modifiée — variantes de paramètres comprises — à sa nouvelle page la plus pertinente, avec d'honnêtes 404/410 pour ce qui est retiré.
3. Mettez la carte en œuvre sous forme de redirections permanentes testées (301, ou 308 quand la méthode compte), avec une correspondance précise.
4. Mettez à jour liens internes, canoniques, hreflang et sitemap vers les nouvelles URL, et levez tout blocage résiduel du développement.
5. Après le lancement, testez directement l'ancien inventaire et surveillez les 404 et les rapports Search Console pendant des semaines.
6. Laissez la carte de redirections — et, pour un changement de domaine, le DNS et le TLS de l'ancien domaine — en place pendant des années, pas des semaines.