Redirection 301 : la règle est triviale, la destination ne l'est pas

Une redirection 301Redirection permanente transférant le jus SEO de l'ancienne URL vers la nouvelle. se pose en une ligne. Une directive dans le .htaccess, un bloc dans nginx, deux clics dans un plugin. Trente secondes de travail. Ce qui fait perdre du trafic pendant une refonteModification majeure du design ou de la structure d'un site. Risque SEO si mal gérée., c'est la colonne de droite du fichier : la destination.

Le code 301 signifie « Moved Permanently ». Le serveur répond à la place de la page demandée, annonce que le document a déménagé pour de bon et donne la nouvelle adresse dans l'en-tête Location. Le navigateur suit sans que l'utilisateur voie quoi que ce soit, et met l'ancienne URLUniform Resource Locator. Adresse unique d'une page web. Une URL optimisée est courte, descriptive et contient le mot-clé. en cache. Les moteurs suivent aussi, reportent les signaux accumulés par l'ancienne page sur la nouvelle, puis sortent l'ancienne adresse de l'index au fil des recrawls. La mécanique tient en un paragraphe et n'a pas bougé depuis quinze ans.

La plupart des articles s'arrêtent là : la définition, le tableau 301 vs 302Redirection temporaire ne transférant pas le jus SEO. À utiliser avec précaution., et un « pensez à faire vos redirections » en guise de conclusion. Sur les migrations qu'on récupère chez Slashr, la partie technique est presque toujours propre, les 301 renvoient bien un 301. Le dernier dossier de ce genre passé sur mon bureau avait perdu 40 % de trafic organiqueVisites provenant des résultats de recherche naturels (non payants) des moteurs de recherche. avec un fichier de règles impeccable, mais des milliers d'URL balancées vers la home ou vers une catégorie qui ne répond pas à la requête d'origine. Pour Google, une redirection permanente vers une page hors sujet, c'est un soft 404Code HTTP indiquant qu'une page n'existe pas. Trop d'erreurs 404 nuisent au crawl budget. avec un supplément de latence.

Poser une redirection 301 selon votre serveur

Apache, nginx, PHP, CMS : quatre syntaxes pour un seul comportement attendu, un code HTTP 301 et un Location propre.

Avec htaccess sur Apache

Le module mod_rewrite gère tout ce qui dépasse la correspondance simple. Pour une URL vers une autre, Redirect suffit et coûte moins cher en CPU.

# URL à URL, le plus lisible
Redirect 301 /ancienne-page/ httpsProtocole sécurisé de transfert de données. Facteur de ranking depuis 2014.://exemple.fr/nouvelle-page/

# Avec RewriteRule quand tu as besoin de conditions
RewriteEngine On
RewriteRule ^categorie/produit-x/?$ /nouvelle-categorie/produit-x/ [R=301,L]

# Domaine entier, en conservant le chemin
RewriteCond %{HTTP_HOST} ^ancien-domaine\.fr$ [NC]
RewriteRule ^(.*)$ https://nouveau-domaine.fr/$1 [R=301,L]

Le [L] empêche la règle suivante de repasser dessus. C'est ce qui vous sauve des boucles quand le fichier grossit.

Avec nginx

Pas de .htaccess ici, tout se passe dans le bloc server et il faut recharger la conf.

location = /ancienne-page/ {
    return 301 https://exemple.fr/nouvelle-page/;
}

# Bascule de domaine complète
server {
    server_name ancien-domaine.fr;
    return 301 https://nouveau-domaine.fr$request_uri;
}

return 301 est plus rapide que rewrite ... permanent et ne rentre pas dans le cycle de réécriture interne.

En PHP ou dans la logique applicative

Utile quand la correspondance dépend d'une donnée en base, par exemple un ancien identifiant produit à retrouver.

header('HTTP/1.1 301 Moved Permanently');
header('Location: https://exemple.fr/nouvelle-page/', true, 301);
exit;

Gardez le exit. Sans lui, le script continue, produit du HTML après l'en-tête, et vous récupérez des comportements erratiques selon le buffer de sortie.

Via un CMS

WordPress, Shopify, PrestaShop et consorts stockent les redirections en base, avec une interface. Pratique jusqu'à quelques centaines de règles. Au-delà, chaque requête déclenche une lecture en base avant d'atteindre la redirection, et le temps de réponse grimpe. Sur un catalogue e-commerce qui migre 40 000 URL, les règles massives se posent côté serveur ou côté CDNContent Delivery Network. Réseau de serveurs distribuant le contenu depuis le serveur le plus proche de l'utilisateur., pas dans un plugin.

Ce que « 301 Moved Permanently » dit vraiment aux navigateurs

Un navigateur qui reçoit un 301 mémorise l'association. C'est le détail que la plupart des gens ignorent, et il explique la moitié des « ma redirection ne marche pas » : elle marche, mais votre Chrome a gardé l'ancienne en cache et il ne redemandera pas au serveur avant un bon moment. Testez en navigation privée ou au curl : l'onglet où vous bricolez depuis deux heures vous ment.

Côté moteurs, le 301 est un signal de consolidation. L'ancienne URL sort de l'index au rythme du recrawl, quelques jours pour une page souvent visitée, plusieurs mois pour une URL de fond de catalogue, et les signaux se reportent sur la destination. Un test publié par SEOMix sur la perte de popularité liée aux redirections montre que l'essentiel du jus passe, sans que le transfert soit absolu. C'est une opération à faible perte, pas un copier-coller.

Et non, l'« erreur 301 » n'existe pas. La famille 3xx regroupe des redirections. Les erreurs commencent à 4xx.

301 ou 302 : le tableau qui tranche en dix secondes

Le choix se fait sur une question unique : est-ce que l'ancienne URL a vocation à revenir ?

Les deux erreurs n'ont pas le même prix. Un 302 posé sur un déplacement définitif laisse l'ancienne URL en vie dans l'index pendant des mois, et Google finit parfois par le réinterpréter en permanent : vous perdez du temps, guère plus. Un 301 posé sur une situation temporaire désindexe une URL que vous vouliez garder, et ça se répare mal.

Le plan de redirection, c'est là que se joue votre migration

Les refontes qui plantent ont rarement zéro redirection. Elles ont un mapping fait la veille de la bascule, entre deux réunions. Un cas documenté par l'agence Wegrowth décrit une migration qui n'avait couvert que la moitié des URL, suivie d'une chute de trafic de 50 %. Les deux chiffres se répondent, il n'y a pas de mystère algorithmique là-dedans.

Recenser les URL, et pas seulement celles que vous connaissez

Un crawlProcessus par lequel les robots des moteurs de recherche parcourent et analysent les pages web. de la prod ne suffit pas. Il vous donne les URL liées depuis le site, donc pas celles qui rankent encore alors qu'elles sont orphelines depuis deux ans. Il vous faut cinq sources, fusionnées dans un seul fichier :

• Le crawl complet de la production avant bascule, en gardant les 200 indexables et en notant les canoniques.
• L'export Search ConsoleOutil gratuit Google pour surveiller et optimiser la présence d'un site dans les résultats de recherche. Performance sur 16 mois en dimension Pages, seuil à 1 impressionNombre de fois qu'une page apparaît dans les résultats de recherche, qu'elle soit cliquée ou non., pas à 1 clic.
• L'export du rapport IndexationProcessus par lequel Google ajoute une page à sa base de données pour qu'elle puisse apparaître dans les résultats., pour récupérer les URL connues de Google que votre crawl n'a pas vues.
• Les logs serveurFichiers enregistrant toutes les requêtes reçues par un serveur, permettant d'analyser le comportement des bots. sur 3 à 6 mois, filtrés sur les hits GooglebotRobot d'exploration de Google qui parcourt le web pour découvrir et indexer les pages.. C'est la seule source qui révèle les URL crawlées et absentes partout ailleurs.
• L'export des pages référentes de vos backlinksLien provenant d'un site externe pointant vers votre site. Facteur de ranking majeur. : une URL sans trafic mais avec trois liens dofollowLien standard transmettant le jus SEO (par défaut, tous les liens sont dofollow). depuis un média mérite sa ligne.

Vous dédoublonnez ensuite en normalisant : slash final, majuscules, paramètres de tracking supprimés, versions http/https/www ramenées à la forme canonique. Ce nettoyage fait fondre le fichier de 30 % et vous évite des règles contradictoires.

L'arbre de décision, URL par URL

Chaque ligne du fichier reçoit une décision prise à la main, pas un remplissage automatique.

Un contenu équivalent existe sur la nouvelle version ? Redirection permanente vers lui. C'est le cas facile, et c'est la majorité du volume.

Quand le contenu a été éclaté en plusieurs pages, visez celle qui répond à l'intention de la requête d'origine plutôt que la catégorie parente. Les requêtesTerme ou expression que les utilisateurs saisissent dans un moteur de recherche. Base de toute stratégie SEO. de l'export GSC pour cette URL vous disent quelle destination choisir bien mieux que votre arborescence.

Deux pages fusionnées : la moins performante part vers celle que vous gardez. C'est le cas où la 301 rapporte vraiment, puisque vous consolidez deux historiques de liens en un.

Contenu supprimé sans équivalent, la question devient : est-ce que la catégorie parente répond à l'intention de la requête qui amenait du trafic sur cette page ? Oui, vous redirigez vers elle. Non, vous renvoyez un 410. Un 410 assumé sort proprement de l'index, là où une redirection vers une page hors sujet traîne des mois en soft 404.

Restent les URL sans impression sur 16 mois, sans lien externe et sans hit Googlebot dans les logs. Celles-là, vous ne redirigez rien. Les facettes, les tris, les paramètres de session meurent en 404 et c'est très bien. Rediriger 200 000 URL de filtresSystème de filtres (taille, couleur, prix) générant de nombreuses URLs. Nécessite une gestion SEO., c'est fabriquer une usine à chaînes de redirections pour zéro gain.

Le fichier final tient en cinq colonnes : url_source, url_cible, code, motif, clics_16m. La dernière sert au tri de recette. Vous vérifiez à la main les 200 premières lignes, celles qui pèsent réellement dans votre trafic, et le reste passe en contrôle par échantillon.

Les regex, à manier avec un garde-fou

Une règle en expression régulière couvre mille URL d'un coup et introduit mille erreurs d'un coup. La contre-mesure tient en deux gestes : vous ancrez systématiquement vos motifs avec ^ et $, et vous passez le fichier de règles sur votre liste complète d'URL en prAlgorithme historique de Google évaluant l'importance d'une page selon ses backlinks. Toujours utilisé en interne.éproduction pour vérifier qu'aucune URL de destination ne matche elle-même une règle. Les boucles naissent là, à chaque fois.

Tester vos redirections avant de dormir tranquille

Une redirection non testée est une hypothèse. La ligne de commande donne la réponse en une seconde.

curl -sI https://exemple.fr/ancienne-page/ | grep -E 'HTTP/|[Ll]ocation'

Vous attendez HTTP/2 301 et un location qui pointe vers l'URL finale en HTTPS, avec le bon slash final. Un 302 qui apparaît, c'est une règle mal écrite ou un plugin qui surcharge la conf serveur.

Pour détecter les chaînes, le paramètre qui compte est num_redirects :

curl -sLo /dev/null -w '%{num_redirects} sauts -> %{url_effective} (%{http_code})\n' \
  https://exemple.fr/ancienne-page/

Au-delà d'un saut, vous avez une chaîne. Deux sauts restent tolérables si le premier est structurel (http vers https), trois relèvent de la négligence. Googlebot suit au maximum dix redirections : au-delà, il abandonne et la Search Console signale une erreur de redirection. Réécrivez le mapping pour que chaque ancienne URL pointe directement vers la destination finale, y compris les redirections héritées d'une migration précédente. Oui, ça veut dire relire l'ancien fichier de règles avant d'ajouter le nouveau. Personne n'aime cette étape, elle rattrape pourtant la moitié des chaînes.

En volume, vous bouclez sur votre fichier de recette :

while read url; do
  printf '%s -> ' "$url"
  curl -sLo /dev/null -w '%{num_redirects} %{url_effective} %{http_code}\n' "$url"
done < urls_a_tester.txt > resultat.txt

Puis vous triez resultat.txt sur les lignes dont le code final n'est pas 200 et sur celles à plus d'un saut. Ces deux filtres attrapent la quasi-totalité des défauts avant qu'ils ne coûtent quelque chose.

Deux contrôles supplémentaires que presque personne ne fait. Le premier : rejouer les tests avec un user-agent Googlebot, parce que certaines configurations (géolocalisation, mur de consentement, cache CDN) se comportent différemment selon le client. Le second : tester les ressources, pas seulement les pages HTML. Les PDF, les images qui ramassent des liens, les flux RSS et les vieux sitemaps ont des URL qui vivent leur vie dans l'index et dans les backlinks.

Après la mise en production, la surveillance dure au moins six semaines. Trois choses à suivre. Les logs serveur d'abord, en regardant la part de hits Googlebot qui tombent sur du 301 : elle doit décroître semaine après semaine, sinon c'est que vos liens internesEnsemble des liens entre les pages d'un même site. Distribue le jus SEO et guide les utilisateurs. pointent encore sur les anciennes adresses. Les 404 dans ces mêmes logs ensuite, à réinjecter chaque semaine dans le fichier de mapping, parce que c'est là que réapparaissent les URL oubliées par votre recensement. Le rapport d'indexation de la Search Console enfin, où le motif « Page avec redirection » doit monter puis se stabiliser pendant que « Introuvable (404) » reste calme.

Rediriger coûte quelque chose, en performance et en crawl

Chaque redirection ajoute un aller-retour réseau avant le premier octet utile. Sur mobile en 4G dégradée, un saut supplémentaire se paye en centaines de millisecondes, et le LCPLargest Contentful Paint. Mesure le temps de chargement du plus grand élément visible. Idéalement < 2,5 secondes. le voit passer. Multiplié par un catalogue entier crawlé chaque jour, le coût se déplace sur le budget de crawlNombre de pages que Googlebot peut et veut crawler sur un site dans un temps donné. : chaque requête dépensée sur une URL morte est une requête qui n'a pas servi à découvrir un nouveau produit. Servez vos redirections côté serveur ou côté CDN, et laissez de côté le script applicatif qui charge un framework complet pour produire un en-tête de 40 octets.

Questions fréquentes