Aller au contenu principal

Réflexions sur la construction de mes URLs

Guillaume Barbier

Temps de lecture : ~ 4 minutes

Cette semaine, j'ai pas mal questionné mes collègues et mes potes dev sur la façon dont je génère mes URLs, histoire d'être sûr de pas "avoir fait une boulette".

Ma crainte ? Avoir surcomplexifié le truc et m'être exposé inutilement à des risques de 404.

La formation de mes URLs

Note

La règle ci-dessous ne concerne que nos articles et les entrées de mon journal. En dehors de ces sections, les URLs de chaque page sont définies au cas par cas.

J'ai implémenté une logique commune pour nommer les contenus générés dans les dossiers "articles" et "journal" (et donc définir leurs URLs) :

/<nom du dossier>/<date de l'article>-<Titre de l'article sécurisé pour les URLs>

Sécuriser du texte pour les URLs

Pour pouvoir reprendre du texte dans une URL tout en gardant une URL fonctionnelle et aisément lue, il est nécessaire de remplacer un certain nombres de caractères :

  • les espaces
  • les caractères accentués
  • la ponctuation (en particulier le point d'interrogation)
  • de nombreux caractères spéciaux (en particulier le croisillon[1])
  • …

Pour faire tout cela, Eleventy embarque heureusement une fonction nommée slugify et qui effectue tous ces remplacements pour moi.

Pourquoi former mes URLs ainsi ?

Deux raisons :

  • Je crois avoir lu quelque part que reprendre le titre dans l'URL était bon pour le SEO (Ce que m'a confirmé avec prudence une amie, en précisant qu'il faudrait aussi supprimer tous les "petits mots", pronoms et conjonctions… ce que je n'ai pas fait)
  • Ça me permet de plus facilement reconnaître les URLs que je partage (par rapport à un obscur identifiant arbitraire)

La problématique

Elle est en fait assez simple : si je change le titre de ma page, je change son URL.

Ce qui veut dire que si je publie un article, le partage puis corrige une faute d'orthographe dans son titre, l'URL partagée aboutira sur une 404.

C'est à cause de ce risque que je me suis posé la question de la pertinence de mes URLs : Si cette approche n'est pas pertinente, il vaut mieux réfléchir à comment la remplacer plutôt que d'essayer de palier aux problèmes qu'elle pose.

Au final, je n'ai pas trouvé de réponses déterminantes mais aucun signe que c'était une mauvaise idée non plus… je vais donc, pour l'instant, conserver cette logique de définition des URLs et tenter de régler ses défauts

Des solutions ?

Malheureusement, pas vraiment.

La question des URLs et de leur stabilité est un problème récurrent que de nombreux CMS ont tenté de résoudre. J'ai notamment vu des solutions comme celles-ci :

  • utiliser le titre pour générer l'URL mais uniquement à la création (ensuite, titre et URL sont indépendants)
  • ajouter une redirection à chaque changement de titre vers l'URL actuellement valide
  • proposer (à la demande) des URLs de partage stable, avec un identifiant unique et immuable (et souvent incompréhensible)

J'aime bien les deux premières mais j'ai un problème de taille pour les implémenter : le mode de fonctionnement d'un générateur de site statique.

Les limites d'un générateur de site statique

Lorsque qu'Eleventy réagit à un changement de fichier, il n'a pas accès à l'état précédent de l'information. Il a uniquement accès à l'information contenue dans le fichier à cet instant T.

Avec un CMS, je pourrais consulter la donnée modifiée avant de l'écraser et définir des règles de gestions, mais ce n'est pas possible avec Eleventy. (Donc exit la stratégie de création automatique de redirections.)

Autre limitation, du fait de la logique "descendante"[2] d'Eleventy (commune je pense à tous les générateurs de site), je ne peux pas non plus stocker le résultat d'une règle de gestion dans mes fichiers sources (donc exit la stratégie d'une décorrélation automatique de l'URL et du titre à la création).

Solutions de repli

N'ayant pas très envie de créer tout une usine à gaz pour avoir de la rétroaction sur mes fichiers sources ou pour ajouter une forme d'historisation des modifications, je laisse tomber la possibilité d'une réponse automatisée et foolproof. Pour mes futurs articles, je me contenterais de ces quelques outils manuels :

  • Si je souhaite renommer une page sans changer son URL :
    • J'ai intégré dans le permalink calculé des articles la notion d'alias. Je peux donc simplement copier-coller l'ancien titre de la page dans une propriété alias avant de le modifier pour préserver son URL originale.
    • Dans le pire des cas, je peux toujours aller modifier le permalink d'un article à la main
  • Si j'ai changé une URL de page après l'avoir partagée : je peux toujours aller ajouter un fichier .htaccess avec des instructions de redirection vers son ancienne URL.

  1. Le symbole "croisillon" (ou hash en anglais) est le symbole "#" que nous trouvons sur nos claviers. À ne pas confondre avec le symbole "dièse" (ou sharp en anglais), généralement utilisé en musique et plus dur à obtenir (combinaison de touches complexe sur Windows, via le sélecteur de symbole sur Mac). ↩︎

  2. Je parle de logique "descendante" car Eleventy ne modifie jamais les fichiers "source", ceux en amont. Il se limite par définition à modifier les fichiers dans le dossier de sortie. ↩︎