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 crawler docs in March 2026 and confirmed that Googlebot processes a maximum of 2 MB of HTML per URL. The old docs said 15 MB. Cue the panic posts.

Here's my take: this is way less dramatic than people are making it. But it's worth understanding what actually changed, because 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 sat in the docs for years, but anyone who tested actual crawling behavior knew the real threshold was much lower. The March 2026 blog post finally put a number on it: 2 MB of uncompressed HTML per URL.

So no, your site didn't suddenly break overnight. But having a confirmed, concrete number is useful. It means you can stop guessing and start measuring.

The actual limits

The 2 MB limit applies to raw, uncompressed HTML, and that includes everything inline: CSS, JavaScript, SVGs, base64-encoded images. External resources (separate CSS/JS files, images loaded via <img>) are fetched separately with their own limits.

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. The median HTML size across the web? Just 20 KB. Even at the 90th percentile, pages clock in around 392 KB, not even 20% of the limit.

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: I've seen React/Next.js apps serialize massive data payloads into the initial HTML. One client had 1.4 MB of JSON in a <script> tag
• 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. Don't waste time optimizing for a problem you don't have.

How to check your pages

Takes about 30 seconds. Pick your method:

Browser DevTools

Open Chrome DevTools (F12), go to the Network tab, reload the page, click the main document request. Look at the Response size — not the transfer size (that's gzip-compressed and much smaller). The uncompressed number is what Google counts.

Lumina Tech Stack Detector

I added an HTML Size metric to the Lumina Tech Stack Detector right after this news broke. Run any URL and you'll see the HTML size with color-coded feedback: green if you're safe, yellow if you're getting close, red if you've crossed the line.

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

If you're actually over (or close to) 2 MB, here's what to fix 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 gets fetched independently with its own 15 MB limit.
• 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.

But seriously, if your pages are under 500 KB (and they almost certainly are), don't spend time on this. The 2 MB limit is irrelevant for you. Put your technical SEO hours where they'll actually move rankings.