This check fires when a crawler requests your URL and gets back essentially nothing — no <html> element, an empty body, or a shell with no real content in the raw response. It matters because if the HTML is empty at fetch time, search engines and AI crawlers may have nothing to index, and a page that returns nothing ranks for nothing.
What "missing or empty HTML" really means
The crawler isn't judging your design; it's looking at the raw bytes the server sent before any JavaScript ran. If that response is blank, a bare <html></html>, or an empty <div id="root"></div> waiting to be filled by client-side JS, the check trips. The usual culprits: a JavaScript app that renders everything in the browser and ships an empty shell, a server error that returned a 200 status with a blank page, an aggressive firewall or bot rule serving a challenge page to crawlers, or a broken template that output nothing. Google can render JavaScript, but rendering is a second, delayed, budget-limited pass — and many AI crawlers don't render at all. If your content only exists after JS runs, you're betting your indexing on a maybe.
A real failing example
The classic single-page-app shell — what the crawler sees is an empty container, because the real content is injected client-side:
<!DOCTYPE html>
<html>
<head><title>My App</title></head>
<body>
<div id="root"></div>
<script src="/bundle.js"></script>
</body>
</html>The fix is to make the server send real, rendered content in the initial response — via server-side rendering, static generation, or prerendering — so the crawler gets the goods immediately:
<!DOCTYPE html>
<html>
<head><title>Merino Base Layers | TrailKit</title></head>
<body>
<div id="root">
<h1>Merino Wool Base Layers</h1>
<p>Lightweight, odor-resistant layers for winter hiking...</p>
<!-- full content present in the server response -->
</div>
<script src="/bundle.js"></script>
</body>
</html>Client-side JS can still hydrate and take over — but the content is already there if the script never runs.
Empty-HTML causes and where to look
| Cause | Tell-tale sign | Fix direction |
|---|---|---|
| Client-side-only rendering | Empty root div in view-source, full in browser | Add SSR / SSG / prerender |
| Server error served as 200 | Blank page, status still 200 | Fix app error; return correct status |
| Bot firewall / challenge page | Content for humans, blank for crawlers | Allowlist known crawlers |
| Broken template | Whole section blank | Repair the template output |
| Redirect or timeout mid-load | Inconsistent across fetches | Check server logs / response time |
How to detect it on your own site
- View source, not the rendered page. Right-click → "View Page Source" (or
view-source:in the address bar). This is the raw HTML before JavaScript. If your content isn't here, crawlers may not see it either. - Fetch it like a bot. From a terminal,
curl -s https://yoursite.com/page/ | wc -cshows how many bytes the server actually returns. A near-empty response is your answer — no browser rendering to hide behind. - Use Search Console URL Inspection. "View crawled page" shows the exact HTML Googlebot received. If it's blank while your browser shows a full page, you've confirmed a rendering-dependency problem.
- Disable JavaScript and reload. In DevTools, turn JS off and refresh. If the page goes blank, everything is client-side rendered — which is precisely what leaves non-rendering crawlers with nothing.
How to fix it
- Identify why it's empty. Rendering issue, server error, or firewall? The table narrows it down. Don't guess — a 200-that-should-be-500 needs a different fix than an SPA shell.
- Get real content into the first response. For JS frameworks, switch to server-side rendering or static generation so the HTML arrives populated. If that's a big lift, prerendering is a reasonable stopgap.
- Return honest status codes. A page that failed to build should return 500, and a missing page should return 404 — not a blank 200 that tricks crawlers into indexing nothing.
- Let crawlers through. Confirm your WAF, CDN, or bot manager isn't serving Googlebot a challenge or empty page. Verify by user agent and by Google's published IP ranges.
- Re-inspect. Re-run URL Inspection and a
curlto confirm the response now carries content, then request re-indexing.
FAQ
Google renders JavaScript, so why does empty initial HTML matter?
Google can render JS, but it's a deferred second pass with a real crawl budget attached, so indexing gets slower and less reliable. And plenty of other crawlers — Bing in some cases, and most AI bots — render little or nothing. If your content only exists after JavaScript runs, you're leaving a chunk of the search and AI ecosystem staring at a blank page. Our piece on SSR vs CSR for AI crawlers covers who sees what.
My page looks perfectly fine in the browser. How can the HTML be "empty"?
Your browser runs JavaScript and paints the result; the check reads the raw server response before any script executes. If the content is assembled client-side, the browser shows a full page while the raw HTML is an empty shell. View-source and curl reveal the difference.
Is this the same as a soft 404?
Related but not identical. A soft 404 returns a 200 for a page that's really "not found." Empty HTML is broader: it includes SPA shells, server errors masked as 200s, and firewall pages. Both share the root sin of returning a 200 with no useful content.
Could my security setup be causing this?
Yes, and it's a sneaky one. A WAF or bot manager can serve real visitors the full page while handing crawlers a JavaScript challenge or a blank body. If humans see content but URL Inspection shows nothing, check your bot rules first — it's a common cause that has nothing to do with your app code.
How is this different from an empty title tag?
Empty HTML means the whole document came back with no content; an empty title means the document is fine but one critical tag is blank. Same family of "the crawler got nothing where it expected something," different scope. See Title Tag Is Empty for the narrower case.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
