Googlebot dévoilé: limite des 2 Mo, infrastructure et bonnes pratiques de crawl
Google publie une explication détaillée du fonctionnement interne de Googlebot, révélant que le crawler est en réalité une infrastructure centralisée partagée par de nombreux produits Google. L'article lève le voile sur les limites de volume de données traitées par URL, notamment la limite de 2 Mo pour le HTML, et ses conséquences directes sur l'indexation. Ces précisions, issues du podcast Search Off the Record (épisode 105), constituent une référence technique indispensable pour optimiser la crawlabilité de tout site.
Points clés
- Googlebot n'est pas un robot unique mais le nom visible d'une infrastructure de crawl centralisée que partagent des dizaines de produits Google (Shopping, AdSense, etc.), chacun opérant sous un nom de crawler distinct.
- Pour les pages HTML, Googlebot récupère au maximum les 2 premiers mégaoctets d'une URL, en-têtes HTTP inclus, et ignore intégralement tout octet situé au-delà de ce seuil, sans rejeter la page pour autant.
- Les fichiers PDF bénéficient d'une limite nettement plus haute fixée à 64 Mo, tandis que les crawlers sans limite explicitement définie appliquent une valeur par défaut de 15 Mo quel que soit le type de contenu.
- Le Web Rendering Service (WRS), qui exécute le JavaScript et le CSS pour interpréter l'état final de la page, est lui aussi soumis à la limite de 2 Mo pour chaque ressource qu'il sollicite, et fonctionne sans état, effaçant le stockage local entre chaque requête.
- Chaque ressource référencée dans le HTML (scripts, feuilles de style, hors médias et polices) possède son propre compteur d'octets indépendant et ne consomme pas le quota des 2 Mo attribué au document parent.
- La limite de 2 Mo n'est pas définitive et pourra évoluer à mesure que les pages web grossissent ou, idéalement selon Google, maigrissent.
Analyse
La révélation la plus structurante de cet article est la distinction entre Googlebot comme marque visible et la réalité d'une plateforme de crawl mutualisée. Pour les professionnels du SEO, cela signifie que les logs serveur peuvent afficher différents user agents Google qui partagent pourtant les mêmes règles fondamentales d'infrastructure. Distinguer chaque crawler (Googlebot pour la Search, Googlebot-Image, AdsBot, etc.) et consulter la documentation officielle des crawlers Google devient une étape d'analyse incontournable pour interpréter correctement les données de crawl.
La limite de 2 Mo appliquée au HTML est un mécanisme de coupure brutale, non un filtre intelligent. Googlebot ne parcourt pas le fichier entier pour identifier les éléments importants, puis décide quoi indexer. Il s'arrête à la frontière des 2 Mo et transmet ce fragment comme si c'était le document complet. Concrètement, un site qui intègre des images encodées en base64 directement dans le HTML, des blocs CSS ou JavaScript massifs en ligne, ou de longs menus de navigation en début de fichier, peut involontairement reléguer son contenu textuel réel, ses données structurées ou ses balises canonicals après ce seuil, les rendant invisibles pour le moteur.
Le comportement sans état du Web Rendering Service a des implications importantes pour les sites fortement dépendants du JavaScript côté client. Puisque le WRS efface le stockage local et les données de session entre chaque requête, les mécanismes d'initialisation d'état (authentification légère, préférences utilisateur, données persistées dans le sessionStorage) ne fonctionneront pas lors du rendu par Google. Les pages qui nécessitent un contexte de session pour afficher leur contenu principal risquent donc d'être rendues partiellement ou incorrectement, indépendamment de la question des octets.
Le fait que les ressources externes (JavaScript et CSS) disposent chacune de leur propre compteur d'octets séparé du document parent constitue une information stratégique majeure. Externaliser le code lourd dans des fichiers distincts est non seulement une bonne pratique de performance web, mais aussi une façon d'optimiser directement la capacité de Googlebot à accéder à l'intégralité du contenu HTML utile. Le budget de 2 Mo du document HTML doit ainsi être réservé au contenu sémantique, aux balises critiques et aux éléments structurés, et non au code applicatif.
La position des éléments dans le document HTML prend une dimension SEO technique nouvelle à la lumière de ces informations. Les balises meta, le titre, les liens canonicals, les données structurées en JSON-LD et les liens de navigation principaux doivent systématiquement apparaître en tête du document, avant tout contenu volumineux. Cette logique de priorisation des octets critiques rejoint les principes du rendu progressif et du Critical Rendering Path, mais l'enjeu n'est plus seulement la performance perçue par l'utilisateur, c'est la garantie d'indexation par Google.
Que faire
- Auditer régulièrement le poids de vos pages HTML en mesurant la taille brute du document servi par le serveur, en-têtes compris, et identifier les pages approchant ou dépassant le seuil de 2 Mo pour prioriser les optimisations.
- Externaliser systématiquement tout CSS et JavaScript volumineux dans des fichiers séparés plutôt que de les inclure en ligne dans le HTML, afin de préserver le quota de 2 Mo pour le contenu sémantique et les balises critiques.
- Placer en priorité absolue en haut du document HTML les éléments les plus importants pour l'indexation, notamment la balise title, les balises meta (description, robots), les liens canonicals, les balises hreflang et les blocs de données structurées JSON-LD.
- Éliminer ou convertir en fichiers externes les images encodées en base64 directement dans le HTML, car elles consomment une part disproportionnée du quota d'octets sans apporter de valeur au contenu textuel indexé.
- Surveiller les logs serveur pour détecter des ralentissements de temps de réponse susceptibles de déclencher une réduction automatique de la fréquence de crawl par Googlebot, et optimiser les temps de réponse en conséquence.
- Tester le rendu des pages critiques via l'outil d'inspection d'URL de Google Search Console en tenant compte de l'absence d'état de session du WRS, et s'assurer que le contenu principal est accessible sans dépendance à un stockage local ou à des données de session persistées.
Les sites dont les pages HTML dépassent 2 Mo risquent de voir leur contenu critique, leurs balises structurées ou leurs canonicals ignorés par Googlebot si ces éléments sont positionnés après le seuil de coupure. Comprendre et respecter cette limite est désormais une condition sine qua non pour garantir une indexation complète et fiable.