If you think Google is not seeing all of your page, the Googlebot file size limit is the first thing I’d rule out. Google updated its Googlebot documentation on 3 February 2026. It now says that when Googlebot crawls for Google Search, it fetches the first 2MB of HTML and other supported file types, and the first 64MB of a PDF. Anything past that point is not sent for indexing.
For most websites this changes nothing. A normal page is a tiny part of 2MB. But some pages carry far more code than their owners know. On those pages, content near the bottom may never reach Google’s index.
What Google Changed in Its Googlebot Documentation
On 3 February 2026, Google logged a documentation change called “Clarified information about the default file size limits for Googlebot.” It touched two pages.
- The general crawler overview. The default limit for all of Google’s crawlers and fetchers moved here. Google’s crawler overview page says that, by default, they only crawl the first 15MB of a file. It also says each project can set its own limit.
- The Googlebot page. With the general default moved out, Google rewrote its Googlebot documentation to give Googlebot’s own limits for Search more exactly: 2MB for supported file types and 64MB for PDFs.
Google’s changelog gave a simple reason. The old place for the default limits “was not the most logical place”, because the default applies to every Google crawler, not only Googlebot. Moving it made room to be more specific about Googlebot.
This fits a wider pattern. In late 2025 Google moved its main crawling documentation to its own section, apart from Search Central. That is because the same crawling system serves products beyond Search. The crawler overview now lives there.
The Googlebot File Size Limit, in Plain Numbers
| What is being fetched | Documented limit | Where Google states it |
|---|---|---|
| HTML and other supported file types, crawled by Googlebot for Google Search | First 2MB | Googlebot documentation |
| PDF files, crawled by Googlebot for Google Search | First 64MB | Googlebot documentation |
| CSS, JavaScript and other resources linked in the HTML | Fetched separately, each bound by the same non-PDF limit | Googlebot documentation |
| Default for Google’s crawlers and fetchers in general | First 15MB | Crawler overview documentation |
Two details on the Googlebot page matter more than the big numbers.
- The limit is measured on uncompressed data. Gzip or Brotli compression (ways to shrink a file while it travels) makes your page faster to send. But it does not give you extra room. A 600KB compressed HTML file that grows to 2.4MB when unpacked is over the limit.
- Googlebot does not reject the file. Once it reaches the cutoff, it stops the fetch and sends what it already has for indexing. The rest of the file is simply not looked at.
Google also notes that other crawlers, like Googlebot Image and Googlebot Video, may have different limits. So a large image is not judged against the 2MB HTML figure.
Is 2MB a New, Smaller Limit?
This is the question most people asked when the update came out. The old Googlebot page showed 15MB. So it looked as if the limit had shrunk to a seventh of its size overnight.
That is not what Google published. The 15MB figure is still there, now as the general default for all crawlers. The 2MB and 64MB figures describe what Googlebot does when it crawls for Search. Google called the update “more precise”, not a change in behaviour.
In practice, I treat it the same way either way. If a page’s HTML is over 2MB uncompressed, I don’t assume Google is indexing all of it.
What Counts Toward the 2MB Limit
The limit applies to the bytes in the file Googlebot fetches. For a web page, that is the HTML document itself, measured after it is unpacked. Everything written into that document counts.
- Visible text and markup. Your headings, paragraphs, tables and all the tags around them.
- Inline CSS. Styles placed inside
<style>tags orstyleattributes. - Inline JavaScript. Scripts written directly in
<script>tags. This includes large JSON blobs that some frameworks add to “hydrate” the page (load the page’s data so the script can take over). - Inline SVG. Icons and pictures pasted into the HTML as code.
- Base64 data URIs. Images or fonts turned into text inside the HTML. Base64 makes data about a third larger than the original file, so this adds up fast.
- Structured data. JSON-LD blocks in the page.
- HTML comments and whitespace. They are still bytes in the file.
Anything loaded by URL does not count against the HTML document’s limit. An external stylesheet loaded with <link rel="stylesheet" href="...">, a script loaded with <script src="...">, or an image in an <img src="..."> tag is a separate fetch. Google’s documentation says each linked resource is fetched separately and has its own limit.
This is the key to almost every fix in this article. When you move code out of the HTML and into a linked file, you take it out of that page’s 2MB budget.
Why the Position of Your Content Matters
Googlebot keeps the first part of the file and drops the rest, so order matters. On an oversized page, whatever sits early in the HTML source is safe. Whatever sits late is at risk.
Sadly, many heavy pages put the bulk in the worst place. A large inline script or style block in the <head> pushes your main content further down. On a very large page, your article text, internal links or product details could end up past the cutoff. When I look at a heavy page, the first thing I check is how far down the main content starts.
Who Could Be Affected
Most pages are nowhere near 2MB of uncompressed HTML. A normal blog post, service page or product page is a small part of that. In my experience, the sites that need to check are the ones with unusual patterns like these.
- Pages with huge inline JavaScript. Some JavaScript frameworks and page builders put the full app state into the HTML as JSON. On data-heavy pages, that can run into megabytes.
- Pages with large inline CSS. Builders and some speed plugins put whole stylesheets inside every page. A little critical CSS is fine. A full theme stylesheet repeated in every page is not.
- Base64 images in the HTML. Email-style templates, some editors and some “lazy” speed setups put images straight into the page as text. A few photos done this way can push a page past the limit on their own.
- Giant single pages. Very long category pages with hundreds of products and no pagination, “view all” archives, full documentation on one URL, long data tables, or forum threads that load every reply.
- Pages with a heavy mega menu. A menu with thousands of links on every page eats into the budget before the main content even starts.
- Large text files and feeds. Big XML or plain-text files you want indexed in Search are also supported file types. The same 2MB figure applies to them.
- Very large PDFs. Most PDFs are well under 64MB. But scanned catalogues, image-heavy reports and print-ready brochures can go over it.
How to Check Your Page Size
You need the uncompressed size of the HTML document. That is not the size of the whole page with images and scripts. Browser tools and page speed reports often show the total page weight or the compressed transfer size. Both can mislead you.
Method 1: Chrome DevTools
- Open the page in Chrome, right-click and choose Inspect, then open the Network tab.
- Reload the page and filter by Doc so you only see the HTML document.
- Look at the Size column. With “Big request rows” turned on in the Network settings, it shows two values: the transferred (compressed) size, and the resource size under it. The resource size is the uncompressed figure that matters here.
Method 2: The Command Line
If you are happy using a terminal, curl gives you an exact byte count of the unpacked HTML. This is the method I use most, because it is quick and exact.
curl -s --compressed https://www.example.com/page/ | wc -cThe --compressed flag asks the server for a compressed response and unpacks it. So wc -c counts the uncompressed bytes. Divide by 1,048,576 to get megabytes. Anything close to 2MB needs attention.
To see what is using the space, count the bytes inside script and style blocks. Or just save the source and search it for data:image to find base64 images.
Method 3: Search Console URL Inspection
In Search Console, inspect the URL and open View crawled page to see the HTML Google has on record. Scroll to the end. Check whether your footer, closing tags and last paragraphs are there.
Don’t wait for a warning about the cutoff. Google’s documentation describes it as silent: Googlebot stops fetching and indexes what it has. Measuring the file yourself is the check I trust.
Method 4: A Site Crawler for Many Pages
For a large site, run a crawling tool that shows HTML document size per URL. Sort by size and review the largest templates. Usually one or two templates cause the problem, so fixing the template fixes thousands of URLs at once.
If you already run a quarterly technical audit as part of your SEO plan for 2026, add HTML document size as a column. That way oversized templates get caught early.
How to Fix a Page That Exceeds the Googlebot File Size Limit
The goal is simple. Get the HTML document well below 2MB uncompressed, and make sure your important content comes early in it. I always aim for a big safety margin rather than squeezing in just under the line.
1. Move Inline JavaScript and CSS Into External Files
This is usually the biggest win, and it is where I start. Put large scripts and stylesheets in separate .js and .css files and link to them. They are fetched separately and don’t count toward the HTML document’s limit.
Keep a small amount of critical CSS inline if your speed setup needs it. Just check that it really is small.
2. Replace Base64 Images With Normal Image Files
Serve images as normal files with <img src="..."> tags. Ideally use an efficient format and lazy loading for images lower down the page. You save the base64 extra size and take the image weight out of the HTML completely.
3. Trim Framework Hydration Data
If your site uses a JavaScript framework, look at the embedded state JSON. Often it holds whole API responses, including fields the page never shows. Ask your developers to send only what the page needs, or to load the rest when it is needed.
4. Split Giant Pages
Break huge category pages, archives and documentation into logical pages with clear internal links between them. A category with thousands of products should be split into pages with pagination or filters, not shown in one HTML file.
5. Put the Main Content First in the Source
Check the order of your HTML. Your main heading, body content and key internal links should come before bulky parts like large menus, embedded widgets and tracking code. Scripts that can wait should load at the end of the body or with defer.
6. Slim Down Navigation and Repeated Blocks
A mega menu with thousands of links, a footer with hundreds of links, or a “related products” block with full markup for dozens of items is repeated on every page. Cut these down to what users actually use. Honestly, I think most mega menus are too big for users anyway, not just for Googlebot.
7. Clean Up Leftover Code
Remove large HTML comments, unused inline styles from old page builder versions, duplicate tracking snippets and output from disabled plugins.
8. Handle Oversized PDFs
For PDFs over 64MB, compress the images inside, remove pages you don’t need, or split the document into parts. Better still, publish the key content as an HTML page and offer the PDF as a download. Then the important text can be indexed whatever the PDF’s size.
What Happens to Rendering and JavaScript
Google renders pages (runs them like a browser) to see content that JavaScript adds. The Googlebot documentation says each resource linked in the HTML, like a CSS or JavaScript file, is fetched separately. Each fetch has the same limit as other non-PDF files.
So a single JavaScript bundle that is several megabytes uncompressed may not be fetched in full. That is another reason to split large bundles. It is also why critical content should not depend on one huge script.
Google’s documentation does not explain every detail of how cut-off resources affect rendering. My advice is not to test the edge. Keep both your HTML and each script file well below the documented figures.
Other Size Limits Worth Knowing
The 2MB figure is not the only size limit Google documents. A few others often catch sites out.
- robots.txt: Google reads up to 500 KiB of a robots.txt file and ignores anything after that.
- XML sitemaps: one sitemap can be up to 50MB uncompressed or 50,000 URLs. Larger sites should split sitemaps and use a sitemap index file.
File size is also only one part of controlling what Google indexes. If you want to keep pages out of the index on purpose, use the right directives. Our guide to robots meta tags and the X-Robots-Tag covers noindex, nofollow and when to use each.
A Quick Example
Picture an online store’s “all products” page. The visible content is a grid of 1,200 products. The theme puts its full stylesheet inline in the head. Each product card has a base64 thumbnail. And the framework adds every product’s full data as JSON at the bottom.
Measured with curl --compressed, the HTML is well over 2MB. The grid starts after the inline styles and runs for most of the file. So the products near the end of the grid, the pagination links and the footer links fall past the cutoff.
The fix is simple. Move the stylesheet to an external file, switch thumbnails to normal image URLs, trim the JSON, and paginate the grid to a sensible number of products per page. The HTML drops to a small part of its old size, and every page’s content sits easily inside the limit.
How to Monitor This Going Forward
Page weight tends to creep up. A new plugin, a redesigned menu or a marketing tag can add hundreds of kilobytes without anyone noticing. I see this most often after a redesign, when nobody re-checks the templates.
- Add HTML document size to your regular technical audit. Flag any template above a level you are comfortable with. I like 1MB as a warning line.
- Check the largest templates again after any redesign, platform change or new page builder.
- Watch indexing trends in Search Console. If you use its weekly and monthly views, a drop in indexed pages or impressions for one page type is a sign to check that template’s size.
Conclusion
The Googlebot file size limit is now clearly documented. Googlebot reads the first 2MB of HTML and other supported files, and the first 64MB of PDFs, measured uncompressed. Google’s crawlers also have a 15MB general default. Google called the February update a clarification, and almost all pages are far below these figures.
The pages at risk are the unusual ones, packed with inline code, base64 images or thousands of items. Measure your biggest templates with DevTools or curl, move bulky code into external files, and keep your main content early in the source. Then add page size to your routine checks, so it never quietly turns into a problem.
