Gérer les redirections de son site WordPress en cas de déménagement

Il ne suffit pas de déménager son site WordPress correctement. Il faut aussi, c’est essentiel, rediriger les anciennes urls vers les nouvelles. Sinon, on perd tout le bénéfice de son référencement et des liens accumulés….

Rediriger les urls avec le fichier .htaccess

Il y a plusieurs façons de “rediriger” ou “réécrire” des urls. On peut le faire avec php, en incluant une instruction dans l’en tête de la page. On peut aussi le faire via un fichier de gestion du serveur Apache (Apache est un système d’exploitation pour serveurs web, et le plus courant ; il y en a d’autres, vous pouvez notamment être avec un serveur WindowsIIS, mais là on gère les réécritures autrement).

Le meilleur moyen de le faire sans prise de tête (si, si) est d’utiliser ce fichier, appelé .htaccess. En effet, quand on peut utiliser des règles concises qui s’appliquent à beaucoup de pages, cela va plus vite : au lieu d’appeler une page, et ensuite de la rediriger grâce à l’instruction php, on le fait tout de suite.

Le fichier .htaccess est un peu particulier : c’est un fichier essentiel pour le bon fonctionnement de son site, en revanche, faire des erreurs dedans peut “tout casser”.

(Une partie de cet article est technique, vous pouvez, si vous débutez, aller directement à la solution, mais si vous êtes curieux, ou que vous aimez comprendre ce que vous faites pour éviter d’appliquer des solutions à l’aveugle, je vous conseille de tout lire).

Comment fonctionne un fichier .htaccess dans un site WordPress ?

A partir du moment où vous avez utilisé une structure de permaliens, WordPress a créé à la racine du blog, un fichier .htaccess qui contient au minimum ceci :

 # BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Et c’est grâce à ces quelques lignes que WordPress sait afficher tout le contenu du blog…

décortiquons les pour les comprendre et pouvoir “ajouter” les nôtres sans panique.

Les deux lignes qui commencent par un # sont des commentaires. Elles ne sont pas prises en compte et servent simplement à se “souvenir” de ce qu’on a fait.

<IfModule mod_rewrite.c>

Ensuite WordPress vérifie que la fonction Rewrite d’Apache est installée. Si elle ne l’est pas :

• vous êtes sur votre propre serveur et vous êtes étourdi
• vous êtes sur un hébergement antique… et changez d’hébergeur

Si la fonction existe, alors on y va et on va exécuter tout ce qui se trouve avant la fin du test ( </IfModule> ).

RewriteEngine On

On fait démarrer le moteur de réécriture (on l’active au cas où ce ne serait pas le cas) et on définit la “base”

RewriteBase /

Cela permet en effet de dire à quelle url “de base” les urls réécrites vont être rattachées.

Lorsque vous installez votre blog WordPress, vous avez défini une url du blog, c’est celle qui sera la “base”.

/ veut dire que votre blog est installé à la racine de votre domaine ou de votre sous-domaine. Si vous avez installé WordPress avec le module d’OVH dans un dossier WordPress3, votre RewriteBase sera /WordPress3/ .

RewriteRule ^index.php$ - [L]

Le [L] veut dire qu’on s’arrête, et qu’on ne va pas exécuter les instructions – néanmoins tout le fichier .htaccess est lu

Cette règle veut dire “si j’ai un fichier qui s’appelle index.php avec quoique ce soit devant ou quoi que ce soit derrière, alors il n’y a pas de réécriture”.

C’est ce qui permet :

• de ne pas essayer de réécrire les urls de WordPress quand les permaliens ne sont pas activés ( genre index.php?p=22 pour affichier l’article dont l’id est 22 )
• empêcher de réécrire les urls des fichiers index.php dans les sous-répertoires, notamment wp-content/plugin qui empêche les petits curieux de voir facilement la liste de tous vos plugins.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

Ces deux règles sont extrêmement importantes : elles disent que s’il existe un fichier ou un répertoire physique, on ne cherche pas à appliquer les règles de réécriture.

Autrement dit… vous avez un article dans votre blog dont l’url serrait urldusite.com/toto-titi ET vous avez un répertoire à la racine de votre site qui s’appelle toto-titi , vous ne verrez pas le fichier, parce que Apache va afficher le répertoire (et donc sa liste de fichiers).

RewriteRule . /index.php [L]

C’est finalement la règle de réécriture qui fait tout…

Le point veut dire “tout et n’importe quoi”, donc “tout et n’importe quoi qui n’est pas un fichier index.php, ou un fichier ou un répertoire existant est réécrit par WordPress grâce au fichier index.php et à la gestion des règles de réécriture.

Les règles de réécritures dans WordPress

Elles sont gérées dans la base de données, et dans le “core” de WordPress. (Si vous n’êtes pas curieux, vous pouvez sauter directement à la conclusion, ici)

Le fichier qui va donc être appelé est index.php, lequel fait un certain nombre de contrôles, et charge “tout” WordPress, y compris l’ensemble d’instructions pour la réécriture, localisées dans /wp-includes/rewrite.php et une fonction essentielle, qui va décomposer l’url appelée pour préparer sa traduction pour le moteur de réécriture, localisée dans /wp-include/class-wp.php

Dans ce fichier, la fonction essentielle pour nous est à la ligne 120, avec parse_request() qui va traiter les variables envoyées à index.php avec la dernière règle de rewrite et tout particulièrement REQUEST_URI : l’url qui a été donnée initialement, donc l’url réécrite

Ce paramètre est traité grâce à deux fonctions, “magiques” dans /wp-includes/rewrite.php

La première se trouve à la ligne 1226, c’est generate_rewrite_rules qui donne toutes les expressions régulières possibles, triées par priorité, qui permettent de découper en morceau une url, en fonction des options du blog.

Et même les développeurs du Core de WordPress parlent de magie :

The contents of the function is a mix of black magic and regular expressions, so best just ignore the contents and move to the parameters.

Ensuite, à la ligne 1518, la fonction rewrite_rules utilise generate_rewrite_rules et, pour une url donnée, construit l’ensemble des “possibilités théoriques” qui vont ensuite être rapprochées des éléments qui existent réellement dans la base de données, pour voir ce qui peut s’appliquer à une url précise.

Autrement dit :

• WordPress enregistre en base de données ce qu’on appelle des schémas d’url, qui permettent, par exemple, de savoir que urldemonsite.com/2012/08/ doit appeler une archive par date, et pour le mois d’août 2012
• Toutes les urls d’un site appellent en réalité, via la réécriture, un fichier unique, index.php, qui va traiter l’url
  • la comparer aux schémas existants pour voir à “quel type de page” elle peut correspondre
  • une fois trouvé le(s) type(s) de page, aller chercher dans la base de données si il y a effectivement un article, une catégorie, etc qui correspond à la valeur des paramètres. Dans notre exemple, si vous n’avez pas écrit d’article en août 2012, WordPress vous renverra une page d’erreur en vous disant “j’ai compris que tu voulais les articles d’août 2012 mais je n’ai rien trouvé.
• Et les règles de réécriture sont faites par rapport au RewriteBase du .htacces, qui utilise l’url du blog définie dans les options générales.

Et mon déménagement de blog alors ?

Le problème, c’est que lorsqu’on déménage un blog, on change généralement ce “RewriteBase” :

• on change de nom de domaine
• on passe d’un sous-domaine au nom de domaine
• on passe d’un sous-répertoire au nom de domaine

Or TOUS les plugins qui gèrent des redirections dans WordPress utilisent les règles de réécritures de WordPress, c’est-à-dire qu’ils travaillent par rapport au RewriteBase

Et comme celui-ci a changé….

On va donc intervenir directement dans le .htaccess en rajoutant à la main une règle qui va réécrire TOUTES les urls de la forme ancienne_url_du_blog.url_de_contenu_wordpress à nouvelle_url_du_blog.url_de_contenu_wordpress (la même)

Et pour que cela soit pris en compte, on va l’insérer dans le .htaccess AVANT les règles WordPress dans le cas où les deux urls pointent sur le même répertoire du serveur, ou bien dans un .htaccess tout seul, si le répertoire de l’ancien nom de domaine est différent.

Premier cas : on change de nom de domaine, ou de sous-domaine

Cette règle est très simple :

RewriteEngine On
RewriteCond %{HTTP_HOST}   ^ancienne_url.com [NC]
RewriteRule ^/?(.*)         http://nouvelle_url_du_blog/$1 [L,R=301]

Ce qui veut dire

Au cas où l’url qui est demandée commence par “ancienne url du blog”, alors, tu prends tout ce qui vient après le “/”, tu remplaces l’ancienne url par la nouvelle, et tu rajoutes ce que tu avais trouvé après le / , et tu dis à Google que le contenu a déménagé définitivement (R=301] pour qu’il le prenne en compte

… la nouvelle url va ensuite être traitée par le bloc WordPress.

Attention, dans la première ligne, il faut mettre un antislash (la barre oblique arrière) avant le . de l’extension. (Ici je ne peux pas, WordPress m’en supprime l’affichage). Même chose si vous étiez en sous-domaine, vous écrirez

^www.ancienne_url.com

(oui, le www est un sous domaine).

Deuxième cas : on passe d’un sous-répertoire au domaine principal

On pourrait mettre une règle dans le .htaccess principal, mais elle serait “lue” à chaque passage. A mon avis, il est plus simple de mettre un simple .htaccess dans le répertoire physique où était WordPress, notamment parce que cela permet de ne pas se mélanger les pinceaux avec d’autres règles, ou de gérer des problèmes de priorité.

Ce .htaccess a l’avantage d’être particulièrement simple :

RewriteEngine on
RewriteRule ^(.*)$ /$1 [R=301,L]

Autrement dit… “active le rewrite, et redirige tout ce qui est ici vers la base (nom de domaine) en rajoutant ce qui vient après le nom du répertoire. (et toujours sans oublier le 301).

Concrètement, voir et éditer son fichier .htaccess

Accéder au fichier sur le serveur et l’ouvrir dans Windows

.htaccess est un nom de fichier Apache, Windows, a priori, ne le reconnait pas. C’est un fichier “caché” (son nom commence par un . ) Certains logiciels FTP, comme Filezilla, ne les montrent pas, par défaut.

Solution 1 : utiliser l’explorateur de fichier de votre hébergeur, à partir de votre panneau de gestion, qui vous permet de voir tous les fichiers, même les fichiers “cachés”.

Solution 2 : allez dans le menu serveur de Filezilla pour forcer l’affichage des fichiers cachés. Je vous ai trouvé un bon tuto ici, ne me demandez pas plus de détails, je n’utilise pas Filezilla.

Comme Windows ne le reconnait pas, il peut être un peu difficile de le modifier.

Avec un clic droit sur le fichier, vous voyez s’afficher “Ouvrir avec” et là vous pouvez choisir le bloc-notes. Mieux, vous installez Notepad++ qui est un excellent éditeur gratuit, et, toujours avec le clic droit, choisissez “Editer avec Notepad++”.

Le modifier

La seule consigne est de faire particulièrement attention… par exemple, mettre un double espace au lieu d’un simple espace peut dans certains cas poser des problèmes.

Si vous n’arrivez pas à l’enregistrer parce que windows vous dit que ce n’est pas un nom de fichier correct, faites lui plaisir, appelez-le htaccess.txt

Remplacer l’ancien .htaccess

La prudence est mère de sûreté : on ne va pas écraser tout de suite le fichier existant sur le serveur, avant d’être certain que tout se passe bien.

• Etape 1 : dans votre logiciel FTP, faire un clic droit sur le fichier .htaccess et le renommer par exemple en _.htaccess (un seul caractère suffit)
• Etape 2 : charger via FTP votre nouveau .htaccess. Si vous avez dû l’appeler htaccess.txt, clic droit, renommer en .htaccess
• Etape 3 : aller sur votre site. Si il y a une erreur genre 500, 503, 403, 401 … remettez en place l’ancien .htaccess tout de suite. Sinon passez à l’étape 4 :
• Etape 4 : testez que les règles de réécritures fonctionnent. Si oui, vous pouvez supprimer l’ancien .htaccess , sinon vous pouvez m’appeler au secours !

 

(Les panneaux de redirections sont une photo sous licence CC BY NC SA de Sharon Drummond )