A page's captured HTML approaches or crosses the fetch limit
In the reportHTML approaches or exceeds the documented 2 MB fetch-size limit
html_over_googlebot_fetch_limit · Issue
The rule reports HTML over 2,000,000 decoded body bytes, or a complete body from 1,500,000 through 2,000,000 bytes. Google documents 2 MB including response headers without guaranteeing decimal or binary units; our policy uses decimal bytes and cannot count the original headers. Reduce large inline content and keep important head tags near the start.
Severity: High. The issue highlights a risk of important content falling outside the fetched portion, not proof of what Google indexed.
Why it matters
Google documents a 2 MB limit for an individual HTML fetch and forwards the downloaded prefix for indexing and rendering. Its October 2026 correction says response headers count toward that limit, so the available body allowance can be smaller.
What to do
- Use the exact body size for a complete read or the lower bound for a stopped read; the bounded tail excerpt starts at the body policy cutoff.
- When present, inspect the listed title, robots or googlebot meta, canonical and hreflang tags whose original encoded byte positions reach the cutoff, then move them earlier in the head.
- Move large inline scripts, styles and embedded data into separate files, or split long catalogues into smaller pages.
When to leave it as it is: A deliberately large page in the approaching band may be acceptable after review if critical content comes early; keep monitoring its size and allow room for response headers.
What we read
For a captured 200 response with an HTML media type, the shared capture supplies decoded body bytes, independently of the compressed transfer size; pages carrying noindex are included.
A complete count below 1,500,000 bytes is clean, a complete count from 1,500,000 through 2,000,000 is approaching, and any observed count above 2,000,000 is over-limit; an incomplete count below or at the cutoff is unknown.
A complete native head supplies original encoded byte positions for critical tags in the head; a missing head or any partial body supplies no tag list, never an empty proof that all tags came early. Other statuses and non-HTML types are outside the check.
Example & evidence
Illustrative example — one page's size, not a live audit.
https://bakery.example/catalogue/ measured, decompressed:
HTML: 2,641,307 bytes
cutoff: 2,000,000 bytes
past the cutoff: 641,307 bytesThe complete body exceeds 2,000,000 bytes, so it is an over-limit issue with a bounded excerpt after the body cutoff.
A possible correction: split the catalogue into pages of 50 products each.
Confirm & check again
Check for yourself: Save the uncompressed response body and measure its byte length, then inspect the original byte positions of critical head tags; separate images and scripts are fetched independently.
Check again: Full audit — Run a new audit that reads the same URL completely below 1,500,000 body bytes. A result in the approaching band remains open; an unread, incomplete, non-HTML or otherwise inapplicable response cannot prove this finding fixed, and a different redirect target does not by itself fix the original URL.
Limits & sources
The measurement uses this audit's captured response, not Google's fetch or indexed content. It counts decoded body bytes only, with response-header bytes unknown; being within the body policy is not proof that the combined response fits Google's limit.
Google writes 2 MB without guaranteeing the unit. The policy uses 2,000,000 bytes and flags the ambiguity through 2,097,152 bytes; partial bodies expose only a size lower bound, and head evidence is unavailable for them. The current page collector does not retain a body after a socket read error, so that case has no body-size proof.
Confidence: High Direct byte counts give high confidence in the stated body measurement, while header size, unit ambiguity and partial head coverage remain explicit limits.
Sources
- Google, Inside Googlebot: demystifying crawling, fetching, and the bytes we process — Documents a 2 MB HTML fetch cutoff including HTTP response headers after the October 29 correction; downloaded bytes are passed for indexing and rendering. Checked 2 November 2026.
Editorial review: 2 November 2026