Catégoriser ses URLs pour un audit SEO : méthode, regex et outil

En bref

Article mis à jour le 22 octobre 2026

• Un crawl de 100 000 URLs ne dit rien tant qu’elles ne sont pas rangées : la question utile, c’est « combien de pages de quoi ? ».
• Deux axes valent mieux qu’un arbre unique : la structure (parent > groupe) et le thème (univers), indépendants l’un de l’autre.
• Une fois les URLs rangées, toutes vos métriques deviennent lisibles par groupe , et le croisement qui rapporte le plus, c’est crawl contre visites.
• À peu près toute source d’URLs se catégorise : export de crawl, logs Googlebot, logs des bots IA, Search Console, sitemap.
• Le vrai piège n’est pas la règle fausse, c’est la règle éclipsée : elle décrit les bonnes URLs, mais une règle placée plus haut les a déjà prises.
• Et à la fin de l’article un lien vers l’outil URLCAT qui permet de catégoriser soi meme n’importe quelle liste d’urls

Bon, on va parler d’une étape que presque tout le monde saute, et qui décide pourtant de la qualité de tout ce qui suit : ranger ses URLs par catégorie avant de les analyser.

Comme à mon habitude, je vais essayer de vulgariser au maximum. À la fin, vous saurez pourquoi on catégorise, ce que ça fait apparaître, sur quelles sources de données ça marche, comment s’écrit une règle, et où les expressions régulières deviennent vraiment utiles — sans avoir à en devenir spécialiste.

Petite précision avant de commencer : les chiffres des schémas qui suivent sont des exemples, pas les relevés d’un site réel. Ils servent à montrer une forme de lecture.

Pourquoi ranger ses URLs avant de les analyser ?

Prenez un crawl de 100 000 URLs. Vous avez un tableau de 100 000 lignes, un taux de pages en erreur, une profondeur moyenne, un joli camembert de codes HTTP. Et vous ne savez toujours rien du site.

Parce que la question qui compte n’est jamais « combien de pages ? ». C’est « combien de pages de quoi ? ». Un site à 40 000 URLs de pagination et 2 000 fiches produit n’est pas le même site que l’inverse, et il n’appelle pas le même audit — alors que les deux rendent exactement le même tableau de bord.

Ranger les URLs, c’est ce qui transforme un tableau en diagnostic. Vous passez de « la profondeur moyenne est correcte » à « elle est correcte partout, sauf sur les fiches produit ». De « Googlebot crawle beaucoup » à « Googlebot dépense l’essentiel de son budget sur des URLs à paramètres ». De « le trafic stagne » à « le trafic ne vient que de deux groupes sur onze ».

Aucune de ces trois phrases n’est possible sans catégorisation. Et ce sont les trois seules qui mènent à une action. Si le vocabulaire du crawl vous manque, j’en ai fait un glossaire.

Quelles URLs peut-on catégoriser ?

N’importe quelle liste, en fait. Un catégoriseur ne crawle rien : il range ce qu’on lui donne. C’est pour ça que la même méthode, et le même fichier de règles, servent sur des sources qui n’ont rien à voir entre elles — et c’est en les croisant que ça devient intéressant.

Source	Ce qu’elle contient	Ce que la catégorisation révèle
Export de crawl (Screaming Frog, Sitebulb…)	les URLs que le site expose	quels groupes pèsent, où se cache la profondeur
Logs Googlebot	les URLs que Google visite vraiment	où part le budget de crawl
Logs des bots IA (GPTBot, ClaudeBot, PerplexityBot…)	ce que les moteurs génératifs lisent chez vous	s’ils lisent votre contenu utile ou vos pages techniques
Export Search Console	les URLs qui ramènent des clics	quels groupes travaillent vraiment
Sitemap XML	les URLs que vous déclarez	l’écart entre ce que vous déclarez et ce qui existe

Le cas des logs mérite une précision, parce qu’il change les comptages. Sur un log, la même URL revient des dizaines de fois : Googlebot repasse. Il faut donc compter les occurrences d’un côté, et classer chaque URL unique une seule fois de l’autre. Sur un échantillon que j’ai passé à la machine, 105 630 lignes de log ne faisaient que 14 777 URLs distinctes.

Et les deux poids ne racontent pas la même histoire : un groupe peut ne contenir qu’une seule URL et concentrer un millier de passages de crawl. Invisible dans un décompte d’URLs, énorme dans un décompte d’occurrences. J’ai détaillé la lecture d’un log dans L’analyse de logs, ce qu’il faut savoir.

Les deux axes : la structure et le thème

Une erreur classique, c’est de vouloir tout faire tenir dans un seul arbre. Ça ne marche pas, parce qu’une URL porte deux informations indépendantes.

L’axe structurel dit où vit la page : fiche produit, page de devis, article, pagination, panier. On le hiérarchise en parent > groupe, parce qu’on veut pouvoir replier « tout le site inutile » d’un côté et « tout le site utile » de l’autre. L’axe thématique — l’univers — dit de quoi elle parle : assurance auto, habitation, santé. Un seul niveau suffit.

Pourquoi les séparer ? Parce qu’une fiche produit et un article de blog peuvent très bien parler du même univers tout en vivant à deux endroits qui n’ont rien à voir. Les mélanger, c’est perdre l’un des deux — et c’est justement le croisement des deux qui permet la question intéressante.

Quel type d’informations la catégorisation fait apparaître ?

C’est là que ça devient concret. La catégorisation ne produit aucune donnée nouvelle : elle rend lisibles celles que vous avez déjà. Toute métrique attachée à une URL devient une métrique par groupe, et par univers.

Ce qu’on croise avec les groupes	La question à laquelle ça répond
Passages de Googlebot (logs)	Où part le budget de crawl ?
Clics et impressions (Search Console)	Quels groupes travaillent vraiment ?
Pages indexées contre pages exclues	Quel groupe Google refuse-t-il d’indexer ?
Profondeur de clic	Quel groupe est enterré trop loin de l’accueil ?
Temps de réponse serveur	Quel groupe coûte cher à crawler ?
Passages des bots IA	Qu’est-ce que les moteurs génératifs lisent chez moi ?

Chacune de ces lignes donne une répartition, et une répartition se regarde très bien en camembert — c’est ce que j’utilise le plus souvent dans mes audits pour montrer où part le crawl ou d’où viennent les visites. Mais le vrai rendement n’est pas dans une répartition seule : il est dans deux répartitions mises côte à côte.

Un conseil de forme, appris à mes frais : le camembert est très bien pour une répartition, lue d’un coup d’œil, à six parts au maximum. Dès qu’il s’agit d’en comparer deux, il devient illisible — l’œil ne sait pas mettre deux angles en rapport. Deux barres, ou la forme ci-dessus avec un point par série, montrent l’écart immédiatement.

Et c’est cet écart qui vaut de l’argent. Un groupe qui absorbe le crawl sans ramener de visites, c’est du budget de crawl à redéployer. Un groupe qui ramène des visites sans être crawlé, c’est du maillage interne à refaire. Les deux se voient en trois secondes sur ce genre de figure, et pas du tout dans un tableau de 100 000 lignes.

Comment s’écrit une règle

Un fichier de règles est un fichier texte. Pas de base de données, pas d’interface : du texte qu’on relit, qu’on versionne et qu’on rejoue. Voici le minimum vital.

[crawl:categories]

@names
100	site
200	inutile

@
path /offers/*
+	/fr/offers/*
name fiches-offers
parent-id	100

@
path *utm_*
name inutiles-tracking
parent-id	200

@names déclare la table des parents. Chaque @ ouvre une règle : path porte le motif principal, + ajoute des motifs alternatifs (un OU), name donne le nom du groupe, et parent-id le rattache — il est facultatif, une règle peut n’avoir aucun parent.

Deux choses à savoir avant d’écrire le premier motif, parce qu’elles expliquent la quasi-totalité des surprises :

1. Le premier motif qui correspond gagne, dans l’ordre du fichier. L’ordre des règles est donc une décision, pas un détail.
2. Le motif porte sur le chemin ET la query string, pas sur le chemin seul. Sans ça, un motif comme *utm_* n’attraperait jamais rien.

Le motif le plus simple est un glob : * est le seul joker, et le motif est ancré aux deux bouts. Pas de correspondance par préfixe, donc pas de surprise :

Motif (glob)	Attrape	N’attrape pas
/offers	/offers	/offers/, /offers/42
/offers/*	/offers/42, /offers/a/b	/offers
*utm_*	/blog/a?utm_source=x	/blog/a

Et oui : /offers et /offers/* sont bien deux règles distinctes. C’est déroutant cinq minutes, puis c’est reposant — on sait exactement ce qu’une règle attrape, sans avoir à le tester.

Les regex, le minimum qui suffit

Le glob couvre l’essentiel. Les expressions régulières servent quand il faut dire quelque chose que le glob ne sait pas exprimer : « un nombre », « l’une de ces trois langues », « seulement si ça se termine là ».

On préfixe alors le motif par rx:, et c’est une vraie regex, en recherche non ancrée — autrement dit le motif porte son ^ lui-même quand il veut démarrer au début de l’URL. Quatre ou cinq briques couvrent la quasi-totalité des cas réels :

Brique	Ce que ça veut dire	Règle d’exemple
^	début de l’URL	rx:^/blog/
$	fin de l’URL	rx:^/offers/[0-9]+$
[0-9]+	un ou plusieurs chiffres	rx:/page/[0-9]+
(fr|en|de)	l’un de ces choix	rx:^/(fr|en|de)/
\?	un point d’interrogation littéral	rx:\?.*utm_
\.	un point littéral	rx:\.pdf$

Avec ça, vous isolez déjà vos pages de pagination, vos fiches à identifiant numérique, vos préfixes de langue, vos PDF et vos URLs taguées. C’est la moitié d’un fichier de règles réel.

Et le piège à connaître, celui qui passe inaperçu pendant des mois : le point non échappé. Dans une regex, . ne veut pas dire « un point », il veut dire « n’importe quel caractère ». Du coup rx:^/www.* n’attrape pas ce que vous croyez : il attrape /www suivi de n’importe quoi, /wwwarchive compris. Pour un point littéral, c’est \. — et c’est exactement le genre de chose qu’un outil doit vous signaler plutôt que vous laisser deviner.

Si les regex sont un terrain neuf pour vous, deux ressources suffisent. RegexOne est le plus efficace pour démarrer : les briques une par une, avec un exercice à chaque fois. Et regex101 pour tester un motif en direct, avec l’explication de chaque morceau — pensez à choisir la saveur Python dans la colonne de gauche, c’est celle que la plupart des catégoriseurs utilisent.

Pour une référence en français, le guide des expressions régulières de Python fait le travail, et il va bien plus loin que ce dont vous aurez besoin ici.

Dans mes audits, je catégorise très finement

C’est la première chose que je fais sur un audit, avant de regarder quoi que ce soit d’autre. Et je ne lésine pas : sur un gros site, ça monte vite à une trentaine de règles.

Pourquoi aussi fin ? Parce qu’un groupe trop large cache précisément ce qu’on cherche. « Pages produit », c’est confortable — et ça mélange les fiches en stock, les fiches épuisées, les fiches sans avis et les variantes de couleur qui dupliquent la fiche mère. Les quatre n’ont ni le même problème, ni la même valeur, ni la même action. Tant qu’elles sont dans le même sac, la moyenne les écrase toutes.

À mon sens, la catégorisation fine est ce qui sépare un audit « avancé » d’un audit qui récite les alertes d’un crawler. Les alertes, l’outil les sort tout seul. Ce qu’il ne sortira jamais tout seul, c’est quelle famille d’URLs mérite qu’on s’en occupe en premier. J’ai décrit cette façon de travailler plus largement dans ma méthodologie d’audit technique.

Il y a un effet de bord auquel je ne m’attendais pas, et qui est devenu la vraie raison de tout ça : le fichier de règles se rejoue. L’audit suivant sur le même site, je repars du même fichier, je l’ajuste, et je compare deux photos prises avec le même cadrage. Au bout de quelques passages, ce fichier vaut bien plus que n’importe quel outil : c’est de la connaissance du site, écrite, versionnée, transmissible.

Le piège : la règle qui ne gagne jamais

Voilà le défaut le plus coûteux, et le plus silencieux. Vous écrivez une règle juste, qui décrit exactement les bonnes URLs. Elle ne classe rien. Pas une erreur, pas un avertissement : zéro URL, et rien pour vous dire pourquoi.

La raison est mécanique. Puisque le premier motif qui correspond l’emporte, une règle placée plus haut a pu prendre ses URLs au passage — souvent par un * un peu large qui avale aussi la query string.

Dans un tableur, ce défaut est invisible : rien ne vous dira qu’une de vos formules est morte. C’est pour ça qu’un catégoriseur doit savoir nommer la règle qui a volé les URLs, dire combien elle en a pris, et en montrer une. À partir de là, c’est à vous d’arbitrer — remonter la règle éclipsée, ou resserrer celle du dessus.

Et pendant qu’on y est, deux autres signaux valent le détour : la règle sans objet (aucune URL du corpus ne la touche : motif faux, ou règle périmée depuis une refonte) et l’hôte non déclaré (vos règles ont été écrites pour le staging, votre liste vient de la prod).

Questions fréquentes

Faut-il savoir coder pour écrire un fichier de règles ?

Non. Un fichier de règles, c’est une suite de lignes « ce motif → ce groupe », et le glob (* comme seul joker) suffit pour la majorité des règles. Les regex ne deviennent utiles que sur les cas que le glob ne sait pas dire, et quatre briques couvrent déjà presque tout.

Camembert ou barres pour présenter ces répartitions ?

Camembert pour une répartition lue d’un coup d’œil, six parts au maximum — au-delà, les parts voisines se confondent. Barres, ou un point par série sur une même échelle, dès qu’il s’agit d’en comparer deux : mettre deux angles en rapport est un exercice que l’œil rate, mettre deux longueurs en rapport est immédiat.

Combien de groupes faut-il viser ?

Autant qu’il y a de familles d’URLs qui appellent une action différente — pas une de plus, pas une de moins. Le bon test : si vous ne savez pas quoi faire de différent entre deux groupes, fusionnez-les ; si une moyenne à l’intérieur d’un groupe vous paraît suspecte, coupez-le en deux.

Puis-je réutiliser mes règles d’un site à l’autre ?

Les motifs, rarement : ils collent aux URLs d’un site. La structure, tout le temps : les parents « site utile » et « inutile », les groupes de pagination, de facettes, de paramètres de tracking se retrouvent partout. En pratique, on garde un squelette et on réécrit les motifs.

Glob ou regex, comment choisir ?

Glob par défaut : il se relit à voix haute, et un motif ancré aux deux bouts ne surprend personne six mois plus tard. Regex dès qu’il faut exprimer une quantité (« un nombre »), un choix (« fr, en ou de ») ou une fin stricte. Si vous hésitez, écrivez le glob : vous le remplacerez le jour où il ne suffira plus.

Les URLs des bots IA se lisent-elles comme celles de Googlebot ?

La méthode est la même — on filtre le log sur le user-agent, on en tire les URLs, on les classe avec le même fichier de règles. Ce qui change, c’est la lecture : sur Googlebot on cherche où part le budget de crawl, sur GPTBot ou ClaudeBot on cherche si ce qu’ils lisent est bien le contenu qu’on voudrait voir cité. Mêmes groupes, deux questions différentes.