Structure d’URL : les principes d’une URL favorable au SEO

Qu’est-ce que la structure d’URL

La structure d’URL désigne l’ensemble des règles qui définissent la forme des adresses des pages d’un site : longueur, hiérarchie des dossiers, format des slugs, usage des paramètres et protocole. Une bonne structure est lisible par un humain, compréhensible par un crawler et reste stable pendant des années. Une mauvaise structure crée des doublons, perturbe l’indexation et oblige à réécrire les redirections à chaque changement de stratégie marketing.

L’URL est l’un des rares signaux SEO que Google présente officiellement comme un facteur de classement depuis plus de quinze ans. Ce n’est pas le plus puissant, mais c’est l’un des moins coûteux : vous la configurez une fois pendant le développement, et elle fonctionne des années sans modification. Les erreurs à ce niveau sont pénibles à corriger : chaque URL modifiée exige une redirection 301 et une nouvelle évaluation par le moteur de recherche.

Les URL en chiffres

Anatomie d’une URL : sept parties

Avant de construire une structure, décomposons ce qu’est une URL. La RFC 3986 décrit sept composants ; dans un contexte SEO, tous comptent, sauf user-info et le fragment :

https://www.example.com:443/blog/seo/url-structure/?utm=email#summary
│  │   │            │   │                          │            │
│  │   │            │   │                          │            └─ fragment (anchor)
│  │   │            │   │                          └────────────── query (GET parameters)
│  │   │            │   └─────────────────────────────────────── path
│  │   │            └─────────────────────────────────────────── port (usually hidden)
│  │   └──────────────────────────────────────────────────────── host (domain)
│  └──────────────────────────────────────────────────────────── subdomain
└─────────────────────────────────────────────────────────────── scheme (protocol)

Pourquoi l’URL compte pour le SEO

Les URL influencent le classement de façon directe et indirecte. La contribution directe est faible : Google a confirmé à plusieurs reprises qu’un mot-clé dans l’URL ne donne qu’un coup de pouce « minime ». L’impact indirect est bien plus important : l’URL conditionne le taux de clic sur les snippets, la confiance des utilisateurs et la prévisibilité pour les crawlers.

Ces signaux se cumulent. Pris isolément, chacun est faible ; combinés, ils font des URL un avantage discret et durable, en particulier pour la longue traîne, où chaque point de CTR compte.

Neuf règles d’une bonne URL

Les recommandations de Google sur les URL ont peu changé en quinze ans. Les neuf règles ci-dessous compilent la documentation officielle et les études empiriques de Backlinko, Ahrefs et Moz. Elles s’appliquent à toutes les technologies, de WordPress à Next.js.

• Utilisez des caractères latins (sauf si votre audience est exclusivement locale). Le cyrillique fonctionne techniquement via le punycode, mais il se copie mal dans les messageries, se dégrade à l’impression et réduit le CTR dans les résultats internationaux. /blog/url-structure/ est préférable à une adresse équivalente en cyrillique.
• Séparez les mots par des tirets, pas par des tirets bas. Google recommande explicitement les tirets. Les tirets bas _ fusionnent les mots lors de l’analyse : url_structure est, pour le robot, un seul jeton url_structure et non deux mots.
• Minuscules uniquement. Les URL sont techniquement sensibles à la casse (sur les serveurs UNIX). /Page/ et /page/ sont deux adresses différentes, donc des doublons. Imposez les minuscules au niveau du serveur.
• Longueur : plus court qu’il ne semble nécessaire. L’optimum se situe entre 50 et 75 caractères. Si l’URL est plus longue, c’est généralement qu’il y a des mots superflus dans le slug ou des catégories redondantes.
• Profondeur des dossiers : trois niveaux maximum. /category/subcategory/page/ est le plafond pour la plupart des sites. Le crawler atteint moins souvent les pages profondes, et les utilisateurs s’y perdent.
• Pas de mots vides. Retirez du slug les mots comme « et », « ou », « le » ou « un » : /comment-corriger-erreur/ est préférable à /comment-corriger-une-erreur-dans-le-code/. Les mots vides n’améliorent ni le classement ni la lisibilité.
• Mot-clé : une seule fois, et tôt. Ne répétez pas le mot-clé (/seo/seo-guide/). Placez-le le plus près possible du domaine : plus il est proche de la racine, plus son poids est élevé.
• Pas d’identifiants ni de hash dans le slug. /article-12384/ ou /post-a3f9b2c8/ ne disent rien à un humain et n’apportent aucune sémantique. Utilisez des slugs descriptifs qui traduisent le sujet.
• L’URL ne doit pas changer. Une adresse publiée est un engagement. Tout changement exige une redirection 301 et fait perdre une partie de la popularité transmise. Réfléchissez à la structure en amont.

Profondeur et hiérarchie des dossiers

La structure en dossiers d’une URL n’est pas qu’esthétique : c’est un plan du site pour le crawler comme pour l’utilisateur. La profondeur de clic (le nombre de clics entre la page d’accueil et une page) est liée à la fréquence à laquelle Google crawle de nouveau une page et à la rapidité avec laquelle il découvre les nouveaux contenus.

La profondeur d’URL n’est pas la profondeur de clic. Une page peut physiquement se trouver à /shop/laptops/macbook-pro-14/ et rester à un clic de la page d’accueil grâce à un maillage interne solide. Le moteur prend en compte les deux signaux : le chemin de l’URL et la distance réelle dans le graphe des liens.

www, HTTPS, slash final et casse

Quatre réglages techniques produisent le plus souvent des doublons. Chacun se règle une fois au niveau du serveur, mais si vous le négligez, le moteur de recherche peut voir jusqu’à huit versions de la même page :

http://example.com/page
http://example.com/page/
https://example.com/page
https://example.com/page/
http://www.example.com/page
http://www.example.com/page/
https://www.example.com/page
https://www.example.com/page/

HTTPS

Obligatoire depuis 2018 : Chrome signale les sites en HTTP comme « non sécurisés », et Google utilise HTTPS comme signal de classement faible. La mise en place tient en une seule redirection dans nginx ou Apache :

# nginx — 301 from HTTP to HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

www ou sans www

Techniquement équivalents. Au niveau DNS, www est un sous-domaine, mais Google et Yandex le traitent comme un alias lorsqu’une redirection 301 est configurée. Sans www, l’adresse est un peu plus courte et plus moderne ; avec www, la gestion des cookies est plus commode, car vous pouvez les séparer par sous-domaine. La règle essentielle : choisissez une variante et redirigez tout le trafic vers elle en 301.

# nginx — 301 from www to non-www
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Slash final

Un slash final (/page/ et /page) désigne deux adresses distinctes pour le serveur. Convention : les répertoires se terminent par /, les fichiers non. Sur les sites modernes, chaque page est traitée comme un répertoire : adoptez donc une stratégie unique, avec ou sans slash final. Next.js et WordPress utilisent le slash final par défaut.

// next.config.ts — enforced trailing slash
const nextConfig = {
  trailingSlash: true,  // /blog/page/  instead of  /blog/page
};
export default nextConfig;

Casse

Les URL sont sensibles à la casse sur la plupart des serveurs (Linux et UNIX). /Page/ et /page/ sont deux URL, donc deux doublons. Forcez l’ensemble du chemin en minuscules au niveau du reverse proxy ou de l’application :

# nginx — redirect URLs to lowercase (Lua module)
location ~ [A-Z] {
    rewrite ^/(.*)$ /$1 last;
    set_by_lua_block $lower_uri {
        return ngx.var.uri:lower()
    }
    return 301 $lower_uri;
}

Modèles d’URL par type de page

Chaque type de contenu appelle un modèle d’URL spécifique. Voici des schémas éprouvés pour six types de pages, présents sur 90 % des sites.

Pour le e-commerce, c’est un sujet à part. Une fiche produit peut suivre deux schémas : /shop/category/product/ (avec la catégorie) ou /shop/product/ (à plat). Le premier sert mieux le SEO des catégories, car l’URL signale l’appartenance ; le second facilite le déplacement de produits d’une catégorie à l’autre sans redirection. Le choix dépend de la fréquence à laquelle les produits changent de catégorie.

Localisation et URL multilingues

Pour un site multilingue, les URL font partie de la stratégie. Google recommande trois approches, chacune avec ses compromis :

Les sous-dossiers l’emportent dans 80 % des cas. Ils sont plus simples à gérer, moins coûteux en certificats SSL et en hébergement, et toute la popularité transmise profite à un seul domaine. C’est exactement l’approche de seohead.tech : la langue principale à la racine, la seconde sous /en/.

Les slugs des URL localisées font débat. Traduire le slug (/en/url-structure/ ↔ /struktura-url/) améliore le CTR dans chaque langue et signale la pertinence avec plus de précision. L’inconvénient : la maintenance se complique, et il faut gérer hreflang et les redirections lorsque les traductions changent. Pour la plupart des projets, le compromis consiste à ne traduire que les slugs des articles de blog et à garder un slug unique pour les pages techniques.

Erreurs courantes et comment les corriger

Huit erreurs d’URL parmi les plus fréquentes relevées lors des audits SEO. Chacune se corrige en un sprint ; laisser faire coûte une perte progressive de positions et de budget de crawl.

• Doublons via les paramètres GET. Les balises UTM, les tris et les filtres créent des centaines de variantes d’une même page. Correction : rel="[canonical](/glossary/canonical)" vers l’URL principale, et gestion des paramètres d’URL dans la GSC.
• Slash final incohérent. Certaines pages se terminent par /, d’autres non. Le moteur voit des doublons. Correction : une convention unique et une redirection 301 depuis toutes les variantes non conformes.
• Cyrillique dans les URL d’un projet international. Un slug en cyrillique devient /%D1%83%D1%81%D0%BB%D1%83%D0%B3%D0%B8/. Correction : translittération (/uslugi/).
• Hiérarchie trop profonde. /shop/electronics/computers/laptops/apple/macbook-pro/ compte six niveaux. Correction : une structure plate, avec les catégories en facettes.
• Identifiants dans l’URL au lieu d’un slug. /article?id=12384 ou /post/12384/. Correction : passer à des URL sémantiques et rediriger en 301 les anciens identifiants.
• Changement d’URL sans 301. Tout changement d’adresse sans redirection entraîne une perte de popularité et de trafic. Correction : mettez toujours en place une 301 lors d’un renommage.
• Casse dans les URL. /Catalog/ et /catalog/ sont deux doublons. Correction : imposez les minuscules côté serveur.
• Chaînes de redirections interminables. A → B → C → D. Chaque étape fait perdre de la popularité. Correction : redirigez toujours en 301 directement vers l’URL finale.

# Check redirect chains via curl:
curl -sILo /dev/null -w "%{http_code} %{url_effective}\n" \
     -L https://example.com/old-page/

# Find URLs with uppercase letters in nginx logs:
grep -E 'GET /[a-z]*[A-Z]' /var/log/nginx/access.log | head

# URL audit via Screaming Frog:
# 1. Run a full site crawl
# 2. Open the URL tab → Underscores / Uppercase / Non ASCII Characters
# 3. Export the list of problematic URLs and plan redirects

FAQ

Réponses aux questions les plus fréquentes sur la structure des URL, posées lors des audits et des refontes.

Synthèse

La structure d’URL est une décision que l’on prend une fois et qu’on assume pendant des années. Une bonne URL est courte, lisible, reflète la hiérarchie du contenu et reste stable dans le temps. Trois principes essentiels (minuscules latines, tirets plutôt que tirets bas, trois niveaux de dossiers au maximum) règlent 80 % des erreurs courantes.

Commencez par un audit des URL existantes. Dans Screaming Frog, ouvrez les rapports « Underscores », « Uppercase » et « Non ASCII Characters » : vous obtenez une cartographie des problèmes en moins d’une heure. Construisez ensuite un tableau old → new, mettez en place les 301 et mettez à jour les liens internes. Ne précipitez pas une migration massive avant la haute saison : Google met de 4 à 8 semaines à réévaluer les pages.