Google impose un plafond strict sur la quantité d’une page qu’il va réellement récupérer et transmettre pour l’indexation, et ce plafond peut être plus petit que ce que beaucoup d’équipes supposent. Si votre HTML dépasse la limite, Google peut toujours explorer l’URL, mais il peut effectivement « arrêter de lire » en cours de source.
Cela importe pour les audits techniques de SEO car le mode d’échec est subtil : vous ne verrez peut‑être pas d’erreur évidente dans Google Search Console, et pourtant un contenu important, des liens internes ou des données structurées peuvent se trouver au‑delà de la portion explorée et ne jamais atteindre l’indexation. Ci‑dessous une approche d’audit pratique fondée sur la documentation officielle de Google et des tests récents de février 2026.
1) Comprendre les deux limites : 2 Mo pour Googlebot (Search) vs 15 Mo par défaut
La documentation de Google décrit désormais plus d’une limite de taille de fichier, selon le crawler/récupérateur impliqué. Officiellement, Googlebot (Search) ne parcourt que les premiers 2 Mo d’un type de fichier pris en charge, et pour les PDF la limite est de 64 Mo ; après le seuil, Googlebot cesse la récupération et ne transmet pour l’indexation que ce qu’il a déjà téléchargé.
Séparément, Google indique aussi : « Par défaut, les crawlers et récupérateurs de Google ne récupèrent que les 15 Mo initiaux d’un fichier », et que des projets peuvent définir des limites différentes selon le crawler et le type de fichier. Cela crée une division apparente dans les docs : une section met en avant le seuil général de 15 Mo, tandis qu’une autre section (plus spécifique) souligne le comportement à 2 Mo pour Googlebot utilisé pour l’indexation dans la recherche.
Des articles de la profession début février 2026 (par ex. Search Engine Land et Search Engine Journal) présentent cela comme une clarification/réorganisation de la documentation plutôt que comme un changement de comportement confirmé. Dans le même contexte, Spotibo a cité via SERoundtable une citation attribuée à John Mueller : « Googlebot est un des crawlers de Google, mais pas tous », et une autre : « Aucun de ces éléments n’a récemment changé, nous avons juste voulu les documenter plus en détail. » Pour les auditeurs, la leçon est simple : vous devez auditer en fonction de la bonne limite du crawler pour l’issue qui vous intéresse, le classement et l’indexation dans Google Search.
2) Ce que la coupure à 2 Mo signifie en pratique pour l’indexation
La formulation officielle de Google est explicite : après le seuil de taille de fichier, Googlebot cesse la récupération et ne transmet pour l’indexation que ce qu’il a déjà téléchargé. Cela signifie que le contenu situé après la coupure n’est pas simplement « dépriorisé », il peut ne jamais être vu par le pipeline d’indexation.
En termes de SEO, tout texte, entités, titres, liens internes, indices canoniques dans le HTML, ou données structurées apparaissant après la limite est à risque. Les recommandations de Seobility de février 2026 s’alignent sur cela : si le HTML dépasse 2 Mo, Google peut ignorer le texte/les liens internes/les données structurées situés après la coupure, ce qui peut affecter la découvrabilité (liens internes) et l’éligibilité aux résultats enrichis (données structurées) si ce balisage est poussé trop bas.
Une nuance importante pour les audits : la limite s’applique à la taille de fichier non compressée. Ainsi, une page qui transfère un petit payload gzip/brotli peut néanmoins dépasser le seuil exploitable une fois décompressée. Ne prenez pas la « taille du transfert réseau » dans un navigateur comme référence ; mesurez les octets non compressés réels que Google traiterait.
3) Les sous‑ressources sont des récupérations séparées, et chacune a son propre plafond
Google a clarifié que chaque ressource référencée, comme le CSS et le JavaScript, est récupérée séparément, et que chaque récupération est soumise à la même limite de taille de fichier (avec l’exception des PDF). Cela a été confirmé dans le billet du Search Central Blog (28 juin 2022) et la clarification du 16 mars 2023 dans ce même billet : chaque récupération de sous‑ressource individuelle (notamment CSS/JS) est également soumise à la limite de 15 Mo décrite là.
Pour les audits, cela signifie que vous ne pouvez pas « lisser » les choses sur l’ensemble de la page. Un petit document HTML qui référence un bundle JavaScript extrêmement volumineux peut quand même rencontrer une troncature ou des contraintes de traitement au niveau de la sous‑ressource. De même, un fichier CSS alourdi par des assets intégrés ou des frameworks gigantesques peut atteindre le plafond même si le HTML est modeste.
Cela explique aussi pourquoi certains sites voient des divergences déroutantes : le HTML peut être inférieur à 2 Mo, mais les scripts nécessaires pour rendre un contenu significatif (pour les applications côté client) peuvent être limités par le plafond par fichier. Si le code critique pour le rendu est tronqué, Google peut ne pas exécuter la page comme prévu, et des contenus ou liens clés peuvent ne pas apparaître dans le DOM rendu qui sera indexé.
4) Preuves issues de tests de février 2026 : troncation de la source indexée sans avertissement
Les tests de Spotibo de février 2026 fournissent une illustration pratique du risque. Dans un test, une page HTML d’environ 3 Mo a été indexée, mais la source indexée était tronquée après 2 Mo, et il n’y avait aucun avertissement dans Search Console. C’est exactement le type d’échec silencieux qui rend l’audit proactif nécessaire.
Spotibo a également observé que le « test en direct » de l’inspection d’URL affichait la source complète de 3 Mo, alors que la version indexée était coupée. Cela suggère que l’outil d’inspection peut utiliser un chemin crawler/récupérateur différent de celui employé par Googlebot pour l’indexation, cohérent avec la déclaration plus large de Google selon laquelle plusieurs crawlers/récupérateurs existent et peuvent avoir des limites différentes.
Dans un autre test de Spotibo, un fichier HTML très volumineux (environ 16 Mo) a entraîné l’échec de la demande d’indexation avec une erreur (« Something went wrong… ») et a affiché des données d’exploration N/A. Bien que ce soit un cas extrême, cela souligne que, au‑delà de la troncature, des fichiers très volumineux peuvent provoquer des échecs de traitement dans des outils ou pipelines, faisant du contrôle de la taille un enjeu de stabilité, pas seulement une bonne pratique de SEO.
5) Priorités dans un audit : garder le contenu critique en début de HTML
Un cadre couramment utilisé pour les audits est de prioriser « le contenu critique au début du HTML » afin qu’il ne puisse pas être poussé au‑delà de la coupure à 2 Mo. « Critique » inclut typiquement : le contenu textuel principal, les principales balises, les liens internes qui favorisent la découverte, les directives canonical et robots, et les données structurées nécessaires pour les résultats enrichis.
Concrètement, cela signifie vérifier l’ordre de votre balisage. Si votre template place d’énormes systèmes de navigation, des blocs de filtres facettés, des mega‑menus ou des widgets répétés au‑dessus du contenu principal, vous risquez de gaspiller des octets explorables sur du boilerplate. De même, si vos données structurées sont injectées tardivement (ou ajoutées après de gros blocs de script), elles peuvent se retrouver au‑delà de la coupure.
Utilisez une marge de sécurité plutôt que de considérer 2 Mo comme un objectif à atteindre. Une heuristique de l’industrie consiste à signaler tout fichier HTML/JS/JSON unique approchant ~1,8, 2,0 Mo non compressé, laissant de la place pour de petits changements de template, l’expansion de la localisation, des snippets d’A/B testing, ou des schémas supplémentaires qui pourraient vous faire dépasser.
6) Schémas de gonflement courants qui poussent les pages au‑delà de la limite
Les frameworks modernes peuvent gonfler le HTML d’une manière que les équipes ne remarquent pas durant le développement habituel. Un schéma à haut risque est la présence de gros JSON inline ou de payloads d’« état » sérialisés (pour l’hydratation) intégrés directement dans le HTML. Ces blobs peuvent être massifs et apparaissent souvent avant ou autour du contenu principal, consommant rapidement les octets explorables.
D’autres sources de gonflement incluent les images en base64 inline, le CSS/JS inline, et des navigations/filtres surdimensionnés qui génèrent des milliers de liens ou d’options. Même quand ces éléments sont « utiles », ils peuvent repousser ce que vous voulez surtout que Google indexe : textes uniques, descriptions de produits, contenus éditoriaux et un maillage interne clair qui favorise la découverte.
Les auditeurs doivent aussi surveiller les motifs de duplication : blocs JSON‑LD répétés, balisage de composants répété dans des listes rendues côté serveur, ou DOM caché massif (onglets/accordéons) généré pour chaque variante. Ceux‑ci ne ralentissent pas seulement les pages, ils peuvent littéralement repousser des signaux indexables au‑delà de ce que Googlebot (Search) récupère.
7) Comment mesurer correctement et éviter la confusion documentaire
Parce que la documentation de Google comporte plusieurs affirmations en circulation, les auditeurs doivent noter un instantané contradictoire/ancien : certaines versions de la documentation « Qu’est‑ce que Googlebot » mentionnent encore une limite de 15 Mo pour le HTML/texte. Pendant ce temps, la section plus récente « Googlebot for Search » met l’accent sur le plafond de 2 Mo pour les types de fichiers pris en charge (et 64 Mo pour les PDF). Lors d’un audit, confirmez que vous lisez la documentation la plus récente et la plus spécifique pertinente pour l’indexation dans la Recherche.
Côté mesure, validez la taille non compressée. Dans un test contrôlé, récupérez le HTML brut, décompressez‑le si nécessaire, et mesurez les octets. Pour votre workflow d’audit, stockez la tranche des premiers 2 Mo et comparez ce qui vient après, puis vérifiez spécifiquement si des éléments importants (corps principal, liens primaires, JSON‑LD) se trouvent au‑delà de cette limite.
Enfin, utilisez les outils de Search Console avec précaution. Les résultats de Spotibo impliquent que le « test en direct » d’inspection d’URL peut afficher un contenu qui ne correspond pas à ce qui a finalement été indexé lorsque Googlebot (Search) applique la coupure à 2 Mo. Servez‑vous de l’inspection pour le diagnostic, mais confirmez la réalité de l’indexation en vérifiant le comportement de la source mise en cache/indexée lorsque c’est disponible, et en vous assurant que vos templates sont sûrs même sous la contrainte plus stricte des 2 Mo.
Auditer la limite de 2 Mo de Googlebot relève moins de la course après un chiffre arbitraire que de la préservation de la portion de vos pages qui atteint réellement l’indexation. La guidance officielle de Google indique qu’après la coupure, Googlebot cesse la récupération et ne transmet que ce qu’il a déjà téléchargé, donc tout ce qui dépasse la limite peut être invisible pour la Recherche.
L’approche la plus résiliente est de garder le HTML léger, de placer le contenu critique et les données structurées en tête, et de mettre en place des alertes automatisées lorsque des fichiers clés approchent ~1,8, 2,0 Mo non compressés. Au vu des tests récents montrant des troncations silencieuses et des comportements différents entre les outils « en direct » et la réalité indexée, un audit proactif de la taille est désormais une nécessité pratique pour le SEO technique.
