Googlebot s'arrête-t-il vraiment à 15 Mo par URL ?

Quelle est exactement cette limite de 15 Mo ?

Google fixe une limite de crawl à 15 mégaoctets pour chaque URL crawlée. Concrètement, Googlebot télécharge le contenu brut d'une page jusqu'à atteindre ce seuil, puis arrête net le téléchargement.

Cette limite s'applique au document HTML principal uniquement. Les ressources externes — CSS, JavaScript, images, vidéos — référencées dans ce HTML bénéficient chacune de leur propre quota de 15 Mo. Autrement dit, une page HTML de 10 Mo qui charge un script de 12 Mo et une feuille de style de 8 Mo passe sans problème.

Pourquoi Google impose-t-il cette contrainte ?

La raison est simple : protéger l'infrastructure de crawl. Google traite des milliards d'URLs quotidiennement. Sans garde-fou, un site mal configuré pourrait envoyer des documents de plusieurs centaines de mégaoctets, saturant les ressources du crawler.

Cette limite évite aussi les abus — volontaires ou non. Pages générées dynamiquement sans fin, flux JSON démesurés, fichiers logs exposés par erreur : autant de cas qui exploseraient le crawl budget sans apporter de valeur.

Que se passe-t-il si ma page dépasse 15 Mo ?

Googlebot coupe la récupération à 15 Mo exactement. Le contenu au-delà de ce seuil n'est jamais vu ni indexé. Si votre texte crucial apparaît après 16 Mo de HTML, il restera invisible pour Google.

Aucune alerte n'est envoyée dans la Search Console. Pas de notification, pas de warning. Le crawl s'arrête silencieusement, et vous découvrez le problème quand vos pages ne rankent pas ou affichent des extraits tronqués.

• Limite de 15 Mo par URL, appliquée au contenu brut (HTML, JSON, XML...)
• Chaque ressource référencée (CSS, JS, images) a sa propre limite de 15 Mo
• Le contenu au-delà de 15 Mo n'est jamais crawlé ni indexé
• Aucun avertissement dans la Search Console en cas de dépassement
• Cette règle vise à protéger l'infrastructure de Google et éviter les abus

Cette limite de 15 Mo pose-t-elle problème en pratique ?

Soyons honnêtes : la majorité des sites web ne s'approchent même pas de ce seuil. Une page HTML classique pèse entre 50 Ko et 500 Ko. Même un article long format avec du rich media intégré dépasse rarement 2-3 Mo de HTML pur.

Là où ça coince ? Les sites e-commerce avec des listings produits démesurés chargés en une seule page, les plateformes SaaS qui injectent des datasets JSON massifs dans le DOM, ou encore les sites d'actualités qui empilent des dizaines d'articles sur une même URL en scroll infini. Dans ces cas, 15 Mo peuvent fondre vite.

Google est-il transparent sur ce qui compte dans ces 15 Mo ?

Martin Splitt parle de "contenu brut", ce qui inclut le HTML non compressé. Mais qu'en est-il du JavaScript inline ? Des données JSON embarquées dans des balises <script> ? Des SVG intégrés directement dans le markup ?

[À vérifier] Google ne précise pas si la compression HTTP (gzip, Brotli) est prise en compte avant ou après cette limite. Si Googlebot décompresse d'abord, un HTML de 3 Mo compressé pourrait peser 12 Mo brut et frôler la limite. Aucune donnée officielle là-dessus.

Faut-il surveiller activement cette métrique ?

Oui, surtout si vous opérez sur des verticales à fort volume de contenu. E-commerce, comparateurs de prix, annuaires, sites d'emploi : autant de secteurs où les pages gonflent facilement.

Le problème ? Il n'existe pas d'outil Google pour monitorer ce seuil. Vous devez mesurer manuellement la taille du HTML retourné pour vos principales templates. Un simple curl -I avec Content-Length ne suffit pas toujours — certains serveurs ne renvoient pas cette en-tête ou servent du contenu compressé.

Comment vérifier si mes pages dépassent la limite ?

Commence par identifier tes templates à risque : pages catégories, listings, archives, pages de résultats de recherche interne. Ce sont elles qui accumulent le plus de contenu.

Ensuite, mesure la taille réelle du HTML retourné. Utilise curl -s https://tonsite.com/page | wc -c pour obtenir la taille en octets du contenu brut. Si tu dépasses 10-12 Mo, tu es en zone dangereuse.

Quelles optimisations mettre en place si je dépasse ?

Première piste : pagination ou lazy loading. Au lieu de charger 500 produits sur une seule page, découpe en pages de 50 produits. Ou implémente un scroll infini qui charge le contenu via AJAX après le rendu initial.

Deuxième levier : nettoyer le HTML superflu. Commentaires de debug, espaces inutiles, JSON-LD redondant, attributs data-* démesurés... tout ça pèse. Minifie et compresse agressivement.

Enfin, si tu embarques des datasets JSON pour tes apps React/Vue, externalise-les. Plutôt que de les inline dans le HTML, charge-les via un endpoint dédié. Ça allège le document principal et respecte la limite par ressource.

Que faire si je ne peux pas réduire la taille ?

Si ton contenu est légitime et ne peut être découpé — par exemple, une documentation technique exhaustive sur une seule page — tu devras accepter que Google ne crawle qu'une partie. Dans ce cas, assure-toi que le contenu crucial apparaît dans les premiers 10 Mo.

Alternativement, restructure ton architecture pour que chaque section majeure soit une URL distincte. Ça améliore aussi le maillage interne et la granularité de ton indexation.

• Auditer les templates à fort volume de contenu (catégories, listings, archives)
• Mesurer la taille réelle du HTML brut avec curl ou des outils de monitoring
• Mettre en place une pagination ou du lazy loading pour les contenus longs
• Nettoyer le HTML : minification, suppression des commentaires, optimisation des data attributes
• Externaliser les gros datasets JSON au lieu de les inline dans le HTML
• Prioriser le contenu important dans les premiers mégaoctets du document
• Surveiller régulièrement la taille des pages après chaque déploiement