Googlebot ne visite jamais la totalité d’un site technique, et le problème se pose souvent au niveau des sous-domaines, car chaque hôte est traité comme un site séparé avec son propre budget d’exploration, ce qui fragmente l’attention du robot sur les plateformes dispersées entre www, code, docs ou api. L’audit classique par nombre de pages passe à côté. Pour comprendre les URL ignorées, lisez les logs. Voici comment reprendre la main.
Un site, c’est d’abord un nom d’hôte
La définition officielle de Google, qu’on lit rarement jusqu’au bout dans les documentations techniques, devrait figurer en tête de tout audit de crawl, car le moteur traite https://www.example.com/ et https://code.example.com/ comme deux sites distincts, chacun avec son budget d’exploration technique. Cela paraît anodin, mais pour une plateforme technique, c’est un point de bascule.
Un portail de documentation, une API exposée en public et un back-office sur plusieurs sous-domaines ne sont pas un grand site aux yeux de Googlebot. Ce sont des petits sites qui se partagent l’attention du robot sans jamais additionner leurs forces. La question du nombre de pages perd alors de sa pertinence.
L’outil de couverture d’indexation additionne volontiers les URL de tous les hôtes, ce qui donne une fausse impression de bonne santé. Or Googlebot ne raisonne pas comme un tableau de bord. Il affecte des capacités séparées à chaque hôte, en fonction de signaux parfois très techniques, ce qui explique pourquoi un sous-domaine de documentation peut rester dans l’ombre alors que le site principal capte la plus grande part du passage.
Pourquoi une plateforme technique dilue son exploration
Le budget d’exploration repose sur la limite de capacité et le besoin d’exploration. Google le précise dans son guide destiné aux sites très volumineux de plus d’un million de pages uniques dont le contenu change au moins une fois par semaine, puis aux sites de plus de 10 000 pages uniques dont le contenu évolue quotidiennement. Une base de connaissances technique peut entrer dans ce second cas sans qu’on s’en aperçoive.
Le guide de l’éditeur publié par SODP, créé par Sue Plunkett, vérifié par Vahe Arabian, édité par Andrew Kemp et mis à jour le 1er décembre 2025, insiste sur la même distinction. Si cette base est répartie sur plusieurs hôtes, chaque budget est calculé séparément, et les URL utiles finissent par attendre.
bloodsnow.fr a publié une définition claire d’Alan Chevereau, datée du 12 juin : le budget de crawl est le nombre d’URL que Googlebot peut et veut parcourir sur un site sur une période donnée. Ce chiffre ne tient pas compte de la somme des pages de tous les sous-domaines, ce qui complique le diagnostic.
Ce que les logs révèlent sur le besoin d’exploration
Combien de pages Googlebot voit-il vraiment ? L’interface Search Console montre une vision agrégée qui masque les blocages par hôte. Les logs serveur racontent autre chose, à condition de croiser les champs user-agent, codes réponse et URL demandée. C’est une lecture différente de celle proposée par les outils de couverture.
Un crawl rate correct sur www ne dit rien des sous-domaines techniques qui restent invisibles. On découvre souvent qu’une API publique reçoit beaucoup plus de requêtes que la documentation qui l’explique, et cette asymétrie signale un déséquilibre dans le besoin d’exploration. Sur ce point, voir aussi notre article sur optimiser son site d’actualités : nos conseils.
Les signaux qui ressortent des logs
Quand on écarte les bruits de fond, quelques indices permettent de repérer une dilution du budget d’exploration. Ces signaux varient selon les hôtes, mais ils montrent souvent où se perd l’attention du robot. Ils ne remplacent pas un audit complet, mais ils donnent une première orientation avant de lancer des consolidations coûteuses.
- Le crawl rate par hôte peut rester élevé alors que des sections entières ne sont jamais demandées.
- Une concentration des requêtes sur les pages de connexion et les redirections techniques.
- Pourquoi les URL de code source reçoivent-elles plus de passages que la documentation de l’API ?
- L’écart de priorité entre les pages de statut et les actualités produit.
- Une proportion croissante de réponses en erreur qui fausse l’estimation du besoin réel.
Le problème n’est pas tant le volume total de pages que la façon dont les signaux se répondent d’un hôte à l’autre. Une URL de documentation appelée depuis une page d’API ne reçoit pas le même traitement si elle change de nom d’hôte en cours de route. Les logs permettent de suivre ces trajectoires de crawl, et c’est là que l’audit devient réellement utile pour décider quelles URL consolider en priorité.
Consolider les URL sans bloquer les équipes produit
Faut-il tout rapatrier sur un seul hôte ? La tentation est forte, mais une migration trop brutale peut casser des processus d’intégration continue. Les équipes qui gèrent l’API n’ont pas les mêmes contraintes que celles qui publient la documentation, et une séparation logique par chemins reste nécessaire.
Mieux vaut déplacer les sous-domaines vers des répertoires du domaine principal, puis laisser le temps aux logs de montrer l’effet, car un simple plan de redirection ne suffit pas lorsque Googlebot doit d’abord comprendre la nouvelle hiérarchie avant de répartir son passage. La migration se fait par étapes, pas d’un bloc.
Franchement, avant de tout déplacer, il faut choisir les chemins les plus visibles et conserver les redirections les plus propres possibles. Les anciennes URL techniques ne doivent pas devenir des impasses. Une consolidation par étapes laisse à Googlebot le temps de réévaluer la nouvelle arborescence sans provoquer de chute brutale sur les pages déjà connues. Les équipes produit y gagnent aussi, parce qu’elles gardent un contrôle sur leurs espaces.
Un budget ne se force pas, il se clarifie
Reprendre la main sur l’exploration d’une plateforme technique passe d’abord par la reconnaissance d’une règle simple : chaque nom d’hôte possède sa propre limite de capacité. Déplacer de nombreuses URL vers un domaine unique ne crée pas soudainement des passages supplémentaires, mais cela évite de gaspiller l’attention sur des zones secondaires.
Les logs deviennent alors un outil de pilotage, pas un simple registre d’erreurs. La vraie question n’est pas de savoir pourquoi Googlebot ignore certaines pages, mais ce que ces pages coûtent aux autres. Quelle URL de votre plateforme mérite le prochain passage du robot ?
