Re­di­rec­tion 301

Le terme 301 Redirect fait référence au transfert permanent d’une adresse Web vers une autre. Nous ex­pli­quons le contexte technique et montrons comment con­fi­gu­rer Redirect 301 avec un fichier .htacess sur le serveur.

À quoi servent les 301 Redirects ?

301 Redirect est la méthode de transfert la plus connue. Ici, le chiffre 301 fait référence au code de statut HTTP dont il est question. Bien que le code de statut 404 indique que la ressource demandée est in­trou­vable, les codes 300 font référence à des re­di­rec­tions, ou « redirects » en anglais. En général, les re­di­rec­tions 301 sont utilisées pour éviter les erreurs 404.

Faisons le tour des prin­ci­paux codes de statut http associés aux re­di­rec­tions :

### Redirection 301 pour migrer du contenu

Les contenus Web, que l’on désigne également comme des res­sources, sont localisés sous des adresses Web. Parfois, les contenus sont migrés, c’est-à-dire que le contenu reste le même et que seule l’adresse change. Ceci peut être notamment le cas lors du passage de HTTP à HTTPS, du dé­pla­ce­ment d’un site vers un nouveau domaine ou de l’ajus­te­ment de la structure de liens pour l’op­ti­mi­sa­tion du ré­fé­ren­ce­ment auprès d’un moteur de recherche. Dans tous les cas, on cherche à éviter que les uti­li­sa­teurs accédant aux adresses exis­tantes se re­trou­vent dans l’impasse.

Si le serveur ne peut pas associer de ressource à une adresse, il renvoie l’erreur HTTP 404 « Not Found ». Cela est ennuyeux pour les uti­li­sa­teurs car ils ne peuvent pas accéder à la ressource souhaitée. Si l’adresse est ac­ces­sible par uncrawler Web au lieu d’un humain, les erreurs 404 en­traî­ne­ront la dé­sin­dexa­tion de la ressource associée. Les ex­ploi­tants de site Web tentent d’éviter autant que possible ces deux scénarios.

### Redirection 301 pour l’optimisation du référencement auprès des moteurs de recherche

Mis à part les chan­ge­ments d’adresse des contenus Web, les 301 Redirects sont es­sen­tiels pour l’op­ti­mi­sa­tion du ré­fé­ren­ce­ment auprès des moteurs de recherche (SEO) et pour le marketing en ligne. Par exemple, les re­di­rec­tions 301 sont utilisées pour générer les URL adaptées aux moteurs de recherche et les « URL ca­no­niques ». Les ré­duc­teurs d’URL eux aussi reposent en interne sur les re­di­rec­tions de type 301.

Pourquoi les 301 Redirects sont-ils si im­por­tants pour le SEO ? Con­trai­re­ment aux re­di­rec­tions 302, 303 et 307 ap­pa­ren­tées, seule la re­di­rec­tion 301 transfère le « Link Juice » ou « jus SEO » de l’adresse d’origine vers la nouvelle adresse. Si un moteur de recherche a indexé un contenu et l’a analysé comme positif, l’adresse peut être réi­ni­tia­li­sée via une re­di­rec­tion 301 sans perdre sa note. Ainsi, les Redirects 301 per­met­tent de mettre sur pied des stra­té­gies de SEO complexes telles qu’une stratégie mul­ti­do­maine.

Comment fonc­tion­nent les 301 Redirects ?

Une re­di­rec­tion 301 in­ter­vient lors de l’échange entre les serveurs Web et les clients. Le serveur informe le client que la ressource demandée n’est plus dis­po­nible à l’adresse Web in­ter­ro­gée (URL) et transmet l’adresse qui est main­te­nant valide. Le client peut être à la fois le na­vi­ga­teur manipulé par un uti­li­sa­teur humain et un robot de moteur de recherche.

1. Le client tente d’accéder à la ressource sous l’URL.
2. Le serveur répond en renvoyant le code de statut 301 « Moved Per­ma­nently » et transmet la nouvelle URL pour accéder à la ressource dans l’en-tête HTTP Location.
3. Le client met en cache la nouvelle URL ; les accès futurs à l’ancienne URL ac­cè­de­ront im­mé­dia­te­ment à la nouvelle URL.
4. Le client tente d’appeler la ressource sous la nouvelle URL.

L’outil de réseau cURL populaire permet de vi­sua­li­ser le dé­rou­le­ment de ce processus. Nous allons à la page d’accueil de IONOS à http://ionos.fr et utilisons la méthode HTTP HEAD pour sortir l’en-tête de réponse :

curl --head http://ionos.fr

Le serveur IONOS répond avec le code de statut HTTP « 301 Moved Per­ma­nently », et l’en-tête Location contient la nouvelle adresse https://www.ionos.fr/. Comme nous l’observons, la page d’accueil se trouve sous le sous-domaine WWW et utilise le protocole HTTPS. Ensuite, nous demandons à cURL de suivre en plus la re­di­rec­tion 301 avec l’option Location :

curl --head --location http://ionos.fr

cURL sort main­te­nant les en-têtes de deux con­nexions. Lors du deuxième appel, le serveur répond avec le code de statut « 200 OK » ; la ressource a été trouvée, le contenu est transmis dans le corps de la réponse. Le même processus s’exécute en arrière-plan dans votre na­vi­ga­teur lorsque vous entrez l’adresse.

### Définir le redirect 301 avec le fichier .htaccess

Nous avons examiné le rôle que joue la re­di­rec­tion 301 dans l’échange entre le serveur et le client. Mais comment puis-je constater l’existence de 301 Redirects sur le serveur? Plusieurs approches existent pour cela : l’une des plus cou­ram­ment utilisée consiste à définir des di­rec­tives de re­di­rec­tion dans le fichier .htaccess du serveur Web Apache. Pour que cela fonc­tionne, les modules Apache cor­res­pon­dants doivent être actifs :

### Redirects simples pour la redirection 301 dans le .htaccess

Observons tout d’abord comment définir des Redirects simples de type 301 dans le fichier .htaccess. Pour ce faire, nous utilisons les di­rec­tives Redirect du module mod_alias. Elles sont utiles dès lors qu’il s’agit de rediriger une URL sur le serveur vers une autre URL. La structure est d’une grande sim­pli­cité :

Redirect 301 "/source_path" "target_URL"

Nous re­di­ri­geons une URL sur le serveur vers une autre URL interne dans un premier temps. La barre oblique au début désigne le début du chemin d’URL, à savoir la partie après le domaine :

Redirect 301 "/old.html" "/new.html"

Si nous sou­hai­tons effectuer le renvoi vers une URL externe, nous la notons au titre de des­ti­na­tion :

Redirect 301 "/old.html" "http://example.com/new.html"

Vous pouvez également définir des re­di­rec­tions 301 de ré­per­toires entiers dans le fichier .htaccess à l’aide de la directive Redirect. Nous re­di­ri­geons toutes les URL com­men­çant par le composant de chemin « fr » vers un sous-domaine :

Redirect 301 "/fr/" "http://fr.example.com/"

En adoptant le même schéma, toutes les URL d’un domaine peuvent être re­di­ri­gées vers un autre domaine :

Redirect 301 "/" "http://other.example.com/"

Si vous voulez rediriger de nom­breuses adresses in­di­vi­duelles calquées sur un certain schéma, la notation des re­di­rec­tions au cas par cas va prendre ra­pi­de­ment des pro­por­tions fas­ti­dieuses. Vous pouvez recourir dans ce cas à la directive Re­di­rect­Match. Elle utilise une ex­pres­sion régulière pour détecter des motifs et en extraire des éléments :

RedirectMatch 301 regex URL

Voici un exemple d’entrée Re­di­rect­Match qui extrait la catégorie et le numéro d’iden­ti­fi­ca­tion d’un article issu des pa­ra­mètres GET, et les réécrit dans le chemin :

RedirectMatch 301 "/article.php?cat=(.*)&id=(.*)" "/articles/$1/$2/"

Prenons comme exemple le domaine example.com. L’URL http://example.com/article.php?cat=web&id=42 serait alors redirigée vers http://example.com/articles//web/42/.

### Redirects complexes pour la redirection 301 dans le fichier .htaccess

Pour créer des re­di­rec­tions 301 pour des cas d’uti­li­sa­tion complexes, on se tourne vers des di­rec­tives de réé­cri­ture du module de re­di­rec­tion Apache mod_rewrite. Cela vous permet de définir et d’in­ter­ro­ger des con­di­tions de re­di­rec­tion, de définir et de lire des variables d’en­vi­ron­ne­ment et de définir des règles de re­di­rec­tion avec des ex­pres­sions ré­gu­lières.

Avec mod_rewrite, il est possible d’enchaîner des règles de re­di­rec­tion ; le module fournit quasiment un mini-langage de pro­gram­ma­tion pour reformer les URL et dé­clen­cher des re­di­rec­tions. Faites preuve de prudence ici, car une erreur pourrait se traduire par des boucles sans fin.

Les di­rec­tives Rewrite com­men­cent par la ligne « Re­wri­teEn­gine on ». Cette opération est suivie de con­di­tions de re­di­rec­tion Re­wri­te­Cond fa­cul­ta­tives, com­plé­tées par une ou plusieurs règles de re­di­rec­tion Re­wri­te­Rule. Le com­por­te­ment des con­di­tions et des règles de re­di­rec­tion peut être influencé par des options nommées « flags » ou « drapeaux ». Pour dé­clen­cher une re­di­rec­tion 301, l’une des règles doit contenir les drapeaux L,R=301 :

RewriteEngine on
RewriteCond TestString CondPattern [flags]
RewriteRule URL_path Substitution [L,R=301]

L’accès à de nom­breuses variables d’en-tête et de serveur de la forme %{HTTP_HOST}, %{REQUEST_URI}, etc. est garanti au sein des règles et con­di­tions de re­di­rec­tion. Elles peuvent être reliées par des opé­ra­teurs et traitées à l’aide de fonctions. Il est ainsi permis de réaliser pra­ti­que­ment n’importe quelle re­di­rec­tion souhaitée, même si la syntaxe n’est pas d’un abord intuitif.

Examinons un exemple de 301 Redirect réalisé à l’aide de mod_rewrite. Nous sou­hai­tons forcer des URL ca­no­niques pour éviter le contenu dupliqué. Cela signifie que toutes les URL doivent commencer par HTTPS et WWW, quelle que soit la manière dont les visiteurs accèdent au contenu.

Nous dé­fi­nis­sons deux con­di­tions de re­di­rec­tion, que nous relions les unes aux autres par le drapeau OR. La première condition teste si HTTPS est désactivé, la deuxième condition vérifie si le WWW de tête ne précède pas le domaine. Nous utilisons le drapeau NC pour dé­sac­ti­ver la dis­tinc­tion entre ma­jus­cules et mi­nus­cules. Si l’une des deux con­di­tions est vérifiée, nous re­di­ri­geons l’URL vers sa version HTTPS-WWW par 301 Redirect. Nous utilisons l’ex­pres­sion régulière (.*), qui récupère n’importe quelle URL, et l’accole derrière le domaine en utilisant $1 :

RewriteEngine on
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteRule (.*) https://www.example.com/$1 [L,R=301]

Quels sont les problèmes et les dangers liés à l’uti­li­sa­tion de 301 Redirects ?

Les re­di­rec­tions de type 301 Redirect sont des outils standard dans le domaine du dé­ve­lop­pe­ment Web et du ré­fé­ren­ce­ment. Cependant, il convient de procéder à la con­fi­gu­ra­tion avec prudence, car d’im­por­tants problèmes peuvent se produire si les re­di­rec­tions sont utilisées de manière in­cor­recte. Le serveur peut par exemple planter ou le site peut dé­grin­go­ler dans le clas­se­ment des moteurs de recherche.

### Corruption du fichier .htaccess lors d’une modification manuelle

Le fichier .htaccess configure le serveur Web Apache au niveau du ré­per­toire. Même les mo­di­fi­ca­tions in­cor­rectes les plus infimes apportées au fichier .htaccess peuvent ir­ré­mé­dia­ble­ment conduire à un site Web inac­ces­sible. La fameuse erreur serveur 500 ou page blanche WordPress risquent alors de se produire.

Il est pré­fé­rable de créer une copie du fichier .htaccess avant de le modifier. Ceci est très facile en partant de la ligne de commande. Nous basculons dans le ré­per­toire Web public du site et utilisons la commande cp :

cp -a .htaccess _htaccess

Si des erreurs se pro­dui­sent à la suite de la mo­di­fi­ca­tion du fichier .htaccess, nous res­tau­rons la version originale:

cp -a _htaccess .htaccess

### Chaînes et boucles de redirection

Les re­di­rec­tions sont utiles, mais se tra­dui­sent par un cycle requête-réponse complet et « coûteux ». Les uti­li­sa­teurs doivent patienter lorsque les re­di­rec­tions sont en­chaî­nées, ce qui se traduit par un taux de rebond accru. De plus, les moteurs de recherche évaluent les pages qui se re­di­ri­gent plusieurs fois de suite de manière négative. Un maximum de trois re­di­rec­tions suc­ces­sives est gé­né­ra­le­ment admis.

Les boucles de re­di­rec­tion, dans les­quelles deux adresses se re­di­ri­gent mu­tuel­le­ment sans fin, sont fatales. Ceci se traduit par une erreur de na­vi­ga­teur ERR_TOO_MANY_REDIRECTS pour l’uti­li­sa­teur. La ressource souhaitée est donc inac­ces­sible. D’une manière générale, il est re­com­mandé de tester les re­di­rec­tions nou­vel­le­ment con­fi­gu­rées avec cURL pour s’assurer que le résultat souhaité est atteint.

### Empoisonnement accidentel du cache lors de l’utilisation de la redirection 301

Une mauvaise uti­li­sa­tion de 301 Redirect peut devenir un vrai casse-tête par la suite. Con­trai­re­ment aux re­di­rec­tions tem­po­raires des types 302, 303 et 307, la re­di­rec­tion 301 indique au client de mettre la nouvelle URL en cache. Si l’on souhaite revenir ul­té­rieu­re­ment à l’URL d’origine, les clients y resteront in­sen­sibles et con­ti­nue­ront in­las­sa­ble­ment à se connecter à la nouvelle URL. L’uti­li­sa­tion de re­di­rec­tions tem­po­raires ou la dé­fi­ni­tion de l’en-tête Cache-Control par une valeur ap­pro­priée permet de con­tre­car­rer cet effet.

Nous avons réglé l’en-tête Cache-Control sur une heure lors de la dé­fi­ni­tion de la règle Redirect 301 dans .htaccess. Cela permet de s’assurer que les mo­di­fi­ca­tions ul­té­rieures apportées à la des­ti­na­tion de re­di­rec­tion par­vien­nent à tous les clients :

ExpiresActive on
ExpiresDefault "access plus 1 hour"
Redirect 301 / https://www.example.com/

En cas d’uti­li­sa­tion de re­di­rec­tions complexes avec des di­rec­tives de réé­cri­ture, nous avons recours à une astuce pour définir l’en-tête Cache-Control. Nous dé­fi­nis­sons une variable d’en­vi­ron­ne­ment li­mit­cache dans le cadre de la règle de re­di­rec­tion 301. Nous dé­fi­nis­sons ensuite l’en-tête, en lisant la variable d’en­vi­ron­ne­ment comme condition. Ceci permet de s’assurer que l’en-tête correct est défini lors de la re­di­rec­tion :

RewriteRule ^.* http://www.example.com/ [L,R=301,E=limitcache:1]
Header always set Cache-Control "max-age=3600" env=limitcache