Tirets vs underscores dans les URLs : pourquoi Google préfère-t-il l'un à l'autre ?

Pourquoi Google ne segmente-t-il pas les underscores ?

Le problème vient de l'usage historique de l'underscore dans la programmation et les noms de variables. Dans de nombreux langages, l'underscore fait partie intégrante du nom — supprimer ou segmenter au niveau de ce caractère casserait littéralement le terme.

Google a donc calibré son segmenteur pour traiter l'underscore comme un caractère alphanumérique classique, pas comme un délimiteur. Le tiret, en revanche, est reconnu comme séparateur naturel entre mots — exactement comme un espace.

Quelles parties de l'URL Google analyse-t-il exactement ?

Gary Illyes parle du "segmenteur" qui utilise "certaines parties de l'URL" — formulation volontairement floue. Dans la pratique, Google examine principalement le slug (la partie après le dernier slash) et potentiellement les segments de sous-dossiers.

L'URL devient un signal de pertinence parmi d'autres. Pas décisif, mais pas négligeable non plus — surtout quand le reste des signaux est équilibré entre plusieurs pages candidates.

Cette recommandation s'applique-t-elle à tous les types de sites ?

En théorie oui, mais l'impact varie énormément. Sur un e-commerce avec des milliers d'URLs générées dynamiquement, refactoriser toute l'architecture pour remplacer des underscores existants peut provoquer plus de dégâts qu'apporter de bénéfices.

Sur un nouveau projet ou un site en refonte, en revanche — aucune excuse pour ne pas appliquer cette règle dès le départ.

• Tirets = séparateurs de mots reconnus par Google
• Underscores = traités comme caractères alphanumériques, pas de segmentation
• Impact principal sur le slug et les segments d'URL
• Recommandation applicable surtout aux nouveaux projets
• Sur sites existants, évaluer le coût/bénéfice d'une migration massive

Cette déclaration est-elle cohérente avec les observations terrain ?

Complètement. Les tests empiriques confirment que Google dissocie effectivement les termes séparés par tirets, tandis que les underscores produisent un token unique. C'est mesurable dans les SERPs pour des requêtes multi-termes.

Par contre — et c'est crucial — l'impact réel sur le classement reste marginal dans la majorité des cas. On parle d'un micro-signal parmi des centaines. Un bon contenu, une autorité solide et des backlinks pertinents écrasent largement cette différence technique.

Quand cette règle devient-elle vraiment problématique ?

Deux scénarios où ça coince sérieusement : les sites multilingues avec slugs traduits, et les plateformes e-commerce avec SKUs ou identifiants techniques dans l'URL. Si vos URLs contiennent des références produits comme "REF_12345_BLUE", Google ne segmentera rien.

Autre cas limite : les CMS legacy ou frameworks imposant des conventions de nommage avec underscores. Migrer peut nécessiter rewrites serveur lourds ou modifications profondes du code — avec risques de régression.

Faut-il vraiment tout refaire si votre site utilise des underscores ?

Soyons honnêtes : probablement pas. Sauf si vous êtes dans un secteur ultra-concurrentiel où chaque micro-optimisation compte, le ROI d'une migration massive est discutable.

En revanche, deux règles simples : pour toute nouvelle page ou section, utilisez des tirets systématiquement. Et si vous refondez complètement le site, profitez-en pour normaliser — mais pas de migration juste pour ce motif isolé.

Que faut-il faire concrètement sur un nouveau projet ?

Configuration en amont. Imposez la convention tirets uniquement dans vos templates, règles de génération d'URLs, et guidelines éditoriales. La plupart des CMS modernes (WordPress, Shopify, Drupal) gèrent ça nativement.

Si vous développez custom : paramétrez votre router ou générateur de slugs pour remplacer automatiquement espaces et caractères spéciaux par des tirets, jamais des underscores. Testez avec des caractères accentués, des apostrophes — le diable est dans les edge cases.

Comment auditer un site existant pour repérer les underscores ?

Crawlez avec Screaming Frog, Oncrawl ou Botify. Filtrez les URLs contenant "_" et évaluez leur poids SEO : trafic organique actuel, positions, backlinks. Priorisez les pages stratégiques si vous décidez de migrer.

Vérifiez aussi les patterns de génération automatique — pagination, filtres, catégories. Un underscore caché dans un paramètre ou un segment de facette peut se multiplier sur des milliers d'URLs.

Quelles erreurs éviter lors d'une migration ?

Ne migrez jamais sans plan de redirections exhaustif. Chaque ancienne URL avec underscore doit pointer vers sa version tirets via 301 permanente. Testez en preprod, vérifiez les chaînes de redirections (jamais plus d'un saut).

Deuxième piège : oublier les canonical tags et sitemaps. Après migration, mettez à jour votre sitemap XML, resoumettez via Search Console, et surveillez l'indexation pendant 4-6 semaines minimum.

• Configurer le CMS ou le générateur d'URLs pour utiliser des tirets par défaut
• Crawler le site existant pour identifier toutes les URLs avec underscores
• Évaluer le poids SEO de chaque URL concernée (trafic, positions, backlinks)
• Prioriser les pages stratégiques si migration partielle
• Créer un mapping complet anciennes URLs → nouvelles URLs
• Implémenter des redirections 301 permanentes (jamais 302)
• Mettre à jour sitemap XML et canonical tags
• Surveiller indexation et positions dans Search Console post-migration
• Documenter la convention pour futures évolutions du site