Dans les coulisses de Googlebot : démystifier l'exploration, la récupération et les octets que nous traitons

Mardi 31 mars 2026

Si vous avez écouté l’ épisode 105 du podcast Search Off the Record, vous nous avez peut-être entendus aborder en profondeur un sujet qui nous tient à cœur (et qui occupe nos serveurs) : le fonctionnement interne de Googlebot.

Pendant longtemps, le nom “Googlebot” a évoqué l’image d’un robot unique et infatigable lisant systématiquement Internet. Mais la réalité est un peu plus complexe — et beaucoup plus intéressante. Aujourd’hui, nous voulons soulever le capot de notre infrastructure de crawl, en nous concentrant sur ce qui nous donne du fil à retordre : les limites d’octets.

D’abord, Googlebot n’est pas un programme unique

Clarifions d’abord une erreur historique. Au début des années 2000, Google n’avait qu’un seul produit, donc un seul crawler. Le nom “Googlebot” est resté. Mais aujourd’hui, Googlebot n’est qu’un utilisateur de ce qui ressemble à une plateforme de crawl centralisée.

Lorsque vous voyez Googlebot dans vos logs de serveur, vous regardez simplement Google Search. Des dizaines d’autres clients — Google Shopping, AdSense, et plus encore — acheminent toutes leurs requêtes de crawl via cette même infrastructure sous-jacente avec des noms de crawlers différents, les plus importants étant documentés sur le site de l’infrastructure Google Crawler.

La limite de 2 Mo : que deviennent vos octets ?

C’est là que les choses deviennent confuses. Chaque client de l’infrastructure de crawl doit définir des paramètres pour ses récupérations. Ces paramètres incluent la chaîne user agent, les jetons user agent recherchés dans le robots.txt, et le nombre d’octets récupérés pour une seule URL.

Googlebot récupère actuellement jusqu’à 2 Mo pour toute URL individuelle (hors PDF). Cela signifie qu’il ne crawl que les 2 premiers Mo d’une ressource, en incluant l’en-tête HTTP. Pour les fichiers PDF, la limite est de 64 Mo.

Les crawlers d’images et de vidéos ont généralement des seuils variés, qui dépendent largement du produit pour lequel ils effectuent la récupération. Par exemple, la récupération d’un favicon peut avoir une limite très basse, contrairement à la recherche d’images.

Pour tout autre crawler ne spécifiant pas de limite, la valeur par défaut est de 15 Mo, quel que soit le type de contenu.

Qu’est-ce que cela signifie pour les octets que votre serveur envoie ?

• Récupération partielle : Si votre fichier HTML dépasse 2 Mo, Googlebot ne rejette pas la page. Il arrête simplement la récupération exactement à la limite de 2 Mo. Notez que cette limite inclut les en-têtes de requête HTTP.
• Traitement de la coupure : Cette portion téléchargée (les 2 premiers Mo) est transmise à nos systèmes d’indexation et au Web Rendering Service (WRS) comme s’il s’agissait du fichier complet.
• Les octets invisibles : Tous les octets situés après ce seuil de 2 Mo sont totalement ignorés. Ils ne sont ni récupérés, ni rendus, ni indexés.
• Importation des ressources : Chaque ressource référencée dans le HTML (hors médias, polices et quelques fichiers exotiques) sera récupérée par le WRS avec Googlebot, tout comme le HTML parent. Elles possèdent leur propre compteur d’octets par URL et ne sont pas comptabilisées dans la taille de la page parente.

Pour la grande majorité du web, une charge utile HTML de 2 Mo est énorme, et vous n’atteindrez jamais cette limite. Cependant, si votre page inclut des images base64 en ligne lourdes, des blocs massifs de CSS/JavaScript en ligne, ou commence par des mégaoctets de menus, vous pourriez accidentellement repousser votre contenu textuel réel ou vos données structurées critiques au-delà de la barre des 2 Mo. Si ces octets cruciaux ne sont pas récupérés, pour Googlebot, ils n’existent tout simplement pas.

Rendu des octets

Une fois que le crawler a récupéré les octets (jusqu’à la limite), il passe le relais au WRS. Le WRS traite le JavaScript et exécute le code côté client comme un navigateur moderne pour comprendre l’état visuel et textuel final de la page. Le rendu récupère et exécute les fichiers JavaScript et CSS, et traite les requêtes XHR pour mieux comprendre le contenu textuel et la structure de la page (il ne demande pas d’images ou de vidéos). Pour chaque ressource demandée, la limite de 2 Mo s’applique également.

Cependant, rappelez-vous que le WRS ne peut exécuter que le code que le crawler a réellement récupéré. De plus, le WRS fonctionne sans état — il efface le stockage local et les données de session entre les requêtes. Cela peut avoir des implications particulières sur la façon dont les éléments dynamiques dépendants du JavaScript sont interprétés par nos systèmes.

Bonnes pratiques pour vos octets

Pour garantir que Googlebot puisse récupérer et comprendre efficacement votre contenu, gardez à l’esprit ces bonnes pratiques au niveau des octets :

• Gardez votre HTML léger : Déplacez les CSS et JavaScript lourds vers des fichiers externes. Bien que le document HTML initial soit limité à 2 Mo, les scripts et feuilles de style externes sont récupérés séparément (soumis à leurs propres limites).
• L’ordre compte : Placez vos éléments les plus critiques — comme les balises meta, les éléments <title>, les éléments <link>, les canonicals et les données structurées essentielles — le plus haut possible dans le document HTML. Cela garantit qu’ils ne se retrouveront pas après la coupure.
• Surveillez vos logs de serveur : Gardez un œil sur les temps de réponse de votre serveur. Si votre serveur peine à servir les octets, nos crawlers ralentiront automatiquement pour éviter de surcharger votre infrastructure, ce qui réduira votre fréquence de crawl.

Notez que cette limite n’est pas gravée dans le marbre et peut évoluer avec le temps à mesure que le web progresse et que les pages HTML augmentent en taille. (Ou diminuent. Espérons qu’elles diminuent.)

Le crawl n’est pas de la magie ; c’est un échange d’octets hautement orchestré et mis à l’échelle. En comprenant comment notre infrastructure de récupération centrale récupère et limite ces octets, vous pouvez vous assurer que le contenu le plus important de votre site est toujours pris en compte.

Bonne optimisation !

Vous voulez plus de détails sur les coulisses ? Consultez l’ épisode 105 du podcast Search Off the Record sur YouTube ou sur votre plateforme de podcast préférée !

Publié par Gary.