Pour des questions SEO, il est intéressant de maîtriser certaines techniques de réécriture d'adresses sous Apache avec les fichiers .htaccess. Si l'adresse ne change pas dans la barre d'adresse du navigateur, on parle de redirection interne. Si l'adresse change, on parle de redirection externe, souvent des redirections retournant le code HTTP 301 indiquant que la ressource est déménagée à la nouvelle adresse de façon permanente. Les redirections internes sont les plus complexes à comprendre car intangibles, elles permettent de créer une structure complètement virtuelle pour un site Web qui lui serait généré à partir du même fichier PHP. WordPress en est un bon exemple!

Il faut garder en tête que le mod_rewrite est appelé chaque fois qu'une demande HTTP est faite sur un fichier. Il faut donc être concis et s'assurer des limites de notre fichier .htaccess pour éviter des comportements incompréhensibles. Le plus complexe dans le URL Rewriting c'est les expressions régulières. Plusieurs règles de base peuvent être mises en place sans trop de connaissance en expressions régulières mais la science des URL Rewriting prend toute son ampleur lorsqu'on y ajoute un peu de « pattern matching »!

Le texte ci-dessous représente principalement une traduction des passages les plus intéressants des 2 sources citées à la fin de l'article.

Contenu de base du fichier .htaccess

Un fichier .htaccess de réécriture d'adresse de base devrait contenir ces lignes. La ligne Options +FollowSymlinks n'est que très rarement utile car elle permet de suivre les liens symboliques à l'intérieur des bornes définies par le <Directory> de votre serveur Apache. En contrepartie, chez certains hébergeurs, la présence de cette ligne donnera une erreur interne de serveur (500). La solution la plus simple est de laisser la ligne si le serveur ne retourne pas d'erreur, s'assurant que d'éventuels besoins seront comblés automatiquement ou de commenter la ligne si le serveur retourne une erreur. Pour faire un commentaire dans un fichier .htaccess, ajoutez simplement un # en début de ligne.

Dans le cas où votre projet est dans un sous-répertoire, il faut ajuster le RewriteBase en conséquence pour que les règles commencent à l'intérieur de ce répertoire.

Flags

Mais qu'est-ce que c'est ces lettres entre crochets []? C'est des « flags » indiquant certaines instructions supplémentaires au moteur de réécriture d'adresse d'Apache. En voici une liste des principaux « flags » :

    R=code : Indique une redirection. Le code est le code HTTP que vous désirez retourner. Souvent le code 301 est utilisé pour indiquer que l'adresse demandée n'existe plus et a été remplacée par la nouvelle adresse. Si aucun code n'est spécifié, le code 302 sera retourné, celui-ci indiquant qu'il s'agit d'une redirection temporaire.
    L : Indique que si cette règle est respectée, ne pas tenter d'autres règles, arrêter immédiatement avec celle-ci. Très utile pour permettre de mettre les règles les plus précises en début de fichier allant vers les moins précises et arrêter le traitement aussitôt qu'une règle correspond à l'adresse demandée.
    NC : Fait en sorte que la règle ne doive pas nécessairement respecter la case (majuscule, minuscule)
    QSA : Permet de conserver les paramètres d'une adresse et d'en ajouter d'autres. Par exemple, avec la règle suivante RewriteRule fr/nouvelles.html$ nouvelle.php?lang=fr , si l'URL demandé est fr/nouvelles.html?page=2 , nouvelle.php n'aura pas accès à la valeur du paramètre page, seulement la valeur de lang. Si au contraire on ajoute [QSA], les paramètres lang et page seront disponibles dans le fichier PHP.
    S=num : Permet de sauter les « num » prochaines règles si la règle en cours est respectée. Permet de faire une sorte de IF ELSE bouetteux... la dernière règle du premier S étant S=X, X étant le nombre de régles à sauter dans la portion « else ».
        (if)
        RewriteRule ... [S=2]
           RewriteRule ...
           RewriteRule ... [S=1]
        (else)
           RewriteRule ...
        (endif)
        Lecture normale des règles suivantes...   
    NE : Permet d'éviter d'escaper des caractères spéciaux lors d'une redirection ce qui arrive automatiquement sinon. Ainsi, RewriteRule /test/(.*) /page?q=repertoire%3d$1 [R,NE] redirigera ‘/test/bobo' sur l'URL suivante ‘/page?q=repertoire=bobo'.
    N : Permet de relancer le traitement des règles de réécriture, mais pas avec l'URL de départ mais plutôt avec l'URL transformé par les premiers passages... À éviter, risque de boucles infinies.
    F : Permet de forcer le retour d'une erreur HTTP 403 : Forbidden sur une page ou un ensemble de page respectant une RewriteConds
    B : Apache traduit les caractères « url escapés » en caractère standard. La règle RewriteRule ^(.*)$ index.php?show=$1 réécrira /C++ vers index.php?show=/C++ mais va également réécrire /C%2b%2b vers index.php?show=/C++ car les + auront été « dé-escapés »! L'utilisation du flags B vous assurera que /C%2b%2b deviendra index.php?show=/C%2b%2b et /C++ restera index.php?show=/C++.
    C : Permet de lier une règle avec la règle suivante et ainsi de suite si le C est présent sur les règles suivantes. Si la règle est respectée, le traitement continue de façon normal et le flag est ignoré. Si la règle n'est pas respectée, toutes les règles liées à celle-ci ne seront pas considérées.
    CO=NAME:VAL:DOMAIN[:LIFETIME[:PATH[:SECURE[:HTTPONLY]]]]' : Permet de créer un cookie! Il s'agit d'une fonctionnalité intéressante mais rarement utilisée... Le prochain développeur à travailler sur votre projet risque de chercher l'emplacement de la création du cookie longtemps dans le code! NAME est le nom du cookie, VAL sa valeur, DOMAIN le domaine « .test.com » sur lequel le cookie doit être actif, LIFETIME la durée de vie en minute, PATH le répertoire où le cookie est effectif, SECURE « true » ou « 1″ fait en sorte que le cookie est effectif seulement sous https, HTTPONLY « true » ou « 1″ fait en sorte que le cookie n'est pas manipulable par du javascript.
    NON COUVERT ICI : DPI, E=VAR:VAL, G, H=Content Handler, NS, P, PT, T

Forcer la présence des www

Bien que les www. ne sont pas du tout nécessaires pour qu'une page Web fonctionne, les internautes néophytes sont tout de même habitués à leur présence. Le plus important à retenir est que www. agit de façon similaire à un sous-domaine (site.domain.com). D'avoir du contenu accessible avec et sans les www. peut causer un problème de dupplication de contenu ce qui n'est pas idéal pour les moteurs de recherche. Une façon d'éviter est de regarder combien de pages sont présentes dans les index des moteurs de recherche avec et sans les www. (site:domain.com). S'il y a plus de pages avec www., forcez la présence du www., sinon, retirez les www. . Dans les 2 cas, faisant des redirections retournant le code HTTP 301 (déplacement permanent), les adresses fautives seront éventuellement remplacées dans les index des moteurs de recherche.

Retirer les www

Il est parfois préférable de se départir des www pour rendre les adresses plus courtes. En tant que tel, les www. n'ajoute aucune valeur. Si un site n'est pas déjà bien référencé dans les moteurs de recherche, il peut être intéressant de forcer le retrait des www.

Forcer la présence du www sans « hardcoder » le domaine

Il peut parfois arriver que plusieurs domaines soient effectifs sur un même compte d'hébergement, bien que c'est en gérale une mauvaise pratique que le même contenu puisse être accessible à partir de différents noms de domaine. Dans un tel cas, plutôt que d'inscrire le nom de domaine dans la règle forçant la présence du www., une règle générale peut être mise en place :

Arrêter des loops de redirections

Bien que non recommandé, il peut arriver que nos règles créées des boucles infinies de redirections sur le serveur. Partant du principe que chaque appel HTTP fait une requête au fichier .htaccess, vous pouvez altérer ce fichier avec le code suivant pour arrêter la boucle.

Déjouer la cache des navigateurs

Trop souvent on doit dire « Avez vous vidé votre cache? »... Une façon de régler ce problème est d'utiliser une règle de réécriture d'adresse permettant de conserver toujours le même nom de fichier pour les feuilles de styles et les fichiers javascript sur le disque mais d'ajouter un numéro de version dans le nom de fichier dans le HTML. Ainsi /skin/js/script-VERSION.js pointe vers /skin/js/script.js et /skin/css/styles-VERSION.css vers /skin/css/styles.css

Retirer le Query_String

Il est très fréquent de voir des sites pour lesquels page.html et page.html?param=bobo affiche le même contenu... Ceci peut causer des problèmes de contenu duppliquer et nuire au référencement de votre site Web. Une façon de régler le problème est de se départir du QUERY_STRING et il suffit simplement d'ajouter un ? à la fin de votre règle.

Documents sauvegardés en base de données

Vous pouvez simuler la présence d'un document PDF ou Word ou autres dans un répertoire donné et utiliser cette règle pour appeler un script en charge de servir le document en provenance de la base de données /getdoc.php

Afficher par défaut dans la langue du visiteur (navigateur)

Il arrive très souvent qu'on doive afficher le contenu d'un site multilangue dans la langue du navigateur du visiteur par défaut. Une façon d'y parvenir est d'utiliser le « flag » ENV permettant d'assigner une variable d'environnement.

On est fermé! Permettre de bloquer l'accès à un fichier à une période donnée de la journée.

Concept à utiliser que si nécessaire... Rendre indisponible du contenu de votre site à une certaine heure pourrait faire en sorte que ce contenu soit retiré des index des moteurs de recherche si ceux ci visitent votre site à cette heure.

Changer les underscore (_) par des tirets (-)

Pour des raisons SEO, les tirets sont plus efficaces que les underscores car ils permettent de séparer une chaîne de caractères en plusieurs mots, plutôt que d'être considéré comme un seul mot. Pour cette raison, l'utilisation de underscrore dans les URL est généralement à éviter. La régle suivante fonctionne pour des URL présentant jusqu'à 5 underscores...

Réduire le vol de bande passante

Il n'est pas rare de voir des sites faire référence directement à une image, une animation flash ou autre mais de façon intégrée à leur contenu. Le résultat est que vous fournissez la bande passante pour le média transmis.

Redirection pour une adresse IP précise

Il arrive souvent qu'on doive ajouter une règle dans un fichier .htaccess et il peut être tentant de la faire directement sur le serveur... Bien entendu, dans certains cas, une erreur de manipulation peut causer des problèmes! C'est pourquoi il peut être intéressant de tester une règle en spécifiant notre adresse IP dans une condition préalable... Ainsi, seulement les requêtes en provenance de cette adresse IP seront considérées.

Contrôle du comportement du HTTPS

Je trouve pratique qu'une section sécurisée d'un site ne soit pas simplement sur https://www.lesite.com... Par exemple, dans le cas de paiement en ligne pour une boutique, l'utilisation d'un sous-domaine secure.lesite.com, lui étant disponible seulement sous HTTPS me paraît un scénario beaucoup plus sympathique... Les règles suivantes permettent d'avoir un contrôle sur une zone bien précise pour le HTTPS et s'assurent que cette zone n'est disponible qu'avec HTTPS

Page 404

Le fichier .htaccess peut également servir à définir une page d'erreur 404 par défaut.