Page indexed without content: when Google stores the URL but not the page

Look at what Google received

1. Inspect the URL in Search Console.
2. Click View crawled page. The HTML tab shows the stored response. Note whether it is completely empty, a few lines of boilerplate, or a full document with an empty <body>.
3. Check More info → Page resources and the HTTP response for clues: content type, status and any resources that failed to load.
4. Click Test live URL, then View tested page → Screenshot. If the live render shows the page correctly, the problem is intermittent or already fixed. If the screenshot is blank or shows a challenge page, it is ongoing.

Compare with your own request:

curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page/ | wc -c

A byte count near zero confirms the server sends bots an empty body.

Causes we see on WordPress sites

A bot challenge returned with status 200. Some CDN and firewall configurations answer suspected bots with a JavaScript challenge or an empty page, but with a 200 status. Google sees a successful response containing nothing useful. Exempt verified search crawlers from challenges.

A PHP error after the headers were sent. The server commits to a 200, then the template dies before printing content. Visitors with a cached copy never notice. Check wp-content/debug.log and the PHP error log for the URL; errors that happen only for logged-out requests are a common variant.

A caching layer storing an empty response. If a cache captured the page during a failure, it serves that blank to everyone who is not logged in. Purge the page cache and CDN cache, then request the URL in a private window.

Content that exists only after JavaScript runs, and the script fails for Google. A page builder widget or app shell that depends on an API call blocked by robots.txt, a script that errors in Google's renderer, or content that appears only after a click. See JavaScript content not indexed.

Conditional output by user agent. Code or a plugin that removes sections "for bots" to save resources, or an optimisation feature that delays all rendering until user interaction.

The wrong content type. A page sent as application/octet-stream or with a broken Content-Encoding header may be unreadable even though browsers recover.

Repair and re-request

1. Fix the cause identified above and purge every cache layer.
2. Fetch the page logged out, with JavaScript disabled, and confirm the main text is in the HTML source. On a standard WordPress theme it will be, because posts are rendered on the server.
3. Run Test live URL again and check both the HTML and the screenshot.
4. Click Request indexing.

If many URLs are affected, look for what they share: one template, one post type, one plugin's shortcode. Fixing the shared component fixes them together.

Why it is urgent

An indexed URL with no content occupies the place the real page should hold. It cannot match queries, and until Google recrawls successfully, your working page does not replace it. For pages that previously ranked, traffic drops to zero while the status lasts. Our free SEO audit fetches the raw HTML of a URL and reports thin content when little text comes back, which is a quick outside check that the server is sending real markup to automated visitors.

Confirming recovery

Inspect the URL again a few days after requesting indexing. View crawled page should now show the full HTML, and the Page indexing status should read "Page is indexed" without the warning. Use Validate fix on the report row to have Google recheck the whole set.