Pourquoi Googlebot refuse-t-il de crawler les pages HTML de plus de 15 Mo ?

Qu'est-ce que cette limite de 15 Mo signifie concrètement ?

Google ne crawle que les 15 premiers mégaoctets d'un fichier HTML. Si votre page dépasse cette taille, tout ce qui suit est ignoré : liens, contenu, balises structurées. C'est un point de coupure net.

Cette limite s'applique au code source HTML brut, pas aux ressources externes comme les images, CSS ou JavaScript. Un fichier HTML de 15 Mo, c'est colossal — équivaut à environ 15 000 pages Word de texte pur. La plupart des sites n'approcheront jamais ce seuil.

Pourquoi Google impose-t-il cette limite ?

Deux raisons principales : efficacité du crawl et protection des ressources. Explorer des fichiers HTML gigantesques consomme du temps machine et de la bande passante. Google doit prioriser.

De plus, un fichier HTML de cette taille signale souvent un problème technique : intégration chaotique de données JSON-LD massives, inclusion inline de milliers de lignes de SVG, ou erreur de génération côté serveur qui duplique du contenu à l'infini.

Quels types de sites risquent de dépasser cette limite ?

Très peu, en réalité. Les cas à risque incluent les pages de listings massifs (milliers de produits sur une seule page sans pagination), les sites embarquant des données structurées volumineuses directement dans le HTML, ou des single-page applications mal optimisées qui génèrent des DOM énormes côté serveur.

Les sites e-commerce avec filtres infinis ou les plateformes de données financières affichant des tableaux interminables sont les premiers suspects. Mais encore une fois : c'est exceptionnel.

• Limite stricte : 15 Mo par fichier HTML, tout dépassement est ignoré
• Périmètre : HTML brut uniquement, pas les ressources externes (images, scripts, CSS)
• Risque principal : perte de contenu, liens non crawlés, indexation partielle
• Sites concernés : pages de listings massifs, données structurées volumineuses inline, erreurs de génération serveur

Cette limite est-elle vraiment un problème pour la majorité des sites ?

Non. Soyons honnêtes : moins de 0,01 % des pages web dépassent 15 Mo de HTML. C'est une limite qui protège Google des configurations aberrantes, pas une contrainte courante. Si votre site est concerné, c'est qu'il y a un souci structurel à corriger de toute façon.

Les pages normales oscillent entre 50 Ko et 500 Ko de HTML. Même les pages complexes d'e-commerce avec beaucoup de contenu restent sous 2 Mo. Atteindre 15 Mo nécessite une accumulation d'erreurs techniques ou une architecture fondamentalement inadaptée.

Quels sont les cas limites qu'il faut surveiller ?

Les pages de résultats de recherche internes avec des milliers d'entrées affichées d'un coup, sans pagination. Les sites qui intègrent des JSON-LD massifs pour des événements ou des produits par milliers. Les plateformes embarquant des SVG complexes directement dans le HTML au lieu de les servir comme fichiers externes.

Et puis il y a les erreurs de génération côté serveur : boucles infinies, duplication de blocs entiers, includes mal configurés qui empilent du contenu. Ces bugs créent des fichiers HTML monstrueux. [À vérifier] : Google ne précise pas si cette limite s'applique après compression gzip/brotli ou avant — mais il est raisonnable de supposer qu'elle s'applique au HTML brut, non compressé.

Cette règle impacte-t-elle le JavaScript rendering ?

Bonne question. La limite concerne le fichier HTML initial reçu par Googlebot, pas le DOM final après exécution du JavaScript. Si votre page génère 20 Mo de contenu côté client via JS, ce n'est pas directement concerné par cette règle.

Mais attention : une page qui génère un DOM gigantesque côté client aura d'autres problèmes (performance, Core Web Vitals, timeout du renderer). La limite de 15 Mo ne vous sauvera pas d'une architecture JavaScript catastrophique.

Comment vérifier si mon site dépasse cette limite ?

Première étape : audit des fichiers HTML. Utilisez un outil comme Screaming Frog ou OnCrawl pour extraire la taille des pages en octets. Triez par taille décroissante et identifiez les pages au-delà de 10 Mo — elles méritent une analyse détaillée.

Vous pouvez aussi interroger vos logs serveur : filtrez les requêtes de Googlebot et regardez la taille des réponses HTTP (header Content-Length). Si vous voyez des fichiers HTML de plusieurs mégaoctets, c'est un signal d'alarme.

Quelles actions correctives mettre en place ?

Si une page dépasse la limite, trois axes d'optimisation : pagination, externalisation, et nettoyage du code. Découpez les listings massifs en pages plus petites avec une pagination claire. Externalisez les données structurées volumineuses dans des fichiers JSON séparés si possible, ou réduisez leur granularité.

Côté technique : supprimez les SVG inline inutiles, les scripts et styles embarqués (passez-les en fichiers externes), et traquez les erreurs de génération (boucles, duplications). Un fichier HTML propre ne dépasse jamais quelques centaines de Ko, même pour des pages riches.

Faut-il surveiller cette métrique en continu ?

Oui, surtout si votre site génère du contenu dynamique ou agrège des données volumineuses. Intégrez un monitoring automatique de la taille des fichiers HTML dans votre pipeline de déploiement. Une alerte à 5 Mo vous laisse de la marge avant d'atteindre la limite critique.

Les outils de log analysis (OnCrawl, Botify) peuvent vous aider à détecter les pages anormalement lourdes crawlées par Googlebot. Configurez des alertes automatiques si une URL dépasse un seuil prédéfini.

• Auditer la taille des fichiers HTML avec Screaming Frog ou OnCrawl
• Analyser les logs serveur pour identifier les réponses volumineuses à Googlebot
• Paginer les listings massifs plutôt que d'afficher des milliers d'entrées sur une page
• Externaliser les SVG, scripts et styles inline en fichiers séparés
• Réduire la granularité des JSON-LD si nécessaire
• Configurer un monitoring continu avec alertes au-delà de 5 Mo