Serveurs et lignes de code représentant Googlebot crawlant le HTML d'une page web

L'essentiel en 20 secondes

  • Le fait : le 23 juin 2026, Google a précisé dans sa documentation combien d'octets de contenu textuel Googlebot crawle.
  • Le chiffre : 2 Mo pour le HTML et les fichiers texte, 64 Mo pour les PDF — sur données décompressées, en-têtes HTTP inclus.
  • Le risque : au-delà de 2 Mo, Googlebot coupe la lecture. Le contenu et les données structurées placés après le seuil ne sont jamais indexés.
  • À faire : alléger le HTML, externaliser CSS/JS, et remonter le contenu utile en haut du fichier.

Le 23 juin 2026, Google a mis à jour sa documentation officielle pour préciser combien d'octets de contenu textuel — du HTML notamment — Googlebot télécharge réellement sur une page, via la page « What Is Googlebot » du Search Central. La réponse tient en un chiffre : Googlebot crawle les 2 premiers Mo d'un fichier HTML pour la recherche Google, et les 64 premiers Mo d'un PDF.

Ce n'est pas une nouvelle limite. C'est une clarification de la règle introduite en mars 2026 dans le billet « Inside Googlebot », qui distinguait pour la première fois deux phases — la récupération (fetching) et l'indexation (indexing). La mise à jour de juin précise ce que recouvre exactement le seuil de 2 Mo et lève une ambiguïté qui traînait dans la communauté SEO depuis le printemps.

Ce que dit précisément la documentation

Trois points méritent qu'on s'y arrête, parce qu'ils changent la façon de construire une page :

2 Mode HTML crawlé par Googlebot pour la recherche
64 Mopour un fichier PDF
0octet indexé au-delà du seuil
  • La limite porte sur les données décompressées. Votre serveur sert peut-être 300 Ko en gzip, mais c'est le poids une fois décompressé qui compte. Un HTML « léger » sur le réseau peut être lourd à l'arrivée.
  • Les en-têtes de la requête HTTP sont inclus dans le décompte. Marginal sur la plupart des sites, mais réel.
  • Le dépassement n'est pas un rejet, c'est une amputation. Une fois les 2 Mo atteints, Googlebot arrête le téléchargement et n'envoie que la partie déjà récupérée à l'indexation. Le reste n'existe pas pour Google.

Chaque ressource appelée par la page (CSS, JavaScript) est récupérée séparément et soumise à la même limite. Le HTML, lui, est un seul fichier : tout ce qu'il contient — menus, scripts inline, images encodées en base64 — consomme votre budget de 2 Mo avant même que votre article ne commence.

Pourquoi c'est un vrai sujet pour les PME

Sur le papier, 2 Mo de HTML brut, c'est énorme : une page saine pèse rarement plus de 100 Ko de balisage. En pratique, plusieurs architectures modernes gonflent le HTML sans qu'on s'en rende compte :

  • des images encodées en base64 directement dans le HTML, qui pèsent chacune des centaines de kilo-octets ;
  • des blocs massifs de CSS et de JavaScript inline, fréquents sur les sites générés par des page builders ou des frameworks mal configurés ;
  • des méga-menus et des données dupliquées en tête de document, qui repoussent le contenu réel vers le bas ;
  • des sorties de frameworks JS qui sérialisent l'état complet de l'application (hydration payloads) dans le HTML.

Le danger est silencieux : la page s'affiche parfaitement pour l'utilisateur, mais le contenu situé après la barre des 2 Mo — ou vos données structurées JSON-LD si elles sont en pied de page — ne sont jamais lus. Ce sujet rejoint directement la façon dont Google découpe et lit le contenu pour la recherche et les IA : si le robot n'atteint pas votre texte, ni Google ni les moteurs génératifs ne peuvent le citer.

L'angle GEO. La même logique vaut pour la visibilité dans les réponses IA. Les moteurs génératifs s'appuient sur du contenu accessible et lisible côté serveur. Un HTML obèse qui enterre votre expertise sous des kilo-octets de code n'est pas seulement un problème de SEO classique — c'est un problème pour être cité par l'IA.

Ce qu'il faut faire maintenant

  1. Mesurez votre HTML brut. Pas le poids rendu dans le navigateur : le HTML source, non compressé. En ligne de commande : curl -s https://votresite.fr/page | wc -c. Si vous approchez le mégaoctet, agissez.
  2. Externalisez CSS et JavaScript. Sortez-les du HTML vers des fichiers .css et .js dédiés. Ils sont crawlés à part, avec leur propre limite.
  3. Bannissez les images base64 du HTML. Servez-les comme fichiers .webp avec une vraie URL. Le base64 inline est le pire ennemi de votre budget d'octets.
  4. Remontez le contenu utile en haut du fichier. Votre texte principal et vos données structurées doivent arriver tôt dans le HTML, pas après 1,8 Mo de menus et de scripts.
  5. Vérifiez vos données structurées. Le JSON-LD placé tard dans le document est le premier à sauter en cas de page lourde. Placez-le dans le <head>.

Ce réflexe d'hygiène technique va de pair avec la qualité éditoriale : Google construit désormais des profils d'entités à partir de ce qu'il lit sur votre site, comme le montre un récent brevet sur la façon dont l'IA apprend des sites web. Encore faut-il que le robot atteigne ce contenu.

Votre HTML est-il lisible par Google et les IA ?

Cicéro audite la visibilité technique et éditoriale de votre site — sur Google comme dans les réponses IA — puis produit le contenu qui convertit. La qualité d'une agence, la productivité d'un software, de 250 € à 1 800 € / mois.

Notre analyse

Cette mise à jour ne révolutionne rien — elle remet une vieille discipline au centre. Pendant des années, le poids du HTML était un sujet de performance ; il devient un sujet d'indexabilité. La leçon est limpide : votre contenu doit être atteignable avant le code. Les sites qui empilent les frameworks sans surveiller leur poids brut prennent le risque que Google — et les IA qui s'appuient sur lui — ne lisent jamais l'essentiel. 2 Mo, c'est large. Le problème, ce n'est pas la limite : c'est tout ce qu'on met devant le contenu.

Sources

Questions fréquentes

Quelle est la limite d'octets que Googlebot crawle sur une page HTML ?
Pour la recherche Google, Googlebot crawle les 2 premiers Mo d'un fichier HTML (et des fichiers texte pris en charge), et les 64 premiers Mo d'un PDF. La limite s'applique aux données décompressées et inclut les en-têtes de la requête HTTP. Une fois ce seuil atteint, Googlebot arrête le téléchargement et n'envoie que la partie déjà récupérée à l'indexation.
Ma page de plus de 2 Mo est-elle rejetée par Google ?
Non. Google ne rejette pas la page. Il coupe la lecture à 2 Mo. Le risque n'est pas le rejet mais l'amputation : si votre contenu réel ou vos données structurées arrivent après le seuil, ils ne sont jamais pris en compte pour l'indexation.
Comment vérifier le poids HTML de ma page ?
Mesurez le HTML brut, non rendu et non compressé, par exemple avec curl -s URL | wc -c, ou via l'outil d'inspection d'URL de la Search Console. Visez largement sous le seuil de 2 Mo : la plupart des pages saines pèsent moins de 100 Ko de HTML, hors images et ressources externes.

Ce que cet article ne couvre pas

On parle ici de la limite d'octets de contenu textuel (HTML et fichiers texte) appliquée par Googlebot pour la recherche. Cet article ne traite pas de la limite de fetching de 15 Mo applicable aux crawlers génériques, ni du budget de crawl global (fréquence et nombre d'URL explorées), ni des limites de rendu JavaScript (WRS), qui obéissent à d'autres mécanismes. Les chiffres cités sont ceux publiés par Google ; ils peuvent évoluer — vérifiez toujours la documentation source à jour.

Alexis Dollé, fondateur de Cicéro
Alexis Dollé
CEO & Fondateur

Spécialiste du growth et de la stratégie de contenu SEO, j'ai lancé Cicéro pour aider les entreprises à capter une visibilité organique durable — sur Google comme dans les réponses des IA. Chaque contenu qu'on produit est pensé pour convertir, pas juste pour exister.

LinkedIn