HTML exceeds the 2 MB limit
html_too_largeShort answer
This page's HTML is larger than 2 MB. Googlebot processes only the first 2 MB of an HTML file; text and links beyond the limit are never seen, so content near the bottom of the page may be effectively invisible to Google. The cause is almost always embedded data (inline JSON, base64 images, inline SVG sprites) or large inline scripts and styles. Move them to external files.
Why it matters
Googlebot processes only the first 2 MB of HTML; text and links beyond the limit are never seen. Internal links at the bottom of a page over the limit do not pass any value, and the content there is not indexed. Pages this large are also slow for users, especially on mobile.
How Glimana detects it
The rule fires when the uncompressed size of the HTML response (size_bytes) exceeds 2,000,000 bytes. The evidence shows the size and how many bytes are over the limit.
How to fix it
- Find the affected pages in Glimana. Open Issues › HTML exceeds the 2 MB limit. Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
Look at the page source: page builders (Elementor, Divi, WPBakery) can inline many kilobytes of CSS per block; galleries sometimes inline base64 thumbnails; some plugins embed JSON data for every product. Turn on the builder's "optimized CSS/asset loading" options, replace base64 images with normal
<img>files and, for data-heavy pages, load the data via AJAX after render.Large pages are usually a theme that outputs the whole product JSON (
{{ product | json }}) for every product in a collection, or inline SVG icons repeated in every card. Output only the fields the JavaScript needs, and reference SVG sprites with<use>.Externalise scripts, styles and SVG sprites so they are cached separately. Replace inline JSON payloads with a fetch after load, and paginate or lazy-load long listings. Serve images as files, not data URIs.
-
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when the HTML size is under 2 MB. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
Re-crawl; the task closes when the HTML size is under 2 MB.