HTML Over 15MB: How Googlebot Truncates Giant Pages and How to Fix It

Quick version: when an HTML response is bigger than 15MB, Googlebot does not reject the page — it truncates it. The first 15MB is kept and parsed; everything after the cut is silently dropped. The danger is not the size number itself, it is what content ends up below the line and therefore invisible to Google.

What this check flags

This fires on the same threshold as the raw document-size check, but the angle here is the consequence: truncation. A 16MB page is not "too big to index." Google indexes the first 15MB of it and behaves as if the rest of the markup does not exist. If your canonical tag, main copy, or internal links happen to sit in that lost tail, you have a ranking problem that looks like a mystery until you understand the cut.

The behavior that trips people up

Googlebot reads bytes sequentially. It streams the HTML in, and once it has taken 15MB it stops reading that resource and hands what it has to the parser. There is no "smart" truncation that tries to close tags or preserve the head — it is a byte cutoff. That leads to two failure modes people rarely anticipate:

• Broken parse tail. The document gets cut mid-tag. The parser does its best with malformed HTML, but anything structurally dependent on the missing close tags can render wrong or drop out.
• Missing critical directives. If a rel="canonical" or a late <meta name="robots"> was injected near the end of the document (some CMSs and tag managers do this), it never gets read. Google then treats the page as self-canonical, or as indexable, contradicting your intent.

A real example

A publisher's article template appended the full comment thread — 4,000 comments — directly into server-rendered HTML. Long-running articles pushed the document past 17MB. The visible article read fine to users because the browser loaded the whole thing, but Google's fetched copy stopped somewhere inside the comment section. Two things broke: the article's structured data block, placed after the comments, never got parsed, and the "related articles" internal link module at the very bottom was invisible to crawlers, quietly orphaning a batch of newer posts that were only linked from there.

The fix was to lazy-load comments after the main content instead of server-rendering all of them, and to move the schema and the related-links module up into the first few KB of the document:

<!-- comments now loaded on demand, out of the initial HTML -->
<div id="comments" data-src="/api/comments/article-1234"></div>

<!-- schema and internal links moved high, guaranteed inside the 15MB window -->
<script type="application/ld+json">{ ...Article schema... }</script>

The document fell to under 200KB and both the schema and the related links reappeared in Google's fetched version.

What survives the cut and what does not

How to detect it on your own site

1. Find the oversized pages first. Crawl in Screaming Frog and sort the Internal tab by Size (bytes). Any URL over ~15MB is a truncation candidate. With curl: curl -s -o /dev/null -w "%{size_download}n" -A "Googlebot" URL.
2. Compare shipped HTML to fetched HTML. In Search Console, run URL Inspection, then View crawled page and read the HTML Google actually captured. Search that text for your closing </html>, your footer link anchors, and your JSON-LD. If they are absent, the tail was cut.
3. Grep the fetched copy for directives. Save Google's fetched HTML and check whether your canonical and robots tags are present. A canonical that exists in your source but not in the fetched copy is being ignored.
4. Watch for the ghost symptom. Rich results disappearing, or new pages never getting discovered despite being linked, on a template that renders a lot into one document, is a fingerprint of truncation even before you measure size.

How to fix it

1. Get the byte count well under 15MB. The root cause is the same family of bloat — inline data, un-paginated lists, huge inline scripts. Trim those and the truncation stops.
2. Front-load anything Google must see. Put canonical, robots, title, main copy, structured data, and key internal links high in the document. Never rely on a directive that lives after megabytes of content.
3. Lazy-load the heavy, low-value stuff. Comment threads, exhaustive spec tables, and infinite lists belong behind pagination or on-demand loading, not in the first response.
4. Re-inspect after deploy. Re-run URL Inspection and confirm the previously-missing elements now appear in the crawled page. That is the real proof, not just a smaller number.

FAQ

Does Google reject a page over 15MB?

No. It indexes the first 15MB and ignores the rest of the markup. The page still gets indexed — it is just missing whatever content and directives lived beyond the cut. That partial indexing is exactly why the problem hides so well.

Where exactly does the cut fall?

At 15MB of bytes from the top of the response, mid-tag if necessary. It is a hard byte cutoff, not a tag-aware or section-aware one, so you cannot predict clean boundaries. Assume anything past 15MB is gone.

My canonical is being ignored — could this be why?

If the canonical tag sits low in a document over 15MB, yes. Some setups inject a late canonical via JavaScript or a tag manager; if that injection lands past the cut, Google never reads it and treats the page as self-canonical. Move the tag into the static <head>.

Will minifying or gzipping the HTML fix truncation?

Gzip will not — Google measures uncompressed bytes. Minifying can shave a little off the uncompressed size, but if you are anywhere near 15MB, minification is a band-aid. The real fix is removing the bulk that pushed you there.

How is this different from a general oversized-page warning?

A generic "heavy page" note is about total transfer weight and speed. This one is specifically about content loss from the 15MB HTML fetch ceiling. For the document-size root cause and the byte sources behind it, see the related check below.

Related checks

For the byte-size root cause and where the bloat comes from, read the companion check on an crawl budget impact of oversized documents. If truncation is orphaning pages by cutting your footer links, URL is orphaned: how to fix orphan pages covers the downstream problem. And when your directives are the casualty, the meta robots and X-Robots-Tag reference shows where they should actually live.