Sensibilité des URL à la casse

TL;DR — /Apple et /apple sont deux chaînes d’URL distinctes, même si un serveur renvoie la même page pour les deux. Les noms d’hôte ne sont pas sensibles à la casse ; le traitement du chemin et de la requête dépend du serveur et de l’application. Des variantes mélangées peuvent créer des parcours d’exploration en double et des règles robots.txt incohérentes : choisissez une convention de casse et appliquez-la partout.

Les URL sont-elles sensibles à la casse ?

Oui, pour la partie située après le domaine. Google l’indique explicitement dans sa documentation : “Be aware that URLs are case sensitive.” (traduction) « Sachez que les URL sont sensibles à la casse. » Ces deux adresses sont donc traitées comme deux URL distinctes :

https://example.com/Apple
https://example.com/apple

Même si elles chargent exactement la même page, un moteur de recherche voit deux URL distinctes, chacune associée à son propre contenu. Voilà tout le problème.

La seule exception est le nom de domaine (le nom d’hôte). Example.com et example.com désignent le même site : les majuscules du domaine n’ont aucune incidence. La casse compte uniquement dans le chemin, le nom de fichier et la chaîne de requête, c’est-à-dire tout ce qui suit le domaine.

Pourquoi cela pose problème

Deux problèmes apparaissent :

1. Contenu dupliqué. Si des internautes, ou votre propre site, créent des liens vers /Apple et /apple, la même page existe à deux adresses. Google peut les regrouper de lui-même, mais rien ne le garantit ; les liens et les signaux de classement risquent alors d’être répartis entre deux versions.
2. Règles robots.txt inopérantes. Si votre robots.txt contient Disallow: /Private/ avec un P majuscule, il ne bloque pas /private/ avec un p minuscule. La règle ne correspond qu’à la casse exacte que vous avez saisie.

Comment corriger le problème

• Choisissez les minuscules. C’est la convention presque universelle et celle qu’utilisent déjà la plupart des plateformes web.
• Faites appliquer cette convention par le serveur : ajoutez une règle qui redirige toute URL contenant des majuscules vers sa version en minuscules. Les onglets Avancé et Scripts fournissent le code pour Apache, Nginx et IIS.
• Conservez vos propres liens en minuscules : menus, contenus et sitemap doivent toujours pointer vers la version en minuscules.

L’erreur la plus fréquente

« Google est suffisamment intelligent pour que cela n’ait pas d’importance. » Google parvient généralement à fusionner les pages identiques qui ne diffèrent que par la casse, mais « généralement » ne signifie pas « toujours ». John Mueller l’a dit sans détour : “hope should not be a part of an SEO strategy.” (traduction) « L’espoir ne doit pas faire partie d’une stratégie SEO. » Ne laissez pas Google deviner.

Vous voulez comprendre le pourquoi — comment le système d’exploitation du serveur décide si /Apple fonctionne ou échoue, le piège complet de robots.txt et les corrections prêtes à copier ? Passez à l’onglet Avancé.

TL;DR — Les noms d’hôte ne sont pas sensibles à la casse ; la comparaison des chemins et des requêtes peut l’être et dépend finalement du routage du serveur et de l’application. Les valeurs par défaut du système de fichiers influencent souvent ce comportement sans définir, à elles seules, la sémantique des URL. Google peut explorer comme des URL distinctes des chemins qui ne diffèrent que par la casse et les canoniser ensemble lorsque le contenu correspond, mais “usually… not always ideal” (traduction) « généralement… pas toujours idéal » ne constitue pas une stratégie. Les valeurs de robots.txt sont elles aussi sensibles à la casse : un Disallow visant une casse ignore les autres. Priorité : empêcher les variantes à la source, puis appliquer une 301 vers les minuscules au niveau du serveur (Apache RewriteMap tolower, Nginx map, IIS URL Rewrite), avec rel=canonical en solution de repli.

Ce qui est sensible à la casse — et ce qui ne l’est pas

Commençons par tracer précisément la frontière, car la formule vague « les URL sont sensibles à la casse » est souvent mal comprise. John Mueller l’a formulée ainsi : “URL path, filename, and query parameters are case-sensitive, the hostname / domain name aren’t. Case-sensitivity matters for canonicalization, so it’s a good idea to be consistent there.” (traduction) « Le chemin, le nom de fichier et les paramètres de requête sont sensibles à la casse ; le nom d’hôte ou de domaine ne l’est pas. La casse compte pour la canonicalisation : mieux vaut donc rester cohérent. »

En résumé :

EXAMPLE.com/page et example.com/page sont la même URL. example.com/Page et example.com/page ne le sont pas. C’est le même problème « une page, plusieurs URL » que celui créé par les slashs finaux, www contre non-www et les paramètres de requête. La casse ajoute simplement un axe à cette grille de doublons.

Ce tableau décrit le comportement par défaut que suivent les moteurs comme Google selon la norme ; il ne garantit pas ce que renverront votre serveur d’origine, votre CDN ou votre application. Utilisez-le comme point de départ : demandez le chemin avec les deux casses et lisez la réponse réelle — l’onglet Scripts propose une commande curl — avant de conclure que la règle s’applique à votre pile.

Autre cas limite à ne pas ignorer : les slugs Unicode. Deux caractères visuellement identiques — par exemple un « a » latin et un « а » cyrillique — peuvent correspondre à des points de code différents qu’une conversion ASCII en minuscules ne modifie pas. Si vos slugs proviennent de titres non anglophones, définissez dès le départ une politique d’encodage et de normalisation au lieu de supposer que .toLowerCase() règle tous les cas internationaux.

Pourquoi cela se produit : le système de fichiers

La plupart des explications répètent que « les URL sont sensibles à la casse » sans aller plus loin. Le pourquoi éclaire pourtant le symptôme le plus déroutant : une même URL fonctionne sur un serveur et renvoie 404 sur un autre.

Les systèmes de fichiers Linux/Unix sont sensibles à la casse. Sur ext4, XFS et les systèmes similaires qui font fonctionner l’essentiel du Web, Apple et apple sont littéralement deux entrées de répertoire, avec deux inodes distincts. Quand Apache ou Nginx associe un chemin demandé à un fichier ou à une route, il compare la casse octet par octet. Demandez /Apple alors que seul /apple existe : vous obtenez une véritable réponse 404.

Windows/NTFS n’est pas sensible à la casse par défaut, mais il la conserve. Il stocke Apple avec sa majuscule, tout en ignorant la casse lors de la recherche du nom. IIS, le serveur web de Microsoft, hérite de ce comportement : /Apple, /APPLE et /apple servent le même fichier. Cela ne corrige pas le problème SEO — Google voit toujours des URL distinctes — mais le serveur renvoie volontiers 200 pour chacune.

Conséquence : le bug classique entre développement et production. Un développeur sous Windows/IIS saisit un chemin avec la mauvaise casse ; tout fonctionne en local, puis la même requête renvoie 404 sur un serveur Linux/Apache/Nginx en production. Ni le CMS ni le plugin SEO n’en sont responsables : les systèmes d’exploitation ne traitent simplement pas la casse de la même façon. Microsoft documente ce comportement dans son guide sur la sensibilité à la casse sous Windows.

Ce point est crucial lors d’une migration de plateforme : en passant d’un hébergement insensible à la casse à un hébergement sensible, des URL à casse mixte qui « ont toujours fonctionné » peuvent soudain casser ou se dupliquer.

Le système de fichiers est le bas de la pile, pas toute la pile. Un reverse proxy, un CDN, un répartiteur de charge ou le routeur de l’application peut normaliser, réécrire ou interrompre la requête avant qu’elle atteigne le disque de l’origine. Une origine Linux ne garantit donc pas que l’URL publique sera sensible à la casse si une couche en amont fusionne déjà les variantes. « Linux + Apache/Nginx = sensible à la casse » est une bonne hypothèse de départ, pas un substitut au test de la réponse réelle de votre pile.

Comment Google traite réellement les différences de casse

Google n’invente pas la sensibilité à la casse : il suit la norme URL appliquée par tout client HTTP conforme. La documentation dit : “Like any other HTTP client following IETF STD 66, Google Search’s URL handling is case sensitive (for example, Google treats both /APPLE and /apple as distinct URLs with their own content).” (traduction) « Comme tout autre client HTTP suivant IETF STD 66, Google Search traite les URL comme sensibles à la casse ; /APPLE et /apple sont deux URL distinctes avec leur propre contenu. » Il s’agit d’un comportement normalisé, pas d’une particularité de Google.

Google recommande de normaliser : “If upper and lower case text in a URL is treated the same by your web server, convert all text to the same case so it’s easier for Google to determine that URLs reference the same page.” (traduction) « Si votre serveur traite de la même manière les majuscules et les minuscules d’une URL, convertissez tout dans une même casse afin que Google identifie plus facilement la même page. » Le « si » vise précisément les serveurs insensibles à la casse, comme IIS, qui servent toutes les variantes et créent ainsi le risque de doublon.

Google peut-il regrouper seul ces doublons ? Souvent oui, par canonicalisation : la casse fait partie des motifs courants qu’il rassemble. Mueller a déclaré : “If a website still shows the same content in these cases, search engines will try to figure it out on their own and usually that works out well. But it’s not always ideal.” (traduction) « Si le site affiche toujours le même contenu, les moteurs essaieront de s’en sortir seuls et cela fonctionne généralement bien, mais pas toujours de façon idéale. » À propos de canoniques incohérentes, il a ajouté : “If it serves the same content, it’ll probably be seen as a duplicate and folded together, but ‘hope’ should not be a part of an SEO strategy.” (traduction) « Si le contenu est identique, il sera probablement regroupé comme doublon, mais l’espoir ne doit pas faire partie d’une stratégie SEO. »

Voilà le cadre honnête : ce n’est pas une urgence absolue, mais inutile de demander à Google de deviner correctement quand une règle de redirection peut lever l’ambiguïté.

L’efficacité de l’exploration en pâtit aussi. Mueller : “Search engines will try to crawl all variations of the URL that they find. This can make it a bit slower for them to find other useful content on your website.” (traduction) « Les moteurs essaieront d’explorer toutes les variantes trouvées, ce qui peut ralentir la découverte d’autres contenus utiles. » Si le graphe de liens diffuse plusieurs casses, les robots réexplorent le même contenu au lieu de découvrir les vraies pages : la casse devient un multiplicateur de gaspillage du budget d’exploration.

Comment Bing traite les URL qui ne diffèrent que par la casse

Bing se comporte différemment, et il importe d’être transparent sur les sources : il n’existe pas de page de documentation Bing consacrée à la sensibilité à la casse des URL qui soit comparable au rappel de la norme STD 66 par Google. Cette section repose donc sur des témoignages de webmasters et des échanges de la communauté Microsoft, et non sur une spécification officielle.

Ces témoignages décrivent de façon récurrente le comportement suivant : Bingbot a tendance à normaliser les URL en minuscules. Il explore et indexe la version en minuscules d’une URL découverte, et Bing Webmaster Tools a été observé convertissant automatiquement en minuscules des URL soumises dans des sitemaps. Des webmasters ont signalé ces deux comportements sur le Microsoft Community Hub. Bing semble donc regrouper davantage les variantes de casse de lui-même que Google, qui traite strictement les différentes casses comme des URL distinctes.

Dans tous les cas, la correction est la même. L’adoption systématique des minuscules respecte le modèle d’URL distinctes de Google et va dans le sens de la normalisation observée chez Bing : vous n’optimisez pas pour un moteur au détriment de l’autre.

Le piège de la casse dans robots.txt

Ce point mérite sa propre section, car il s’agit d’un type de défaillance différent du contenu dupliqué. Le contenu dupliqué répartit les signaux ; une règle robots.txt incorrecte constitue une défaillance du contrôle d’accès : les robots explorent malgré tout un chemin que vous vouliez leur interdire.

La règle est énoncée directement dans la spécification robots.txt de Google : le nom de la directive est insensible à la casse, mais sa valeur y est sensible. “The field name (disallow) is case-insensitive, but its value is case-sensitive.” (traduction) « Le nom du champ disallow est insensible à la casse, mais sa valeur y est sensible. » Et : “The path value must start with / to designate the root and the value is case-sensitive.” (traduction) « La valeur du chemin doit commencer par / pour désigner la racine et elle est sensible à la casse. » L’exemple de Google est explicite : une règle pour /fish “Matches any path that starts with /fish. Note that the matching is case-sensitive.” (traduction) « Correspond à tout chemin commençant par /fish. Notez que la correspondance est sensible à la casse. »

Ainsi, Disallow, disallow et DISALLOW fonctionnent de façon identique : la casse du nom de la directive n’a aucune importance. En revanche, la valeur du chemin doit correspondre exactement. Mueller en a confirmé directement la conséquence : “The robots.txt file also uses exact URLs, so if you have entries there which refer to one version of a URL they would not apply to other versions.” (traduction) « Le fichier robots.txt utilise lui aussi des URL exactes ; une entrée visant une version d’une URL ne s’applique donc pas aux autres versions. »

Deux exemples concrets montrent le problème ; le second est le plus dangereux :

Exemple 1 — le cas classique. Votre robots.txt contient :

User-agent: *
Disallow: /Private/

Cette règle bloque /Private/, mais ne fait rien pour /private/. Si un élément de votre site pointe vers la version en minuscules, celle-ci reste entièrement explorable malgré la règle.

Exemple 2 — le décalage après une migration. Vous changez de plateforme et le nouveau CMS génère les chemins du panier et de l’administration en minuscules. Votre ancien robots.txt, recopié tel quel, contient toujours :

Disallow: /Checkout/
Disallow: /Admin/

Les URL actives sont désormais /checkout/ et /admin/. Les interdictions ne les visent plus, sans produire d’erreur, et des chemins pauvres, sans valeur — voire sensibles — sont explorés et peuvent finir indexés. C’est exactement le piège qui attend les équipes de migration, car la casse réelle des nouvelles URL est rarement comparée à celle des règles robots.txt.

(Pour être clair, ce problème produit rarement des conséquences catastrophiques en pratique : Mueller a indiqué que les décalages de casse dans robots.txt causent rarement de vrais problèmes. Mais un défaut « rare et silencieux » peut justement rester invisible pendant des mois ; une vérification de cinq minutes en vaut la peine.)

La correction repose sur la même discipline qu’ailleurs : écrivez les règles robots.txt avec la casse réellement utilisée par vos URL et imposez une casse unique, afin qu’il n’existe qu’une seule version à bloquer.

Corriger les URL dupliquées par la casse

Voici la hiérarchie habituelle des corrections en SEO technique, de la plus à la moins recommandée :

1. Empêcher la création de variantes à la source

La meilleure solution consiste à ne jamais générer d’URL à casse mixte. Cela relève du CMS ou de la couche qui produit les URL, et le comportement varie selon la plateforme : vérifiez votre propre pile au lieu de vous fier à une affirmation générale.

• Shopify convertit automatiquement en minuscules les handles de produits et de collections. Les URL natives sont donc largement protégées, mais les URL générées par une application ou importées depuis un ancien système peuvent encore introduire des variantes de casse.
• WordPress utilise par convention des permaliens en minuscules, mais les types de contenus personnalisés, les étiquettes et les slugs saisis manuellement peuvent introduire une casse mixte ; Yoast et RankMath n’imposent pas nativement les minuscules dans les URL.
• Les plateformes d’entreprise, sur mesure ou fondées sur Java/.NET sont les plus exposées. La casse dépend souvent du framework de routage et du système d’exploitation de l’hébergement, sans politique explicite, surtout sur les piles Windows/IIS où rien n’impose localement une casse donnée.

2. Redirection vers les minuscules au niveau du serveur — la correction définitive

Une redirection 301 vers l’URL canonique en minuscules constitue la correction ferme : elle consolide les signaux et envoie utilisateurs et robots vers une seule adresse. La mise en œuvre dépend du serveur ; des configurations complètes à adapter figurent dans l’onglet Scripts.

• Apache dispose d’un outil natif de conversion en minuscules : RewriteMap avec int:tolower. Une règle de réécriture peut ainsi convertir un chemin entier.
• Nginx ne possède aucune fonction intégrée de conversion d’une chaîne en minuscules. La solution est réellement plus complexe que la règle unique d’Apache : il faut employer le module njs ou Lua pour convertir l’URI, ou construire une table map explicite qui détecte les majuscules. Une simple règle map équivalente à celle d’Apache n’existe pas.
• IIS utilise le module URL Rewrite, une condition de règle et la fonction {ToLower:...}. Comme IIS sert toutes les variantes de casse par défaut, c’est sur ce serveur que l’application de la règle est la plus importante.

Ne déployez pas à l’aveugle une règle générale sur tout le site. Les minuscules sont la bonne convention pour les nouveaux chemins, mais rediriger automatiquement toute casse mixte sur un site existant n’est pas toujours sûr. Commencez par inventorier les variantes réelles — export d’exploration, journaux d’accès, sitemap et liens internes — puis recherchez les chemins dont la casse est légitime et indispensable : noms de fichiers téléversés, jetons générés ou toute valeur produite volontairement avec une casse mixte par un CMS ou une application. Vérifiez que chaque route renvoie réellement un contenu équivalent dans les deux casses avant de l’intégrer à la règle. Déployez la redirection sur un périmètre limité plutôt que de modifier tous les chemins d’un coup, puis surveillez le taux d’erreurs et le rapport d’indexation des pages dans GSC. Rien ne garantit qu’un nettoyage des casses récupérera les positions ou la couverture d’exploration perdues ; il empêchera seulement une nouvelle répartition des signaux.

3. rel=canonical comme solution de repli

Lorsque vous ne pouvez pas modifier la configuration du serveur — hébergement mutualisé, plateforme qui interdit les règles de réécriture ou variantes de casse légitimes qui doivent rester accessibles — un rel=canonical pointant chaque variante vers la version en minuscules sert de filet de sécurité. Il s’agit d’un indice, pas d’une directive, moins fort qu’une 301, mais nettement préférable à l’absence de mesure. Mueller recommande : “Using internal linking to link to a consistent version makes your preference clear. Adding a link rel=“canonical” element also helps to confirm that.” (traduction) « Des liens internes vers une version cohérente rendent votre préférence claire. L’ajout d’un élément link rel=“canonical” contribue aussi à la confirmer. »

Cela dit, la canonical ne fonctionne qu’après confirmation que les variantes servent réellement un contenu dupliqué. Si une variante renvoie un contenu véritablement différent ou une erreur, un élément rel=canonical ne peut pas les fusionner : un indice ne transforme pas deux ressources distinctes en une seule. Vérifiez la réponse avant de désigner une URL canonique, pas après.

4. Harmoniser les liens internes et les sitemaps

Quelle que soit la casse choisie, vos propres liens doivent la respecter. Chaque lien interne, entrée de navigation et URL de sitemap doit utiliser la version canonique en minuscules. Même parfaite, une règle de redirection est affaiblie si les menus pointent encore vers /Products/ : elle impose simplement aux robots un détour inutile.

Comment trouver les URL dupliquées par la casse sur votre site

Trois méthodes complémentaires : GSC montre ce que Google a réellement fait, tandis que les robots d’exploration permettent de repérer les variantes avant qu’elles ne deviennent un problème d’indexation.

• Google Search Console → rapport d’indexation des pages. Recherchez les états “Duplicate without user-selected canonical” et “Duplicate, Google chose different canonical than user”, puis examinez les paires d’URL signalées pour repérer les différences de casse. GSC n’indique pas « casse » comme cause : toutes les formes de duplication sont signalées de la même manière. Vous devez donc identifier vous-même les paires qui ne diffèrent que par la casse.
• Ahrefs Site Audit. Une exploration fait ressortir les URL presque identiques. Les différences de casse apparaissent comme des URL explorées séparément, avec un contenu identique ou quasi identique ; recoupez-les avec le rapport sur le contenu dupliqué.
• Screaming Frog. Exportez l’exploration complète, convertissez la colonne des URL en minuscules, puis triez ou filtrez pour trouver les paires qui ne diffèrent que par la casse. Vous pouvez aussi tester des chemins connus dans les deux casses afin de confirmer le comportement du serveur : /Apple renvoie-t-il 200, 301 ou 404 ? Ce test indique si le serveur est insensible à la casse — 200, comme IIS —, impose déjà les minuscules — 301 — ou est sensible à la casse sans variante — 404.

Place de ce problème dans l’ensemble

La sensibilité à la casse est l’un des axes du problème plus large des URL dupliquées. Elle se combine aux slashs finaux, à www contre l’absence de www et aux paramètres de requête ; elle fait partie des quelque 40 signaux qui alimentent la canonicalisation. Le guide sur la structure des URL, les analyses consacrées au slash final et aux paramètres d’URL, ainsi que l’article sur la canonicalisation couvrent chacun leur propre axe. La discipline reste identique : choisir une version propre et l’imposer au moyen de redirections, de canonicals, de liens internes cohérents et de sitemaps concordants.

Résumé IA

Version condensée du contenu avancé :

• Éléments sensibles à la casse : le chemin, le nom de fichier et la chaîne de requête, mais pas le nom d’hôte. /Apple ≠ /apple, tandis que Example.com = example.com. Google suit IETF STD 66 et traite donc les variantes de casse comme des URL distinctes avec leur propre contenu. Cette règle est une valeur par défaut à vérifier, pas une garantie : demandez les deux variantes et examinez la réponse réelle de votre pile. Les slugs non ASCII présentent un autre risque : des caractères Unicode visuellement identiques peuvent correspondre à des points de code différents que la conversion en minuscules ne modifie pas. Les slugs internationaux exigent donc une politique explicite d’encodage et de normalisation.
• Origine du problème — le système de fichiers : Linux/Unix, ainsi qu’Apache et Nginx sur ces systèmes, sont sensibles à la casse : Apple et apple sont des fichiers différents. Windows/NTFS et IIS sont insensibles à la casse par défaut, tout en la préservant. Une même requête peut donc renvoyer 200 sur IIS et 404 sous Linux : c’est le décalage classique entre développement et production ou lors d’une migration. Le système de fichiers n’est toutefois que la couche inférieure : un proxy, un CDN, un équilibreur de charge ou le routeur d’une application peut remplacer ce comportement avant même que la requête ne l’atteigne.
• Google peut regrouper les doublons de casse par canonicalisation, mais le résultat est “usually… not always ideal” (traduction) « généralement… pas toujours idéal ». Et “hope should not be a part of an SEO strategy.” (traduction) « l’espoir ne doit pas faire partie d’une stratégie SEO. » L’efficacité de l’exploration en souffre aussi : les robots gaspillent des requêtes à parcourir chaque variante.
• Bing semble normaliser vers les minuscules — exploration et indexation de la version en minuscules, conversion automatique des URL de sitemap — d’après des témoignages de webmasters, pas une spécification officielle.
• Piège de robots.txt — une défaillance d’accès, pas un doublon : le nom de la directive est insensible à la casse, mais la valeur du chemin y est sensible. Disallow: /Private/ ne bloque pas /private/. Méfiez-vous des décalages après migration, comme une règle /Checkout/ face à des chemins actifs en minuscules.
• Ordre des corrections : (1) empêcher les variantes à la source ou dans le CMS ; (2) appliquer une 301 vers les minuscules au niveau du serveur — Apache avec RewriteMap int:tolower, Nginx avec njs, Lua ou une table map puisqu’il ne sait pas convertir nativement en minuscules, en conservant la chaîne de requête avec $is_args$args, car la fonction njs ne convertit que le chemin, et IIS URL Rewrite avec {ToLower:...} ; (3) employer rel=canonical comme solution de repli après avoir confirmé que la variante sert bien un contenu dupliqué ; (4) harmoniser les liens internes et les sitemaps. Avant une redirection générale, inventoriez les chemins dont la casse est légitime — fichiers téléversés, jetons — et déployez la règle sur un périmètre limité. Aucune récupération de positions ou de couverture d’exploration n’est garantie ; la règle empêche seulement de répartir les signaux à l’avenir.
• Détection : rapport d’indexation des pages de GSC — examinez les paires associées aux états de duplication —, Ahrefs Site Audit et Screaming Frog — convertissez l’export en minuscules, triez-le et testez /Apple pour 200/301/404.
• Effets combinés : slash final, www/non-www et paramètres. Même correction : choisir une version et l’imposer.

Documentation officielle

Documentation de première main sur le traitement de la casse.

Google

• Bonnes pratiques relatives à la structure des URL — “Be aware that URLs are case sensitive” (traduction) « Sachez que les URL sont sensibles à la casse » ; le cadre IETF STD 66 avec /APPLE et /apple ; et la recommandation d’adopter une casse unique.
• Interprétation de la spécification robots.txt par Google — le nom de la directive est insensible à la casse, mais la valeur du chemin y est sensible ; exemple de correspondance sensible à la casse avec /fish.
• Canonicalisation — la casse figure parmi les cas courants d’URL dupliquées, avec HTTP/HTTPS, www, le slash final et les paramètres.
• Rapport d’indexation des pages — Aide Search Console — les états “Duplicate without user-selected canonical” et “Duplicate, Google chose different canonical than user” qui permettent de repérer les doublons de casse.

Bing / Microsoft

• Conversion des URL de majuscules en minuscules par Bing — Microsoft Community Hub — témoignages de webmasters sur la normalisation en minuscules de Bing ; il s’agit d’éléments communautaires, pas d’une spécification officielle.
• Régler la sensibilité à la casse — Microsoft Learn — comportement de Windows/NTFS, insensible à la casse tout en la préservant, à l’origine de la différence entre IIS et Linux.

Citations des sources

Déclarations publiques tirées de la documentation de Google et de John Mueller. Lorsque la source est une documentation, le lien pointe directement vers le passage.

Documentation Google Search Central — les URL sont sensibles à la casse

• “Be aware that URLs are case sensitive.” (traduction) « Sachez que les URL sont sensibles à la casse. » Accéder à la citation
• “Like any other HTTP client following IETF STD 66, Google Search’s URL handling is case sensitive (for example, Google treats both /APPLE and /apple as distinct URLs with their own content).” (traduction) « Comme tout autre client HTTP suivant IETF STD 66, Google Search traite les URL en tenant compte de la casse ; par exemple, /APPLE et /apple sont des URL distinctes avec leur propre contenu. » Accéder à la citation
• “If upper and lower case text in a URL is treated the same by your web server, convert all text to the same case so it’s easier for Google to determine that URLs reference the same page.” (traduction) « Si votre serveur traite de la même manière les majuscules et les minuscules d’une URL, convertissez tout dans une même casse afin que Google identifie plus facilement la même page. » Accéder à la citation

Documentation Google Search Central — robots.txt est sensible à la casse

• “The field name (disallow) is case-insensitive, but its value is case-sensitive.” (traduction) « Le nom du champ (disallow) est insensible à la casse, mais sa valeur y est sensible. » Accéder à la citation
• “The path value must start with / to designate the root and the value is case-sensitive.” (traduction) « La valeur du chemin doit commencer par / pour désigner la racine et elle est sensible à la casse. » Accéder à la citation
• “Matches any path that starts with /fish. Note that the matching is case-sensitive.” (traduction) « Correspond à chaque chemin dont le début est /fish ; la comparaison tient compte de la casse. » Accéder à la citation

John Mueller, Google — ce qui est sensible à la casse et ce qui ne l’est pas

• “URL path, filename, and query parameters are case-sensitive, the hostname / domain name aren’t. Case-sensitivity matters for canonicalization, so it’s a good idea to be consistent there.” (traduction) « La casse distingue le chemin, le nom de fichier et les paramètres de requête, mais pas le nom d’hôte ni le domaine. Une forme cohérente facilite donc la canonicalisation. » Article de Search Engine Journal

John Mueller, Google — ne pas compter sur Google pour tout résoudre

• “If it serves the same content, it’ll probably be seen as a duplicate and folded together, but ‘hope’ should not be a part of an SEO strategy.” (traduction) « Si le contenu est identique, il sera probablement considéré comme un doublon et regroupé, mais l’espoir ne doit pas faire partie d’une stratégie SEO. » Article de Search Engine Journal
• “If a website still shows the same content in these cases, search engines will try to figure it out on their own and usually that works out well. But it’s not always ideal.” (traduction) « Si le site affiche toujours le même contenu dans ces cas, les moteurs essaieront de s’en sortir seuls et cela fonctionne généralement bien. Mais ce n’est pas toujours idéal. » Article de Search Engine Journal

John Mueller, Google — robots.txt et efficacité de l’exploration

• “The robots.txt file also uses exact URLs, so if you have entries there which refer to one version of a URL they would not apply to other versions.” (traduction) « Le fichier robots.txt utilise lui aussi des URL exactes ; une entrée visant une version d’une URL ne s’applique donc pas aux autres versions. » Article de Search Engine Journal
• “Search engines will try to crawl all variations of the URL that they find. This can make it a bit slower for them to find other useful content on your website.” (traduction) « Les moteurs essaieront d’explorer toutes les variantes trouvées, ce qui peut ralentir la découverte d’autres contenus utiles sur votre site. » Article de Search Engine Journal
• “Using internal linking to link to a consistent version makes your preference clear. Adding a link rel=“canonical” element also helps to confirm that.” (traduction) « Des liens internes cohérents rendent la version préférée explicite. Ajouter un élément link rel=“canonical” vient également confirmer ce choix. » Article de Search Engine Journal

Liste de contrôle de la sensibilité à la casse des URL

Un contrôle rapide pour repérer et éliminer le risque de doublons dus à la casse :

• Choisir une convention de casse unique — les minuscules, sauf raison impérative de faire autrement.
• Tester un chemin connu dans les deux casses (/Apple et /apple) : la version en majuscules renvoie-t-elle une 301 vers les minuscules, ou un 200/404 ? Toute réponse autre qu’une 301 révèle une lacune.
• Connaître le système d’exploitation et le serveur d’hébergement : Linux avec Apache/Nginx est sensible à la casse — les liens à casse mixte peuvent renvoyer 404 — ; Windows avec IIS ne l’est pas — toutes les casses renvoient 200, avec un risque de doublons.
• Avant de déployer une redirection générale vers les minuscules, inventorier les chemins existants dont la casse est légitime — fichiers téléversés, jetons, slugs générés — et confirmer qu’ils sont exclus ou testés comme équivalents, sans simplement les présumer sûrs.
• Mettre en place la redirection vers les minuscules au niveau du serveur — Apache RewriteMap, Nginx map/njs ou IIS URL Rewrite — et, avec Nginx, conserver la chaîne de requête d’origine ($is_args$args) au lieu de la supprimer.
• Faire correspondre dans robots.txt chaque valeur Disallow/Allow à la casse réelle des URL actives ; aucune règle /Private/ ne doit être censée protéger un chemin /private/.
• Utiliser la casse canonique en minuscules dans tous les liens internes, éléments de navigation et menus.
• Ne répertorier dans le sitemap XML que les URL ayant la casse canonique.
• Faire pointer rel=canonical de chaque variante accessible vers la version en minuscules, comme filet de sécurité lorsque la redirection est impossible.
• Examiner les états de duplication dans le rapport d’indexation des pages de GSC, puis vérifier visuellement si les paires signalées ne diffèrent que par la casse.
• Après une migration, réexaminer robots.txt, les canonicals et les liens internes en fonction de la casse produite par la nouvelle plateforme.

Sensibilité à la casse des URL — aide-mémoire

Éléments sensibles à la casse

Comportement du serveur selon la plateforme

Il s’agit de valeurs par défaut du système d’exploitation et du serveur, pas de garanties : un proxy inverse, un CDN ou le routeur d’une application placé devant l’origine peut les remplacer. Testez la réponse réelle de votre pile.

Le piège de robots.txt

La casse du nom de la directive (Disallow / disallow) ne compte pas ; celle de la valeur du chemin compte.

Ordre de priorité des corrections

1. Empêcher les variantes à la source ou dans le CMS.
2. Appliquer une 301 → minuscules au niveau du serveur — correction définitive.
3. Définir rel=canonical → minuscules — solution de repli, car il s’agit d’un indice.
4. Harmoniser les liens internes et le sitemap.

Diagnostic en une ligne : demandez /Apple ; une 301 vers /apple signifie que la règle est en place. Un 200 — IIS — ou un 404 — Linux sans variante — signifie qu’elle ne l’est pas.

Imposer les URL en minuscules — configuration du serveur

Points de départ prêts à copier et à adapter pour chaque serveur. Testez-les sur votre propre pile avant le déploiement : la disponibilité de mod_rewrite, les modules installés et l’ordre des règles varient selon l’hôte. Une règle trop large peut créer une boucle ou convertir en minuscules des éléments qui doivent conserver leur casse, comme certaines valeurs de requête.

Apache (.htaccess / hôte virtuel) — l’approche native avec tolower

Apache propose une table de conversion en minuscules intégrée. Définissez-la une fois dans la configuration principale du serveur — RewriteMap ne peut pas figurer dans .htaccess — puis utilisez-la dans une règle :

# In httpd.conf / vhost config (NOT .htaccess):
RewriteMap lc int:tolower

# In .htaccess or vhost:
RewriteEngine On
# Only act when the path actually contains an uppercase letter
RewriteCond %{REQUEST_URI} [A-Z]
# Redirect the whole path to its lowercase form
RewriteRule (.*) ${lc:$1} [R=301,L]

int:tolower est la fonction interne d’Apache qui convertit le chemin capturé en minuscules. La condition RewriteCond %{REQUEST_URI} [A-Z] limite l’exécution de la règle aux chemins qui contiennent une majuscule et évite de rediriger les URL déjà en minuscules.

Nginx — aucune conversion native en minuscules

La directive map du cœur de Nginx ne peut pas convertir seule une chaîne en minuscules. Il n’existe donc pas d’équivalent direct à la règle unique d’Apache. Deux options sont réellement disponibles :

Option A — njs ou Lua, la méthode propre. Avec le module njs, convertissez l’URI en minuscules en JavaScript, puis redirigez-la :

# Load the njs module and a small JS file that lowercases the URI path
js_import lower from conf.d/lower.js;
js_set $lower_uri lower.uri;

server {
    # ...
    # Test $uri (path only), NOT $request_uri (path + query) — the njs
    # function below only lowercases the path, so the query string is
    # intentionally left untouched. Testing $request_uri would fire on an
    # uppercase-containing query even when the path is already lowercase.
    if ($uri ~ [A-Z]) {
        # $is_args$args re-attaches the original query string. Without it,
        # the redirect drops any query string entirely, since $lower_uri
        # (built from r.uri, which excludes the query) never contains one.
        return 301 $scheme://$host$lower_uri$is_args$args;
    }
}

// conf.d/lower.js
function uri(r) { return r.uri.toLowerCase(); }
export default { uri };

Deux détails sont faciles à manquer et peuvent invalider silencieusement la correction. Une correspondance sur $request_uri plutôt que sur $uri déclenche la règle si la chaîne de requête contient une majuscule, même lorsque le chemin est déjà en minuscules. Oublier $is_args$args dans la destination supprime toute la chaîne de requête à chaque redirection — jetons, paramètres de filtre, etc. — puisque la fonction njs ne voit et ne convertit que le chemin. Avant le déploiement, testez un chemin assorti d’une chaîne de requête à casse mixte.

Option B — une table de correspondance map explicite, si vous ne pouvez pas ajouter de module. Construisez une table qui détecte uniquement les URI contenant des majuscules qui vous intéressent. Cette solution est longue et partielle, d’où la préférence pour l’option A :

map $request_uri $has_upper {
    default        0;
    "~[A-Z]"       1;   # flag URIs containing any uppercase letter
}
# You still need njs/Lua or per-path rewrites to do the actual lowercasing —
# map alone flags, it doesn't transform. Don't ship this as a complete fix.

Conclusion : sur Nginx, prévoyez la solution njs ou Lua. Affirmer qu’une simple règle map convertit les URL en minuscules revient à ignorer que map ne sait pas transformer les chaînes.

IIS (Windows) — module URL Rewrite

Comme IIS sert toutes les variantes de casse par défaut, c’est ici que l’application de la règle est la plus importante. Le module URL Rewrite fournit une fonction {ToLower:...} :

<!-- web.config -->
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Lowercase URLs" stopProcessing="true">
          <match url="[A-Z]" ignoreCase="false" />
          <conditions>
            <add input="{URL}" pattern="[A-Z]" ignoreCase="false" />
          </conditions>
          <action type="Redirect" url="{ToLower:{R:0}}" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

ignoreCase="false" dans la correspondance permet à la règle de détecter les majuscules ; {ToLower:{R:0}} réécrit le chemin correspondant en minuscules ; redirectType="Permanent" produit la 301.

Vérifier le résultat

Après le déploiement, confirmez la redirection avec une seule requête sous macOS ou Linux :

# Should show: HTTP/… 301 and a Location header pointing to the lowercase path
curl -sI https://example.com/Apple | grep -Ei "^HTTP|^location"

Windows (PowerShell):

# -MaximumRedirection 0 stops the redirect so you can read the 301 + Location
try { Invoke-WebRequest "https://example.com/Apple" -MaximumRedirection 0 } catch {
  $_.Exception.Response.StatusCode.value__
  $_.Exception.Response.Headers["Location"]
}

Une 301 vers l’URL en minuscules signifie que la règle est active. Un 200 signifie que le serveur sert encore la version en majuscules ; un 404 signifie qu’aucune page n’existe sous cette casse et que l’hébergement est probablement sensible à la casse, sans couche de redirection.

Anti-modèles liés à la sensibilité à la casse

Les erreurs qui transforment un détail de configuration anodin en véritable problème de contenu dupliqué ou d’exploration :

1. Supposer que Google regroupera toujours les doublons de casse. Il le fait souvent, mais « généralement » ne signifie pas « toujours ». La formule de Mueller — “hope should not be a part of an SEO strategy” (traduction) « l’espoir ne doit pas faire partie d’une stratégie SEO » — le rappelle. Laisser la canonicalisation tout résoudre répartit les signaux lorsque Google se trompe.

2. Écrire les règles robots.txt dans une casse différente de celle des URL actives. Une règle Disallow: /Private/ censée protéger /private/ ne fait rien, sans le signaler. La casse du nom de la directive est sans importance ; celle de la valeur du chemin est exacte. C’est un défaut de contrôle d’accès, pas un problème de classement.

3. Recopier robots.txt tel quel après une migration. La nouvelle plateforme génère /checkout/ et /admin/, tandis que l’ancien robots.txt interdit encore /Checkout/ et /Admin/. Tout ce qui devait être bloqué devient explorable. Après chaque migration, réexaminez robots.txt selon la casse des nouvelles URL.

4. Corriger la redirection, mais pas les liens internes. Une règle parfaite imposant les minuscules est affaiblie si les menus et les contenus pointent encore vers /Products/ : robots et utilisateurs subissent un détour de redirection supplémentaire à chaque fois. La redirection est le filet de sécurité ; des liens cohérents constituent la vraie correction.

5. Considérer rel=canonical comme l’équivalent d’une 301. La canonical est un indice ; une 301 est une directive. N’employez la canonical que lorsque vous ne pouvez réellement pas ajouter de redirection, pas simplement parce qu’elle est plus facile à mettre en place.

6. Croire qu’une plateforme moderne règle automatiquement le problème. Shopify convertit bien ses handles natifs en minuscules, mais les URL importées, héritées ou générées par une application, ainsi que toute pile Windows/IIS, restent exposées. « Acheter un CMS moderne et ne plus y penser » n’est pas une politique.

7. Penser que les minuscules constituent une préférence de classement. Google n’a jamais affirmé que les URL en minuscules étaient mieux classées. Le problème concerne la consolidation du contenu dupliqué et l’efficacité de l’exploration, pas un signal de classement fondé sur la casse. Les minuscules sont une convention, adoptée par défaut par la plupart des CMS, pas un facteur de classement. C’est le même type de mythe que « les URL plus courtes sont mieux classées ».

8. Employer des règles de réécriture trop larges qui convertissent les valeurs de requête. La conversion aveugle de toute l’URI de requête peut altérer les valeurs de paramètres sensibles à la casse — jetons, base64, signatures. Limitez la redirection au chemin et laissez les chaînes de requête intactes, sauf si leur conversion est assurément sans danger.

Problèmes courants liés à la casse des URL

Les URL à casse mixte et en minuscules renvoient toutes deux 200

Symptôme : /Products/Blue-Shoe et /products/blue-shoe chargent la même page. Cause probable : l’application ou l’hôte résout les chemins sans tenir compte de la casse et n’applique aucune redirection de normalisation. Correction : choisissez le format établi, généralement en minuscules, redirigez les variantes en un seul saut et harmonisez les liens internes, les canonicals et les sitemaps.

Une URL fonctionne en préproduction, mais renvoie 404 en production

Symptôme : un chemin à casse mixte fonctionne dans un environnement et échoue dans un autre. Cause probable : les hôtes appliquent des règles différentes de sensibilité à la casse, souvent entre Windows et les systèmes fondés sur Linux. Correction : modifiez le lien source pour qu’il reprenne exactement la casse de la route et ajoutez des tests de déploiement qui demandent littéralement le chemin de production.

Une règle robots ne bloque pas le chemin attendu

Symptôme : un robot peut récupérer /private/ alors que robots.txt interdit /Private/. Cause probable : la correspondance des chemins pour les robots est sensible à la casse. Correction : reprenez exactement la casse de l’URL ou normalisez les chemins avant de vous fier à une règle unique, puis retestez la combinaison réelle du robot et de l’URL.

Examiner les paires d’URL à casse mixte

Collez dans cette invite un export d’exploration comprenant l’URL, l’état, l’URL finale, la canonical, les liens entrants, la source du sitemap et les signaux organiques :

Group URLs that differ only by path or query-string case. For each group, identify
the strongest candidate preferred URL using only the supplied evidence. Flag
conflicting redirects, canonicals, internal links, sitemap entries, and robots rules.
Return an implementation table with preferred URL, alternate URL, redirect action,
source links to update, and unresolved evidence. Do not assume lowercase wins when
the data shows an established mixed-case canonical.

Outils de normalisation de la casse

• Redirect Chain Mapper — comparer les variantes de casse et vérifier si elles atteignent directement la forme préférée ou accumulent des sauts supplémentaires.
• Canonicalization Checker — repérer les contradictions entre la réponse, l’élément canonical et la destination finale d’une variante d’URL.
• robots.txt Tester — tester exactement les chemins en majuscules et en minuscules pour le robot concerné, puisque la correspondance des chemins est sensible à la casse.
• Un robot d’exploration de tout le site — regrouper les URL sans tenir compte de la casse pour trouver les variantes, puis utiliser les rapports de liens entrants afin de corriger les modèles et les contenus qui continuent de les générer.

Vérifier la redirection vers la casse préférée

Test à exécuter : demandez l’URL préférée et plusieurs variantes de casse avec le Redirect Chain Mapper. Résultat attendu : l’URL préférée renvoie une réponse correcte et chaque variante la rejoint par une redirection permanente en un seul saut. Interprétation d’un échec : la règle est incomplète, mal ordonnée ou incompatible avec la route de l’application. Période de suivi : immédiatement après le déploiement. Déclencheur d’un retour arrière : des routes valides entrent dans une boucle, redirigent vers la mauvaise page ou renvoient des erreurs.

Vérifier les URL émises et le contrôle de l’exploration

Test à exécuter : explorez les liens internes et les sitemaps, puis testez des chemins représentatifs dans le robots.txt Tester. Résultat attendu : les modèles, les canonicals et les sitemaps n’émettent que la casse préférée, et les règles robots se comportent comme prévu pour les URL exactes exposées par le site. Interprétation d’un échec : un système source génère encore des variantes ou une règle robots emploie la mauvaise casse. Période de suivi : après une exploration complète suivant la mise en production. Déclencheur d’un retour arrière : des URL préférées importantes sont bloquées ou un vaste nouvel ensemble de variantes apparaît.

Testez vos connaissances : sensibilité à la casse des URL

Cinq questions rapides sur le fonctionnement réel de la sensibilité à la casse et sa correction. Choisissez une réponse pour chacune, puis vérifiez-la.

Ressources utiles

Mes articles connexes

• Google utilise environ 40 signaux de canonicalisation — mon analyse de la façon dont Google choisit une URL représentative ; les variantes de casse (/page/ et /Page/) figurent parmi les modèles d’URL dupliquées, soit précisément le problème corrigé ici.
• Slash final : faut-il l’utiliser ? — un axe voisin de la canonicalisation : la même discipline, « choisir une version et l’imposer », appliquée au slash plutôt qu’à la casse.
• Paramètres d’URL : guide complet pour le SEO — l’autre grand multiplicateur d’URL dupliquées, et la raison pour laquelle les paramètres passifs gaspillent le budget d’exploration comme les variantes de casse parasites.
• Redirections pour le SEO : guide simple et complet — le fonctionnement des 301 qui sous-tend l’application des minuscules au niveau du serveur.
• Guide du débutant sur le SEO technique — la place de l’hygiène des URL dans l’ensemble du SEO technique.

Mes interventions

• Résoudre les problèmes de SEO technique (SlideShare, Raleigh SEO Meetup) — les problèmes d’URL dupliquées et de canonicalisation replacés dans leur contexte. Réserve habituelle : il s’agit de ma compréhension de ces systèmes, pas d’une spécification officielle.

Dans le reste du secteur

• Bonnes pratiques relatives à la structure des URL (Google Search Central) — source de la règle “URLs are case sensitive” (traduction) « les URL sont sensibles à la casse » et d’IETF STD 66.
• Interprétation de la spécification robots.txt par Google (Google Search Central) — source de la règle robots.txt “value is case-sensitive” (traduction) « la valeur est sensible à la casse ».
• Google : les URL sont sensibles à la casse (Search Engine Journal) — source secondaire de référence pour les citations de Mueller sur la casse, robots.txt, le ralentissement de l’exploration et la recommandation relative aux canonicals.
• Conseil de Google sur les canonicals : elles sont sensibles à la casse (Search Engine Journal) — échange contenant “hope should not be a part of an SEO strategy” (traduction) « l’espoir ne doit pas faire partie d’une stratégie SEO ».
• Sensibilité à la casse des URL et SEO (Practical Ecommerce) — concurrent direct le plus proche, particulièrement utile sur le symptôme 404 en e-commerce.
• Régler la sensibilité à la casse (Microsoft Learn) — explication du modèle Windows/NTFS qui conserve la casse sans l’utiliser pour comparer les chemins, ce qui éclaire l’écart entre IIS et Linux.
• Conversion des URL de majuscules en minuscules par Bing (Microsoft Community Hub) — témoignages de webmasters sur la normalisation en minuscules de Bing ; éléments communautaires, pas une spécification officielle.

Journal des modifications