Pourquoi Google impose-t-il une limite de 15 Mo par page crawlée ?

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

Quand Googlebot demande une page, il commence à recevoir le contenu HTML, CSS, JavaScript ou autre. Si la taille totale du fichier dépasse 15 mégaoctets, le crawler coupe la connexion et arrête de recevoir les données restantes.

Cette limite est codée au niveau de l'infrastructure de crawl, pas au niveau algorithmique. Elle s'applique donc à tous les bots Google (Googlebot Desktop, Mobile, Ads, News...) sauf si un crawler spécifique la surcharge — ce qui arrive rarement et de façon opaque.

Pourquoi Google impose-t-il cette contrainte ?

Deux raisons principales : économie de ressources et protection contre les abus. Crawler des milliards de pages coûte cher en bande passante et en temps. Limiter la taille des fichiers empêche qu'un seul domaine monopolise les ressources en servant des fichiers monstrueux.

Deuxième point — une page de 15 Mo, c'est déjà énorme pour du HTML standard. Si votre page fait cette taille, il y a un problème structurel : JavaScript obèse, images inline en base64, CSS redondant.

Cette limite affecte-t-elle l'indexation ?

Oui, directement. Si Googlebot arrête de recevoir les données à 15 Mo, tout ce qui suit est invisible pour l'index. Les liens internes, le contenu textuel, les balises structurées — tout ce qui apparaît après la coupure n'est jamais vu.

Pour les sites dynamiques qui chargent du contenu via JavaScript, c'est encore plus vicieux. Si le JavaScript principal dépasse 15 Mo (bundles mal optimisés, vendors surchargés), le moteur de rendu ne peut pas l'exécuter complètement.

• Limite universelle : 15 Mo s'appliquent à tous les crawlers Google par défaut
• Coupure brutale : aucune négociation, le crawler arrête net de recevoir les données
• Impact indexation : tout contenu au-delà de 15 Mo est perdu pour Google
• Niveau infrastructure : décision technique, pas algorithmique
• Surcharge possible : certains crawlers peuvent outrepasser cette limite, mais c'est rare et non documenté

Cette limite de 15 Mo est-elle cohérente avec les pratiques observées sur le terrain ?

Oui et non. Historiquement, Google a toujours eu des limites de taille de fichier — ce n'est pas une nouveauté. La documentation officielle mentionne depuis des années une limite de « plusieurs mégaoctets » sans jamais donner de chiffre précis.

Ce qui est nouveau, c'est la confirmation explicite : 15 Mo. Avant, on naviguait à l'aveugle. Les tests terrain suggéraient une limite entre 10 et 20 Mo, mais rien d'officiel. Gary Illyes met enfin un chiffre sur la table.

Maintenant, la vraie question — combien de sites dépassent réellement 15 Mo par page ? Honnêtement, très peu. La médiane d'une page web en 2025 tourne autour de 2-3 Mo (HTTP Archive). Les sites qui dépassent 15 Mo sont généralement des cas pathologiques : e-commerce avec des milliers de produits en inline, SPA mal optimisés, pages de documentation sans pagination.

Quelles zones d'ombre subsistent dans cette déclaration ?

Premier point — Gary dit « à moins qu'un crawler ne la surcharge ». [À vérifier] Quels crawlers ? Dans quelles circonstances ? Google ne donne aucun détail.

On peut supposer que certains crawlers spécialisés (Googlebot-Image, Googlebot-Video) ont des limites différentes adaptées à leur usage. Mais c'est une hypothèse, pas un fait documenté.

Deuxième flou — cette limite s'applique-t-elle uniquement au HTML initial ou aussi aux ressources chargées (CSS, JS externes) ? La formulation « le crawler arrête de recevoir les données » suggère que c'est au niveau de chaque requête HTTP individuelle. Si votre page HTML fait 2 Mo mais que votre bundle JS fait 16 Mo, ce bundle sera tronqué.

Cette limite pose-t-elle un problème réel pour la plupart des sites ?

Non, soyons honnêtes. Si votre page fait 15 Mo, vous avez déjà un problème de performance bien avant de vous soucier du crawl. Les utilisateurs sur mobile ou connexion lente ne verront jamais votre contenu.

Cela dit, certains secteurs sont plus à risque : portails d'actualités avec des dizaines de widgets, sites de documentation technique avec du code inline, applications SaaS avec des tableaux de bord complexes. Pour ces cas, la limite de 15 Mo peut devenir un plafond de verre invisible.

Comment vérifier si mon site dépasse la limite de 15 Mo ?

Première étape : auditer la taille de vos pages et ressources. Utilisez les outils DevTools de Chrome (onglet Network) pour mesurer la taille totale de chaque requête HTTP. Filtrez par type (Document, Script, Stylesheet) et vérifiez les fichiers individuels.

Pour automatiser l'audit à grande échelle, des outils comme Screaming Frog ou Sitebulb permettent de crawler votre site et d'extraire la taille de chaque ressource. Exportez les données et triez par taille décroissante — vous verrez immédiatement les outliers.

Attention — ne vous limitez pas au HTML. Vérifiez aussi vos bundles JavaScript et vos feuilles CSS. Un fichier vendor.js de 18 Mo sera tronqué, ce qui peut casser le rendu côté Googlebot.

Quelles optimisations appliquer si des ressources dépassent 15 Mo ?

Premier levier : code splitting. Si vous utilisez un framework moderne (React, Vue, Angular), divisez vos bundles JavaScript en chunks plus petits chargés à la demande. Webpack, Vite ou Rollup le font nativement.

Deuxième action — éliminer le code mort. Tree shaking, suppression des vendors inutilisés, lazy loading des composants non critiques. Un audit avec Lighthouse ou Bundle Analyzer révèle souvent des dizaines de bibliothèques importées mais jamais utilisées.

Pour les images inline (base64), stop immédiatement. Les images doivent être servies en fichiers séparés, optimisées en WebP ou AVIF, avec lazy loading. Une seule image 4K en base64 peut exploser la taille de votre HTML.

Si vous avez des pages de listing avec des centaines de produits, implémentez une pagination stricte ou un système d'infinite scroll avec chargement progressif. Google crawle mieux 10 pages de 50 produits qu'une seule page de 500 produits.

Faut-il surveiller cette métrique en continu ?

Oui, surtout si votre site évolue rapidement. Ajoutez un monitoring automatisé de la taille des ressources dans votre pipeline CI/CD. Définissez des seuils d'alerte : si un bundle dépasse 10 Mo, bloquez le déploiement jusqu'à investigation.

Côté SEO, intégrez cette vérification dans vos audits trimestriels. Les sites dynamiques avec des équipes dev multiples peuvent voir leur poids exploser sans supervision — un plugin ajouté ici, une lib tierce là, et soudain votre page fait 20 Mo.

• Auditer la taille de toutes les pages stratégiques avec DevTools ou Screaming Frog
• Vérifier la taille des bundles JavaScript et CSS — seuil d'alerte à 10 Mo
• Implémenter le code splitting pour diviser les gros fichiers JS en chunks plus petits
• Éliminer les dépendances inutilisées via tree shaking et bundle analysis
• Convertir toutes les images inline (base64) en fichiers externes optimisés
• Paginer ou lazy-loader les listes de produits ou contenus volumineuses
• Configurer des alertes automatiques dans le CI/CD si une ressource dépasse 10 Mo
• Revoir l'architecture de rendu pour les SPA : SSR ou pré-rendu si nécessaire