The 2MB line: what Google actually changed about Googlebot (and what it didn't)

In February 2026, a single line in Google's documentation changed: the file-size limit it had published for Googlebot for years dropped from 15MB to 2MB. The SEO industry read it as a cut — ppc.land's headline calls it an 86.7% reduction and says Google "slashes" the limit. Google's own posture, across two posts, is that its documented limits are clarifications, not behaviour changes. Both readings are defensible, and the uncomfortable part is that the primary sources don't let anyone settle which is true.

Here is what is flatly verifiable. As of its Last updated 2026-02-03 revision, Google's Googlebot documentation reads: Googlebot crawls the first 2MB of a supported file type, and the first 64MB of a PDF file. It also says The file size limit is applied on the uncompressed data. The 15MB figure that the page carried for years is gone from its visible documentation text.

This post pins down what's verifiable, corrects the technical error nearly every write-up repeats, scopes who is actually at risk — a smaller group than the headlines imply, but not the one you'd guess — and explains why the durable lesson, byte order, rewards lean, content-first HTML however the clarification-vs-cut argument resolves. We also stopped theorising and crawled the heavy end of the web ourselves; the numbers are in §6.

1 · What Google actually changed (and what it didn't)

The current wording, verbatim from the doc page above: the limit is 2MB for supported file types, 64MB for PDFs, and it is applied on the uncompressed data. That last clause matters more than it looks: gzip and brotli shrink what crosses the wire, but the limit is measured against the uncompressed bytes, so transfer-compression buys you nothing against this particular cutoff. The 15MB number is simply absent from the page now.

Whether that absence represents a behaviour change is exactly what Google never says. Its framing is consistent with the 2022 post "Googlebot and the 15 MB thing" (Gary Illyes, June 2022), which introduced the 15MB figure with the line that it had been around for many years and that Google had just added it to our documentation — a clarification, not a new rule. The March 2026 post takes the same posture toward the infrastructure it describes, and explicitly notes the limit is not set in stone and may change over time. SEO outlets report John Mueller characterising the 2026 update the same way — as a documentation clarification rather than a change in behaviour — though that quote travels through secondary coverage (seo-kreativ and others), not a primary Google post we could locate, so treat it as industry-reported.

The honest gap is this: Google has not published a statement saying "the documented number moved from 15 to 2, and behaviour is unchanged." So whether Googlebot's real fetch ceiling dropped, or whether 2MB was always its true setting and 15MB was an over-generous documented figure, is not resolved by anything Google has put in writing. Do not let anyone — including this post — tell you which it is. The industry "86.7% reduction" is arithmetic on the two documented numbers, (15−2)/15, not a figure Google published. And the wording has kept moving: SEO outlets (Search Engine Roundtable, seo-kreativ) report that on 11 February 2026 the doc was softened to say a Google crawler may have a smaller size limit (for example, 2MB), which reads less like a universal hard ceiling than the flat 2MB statement does. We surface that as reported, not as a primary fact we re-verified.

2 · Fetch vs index: getting the two-phase nuance exactly right

This is the part almost everyone gets wrong, including write-ups that are otherwise careful. The popular framing — "Googlebot fetches 15MB but only indexes 2MB" — is no longer correct, if it ever was. Google's March 2026 post "Inside Googlebot" (Gary Illyes, 31 March 2026) is explicit that the 2MB cap is on the fetch itself: Googlebot currently fetches up to 2MB for any individual URL (excluding PDFs). This means it crawls only the first 2MB of a resource, including the HTTP header. Googlebot stops the fetch exactly at the 2MB cutoff — it does not download more and then trim.

What gets fetched is what gets indexed, and nothing else. The post continues: That downloaded portion (the first 2MB of bytes) is passed along to our indexing systems and the Web Rendering Service (WRS) as if it were the complete file. And, bluntly: Any bytes that exist after that 2MB threshold are entirely ignored. They aren't fetched, they aren't rendered, and they aren't indexed. Google says the HTTP header counts toward the 2MB, so the budget for the document body is slightly less than the full 2MB.

So where did 15MB go? It became the fallback for everyone else. Per the same post: For any other crawler that doesn't specify a limit, the default is 15MB regardless of content type. 15MB is now the documented default for Google's other crawlers and fetchers that don't set their own ceiling — it is no longer Googlebot's number. Because several secondary SEO write-ups still circulate the old fetch-15/index-2 framing, we flag the disagreement openly and side with the primary source: there is one fetch, and it stops at 2MB.

One more detail that defuses a common panic: external resources are budgeted separately. CSS and JavaScript files that the page references have their own, separate, per-URL byte counter and don't count towards the size of the parent page, each subject to the same 2MB per-resource limit when WRS fetches them. So a heavy external stylesheet does not eat into the HTML document's 2MB — though if that stylesheet itself exceeds 2MB, its own tail is dropped on the same terms.

3 · Why byte ORDER matters, not just byte size

The cutoff is positional. It is the first 2MB, which means what occupies those early bytes is what exists to Google, and what sits past the line does not. Size is the constraint; order is the lever. And this is not PrerenderProxy editorialising — Google names both the risk pattern and the fix in the same post.

The risk, in Google's words: if your page includes bloated inline base64 images, massive blocks of inline CSS/JavaScript, or starts with megabytes of menus, you could accidentally push your actual textual content or critical structured data past the 2MB mark. If those crucial bytes aren't fetched, to Googlebot, they simply don't exist. An inline base64 image is the cleanest illustration — SAVIC estimates each can consume on the order of 200–400KB of the HTML document's budget, though the real figure varies with the source image; treat it as illustrative, not a constant. Stack a few of those, or a multi-megabyte mega-menu, ahead of the article body, and the content can land on the wrong side of the line.

The fix, also in Google's words, is two best-practice rules. First: Keep your HTML lean: Move heavy CSS and JavaScript to external files. (External files get their own budget — §2.) Second, and this is the one to tape to the monitor: Place your most critical elements - like meta tags, <title> elements, <link> elements, canonicals, and essential structured data - higher up in the HTML document. This ensures they are unlikely to be found below the cutoff. Order matters because the cutoff is positional. That is the whole lesson, and it is Google's, not ours.

4 · Where this bites: CSR bloat meets non-JS crawlers

The 2MB line stacks on top of a problem PrerenderProxy already documents, and the two compound. Heavy client-rendered pages spend their early bytes on framework bundles and serialised state, and their late bytes — sometimes their only real textual content — on whatever the JavaScript eventually injects. That is already a problem for crawlers that don't run JS. Now the early-byte budget has a hard documented ceiling on top of it.

And the crawlers that matter most for AI visibility generally don't execute JavaScript at all. Vercel's December 2024 analysis measured roughly 569 million GPTBot and 370 million ClaudeBot requests across its CDN in a single month, and found that the major AI crawlers download JavaScript without rendering it — GPTBot fetched JS files but did not execute them. (We've written the longer version of this in the strange afterlife of dynamic rendering.) For those bots, content that only materialises after JS execution never appears regardless of the byte limit. For Googlebot, WRS does execute the JS — but only the JS it actually fetched, capped at 2MB, and statelessly, clearing local and session storage between requests. So the two failure modes meet: non-rendering bots miss JS-dependent content entirely, and the rendering bot only gets to run what fit inside the first 2MB.

5 · What lean prerendered HTML actually does about it

Here is the honest version of the PrerenderProxy angle, and it is mechanistic, not promised. A prerendered, content-first response puts the real human-readable content and the critical tags — <title>, canonical, JSON-LD — high in the byte order and inside the first 2MB. That mirrors Google's own "order matters" and "keep HTML lean" best practices from §3, applied at the edge. And for the non-rendering AI crawlers, it removes the JS-execution dependency: the content is already in the HTML they download, so it doesn't matter that they never run the bundle. When the origin CMS can't be changed to produce that HTML, the prerender layer can — that is the subject of stuck with legacy.

The guardrail, stated plainly: this is a structural claim — that content lands inside the window Google fetches and indexes — not a causal one. No ranking lift is promised, no citation lift, no byte-saving percentage. And prerendering is not magic against this limit: a bloated prerendered page can also blow past 2MB if you let it. We watched it happen — a major retailer's laptop category, fully rendered with every lazy-loaded product in the DOM, weighs about 5MB; serialise that naively as the HTML you hand crawlers and Googlebot fetches only the first 2MB, dropping more than half the page. The win is "lean and content-first" — paginate, cap the grid, keep the real content high in the byte order — not "prerendered, therefore safe". The only numbers worth offering here are variance, not proof: in our May 2026 top-100 e-commerce audit, amazon.co.uk served Googlebot roughly 914KB of HTML and Bingbot roughly 990KB (the audit rounds both to about 900KB) — both comfortably under 2MB, so neither is a limit breach. They are bytes-served figures, included only to show how far response sizes range across user agents; Bingbot's ~990KB is still only about half the cap — but it shows real crawler-facing HTML can run into seven figures, so "well under" is not "nowhere near" for every site.

6 · The counter-argument: almost no page is over 2MB

The strongest objection to all of the above is also the most honest, so here it is at full strength. Median HTML is tiny. Dave Smart's measurement puts median uncompressed HTML around 20KB; the 2025 Web Almanac likewise puts median HTML in the low tens of KB. Either way that is on the order of 60–100× under the 2MB cap. The 90th percentile is about 392KB (Dave Smart) — still a long way short. Seobility found only about 0.82% of ~44.5 million analysed pages exceed 2MB of HTML, and Dave Smart estimates the share of sites actually affected at well under that. This is not a universal emergency, and anyone telling you to panic about your 33KB blog is selling something.

Concede all of that, and the narrow point survives intact: the risk is concentrated in the bloated client-rendered tail and in pages carrying huge inline state or late JSON-LD — Seobility's own over-limit examples include OMR Reviews at roughly 3.4MB and Zalando around 2.6MB of HTML. Those are precisely the sites whose owners most need to care, and precisely the ones most likely to have shipped the bloat in the first place. One myth to retire while we're here: SAVIC's claim that the "median mobile page now weighs 2.3MB, already exceeding the limit" conflates total page weight — all images, fonts, scripts, every byte the browser downloads — with the HTML document size the 2MB limit actually governs. The limit is on the document (and per-resource), not on the page's total transfer weight. Don't repeat that one.

We didn't want to take the aggregate on trust, so in June 2026 we crawled a set of heavyweight commercial pages ourselves — sending the Googlebot user-agent and measuring the HTML document only, uncompressed, the way the limit does. The heavy tail is not hypothetical. omr.com's reviews index came back at 2.29MB — over the line. Netflix's Stranger Things page measured 1.07MB and gigantti.fi 1.06MB, both more than half the 2MB budget; our own May audit clocked amazon.co.uk's HTML to Googlebot at roughly 0.9MB. (Seobility's snapshot of OMR ran larger still, around 3.4MB — these numbers move as pages do.) One honest caveat on method: we send the Googlebot UA from an ordinary IP, so this is what a client presenting that user-agent receives, not Google's own verified fetch — a fair proxy, not a perfect one. "Almost no page is over 2MB" is true of the median and quietly misleading for the pages whose owners pay people to think about crawlers.

And the median stat hides a second failure mode — the more common one. The pages most exposed often dodge the 2MB ceiling not by being lean but by being nearly empty. In a live engagement we measured a major retailer's two highest-traffic shop categories — each pulling hundreds of thousands of monthly search impressions — at about 158KB of HTML with no server-rendered <h1> at all: the real content is injected by JavaScript that a non-rendering crawler never runs. Where those pages do server-render their content, the <h1> often sits some 110KB deep, behind the framework's inline JavaScript. The 2MB ceiling and the empty-shell floor are the same byte-order problem viewed from opposite ends, and lean, content-first HTML is the answer to both.

Two more honest caveats, because the enforcement story is genuinely unsettled. Is the limit hard? Two independent live tests reached opposite conclusions. Spotibo built a 3MB page and observed the indexed version truncated at exactly 2MB — cut mid-word — with no warning in Search Console. DebugBear ran its own tests and saw no truncation, calling it unclear how hard the limit is and when truncation happens. Both are real observations; neither settles it, so we won't pretend it's settled. And there is a trap worth naming: the URL Inspection / Live Test tool appears to fetch under the larger 15MB ceiling, so it can show you the full HTML and give false reassurance even if indexing truncates at 2MB — that behaviour is reported and reasoned from the tests, not documented by Google. The self-test that routes around it is simple: take a unique string from the very bottom of your page and search Google for it. If it doesn't surface, your tail may be falling off the line.

We also went looking for the cutoff in the wild — a real page where unique, indexable content sits only past the 2MB line — and mostly couldn't find one, which turned out to be the more useful result. Crawl the heavy end of the web and the bytes past 2MB are almost always one of four things: a serialized app-state blob (machine data, not readable content); content also published in a smaller paginated view that Google indexes instead (every large specification does this); text mirrored across other sites; or content that was never in the HTML to begin with because JavaScript injects it after load. Well-built sites route around the limit without trying. The reliable way to actually strand content past 2MB is to force it into one giant document with no alternate — which is precisely what a naive prerender of a heavy page produces. The limit is real, and Spotibo's controlled test shows it truncates; it just rarely bites by accident.

7 · Where we land

The verifiable core is small and solid: Google's documented Googlebot limit now reads 2MB, measured on uncompressed data, with the HTTP header counted in; 64MB for PDFs; referenced CSS and JavaScript budgeted separately at 2MB each. The unresolved core is real and worth holding open: whether any actual fetch behaviour changed, and how hard the limit is enforced. We don't resolve either, because the sources don't.

What survives every reading of the clarification-vs-cut debate is the lesson Google itself spells out — byte order is a content-strategy variable, and lean, content-first HTML is the structural answer. Most pages are nowhere near the line; the ones that are tend to be the JS-heavy, inline-bloated pages whose owners have the most to lose. And the documented limit, in Google's own words, is not set in stone — so this is a moving target, and the right posture is to keep your critical content and tags early and your HTML lean, which was good practice before the number changed and remains so whichever way it changes next.

Companion reading: The strange afterlife of dynamic rendering, 2018–2026 · Stuck with legacy — fixing it at the edge · The May 2026 top-100 e-commerce audit