Comment structurer les URLs pour un meilleur crawling

Une cliente m'a appelé un jour, paniquée. Search Console venait de lui remonter 42 000 pages "Explorées, actuellement non indexées" sur un site qui n'en comptait que 800. Le crawler de Google tournait en rond. Pas un bug de serveur, pas un problème de contenu : la structure d'URL. Son développeur avait laissé passer un paramètre de tri sur les pages catégories, et chaque combinaison créait une adresse théorique différente. 42 000 portes d'entrée pour 800 pièces.

C'est l'erreur la plus coûteuse que je croise, et paradoxalement la plus simple à corriger. Bien structurer les URLs pour le crawling, ça n'a rien de magique. C'est de l'hygiène. Mais quand cette hygiène manque, tout le reste — maillage, contenu, netlinking — travaille contre vous.

Pourquoi la structure des URLs dicte le travail du crawler

Googlebot ne voit pas votre site comme un humain. Il ne clique pas, il ne "comprend" pas le design. Il suit des liens, enregistre des adresses, et décide lesquelles méritent d'être revisitées. Chaque adresse qu'il découvre entre dans une file d'attente. Cette file a un budget.

Le budget de crawl, ce n'est pas une légende. C'est le nombre de requêtes que Google juge raisonnable d'envoyer à votre serveur sur une période donnée. Plus votre site génère d'URLs inutiles, plus ce budget se dilue.

Ce que le crawler lit vraiment dans une URL

Trois choses, dans l'ordre :

• Le chemin, qui donne une idée de la hiérarchie du contenu.
• Les paramètres (tout ce qui suit le ?), qui sont souvent du bruit.
• Le protocole et le domaine, qui déterminent à quel site appartient la ressource.

Un chemin clair comme votresite.fr/guides/crawling-structure-url se lit d'un coup d'œil. Un chemin comme votresite.fr/index.php?id=8871&cat=42&sort=asc ne dit rien, sinon qu'il faut aller chercher une base de données pour comprendre. Et surtout — c'est le point qu'on oublie — chaque variation de ces paramètres crée une URL distincte aux yeux du crawler.

Le mythe des URLs courtes à tout prix

Franchement, la longueur exacte, on s'en fiche un peu. J'ai vu des URLs de 90 caractères bien indexées et des URLs de 15 caractères ignorées. Ce qui compte, c'est la lisibilité sémantique et l'absence de redondance. Une URL longue mais descriptive battra toujours une URL courte mais cryptique.

Le vrai critère, c'est : un humain qui lit cette adresse devine-t-il ce qu'il va y trouver ? Si oui, vous êtes probablement dans le bon.

Les critères techniques que le crawler vérifie

Il y a un angle que je n'ai jamais vu traité correctement, alors je le pose ici. Beaucoup d'articles listent "URL courte, mots-clés, tirets". Personne ne parle des seuils concrets. Voici ce que j'applique sur mes propres projets, après pas mal de tests.

Casse, encodage et caractères spéciaux

Le serveur qui héberge votre site est probablement sous Linux. Et sous Linux, /Guides/ et /guides/ sont deux dossiers différents. Si votre CMS génère les liens en minuscules mais que des liens externes pointent vers la version majuscule, vous venez de créer un doublon sans le savoir.

Ma règle : tout en minuscules, tirets comme séparateurs, jamais d'underscores. Le tiret, Google le lit comme un espace ; l'underscore, il le lit comme un caractère collé. Et pour l'encodage, évitez les accents et caractères spéciaux dans l'URL elle-même. Préférez /developpement-web à /développement-web.

Profondeur des dossiers

Là aussi, pas de règle gravée dans le marbre, mais une intuition solide : au-delà de trois niveaux de dossiers, le crawl se complique. Pas parce que Google pénalise, mais parce que la page devient difficile à atteindre depuis la page d'accueil, donc moins de liens internes la pointent, donc elle est crawlée moins souvent.

Structure	Profondeur	Effet observé sur le crawl
site.fr/categorie/produit	2 niveaux	Découverte rapide, crawl régulier
site.fr/cat/sous-cat/produit	3 niveaux	Correct si le maillage est bon
site.fr/cat/sous-cat/sous-sous-cat/produit	4+ niveaux	Crawl espacé, pages souvent orphelines
site.fr/index.php?cat=42&id=8871	aplati	Fonctionne, mais empêche la lecture sémantique

Le quatrième cas est instructif. Un site e-commerce avec des URLs de type ?cat=42&id=8871 peut très bien se faire crawler, à condition de bloquer les variations de tri et de filtre via le robots.txt. Je l'ai fait sur un projet de bijouterie : on a gardé les URLs à paramètres, mais on a interdit les combinaisons de filtres. Résultat : le nombre de pages explorées est passé de 180 000 à 11 000 en six semaines. Le crawl est devenu enfin pertinent.

Où se trouve mon adresse URL ? Comprendre la question

C'est une question qu'on me pose souvent, et je pense qu'elle cache autre chose. Quand quelqu'un demande "où se trouve mon adresse URL", il cherche en réalité à savoir où la trouver, où la modifier, et à quoi elle ressemble — et les réponses varient selon le contexte.

Dans un navigateur

L'adresse s'affiche dans la barre d'adresse, en haut de la fenêtre. Sur Chrome, Firefox ou Safari, c'est la même logique : on clique dedans, on voit l'URL complète, on peut la copier ou la modifier. Sur mobile, elle apparaît en haut de l'écran et se réduit parfois au seul nom de domaine — il faut taper dessus pour voir le chemin complet.

Dans un CMS

Sur WordPress ou équivalent, l'URL d'une page ou d'un article se modifie dans le champ "Permalien", généralement visible dans la colonne de droite de l'éditeur. Sur Shopify, c'est le champ "URL et gestion" dans les paramètres du produit ou de la collection. Sur un site codé à la main, elle est définie dans les règles de réécriture du serveur (fichier .htaccess pour Apache, configuration nginx pour les autres).

Une nuance importante : si vous modifiez une URL existante sans mettre en place une redirection, vous perdez le référencement accumulé sur l'ancienne adresse. Toujours une redirection 301 avant la mise en ligne.

Paramètres et boucles : les deux ennemis silencieux

Revenons à ma cliente avec ses 42 000 pages. Le coupable, c'était un paramètre de tri : ?sort=prix-asc, ?sort=prix-desc, ?sort=date. Chaque combinaison avec les filtres produisait une adresse unique. Google les explorait toutes, patiemment, pendant que les vraies pages attendaient leur tour.

Comment neutraliser les paramètres

Trois leviers, à combiner :

1. Balise <link rel="canonical"> sur chaque page à paramètres, pointant vers la version propre.
2. Interdiction dans le fichier robots.txt des paramètres qui n'ont aucune valeur SEO (tri, session, tracking).
3. Réglage du paramètre "Paramètres d'URL" dans Search Console, pour indiquer à Google qu'un paramètre ne change pas le contenu.

Le troisième est sous-utilisé. C'est un outil ancien de Google, discret, mais il aide concrètement quand il est bien configuré. Je l'ai utilisé sur trois sites e-commerce différents — à chaque fois, la découverte de nouvelles pages utiles a augmenté.

Redirections en boucle

Une redirection qui pointe vers une autre redirection qui revient au point de départ. Le crawler suit, se lasse, et abandonne. Ces boucles sont souvent invisibles à l'œil nu — elles naissent d'une migration partielle, d'un changement de CMS mal nettoyé, ou d'une règle de réécriture trop large.

Pour les détecter, il faut crawler son propre site avec un outil dédié (Screaming Frog ou équivalent) et filtrer sur les codes 301/302. J'ai mis deux jours à trouver une boucle de ce type sur un site que je reprenais. Elle concernait 400 pages. Personne ne l'avait vue.

Migration d'URL : la partie qui fait peur

Changer la structure d'URL d'un site existant, c'est l'opération la plus risquée du référencement technique. Je l'ai faite quatre fois. Trois fois bien, une fois mal. La mauvaise m'a coûté environ 40 % du trafic organique pendant cinq semaines, et deux mois pour revenir à la normale.

Ce qui a mal tourné ? J'avais oublié de mettre à jour les liens internes. La redirection 301 fonctionnait pour les visiteurs externes, mais en interne, tous les liens pointaient encore vers les anciennes URLs. Google a interprété ça comme un signe que la nouvelle structure n'était pas encore prête. Erreur de débutant. Coûteuse.

La checklist que j'applique désormais

• Cartographier toutes les anciennes URLs et leur correspondance exacte.
• Générer les redirections 301 en masse, mais vérifier une par une les pages stratégiques.
• Mettre à jour tous les liens internes dans le CMS — pas seulement les redirections serveur.
• Mettre à jour le sitemap XML et le soumettre avant la bascule.
• Surveiller le taux d'exploration et les erreurs 404 dans Search Console pendant les six semaines suivantes.
• Ne rien changer d'autre pendant la migration. Pas de nouvelle structure, pas de refonte de design.

Le dernier point est celui qu'on oublie systématiquement. Migrer les URLs et refondre le site en même temps, c'est ne plus savoir ce qui a causé quoi quand les chiffres bougent.

En résumé : ce qui compte vraiment

Une bonne structure d'URL pour le crawling, ça tient à trois principes. Un : une seule adresse pour une seule ressource. Deux : une adresse qui se lit. Trois : un maillage interne cohérent, qui pointe vers les nouvelles adresses après toute modification.

Le reste — longueur idéale, mots-clés exacts dans l'URL — pèse peu. J'ai vu des sites avec des URLs sémantiquement parfaites et un crawl catastrophique, parce qu'ils avaient laissé proliférer les paramètres. Et j'ai vu l'inverse, des URLs banales, mais un crawl impeccable, parce que le développeur avait eu la rigueur de tout verrouiller.

Ce qui m'intéresse, en fin de compte, c'est le moment où on ouvre Search Console après trois semaines et où le rapport "Explorées, actuellement non indexées" redescend. Cette courbe qui pique vers le bas, c'est le signe qu'on a arrêté de gaspiller le budget de crawl. Et ce jour-là, on se dit qu'on aurait dû le faire plus tôt.

La vraie question, ce n'est pas "comment structurer mes URLs". C'est : combien de portes inutiles j'ai laissées ouvertes, et combien de temps je vais encore les laisser ouvertes ?