Comment rediriger une URL : six méthodes, et quand utiliser chacune

Une redirection est une réponse HTTP : un statut 301 ou 302 avec un en-tête Location qui indique au navigateur où aller à la place. C'est tout ce qu'elle est sur le fil, ce qui veut dire que la question n'est pas vraiment comment rediriger une URL, mais quelle couche devant votre site doit être celle qui répond.

Six couches peuvent faire le travail, et elles ne sont pas interchangeables. Elles diffèrent selon qui sert la réponse, si le chemin et la chaîne de requête survivent au trajet, à quelle vitesse vous pouvez changer d'avis, et quelle part de la configuration vous possédez. Ce guide parcourt les six, le tableau qui permet de choisir entre elles, et les deux vérifications qui séparent une redirection qui fonctionne d'une autre qui avale discrètement vos paramètres de campagne. Pour les codes de statut eux-mêmes, les types de redirections d'URL est la référence sous-jacente à celle-ci.

Où vit vraiment une redirection

Commencez par le mythe, car il gaspille plus d'après-midis que n'importe quel autre : le DNS ne peut pas rediriger une URL. Un enregistrement DNS fait correspondre un nom d'hôte à une adresse. Il ne voit jamais le chemin, ne voit jamais la chaîne de requête, et n'a aucun mécanisme pour dire « allez ailleurs à la place ». Un enregistrement A ou CNAME pointe ; il ne redirige pas.

Alors quand votre registrar propose la « redirection d'URL », ce qu'il fait en réalité, c'est pointer le nom d'hôte vers un petit serveur web qu'il exploite, lequel renvoie la redirection HTTP à votre place. Utile, et parfaitement légitime, mais c'est un serveur web qui fait le travail, pas le DNS. Une fois que vous le voyez ainsi, les six méthodes ci-dessous cessent de ressembler à des alternatives et commencent à ressembler à une seule question : quelle machine dans le chemin de la requête voulez-vous voir répondre ?

Une requête qui se résout via le DNS vers un serveur, la redirection étant émise sous forme de réponse HTTP 301, avec le DNS marqué comme incapable de rediriger

Six endroits où placer une redirection

Chacune de ces méthodes se termine par la même réponse sur le fil. Ce qui diffère, c'est le coût de mise en place, qui la contrôle, et ce qui arrive à tout ce qui suit le nom de domaine.

la redirection de domaine chez le registrar

L'option la plus rapide, et la plus brutale. Dans le panneau de contrôle de votre registrar, vous pointez le domaine vers une destination et choisissez permanent ou temporaire. Bien adapté à un domaine acheté à titre défensif, à un changement de marque où l'ancien nom doit simplement passer la main, ou à un domaine de campagne éphémère.

Le piège, c'est ce que cela fait au reste de l'URL : la plupart des redirections de registrar aplatissent chaque requête vers l'unique destination configurée, si bien qu'un lien profond arrive sur la page d'accueil. Certains proposent un mode qui préserve le chemin ; vérifiez avant de vous y fier.

une règle dans votre serveur web

Si vous faites tourner nginx ou Apache, c'est là que la redirection a sa place, car vous obtenez un contrôle exact sur la correspondance et la préservation. La documentation d'Apache sur le remappage d'URL avec des règles de réécriture couvre les schémas, et la référence du module rewrite de nginx couvre return 301 et rewrite ... permanent, qui est la voie rapide pour un déplacement simple.

Les règles serveur sont le bon outil pour l'application de l'hôte canonique et de HTTPS, la réécriture de chemins après une restructuration, et tout ce qui est conditionnel. C'est aussi là que les règles de redirection s'accumulent discrètement au fil des années, donc traitez le fichier comme quelque chose à élaguer plutôt que d'y ajouter seulement.

une règle chez votre plateforme d'hébergement

La plupart des hébergeurs modernes se placent devant l'origine et proposent leur propre couche de redirection : un fichier _redirects, un bloc de configuration, une interface de règles dans le tableau de bord. Elles s'évaluent avant que votre application ne s'exécute, ce qui les rend rapides et sûres, et c'est généralement le meilleur endroit pour des redirections en masse après une migration de site, car elles vivent dans le contrôle de version avec le reste du projet.

un plugin ou un réglage dans votre CMS

Tout CMS sérieux a un gestionnaire de redirections, et pour une équipe éditoriale, c'est la bonne réponse : pas de déploiement, pas d'accès serveur, une piste d'audit, et une personne qui comprend le contenu qui prend la décision de correspondance. Le compromis, c'est que la requête doit atteindre l'application avant que la redirection ne soit émise, donc c'est plus lent que les couches précédentes, et cela cesse de fonctionner si l'application est en panne.

meta refresh ou JavaScript sur la page

Un dernier recours pour quand vous ne pouvez toucher à rien côté serveur. La page se charge, puis envoie le visiteur plus loin avec une balise <meta http-equiv="refresh"> ou un script. Cela fonctionne, mais cela coûte un chargement de page complet, cela dépend de l'exécution par le client, et les moteurs de recherche le traitent comme un signal plus faible qu'une réponse serveur. Utilisez-le quand l'alternative est de ne rien faire du tout.

un lien court géré

Quand ce qui est redirigé est un lien que vous avez publié plutôt qu'une page que vous possédez, la redirection a sa place dans un gestionnaire de liens. La destination est une valeur stockée que vous pouvez modifier sans toucher au DNS, aux serveurs, ou à un pipeline de déploiement, chaque saut est journalisé, et le lien continue de fonctionner après avoir été imprimé ou partagé. C'est tout le mécanisme derrière ce qu'est un raccourcisseur d'URL, et c'est pourquoi un lien de campagne imprimé ne devrait jamais pointer directement vers une page de destination.

Choisir en trente secondes

L'essentiel de la décision se résume à deux colonnes : qui a accès, et ce qui doit survivre.

Méthode	Qui la sert	Chemin et requête préservés	Idéal pour
Redirection du registrar	Serveur du registrar	Souvent non, à vérifier d'abord	Transfert de domaine entier
Règle de serveur web	Votre origine	Oui, si écrite ainsi	Hôte canonique, restructuration
Règle de plateforme	Hébergeur en amont	Oui	Redirections de migration en masse
Plugin CMS	Votre application	Oui	Équipe éditoriale, sans déploiement
Meta refresh ou JS	Le navigateur	Oui, mais lentement	Aucun accès serveur
Lien court géré	Le service de liens	Oui, depuis l'URL stockée	Liens publiés et imprimés

Préserver le chemin et la chaîne de requête

C'est l'échec qui survit aux tests, parce que tout le monde teste la racine du domaine, et la racine fonctionne toujours.

Pointez oldsite.com vers newsite.com avec une simple redirection de domaine, puis suivez un vrai lien entrant, oldsite.com/pricing?utm_source=newsletter. Avec une redirection qui aplatit tout, ce visiteur atterrit sur la nouvelle page d'accueil, le chemin a disparu, et les paramètres de campagne sont partis avec lui. Rien ne plante. Vos analytiques montrent simplement du trafic direct vers la page d'accueil, et la newsletter a l'air de n'avoir servi à rien.

Deux habitudes évitent ce problème. Testez avec une URL profonde qui porte une chaîne de requête, jamais avec le domaine nu. Et quand les deux sites ont des structures différentes, faites correspondre explicitement les chemins importants plutôt que d'envoyer tout vers la racine, ce qui est aussi ce qui garde la valeur SEO des anciennes URL attachée à la nouvelle page la plus proche. La même discipline s'applique quand vous héritez des liens de quelqu'un d'autre, ce qui explique pourquoi migrer des liens courts sans les casser est un exercice de correspondance avant d'être un exercice technique.

Si les liens en question sont ceux que vous avez publiés, garder la destination modifiable vaut plus que tout le reste : mettez vos liens sur votre propre domaine et la correspondance devient un champ que vous modifiez plutôt qu'un fichier de configuration que vous déployez.

Vérifiez-la avant de l'annoncer

Une seule commande tranche la question :

curl -sIL "https://oldsite.com/pricing?utm_source=newsletter" | grep -E '^HTTP|^[Ll]ocation'

Lisez trois choses dans le résultat. Le code de statut doit être celui que vous vouliez, 301 pour permanent et 302 tant que les choses bougent encore, et 301 contre 302 explique pourquoi ce choix compte plus qu'il n'y paraît. L'en-tête Location doit porter le chemin complet et la chaîne de requête, pas un domaine nu. Et il ne doit y avoir qu'une seule redirection : une chaîne de trois ou quatre sauts se résout encore, mais chaque saut coûte de la latence et représente une nouvelle occasion de perdre des paramètres, et un nom d'hôte qui se répète signifie que vous avez construit une boucle de redirection plutôt qu'une redirection.

Si vous préférez ne pas ouvrir de terminal, notre vérificateur de liens trace la chaîne et affiche le statut à chaque saut.

Une URL profonde avec des paramètres UTM aplatie vers une page d'accueil par une redirection de domaine, à côté d'une redirection qui préserve le chemin et la chaîne de requête

Ce que les moteurs de recherche en font

Une redirection bien faite n'est pas un risque SEO, et les recommandations sont exceptionnellement claires sur ce point. La documentation de Google sur les redirections et la Recherche traite une redirection permanente côté serveur comme le signal le plus fort pour consolider une URL sur son remplacement, classe les redirections côté client en dessous, et vous demande de garder les chaînes courtes.

Les deux erreurs qui coûtent vraiment sont d'effondrer de nombreuses anciennes URL vers la page d'accueil, ce qui jette la pertinence spécifique que chacune avait, et de laisser une chaîne de sauts historiques en place après plusieurs migrations. Aucune des deux n'est une raison d'éviter les redirections ; toutes deux sont des raisons de les auditer. Cet audit est la même habitude hebdomadaire que la prévention de la pourriture des liens, et si la redirection se trouve sur un domaine court personnalisé, domaines personnalisés pour liens courts couvre la moitié DNS et certificat de la mise en place.

Choisissez la couche qui correspond à qui possède le changement, préservez le chemin, limitez-vous à un seul saut, et une redirection cesse d'être quelque chose qui vous inquiète.

Lire la série pilier

Cet article appartient au cluster tutorials. Pour les codes de statut et leur sémantique, les types de redirections d'URL est la carte, et comment fonctionnent les raccourcisseurs d'URL couvre ce qui se passe quand la redirection est un lien plutôt qu'une page.

Questions fréquentes

Comment rediriger une URL vers une autre URL ?

Faites en sorte que ce qui sert la requête renvoie un 301 ou un 302 avec un en-tête Location pointant vers la nouvelle adresse. En pratique, cela revient à choisir une couche : la redirection de domaine chez votre registrar, une règle dans votre serveur web ou votre plateforme d'hébergement, un plugin dans votre CMS, ou un lien court géré. La méthode change qui sert la réponse et si le chemin et la chaîne de requête survivent, pas ce que reçoit le navigateur.

Puis-je rediriger une URL avec le DNS ?

Non, et c'est le malentendu le plus courant sur tout ce sujet. Le DNS résout un nom d'hôte vers une adresse ; il n'a aucune idée du chemin demandé et ne peut pas renvoyer de redirection. Quand un registrar propose la redirection d'URL, il pointe en réalité le nom d'hôte vers un petit serveur web à lui, qui émet la redirection HTTP à votre place.

Une redirection conserve-t-elle le chemin et la chaîne de requête ?

Cela dépend entièrement de la méthode choisie. La redirection de domaine chez un registrar aplatit souvent tout vers une seule destination, si bien que /pricing?utm_source=email atterrit sur la page d'accueil, paramètres disparus. Une règle serveur ou plateforme peut préserver les deux si vous l'écrivez ainsi, et un lien court géré transfère la destination stockée, chaîne de requête comprise. Testez avec une URL profonde, pas seulement la racine du domaine.

Dois-je utiliser une redirection 301 ou 302 ?

Utilisez un 301 quand le déplacement est permanent et que vous voulez que les moteurs de recherche consolident les signaux sur la nouvelle URL, et un 302 tant que quelque chose reste en mouvement. Le piège pratique, c'est que les navigateurs mettent un 301 en cache de façon très agressive, si bien qu'une redirection permanente que vous regrettez ensuite continue de se déclencher pour les visiteurs récurrents longtemps après que vous avez changé le serveur. Testez avec un 302, promouvez en 301 une fois la destination stabilisée.

Comment vérifier que ma redirection fonctionne ?

Exécutez curl -sIL sur l'URL et lisez les lignes de statut et les en-têtes Location. Vous voulez une seule redirection, le bon code de statut, et la destination attendue, avec le chemin et la requête intacts. Une chaîne de plusieurs sauts fonctionne encore mais gaspille de la latence, et un nom d'hôte qui se répète signifie que vous avez construit une boucle plutôt qu'une redirection.

Les redirections nuisent-elles au SEO ?

Une redirection correctement mise en œuvre, non. Google traite un 301 comme un signal fort pour consolider le positionnement sur la destination, et ce sont les longues chaînes, pas les redirections elles-mêmes, qui posent problème. Limitez-vous à un seul saut, pointez les anciennes URL vers la nouvelle page la plus proche plutôt que de tout déverser sur la page d'accueil, et évitez les redirections côté client quand une redirection côté serveur est possible.

Essayer Elido

Collez une URL, obtenez un lien court

Sans inscription. Lien actif 30 jours. Inscrivez-vous pour le garder pour toujours.

Gratuit, sans inscription · 2 par jour