Googlebot et la limite 2 Mo : ce que vos ressources coûtent vraiment au crawl

En février 2026, Google a mis à jour sa documentation officielle pour préciser que Googlebot crawle les 2 premiers Mo de tout fichier HTML, CSS ou JavaScript. Ce qui a semé la confusion, c'est que l'ancienne documentation mentionnait 15 Mo : cette valeur correspond à la limite générale de crawl pour l'ensemble des robots Google, pas à la limite d'indexation Search.

La clarification est importante : ce n'est pas une nouveauté technique. C'est une mise à jour documentaire qui officialise une limite probablement déjà en vigueur. Aucun signal ne laisse penser que Google a modifié son comportement de crawl en même temps. Pour plus de contexte sur cette clarification, j'ai publié une analyse détaillée dans l'article sur les limites de fichiers Googlebot.

Avant de paniquer, regardons ce que disent les données HTTP Archive sur la taille réelle des pages web. La réalité est que la limite de 2 Mo est très rarement atteinte en HTML brut.

La lecture est claire : 99 % des sites web ont un HTML inférieur à 600 Ko, soit moins d'un tiers de la limite Googlebot. Même le centile 99 est trois fois en dessous du seuil. La limite de 2 Mo ne concerne qu'une fraction marginale du web, mais cette fraction existe, et ce sont souvent des sites qui en ont le plus besoin en termes de crawl.

Si les données montrent que la limite est rarement atteinte sur le HTML principal, elle l'est plus fréquemment sur des ressources annexes. Voici les profils que je rencontre lors d'audits.

JavaScript inline massif

Les builders modernes (Elementor, Divi, WPBakery) ont tendance à injecter du JavaScript directement dans le HTML plutôt que de le charger en fichier externe. Une page construite avec Elementor peut facilement dépasser 500 Ko de HTML à cause de ce JS inline, sans que l'éditeur s'en rende compte.

Bundles JS non splittés

Un seul fichier main.js ou app.js qui contient toute la logique de l'application, toutes les dépendances et tous les composants. Sans code splitting, ces bundles atteignent parfois 3 à 5 Mo. Googlebot s'arrête à 2 Mo et n'analyse pas la suite.

Pages catalogue e-commerce surchargées

Les pages catégorie avec des centaines de produits, des filtres dynamiques et des aperçus JSON inline peuvent rapidement dépasser le seuil. Le problème est souvent un script de données structurées JSON-LD généré dynamiquement qui embarque l'intégralité du catalogue dans la page.

CSS globaux non optimisés

Un fichier CSS qui accumule des années de règles sans nettoyage peut dépasser 2 Mo. C'est moins fréquent que le JS, mais des plateformes comme WooCommerce avec de nombreux plugins génèrent parfois des CSS cumulatifs importants.

Entrez la taille approximative de votre fichier HTML non compressé pour situer votre risque :

Avant de lancer des optimisations, mesurez. L'erreur classique est d'optimiser au feeling alors que le problème ne concerne peut-être pas votre site.

Ce que j'utilise en audit

• L'outil Vérificateur de poids Googlebot (rankit.fr) : il fetche le HTML réel via proxy, mesure le poids non compressé et liste chaque ressource. C'est le point de départ indispensable.
• Google Search Console, rapport Couverture : chercher des pages avec des erreurs de crawl inexpliquées : elles peuvent indiquer des ressources trop lourdes.
• Les logs serveur : si Googlebot tronque une ressource, il renvoie un code 206 (Partial Content) ou son UA peut indiquer un timeout. Visible dans les logs Apache/Nginx.
• PageSpeed Insights ne mesure pas la taille non compressée de chaque ressource séparément : il ne suffit pas pour ce diagnostic.
• La taille gzip affichée dans DevTools est trompeuse : un fichier de 80 Ko transféré peut peser 400 Ko décompressé, soit la valeur que Googlebot analyse.

Si votre audit révèle des ressources proches ou au-delà de 2 Mo, voici l'ordre d'intervention que je recommande.

1. Externaliser le JS inline vers des fichiers séparés

C'est l'optimisation au meilleur ratio effort/impact. Un fichier JS externe de 2 Mo a sa propre limite. Le même JS inline dans le HTML réduit d'autant l'enveloppe disponible pour le contenu éditorial de votre page. Sans compter que le JS externe bénéficie du cache navigateur.

2. Code splitting sur les bundles JS

Si votre framework (React, Vue, Angular, Next.js) génère un bundle unique, activez le code splitting pour charger les composants à la demande. Webpack et Vite le font nativement. L'objectif : que chaque fichier JS reste sous 500 Ko décompressé pour avoir une marge confortable.

3. Purger les CSS inutilisés

Des outils comme PurgeCSS ou le built-in de Tailwind éliminent les règles CSS non utilisées. Un framework CSS complet peut représenter 300 Ko ; après purge, il tombe souvent à 10-30 Ko. Impact SEO direct : le CSS est crawlé et analysé par Googlebot pour comprendre votre mise en page.

4. Paginer les contenus JSON-LD massifs

Si vous injectez des données structurées JSON-LD avec des centaines d'éléments (produits, avis, FAQ), découpez-les. Google n'exige pas d'avoir tous les éléments sur une seule page pour les indexer. Une pagination des données structurées est préférable à une page qui déborde.

La limite de 2 Mo de Googlebot concerne le SEO classique, mais la même logique s'applique aux crawlers IA comme OAI-SearchBot ou PerplexityBot. Ces robots ont leurs propres limites de lecture, non documentées officiellement, mais le principe est identique : un fichier trop lourd sera tronqué, et le contenu après la coupure ne sera pas lu.

C'est une raison supplémentaire d'optimiser le poids des pages si vous travaillez une stratégie GEO. Les articles de la série sur les crawlers IA 2026 détaillent les user-agents à surveiller et la configuration robots.txt recommandée pour maximiser votre visibilité dans les moteurs IA.

À propos de l'auteur

Frédéric Jézégou Consultant SEO & GEO

Fondateur de Rankit.fr · Dicocitations SASU · Pornichet (44)

Freelance SEO Senior, 20 ans d'expérience. J'aide les PME à renforcer leur visibilité sur Google tout en intégrant les nouveaux enjeux liés aux moteurs IA. Mon expertise couvre à la fois le SEO classique et les stratégies émergentes de présence dans les IA (GEO), que j'exploite de manière complémentaire selon les objectifs. Approche basée sur des données réelles : logs serveur, tests en compétition, audits de sites.

LinkedIn SEO Technique Me contacter