Un client m'a envoyé le mois dernier un rapport de la Search Console avec une allure de catastrophe : 380 000 URL détectées, 12 000 réellement indexées, et une courbe de crawl qui ressemblait à un électrocardiogramme plat. Son site vendait des pièces auto. Il avait 3 000 références produits. Vous voyez le problème.
Le crawl, ce n'est pas un réglage dans un plugin. C'est la conséquence directe de la façon dont vous avez rangé votre site. Et en 2026, avec les crawlers IA qui viennent s'ajouter à Googlebot, une architecture mal fichue ne se contente plus de gaspiller du budget : elle vous rend invisible dans deux mondes à la fois.
Je vais vous montrer comment je construis une architecture optimisée pour le crawl sur les projets que je reprends, avec les règles concrètes que j'applique, celles qui ont foiré, et la méthode pas-à-pas que personne ne détaille vraiment.
Points clés à retenir
- Une profondeur de clic maximale de 3 depuis la home, pas une recommandation vague : une contrainte de construction.
- Le budget de crawl se gaspille à 80 % sur des pages qu'on n'a jamais décidé de publier (facettes, paramètres, paginations infinies).
- Le maillage interne compte plus que la vitesse serveur pour la fréquence de passage, dans la majorité des cas que je traite.
- Un fil d'Ariane bien fait n'est pas de la déco : c'est un chemin de crawl que vous offrez gratuitement.
- Les crawlers IA (GPTBot, ClaudeBot, PerplexityBot) suivent souvent le même maillage que Googlebot. Une bonne arborescence sert deux fois.
- Le nommage d'URL est une décision d'architecture, pas de rédaction. À figer avant la mise en ligne.
Pourquoi le crawl reste le vrai goulot d'étranglement en 2026
On m'a répété pendant des années que le crawl budget ne concernait que les mastodontes. Faux. Je l'ai constaté sur un site de 400 pages l'an dernier : la moitié du budget partait sur des URL de filtres e-commerce que le client avait laissés ouverts "au cas où".
Le mécanisme est simple à comprendre, et c'est ce qui le rend vicieux. Googlebot explore par vagues. Il revient plus souvent sur les pages qu'il juge importantes, et il juge l'importance à la fois par les liens internes qui pointent vers elles et par la fréquence à laquelle elles changent. Si vous noyez ces pages au milieu de 200 000 URL inutiles, vous n'avez pas perdu du temps de crawl. Vous avez dégradé le signal envoyé sur vos pages stratégiques.
Ce qui a changé avec les crawlers IA
Ce n'est pas une révolution, mais ça déplace une pièce. Les robots des moteurs génératifs ne suivent pas la même logique que Googlebot : ils privilégient souvent la structure du contenu et le maillage éditorial. Un site en silo clair, avec des liens contextuels, se fait absorber proprement par ces robots. Un site en pagaille se fait ignorer.
Le corollaire pratique : une architecture propre travaille maintenant deux fois. Une fois pour l'indexation classique. Une fois pour les réponses génératives.
Les trois règles de construction que j'applique par défaut
Avant de parler outils et audits, il faut poser des contraintes. Sans contraintes, une architecture dérive en trois mois. Voici celles que je m'impose sur tous les projets où je peux décider.
Règle 1 : profondeur maximale de 3 clics
Depuis la home, aucune page qui mérite d'être indexée ne doit se trouver au-delà du troisième clic. C'est contraignant. Ça vous oblige à imaginer une hiérarchie hub → catégorie → page, avec éventuellement une sous-catégorie quand la thématique est dense. Pas quatre niveaux de sous-sous-catégories parce qu'un commercial a dit "il faut tout ranger".
Quand je passe d'une arborescence profonde à cette contrainte, je constate en moyenne une multiplication par deux à trois du nombre de pages crawlées par semaine sur les pages produits. Pas une donnée issue d'une étude. Un constat répété sur une dizaine de refontes.
Règle 2 : une URL par intention, une page par URL
Le contenu dupliqué ne vient pas de la paresse. Il vient des CMS qui génèrent mécaniquement cinq variantes de la même page : une en HTTP, une en HTTPS, une avec slash final, une avec paramètres de tri, une avec paramètres de session. Vous croyez publier une page. Vous en publiez cinq.
Le travail consiste à trancher une fois pour toutes. Une URL canonique. Les autres redirigées ou en noindex. Pas les deux à la fois, jamais.
Règle 3 : le nommage des URLs se décide avant la rédaction
J'ai fait l'erreur une fois. Une refonte de blog où j'ai laissé les rédacteurs nommer les URLs. Résultat : trois mois plus tard, onze articles "principes-seo-technique" ou "principes-seo-technique-2". Le crawl était propre, le maillage interne illisible. On a dû rediriger 40 URLs à la main.
Depuis : une convention figée. Minuscules, tirets, pas de date, pas de numéro d'ordre. /guides/architecture-crawl, jamais /2026/07/guide-seo-3.
Arborescence type : ce que ça donne concrètement
Voici la structure que je pose sur la plupart des sites de contenu ou de e-commerce de taille moyenne. Elle est volontairement simple.
| Niveau | Rôle | Exemple d'URL | Volume cible |
|---|---|---|---|
| 0 — Home | Point d'entrée, distribution du jus | / | 1 |
| 1 — Hub thématique | Regroupe les grands univers. Lié depuis la home dans le menu principal. | /pieces-moteur/ | 5 à 12 |
| 2 — Catégorie | Sous-division du hub. Lié depuis le hub ET depuis les pages du même niveau. | /pieces-moteur/filtres/ | 30 à 150 |
| 3 — Page finale | Le contenu à indexer. Produit, article, fiche. | /pieces-moteur/filtres/filtre-a-huile-1-6-hdi | Variable |
Ce qui compte dans ce tableau, ce n'est pas la profondeur en soi. C'est la règle qui va avec : chaque niveau doit être atteignable depuis son parent direct sans passer par un listing paginé. Si vous cassez ça, vous fabriquez une page orpheline de facto.
Et le maillage interne dans tout ça ?
Le maillage fait plus de travail que la structure. Une page de niveau 3 liée depuis cinq autres pages de niveau 3 sera crawlée plus vite qu'une page de niveau 2 liée une seule fois. C'est la redondance des liens qui pèse, pas la position dans l'arborescence.
Concrètement, je demande toujours deux choses aux rédacteurs : au moins 3 liens contextuels sortants par page, et au moins 3 liens entrants vers chaque page stratégique. Ce deuxième chiffre est celui qu'on oublie systématiquement.
Le cas des facettes et paramètres d'URL
C'est le poste qui coûte le plus cher, et de loin. Sur le site de pièces auto du début, les facettes généraient 340 000 URL. On en a gardé 800.
La méthode n'est pas de tout bloquer en robots.txt. C'est une erreur classique : bloquer empêche le crawl, mais n'empêche pas l'indexation si des liens externes pointent vers ces URLs. On se retrouve avec des pages indexées qu'on ne peut plus explorer pour corriger. Le piège.
Ce que je fais à la place :
- Filtrer les combinaisons de facettes qui génèrent du contenu réellement distinct (rare).
- Tout le reste passe en
noindex, follow, ou mieux, en suppression de lien si l'URL reste techniquement accessible. - Aucune pagination au-delà de la page 5 sans
rel="next"mal géré — en pratique, on la rend crawlable mais on la retire du maillage. - Le paramètre de tri par défaut devient l'URL canonique.
Résultat constaté sur ce projet : le nombre d'URL crawlées passe de 380 000 à 18 000, et les pages produits remontent en tête des statistiques d'exploration en trois semaines.
Questions fréquentes
Combien de pages un site peut-il raisonnablement faire crawler ?
Il n'y a pas de plafond universel. Tout dépend de l'autorité du domaine, de la fraîcheur du contenu et de la qualité du maillage. Un site de 5 000 pages bien structuré se fait crawler intégralement en quelques jours. Un site de 5 000 pages mal structuré peut mettre des mois à faire explorer la moitié de ses URLs. La question n'est donc pas "combien", mais "est-ce que chaque URL mérite d'être crawlée ?". Si la réponse est non, elle ne devrait pas exister.
Faut-il bloquer les crawlers IA dans le robots.txt ?
Ça dépend de votre modèle. Si votre contenu est votre produit et que vous ne voulez pas qu'il alimente des réponses génératives sans contrepartie, bloquez. Si votre objectif est la visibilité, laissez passer. Ce qui est sûr, c'est que bloquer un crawler IA n'a aucun effet sur le crawl de Googlebot. Ce sont deux canaux séparés. J'ai vu des clients paniquer à l'idée de "faire fuiter du contenu" alors qu'ils laissaient 200 000 URLs de facettes ouvertes à tout le monde. L'ordre des priorités est à revoir.
À quelle fréquence faut-il auditer l'architecture ?
Une fois par trimestre sur un site qui bouge, une fois par an sur un site stabilisé. Le signal à surveiller n'est pas le nombre d'URL indexées, mais le ratio entre URL explorées et URL indexées dans la Search Console. Quand ce ratio dépasse 3 pour 1, il y a un problème d'architecture, pas de contenu. C'est le déclencheur que j'utilise systématiquement avant de lancer un audit — la plupart des clients qui m'appellent ont un ratio compris entre 5 et 12.
Ce que je regrette de ne pas avoir fait plus tôt
J'ai passé des années à corriger des sites après coup alors qu'un seul geste aurait tout évité : dessiner l'arborescence sur une feuille avant d'ouvrir le CMS. Pas un schéma dans un tableur. Un vrai dessin, avec des flèches entre les pages, et le nombre de clics depuis la home écrit à côté de chaque nœud.
Cette contrainte visuelle fait ressortir en trente secondes les pages qui sont à cinq clics de profondeur. Celles-là, vous ne les verrez jamais dans un rapport. Elles existent, elles consomment du budget de crawl, et elles ne rapportent rien.
La vraie question, au fond, ce n'est pas "comment optimiser le crawl". C'est : est-ce que vous savez, sans ouvrir votre site, combien de pages vous avez publiées cette année qui sont à plus de trois clics de votre home ? Si vous hésitez, vous avez votre réponse.
