Format pour le slug des URL

Bonjour,

La question suivante n'est pas d'ordre technique*** mais plutôt une considération architecturale : je me pose la question de concevoir correctement le slug des URL pour les articles d'un CMS.

Déjà, on en est où en 2024 ?

Perso mon côté "dev" me fait préférer ceci (l'ID de l'article, forcément...) :

site.fr/article/423

Mais apparemment, moins pour les moteurs de recherche que pour une URL "conviviale" pour l'utilisateur, il serait mieux d'écrire ceci :

site.fr/article/un-joli-slug-pour-mon-article

Et même, en réalité, il faut supprimer les déterminants :

site.fr/article/joli-slug-pour-article

Sur le plan de la norme, je sais que l'on peut aussi prendre en compte les majuscules, mais... sur ce point je suis hésitant. Un exemple qui me freine : lorsque l'on copie colle une URL dans la fenêtre de recherche Chrome, ce dernier passe tout en lowercase à la validation.
Édit : j'ai dit ici une énormité, apparemment, car je n'ai pas réussi à reproduire ce comportement depuis cette affirmation.

Que pensez-vous de tout cela ?

___
*** Sur le plan technique, je prévois une petite assistance "à la WordPress" (mais en mieux) au moment de la création de l'article. Voici le code isolé : CodePen. Les slugs sont ensuite enregistrés en base de données et constituent les points de terminaison pour l'appel de l'article. Le tout fonctionne très bien.
Modifié par Olivier C (13 Mar 2024 - 22:41)

Salut

Tu as tout résumé correctement sur les bonnes pratiques d'un slug au lieu d'un ID

Oui c'est mieux référencé et en général, il est recommandé d'utiliser des URL en minuscules pour éviter toute confusion et pour des raisons de cohérence

et oui les slugs des URL doivent contenir des mots-clés pertinents

site.fr/article/joli-slug-pour-article

est la meilleur option

+1 pour les diacritiques.
J'avais en tête cette fonctionnalité grâce à un topic récent sur le forum. Voici mon petit code d'assistance à la création du slug :

(function createSlug() {
  const inputName = document.querySelector('#input-name')
  const inputSlug = document.querySelector('#input-slug')
  function slugFormat(inputName, inputSlug) {
    return (inputSlug.value = inputName.value
      .toLowerCase() // .toLocaleLowerCase('fr_FR')
      .replace(/(<([^>]+)>)/gi, '')
      .normalize('NFD')
      .replace(/\p{Diacritic}/gu, '')
      .replace(/[^a-z0-9]/g, '-')
      .replace(/-+/g, '-')
      .trim())
  }
  if (inputName && inputSlug) inputName.addEventListener('input', () => slugFormat(inputName, inputSlug))
})()

Modifié par Olivier C (15 Mar 2024 - 21:44)

Bonjour,

Olivier C a écrit :

T'aimes pas Amazon du coup

Je vois vaguement ce que c'est qu'Amazon, mais je n'ai pas souvenir d'y avoir fait une action quelconque. Et je n'ai vraiment aucune idée de ce que leurs slugs peuvent être !

Amicalement,

Un petit retour sur les slugs : la suppression totale des diacritiques m'a posé problème pour les lettre avec ligature (en français les "æ" et "œ"). Par exemple avec un titre comme celui-ci :

Ælred de Rievaulx, moine de cœur

Qui me donnait :

-lred-de-rievaulx-moine-de-c-ur

J'ai donc modifié ma petite fonction d'assistance en conséquence :

(function createSlug() {
  const inputName = document.querySelector('#input-name.assistance-slug')
  const inputSlug = document.querySelector('#input-slug.assistance-slug')

  function slugFormat(inputName, inputSlug) {
    return (inputSlug.value = inputName.value
      .trim() // @note Facultatif car le titre bénéficie du même traitement.
      .toLowerCase() // .toLocaleLowerCase('fr_FR')
      .replace(/(<([^>]+)>)/gi, '')
      .replace(/æ/g, 'ae')
      .replace(/œ/g, 'oe')
      .normalize('NFD')
      .replace(/\p{Diacritic}/gu, '')
      .replace(/[^a-z0-9]/g, '-')
      .replace(/-+/g, '-')
      .replace(/-$/g, '')) // @note Un tiret peut persister si suppression d'un caractère spécial (par exemple "?") mais pas son séparateur "-", donc suppression de ce tiret.
  }
  if (inputName && inputSlug) inputName.addEventListener('input', () => slugFormat(inputName, inputSlug))
})()

Ce qui donnera :

aelred-de-rievaulx-moine-de-coeur

Mais du coup je me pose la question d'autres potentiels effets de bord... vous en voyez d'autres ?

Et quid de l'esperluette "&" ? Dans un premier jet je la traduirais bien par "et" mais cela rend le script moins portable (lié à une langue, ce qui est déjà le cas de toute façon) ?
Sachant que, comme sous WordPress, je laisse à l'utilisateur le dernier mot par rapport à mon script d'assistance de création du slug. Il est libre de le retoucher comme bon lui semble.
Modifié par Olivier C (25 Mar 2024 - 04:31)

Bonjour,

Olivier C a écrit :

À ce propos je viens de trouver une info intéressante : https://developers.google.com/maps/url-encoding?hl=fr#special-characters.

En gros : rien n'a changé, en tous cas pour les moteurs de recherche.

Oui et non !

Du point de vue de la norme, il faut que les urls soient encodées à un moment ou à un autre. Mais déterminer qui doit faire quoi pose question.

On notera que quand la page est en HTML 5, la rfc 3986 évoquée dans la page de google que tu cites (voir le texte de cette rfc à https://datatracker.ietf.org/doc/html/rfc3986) n'est pas la seule à devoir être considéré car elle ne concerne que les URIs. Or en HTML 5, on peut aussi utiliser des IRIs définies dans la rfc 3987 (voir https://datatracker.ietf.org/doc/html/rfc3987 et en particulier le chapitre 2.1) à la place des URIs (voir aussi la norme concernant les URLs en HTML5 https://www.w3.org/TR/2011/WD-html5-20110405/urls.html et en particulier la ligne "The URL is a valid IRI reference and the character encoding of the URL's Document is UTF-8 or UTF-16. [RFC3987]" qui précise que c'est la rfc 3987 qu'il faut aller voir).

En résumé, on peut (au moins dans certaines parties des urls) utiliser la plupart des caractères unicode puisqu'ils ont été ajoutés à la liste des caractères non réservés lors du passage à HTML 5.

Pour ma part, j'utilise intensivement des caractères asiatiques dans les urls (en particulier dans la partie "query", celle située après le ?), ainsi que nombre de diacritiques pour les transcriptions de ces caractères en lettres latines. Je ne les encode plus dans le cas général dans mon code html, et ça semble ne gêner ni les logiciels et serveurs qui traitent ces urls ni les moteurs de recherche !

Deux choses que je fais quand même, c'est remplacer préventivement les espaces par des + dans les "queries" (parce que je ne veux pas que des %20 ressurgissent par inadvertance). Et j'encode les éventuels caractères réservés (les ?, =, etc.) s'il y en a car c'est (et ça restera encore longtemps) une obligation. Mais je fais tout pour qu'il n'y en ait pas.

Par contre, mes noms de fichiers et de dossiers restent "à l'ancienne", et ne contiennent que les caractères A-Za-z0-9._- dans le cas général.

Certes, derrière, les différents codes informatiques qui traitent les urls vont les encoder/décoder ici et là. Mais en 2024, c'est selon moi devenu transparent pour les humbles développeurs que nous sommes (mis à part les espaces et les caractères réservés).

Ceci étant, on est encore dans les sables mouvants, j'en conviens.

Amicalement,