Googlebot impose-t-il vraiment une limite de 15 Mo au crawl HTML ?

Google fixe une limite technique stricte : 15 Mo de HTML par page. Cette contrainte concerne le document HTML brut, pas les ressources externes (images, CSS, JavaScript). Si votre page dépasse ce seuil, Googlebot arrête le téléchargement et indexe uniquement la portion qu'il a pu récupérer.

Cette déclaration de John Mueller vise à clarifier un paramètre technique souvent méconnu du processus de crawl. Contrairement au crawl budget qui régit la quantité de pages explorées, cette limite porte sur la taille individuelle de chaque document HTML.

Qu'est-ce qui compte dans ces 15 Mo ?

Seul le code HTML source est concerné. Les fichiers JavaScript, CSS, images, vidéos et autres ressources externes chargées via des requêtes séparées n'entrent pas dans le calcul. On parle du document tel qu'il est renvoyé par le serveur lors de la requête initiale.

En pratique, cela signifie que le HTML généré côté serveur, le contenu inline et le DOM initial sont comptabilisés. Si vous injectez massivement du contenu ou des données JSON dans vos balises <script>, ça pèse.

Pourquoi Google impose-t-il cette limite ?

Une question de ressources et de performance. Crawler le web à l'échelle de Google nécessite d'arbitrer entre profondeur d'exploration et efficacité. Télécharger des dizaines de mégaoctets par page ralentirait le processus et consommerait une bande passante considérable pour un bénéfice marginal.

Google part du principe que si votre page HTML pèse plus de 15 Mo, soit vous avez un problème d'architecture, soit le contenu excédentaire n'apporte rien à l'expérience utilisateur ni à la compréhension sémantique de la page.

Quels sites risquent d'être impactés ?

La majorité des sites web ne frôlent même pas cette limite. Une page éditoriale classique pèse entre 50 Ko et 500 Ko de HTML. Même les pages complexes avec beaucoup de contenu dépassent rarement 2-3 Mo.

Les cas à risque ? Les sites e-commerce avec des milliers de produits chargés en dur dans le DOM, les applications web monopages (SPA) qui embarquent l'intégralité de leur state dans le HTML initial, ou les pages infinies générées côté serveur avec du lazy loading mal implémenté.

• 15 Mo de HTML brut : seul le document source compte, pas les ressources externes
• Crawl tronqué : au-delà de la limite, le contenu est ignoré pour l'indexation
• Cas rares : affecte principalement les architectures web lourdes ou mal optimisées
• Aucune pénalité : Google ne sanctionne pas, il arrête simplement de télécharger

Cette limite est-elle cohérente avec les observations terrain ?

Oui. Cette déclaration correspond à ce que nous constatons depuis des années. Google a toujours eu des limites techniques implicites, et celle-ci n'est qu'une formalisation publique d'une contrainte déjà en place. Les audits techniques révèlent régulièrement des pages dont le contenu en bas de page n'est jamais indexé — souvent parce que le HTML est trop lourd ou que le temps de réponse dépasse les seuils de patience de Googlebot.

Cela dit, il faut nuancer : la limite de 15 Mo n'est probablement pas le seul facteur en jeu. D'autres mécanismes (timeout serveur, profondeur DOM, temps de traitement) peuvent couper le crawl bien avant qu'on atteigne ce plafond.

Que nous dit vraiment cette déclaration ?

Soyons honnêtes : cette limite est un signal indirect. Google nous dit entre les lignes que si votre HTML dépasse 15 Mo, vous avez un problème d'architecture. Aucun utilisateur humain ne devrait avoir à charger une telle masse de code pour afficher une page web.

Le message implicite : optimisez votre génération HTML, différez le chargement du contenu secondaire, utilisez le lazy loading côté client, et séparez vos données de votre présentation. [A vérifier] : on manque de données sur la fréquence réelle de dépassement de cette limite et son impact SEO concret. Google affirme que « la plupart des sites » ne sont pas concernés, mais aucune métrique précise n'est fournie.

Quelles sont les zones d'ombre ?

La déclaration reste floue sur plusieurs points. Qu'advient-il exactement du contenu situé après les 15 Mo ? Est-il totalement ignoré, ou Google peut-il y revenir lors d'un crawl ultérieur ? Aucune réponse officielle.

Autre question : cette limite s'applique-t-elle de la même manière au rendering JavaScript ? Si Googlebot exécute le JS et que le DOM résultant dépasse 15 Mo, y a-t-il une seconde limite ? Là encore, silence radio.

Comment vérifier si mon site est concerné ?

Commencez par mesurer le poids HTML brut de vos pages stratégiques. Utilisez les DevTools de Chrome (onglet Network, filtrez sur « Doc ») ou un simple curl -I pour récupérer la taille du document initial. Concentrez-vous sur les pages à fort contenu : fiches produits, pages catégories, articles longs.

Si vous dépassez 5 Mo, creusez. Au-delà de 10 Mo, vous êtes en zone rouge. Inspectez le code source : cherchez les blocs de données JSON embarqués, les variables JavaScript inline, les métadonnées excessives.

Que faire si vous approchez la limite ?

Fragmentez votre contenu. Si vous chargez des milliers de produits en dur dans le HTML, optez pour une pagination côté serveur ou un lazy loading propre. Externalisez les données volumineuses dans des fichiers JSON récupérés en AJAX après le chargement initial.

Nettoyez le code inutile : commentaires HTML verbeux, balises redondantes, scripts inline démesurés. Minifiez votre HTML en production — chaque octet compte. Déléguez le maximum de logique au JavaScript post-chargement plutôt que de tout générer côté serveur.

Quelles erreurs éviter absolument ?

Ne tentez pas de contourner artificiellement la limite en scindant une page en plusieurs fragments cachés que vous chargeriez ensuite en JS. Google détecte ces manipulations et vous risquez une dévalorisation pour cloaking ou contenu masqué.

Évitez aussi de surcharger vos pages avec du contenu uniquement destiné aux moteurs. Si personne ne lit les 12 000 mots de description produit que vous avez générés automatiquement, Google non plus ne les indexera pas — et vous aurez alourdi votre HTML pour rien.

• Mesurez le poids HTML brut de vos pages stratégiques avec les DevTools ou curl
• Identifiez les blocs de données inline (JSON, variables JS) qui alourdissent le document
• Fragmentez les listes longues avec pagination serveur ou lazy loading client
• Externalisez les ressources volumineuses (données produit, configurateurs) en fichiers séparés
• Minifiez le HTML en production et supprimez les commentaires inutiles
• Testez le rendu dans Google Search Console pour vérifier que tout le contenu est bien indexé
• Surveillez les logs serveur pour détecter des crawls incomplets (codes 206, interruptions réseau)