Votre page pèse 180 Ko de HTML. Vous avez des données structurées, des balises canoniques, des liens internes. Tout ça en bas du code. Googlebot s’est arrêté bien avant. Il ne les a jamais vus.
Le 31 mars 2026, Gary Illyes a publié sur Google Search Central une explication détaillée du fonctionnement interne de l’infrastructure de crawl. Pas un billet de blog vague. C’est la première fois que Google décrit aussi précisément ce qui se passe entre le moment où le fetcher arrive sur votre URL et le moment où votre contenu entre dans l’index. Ou n’y entre pas.
Googlebot n’a jamais été un seul robot
Le nom « Googlebot » date des années 2000, quand Google n’avait qu’un produit et un seul crawler. Ce nom est resté. Mais aujourd’hui, Googlebot est un client parmi d’autres dans une infrastructure de crawl centralisée.
Quand vous lisez « Googlebot » dans vos logs serveur, vous voyez le trafic de Google Search. Pas celui de Google Shopping, d’AdSense ou des dizaines d’autres services qui passent par la même infrastructure. Chacun a son nom de crawler, tous listés sur la page Google Crawling Infrastructure.
Les plages IP que vous bloquez ou autorisez sous le nom « Googlebot » ne couvrent qu’une partie de l’activité réelle de Google sur votre serveur.
La limite de 2 Mo : ce que Googlebot télécharge vraiment
Googlebot ne télécharge que les 2 premiers Mo de chaque URL HTML, en-têtes HTTP compris. Pour les PDF, c’est 64 Mo. Pour les crawlers sans limite spécifiée, 15 Mo par défaut. Ces chiffres sont documentés officiellement par Google (Google Search Central Blog, 31 mars 2026).
Le comportement exact quand ce seuil est atteint est ce qui importe pour le SEO :
- Le fetch s’arrête net à 2 Mo. Googlebot ne rejette pas la page : il coupe le téléchargement au seuil exact.
- La portion récupérée est transmise aux systèmes d’indexation et au Web Rendering Service (WRS) comme s’il s’agissait du fichier complet. Aucun signal d’erreur.
- Tout ce qui dépasse est invisible. Ces octets ne sont pas fetchés, pas rendus, pas indexés. Pour Googlebot, ils n’existent pas.
- Les ressources liées (CSS, JavaScript) sont fetchées séparément, avec leur propre compteur de 2 Mo.
Le point le plus sous-estimé de cette publication : vous ne recevrez aucune alerte dans la Search Console si votre contenu est coupé. Le WRS traite le tronqué comme un fichier normal. L’erreur est silencieuse.
Le Web Rendering Service après le fetch
Une fois les octets récupérés, le WRS prend le relais. Il exécute JavaScript et CSS côté client, comme un navigateur moderne, pour comprendre l’état final de la page. Il traite aussi les requêtes XHR.
Mais le WRS ne peut exécuter que le code effectivement téléchargé par le fetcher. Si votre JavaScript de rendu du contenu principal est situé après 2 Mo de HTML lourd, il n’est jamais chargé. Point.
Autre détail qui compte : le WRS fonctionne sans état. Il efface les données de stockage local et de session entre chaque requête. Les éléments dynamiques qui dépendent d’un état persistant ne sont pas rendus comme un utilisateur connecté les verrait.
Les pratiques qui consomment votre quota sans bruit
Pour la majorité des sites, 2 Mo de HTML c’est énorme. Une page standard de 80 à 150 Ko est largement en dessous. Mais certaines pratiques créent des pages bien plus lourdes :
- Des images en base64 intégrées directement dans le HTML
- De larges blocs de CSS ou JavaScript en inline
- Des menus de navigation volumineux placés en début de code
- Des tableaux de données complets intégrés dans la page au lieu d’être chargés via XHR
Si ces éléments poussent vos données structurées, vos balises canoniques ou vos liens internes au-delà du seuil, Googlebot ne les verra jamais. Et vous ne le saurez pas.
Quoi changer dans votre HTML
Externalisez le CSS et le JavaScript dans des fichiers séparés. Ces ressources sont fetchées indépendamment, avec leur propre quota. Un fichier CSS de 500 Ko inline dans votre HTML consomme votre quota HTML. Le même fichier en externe, non.
Placez vos éléments critiques en haut du document. Balises meta, titre, canonicals, liens, données structurées : tout ça doit apparaître le plus tôt possible dans le code. L’ordre du HTML détermine ce que Googlebot indexe.
Surveillez vos logs serveur. Des temps de réponse élevés incitent les fetchers à réduire la fréquence de crawl. Ce n’est pas visible dans la Search Console. Ça se lit dans les logs.
Migration des fichiers de plages IP : 6 mois pour agir
En parallèle, Google a annoncé le déplacement de ses fichiers JSON listant les plages IP des crawlers Google. Ces fichiers, jusqu’ici disponibles sous /search/apis/ipranges/ sur developers.google.com, migrent vers /crawling/ipranges/.
Logique : ces plages IP concernent bien plus que le seul Googlebot Search. L’ancien chemin restera accessible pendant la transition mais Google prévoit de le supprimer et d’y appliquer une redirection dans un délai de 6 mois à partir du 31 mars 2026.
Si vous utilisez ces fichiers JSON pour filtrer les accès serveur, autoriser les crawlers Google dans votre pare-feu ou vérifier l’authenticité des requêtes, mettez à jour vos scripts maintenant. Pas dans 5 mois. La suppression n’attendra pas.
La vérification d’authenticité reste la même : reverse DNS lookup pour confirmer que le nom est dans le domaine googlebot.com, suivi d’un forward DNS lookup de confirmation. La méthode ne change pas. L’URL du fichier de référence, si.
L’ordre du HTML compte plus qu’on ne le croit
Gary Illyes n’a pas publié un billet anodin. L’ordre et le poids de votre HTML ont des conséquences directes sur ce qui est indexé. C’est écrit noir sur blanc.
La plupart des audits SEO ne vérifient pas le poids brut du HTML. Ils vérifient la vitesse de chargement, les Core Web Vitals, la présence des balises. Pas l’ordre des éléments dans le code source.
Si votre page pèse 1,9 Mo de HTML et que vos données structurées sont à 1,95 Mo, vous avez un problème invisible. Google ne vous le dira pas. Vos rankings vous le diront, avec du retard.
« The fetcher stops at the cutoff and sends the truncated content to our indexing systems and the Web Rendering Service, and those systems treat the truncated file as if it were complete. » — Gary Illyes, Google Search Central Blog, 31 mars 2026
La limite de 2 Mo n’est pas figée, précise Google. Elle évoluera à mesure que le web change. Ce qui ne changera pas : ce que vous placez en bas du code reste moins sûr que ce que vous placez en haut.
