Googlebot fetches up to 2 MB of HTML per URL for Search indexing. Anything past 2 MB is silently truncated, which means it never gets rendered and never reaches the index. The cap includes HTTP response headers.
Most sites get away with bloated pages because their critical content (title, meta tags, canonical, structured data, hero text) lands inside the first 2 MB. The pages that don't get away with it are JavaScript-heavy sites with massive inline scripts or base64-encoded images that push the meaningful HTML past the cutoff.
Gary Illyes confirmed the number explicitly in his March 31, 2026 Inside Googlebot blog post. The 2 MB limit isn't new, since it's been in effect for years, but the formal documentation in 2026 means there's no more debating it.
This post is the practical guide to the limit: what it is, why it matters more in 2026 than ever, how to test if your pages are over, and the quick wins that bring you back under.
The actual numbers
There isn't one byte limit. There are several, depending on the crawler and content type. Per Google's Overview of Google crawlers and fetchers and the March 2026 Inside Googlebot post:
- Googlebot (HTML): 2 MB per URL, including HTTP response headers
- Googlebot (PDF): 64 MB per URL
- Default for other Google crawlers: 15 MB per URL
- Image and video crawlers: vary by purpose (favicons are tiny, Image Search higher)
Per Gary Illyes, "Googlebot currently fetches up to 2MB for any individual URL (excluding PDFs)." Per the same post: "For PDF files, the limit is 64MB" and for crawlers without specific limits, "the default is 15MB regardless of content type."
The 2 MB cap is what matters for nearly every web page audit, and it's tighter than most engineers assume. The truncation behavior is brutal: Googlebot does not reject your page if it's over 2 MB, it cuts at exactly 2 MB. Whatever HTML is past byte 2,097,152 (2 × 1024 × 1024) silently disappears from Google's processing pipeline.
> Googlebot's per-URL fetch limit for Search rendering is 2 MB of HTML, including HTTP response headers. Anything past 2 MB is silently truncated. Per Gary Illyes, Google Search Central blog, March 31, 2026.
Embedded resources (external CSS files, JavaScript bundles, images, XHR endpoints fetched during render) each have their own per-URL byte counter. The 2 MB on the HTML response is the constraint; external assets get 15 MB each by default. Moving inline content into external files is one of the quickest ways to get back under the 2 MB HTML cap (more on the tradeoff below).
Why 2 MB matters more in 2026 than ever
The cap isn't new. What's new is the cost of hitting it.
1. AI Mode and AI Overviews extract from rendered HTML. When AI Mode generates an answer, it pulls signals from the rendered DOM Google indexed. If your structured data, canonical, or key content landed past the 2 MB cut, it's not in the DOM Google indexed, and it's not available for AI extraction. The pages most likely to be cited in AI Overviews are the pages with clean, machine-readable HTML inside the byte limit.
2. Information Agents do recurring fetches. Per the I/O 2026 announcements, Information Agents (the persistent agent-based search surface) re-fetch pages on schedules. Each fetch is subject to the same 2 MB limit. A page that occasionally landed under the cap because of a smaller JS payload yesterday may land over the cap today, which makes the truncation hard to predict.
3. JavaScript fan-out is up. Per Search Off the Record episode 106, the median mobile homepage went from 845 KB in 2015 to 2.3 MB in July 2025, roughly 3x growth in a decade. Most of that growth is JavaScript and inline assets, not actual content. Sites that were fine on page weight five years ago are now sitting right at the edge of the cap.
4. Render-blocking issues compound. Google's Web Rendering Service (WRS), documented in its JavaScript SEO Basics, runs JavaScript and applies CSS. Per Gary Illyes's March 2026 post, WRS is stateless, so local and session storage are cleared between requests, and it skips images and videos while still processing JavaScript, CSS, and any XHR calls the page fires during render. If your page can't render its critical content within the 2 MB byte budget, WRS won't either.
The sites most at risk are heavy SPAs that ship the full app bundle in the initial HTML, sites that inline large base64 images directly in HTML, sites with massive inline CSS, and sites that try to be "fast" by inlining everything and accidentally push real content past the cap.
We see this pattern in heavy-SPA verticals like real estate sites and AV installer portfolios, where map embeds and image carousels and a pile of inline scripts add up fast.
How to test if your page is over
You don't need expensive tools. Two methods.
Method 1: curl from your terminal.
curl -s -o /dev/null -w "%{size_download}
" \
-H "User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html)" \
https://yoursite.com/your-pageThat prints the byte count of the HTML response. If it's over 2,097,152 (2 MB in binary) you have a problem. Run it on every key page: homepage, top blog posts, top landing pages.
Method 2: Chrome DevTools.
Open the page in Chrome, open DevTools, go to the Network tab, and reload. Click the very first row (the HTML document, not the assets) and read the "Size" column. If it's red and over 2 MB transferred, you're over the cap.
A nuance: the 2 MB is the uncompressed HTML the server sends. Compression (gzip, Brotli) reduces transfer bytes but doesn't change what counts against the limit. The relevant number is what Googlebot sees after decompression. Most sites compress, so transferred bytes look small while the actual HTML is two to three times larger. Check the "Content-Length" header after decompression, not the over-the-wire transferred bytes.
Method 3: URL Inspection in Search Console.
In Google Search Console, use the URL Inspection tool. Click "View Crawled Page" then "HTML." If the HTML shown is truncated mid-tag or mid-element, you're over. This is the slowest method but it tells you exactly what Google saw.
Quick wins that bring you under
Here's the order I run on client audits, fastest first:
1. Remove inline base64 images. A single base64-encoded hero image can be 500 KB to 2 MB of HTML. Move it to an external file. Use a srcset and loading="lazy". Per Martin Splitt on SOTR 106: don't ship a "five megabyte image" to a smartphone. Google itself enforces a 1 MB-per-image rule internally for its docs site submissions.
2. Move inline CSS to external files. If you have 200 KB of CSS in a