Page indexed without content

What this status means

According to Google's documentation (Page indexing report), the page appears in the Google index, but for some reason Google could not read the content. The document names two possible reasons, cloaking and a format Google cannot index, states that this is not a case of robots.txt blocking, and tells you to inspect the page for the cause.

The status sits in the warnings group. Google describes warnings as issues that do not prevent indexing but reduce its ability to understand and index your pages. Without content there is nothing to match against the queries that matter, so for a product or category page the fix has the same priority as a Crawled - currently not indexed problem.

Common causes

Content that exists only after JavaScript runs

A single-page application, a headless front end or a widget that fetches the product description from an API after load. Google's JavaScript SEO basics documentation explains that pages with a 200 status are queued for rendering and that content not present in the rendered HTML will not be indexed. If the script fails during rendering, times out or waits for a user event, the rendered page is empty. The JavaScript rendering entry explains the process.

Scripts or API endpoints blocked by robots.txt

The HTML is allowed, but /api/ or /_next/static/ is disallowed. The same Google document says Google will not render JavaScript from blocked files, so the shell loads and the content never arrives. This is why the warning can be caused by robots.txt even though the page itself is not blocked.

A different page served to Googlebot

A CDN rule, a bot-management product or an A/B testing tool serves an empty version to clients it identifies as bots. Google's spam policies call it cloaking when crawlers get different content than users. It also happens by accident: a cache stores a failed, cookieless response and serves it to Google until it expires.

A format Google cannot parse

A page that is a single image of text, a canvas element drawn by script, a PDF made of scanned images, or HTML served with a wrong Content-Type such as application/octet-stream. Google receives bytes but no text.

Empty templates and failed data sources

The CMS returns 200 with the layout but the main block is empty: an unpublished product whose URL still resolves, a category with no products, a template whose data query returned nothing after a migration. The header and footer render, so nobody notices.

Consent walls and interstitials

A consent layer or an age gate that removes the main content from the DOM until the visitor clicks. Googlebot does not click. Content hidden with CSS is still read; content removed from the HTML or rendered only after consent is not.

Overlap with soft 404

An empty template often also shows "no results". Google may then report the URL as a soft 404 instead of this warning. Google's HTTP status codes documentation describes a soft 404 as a page that returns 2xx but whose content looks like an error. The fix is the same: real content or a real 404.

How to confirm it

1. Inspect the URL in Search Console and open View crawled page. The HTML tab shows what Google stored. A body made of script tags and an empty container points at rendering or blocked resources.
2. Run Test live URL and click View tested page. According to Google (URL Inspection tool) the live test fetches the URL in real time, so the screenshot and rendered HTML show whether the problem still exists. The More info tab lists resources that could not be loaded.
3. Fetch the raw HTML yourself: curl -s -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://example.com/page/ | wc -c and compare with a normal user agent. A much smaller response for Googlebot means a rule serves crawlers a different page.
4. Check the Content-Type header with curl -sI; a page should return text/html.
5. Open the page with JavaScript disabled. If the main content disappears, anything that breaks rendering breaks indexing.
6. Run the URL through the indexability checker to rule out a conflicting noindex or canonical on the same page.

How to fix it

1. JavaScript-only content: server-side render or pre-render the main content so the text is in the initial HTML. Otherwise make sure the script runs without user interaction and does not depend on blocked resources. Verify with the rendered HTML in URL Inspection.
2. Blocked resources: remove the robots.txt disallow for the script, CSS and API paths the page needs, then retest. Google's robots.txt introduction advises against blocking resources whose absence makes the page harder for Google to understand.
3. Different page for bots: find the rule in the CDN, WAF or testing tool that keys on the user agent or on bot score and exclude verified Google crawlers from it. Then purge the cache.
4. Unparseable format: put the text in HTML. For PDFs, make sure the file has a text layer.
5. Empty templates: return 404 or 410 for products and categories that no longer exist, redirect where a replacement exists, and fix the data query for pages that should have content. The indexability entry lists what Google needs from a page to keep it.
6. Consent walls: keep the content in the HTML and overlay the consent layer, instead of injecting the content after consent.
7. Request indexing for the fixed URLs that matter most and watch the warning count over the following weeks.

When it is fine and when to act

It is fine on pages that should not rank anyway: an empty search results page, a cart, a logged-out account page. Add noindex to those and the warning becomes irrelevant.

Act when the list includes product, category or article pages, when the count jumps after a front-end release or a CDN change, or when one template is affected across many URLs. A site that moved to a JavaScript framework and sees this warning on hundreds of pages has lost its content in Google even though every URL is still "indexed".

How IndexRise helps

IndexRise fetches every monitored page each night and compares the status code, title, H1 and canonical with the saved baseline. A page that suddenly returns an empty title or H1 raises an event, and a status that changes from 200 to 4xx raises a critical one confirmed on the next check, which is how a release that broke a template shows up the morning after. A request that could not be completed is reported as "couldn't check" rather than as a change on the page. The full list of checks is on the features page.