Introduction
Les techniques présentées ici à propos de l’optimisation de l’indexation d’un site s’adresse à tous ceux qui, comme l’auteur de cet article, ne sont pas des webmestres et dont le métier premier n’est pas le design Web. Cet article est le résultat d’un apprentissage autodidacte afin d’améliorer l’indexation de www.sqlpac.com et s’adresse par conséquent aux novices dans le domaine. Si un expert parcourt ce document et détecte une erreur ou une ineptie : Nous contacter
La qualité de l’indexation d’un site par les robots des moteurs d’indexation comme GoogleBot, robot de Google, est particulièrement influencée par la qualité des adresses URL du site.
Le graphique ci-dessous présente l’évolution du nombre de visites par mois du site http://www.sqlpac.com depuis mai 2009. Entre février et mars 2010, la structure des adresses URL du site a été revue et optimisée pour l’indexation. Depuis la restructuration des adresses URL du site sqlpac.com, la qualité de l’indexation par Google a été aussitôt constatée et le nombre de visites par mois est depuis en constante progression.
Le module de réécriture des URL mod_rewrite du serveur Web Apache a été mis à contribution pour structurer les adresses URL afin que celles-ci soient en conformité avec les règles du SEO (Search Engine Optimization).
Au préalable, les conseils de Google à propos de l’écriture des URL sont brièvement rappelés ainsi que l’activation du module mod_rewrite du serveur web Apache puis le document présente les techniques et astuces qui ont été utilisées avec le module de réécriture des adresses URL d’Apache pour le site http://www.sqlpac.com.
La restructuration et l’optimisation des adresses URL se sont déroulées en 2 étapes, étapes menées en parallèle :
- Renomenclature des articles.
- Création d’une structure optimisée des adresses URL du site.
Le module mod_rewrite d’Apache a été d’un grand secours pour réparer les erreurs du passé à propos de la nomenclature des articles et offre une puissance inégalée pour structurer les sites en conformité avec le SEO. Il évite incontestablement le développement d’usines à gaz en Javascript pour effectuer les redirections vers des URL "propres".
Les règles optimales d’écriture des adresses URL pour le SEO (Search Engine Optimization)
L’optimisation de l’indexation avec les meta tags comme description, title
et keywords n’est pas le propos de l’article. Seule la structuration optimisée
des adresses URL est évoquée ici.
2 règles pour améliorer l’indexation SEO à propos des adresses URL :
- Créér des adresses URL évocatrices du sujet.
- Faciliter la navigation dans le site.
À retenir : dans ses algorithmes d’indexation, le robot Google GoogleBot navigue comme un internaute sur un site.
Créér des adresses URL évocatrices du sujet
Entre les 2 adresses URL ci-dessous renvoyées dans des résultats Google, adresses URL qui affichent des articles sur Sybase Adaptive Server Enterprise,
http://www.sqlpac.com/sqlpacv2/prp_library.php5?idfld=6&idsec=6
http://www.sqlpac.com/articles/sybase/adaptive-serverun internaute clique intuitivement sur la deuxième adresse qui est explicite et évocatrice sur le sujet. L’adresse http://www.sqlpac.com/articles/sybase/adaptive-server est par ailleurs plus facilement mémorisable pour un internaute.
Il faut considérer GoogleBot comme un internaute : GoogleBot exploite et indexe bien mieux l’adresse explicite contenant les mots clés séparés par des traits d’union.
Google conseille :
- d’utiliser le trait d’union (
-) pour séparer les mots clés dans une adresse URL au lieu des caractères underscore (_). - d’éviter les adresses URL trop complexes, notamment celles contenant de nombreux paramètres. Elles peuvent empêcher l’indexation.
- d’éviter autant que possible d’insérer des identifiants de session. Remplacer ces derniers par des cookies.
- d’ajouter l’attribut
nofollow(<a href="url" rel="nofollow">) dans les liens d’un calendrier généré dynamiquement
Le dernier paragraphe de cet article présente la technique utilisée avec le module
mod_rewrite d’Apache pour transformer les adresses URL
http://www.sqlpac.com/prp_library.php5?param1=x¶m2=y en adresses
explicites, lisibles et exploitables par un internaute et GoogleBot comme par
exemple http://www.sqlpac.com/articles/sybase/adaptive-server ou
http://www.sqlpac.com/themes/authentification-ldap.
Faciliter la navigation dans le site : plans de site et structures hiérarchiques
Utiliser des adresses URL explicites présente également l’avantage majeur de pouvoir mieux organiser structurellement un site.
La mise en place d’une structure hiérarchique dans un site ou encore plan de site grâce aux adresses URL explicites facilite la navigation de l’internaute mais également, et dans une très forte mesure, l’indexation par Google qui prend en compte la hiérarchie dans ses algorithmes.
www.sqlpac.com/
/apropos/
/recherche/
/articles/
/sybase/
/adaptive-server
/replication-server
/sybase-iq
/oracle/
/oracle-server
/transparent-gateway
/mysql/
/mysql-server
/replication
/themes/
/authentification-ldap
/bus-de-messages
/guides-pratiques
/migrations
/archives/
/2009
/2008
/2007
/2006Google conseille à propos des hiérarchies dans un site :
- d’éviter des profondeurs disproportionnées de hiérarchie (
http://.../dir1/dir2/dir3/dir4/dir5/dir6/page.htm). - d’éviter des liens de navigation trop complexes où les pages sont toutes liées entre elles. GoogleBot s’y perd dans le suivi des liens.
- de trop découper la navigation obligeant l’internaute ou GoogleBot à suivre un nombre important de liens avant d’arriver au contenu final et important.
- d’éviter systématiquement la navigation basée uniquement sur des menus déroulants, images ou animations. Utiliser des liens textes.
Pour finir, ajouter systématiquement un bandeau de navigation en haut ou bas de page, bandeau contenant des liens internes afin de faciliter la navigation des visiteurs vers la section précédente ou parente ou encore vers la page d’accueil du site :
Ce bandeau de navigation aide également favorablement GoogleBot dans l’indexation des liens internes du site en prenant en compte sa hiérarchie.
Activation et utilisation du module mod_rewrite d’Apache
Dans cet article, /intranet/sqlpac est la racine du site web http://www.sqlpac.dev.
DocumentRoot "/intranet/sqlpac"Le module mod_rewrite dans Apache
Par défaut le module de réécriture des URL d’Apache mod_rewrite est
construit à la compilaton d’Apache : --enable-module=rewrite.
La disponibilité du module est réalisée dans le fichier httpd.conf du
serveur Apache en décommentant les lignes suivantes :
/Software/apache/apache-2.2/conf/httpd.conf
#
LoadModule rewrite_module modules/mod_rewrite.so
AddModule mod_rewrite.c
#Activation du module mod_rewrite : RewriteEngine et le fichier .htaccess
La directive Apache RewriteEngine on|off active ou désactive le module
mod_rewrite. Il peut être activé globalement au niveau du serveur Apache ou
seulement pour un répertoire en particulier du site.
Pour activer le module mod_rewrite au niveau du serveur Apache, le fichier
$DIR_APACHE/conf/httpd.conf est édité pour ajouter la directive RewriteEngine
:
#
# httpd.conf
#
RewriteEngine OnUn redémarrage du serveur Apache est nécessaire.
Pour utiliser le module de réécriture des URL uniquement pour un répertoire
donné d’un site, la directive RewriteEngine On est ajouté dans le fichier
.htaccess à créér ou déjà installé dans ce répertoire :
#
# /intranet/referentiel/docs/.htaccess
#
RewriteEngine OnDéboguer les directives de réécriture avec RewriteLog et RewriteLogLevel
Le module Apache mod_rewrite propose des options de debug avec les
directives RewriteLog et RewriteLogLevel.
RewriteLog: chemin et nom du fichier de log. Les actions du module mod_rewrite sont alors consignées dans ce fichier.RewriteLogLevel: niveau de verbosité.
Ces directives ne doivent être utilisées qu’à des fins de débogage, le serveur Apache est très pénalisé d’un point de vue performances lorsque ces directives sont actives et que le niveau de verbosité dépasse 2.
Les directives RewriteLog et RewriteLogLevel sont spécifiées uniquement dans
un fichier <httpd>.conf du serveur Web Apache, il est impossible de
renseigner ces directives pour un répertoire donné dans un fichier .htaccess,
la directive AllowOverride ne l’autorise pas. Si ces directives sont
renseignées dans un fichier .htaccess :
.htaccess
RewriteLog "/Software/apache/apache-2.2/logs/rewrite.log"
RewriteLogLevel 3l’erreur "RewriteLog not allowed here" est levée :
sqlpac-dev-error.log
[Wed Sep 29 15:22:58 2010] [alert] [client 127.0.0.1] /intranet/sqlpac/referentiel/docs/.htaccess:
RewriteLog not allowed here, referer: http://www.sqlpac.dev/articles/conception/google/176Un redémarrage du serveur Apache est nécessaire pour prendre en compte les
directives RewriteLog et RewriteLogLevel.
Règles et conditions : RewriteRule, RewriteCond
Les règles et conditions de réécriture des adresses URL, qu’elles soient
définies au niveau du serveur Apache ou dans le fichier .htaccess pour un
répertoire donné, sont définies avec les directives RewriteRule et RewriteCond.
L’ordonnancement des règles et conditions n’est pas trivial, aussi leur étude
sera faite ici par l’exemple.
RewriteRule par l’exemple
Dans l’exemple, les adresses URL ci-dessous sont réécrites de la façon suivante :
| Ancienne URL | Contenu | Nouvelle URL | Contenu | |
|---|---|---|---|---|
/labs/page1.htm |
Page 1 | /labs/chapitre-1.htm |
Chapitre 1 | |
/labs/page2.htm |
Page 2 | /labs/chapitre-2.htm |
Chapitre 2 | |
/labs/page3.htm |
Page 3 | /labs/chapitre-3.htm |
Chapitre 3 | |
/labs/page4.htm |
(Page inexistante) | /labs/chapitre-4.htm |
Chapitre 4 |
Les pages des anciennes URL peuvent ne plus exister (par exemple la page
page4.htm n’existe pas) : dans tous les cas de figure une redirection interne
ou explicite vers le contenu de la page de la nouvelle URL est réalisée.
Intuitivement, après un survol très rapide des manuels d’Apache, les règles
de réécriture RewriteRule sont appliquées comme ci-dessous dans un fichier
.htaccess installé dans le répertoire /intranet/sqlpac/labs/ :
/intranet/sqlpac/labs/.htaccess
RewriteEngine on
RewriteRule ^page1\.htm$ chapitre-1.htm
RewriteRule ^page2\.htm$ chapitre-2.htm
RewriteRule ^page3\.htm$ chapitre-3.htm
RewriteRule ^page4\.htm$ chapitre-4.htmLes expressions régulières sont utilisables dans les directives RewriteRule
: ^ pour commençant par, $ pour se terminant par, etc. Le caractère spécial .
doit être échappé avec \ car il est interprété dans les expressions
régulières.
Avec les directives ci-dessus : l’adresse
http://www.sqlpac.dev/labs/page2.htm demeure inchangée pour l’internaute ou
GoogleBot mais c’est le contenu de http://www.sqlpac.dev/labs/chapitre-2.htm
qui est affichée.
http://www.sqlpac.dev/labs/page2.htm
Chapitre 2Que nous apprend le fichier de log de moteur mod_rewrite sur le comportement
par défaut ? (la sortie est allégée pour la lisibilité).
| Fichier de log rewrite.log | Commentaire | |
|---|---|---|
| 1. | |
Dans la phase initiale, la page demandée
page2.htm sans le chemin complet est testée
avec les règles d’écriture une par une et
dans l’ordre des règles définies dans le
fichier .htaccess |
| 2. | |
Dès qu’une règle est satisfaite, la translation vers l’URL définie dans la règle est réalisée en mémoire. |
| 3. | |
Les règles restantes sont alors testées sur la forme réécrite. |
| 4. | |
Lorsque toutes les règles sont parcourues,
par défaut, une redirection interne
(INTERNAL REDIRECT) vers chapitre-2.htm
est réalisée sans modifier l’adresse URL
affichée à l’internaute |
| 5. | |
La redirection interne vers le contenu
de la page chapitre-2.htm redéclenche la
vérification des règles définies dans le
fichier .htaccess : |
La fin du processus de réécriture est notifiée par le mot clé "pass through"
dans le fichier de log.
Cet exemple décortiqué montre que l’ordonnancement de l’écriture des règles est capital.
La directive RewriteRule inclut de multiples options : R, NC, F… Ces
options sont données à la fin de la règle sous la forme [option1, option2,
option3,...]. Les options les plus importantes (L, R, et NC) sont présentées
dans les paragraphes qui suivent. La liste des autres options de la directive
RewriteRule sont proposées dans ce guide pratique : SQLPAC - Apache, Guide pratique du module
mod_rewrite
Option L
Les règles sont testées ligne à ligne. À l’étape 3, les règles qui restent à
tester le sont avec la forme réécrite. L’option [L] permet de sauter cette
étape et de sortir prématurément de la boucle en forçant le passage de l’étape
2 à l’étape 4 directement.
/intranet/sqlpac/labs/.htaccess
RewriteEngine on
RewriteRule ^page2\.htm$ chapitre-2.htm [L][rid#e8e2f8/initial]
strip per-dir prefix: /intranet/sqlpac/labs/page2.htm -> page2.htm
applying pattern '^page1\.htm$' to uri 'page2.htm'
strip per-dir prefix: /intranet/sqlpac/labs/page2.htm -> page2.htm
applying pattern '^page2\.htm$' to uri 'page2.htm'
rewrite 'page2.htm' -> '/labs/chapitre-2.htm'
add per-dir prefix: chapitre-2.htm -> /intranet/sqlpac/labs/chapitre-2.htm
strip document_root prefix: /intranet/sqlpac/labs/chapitre-2.htm -> /labs/chapitre-2.htm
internal redirect with /labs/chapitre-2.htm [INTERNAL REDIRECT]
[rid#e9b858/initial/redir#1]
strip per-dir prefix: /intranet/sqlpac/labs/chapitre-2.htm -> chapitre-2.htm
applying pattern '^page1\.htm$' to uri 'chapitre-2.htm'
...
pass through /intranet/sqlpac/labs/chapitre-2.htmBien entendu, il faut être sur que la forme réécrite n’est pas sujette à une règle définie.
Option R
L’option [R] force la redirection explicite vers la nouvelle adresse pour
l’internaute ou GoogleBot, il ne s’agit plus d’une redirection cachée et
interne.
http://www.sqlpac.dev/labs/page2.htmhttp://www.sqlpac.dev/labs/chapitre-2.htm
Chapitre 22 arguments sont possibles avec la redirection : R=301 et R=302. Sans
argument, par défaut, la redirection 302 est appliquée.
R=302: l’adresse URL est déplacée temporairement.R=301: l’adresse URL est déplacée définitivement.
L’argument 301 est très important car il permet de notifier notamment à GoogleBot pour son indexation qu’une adresse URL a été définitivement déplacée.
Avec les options de redirection R, le chemin complet de la nouvelle adresse URL est obligatoire
dans le fichier .htaccess sauf si la directive RewriteBase est spécifiée.
Voici un exemple avec la redirection par défaut (redirection temporaire), sans la directive RewriteBase
:
/intranet/sqlpac/labs/.htaccess
RewriteEngine on
RewriteRule ^page2\.htm$ /labs/chapitre-2.htm [L,R][rid#e8e2f8/initial]
strip per-dir prefix: /intranet/sqlpac/labs/page2.htm -> page2.htm
applying pattern '^page1\.htm$' to uri 'page2.htm'
strip per-dir prefix: /intranet/sqlpac/labs/page2.htm -> page2.htm
applying pattern '^page2\.htm$' to uri 'page2.htm'
rewrite 'page2.htm' -> '/labs/chapitre-2.htm'
explicitly forcing redirect with http://www.sqlpac.dev/labs/chapitre-2.htm
escaping http://www.sqlpac.dev/labs/chapitre-2.htm for redirect
redirect to http://www.sqlpac.dev/labs/chapitre-2.htm [REDIRECT/302]
[rid#e9b858/initial/redir#1]
strip per-dir prefix: /intranet/sqlpac/labs/chapitre-2.htm -> chapitre-2.htm
applying pattern '^page1\.htm$' to uri 'chapitre-2.htm'
...
pass through /intranet/sqlpac/labs/chapitre-2.htmAvec la directive RewriteBase
/intranet/sqlpac/labs/.htaccess
RewriteEngine on
RewriteBase "/labs/"
RewriteRule ^page2\.htm$ chapitre-2.htm [L,R]Pour une redirection définitive, c’est le mot clé [REDIRECT/301] qui
apparaît dans le fichier de log
/intranet/sqlpac/labs/.htaccess
RewriteEngine on
RewriteRule ^page2\.htm$ /labs/chapitre-2.htm [L,R=301][rid#e8e2f8/initial]
...
redirect to http://www.sqlpac.dev/labs/chapitre-2.htm [REDIRECT/301]
...Option NC
L’option [NC] (pour No CaseSensitive) rend les opérations de réécriture
insensibles à la casse.
/intranet/sqlpac/labs/.htaccess
RewriteEngine on
RewriteRule ^page1\.htm$ /labs/chapitre-1.htm [R,NC]la saisie de l’adresse http://www.sqlpac.dev/labs/paGE1.htm sera bien
réécrite et redirigée vers http://www.sqlpac.dev/labs/chapitre-1.htm
RewriteCond par l’exemple
Des conditions peuvent être ajoutées à des règles avec la directive
RewriteCond. Exemple : la redirection de la page page2.htm vers chapitre-2.htm
n’est réalisée que si l’adresse IP du requêteur est 127.0.0.1
/intranet/sqlpac/labs/.htaccess
RewriteEngine on
RewriteRule ^page1\.htm$ /labs/chapitre-1.htm [L,R=301]
RewriteCond %{REMOTE_ADDR} ^127.0.0.1*
RewriteRule ^page2\.htm$ /labs/chapitre-2.htm [L,R=301]
RewriteRule ^page3\.htm$ /labs/chapitre-3.htm [L,R=301]
RewriteRule ^page4\.htm$ /labs/chapitre-4.htm [L,R=301]La ou les conditions écrites ne s’appliquent qu’à la directive RewriteRule
qui suit immédiatement. Les conditions ne sont pas conservées pour les
directives RewriteRule ultérieures.
Dans l’exemple ci-dessus, la condition %REMOTE_ADDR qui commence par
127.0.0.1 ne s’applique que pour la redirection de page2.htm. Elle ne sera
jamais appliquée aux règles définies pour page1.htm ou page3.htm.
strip per-dir prefix:
/intranet/sqlpac/labs/page2.htm -> page2.htm
applying pattern '^page2\.htm$' to uri 'page2.htm'
RewriteCond: input='127.0.0.1' pattern='^127.0.0.1*' => matched
rewrite 'page2.htm' -> '/labs/chapitre-2.htm'
explicitly forcing redirect with http://www.sqlpac.dev/labs/chapitre-2.htm
escaping http://www.sqlpac.dev/labs/chapitre-2.htm for redirect
redirect to http://www.sqlpac.dev/labs/chapitre-2.htm [REDIRECT/301]
...Il est possible de combiner avec l’opérateur OU des conditions grâce à
l’option OR de la directive RewriteCond ( SQLPAC : Apache - Guide pratique du module
mod_rewrite). Les conditions peuvent être également insensibles à la
casse avec l’option NC.
Résumé de la cinématique des directives RewriteRule et RewriteCond
Le schéma ci-dessous résume bien plus qu’une dissertation la cinématique du moteur de réécriture des adresses URL vue dans les paragraphes précédents.
Renomenclature des articles et migration de l’indexation Google existante
Adoption d’une nouvelle nomenclature
La nomenclature des articles adoptée en 2003 à la naissance de SQLPAC était parfaitement inadaptée pour l’optimisation de l’indexation : les URL étaient préfixées du numéro de la documentation et aucun mot clé en rapport avec le sujet de l’article exploitable par le robot GoogleBot n’apparaissait dans l’URL.
Pour exemples, l’article qui traite du partitionnement sémantique de Sybase
Adaptive Server Enterprise 15.0 avait pour nomenclature
158_sy_ase15semantincpartitioning.htm et l’article généraliste sur les
commandes find et grep sous Unix avait pour nomenclature 037_un_fdgrep.htm.
Pour optimiser l’indexation, la nomenclature des fichiers HTML et PDF des articles nouvellement adoptée est la suivante :
[éditeur][thème]-[produit][version]-*-[mot clé #1 sujet][mot clé #2 sujet]*.htmSont bannis dans la nouvelle nomenclature :
- Les caractères accentués é, è, à, etc.
- Excepté le point pour les versions, les caractères de ponctuation : ; , ! ?.
- Quelques caractères spéciaux : # $ ^ *
Les 2 articles cités en exemple ont désormais pour nouvelle nomenclature :
sybase-ase-15.0-partitionnement-semantique.htm
unix-find-grep-commandes.htmChaque composante de la nomenclature de l’article devient exploitable par
GoogleBot pour l’indexation : sybase, ase, 15.0, partitionnement, sémantique,
unix, find, grep, commandes.
Migration de l’indexation existante grâce au module mod_rewrite d’Apache
Si les anciennes adresses URL sont indexées par Google, les nouvelles et anciennes nomenclatures des articles doivent dans un premier temps coexister : la migration va demander du temps (quelques semaines à 2 ou 3 mois).
ls /referentiel/docs/037_un_fdgrep.htm 158_sy_ase15semantincpartitioning.htm sybase-ase-15.0-partitionnement-semantique.htm unix-find-grep-commandes.htm
Les règles RewriteRule sont alors écrites pour chaque article dans un
fichier .htaccess créé dans le répertoire des articles en donnant le chemin
complet car il s’agit d’une redirection de type permanente (R=301) :
/referentiel/docs/.htaccess
...
RewriteRule ^037_un_fdgrep\.htm$ /referentiel/docs/unix-find-grep-commandes.htm [R=301,L,NC]
...Le chemin complet peut être omis en indiquant la directive RewriteBase dans le fichier .htaccess.
/referentiel/docs/.htaccess
...
RewriteBase "/referentiel/docs/"
RewriteRule ^037_un_fdgrep\.htm$ unix-find-grep-commandes.htm [R=301,L,NC]
...GoogleBot est aidé avec un fichier sitemap mis à jour avec les nouvelles
nomenclatures des URL :
/referentiel/sitemap/sitemap.xml
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.google.com/schemas/sitemap/0.84"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.google.com/schemas/sitemap/0.84
http://www.google.com/schemas/sitemap/0.84/sitemap.xsd">
<urlset>
<url>
<!-- #37 -->
<loc>http://www.sqlpac.com/referentiel/docs/unix-find-grep-commandes.htm</loc>
<lastmod>2002-07-31</lastmod>
<changefreq>monthly</changefreq>
<priority>0.5</priority>
</url>
</urlset>Lorsque la nouvelle nomenclature unix-find-grep-commandes.htm est finalement
indexée par Google :
- Soumettre la suppression de l’ancienne nomenclature
/referentiel/docs/037_un_fdgrep.htmdans l’outil "Google Webmaster Tools" (SQLPAC : Google - Outils pour les Webmasters. Supprimer des pages de l’index Google ) - Dès que la suppression de la page est acceptée, supprimer physiquement la page
/referentiel/docs/037_un_fdgrep.htmet retirer l’entréeRewriteRuledans le fichier.htaccesspour cette page (sauf si un autre site référence cette ancienne nomenclature et que l’on souhaite conserver ce référencement).
Création d’une structure optimisée des adresses URL du site
Contexte
Le module de réécriture des URL d’Apache va être un formidable outil pour
structurer le site de manière optimale. L’objectif est de masquer aux
internautes et GoogleBot les scripts PHP appelés pour les remplacer par des
adresses URL parlantes (http://www.sqlpac.com/articles/sybase/adaptive-server,
etc.). La structure du site mise en place est celle présentée dans le
paragraphe d’introduction, elle est rappelée ici :
www.sqlpac.com/
/apropos/
/recherche/
/articles/
/sybase/
/adaptive-server
/replication-server
/sybase-iq
/oracle/
/oracle-server
/transparent-gateway
/mysql/
/mysql-server
/replication
/themes/
/authentification-ldap
/bus-de-messages
/guides-pratiques
/migrations
/archives/
/2009
/2008
/2007
/2006Les scripts et pages du site SQLPAC sont installés non pas à la racine du
site mais dans un sous répertoire /intranet/sqlpac/sqlpacv2, ce qui corse un
peu techniquement le sujet et www.sqlpac.com pointe sur /intranet/sqlpac.
/intranet/sqlpac/sqlpacv2/index.php5 est le script qui ouvre le site.
ls /intranet/sqlpac/sqlpacv2index.php5 prp_library.php5 prp_srch.php5
Structuration des URL pour les articles
Le fichier .htaccess avec les règles de réécriture est créé à la racine du
site (/intranet/sqlpac).
L’adresse URL http://www.sqlpac.com/articles/sybase/adaptive-server
correspond en réalité à l’exécution du script
prp_library.php5?libfld=sybase&libsec=adaptive-server&item=0. Grâce aux
expressions régulières, la régle de réécriture en redirection masquée (INTERNAL
REDIRECT) va donc être la suivante :
/intranet/sqlpac/.htaccess
RewriteRule ^articles/([A-Za-z0-9-]+)/([A-Za-z0-9-]+)$ prp_library.php5?libfld=$1&libsec=$2&item=0 [L]Chaque variable $1, $2… est le résultat de chaque expression régulière
(regexp) dans la règle de réécriture : (sybase) => $1, (adaptive-server)
=>$2.
D’après la cinématique observée précédemment dans le module de réécriture
des URL : la règle /articles/sybase/adaptive-server ayant été vérifiée, c’est
ensuite au tour de prp_library.php5 de repasser dans la moulinette des règles
une par une.
[rid#e8e2f8/initial]
applying pattern '^articles/([A-Za-z0-9-]+)/([A-Za-z0-9-]+)$' to uri 'articles/sybase/adaptive-server'
rewrite 'articles/sybase/adaptive-server' -> 'prp_library.php5?libfld=sybase&libsec=adaptive-server&item=0'
split uri=prp_library.php5?libfld=sybase&libsec=adaptive-server&item=0 -> uri=prp_library.php5, args=libfld=sybase&libsec=adaptive-server&item=0
add per-dir prefix: prp_library.php5 -> /intranet/sqlpac/prp_library.php5
strip document_root prefix: /intranet/sqlpac/prp_library.php5 -> /prp_library.php5
internal redirect with /prp_library.php5 [INTERNAL REDIRECT]
[rid#e9dab8/initial/redir#1]
strip per-dir prefix: /intranet/sqlpac/prp_library.php5 -> prp_library.php5Cependant, prp_library.php5 n’est pas un script à la racine du site
(/intranet/sqlpac), ce script est dans un sous répertoire du site :
/intranet/sqlpac/sqlpacv2.
En conséquence, si l’URL traitée par le moteur de réécriture est un script
PHP ou une page HTML du répertoire /intranet/sqlpac/sqlpacv2, une redirection
interne ou masquée (INTERNAL REDIRECT) est réalisée vers /sqlpacv2/<script
ou page html>, ce qui s’écrit avec une règle RewriteRule accompagnée d’une
condition RewriteCond (-f pour indiquer un script existant) :
/intranet/sqlpac/.htaccess
RewriteEngine on
RewriteCond %{DOCUMENT_ROOT}/sqlpacv2%{REQUEST_URI} -f
RewriteRule .* /sqlpacv2/$0 [L]
RewriteRule ^articles/([A-Za-z0-9-]+)/([A-Za-z0-9-]+)$ prp_library.php5?libfld=$1&libsec=$2&item=0 [L]rid#e9dab8/initial/redir#1]
strip per-dir prefix: /intranet/sqlpac/prp_library.php5 -> prp_library.php5
applying pattern '.*' to uri 'prp_library.php5'
RewriteCond: input='/intranet/sqlpac/sqlpacv2/prp_library.php5' pattern='-f' => matched
rewrite 'prp_library.php5' -> '/sqlpacv2/prp_library.php5'
internal redirect with /sqlpacv2/prp_library.php5 [INTERNAL REDIRECT]
strip per-dir prefix: /intranet/sqlpac/sqlpacv2/prp_library.php5 -> sqlpacv2/prp_library.php5
...Règle pour la racine
Si l’internaute ou GoogleBot saisit http://www.sqlpac.com, c’est le script
index.php5 qui doit être exécuté en redirection interne. Le cas de la racine
est traité en appliquant une règle de redirection interne sur index.php5 pour
^$, expression qui notifie une requête vide par rapport au positionnement
courant du fichier .htaccess.
RewriteRule ^$ index.php5 [L]Cas des caractères résiduels / dans les saisies d’URL
Le cas très fréquent de la saisie d’un caractère / résiduel à la fin de
l’URL par l’internaute doit être traitée
(http://www.sqlpac.com/articles/sybase/adaptive-server/). La règle n’est en effet plus
vérifiée avec ce caractère résiduel /
applying pattern '^articles/([A-Za-z0-9-]+)/([A-Za-z0-9-]+)$' to uri 'articles/sybase/adaptive-server/'La simple règle ci-dessous retire en redirection interne le caractère / à la
fin de l’URL, règle à placer judicieusement avant les règles principales de
structuration du site (/articles, /themes, etc.).
RewriteRule ^(.+)/$ $1 [L]Résultat final
Un simple fichier .htaccess avec très peu de directives RewriteRule et
RewriteCond génère une structure de site lisible et très efficace pour
GoogleBot :
/intranet/sqlpac/.htacess
RewriteEngine on
RewriteCond %{DOCUMENT_ROOT}/sqlpacv2%{REQUEST_URI} -f
RewriteRule .* /sqlpacv2/$0 [L]
# Si / a la fin, suppression du / pour la vérification des règles
RewriteRule ^(.+)/$ $1 [L]
RewriteRule ^$ index.php5 [L]
RewriteRule ^index\.html$ index.php5 [L]
RewriteRule ^articles/([A-Za-z0-9-]+)/([A-Za-z0-9-]+)$ prp_library.php5?libfld=$1&libsec=$2&item=0 [L]
RewriteRule ^articles/([A-Za-z0-9-]+)/([A-Za-z0-9-]+)/([A-Za-z0-9-_\.]+)$ prp_library.php5?libfld=$1&libsec=$2&item=$3 [L]
RewriteRule ^themes$ prp_library.php5?libtheme=0 [L]
RewriteRule ^themes/([A-Za-z0-9-]+)$ prp_library.php5?libtheme=$1&item=0 [L]
RewriteRule ^themes/([A-Za-z0-9-]+)/([A-Za-z0-9-_\.]+)$ prp_library.php5?libtheme=$1&item=$2 [L]
RewriteRule ^archives/([0-9]{4})$ index.php5?crtYear=$1 [L]
RewriteRule ^news/([0-9]+)$ index.php5?item=$1 [L]
RewriteRule ^recherche$ prp_srch.php5 [L]
RewriteRule ^apropos$ prp_apropos.php5 [L]
RewriteRule ^remarques$ prp_upd_suggest.php5 [L]
RewriteRule ^inscription$ prp_upd_subscribe.php5 [L]Conclusion
Le moteur de réécriture des URL d’Apache est très complexe et puissant et il s’avère être un formidable compagnon incontournable pour structurer efficacement des sites pour des internautes ou GoogleBot.
Il permet d’éviter bien des développements lourds et non maintenables en Javascript, PHP ou autres langages pour arriver au même résultat.