Le module mod_rewrite de réécriture des URL d’Apache 2 appliqué à l’optimisation de l’indexation (SEO)

Logo

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.

Evolution indexation

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-server

un 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.

resultat Google SQLPAC Sybase Adaptive Server Enterprise

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&param2=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
                        /2006

Google 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 :

Sitemap

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 On

Un 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 On

Dé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 3

l’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/176

Un 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.htm

Les 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 2

Que 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.
[rid#f2a0f8/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'
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.
[rid#f2a0f8/initial]
rewrite 'page2.htm' -> 'chapitre-2.htm'
add per-dir prefix:
chapitre-2.htm -> /intranet/sqlpac/labs/chapitre-2.htm
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.
[rid#f2a0f8/initial]
strip per-dir prefix:
/intranet/sqlpac/labs/chapitre-2.htm -> chapitre-2.htm
applying pattern '^page3\.htm$' to uri 'chapitre-2.htm'
strip per-dir prefix:
/intranet/sqlpac/labs/chapitre-2.htm -> chapitre-2.htm
applying pattern '^page4\.htm$' to uri 'chapitre-2.htm'
Les règles restantes sont alors testées sur la forme réécrite.
4.
[rid#f2a0f8/initial]
strip document_root prefix:
/intranet/sqlpac/labs/chapitre-2.htm -> /labs/chapitre-2.htm
internal redirect with /labs/chapitre-2.htm [INTERNAL REDIRECT]
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.
[rid#f49b60/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'
strip per-dir prefix:
/intranet/sqlpac/labs/chapitre-2.htm -> chapitre-2.htm
applying pattern '^page2\.htm$' to uri 'chapitre-2.htm'
strip per-dir prefix:
/intranet/sqlpac/labs/chapitre-2.htm -> chapitre-2.htm
applying pattern '^page3\.htm$' to uri 'chapitre-2.htm'
strip per-dir prefix:
/intranet/sqlpac/labs/chapitre-2.htm -> chapitre-2.htm
applying pattern '^page4\.htm$' to uri 'chapitre-2.htm'
pass through /intranet/sqlpac/labs/chapitre-2.htm
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.htm

Bien 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.htm
http://www.sqlpac.dev/labs/chapitre-2.htm

Chapitre 2

2 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.htm

Avec 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.

Cinématique rewrite url

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]*.htm

Sont 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.htm

Chaque 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.htm dans 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.htm et retirer l’entrée RewriteRule dans le fichier .htaccess pour 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
                        /2006

Les 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/sqlpacv2

index.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.php5

Cependant, 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.