Rediriger un domaine sans perdre les chemins ni les paramètres UTM

Pour rediriger un domaine en conservant les chemins et les query strings, votre couche de redirection doit transmettre l’URI complète, pas seulement le nom d’hôte.

Une requête comme :

ancienne-marque.fr/pricing?plan=pro&utm_source=email

devrait arriver sur :

nouvelle-marque.fr/pricing?plan=pro&utm_source=email

Si votre configuration ne redirige que le domaine nu, vous perdez le chemin exact demandé. Cela casse les liens de campagne, les deep links, les pages de documentation et parfois une partie de la valeur SEO de la migration.

Si ce changement fait partie d’une migration plus large, commencez par la checklist de redirections pour une migration de site, puis revenez à ce détail d’implémentation.

Ce que signifie vraiment conserver chemin et query string

Quand une équipe parle de domain forwarding, elle peut vouloir dire plusieurs choses.

Forwarding uniquement par hôte

Toutes les requêtes atterrissent sur une nouvelle page d’accueil :

ancienne-marque.fr/* -> nouvelle-marque.fr/

C’est simple, mais cela jette tout le contexte.

Forwarding avec conservation du chemin

Le chemin après le domaine reste intact :

ancienne-marque.fr/blog/post-1 -> nouvelle-marque.fr/blog/post-1

C’est ce dont la plupart des migrations ont réellement besoin.

Forwarding avec conservation des query strings

Les paramètres de campagne et de suivi restent présents :

ancienne-marque.fr/pricing?utm_source=email -> nouvelle-marque.fr/pricing?utm_source=email

Sans cela, l’attribution et le reporting deviennent vite moins fiables.

Pourquoi le DNS seul ne suffit pas

Les enregistrements DNS comme CNAME ou A indiquent où envoyer le trafic. Ils ne génèrent pas à eux seuls une redirection HTTP 301 ou 302 pour le navigateur.

Pour que les utilisateurs et les crawlers arrivent sur une autre URL, il faut une couche HTTP capable de contrôler :

• le bon code de statut
• la bonne destination
• la conservation du chemin
• la gestion des paramètres
• le comportement HTTPS

Le forwarding de domaine n’est donc pas seulement une tâche DNS. C’est une question de routage.

Si vous hésitez encore entre un changement permanent ou temporaire, lisez 301 vs 302 vs 307 vs 308 avant de publier la règle.

Le modèle le plus sûr pour une migration de domaine

Pour la plupart des migrations, la base est la suivante :

1. choisir l’hôte canonique final
2. forcer HTTPS
3. rediriger les anciens chemins importants vers leurs nouveaux équivalents
4. conserver les paramètres utiles
5. limiter le parcours à un seul hop

Bon modèle :

http://ancienne-marque.fr/docs/api?ref=partner
  -> https://nouvelle-marque.fr/docs/api?ref=partner

Mauvais modèle :

http://ancienne-marque.fr/docs/api
  -> https://ancienne-marque.fr/docs/api
  -> https://www.nouvelle-marque.fr/docs/api
  -> https://nouvelle-marque.fr/docs/api

Si votre forwarding passe par deux ou trois destinations intermédiaires, corrigez-le avant la mise en ligne. Notre guide sur les chaînes et boucles de redirection explique quoi vérifier.

Quand la conservation du chemin compte le plus

Migrations de site

Si vous changez de domaine ou de plateforme, conserver la structure des chemins permet aux backlinks et URLs indexées de rester utiles.

Documentation et bases de connaissance

Les utilisateurs de documentation n’arrivent presque jamais d’abord sur la page d’accueil. Ils ouvrent un article précis. Tout renvoyer vers / détruit cette expérience.

Campagnes payantes

Si une publicité contient plusieurs paramètres de suivi et que la redirection les supprime, votre reporting perd en fiabilité immédiatement.

Liens courts et liens de marque

Beaucoup de liens de marque sont de petites règles de routage. Si le chemin ou les paramètres disparaissent, la stratégie de lien perd en clarté.

Un modèle wildcard propre

Le modèle mental le plus simple :

source:      ancienne-marque.fr/*
destination: nouvelle-marque.fr/$1

Autrement dit :

• tout ce qui suit le slash est repris
• le chemin est injecté dans la destination
• la forme de la requête reste prévisible

Exemples :

Si vous conservez aussi les query strings, alors :

/pricing/enterprise?utm_source=partner

reste présent à destination.

Quatre vérifications qui évitent la plupart des erreurs

1. Confirmer l’hôte final

Choisissez une destination :

• nouvelle-marque.fr
• ou www.nouvelle-marque.fr

Ne prenez pas cette décision au milieu de la migration. C’est ainsi que les chaînes apparaissent.

2. Choisir le bon code de statut

Si le déplacement est permanent, utilisez un code permanent comme 301.

S’il est temporaire, utilisez un code temporaire comme 302.

3. Tester explicitement les paramètres

Ne supposez pas que chaque fournisseur conserve les query strings automatiquement.

Testez avec de vrais exemples :

curl -I 'https://ancienne-marque.fr/pricing?plan=pro&utm_source=email'

Vérifiez ensuite que l’en-tête Location contient bien le chemin et les paramètres attendus.

4. Tester la racine et les URLs profondes

Beaucoup de redirections fonctionnent pour / et échouent sur :

• /docs/api
• /blog/post-slug
• /pricing/enterprise
• /old-category/product-123

HTTPS fait partie de la redirection

Un mauvais résultat de migration peut ressembler à ceci :

• la redirection est techniquement correcte
• mais l’ancien domaine ne termine pas HTTPS proprement
• les utilisateurs voient une erreur de certificat avant même d’être redirigés

Le SSL automatique compte donc dès la première requête. Le flux de redirection commence avant que votre logique parfaite ait une chance de s’exécuter.

Si vous voulez une option managée, UrlEdge Free Redirect Service inclut HTTPS automatique et forwarding wildcard.

Erreurs courantes

Rediriger uniquement la page d’accueil

C’est le piège classique du lancement : "ça marche sur la homepage". Les vrais utilisateurs ouvrent aussi des deep links.

Oublier non-www et domaine racine

Pensez ensemble :

• ancienne-marque.fr
• www.ancienne-marque.fr
• les sous-domaines concernés

Supprimer les paramètres de campagne

Même si le SEO reste correct, vos données d’attribution peuvent devenir moins fiables du jour au lendemain.

Créer plusieurs hops

La conservation du chemin perd beaucoup d’intérêt si la requête rebondit par deux ou trois hôtes intermédiaires.

Un modèle UrlEdge pratique

Pour une migration permanente typique :

1. connecter l’ancien domaine
2. activer HTTPS
3. créer une règle wildcard
4. conserver le chemin
5. conserver les paramètres nécessaires
6. tester les pages principales avec Redirect Checker

C’est utile quand vous voulez une migration no-code ou low-code sans réécrire la logique de routage dans Nginx, Apache ou votre middleware applicatif.

FAQ

Puis-je rediriger un domaine racine et conserver le chemin ?

Oui, si votre couche de redirection prend en charge le forwarding du domaine racine et la conservation du chemin.

Dois-je toujours conserver les query strings ?

Pas toujours. Conservez les paramètres de tracking, de campagne et les paramètres fonctionnels qui comptent. Supprimez les paramètres inutiles seulement si vous en êtes sûr.

Le wildcard forwarding suffit-il pour toutes les migrations ?

Non. Certaines migrations demandent des mappings un à un pour les chemins renommés. Les wildcards sont utiles quand la structure reste proche.

Puis-je tester avant de changer le DNS pour tout le monde ?

Oui. Testez sur staging ou sur des hôtes contrôlés, puis validez un échantillon réel de chemins avant la bascule complète.