Configurer la redirection 301 d’une page vers une nouvelle URL facilement

Une page qui disparaît sans redirection, c'est un client qui sonne à votre ancienne adresse et qui trouve porte close. Sauf qu'en ligne, il ne revient pas. Il tombe sur un 404, hausse les épaules, et va voir ailleurs. La redirection 301 existe précisément pour éviter ça : elle dit au navigateur et à Google « cette page a déménagé définitivement, va là-bas ».

Le problème, c'est que la plupart des articles qui en parlent s'arrêtent à la théorie. On vous explique ce qu'est une 301, pourquoi c'est important pour le SEO, et puis... rien. Pas un mot sur la ligne `.htaccess` à écrire, ni sur le piège des chaînes de redirections qui vous font perdre du jus sans que vous le sachiez.

Je vais vous montrer les deux côtés : comment la configurer concrètement selon votre hébergement, et surtout comment ne pas saboter votre référencement en croyant bien faire.

Ce qui distingue vraiment une redirection 301 d'une 302

Le code HTTP n'est pas un détail technique. C'est un message adressé à deux publics à la fois : l'humain devant son écran, et le robot d'indexation.

Quand vous configurez une 301 Moved Permanently, vous dites : « cette adresse n'existe plus, la nouvelle est définitive. » Google retire progressivement l'ancienne URL de son index et lui substitue la nouvelle, en lui transmettant l'historique de liens, l'ancienneté, et autres signaux accumulés.

La 302 Found raconte une autre histoire. Elle signifie « déplacement temporaire ». Google garde l'ancienne URL dans son index, ne transfère pas les signaux, et continue de la considérer comme la version de référence.

Dans quel cas utiliser une 302

• Une promotion limitée dans le temps sur une page dédiée
• Un test A/B pendant quelques semaines
• Une maintenance temporaire
• Une page en cours de refonte que vous remettrez en ligne

Si vous redirigez définitivement une page et que vous mettez une 302 par réflexe ou par flemme, vous ne transférez rien. C'est l'erreur que j'ai commise sur un ancien site : après un changement de slug, j'avais laissé une 302 « pour voir ». Six mois plus tard, la nouvelle page n'avait toujours pas pris la place de l'ancienne dans les résultats. Corrigé en 301, l'effet a été visible en quelques semaines.

Configurer la redirection 301 selon votre type d'hébergement

C'est ici que la majorité des tutoriels vous abandonnent. Pourtant, la méthode change complètement selon que vous êtes sur un serveur Apache, Nginx, ou un CMS fermé comme Wix.

La méthode .htaccess (serveurs Apache)

Vous ouvrez ou créez le fichier .htaccess à la racine de votre site, et vous ajoutez une ligne de ce type :

Redirect 301 /ancienne-page/ https://www.votresite.fr/nouvelle-page/

Une ligne par redirection. Pour des règles plus souples, la directive RewriteRule permet d'utiliser des expressions régulières. Attention : une seule faute de frappe dans le chemin et vous redirigez tout le site vers une page blanche. Je teste toujours sur une préproduction avant de toucher au `.htaccess` en production. Toujours.

Le cas Nginx

Nginx n'utilise pas de `.htaccess`. La redirection se déclare dans le fichier de configuration du serveur, avec une syntaxe différente. Si votre hébergeur est sur Nginx et que vous cherchez un `.htaccess`, vous perdez votre temps : il n'existera jamais. C'est une confusion fréquente chez ceux qui changent d'hébergement.

WordPress et les CMS

Sur WordPress, plusieurs options, du plus simple au plus technique :

• Le plugin Redirection, qui gère un tableau de correspondances et détecte les erreurs 404
• L'extension Yoast SEO, qui propose un champ de redirection sur chaque page ou article
• Le fichier .htaccess directement, si vous êtes à l'aise

Le point commun de tous les CMS corrects : dès que vous modifiez le slug d'une page publiée, ils proposent de créer automatiquement la redirection. Acceptez. Toujours.

Sur Wix et les plateformes fermées

Sur Wix, vous n'avez pas accès au serveur. La redirection passe par le gestionnaire de redirections dans les paramètres SEO du tableau de bord. Vous saisissez l'ancienne URL et la nouvelle, point.

La redirection 301 sur Wix fonctionne, mais avec une limite : certaines redirections ne sont pas transmises quand l'ancienne URL contenait des paramètres ou des ancres. Si vous migrez depuis un autre système vers Wix, listez toutes vos anciennes URL avant, sinon vous en oublierez.

Plateforme	Où configurer	Contrôle total sur les règles
Apache	Fichier .htaccess	Oui
Nginx	Fichier de configuration serveur	Oui
WordPress	Plugin, Yoast, ou .htaccess	Oui
Wix	Gestionnaire de redirections (tableau de bord)	Limité
Shopify	Paramètres > Navigation > URL de redirection	Limité

Le piège des chaînes et des boucles de redirection

Deux redirections vers une même destination, c'est propre. Trois qui s'enchaînent, c'est un problème.

Imaginez : vous redirigez la page A vers B. Un an plus tard, vous renommez B en C, avec une redirection B → C. Résultat pour quelqu'un qui clique sur un vieux lien vers A : A → B → C. Deux sauts au lieu d'un. Chaque saut supplémentaire gaspille un peu du signal transmis, et ralentit légèrement le chargement pour l'utilisateur.

La boucle de redirection est pire. A redirige vers B, et B redirige vers A. Résultat : le navigateur abandonne après plusieurs tentatives et affiche une erreur. La page est inaccessible, pour l'humain comme pour le robot.

Comment repérer ces cas ? Deux réflexes :

• Après toute migration, testez chaque ancienne URL et vérifiez qu'elle arrive en un seul saut à la bonne destination
• Sur un site avec beaucoup de pages, un outil de crawl signale automatiquement les chaînes et les boucles

J'ai vu un site avec 47 chaînes de redirection actives, accumulées sur quatre ans de renommages successifs. Personne ne s'en était rendu compte. Le nettoyage a pris une demi-journée, mais il a clarifié tout le maillage interne.

Rediriger une page du même site ou vers un autre domaine

La mécanique technique est identique. Les enjeux, non.

Une redirection interne (même domaine) corrige un slug modifié, fusionne deux pages proches, ou remplace une page supprimée. C'est du ménage courant.

Une redirection externe (vers un autre domaine) implique un transfert de signal entre deux propriétés différentes. Si vous déplacez tout un site vers un nouveau domaine, vous devez rediriger chaque page vers sa correspondante, pas seulement la page d'accueil. Un site migré où seule la racine est redirigée perd la quasi-totalité de son historique.

Le cas le plus mal traité : la migration HTTP vers HTTPS. Elle devrait être une redirection globale, pas des centaines de règles individuelles. Une règle serveur bien écrite suffit à basculer tout le trafic.

Comment vérifier qu'une redirection fonctionne

Ne vous fiez pas à votre navigateur. Il met les redirections en cache et vous mentira sur l'état réel.

Ouvrez les outils de développement (touche F12), onglet Réseau, puis chargez l'ancienne URL. Vous devez voir un code 301 suivi d'un code 200 sur la nouvelle adresse. Si vous voyez un 302, ou une chaîne de plusieurs 301, quelque chose ne va pas.

Un second test, plus rapide pour un lot de pages : un outil en ligne qui affiche l'en-tête HTTP renvoyé. Vous y lirez le code exact, sans cache pour fausser la lecture.

Ce que vous devez obtenir au final : 301 vers la nouvelle URL, puis 200. C'est le seul résultat valide.

Peut-on faire une redirection en JavaScript ?

Techniquement, oui, avec window.location. En pratique, c'est une mauvaise idée pour du référencement. Un robot qui n'exécute pas le JavaScript ne verra jamais la redirection : il verra juste une page au contenu vide ou inchangé. Le signal n'est pas transmis proprement. Réservez le JavaScript à des cas d'usage purement fonctionnels, jamais pour une redirection destinée à Google.

Ce qu'il faut garder en tête

Une redirection 301 n'est pas une case à cocher après une migration. C'est une correspondance à maintenir dans le temps. Chaque fois que vous renommez une URL, vous créez une dette technique qui s'accumule si personne ne nettoie.

Ma règle personnelle : dès qu'une page a reçu ne serait-ce qu'un seul lien externe, sa redirection est obligatoire. Pas optionnelle. Une page sans lien entrant peut disparaître sans dommage ; une page liée depuis ailleurs ne doit jamais mourir sans successeur.

Et si vous ne devez retenir qu'une chose de tout ça : testez. Après chaque migration, chaque changement de slug, chaque bascule de domaine. Cinq minutes de vérification valent mieux que six mois à se demander pourquoi le trafic ne revient pas.