Redirection 301 — déménagement permanent

TL;DR — Une redirection 301 envoie définitivement toute personne (ou tout robot) qui visite une ancienne URL vers une nouvelle. C’est le bon outil lorsqu’une page déménage pour de bon : nouveau domaine, nouvelle URL, passage de HTTP à HTTPS ou fusion de deux pages. Configurez-la sur votre serveur, pointez chaque ancienne URL vers son vrai remplacement (pas simplement vers l’accueil) et laissez-la en place. Google indique qu’une 301 ne coûte pas de valeur de classement : il n’y a donc rien à craindre.

Qu’est-ce qu’une redirection 301 ?

Quand un navigateur ou un moteur de recherche demande une page, votre serveur répond avec un code d’état HTTP à trois chiffres. 200 signifie « voici la page ». 404 signifie « introuvable ». 301 signifie « Moved Permanently » : cette URL a une nouvelle adresse, utilisez-la à la place.

Une redirection 301 est donc votre serveur qui indique à tous : la ressource demandée se trouve désormais à une autre adresse, et ce déplacement est permanent. Les visiteurs sont envoyés automatiquement vers la nouvelle page et les moteurs mettent à jour leurs enregistrements pour pointer vers la nouvelle URL.

Quand l’utiliser

Utilisez une 301 dès que l’adresse d’une page est modifiée définitivement :

• Vous modifiez une URL — page renommée, structure du site réorganisée ou URL nettoyée.
• Vous migrez vers un nouveau domaine — rebranding ou migration de site.
• Vous passez à HTTPS — chaque URL http:// doit renvoyer une 301 vers sa jumelle https://.
• Vous fusionnez des pages — deux articles similaires deviennent un seul ; redirigez les anciennes URL vers la page conservée.
• Vous retirez une page avec un remplacement clair — envoyez-la vers l’équivalent le plus proche, pas vers une impasse.

Le conseil de Google est le suivant : “If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible.” (traduction) « Si vous devez modifier l’URL d’une page affichée dans les résultats d’un moteur, utilisez autant que possible une redirection permanente côté serveur. »

Le chiffre que vous devez ignorer

Vous entendrez dire qu’une 301 « perd 10–15 % de popularité de liens ». C’est un vieux mythe. Google est direct : “301 and other permanent redirects don’t cause a loss in PageRank.” (traduction) « Les redirections 301 et autres redirections permanentes ne font pas perdre de PageRank. » N’évitez donc pas une redirection par peur de « fuir » de la valeur : une 301 correcte transmet à la destination les signaux acquis par l’ancienne URL.

Vous verrez aussi des affirmations assurées selon lesquelles une 301 « transmet 90–99 % de la popularité des liens ». Ignorez-les également : Google ne publie aucun pourcentage de ce type et ce chiffre est inventé.

Trois points à régler correctement

1. Pointez chaque ancienne URL vers son vrai remplacement — pas vers l’accueil. Si vous envoyez toutes les pages retirées vers la page d’accueil, Google peut les traiter comme des erreurs (un « soft 404 ») et ne pas transmettre la valeur. Faites une correspondance une pour une.
2. Utilisez une vraie 301, pas une fausse. Une redirection faite uniquement en JavaScript ou un lien « cliquez ici si vous n’êtes pas redirigé » n’est pas équivalent : Google peut ne même pas la voir. Faites-la au niveau du serveur.
3. Laissez-la en place. Google recommande de conserver les redirections généralement au moins un an pour laisser le temps aux signaux de se transférer. Si vous le pouvez, gardez-les indéfiniment.

Et une 302 ?

A 302 est la version temporaire : « cette page a été déplacée pour l’instant, mais l’originale reste la vraie ». Si vous utilisez 302 alors que vous vouliez 301, Google peut conserver l’ancienne URL dans ses résultats au lieu de la nouvelle. Lorsque le déplacement est permanent, utilisez 301. (Une comparaison complète de 301 et 302 est disponible ailleurs.)

Pour les configurations serveur, les délais, les règles de chaîne et le diagnostic d’une « fausse » 301 qui échoue en silence, passez à l’onglet Advanced.

TL;DR — Une 301 (HTTP « 301 Moved Permanently ») est une réponse côté serveur qui déplace définitivement une URL et constitue le signal le plus fort pour consolider le classement sur la destination. Google précise que les redirections permanentes ne font pas perdre de PageRank : la règle des « ~15 % par saut » est morte et aucun pourcentage publié de valeur transmise n’existe, n’en inventez donc pas. Implémentez-la sur le serveur (Apache, nginx, code applicatif) ou sur le edge (Cloudflare), pas avec un contournement JavaScript ou un meta-refresh différé. Redirigez les anciennes URL vers leur équivalent pertinent, une pour une — pas toutes vers l’accueil, que Google peut reclasser en soft 404. Gardez les chaînes courtes (Google suit jusqu’à 10 sauts mais recommande moins d’environ 5). L’effet serveur est instantané ; la consolidation complète des signaux dans l’index prend des semaines à généralement au moins un an.

Ce qu’est réellement une 301

Une 301 est un code d’état HTTP — « 301 Moved Permanently » — renvoyé par votre serveur (ou par le edge de votre CDN) dans les en-têtes de réponse, avant tout corps de page. C’est le point important : une vraie 301 se produit au niveau du protocole, dans la réponse à la requête. Ce n’est ni une fonctionnalité de plugin, ni une balise <meta>, ni un extrait JavaScript ; ces solutions de contournement servent quand le serveur ne peut pas agir et se comportent différemment (voir ci-dessous).

Google donne une définition simple : “The 301 and 308 status codes mean that a page has permanently moved to a new location.” (traduction) « Les codes d’état 301 et 308 signifient qu’une page a été déplacée définitivement vers un nouvel emplacement. » (308 est le code de redirection permanente plus récent, qui préserve aussi la méthode ; pour le SEO, Google traite 301 et 308 de la même manière et recommande d’utiliser si possible les redirections permanentes HTTP, comme 301 et 308.)

Quelques détails de protocole comptent. Une réponse 301 est cacheable par heuristique par défaut : un navigateur ou un cache intermédiaire peut la conserver, raison pour laquelle une redirection « corrigée » peut encore envoyer les tests vers l’ancienne cible jusqu’à expiration du cache. Comme la 301 existe depuis HTTP/1.0, un agent utilisateur peut transformer une requête POST en GET en la suivant ; ne supposez donc pas qu’une 301 préserve la méthode originale d’un formulaire. Utilisez 308 si cela compte. L’en-tête Location doit simplement être une référence URI (elle peut être relative), mais une URL absolue évite les ambiguïtés.

Comment Google traite une 301 (canonicalisation et indexation)

Une redirection permanente est l’un des signaux de canonicalisation les plus forts dont dispose Google. Quand Googlebot suit une 301, le pipeline d’indexation utilise la redirection comme signal indiquant que la cible devrait être l’URL canonique. Google conserve une trace des deux extrémités : “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical… The other URL becomes an alternate name of the canonical URL.” (traduction) « Lorsque vous redirigez une URL, Google suit la source et la cible ; l’une devient canonique et l’autre un autre nom de cette URL canonique. »

C’est pourquoi vous pouvez encore voir une ancienne URL dans les résultats quelque temps après un déplacement : Google la conserve comme « autre nom ». Pas de panique : pour un déplacement de domaine, Google indique : “it’s very likely that Google will continue to occasionally show the old URLs in the results, even though the new URLs are already indexed. This is normal… the alternate names will fade away without you doing anything.” (traduction) : « Il est très probable que Google continue à afficher occasionnellement les anciennes URL dans les résultats, même si les nouvelles URL sont déjà indexées. C’est normal… les autres noms disparaîtront sans que vous ayez quoi que ce soit à faire. »

Une redirection l’emporte sur les signaux de canonicalisation plus faibles. Gary Illyes a formulé la hiérarchie ainsi : une redirection « devrait avoir un poids bien plus élevé… que le fait qu’une page soit en HTTP ou en HTTPS ». Une 301 égarée peut donc remplacer en silence une balise canonical ou une préférence HTTPS qui pointe dans l’autre direction. (Voir le traitement complet de la canonicalisation.)

Il faut préciser ce que ce signal fait et ne promet pas : une 301 est un signal fort vers une cible canonique, pas une garantie. Elle indique à Google quelle URL devrait être canonique, sans garantir que cette URL sera indexée, qu’elle se classera, que le trafic suivra ou que tous les autres signaux (liens, qualité du contenu, autorité du site) seront transférés automatiquement. Traitez « choix canonique » et « indexation, classement, trafic » comme des questions distinctes ; la 301 répond directement à la première seulement.

Le mythe du PageRank — être exactement précis

C’est le fait le plus déformé à propos des redirections permanentes ; voici donc la version précise.

**Déclaration exacte de Google : “301 and other permanent redirects don’t cause a loss in PageRank.” (traduction) « Les redirections 301 et autres redirections permanentes ne font pas perdre de PageRank. » C’est tout : ni « vous gardez 85 % », ni « vous perdez 10–15 % par saut ». Aucune perte.

La règle des « ~15 % par saut » vient d’anciennes déclarations, antérieures à 2016, sur l’amortissement du PageRank à travers les redirections (souvent attribuées à Matt Cutts). Google l’a inversée publiquement autour de 2016 : selon les comptes rendus de l’époque, Google a cessé d’appliquer une dilution du PageRank à travers les redirections 30x et la destination reçoit l’autorité.

Le corollaire qui piège dans l’autre sens : ne dites pas qu’une 301 « transmet 90–99 % de la popularité des liens ». Google ne publie aucun chiffre de ce type. « Ne fait pas perdre de PageRank » est une affirmation directionnelle, pas un pourcentage ; tout pourcentage précis relève du folklore, pas d’une confirmation de Google. Citez la formulation « aucune perte » ; n’inventez jamais de chiffre.

J’ajoute une mise en garde issue de mes propres essais. J’ai testé l’affirmation selon laquelle les « signaux restent après un an » en supprimant les 301 de quatre articles Ahrefs bien référencés et en observant le résultat (Is It OK to Supprimer 301 Redirections Après a Année? We Testé It). Les domaines référents ont nettement diminué après le retrait des redirections et le trafic organique a varié — un article en hausse, un en baisse, deux presque stables, avec une « chute » apparente qui précédait en réalité le retrait. Ma conclusion honnête est que je ne peux pas affirmer que les redirections permanentes conservent toute leur valeur après un an, mais l’observation de Gary semble globalement vraie. Échantillon réduit, donc prudence ; la leçon pratique reste simple : ne supprimez pas vos redirections.

Timing — three différent clocks

« Combien de temps faut-il à une 301 pour fonctionner ? » dépend de l’horloge considérée :

• Le serveur : instantané. Dès que la règle est active, chaque requête reçoit 301 et les utilisateurs arrivent sur la nouvelle URL. Aucun délai.
• L’index : de quelques jours à quelques semaines. Google doit recrawler l’ancienne URL, voir la redirection et traiter la cible. Un petit ou moyen site peut prendre quelques semaines pour déplacer la plupart des pages ; les grands sites prennent plus longtemps, et la visibilité peut fluctuer temporairement pendant le déplacement.
• Consolidation complète des signaux : généralement au moins un an. Google recommande de conserver les redirections aussi longtemps que possible, généralement au moins un an, pour transférer tous les signaux vers les nouvelles URL ; du point de vue utilisateur, envisagez de les garder indéfiniment.

Règle pratique : gardez les redirections permanentes en place au moins un an, et idéalement indéfiniment si cela ne vous coûte rien.

Implementing a 301

Faites-le aussi près du serveur que possible. Voici quatre voies qui couvrent presque tous les cas. (Elles sont illustratives : adaptez chemins et noms d’hôte à votre configuration ; l’onglet Scripts contient des versions prêtes à copier ainsi que les tests.)

Sauvegardez votre configuration .htaccess ou nginx avant toute modification : une règle mal formée peut mettre tout le site hors ligne, pas seulement l’URL redirigée.

Apache (.htaccess)

Pour une URL unique avec mod_alias :

Redirect permanent "/old-page" "https://example.com/new-page"

Pour des règles basées sur un modèle avec mod_rewrite :

RewriteEngine on
RewriteRule "^/service$" "/about/service" [R=301,L]

nginx

location = /service {
  return 301 https://example.com/about/service;
}

WordPress

WordPress n’a pas de gestionnaire de redirections intégré ; vous pouvez en ajouter un :

• Extension Redirection (gratuite) — le choix le plus courant ; ajoutez source → cible dans une interface, sans code.
• Yoast SEO Premium — son gestionnaire de redirections peut créer automatiquement une redirection lorsque vous supprimez ou modifiez le slug d’une URL. La version gratuite de Yoast n’a aucun gestionnaire de redirections (beaucoup de tutoriels l’omettent).
• Au niveau du serveur — si vous pouvez modifier directement .htaccess/nginx, une règle serveur est plus rapide qu’une extension PHP exécutée à chaque requête.

Cloudflare

Si vous utilisez Cloudflare, vous pouvez rediriger au niveau du edge, avant que la requête n’atteigne votre origine :

• Redirections uniques — règles ponctuelles dans le tableau de bord.
• Redirections groupées — une liste de redirections (milliers de paires source → cible) appliquée à tout le compte. Très utile pour une migration complète, car vous n’avez pas à toucher la configuration d’origine, notamment lorsque l’ancien serveur est décommissionné.

Application code (PHP exemple)

header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/new-url');
exit();

« Fausses » redirections : l’échec que personne ne vérifie

Voici un point contre-intuitif à retenir : une URL peut retourner 200 OK tout en redirigeant. Comme je l’ai écrit dans 11 Types Of Redirections & Leur SEO Impact, “A redirect can still be happening with any status code. You may have a page that shows as a 200 OK status code, but is actually still redirecting” (traduction) « Une redirection peut encore se produire avec n’importe quel code d’état : une page peut afficher 200 OK tout en redirigeant réellement » — via JavaScript après le chargement. Cette « redirection » échappe à un vérificateur de statut rapide et ne bénéficie d’aucune garantie d’une 301.

Google classe les méthodes ainsi :

• Côté serveur (301/308) : meilleur choix. Utilisez cette méthode dès que possible.
• Meta-refresh : dépend du délai. Un meta-refresh instantané est interprété comme une redirection permanente ; un meta-refresh différé est temporaire. Un rafraîchissement content="5;url=…" ne remplace donc pas une 301.
• JavaScript : dernier recours. Utilisez-le seulement si le serveur ou le meta-refresh sont impossibles ; si le rendu échoue, Google peut ne jamais voir la redirection.
• Pseudo-redirections par lien : à éviter. Une page qui contient seulement un lien vers la nouvelle URL, sans code d’état ni rafraîchissement, n’est pas reconnue comme une redirection officielle.

Leçon : pour le SEO, confirmez que la redirection est une vraie 301 côté serveur, pas une page 200 qui redirige dans le navigateur. L’onglet Scripts montre comment vérifier avec curl.

Erreurs courantes avec les 301

• Tout rediriger vers l’accueil. Le grand classique. Cela peut dérouter les utilisateurs et être traité comme un soft 404. Redirigez vers le remplacement pertinent ; si plusieurs pages ont réellement été fusionnées, la nouvelle page commune convient.
• Chaînes trop longues. Google peut suivre jusqu’à 10 sauts, mais conseille d’aller directement à la destination finale, idéalement au plus 3 et moins de 5. Les chaînes ajoutent aussi de la latence. Quand vous ajoutez une redirection, mettez à jour les anciennes règles pour pointer vers l’URL finale, pas vers le saut précédent.
• Utiliser 302 au lieu de 301. Une 302 indique à Google de préférer l’URL originale ; un déplacement permanent en 302 peut donc laisser l’URL incorrecte indexée. Utilisez le code qui correspond à l’intention.
• Supprimer les redirections trop tôt. Moins d’un an risque de laisser la valeur sur l’ancienne URL. Gardez-les au moins un an, idéalement indéfiniment.
• Règles wildcard trop larges. Un attrape-tout de dossier envoie souvent des URL vers la mauvaise page. Faites une correspondance ancienne → nouvelle 1:1 autant que possible.
• Oublier les ressources non HTML. Lors d’une migration, redirigez aussi les images et les PDF ; ne redirigez pas aveuglément les fichiers JS/CSS/polices.
• Éteindre trop tôt l’ancien hôte. Une règle ne peut pas sauver une requête qui ne l’atteint jamais. Gardez DNS, certificat TLS et règles de l’ancien hôte actifs aussi longtemps que les redirections.

Bing

Bing traite une 301 comme un signal fort pour consolider le classement sur l’URL cible et retirer l’ancienne de son index, selon le même modèle général que Google. Ses recommandations anciennes conseillent de conserver une redirection permanente au moins quelques mois, durée plus courte que l’année environ de Google ; son guide de migration indique que les 301 suffisent généralement et que son outil de déplacement de site ne les remplace pas. Si vous servez les deux moteurs, suivez la règle la plus stricte : de vraies 301 côté serveur, conservées au moins un an.

Où se situe cette redirection

Une 301 est un code d’état parmi d’autres. Elle se rapproche surtout de la redirection 302 (son équivalent temporaire) : le choix 301 ou 302 revient à demander si le déplacement est permanent. Elle est la cousine proche de la canonicalisation (une 301 est un signal canonique fort pour déplacer une page, pas pour regrouper des doublons qui restent actifs — utilisez alors rel="canonical"). Elle constitue aussi la base de toute migration de site. Pour les autres codes — 302/307 temporaires, 308 permanent, 404/410 supprimés, erreurs 5xx — consultez le cluster des codes d’état HTTP.

Résumé IA

Une synthèse de la version Advanced :

• 301 = HTTP « 301 Moved Permanently » — réponse côté serveur qui déplace définitivement une URL et constitue l’un des signaux de cible canonique les plus forts de Google. C’est un signal, pas une garantie : il ne promet ni indexation, ni classement, ni trafic. Google traite 301 et 308 de la même manière pour le SEO, mais une 301 peut convertir POST en GET et est cacheable par heuristique ; utilisez 308 si la méthode doit être préservée.
• Aucune perte de PageRank. Google dit que les redirections permanentes ne font pas perdre de PageRank. La vieille règle des « ~15 % par saut » est morte et Google ne publie aucun pourcentage de popularité transmise : ne citez jamais « 90–99 % ».
• Trois horloges : serveur = instantané ; migration d’index = jours à semaines (davantage pour les grands sites) ; consolidation complète = généralement au moins un an. Gardez les redirections au moins un an, idéalement indéfiniment.
• Implémentation côté serveur/edge : Apache .htaccess (Redirect permanent / mod_rewrite [R=301]), nginx (return 301), WordPress (extension Redirection ou Yoast Premium — la version gratuite n’a pas de gestionnaire), Cloudflare Unique/Groupées (edge, sans configuration d’origine) ou code applicatif.
• « Fausses » 301 : une page peut retourner 200 et rediriger en JavaScript, invisible à un vérificateur de statut. Meta-refresh instantané ≈ permanent ; différé ≈ temporaire ; JS en dernier recours ; les pseudo-redirections par lien sont peu fiables.
• Erreurs principales : tout envoyer vers l’accueil (risque de soft 404) ; chaînes longues (restez sous ~5 sauts) ; utiliser 302 pour un déplacement permanent ; retirer les redirections trop tôt ; wildcard larges au lieu d’une correspondance 1:1.
• Mise en garde de Patrick : son test de retrait des 301 après un an a donné des résultats réels plus mélangés que le récit « un an suffit » ; gardez donc les redirections.

Documentation officielle

Documentation de référence des moteurs de recherche.

Google

• Redirections et recherche Google — définition de 301, redirections côté serveur, meta-refresh et JavaScript, règles de délai et exemples PHP, Apache et nginx.
• Déplacement de site avec changement d’URL — absence de perte de PageRank, conservation au moins un an, limites des chaînes, avertissement soft 404 et différences entre petits et grands sites.
• Définir une URL canonique — place des redirections parmi les signaux de canonicalisation.
• Exploration et indexation — hub des redirections, de la canonicalisation et du contrôle d’exploration.

Bing / Microsoft

• Bing Webmaster Guidelines — position de Bing sur les redirections et déplacements permanents.
• Migration de site avec Bing (déc. 2020) — outil de déplacement de site de Bing et rappel que les redirections permanentes suffisent généralement.

Mise en œuvre sur les plateformes

• Cloudflare — Redirections groupées — listes de redirections appliquées au niveau du compte et du edge.
• Cloudflare — Présentation du transfert d’URL — redirections uniques ou groupées.
• Yoast — Créer une redirection 301 dans WordPress — méthodes propres à WordPress et rappel que la gestion des redirections est une fonctionnalité Premium.

Citations des sources

Déclarations attribuées à Google. Chaque lien renvoie directement au passage cité sur la page source.

Google — définition et emploi d’une 301

• “The 301 and 308 status codes mean that a page has permanently moved to a new location.” (traduction) « Les codes 301 et 308 signifient qu’une page a été déplacée définitivement vers un nouvel emplacement. » — Google Search Central, Redirections et recherche Google. Accéder à la citation
• “If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible.” (traduction) « Pour modifier l’URL affichée dans les résultats, utilisez autant que possible une redirection permanente côté serveur. » Accéder à la citation
• “Use server side permanent redirects if technically possible… we recommend that you use HTTP permanent redirects if possible, such as 301 and 308.” (traduction) « Utilisez des redirections permanentes côté serveur ; si possible, des redirections HTTP comme 301 et 308. » — Google Search Central, Déplacement de site avec changement d’URL. Accéder à la citation

Google — PageRank et consolidation (le socle de précision)

• “301 and other permanent redirects don’t cause a loss in PageRank.” (traduction) « Les redirections 301 et autres redirections permanentes ne font pas perdre de PageRank. » — Google Search Central, Déplacement de site. Accéder à la citation
• “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical… The other URL becomes an alternate name of the canonical URL.” (traduction) « Lorsque vous redirigez une URL, Google suit la source et la cible ; l’une devient canonique et l’autre un autre nom. » — Google Search Central. Accéder à la citation

Google — délais

• “Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs… From users’ perspective, consider keeping redirects indefinitely.” (traduction) « Gardez les redirections aussi longtemps que possible, généralement au moins un an, pour transférer tous les signaux ; envisagez de les conserver indéfiniment. » — Google Search Central. Accéder à la citation
• “A small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer… the visibility of your content in Search may fluctuate temporarily during the move. This is normal.” (traduction) « Un petit ou moyen site peut prendre quelques semaines pour déplacer la plupart des pages, et les grands sites davantage ; la visibilité peut fluctuer temporairement. C’est normal. » Accéder à la citation

Google — chaîne de redirectionss, soft 404s, and fake redirections

• “While Googlebot can follow up to 10 hops in a ‘chain’ of multiple redirects… we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.” (traduction) « Googlebot peut suivre jusqu’à 10 sauts ; redirigez directement vers la destination finale et gardez les chaînes courtes, idéalement moins de 5. » Accéder à la citation
• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error.” (traduction) « Ne redirigez pas de nombreuses anciennes URL vers une destination unique et sans rapport, comme l’accueil ; cela peut dérouter et être traité comme un soft 404. » Accéder à la citation
• “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects… if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” (traduction) « Utilisez JavaScript seulement si le serveur et le meta-refresh sont impossibles ; Google peut ne jamais voir la redirection si le rendu échoue. » — Recherche Google Central, Redirections and Recherche Google. Jump to quote
• “Google Search interprets instant meta refresh redirects as permanent redirects… Google Search interprets delayed meta refresh redirects as temporary redirects.” (traduction) « Google interprète le meta-refresh instantané comme permanent et le meta-refresh différé comme temporaire. » Accéder à la citation

301 redirection implementation checklist

A réussir to run avant, during, and après putting a redirection permanente (or a batch of les) live:

Avant

• Confirmer que le déplacement est réellement permanent — s’il est temporaire, utilisez 302, pas 301.
• Construire une correspondance 1:1 entre l’ancienne URL et la nouvelle URL la plus pertinente (pas l’ancienne URL vers l’accueil).
• Pour les regroupements, décider quelle URL survivante chaque groupe doit conserver.
• Prévoir aussi les images et PDF (ignorer les fichiers JS/CSS/polices).

Mise en œuvre

• Faire la redirection côté serveur (Apache/nginx/application) ou sur l’edge (Cloudflare), jamais via JavaScript ou un meta-refresh différé.
• Préférer des règles 1:1 aux jokers de dossier trop larges qui peuvent mal router les URL.
• Faire pointer chaque règle vers la destination finale, pour ne pas créer de chaînes.
• Dans WordPress, utiliser l’extension Redirection ou Yoast Premium (Yoast gratuit n’a pas de gestionnaire de redirections), ou une règle serveur.

Vérification

• Vérifier que chaque ancienne URL renvoie une vraie 301 (pas 200, pas 302, pas une redirection JavaScript) — voir l’onglet Scripts pour les commandes curl.
• Confirmer qu’il n’existe aucune chaîne de plus d’environ 5 sauts ; réduire toute chaîne trouvée à un seul saut.
• Vérifier que la cible renvoie 200, pas une autre redirection ni une 404.
• Tester une URL avec une chaîne de requête, un fragment, un slash final ou une casse mixte — les règles peuvent supprimer ou modifier silencieusement ces éléments au lieu de les conserver.
• Contrôler quelques URL redirigées dans l’Inspection d’URL de GSC pour voir comment Google les résout.
• Pour une migration, lancer un crawl du site (Ahrefs Site Audit / Screaming Frog) afin de détecter les boucles et chaînes de redirection, ainsi que les anciennes URL absentes de la carte.

Après

• Laisser les redirections en place généralement au moins un an, idéalement indéfiniment.
• S’attendre à ce que l’ancienne URL reste quelque temps dans les résultats comme « autre nom » ; c’est normal, ne supprimez pas la redirection pour la faire disparaître.

Detecting and testing 301s

Vérifiez avec le Redirection Checker :

1. Collez l’URL à tester dans le champ URL unique (ou passez au mode groupé, jusqu’à 20 à la fois).
2. Cliquez sur Vérifier les redirections pour tracer la chaîne complète.
3. Lisez le code du premier saut et le verdict : une redirection permanente affiche 301 (ou 308) directement ; un 302/307 ou une gravité « chaîne » signifie qu’il ne s’agit pas d’une 301 propre en un seul saut.

Le but est de répondre à une question : cette URL renvoie-t-elle réellement une 301 côté serveur, ou quelque chose me trompe-t-il ? (Une page peut retourner 200 OK tout en redirigeant dans le navigateur via JavaScript.)

Ne testez pas seulement l’URL nue : relancez la vérification avec une chaîne de requête, un #fragment, un slash final ou une casse différente. La spécification HTTP ne garantit pas qu’une règle RewriteRule conserve ces éléments ; c’est un détail d’implémentation et les motifs peuvent supprimer silencieusement la chaîne ou le fragment.

Voir le code d’état brut et la chaîne de redirections (curl)

macOS / Linux / WSL

# Show response headers only — look for "HTTP/… 301" and the "location:" target
curl -sI https://example.com/old-page

# Follow the whole chain and print each hop's status + final URL
curl -sIL -o /dev/null -w "%{http_code}  %{url_effective}\n" https://example.com/old-page

# Print every status code in the chain (catches multi-hop chains)
curl -sIL https://example.com/old-page | grep -i "^HTTP\|^location"

‘A clean permanent redirect looks like HTTP/1.1 301 Moved Permanently (or HTTP/2 301) with a single location: header pointing at the final URL. If you see 302, it’s temporary. If you see 200 but the browser still ends up somewhere else, it’s a JavaScript/meta-refresh “fake” redirect.’ (traduction) « Une redirection permanente propre utilise le statut approprié, avec un seul en-tête indiquant l’URL finale. Un statut temporaire signale un déplacement provisoire ; si le navigateur arrive ailleurs malgré une réponse réussie, il s’agit d’une fausse redirection JavaScript/meta-refresh. »

Windows (PowerShell)

# MaximumRedirection 0 stops at the first hop so you can read its status code
$r = Invoke-WebRequest -Uri "https://example.com/old-page" -MaximumRedirection 0 -SkipHttpErrorCheck
$r.StatusCode              # 301 for a permanent redirect
$r.Headers.Location        # the target URL

Repérer une « fausse » redirection JavaScript

curl ne voit que la réponse serveur, pas JavaScript. Si curl indique 200 mais que la page vous déplace dans un navigateur réel, la redirection est côté client. Confirmez-la dans Chrome DevTools :

1. Ouvrez DevTools → Network et activez Preserve log.
2. Chargez l’ancienne URL.
3. Si la première requête affiche Status 301 (ou 308), c’est une vraie redirection serveur. Si la première requête est 200 et qu’une navigation apparaît ensuite, il s’agit d’une redirection JS/meta-refresh, pas d’une vraie 301.

Apache .htaccess

# Single URL (mod_alias)
Redirect permanent "/old-page" "https://example.com/new-page"

# Pattern / regex rule (mod_rewrite) — R=301 makes it permanent, L stops processing
RewriteEngine on
RewriteRule "^old-section/(.*)$" "https://example.com/new-section/$1" [R=301,L]

# Force HTTP → HTTPS for the whole site
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

nginx

# Single URL
location = /old-page {
  return 301 https://example.com/new-page;
}

# Whole-path prefix
location /old-section/ {
  return 301 https://example.com/new-section/;
}

# Force HTTP → HTTPS
server {
  listen 80;
  server_name example.com;
  return 301 https://$host$request_uri;
}

WordPress (sans extension — functions.php, à utiliser avec parcimonie)

// Runs on every request; a server rule or the Redirection plugin scales better.
add_action( 'template_redirect', function () {
    if ( is_page() && get_query_var( 'name' ) === 'old-page' ) {
        wp_redirect( home_url( '/new-page/' ), 301 );
        exit;
    }
} );

Pour la plupart des sites WordPress, l’extension Redirection ou le gestionnaire de redirections de Yoast Premium est le choix pratique : aucun code, et Yoast Premium peut créer automatiquement une 301 lorsque vous modifiez ou supprimez une URL.

Cloudflare (edge, sans configuration d’origine)

Les Redirections uniques Cloudflare se configurent dans le tableau de bord (Rules → Redirection Rules). Pour une migration, une liste de Redirections groupées prend un CSV à deux colonnes source → cible et s’applique au compte entier sur le edge : le moyen le plus rapide de déplacer des milliers d’URL sans toucher au serveur d’origine.

Erreurs de 301 qui transforment un déplacement propre en désordre

Rediriger toutes les anciennes URL vers l’accueil

Un attrape-tout sans rapport déroute les utilisateurs et peut être traité comme un soft 404. Faites correspondre chaque ancienne URL à son remplacement le plus proche ; renvoyez 404 ou 410 lorsqu’aucun remplacement n’existe.

Ajouter la nouvelle cible à la fin d’une ancienne chaîne

Enchaîner ancienne → précédente → actuelle ajoute de la latence et des points d’échec. Mettez à jour la règle la plus ancienne pour qu’elle pointe directement vers la destination finale 200.

Laisser une 302 sur un déplacement permanent

Un code temporaire demande au moteur de préférer l’URL source. Utilisez une vraie 301 ou 308 côté serveur lorsque le déplacement est permanent, puis vérifiez le statut sur le réseau.

Supprimer la redirection dès que la nouvelle URL apparaît

Le déplacement dans l’index n’est pas une consolidation complète des signaux. Conservez les redirections aussi longtemps que possible, généralement au moins un an ; une conservation indéfinie est préférable pour les utilisateurs et les anciens liens si elle reste peu coûteuse.

Faire confiance à un wildcard large sans tester ses cibles

Une règle de dossier peut envoyer des URL sans rapport vers la mauvaise page. Commencez par une correspondance 1:1, testez les cas limites et réservez les motifs aux structures dont la transformation source-cible est réellement cohérente.

Oublier les ressources non HTML

Les images et PDF peuvent aussi avoir des liens et du trafic. Incluez les ressources déplacées dans la carte lorsqu’elles ont un remplacement pertinent ; ne redirigez pas aveuglément toutes les requêtes JS, CSS ou de polices.

Audit a redirection map avant deployment

Paste a CSV containing au moins source_url and target_url. Ajouter current source/target le statut, le type de contenu, le titre de page et la catégorie thématique lorsque disponibles.

Audit this proposed permanent redirect map.

For each row:
1. Flag homepage or other catch-all targets that are not demonstrably relevant.
2. Flag duplicate sources, missing targets, source=target loops, and likely chains where a
   target also appears as a source.
3. Compare source and target titles/categories only from the supplied data and label the
   mapping relevant, questionable, or insufficient evidence.
4. Recommend one action: keep the 1:1 mapping, map to a closer replacement, return 404/410,
   or investigate manually.

Do not invent replacement URLs or assume a target returns 200 unless the data says so.
Return: critical blockers, row-by-row findings, then the exact URLs to test after launch.

PASTE REDIRECT CSV HERE

Le cadre des trois horloges pour une 301

« Combien de temps faut-il à une 301 ? » n’a pas une seule réponse, car trois systèmes avancent à des horloges différentes. Nommez l’horloge avant d’interpréter le résultat.

Ce cadre évite deux erreurs courantes : prendre une règle serveur fonctionnelle pour la preuve que l’indexation est terminée, et prendre un résultat de recherche modifié comme permission de supprimer la règle. Validez chaque horloge avec ses propres preuves.

Outils pour déployer et vérifier les redirections permanentes

Outils gratuits de Patrick

• Redirection Checker — inspectez une URL ou un lot rapide, voyez le premier statut, chaque saut et la destination finale. Utilisez-le pour vérifier rapidement s’il s’agit d’une vraie 301 en un seul saut.
• Chaîne de redirections Mapper — diagnostiquez ce qui change à chaque saut et exportez les règles de nettoyage pour Cloudflare, Apache ou nginx. Utilisez-le lorsque la chaîne doit être réduite.
• Bulk Code d’état HTTP Checker — testez jusqu’à 500 URL, filtrez les sources non-301 et les destinations non-200, puis exportez le rapport QA de lancement.

Contrôles de recherche et d’infrastructure

• Inspection d’URL de Google Search Console — confirmer que Google a récupéré l’ancienne URL comme redirection et examiner la sélection canonique sur la destination.
• Journaux serveur/CDN — vérifier que les requêtes Googlebot reçoivent la même règle que les utilisateurs.
• Crawl complet du site — trouver les liens internes oubliés, anciennes entrées de sitemap, boucles, chaînes et ressources redirigées après une migration.

Testez vos connaissances: 301 redirections

Cinq questions rapides sur les redirections permanentes. Choisissez une réponse, puis vérifiez.

Prouver que la redirection fonctionne réellement

La 301 est en ligne. Ces contrôles distinguent « la règle est dans la configuration » de « Google consolide l’ancienne URL sur la nouvelle ». Exécutez-les dans l’ordre : le premier est instantané, le dernier prend des semaines.

Test 1 — L’ancienne URL renvoie une vraie 301 serveur

• Test à exécuter — Collez l’ancienne URL dans le Redirection Checker (or run curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/old-url).
• Résultat attendu — Le premier saut est 301 (ou 308) avec un en-tête location:, et l’URL finale renvoie 200. Un seul saut, propre.
• Interprétation d’un échec — 200 sur l’ancienne URL signifie une fausse redirection JavaScript/meta-refresh ; 302/307 signifie que le code temporaire a été déployé par erreur.
• Fenêtre de surveillance — Immédiate : le serveur répond dès que la règle est active.
• Déclencheur de retour arrière — Plus de ~5 sauts ou une boucle : retirez la règle et repointez l’ancienne URL vers la destination finale 1:1 avant de republier.

Test 2 — Google a vu la redirection et choisi la nouvelle URL

• Tester to run — Run Inspection d’URL dans la recherche Google Console on the old URL.
• Résultat attendu — Le statut indique « Page avec redirection » et l’inspection de la nouvelle URL montre qu’elle est indexée avec elle-même comme canonical choisie par Google.
• Échec — Si l’ancienne URL reste « envoyée et indexée » comme sa propre canonical, Google ne récupère peut-être pas la redirection ou un signal conflictuel pointe vers elle.
• Fenêtre — Quelques jours à quelques semaines pour un petit/moyen site, davantage pour un grand ; la visibilité peut fluctuer pendant le déplacement, c’est normal.
• Déclencheur — Ne supprimez pas la redirection pour corriger une ancienne URL persistante : Google la conserve comme autre nom et elle disparaît progressivement.

Test 3 — La migration n’a pas perdu le trafic

• Contrôle — Traitez les anciennes URL dans le Redirection Checker (jusqu’à 20 à la fois) ou lancez un crawl complet, puis surveillez les pages migrées dans le rapport Performances de GSC.
• Résultat attendu — Chaque URL mappée est un saut unique vers 200 et les clics et impressions de la destination retrouvent les niveaux antérieurs en quelques semaines.
• Échec — Une baisse durable indique généralement une carte cassée (URL incorrecte ou sans rapport, potentiellement soft 404), pas une « fuite » de PageRank : une 301 correcte ne fait pas perdre de PageRank.
• Fenêtre — Attendez 2 à 4 semaines de données GSC et comparez une période avant/après comparable, pas le bruit quotidien.
• Déclencheur — Une baisse nette et durable d’impressions alignée sur le lancement impose de réauditer la carte 1:1 avant d’accuser la redirection.

Journal des modifications