URL Slugs qui se classent bien : créer des URLs SEO-friendly à chaque fois

Je construis des sites web depuis longtemps, et l'une des sources les plus constantes de dommages SEO silencieux et invisibles que je constate sont les mauvais URL slugs. Pas des canonicals incorrects. Pas des meta descriptions manquantes. Juste de mauvais slugs — des URLs qui ont été soit auto-générées par un CMS sans réflexion, soit tapées manuellement par quelqu'un pressé qui n'avait jamais entendu parler du percent-encoding.

La bonne nouvelle, c'est que les slugs sont faciles à réussir. Une fois que vous comprenez les règles, vous n'y penserez plus jamais à deux fois. Et si vous voulez tout simplement éviter d'y penser, notre convertisseur texte en slug fera le travail à votre place.

Mais comprendre pourquoi ces règles existent vaut quelques minutes de votre temps. Laissez-moi vous guider.

Qu'est-ce exactement qu'un URL slug ?

Un slug est la partie lisible par l'humain d'une URL qui identifie une page spécifique. Dans cette URL :

https://example.com/blog/how-to-bake-sourdough-bread

Le slug est how-to-bake-sourdough-bread.

Le terme vient de l'industrie des journaux, où un "slug" était un nom court donné à un article en cours — un identifiant interne avant que le titre ne soit finalisé. Les développeurs web ont emprunté ce terme à l'époque des premiers CMS et il est resté.

Les slugs servent deux objectifs simultanément : ils indiquent aux humains de quoi parle une page avant qu'ils ne cliquent, et ils indiquent aux moteurs de recherche quels mots sont pertinents pour le contenu de la page. Réussissez un slug et vous faites les deux à la fois. Ratez-le et vous travaillez contre vous-même sur les deux fronts.

Pourquoi les slugs comptent vraiment pour le SEO

Voici quelque chose que beaucoup de gens ratent : ils traitent la structure des URLs comme un facteur SEO mineur et la relèguent en bas de la liste des priorités. Et bien qu'il soit vrai que la qualité du contenu et les backlinks comptent davantage, les URL slugs sont l'un des rares signaux de classement qui ne coûtent rien à corriger sur une nouvelle page.

Google lit votre URL slug comme un signal sur ce que couvre la page. Si votre page parle des "meilleures chaussures de randonnée pour pieds larges" et que votre slug est best-hiking-boots-for-wide-feet, vous renforcez ce mot-clé à un endroit de plus. Si votre slug est product-2847-v3, vous jetez cette opportunité par la fenêtre.

Plus concrètement : les URLs apparaissent dans les résultats de recherche. Elles sont affichées sous le titre de votre page dans l'extrait SERP. Un slug propre et lisible rend votre résultat plus digne de confiance et pertinent. Un slug plein de tirets, de chiffres aléatoires et d'IDs de session produit l'effet inverse.

Les liens partagés sur les réseaux sociaux, dans les emails et dans les messages Slack sont souvent affichés en texte brut. Comparez :

• example.com/p?id=4821&ref=sidebar — suspect, ressemble à du spam de tracking
• example.com/blog/best-hiking-boots-wide-feet — vous dit immédiatement ce que vous obtenez

Le deuxième obtient plus de clics. Plus de clics pour les mêmes impressions signifie un meilleur taux de clics, que Google utilise comme signal de classement.

Le débat tiret vs. underscore (enfin tranché)

Cet argument dure depuis le début des années 2000 et je le vois encore surgir dans des canaux Slack et des posts de forums. Permettez-moi de le clore ici.

Utilisez des tirets. Toujours. Dans les URLs.

Voici la position officielle de Google : les tirets dans les URLs sont traités comme des séparateurs de mots. Si votre slug est best-hiking-boots, Google le lit comme trois mots séparés : "best", "hiking", "boots". Votre page sera éligible pour se classer dans les recherches impliquant l'un de ces mots.

Les underscores ne sont pas traités de la même façon. best_hiking_boots est traité par Google comme un seul token : best_hiking_boots. Votre page ne se classera pas pour "hiking boots" en tant que phrase — seulement pour la chaîne connectée par underscore que presque personne ne recherche.

Ce n'était pas une rumeur d'un forum SEO. Matt Cutts de Google l'a abordé explicitement dans une vidéo Webmaster il y a des années, et John Mueller l'a confirmé depuis. La recommandation officielle de Google est : utilisez des tirets comme séparateurs de mots dans les URLs.

Quand les underscores conviennent (juste pas dans les URLs)

Les underscores ont leur place — juste pas dans les chemins d'URLs :

• Noms de fichiers dans le code : user_profile_image.png, config_loader.py
• Noms de variables Python : PEP 8 dit snake_case pour les variables et fonctions
• Noms de colonnes de base de données : created_at, user_id, order_total
• Variables d'environnement : DATABASE_URL, API_SECRET_KEY

Dans ces contextes, les underscores sont idiomatiques et corrects. Mais dès que vous construisez une URL, passez aux tirets.

Erreurs courantes de slugs (j'ai fait toutes ces erreurs)

1. Laisser des caractères spéciaux

Quelqu'un écrit un article intitulé What's the Best Framework for 2026? et le CMS plante soit, soit génère un slug comme what%27s-the-best-framework-for-2026%3F. L'apostrophe devient %27, le point d'interrogation devient %3F.

Ces URLs percent-encodées fonctionnent techniquement, mais elles ont l'air atroces quand elles sont collées en texte brut. Elles sont aussi traitées de façon incohérente par différents serveurs, CDNs et reverse proxies. Supprimez-les simplement.

Bonne règle : ne gardez que des lettres minuscules, des chiffres et des tirets dans vos slugs. Tout le reste est supprimé ou translittéré.

2. Laisser les caractères accentués tels quels

Un site en langue française pourrait avoir un article intitulé "Café au lait : histoire et préparation". Un générateur de slug naïf pourrait produire café-au-lait-histoire-et-préparation.

Le é dans ce slug sera percent-encodé dans l'URL réelle : caf%C3%A9-au-lait-histoire-et-pr%C3%A9paration. C'est un désordre. Une meilleure approche est de translittérer les caractères accentués en leurs équivalents ASCII d'abord : cafe-au-lait-histoire-et-preparation.

Oui, les puristes diront que les caractères accentués sont maintenant techniquement valides dans les IRIs (Internationalized Resource Identifiers). Ils ont raison. Mais la réalité pratique est que les URLs avec des caractères multi-octets percent-encodés se cassent dans les clients email, ont l'air mauvaises dans les partages sociaux et peuvent parfois être altérées par le copier-coller. Pour les URLs publiques, les slugs ASCII purs sont plus sûrs et plus propres.

3. Majuscules dans les slugs

/Blog/How-To-Bake-Sourdough-Bread et /blog/how-to-bake-sourdough-bread sont techniquement deux URLs différentes. La plupart des serveurs sont sensibles à la casse sur le composant de chemin. Vous pouvez vous retrouver avec des problèmes de contenu dupliqué et une division du link equity si les deux versions sont accessibles.

Toujours en minuscules. Pas d'exceptions.

4. Tirets consécutifs ou tirets en début/fin

how--to-bake--sourdough (double tirets lors de la suppression de caractères) ou -how-to-bake-sourdough- (tirets en début/fin lors de la suppression de caractères spéciaux en début/fin). Ceux-ci ne cassent rien techniquement, mais ils ont l'air négligés et certains validateurs les signalent.

Un bon générateur de slugs réduit plusieurs tirets consécutifs en un seul et supprime les tirets au début et à la fin du résultat.

5. Les mots vides consomment le budget de caractères

the-best-way-to-bake-sourdough-bread-at-home vs bake-sourdough-bread-home.

La deuxième version est plus courte, cible les termes clés et se lit bien. "the", "best", "way", "to", "at" sont des mots vides — ils ajoutent de la longueur sans ajouter de valeur SEO. Vous n'avez pas besoin de supprimer tous les mots vides, mais soyez délibéré concernant la longueur des slugs.

Cela dit, personnellement je ne stresse pas pour chaque mot vide. Parfois ils rendent le slug plus lisible. how-to-bake-sourdough se lit plus naturellement que bake-sourdough. Utilisez votre jugement.

Bons slugs vs. mauvais slugs : exemples réels

Voici ce que ça donne en pratique :

Sujet de la page	Mauvais slug	Bon slug
Article de blog sur le pain au levain	post-1293-v2	sourdough-bread-beginners-guide
Page produit pour chaussures de course	product?id=8821&cat=shoes	mens-running-shoes-lightweight
Page de documentation	Docs_API_Reference_v3	api-reference
Page d'événement	event_for_2026-03-25_conference	2026-developer-conference
Article café français	caf%C3%A9-au-lait-recipe	cafe-au-lait-recipe
Article question	what%27s-new-in-react-2026%3F	whats-new-react-2026

Remarquez que les bons slugs sont cohérents : minuscules, tirets seulement, pas de caractères spéciaux, courts mais descriptifs. Ils n'ont pas besoin d'être parfaitement concis — sourdough-bread-beginners-guide convient — mais ils doivent clairement décrire le contenu de la page.

Longueur des slugs : quelle longueur est trop longue ?

Il n'y a pas de limite stricte, mais il y a quelques directives pratiques.

Google affiche généralement les URLs dans les résultats de recherche tronquées autour de 70-80 caractères. Si votre slug fait 120 caractères, l'URL affichée dans les résultats de recherche sera coupée. Ce n'est pas catastrophique, mais c'est légèrement moins lisible.

Plus important : les longs slugs indiquent souvent que vous incluez des mots vides ou des termes redondants dont vous n'avez pas besoin. Si votre titre est "Le guide définitif complet et total pour comprendre et utiliser les URL slugs dans le développement web moderne en 2026", votre slug ne devrait pas être toute cette phrase. Quelque chose comme url-slug-guide-web-development couvre les mots-clés pertinents en une fraction de la longueur.

Objectif approximatif : essayez de garder les slugs sous 70 caractères. Sous 50 est encore mieux. Sous 30 est idéal pour les pages à fort trafic que vous voulez faciles à retenir et à taper.

Que se passe-t-il quand vous changez un slug après publication ?

C'est là que beaucoup de gens font des erreurs coûteuses. Vous publiez un article de blog avec le slug how-to-build-react-app, il accumule des backlinks, est partagé, monte dans les classements. Puis six mois plus tard vous décidez de le renommer react-app-tutorial-beginners. Vous changez le slug et... l'ancienne URL commence à renvoyer des 404.

Chaque lien entrant pointant vers l'ancienne URL atteint maintenant une page morte. Chaque classement de recherche construit sur cette URL est perdu. Le link equity que vous avez mis des mois à gagner s'évapore.

Vous devez mettre en place une redirection 301 de l'ancienne URL vers la nouvelle. Une 301 est une redirection permanente — elle indique aux navigateurs et aux moteurs de recherche que la page a définitivement déménagé, et transmet la plupart du link equity et des signaux de classement vers la nouvelle URL.

En pratique : la plupart des CMS ont une gestion des redirections intégrée (ou via plugins). Dans Next.js, vous gérez cela dans next.config.js. Dans nginx, c'est une directive rewrite. Dans Apache, c'est un Redirect ou RewriteRule dans .htaccess.

Si vous êtes sur WordPress, le plugin Redirection est le chemin le plus simple. Assurez-vous de définir des redirections 301, pas des redirections 302 (temporaires).

En résumé : si une page a des backlinks ou du trafic organique, traitez un changement de slug comme une opération significative qui nécessite un travail de redirection. Ne mettez pas juste à jour le slug et appelez ça terminé.

Comment générer des slugs par programmation

Si vous construisez un CMS ou une plateforme de contenu, vous voudrez auto-générer des slugs à partir des titres d'articles. Voici la logique centrale en JavaScript :

function toSlug(text) {
  return text
    .toLowerCase()
    .normalize('NFD')                    // Décomposer les caractères accentués
    .replace(/[\u0300-\u036f]/g, '')     // Supprimer les marques d'accent
    .replace(/[^a-z0-9\s-]/g, '')        // Supprimer les caractères spéciaux restants
    .trim()
    .replace(/\s+/g, '-')               // Remplacer les espaces par des tirets
    .replace(/-+/g, '-');               // Réduire les tirets multiples
}

Quelques points à noter sur cette implémentation :

• normalize('NFD') suivi de la suppression des caractères de combinaison gère proprement la plupart des lettres accentuées européennes. café devient cafe, naïve devient naive, résumé devient resume.
• Cela ne gère pas tous les scripts. Cyrillique, chinois, japonais, arabe — ceux-ci nécessitent des bibliothèques de translittération plutôt qu'une simple suppression d'accents. Si votre contenu est multilingue, regardez les packages npm transliteration ou slug qui gèrent mieux cela.
• Cela ne supprime pas les mots vides. Je recommande de gérer cela séparément avec une liste explicite si vous voulez ce comportement, plutôt que de l'intégrer dans la fonction slug centrale.

Ou vous pouvez sauter complètement l'écriture de ceci et utiliser notre convertisseur texte en slug, qui gère les caractères accentués, les symboles spéciaux, les espaces multiples et tous les cas limites.

SEO au-delà du slug

Les slugs sont une pièce du puzzle de la structure des URLs, mais quelques points connexes valent la peine d'être mentionnés :

La profondeur des URLs compte. Une URL comme example.com/blog/seo/2026/03/how-to-write-slugs est profondément imbriquée et signale que la page est une sous-sous-sous-catégorie. Les structures plus plates comme example.com/blog/how-to-write-slugs fonctionnent généralement mieux.

La cohérence au sein d'un site compte. Si certains de vos articles utilisent des URLs basées sur la date (/2026/03/25/post-title) et d'autres non, cette incohérence n'est pas une pénalité de classement — mais elle rend la gestion des URLs plus complexe. Choisissez un modèle et restez-y.

Ne bourrez pas de mots-clés. Un slug comme best-seo-slug-url-slug-generator-seo-2026 semble spam. Les politiques anti-spam de Google mentionnent explicitement le keyword stuffing dans les URLs. Un ou deux mots-clés principaux, décrivez le contenu avec précision, arrêtez-vous là.

Le flux de travail pratique

Quand j'écris un article ou crée une nouvelle page, mon flux de travail pour les slugs est :

1. Écrire le titre
2. Réfléchir à ce que quelqu'un taperait dans Google pour trouver cette page
3. Construire le slug à partir des mots-clés principaux de l'étape 2, pas mécaniquement à partir du titre
4. Vérifier : minuscules ? Seulement des tirets ? Pas de caractères spéciaux ? Moins de 60 caractères ? Descriptif sans bourrage ?
5. Définir, publier et laisser tranquille

La partie "laisser tranquille" est importante. Résistez à l'envie de modifier les slugs après publication à moins d'avoir une très bonne raison. Le coût SEO des changements d'URL est réel.

Pour convertir rapidement n'importe quel titre en slug propre, mettez en favori le convertisseur texte en slug — il gère tous les cas limites et produit un résultat prêt à copier instantanément.

---

Questions fréquemment posées

Qu'est-ce qu'un URL slug ?

Un URL slug est la partie d'une adresse web qui vient après le nom de domaine, identifiant une page spécifique. Par exemple, dans example.com/blog/how-to-bake-bread, le slug est how-to-bake-bread. Les bons slugs sont en minuscules, utilisent des tirets comme séparateurs de mots et décrivent le contenu de la page de façon concise.

Faut-il utiliser des tirets ou des underscores dans les URLs ?

Utilisez des tirets. Google traite les tirets comme des séparateurs de mots, ce qui signifie qu'un slug comme best-hiking-boots est lu comme trois mots séparés. Les underscores ne reçoivent pas ce traitement — best_hiking_boots est analysé comme un seul token. Cela affecte directement la façon dont votre page se classe pour les requêtes de recherche à plusieurs mots, donc le choix compte.

Quelle doit être la longueur d'un URL slug ?

Gardez les slugs sous 70 caractères si possible. Les slugs plus courts sont plus faciles à partager, à retenir et obtiennent souvent de meilleures performances dans les résultats de recherche. L'objectif pratique est d'inclure vos mots-clés principaux et de supprimer les mots de remplissage comme "le", "un", "et". La plupart des bons slugs finissent entre 20 et 50 caractères.

Puis-je changer un URL slug après publication ?

Vous pouvez, mais cela nécessite de mettre en place des redirections 301 de l'ancienne URL vers la nouvelle. Sans redirections, vous perdrez tous les backlinks et classements de recherche accumulés pour l'ancienne URL. Traitez les changements de slugs sur des pages établies comme une opération SEO délibérée, pas une modification rapide.

Les caractères accentués comme é ou ñ fonctionnent-ils dans les URLs ?

Techniquement oui — les navigateurs modernes les encodent automatiquement — mais en pratique il vaut mieux les supprimer ou les convertir. Le caractère é devient %C3%A9 dans une URL brute, ce qui est terrible dans les emails et partages sociaux et peut être altéré par les anciens systèmes. La conversion en équivalents ASCII simples (e, n) est plus propre et plus sûre.