Googlebot stops reading at 2MB

Googlebot reads at most 2MB of any HTML page, headers included, and hands that fragment to indexing as if it were the whole file. We measured the homepages of 82 well-known sites and found 5 already past the cutoff — the largest, cnn.com, serving 5.3 MB, which is 2.7 times the limit.

None of those 5 is losing markup Google requires. That is the honest headline and it is the less alarming one: the title, canonical and structured data on every over-sized page we measured sit comfortably inside the first 2MB. What they are losing is content, silently, with nothing anywhere to say so.

What Google actually says

From the Search Central crawler post, and the exact wording is the whole point:

• Googlebot "crawls only the first 2MB of a resource, including the HTTP header".
• The portion it did get "is passed along to our indexing systems and the Web Rendering Service as if it were the complete file".
• Bytes past the threshold "aren't fetched, they aren't rendered, and they aren't indexed".

Read those together and the failure mode is specific. Google does not reject an oversized page, does not report an error, and does not tell you in Search Console. It reads the first 2MB, treats it as the document, and moves on. A page whose structured data sits at 2.4 MB does not have late structured data — it has none, from Google's point of view, while every tool that reads that page from disk sees it perfectly.

Two limits people conflate with this one: PDFs get 64MB, and any crawler that sets no limit of its own gets 15MB. Referenced files — your CSS, your JavaScript, your images — each have their own separate budget and do not count against the parent page. Moving an inline block into a linked file removes it from this problem outright.

What we measured

We fetched the homepage of every site in the Docket Index sample list on 2026-08-07 and recorded two things: how many bytes came back, and how far into those bytes the last title, canonical, meta robots directive and JSON-LD block sat. 82 of 110 answered.

The median homepage is 468 KB, comfortably inside the limit. The 90th percentile is 1532 KB — which is the number worth sitting with, because it means one homepage in ten is already within a third of a cutoff nobody mentions.

cnn.com is the striking one: 5.3 MB served, with everything Google needs inside the first 470 KB. More than half of that page is fetched by nobody. It costs them nothing measurable today, and it is a large amount of work being done for an audience that does not exist.

The false positive we caught on the way

The first version of this measurement reported that cnn.com's title tag sat at 2.48 MB, past the cutoff. That would have been the headline of this page.

It was wrong. Inline SVG icons carry <title> elements as accessibility labels, and the one at 2.48 MB reads "Close icon". Our rule took the last match for every element, which is right for JSON-LD — each block is separate content, so a block past the cutoff is data Google never gets — and wrong for a document title, which is the first one and lives in the head. cnn.com's real title is at 470 KB.

We are writing that down because it is the same mistake in both directions. The check exists because tools read pages from disk and see things Google never received; the bug was our tool reading a page from disk and seeing something that was not what it thought.

Where another tool is better

Screaming Frog reports page size across a whole crawl and lets you sort and filter on it, at a scale Docket is not built for. If the question is "which of my 400,000 URLs are heavy", that is the tool, and it has been doing it for years.

What it will not tell you is which required markup falls past 2MB on the pages that are, because that needs the byte offset of each element rather than the size of the file. That is the part Docket adds, and it only matters on the pages Screaming Frog would have found for you first.

What to do if a page is over

1. Find the weight. It is almost always one of three things: base64 images inlined into the HTML, large inline CSS or JavaScript blocks, or navigation that renders thousands of links before the content starts.
2. Move inline blocks into linked files. They stop counting against the page entirely — referenced resources each get their own budget.
3. Put required markup in the head and keep it there. Structured data injected at the end of the body is the common way to lose it.
4. Check again after a redesign. Page weight grows; the limit does not.
5. Remember this happens before rendering. If the page is also built by JavaScript, the renderer only ever sees the fragment that was fetched.

Docket runs this as index.byte_cap on every audit, and reports the two cases separately: a page merely over the limit is losing content, and a page whose required markup falls past the cutoff is losing indexation. They are not the same problem and they do not deserve the same urgency.

Download Docket

Common questions

How much of a page does Googlebot fetch?

Up to 2MB of any individual URL, including the HTTP headers. PDFs get 64MB, and any crawler that sets no limit of its own defaults to 15MB. Referenced resources like CSS and images have their own separate budgets and do not count against the page that links them.

What happens to the rest of the page?

Nothing. In Google's words the bytes past the threshold are not fetched, not rendered and not indexed, and the portion that was fetched is passed to indexing as if it were the complete file. There is no error and no Search Console report.

Is 2MB of HTML a realistic problem?

For most sites, no — the median homepage in our sample was 468 KB. But 5 of 82 well-known sites we measured were already past it, and the 90th percentile was 1532 KB, so one in ten is closer than its owners probably think.

How do I make a page smaller?

Move inline CSS, JavaScript and base64 images into linked files. That removes them from the page's budget completely, because every referenced resource has its own. Navigation that renders thousands of links before the content is the other common cause.