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)

Et oui, mais la on parle vraiment front.

L'id c'est sur que c'est mieux pour les tech!

Alors les doublons je ne peux pas en avoir car j'ai mis une contrainte UNIQUE sur la colonne "slug" de ma table "article". C'est juste le côté relou où il faut préalablement vérifier côté application pour éviter à l'utilisateur une erreur 23505 lors de la validation (contrainte d'unicité violée) mais bon...

Ceci étant dit, une URL de ce type serait-elle un compromis acceptable ? ou... non, surtout pas ! :

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

Ce serait le beurre et l'argent du beurre en somme... et en même temps ça ferait peut être déjà trop "compromis lié à un CMS"...

Édit : et ce serait aussi la réponse de Matthieuu il me semble.
Modifié par Olivier C (13 Mar 2024 - 15:32)

Salut,
merci d'avoir mis ceci sur le devant. Il semblerait que cette pratique soit très bénéfique pour le SEO. Un article que je viens de consulter :
https://www.semrush.com/blog/what-is-a-url-slug/
Et ça date de décembre 2022, donc c'est récent.
Il en ressort que les - doivent être préféré aux _
Les majuscules sont déconseillées.
Ainsi que les déterminants.
Ainsi que les chiffres, peu parlants (surtout les dates qui évoluent).
Par contre pour un site qui est déjà bien référencé, tout changement d'url devrait pendant quelques temps bénéficier d'une redirection 301 (ils le préconisent sur le lien donné).

Bonjour,

En tant qu'utilisateur, je n'aime pas du tout les url qui font 10 km de long.

Amicalement,

Salut,
moi de même, mais il me semble que ces url slug sont plus faites pour le référencement que pour êtres entrées à la main, non ?
Sur le lien que j'ai donné, ils le précisent bien, pas plus de cinq mots, même moins si possible.

Quand on change une part d'une url sur un site pour adopter une url slug, ne pas oublier de modifier :
- le sitemap
- les liens internes du site.
- les données structurées en LDJSON (ou autres).
- les meta où il y a souvent l'url en question (dans la balise canonical entre autres).

Bonjour,

préférence pour avoir l´ID dans l´URL (et c´est lui qui fait référence) et un slug lisible en plus.
3 trucs que j´ai pu constater :
- «quoteacuteconomiequot» c´est un peu nase comme slug . Mieux vaut nettoyer les caractères non-alphanumériques et penser aux diacritiques : les convertir en aeinouy sans accent ? Ici ce serait «economie»
- éviter qu´une URL comme /IDcorrect/slug-titre-article soit partagée par un troll sous la forme /IDcorrect/insuuuulte et que cette URL reste affichée ainsi... Donc réécrire systématiquement /IDcorrect/blabla en /IDcorrect/slug-titre-article ?
- prévoir le cas où le titre est édité : que faire du slug ? Les contraintes c´est d´éviter la page 404 avec l´ancien slug. Avantage à se fier à l´ID donc
Modifié par Felipe (13 Mar 2024 - 17:04)

+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 :
+1 pour les diacritiques.

On peut quand même se demander en 2024 s'il est si nécessaire que ça d'avoir des urls sans diacritiques.

Amicalement,

Bonjour,

Olivier C a écrit :
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.

Il ne faut pas confondre ce que tu mets dans un champ de saisie de moteur de recherche et ce que tu mets dans la barre d'adresse du navigateur. Et la différence est d'autant plus difficile à faire que les navigateurs utilisent automatiquement la barre d'adresse comme champ de saisie pour une recherche via un moteur de recherche (ce qui m'agace prodigieusement d'ailleurs).

Note qu'en ce qui concerne les URL, elles peuvent avoir des majuscules mais leur traitement dépend du serveur. Par exemple, certains serveurs sont "case sensitive" pour les noms de fichiers, et d'autres pas. Si ton url est un chemin vers un fichier, mettre ou pas des majuscules aura son importance avec certains serveurs et aucune importance avec d'autres serveurs.

Pour ce qui est du champ de saisie des moteurs de recherche, bah, c'est comme d'habitude avec les moteurs de recherche : ingérable a priori !

Amicalement,

parsimonhi a écrit :
En tant qu'utilisateur, je n'aime pas du tout les url qui font 10 km de long.

T'aimes pas Amazon du coup

Merci pour ton message précédent.

Olivier C a écrit :
Alors les doublons je ne peux pas en avoir car j'ai mis une contrainte UNIQUE sur la colonne "slug" de ma table "article". C'est juste le côté relou où il faut préalablement vérifier côté application pour éviter à l'utilisateur une erreur 23505 lors de la validation (contrainte d'unicité violée) mais bon...

Ceci étant dit, une URL de ce type serait-elle un compromis acceptable ? ou... non, surtout pas ! :

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

Ce serait le beurre et l'argent du beurre en somme... et en même temps ça ferait peut être déjà trop "compromis lié à un CMS"...

Édit : et ce serait aussi la réponse de Matthieuu il me semble.

Salut,
ta solution doit convenir aussi je pense, perso je pensais à mettre l'id directement au début du slug avec un tiret :

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

Ce que je disais c'est que l'avantage de mettre l'id dans l'url c'est que tu auras ta contrainte d'unicité sans prendre le chou à l'utilisateur (ou faire un traitement spécifique)
Si tu as plusieurs personnes qui font un article avec le même titre tu auras le même slug :

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

et donc soit ça le signale à l'utilisateur qui doit le gérer, ça c'est à toi de coder un petit truc qui le corrige (généralement va rajouter tout seul un numéro à la fin :

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

)

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,

parsimonhi a écrit :
On peut quand même se demander en 2024 s'il est si nécessaire que ça d'avoir des urls sans diacritiques.

Je précise : des named characters HTML à la é ou des martine écrit en UTF-8. Pas de souci avec les diacritiques tant que c´est bien géré (quoiqu´un traitement radical est de les virer).
Il m´arrive 3 fois par an de recopier une URL m´enfin j´espère être le seul et c´est pas à considérer sérieusement...

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)

parsimonhi a écrit :
On peut quand même se demander en 2024 s'il est si nécessaire que ça d'avoir des urls sans diacritiques.

À 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.
Modifié par Olivier C (25 Mar 2024 - 04:28)

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,