Les procédures de définition d’un projet web mettent naturellement ce que l’on trouve dans le site. L’identité visuelle, l’ergonomie, les chemins que les utilisateurs devront parcourir pour atteindre leur objectifs sautent à l’esprit puisque c’est ce que l’on voit et ressent dès les premières minutes sur un site. Depuis que Google est en position de quasi-monopole dans la plupart des pays, on prend aussi en compte des mots clefs (taxonomie, règles d’édition du contenu) et d’informations moins visuelles (comme le titre des fenêtres ou les textes descriptifs des images). Ça fait déjà une longue liste de tâches à accomplir pour être au niveau par rapport à vos concurrents potentiels. La bonne nouvelle, c’est qu’il y a encore des moyens de se différencier et de marquer des points de manière efficace ou de combler votre retard actuel. Comme le nom « url rewriting » l’indique, l’idée est de reformater les urls pour leur donner plus de pertinence, de sens.
Reformater mes urls ?
En ré-écrivant des urls dynamiques, il y a de fortes chances pour que la structure qui se déploie dans la barre d’adresse de votre navigateur paraisse plus logique aux yeux de vos visiteurs. C’est déjà quelque chose que vous voyez au quotidien sans vous en rendre compte. Normal, on ne remarque que si nous parait compliqué. Ainsi, de l’exemple #1 on pourra passer à l’exemple #2 en quelques étapes.
Exemple #1:
https://www.site.com/comparaison.php?categorie=172201&c=fr&l=fr
Exemple #2:
https://voyages.site.fr/billet/avion
1er avantage: imaginons que l’on voit cette url dans les pages de résultat d’un moteur de recherche (SERP), il y a fort à parier que que les visiteurs cliquent davantage sur l’url qui comprend les mots clefs qui correspondent à leur recherche.
2ème avantage: entre deux pages comprenant un contenu globalement similaire, traitant du même sujet, sans vrai facteur différenciateur; devinez laquelle de ces pages sera indexée plus facilement que l’autre ?
Pour autant, le champ d’application de l’url-rewriting est bien plus large que ce simple exemple. En fonction des besoins de vos projets, on pourra approcher cette fonctionnalité en s’axant sur:
- la sécurité : cacher des failles potentielles liées à certains scripts,
- le SEO : améliorer le référencement naturel des pages du site et le click-through,
- le Customer Experience : les visiteurs peuvent mieux appréhender la structure du site… et on aime tous pouvoir se repérer sur un site,
- les webanalytics : imaginez un rapport de trafic / revenu (basé sur les répertoires de vos urls) qui ait du sens,
- l’opérationnel : pas besoin de changer toutes vos urls (ni de perdre le trafic ou Page Rank associé) lorsque vous lancez ou re-« brandez » un produit ou un site.
Chacun de ses points peut être une raison suffisante pour se lancer dans cet exercice.
Ok, j’en veux changer la structure de mes urls, je fais comment ?
Il existe des centaines de très bon sites qui couvrent l’implémentation technique sous les différents serveurs web qui existent aujourd’hui (enfin quand même surtout Apache et Microsoft IIS). Sans réinventer ou recopier ce qui a été fait ailleurs, voilà déjà quelques pistes qui vont vous donner de quoi commencer.
Revenons à la définition de l’url rewriting. Le principe est de de vous permettre d’écrire des règles permettant au serveur de modifier les urls des contenus recherchés par les visiteurs. On a donc bien une notion de règles (à définir) que le serveur (Apache ou IIS) devra interpréter.
Concrètement, je veux transformer quoi en quoi ?
La première étape est donc de faire un état de ce que vous avez et de voir en quoi vous voulez le transformer. Bien que cela tombe sous le sens, il est important de bien se poser la question sous différents angles. Est-ce que ce que vous pourriez imaginer sur un coin de table serait pertinent une fois que vous regarder à vos rapports de statistiques ? Est-ce votre site est la cible d’attaques incessantes contre lesquelles il faudrait penser à se protéger ?
La meilleure méthode reste de commencer à griffonner sur un bout de feuille Excel les urls type que vous avez aujourd’hui, trier celles que vous voulez reformater et imaginer comment vous pourriez les simplifier. Vous n’avez pas besoin de simplifier TOUTES les urls de votre site, une approche branche par branche peut être se révéler bien plus pertinente ou en tous cas permettre de valider les acquis et la méthode.
Comment je dis ça au serveur ?
Cette fois, cela va dépendre du langage et du type de serveur que vous utilisez pour faire tourner votre site. Il exise grosso-modo 2 types de serveurs web : Apache (qui se couple généralement avec PHP & MySQL) et Microsoft IIS (qui se couple généralement avec ASP.NET). D’après Woozweb (observatoire de sites) la part de serveurs Apache tourne autour des 80% du marché alors que IIS ne récolte que près de 20%. Apache représente a peu près 80% du marché mondial, vous trouverez par conséquent beaucoup plus de documentation à ce sujet, pour autant IIS n’est pas en reste et vous permet d’atteindre exactement les mêmes objectifs. Commençons donc avec le couple Apache & PHP.
Méthodologie sous Apache
On se bornera ici à faire quelques tests donnant des directions sur ce que vous pouvez développer de votre côté. En aucun cas il ne s’agit d’une liste exhaustive.
1. Assurez-vous que votre serveur Apache gère l’url rewriting.
Il se peut que, en fonction de votre hébergeur ou de la manière dont est configuré le serveur, les instructions ne soient pas prises en charge. Commençons par savoir si le module est actif.
Créez le fichier « info_config_apache.php » comprenant cette simple ligne de code:
<?php phpinfo(); ?>
Ouvrez votre navigateur à l’adresse en question et regardez si « mod_rewrite » fait partie des modules listés. Si ce n’est pas le cas, je vous conseille de vous reporter à la FAQ de votre hébergeur. S’il s’agit de votre propre serveur, vous trouverez toutes les démarches ici. Enfin, si vous êtes hébergés chez 1and1, l’instruction ne s’affichera pas dans la liste pas mais vous pourrez tout de même faire de l’url rewriting.
2. Essayons ensuite de passer une ou deux commandes de test pour être sur que tout fonctionne bien avant de se lancer.
En fonction de votre hébergeur (notamment en hébergement mutualisé) il se peut que vous deviez rajouter quelques lignes de code. Lancez donc votre éditeur de code, Dreamweaver ou Notepad, et créez (ou éditez) un fichier « .htaccess » à la racine de votre site. Le fichier « .htaccess » permet de faire énormément de choses très utiles dans de nombreux domaines; si vous n’en avez jamais entendu parlé, je vous conseille d’aller là et là avant de continuer. Tout le monde est revenu ? Ok, on commence donc avec ce petit bout de code:
Options +FollowSymlinks
RewriteEngine on
RewriteBase /
RewriteRule ^perdu.html$ gagne.html [L]
Placez le à la racine de votre site, et créez au passage le fichier gagne.html. Si vous avez la flemme, téléchargez les deux fichiers en question et de-zippez les sur la racine de votre site.
Une fois les fichiers en place, il vous reste juste à tester avec votre navigateur si tout fonctionne bien. Tapez donc l’url de votre site (https://www.monsite.com/perdu.html) et vous devriez être redirigé de manière transparente vers le fichier gagner.html. Si ca marche, passez à l’étape suivante. Si ca ne marche pas (probablement « erreur 500 »), essayez de retirer la première puis la troisième ligne de code du fichier .htaccess.
3. Passons maintenant à la phase finale, la mise en production de ce que vous aviez griffonné un peu plus tot.
Pour cela il existe tout un langage et une syntaxe. Je ne livrerai ici que 2 exemples typiques et des sites permettant d’approfondir.
Forcer le sous-domaine « www » ?
Options +FollowSymlinks
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_HOST} ^votre_site\.com$
RewriteRule ^(.*)$ https://www.votre_site.com/$1 [R=301,L]
Si vous tapez « votre_site.com », le serveur affichera et interprètera automatiquement « www.votre_site.com ». Visitez le site Apache Mod Rewrite pour creuser cet exemple.
Cacher les extensions de fichiers
Options +FollowSymlinks
RewriteEngine on
RewriteBase /
RewriteCond %{SCRIPT_FILENAME} !-d
RewriteRule ^([^\.]+)$ $1.php [NC,L]
Allez sur votre site, et vous y verrez toutes vos pages fonctionner sans le « .php », c’est à dire comme un nom de répertoire. Visitez le site Apache Mod Rexrite pour creuser cet exemple.
Dans un prochain article, nous reviendrons sur la syntaxe assez barbare utilisée ici -les expressions rationnelles- et nous verrons que cette norme est extrêmement pratique et puissante dans de nombreux domaines. D’ici là vous pouvez continuer à parcourir des exemples d’url rewriting et même d’autres possibilités offertes par la manipulation d’un fichier .htaccess.
Méthodologie sous IIS
Microsoft oblige, IIS nous offre une API pour faire ces même manipulations. On utilisera pourra utiliser l’application ISAPI (Internet Server Application Program Interface) développée par Helicon qui revient à triturer un fichier .htaccess sous Apache. On notera d’ailleurs que ISAPI 3.0 permet d’importer un fichier .htaccess, ce qui n’est pas sans intérêt. Découvrez ISAPI 3.0 et d’autres logiciels du même style .
IIS gérant nativement l’ASP.NET, vous pourrez aussi passer par une approche « code » si vous n’avez pas accès à la configuration de votre serveur. Voilà de quoi vous mettre sur la voie !
Le temps de digerez tout ca et j’aurai fini un deuxième article sur une série d’exemples prioritaires pour vos réécritures d’url sur Apache. D’ici là, commencez déjà à imaginer si certaines de vos urls devraient être réécrites et si oui, lesquelles et pour donner quel résultat ! Tout un programme.
