Google 2 MB Crawl Limit: What It Means for Your Site

The Google 2 MB crawl limit showed up in one quiet docs update — and my LinkedIn feed exploded over a single number: 2 MB. Google updated its Googlebot documentation on February 3, 2026 and spelled out that Googlebot fetches the first 2 MB of a file. The old docs only mentioned 15 MB. Cue the panic posts, and a Search Central blog post at the end of March that explained the details.

Here's my take: this is way less dramatic than people are making it. The number itself does matter, even if 99% of sites don't need to worry.

What changed

Google didn't actually change how Googlebot works. They fixed the documentation to match reality. The 15 MB figure is still real: it's the default for Google's crawlers that don't set their own limit. Googlebot for Search has a tighter one, and the docs now say so: the first 2 MB of each file, measured uncompressed.

So no, your site didn't break overnight. But now there's a concrete number to measure against.

The actual limits

For your HTML, the limit applies to the raw, uncompressed response, and that includes everything inline: CSS, JavaScript, SVGs, base64-encoded images. External CSS and JavaScript files are fetched separately, and each of them has its own 2 MB limit.

The key detail: Googlebot doesn't reject pages over 2 MB. It truncates: processes the first 2 MB and silently ignores the rest. If your structured data, important links, or main content sits below that cutoff, Google will never see it. That's the real risk.

Who's actually affected

Almost nobody, and I mean that literally. A Seobility analysis of 44.5 million pages found that only 0.82% exceed 2 MB.

But some sites are at risk:

• E-commerce filter pages: when every color/size/brand combo gets rendered server-side, the HTML balloons fast
• Base64-encoded images inline in HTML: one large image as base64 can eat 300+ KB by itself
• SPAs dumping state as JSON: frameworks like Next.js can serialize large data payloads into the initial HTML, and on data-heavy pages that JSON can reach hundreds of kilobytes
• Inline SVGs: complex illustrations or full icon systems embedded directly in the markup

Standard business sites, blogs, even mid-size e-commerce shops? You're fine.

How to check your pages

Browser DevTools

Open Chrome DevTools (F12), go to the Network tab, reload the page, click the main document request. In the Size column, hover to see the resource size, not the transferred size (that one is compressed and much smaller). The uncompressed number is what Google counts.

Lumina Tech Stack Detector

The Lumina Tech Stack Detector shows an HTML Size metric for any URL, green when you're far from the limit and yellow above 1 MB. It measures the HTML Lumina receives, which is usually the rendered page. For the exact raw figure Googlebot sees, use the command line below. Pages above roughly 2 MB are too large for Lumina to fetch at all, and the tool tells you so.

Command line

curl -s https://example.com | wc -c

This gives you the byte count of the raw HTML response.

What to do if you're over the limit

Over or close to 2 MB? Fix these first, in order of impact:

• Move inline assets to external files. Base64 images, fat inline SVGs, embedded CSS/JS: pull them into separate files. Each file is fetched separately with its own 2 MB limit, so a large stylesheet moved out of the HTML no longer counts against the page.
• Put critical content first. If truncation happens, make sure your main content, JSON-LD schema, and key internal links sit near the top of the HTML. Not buried under 1.5 MB of navigation markup.
• Paginate long listings. 500 products rendered server-side in one HTML file is a problem. Paginate, or lazy-load the tail.
• Trim dead markup. Unused CSS classes, redundant data attributes, excessive whitespace from server-rendered output: it adds up faster than you'd think.

If your pages are under 500 KB (and they almost certainly are), don't spend time on this. Put your technical SEO hours where they'll actually move rankings.