La barre oblique dans l’URL, oui ou non?

Votre grand-maman vous l’a peut-être déjà dit dans le passé: « le diable est dans les détails! » Les choses ont tendance à se compliquer lorsqu’on creuse un peu plus profondément dans les détails d’implémentation.

Dernièrement, dans mon équipe, il s’agit de la question de la barre oblique en fin d’URL qui s’est invitée dans le débat. Il était de savoir quel format adopter pour les URL du projet web du client que nous débutions.

En fait, le débat a démarré sur la préférence du client pour que les URL comprennent en tout temps la barre oblique à la fin. Concrètement, le souhait est que les URL aient la forme suivante : https://frenchcoding.com/2014/03/17/les-liens-de-la-semaine-edition-71/.

Ma première réaction a été d’émettre des critiques et des réserves à cette décision. À mes yeux, la barre oblique en fin d’URL ajoute inutilement un caractère à une URL. Une URL est avant tout conçue pour les humains et doit être sans source d’erreurs possibles.

C’est à ce moment que mes recherches à ce sujet ont débuté. Rapidement, j’ai su que j’avais tort de croire que j’avais absolument raison sur ce point. La problématique est plus philosophique que concrète.

Historique

Le format d’une URL est intimement lié aux chemins de répertoires de type Unix. Un fichier se situe dans un répertoire comme /var/www/type/ficher.tar.gz. Cette convention a aussi été conservée pour le protocole HTTP et ses cousins.

Cette décision a beaucoup de sens lorsqu’on y pense. Toutefois, lorsqu’on creuse dans le détail, il faut se rendre compte de l’évidence suivante. Selon la philosophie UNIX, un chemin d’accès comme /chemin/accès/ représente un répertoire tandis que /un/chemin représente un fichier qui peut être téléchargé.

L’argument de laisser tomber la barre oblique en fin d’URL tiens uniquement de l’idéologie, car il a été clairement affirmé par Google que cela a aucune importance pour son algorithme d’indexation.

La seule règle à suivre

Vous trouvez qu’une URL ayant une barre oblique en fin d’URL est jolie? Tant mieux. Cela importe très peu dans l’équation, en réalité. Ce qui doit, cependant, être fait est de s’assurer que l’un ou l’autre des formats soit accessible sur votre site.

Ce qui est souhaité dans cette situation c’est qu’une requête à une page dans le mauvais format redirige vers le bon format. C’est tout. La redirection à opter dans ce cas est une redirection 301.

Alternativement, si vous n’êtes pas en mesure de faire une redirection automatiquement, vous pouvez faire en sorte que les contenus dans le format d’URL incorrect contiennent un lien ayant l’attribut rel= »canonical ».

Sources

http://stackoverflow.com/questions/3888997/dynamic-urls-with-or-without-a-trailing-slash/3889636#3889636

http://stackoverflow.com/questions/5948659/trailing-slash-in-urls-which-style-is-preferred

http://googlewebmastercentral.blogspot.ca/2010/04/to-slash-or-not-to-slash.html

http://moz.com/learn/seo/canonicalization

http://stackoverflow.com/questions/696673/lower-case-urls-in-asp-net-mvc

Advertisements

Laisser un commentaire

Entrer les renseignements ci-dessous ou cliquer sur une icône pour ouvrir une session :

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l’aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment ce contenu :