Page Indexed Without Content

TL;DR — “Page indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. without content” in Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. means your page is in Google’s index, but Google couldn’t actually read any usable content from it. That’s different from a robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. block, and it’s usually not a “write more words” problem. A frequent real cause is your server or CDN quietly blocking GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer., so Google gets an empty response even though the page looks fine to you — but treat that as one likely cause to check, not the only one.

What the status means

Open the Page IndexingThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. report in Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. (it’s under “IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.” in the left menu), and you may see a status called “Page indexed without content.” It’s sometimes shown as just “Indexed without content.”

Here’s the key thing: the page is indexed. Google foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. it and added it to the index. The problem is that Google could not read the page’s content. Evidence for this claim Google defines Page indexed without content as indexed even though Google could not read the content, citing cloaking or unsupported formats as examples. Scope: Google Search Console Page Indexing status; other diagnoses require inspection. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Google’s own docs name cloaking or an unindexable format as the possible reasons — and are explicit that this is not the same thing as the page being blocked by a page-level robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. disallow (that has its own separate report reason).

That makes this different from two statuses people mix it up with:

• “Discovered — currently not indexed” — Google knows the URL exists but hasn’t indexed it.
• “Crawled — currently not indexed” — Google crawled it but chose not to index it.

Both of those pages are not in the index. “Page indexed without contentA Google Search Console status meaning the URL is in Google's index, but Googlebot couldn't read any usable content from it — possible causes include a server/CDN block, cloaking, an empty render, or an unsupported format. Not the same as a page-level robots.txt block.” pages are — just with nothing readable in the index entry.

Why it usually isn’t what people think

The natural assumption is “Google can’t read my JavaScript.” Sometimes that’s true. But Google’s John Mueller has said the more common cause is a server or CDN blocking GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. — your hosting, firewall, or botA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.-protection setup hands Googlebot an empty response while normal visitors (and you) see the full page.

That’s why this can be sneaky: you load the page in your browser, it looks perfect, and you assume the report is wrong. But Google saw something different.

How to check what Google saw

Use the URL Inspection toolA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. in Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. (paste the URL in the search bar at the top). Then:

1. Click View Crawled Page to see what Google’s indexed crawl actually got — this is the record tied to the status you’re diagnosing.
2. Run Test Live URL too, but know what it can and can’t tell you here: Google lists this status among the conditions the live test can’t directly re-test, and a “valid” live result only means Google’s inspection tool can currently reach the page right now — it isn’t proof the indexed status has cleared.

If the indexed crawl looks blank but the page is full in your browser, that’s your sign something served Googlebot different (or no) content — most likely a server/CDN/bot-protection block or cloaking, not a writing problem.

Want the full cause list, a step-by-step diagnosis, and why curl won’t reproduce a Googlebot block? Switch to the Advanced tab.

TL;DR — “Page indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. without content” means the URL is in Google’s index but GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. couldn’t read any usable content from it — distinct from Crawled/ Discovered — currently not indexed, which aren’t indexed at all, and distinct from a page-level robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. block, which is its own separate reason. The default assumption is a JavaScript failure; in one January 2026 case, Mueller told a user this usually means a low-level server/CDN block, often IP-based and aimed at GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer., that you can’t reproduce with curl or a third-party crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.. Other possible causes: cloaking, an empty render, click-gated content, or an unsupported format — check them as evidence-led branches, not a fixed ranking. Diagnose with URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version.’s indexed View Crawled Page, keeping in mind Google explicitly lists this status among the ones the live test can’t directly re-test, and a “valid” live result isn’t proof the status has cleared.

What Google’s docs actually say

Google’s Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. documentation is short on this one: the page is in the index, but for some reason Google could not read the content. The doc’s own cause examples are that the page might be cloaked to Google, or might be in a format that Google can’t index — and the recommended action is to inspect the URL and look at the Coverage details. Evidence for this claim Google defines Page indexed without content as indexed even though Google could not read the content, citing cloaking or unsupported formats as examples. Scope: Google Search Console Page Indexing status; other diagnoses require inspection. Confidence: high · Verified: 2026-07-14 Google: Page indexing report (See the Official Docs and Quotes tabs for the verbatim wording and deep links.)

Two things worth being precise about, because guides on this term routinely blur both:

• Google’s wording is “could not read the content” — it does not describe an internal “blank object” it stores. Treat “blank/empty entry” as shorthand for the reader-facing effect, not a documented mechanism.
• This status is explicitly not the same thing as a page-level robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. disallow — that has its own separate reason in the report. Where robots.txt does matter here is indirectly: blocking a critical resource (a JS or CSS file the page needs to render) can still leave the render empty, which is a render-branch cause, not the robots reason itself.

Keep that straight and you won’t confuse this with the “not indexed at all” statuses, or with a robots block.

Don’t assume it’s JavaScript

This is the most important correction in the whole article, so I’ll lead with it.

The reflex — and most of the guides ranking for this term — treat “indexed without content” as a renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM./JavaScript problem. John Mueller pushed back on that in one specific case. Replying on Reddit’s r/TechSEO to a user whose homepage had dropped from roughly position 1 to position 15 after this status appeared, he told them this usually means the server or CDN is blocking Google from receiving any content, and that it isn’t related to JavaScript. He added that it’s typically a fairly low-level block, sometimes based on Googlebot’s IP address — which makes it effectively impossible to test from outside the Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. testing tools. The affected setup was reportedly Webflow on Cloudflare, a useful concrete example of where a CDN or bot-protection default can quietly starve Googlebot. (I’m paraphrasing a relayed Reddit remark here, not quoting it — treat the framing as the takeaway from one documented case, not a measured statistic about how often each cause occurs.)

That’s the correction worth internalizing: Mueller’s “usually” describes what he saw in that one exchange, not a ranked, universal cause order. Google’s own docs don’t rank the causes either — they just name cloaking and unsupported format as possibilities. So instead of a fixed 1-through-5 list, work through these as evidence-led branches and let what Googlebot actually received point you at the right one:

• Server / CDN / WAF response — something at the network layer is starving Googlebot of content (often IP-based, often invisible from outside). Mueller’s documented cause.
• Client-specific serving (cloaking) — Googlebot is served different or empty content than users. This can be intentional cloaking (a spam-policy violation requiring intent to manipulate rankings) or an accidental configuration difference — don’t call the accidental version “cloaking” as if it were the policy violation; call it what it is, a serving bug.
• Format / parser issue — the response isn’t in a format Google indexes, or the Content-Type header doesn’t match the actual content.
• Render / resource failure — a JavaScript render that fails, times out, or depends on a blocked resource, leaving the rendered HTML empty.
• Content gated behind interaction — content that only appears after a click or scroll Google never triggers.
• Genuinely empty output — the page really does render to nothing.

JavaScript is one branch to check — not the default, and not automatically ranked above or below the others without evidence from your own inspection.

Why this can cost you rankings

Worth flagging the urgency: in that one reported case, the site owner said their page fell from about position 1 to position 15 — a single user’s account, not an independently verified statistic, but a plausible outcome if Google is holding an unreadable version of a page that used to rank. This isn’t a cosmetic report status to shrug off — when it shows up on a page that matters, treat it as worth investigating promptly.

The server/CDN block, in detail

The reason this cause is under-covered is that it’s hard to see. A bot-protection or WAF rule, an IP allowlist, aggressive rate-limiting, or a security default that auto-updated can decide Googlebot looks like abusive traffic and return an empty body, a challenge page, or a non-200 status — but only to Googlebot’s IPs. You, your team, and your third-party crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. all hit the page from normal IPs and see the real thing.

That’s the trap: you can’t reproduce an IP-based Googlebot block with curl or a desktop crawler. They aren’t coming from Googlebot’s IP ranges. The only place you’ll reliably see what Googlebot got is inside Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.’s testing tools, which fetch as Google.

If you suspect this, the move is to verify what’s actually Googlebot (reverse + forward DNS, or Google’s published IP ranges) and then check your CDN’s bot management, firewall/WAF rules, IP allowlists, and rate limits for anything that would block those ranges. The Scripts tab has the verification commands.

Before changing anything, correlate the evidence rather than guessing: pull the indexed View Crawled Page response, your CDN/WAF event logs, and your origin server logs for the same time window, and look for a request ID, client category, and the specific rule or rate limit that denied the request. Then change only the narrowest route, client category, or rule you’ve actually confirmed is responsible — with a security review before you ship it. Broadly allowlisting all of Google’s published IP ranges isn’t something the reviewed sources support as a safe default; it widens your attack surface for a problem that’s usually one misconfigured rule. After the change, watch for confirmed Googlebot requests returning a full response in your logs, then re-check the indexed report on a later crawl — Google doesn’t publish a fixed re-crawl schedule, so this is a “keep checking,” not a “check back on day X,” situation.

The rendering / JavaScript cause (when it is JS)

When the cause genuinely is renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., the mechanism is straightforward: Google crawls the raw HTML, then a headless Chromium renders the page and runs its JavaScript. Google can only index what ends up in the rendered HTML. If your content is client-side rendered and that render fails, errors out, times out, or depends on a request that Google doesn’t make, the rendered HTML can come back empty — and you get indexed without content.

A specific flavor worth calling out: content gated behind interaction. I’ve written before in my JavaScript SEO guide that elements which only load content when clicked are a problem — Google doesn’t click, so it doesn’t see that content. Same with content that only appears on scroll or after a user action. If your main content needs a tap to exist, assume Google doesn’t have it.

The fix for the JS cause is the usual rendering playbook — server-side rendering or prerendering, making sure content is in the rendered HTML, and exposing navigation through real <a href> links rather than click-only handlers. (Full treatment in JavaScript SEO.)

Diagnosing it: URL Inspection is the whole game

There’s really one diagnostic that matters here, and it’s URL Inspection — but it has two different data sources, and mixing them up leads people to wrong conclusions. Google separates indexed data (what its last indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. crawl saw) from a live test (Google-InspectionTool fetching the URL right now), and they don’t answer the same question:

So the actual workflow:

1. View Crawled Page (indexed data). Read the rendered HTML, HTTP response, and page resources tied to the status — this is what Googlebot’s indexing crawl actually got. Availability of each piece can vary by status; if some fields aren’t shown, that itself is diagnostic (a blocked or non-200 response often shows less than a normal render).
2. Compare it to your own browser. If the indexed render is blank or stripped but the live page is full in your browser, you’re looking at a block or client-specific serving, not a missing-content problem.
3. Run Test Live URL anyway, but read it correctly. It won’t directly confirm this status has cleared, but it’s still useful: if the live test itself fails or flags an access problem, that’s real evidence; if it comes back “valid,” treat that as “currently reachable,” not “fixed.” Evidence for this claim URL Inspection can show Google's indexed/crawled information and supports a live test for the current accessible version. Scope: Google Search Console URL Inspection; live test results can differ from the indexed version. Confidence: high · Verified: 2026-07-14 Google: URL Inspection tool
4. Read the response and resources. A non-200 status, a challenge/interstitial, or blocked critical resources (JS/CSS the page needs) all point at the cause.

Because IP-based blocks won’t show up from outside, don’t trust an external curl or crawler to clear the page — the Search Console tools are the only thing fetching as Google, and even they need the indexed data, not just the live test, to speak to this specific status.

Telling the causes apart

A quick reference for statuses and causes people conflate with this one:

The myths to drop

• “Add 600 words and it’ll fix itself.” Word count is a thin-content/quality issue. If Google received no content, adding words to a page it can’t read changes nothing.
• “It’s a JavaScript problem.” Sometimes — but per Mueller it’s usually a server/CDN block, not JavaScript. Don’t start there.
• “I can reproduce it with curl.” Not if it’s an IP-based block on Googlebot.
• “It’s the same as Crawled/Discovered — currently not indexed.” No — those aren’t indexed at all; this one is.
• “Just hit Request Indexing.” Re-indexing without fixing the underlying block or render just re-confirms an empty page.

After you fix it

Once View Crawled Page shows real content again, use the report’s Validate Fix flow and/or Request Indexing to prompt a re-crawl, then re-inspect to confirm the render now contains your content. Validation without a fix just bounces.

Where this sits

This is one status in the Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason., which sits inside Google’s broader indexing stage (crawl → render → index → serve). The sibling statuses in that report — the “currently not indexed” pair, duplicate/canonical statuses, and the blocked/error statuses — each fail at a different point in the pipeline. For the rendering mechanics behind the JS cause, see rendering and JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript.; for how the report as a whole works, see the Page Indexing report hub.

AI summary

A condensed take on the Advanced version:

• What it means: the URL is in Google’s indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., but GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. couldn’t read any usable content from it. A Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. status in Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — Google names cloaking or an unindexable format as possible causes, and explicitly excludes a page-level robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. block.
• Not the same as “Crawled — currently not indexed” or “Discovered — currently not indexed” — those pages aren’t indexed at all. Also not the same as a page-level robots block, or a 401/403 (those have their own dedicated reasons).
• It usually isn’t JavaScript. In one January 2026 case (paraphrased from a relayed Reddit remark), Mueller told a user this usually means a low-level server/CDN block — often IP-based and aimed at GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. — that you can’t reproduce with curl or a third-party crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.. That’s one documented case, not a measured prevalence ranking.
• Cause branches to check (evidence-led, not a fixed order): server/CDN/WAF response, client-specific serving (cloaking or an accidental config bug), format/parser issue, render/resource failure, content gated behind clicks/scroll, genuinely empty output.
• It can cost rankings: one user reported a drop from ~position 1 to ~15 — a single account, not a verified statistic.
• Diagnose with URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version.’s indexed View Crawled Page first — that’s the record tied to the status. The live test can’t directly re-test this specific status, and a “valid” live result only means the page is currently reachable, not that the status has cleared. Blank in the indexed view but full in your browser ⇒ block or client-specific serving, not word count.
• Verify Googlebot (reverse/forward DNS or published IP ranges), correlate CDN/ WAF/origin logs for the exact denying rule, and change only that narrow rule with a security review — broad IP allowlisting isn’t a supported default.
• Adding more words doesn’t fix a page Google can’t read. After a real fix, use Validate Fix / Request Indexing, then keep re-checking — Google doesn’t publish a fixed re-crawl timeline.

Official documentation

Primary-source documentation for this status and the tools you diagnose it with.

Google

• Page Indexing report — Search Console Help — the report this status lives in, with the verbatim “Page indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. without content” definition and its cloaking / unsupported-format cause examples.
• URL Inspection Tool — Search Console Help — View Crawled Page and Test Live URL; how to see the rendered HTML, screenshot, HTTP response, and page resources GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. received.
• Understand the JavaScript SEO basics — why Google can only index content in the rendered HTML, and how to check the render.
• Overview of Google crawlers and fetchers — GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. user-agentsA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. and the published IP ranges, for diagnosing an IP-based block.
• Verifying Googlebot and other Google crawlers — the reverse + forward DNS check.

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — Bing uses different status labels and has no exact “indexed without content” equivalent, but its URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. offers a similar fetch/render view for BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share..

Quotes from the source

On-the-record wording from Google’s documentation. Each link is a deep link that jumps to the quoted passage on the source page.

Google — the Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. definition

• “This page appears in the Google indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., but for some reason Google could not read the content.” — Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason., Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. Help. Jump to quote

Google — JavaScript and the rendered HTML

• “To make sure that Google can still see your content after it’s rendered, use the Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. Test or the URL Inspection ToolA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. and look at the rendered HTML.” — Understand the JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript. basics, Google Search Central. Jump to quote

A diagnosis decision tree

Work it top to bottom. The whole point is to stop assuming “it’s JavaScript” and let what GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. actually received decide for you.

Step 1 — Confirm it’s really this status. Is the page in the IndexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. bucket of the Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. (not “Crawled — currently not indexed” or “Discovered — currently not indexed”)? If it’s in the not indexed group, you’re solving a different problem.

Step 2 — Look at what GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. got. URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. → View Crawled Page (indexed data) → read the rendered HTML and HTTP response tied to the status. (A screenshot is live-test only, not part of the indexed view.)

• Render has your content → the status record may be stale; run Test Live URL for current reachability (note it can’t directly re-test this status), and if that looks fine too, validate/request indexing and move on.
• Render is blank, stripped, or wrong → continue.

Step 3 — Compare to your browser. Open the live URL yourself.

• Blank for Google, full for you → this is a block or cloaking, not a content problem. Go to Step 4.
• Blank for both → it’s a render or content problem. Go to Step 5.

Step 4 — Block / cloaking branch. Check the HTTP response and page resources in URL Inspection for a non-200, a challenge/interstitial, or blocked critical resources. Then verify Googlebot (reverse/forward DNS or published IP ranges) and audit your CDN botA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. management, WAF/firewall rules, IP allowlists, and rate limits for anything blocking those ranges. Correlate logs to find the exact rule responsible and change only that narrow rule, with a security review — don’t broadly allowlist Google’s IP ranges. Remember: an external curl or third-party crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. won’t reproduce an IP-based Googlebot block — only the Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. tools fetch as Google.

Step 5 — Render / content branch. Is the content client-side rendered, gated behind a click/scroll, or in an unsupported format? Fix the render (SSR/prerenderThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal., content in the rendered HTML, real <a href> links — Google doesn’t click). If the page is genuinely empty, that’s the answer.

Step 6 — Validate. Only after View Crawled Page shows real content: use Validate Fix and/or Request IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., then re-inspect to confirm.

”Page indexed without content” diagnosis checklist

Run it in order — it’s deliberately weighted toward the block/render causes, not word count:

• Confirmed the URL is in the IndexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. bucket (not “Crawled/Discovered — currently not indexed”).
• Ran URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. → View Crawled Page (indexed data) and read the rendered HTML and HTTP response tied to the status.
• Knew that a screenshot is live-test only — not part of the indexed view.
• Checked the HTTP response for a non-200, challenge page, or interstitial.
• Checked page resources for blocked JS/CSS the page needs.
• Opened the live URL in my own browser and compared it to Google’s indexed render.
• Did not treat a “valid” Test Live URL result as proof this status has cleared — it only means the page is currently reachable to Google’s tester.
• If blank-for-Google/full-for-me: treated it as a block or client-specific serving, not automatically “cloaking” (that term implies manipulative intent) and not a content issue.
• Ruled out a page-level robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. block and a 401/403 as the real reason (those are separate, dedicated statuses).
• Verified GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. (reverse + forward DNS, or published IP ranges).
• Correlated CDN/WAF logs, origin logs, and request IDs to find the exact denying rule, then changed only that narrow rule, with a security review — not a broad GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.-IP allowlist.
• Did not assume curl / a third-party crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. clears it (IP blocks won’t reproduce externally).
• If render-related: confirmed content is in the rendered HTML, not gated behind a click/scroll, and reachable via real <a href> links.
• Did not “just add 600 words” as a fix.
• After a real fix: ran Validate Fix / Request Indexing and re-inspected.

Verify it’s really Googlebot

If you suspect a server/CDN block, first confirm the requests in your logs are genuinely GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. (lots of traffic fakes the user-agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target.). Use a reverse + forward DNS check — Google publishes no shortcut.

macOS / Linux

# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

If the reverse lookup doesn’t end in a Google domain, or the forward lookup doesn’t match the original IP, it isn’t GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.. You can also match the IP against Google’s published ranges (googlebot.json).

Compare raw vs rendered HTML yourself

This won’t reproduce an IP-based Googlebot block (you aren’t on Google’s IPs — that’s why URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. is the real test). But it’s still the fastest way to spot a client-side-renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. gap: if the raw HTML is nearly empty and the page only fills in after JS runs, your content depends on a render that can fail.

macOS / Linux — fetch the raw HTML and eyeball how much real content is in it:

# Raw HTML as a plain GET (what a crawler sees before rendering)
curl -sL https://example.com/page/ -o raw.html

# Rough "is there content?" check — count visible-ish characters
# (a near-empty body here on a content page is a red flag for CSR)
wc -c raw.html

# Optional: render with a headless browser to compare, if you have Chrome installed
# (Chrome path varies; this dumps the post-JS DOM)
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --headless --disable-gpu --dump-dom https://example.com/page/ > rendered.html
wc -c rendered.html

Windows (PowerShell)

# Raw HTML as a plain GET
Invoke-WebRequest -Uri "https://example.com/page/" -OutFile raw.html
(Get-Item raw.html).Length

# Render with headless Chrome to compare (adjust the Chrome path as needed)
& "C:\Program Files\Google\Chrome\Application\chrome.exe" `
  --headless --disable-gpu --dump-dom "https://example.com/page/" > rendered.html
(Get-Item rendered.html).Length

A big gap between raw.html and rendered.html means your content is JavaScript-dependent. A small, near-empty raw.html on a page that should be full is exactly the kind of thing that renders to nothing if the JS fails. Either way, confirm against URL Inspection’s View Crawled Page — that’s the only fetch that sees what Googlebot actually got.

Mistakes that waste time on this status

These are the specific missteps I see people make when they hit “page indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. without content” — each one either points you at the wrong cause or destroys the evidence you needed to find the right one.

Rewriting the page’s copy before checking View Crawled Page. Adding words is a thin-content fix. If Google received no content at all — a blank or blocked response — extra words never reach the index entry that’s already empty. Check View Crawled Page first; only write more content if the render genuinely shows a thin (not blank) page.

Assuming it’s JavaScript and jumping straight to a renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. fix. It’s the default guess, but per John Mueller it’s usually a server/CDN block instead. Spending a sprint on SSR/prerendering when the real problem is a WAF rule means the status never clears — and you’ve burned dev time solving the wrong layer.

“Clearing” the page with curl or a third-party crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.. An IP-based GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. block won’t reproduce from your IP, your crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.’s IP, or any tool that isn’t fetching as Google. A clean curl response tells you nothing about what GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. got. Only URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version.’s Test Live URL fetches as Google.

Hitting Request Indexing on repeat without fixing anything. Re-submitting a blocked or blank page just re-confirms the same empty render. Request IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. (or Validate Fix) only means something after View Crawled Page shows real content.

Treating a CDN/WAF change as safe because your own browsing was unaffected. Bot-management defaults, IP allowlists, and aggressive rate limits can target Googlebot’s IP ranges specifically while leaving normal visitor traffic untouched — so “the site works fine for me” proves nothing about what Googlebot sees. Verify Googlebot’s requests in your logs (or with the URL Inspection toolsA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version.) before and after any CDN/security change.

Confusing this with “Crawled/Discovered — currently not indexed,” a robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. block, or a 401/403. Those are each separate, dedicated reasons in the report. The first pair means the page isn’t in the index at all; a page-level robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. disallow and a real 401/403 have their own statuses too. “Page indexed without contentA Google Search Console status meaning the URL is in Google's index, but Googlebot couldn't read any usable content from it — possible causes include a server/CDN block, cloaking, an empty render, or an unsupported format. Not the same as a page-level robots.txt block.” means the page is indexed, just unreadable. Applying a not-indexed fix (better internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them., sitemap prioritySitemap priority is the optional <priority> tag (0.0–1.0, default 0.5) in the sitemaps.org XML protocol meant to rank a URL's importance relative to others on the same site. Google ignores it entirely — as does Bing — and it was never a ranking factor even by the spec's own admission.) or a robots fix to this status misses the actual cause entirely.

Calling every bot/user content difference “cloaking.” Cloaking, under Google’s spam policy, requires intent to manipulate rankings by misleading users. An accidental empty response to Googlebot from a misconfigured CDN rule is a serving bug, not proof of a policy violation — mislabeling it can send you chasing the wrong fix (a manual-action response) instead of the actual one (a config change).

”Page indexed without content” — quick reference

What it is

Don’t confuse it with its neighbors

Cause branches — check the evidence, not a fixed order

Which tool answers which question

Ready-to-copy AI prompts

These are for the diagnostic step, not for guessing the cause from a description — paste in what the tools actually returned, and always confirm the AI’s read against URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. yourself before acting on it.

Diagnose the likely cause from what URL Inspection showed you

I'm diagnosing a "Page indexed without content" status in Google Search Console.
Here's what I have:
- Rendered HTML from View Crawled Page: [paste it, or "blank"]
- HTTP response status/headers from View Crawled Page: [paste them]
- What the live page looks like in my own browser: [describe or paste raw HTML]
- Whether Test Live URL shows the same result: [yes/no + what it showed]

Based only on this evidence, rank the most likely cause among: (1) a server/CDN/WAF
block targeting Googlebot, (2) cloaking, (3) a JavaScript rendering failure,
(4) content gated behind a click or scroll, (5) a genuinely blank page or
unsupported format. Explain which specific detail above points to your top pick,
and tell me what additional evidence would confirm or rule it out. Don't assume
JavaScript is the cause by default.

Audit a CDN/WAF config description for a GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.-blocking rule

Here is a description of my CDN/WAF setup: [paste your bot-management settings,
rate-limit rules, IP allowlist/denylist entries, and any custom firewall rules].
Google's crawler IP ranges are published at
https://developers.google.com/static/search/apis/ipranges/googlebot.json.
Identify any rule that could return an empty response, a challenge page, or a
non-200 status to Googlebot's IP ranges specifically, even if normal visitor
traffic is unaffected. List each suspect rule and what to check or relax first.

Draft an escalation to my host/CDN provider

Draft a short, specific support ticket to my hosting/CDN provider. Context: Google
Search Console shows "Page indexed without content" for [URL]. Google's own
View Crawled Page tool shows an empty/blocked response, while the page loads fully
in a normal browser — which points at a server or CDN-level block on Googlebot's
IP ranges, not a content or JavaScript issue. Ask them to check bot-management,
WAF, and rate-limiting logs for requests from Google's published crawler IP ranges
around [date/time], and to confirm whether any rule is blocking or challenging
those requests.

Prove Googlebot is actually getting content now

“I changed the WAF rule” or “I fixed the render” isn’t proof — the only result that counts is what GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. receives on the next fetch. These tests check that, not just that you made a change.

Test 1 — Confirm the fix in what Google actually inspects

• Test to run — URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. on the affected URL. Run Test Live URL first — it can’t directly re-test this indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. status, but it does confirm whether Google-InspectionTool can currently reach the page and shows a fresh screenshot. Then read the rendered HTML and HTTP response. Cross-check against your own render with the Render Gap tool if the cause was client-side renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM..
• Expected result — The live test’s rendered HTML and screenshot contain your actual content, matching what a normal visitor sees in a browser, and the HTTP response is a clean 200.
• Failure interpretation — Still blank, stripped, or non-200 means the block, serving difference, or render failure is not actually fixed — don’t move on to Validate Fix yet. Note this confirms current reachability, not that the indexed status itself has updated; that only shows up once Google re-crawls and re-indexes the URL.
• Monitoring window — The live test result is immediate; whether the indexed status has actually cleared only shows up after Google’s next scheduled crawl of this URL, which isn’t published or predictable.
• Rollback trigger — Still blank or non-200 after the change you believed fixed it — revisit the cause branches rather than repeating Request Indexing.

Test 2 — Confirmed Googlebot requests now get a full 200 response

• Test to run — Pull recent server/CDN logs and isolate requests from confirmed GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. IPs (reverse + forward DNS, or Google’s published ranges), using Log File Analyzer to separate real Googlebot hits from spoofed user-agentsA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target.. Compare status codes and response sizes before and after your fix.
• Expected result — Confirmed Googlebot requests return 200 with a full-size body, not a challenge page, empty body, or non-200 status.
• Failure interpretation — Confirmed Googlebot IPs still getting blocked or empty responses means the WAF/CDN rule you changed wasn’t the one causing this, or wasn’t relaxed enough.
• Monitoring window — Watch log volume across Googlebot’s next several visits rather than expecting an instant result — Google doesn’t publish a fixed recrawlCrawl frequency is how often a search engine comes back to re-fetch a page it already knows about. Popular pages that change often get refreshed many times a day; stable pages can go weeks or months between crawls — and you influence it indirectly, not by setting a dial. schedule for a given URL.
• Rollback trigger — Confirmed Googlebot traffic is still blocked in logs after the fix — go back to auditing botA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.-management rules, don’t assume the first change was sufficient.

Test 3 — The Page Indexing status stops recurring

• Test to run — Run Validate Fix in the Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason., and periodically re-check the URL’s indexed content with the Google Index Checker.
• Expected result — The status clears (validation passes) and subsequent checks keep showing real, indexed content — not a reversion to blank.
• Failure interpretation — Validation failing, or the status reappearing later, usually means the block/render issue is intermittent (e.g. only some requests get blocked) rather than fully resolved.
• Monitoring window — Google doesn’t publish a fixed re-crawl or validation timeline for this — don’t judge it the day you click Validate Fix; check back periodically until the report updates.
• Rollback trigger — The status returns to “indexed without content” after a validation cycle completes — treat it as unresolved and restart from Test 1.

Test yourself: Page indexed without content

Five quick questions on the GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. “Page indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. without content” status. Pick an answer for each, then check.

Page indexed without content

A Google Search Console status meaning the URL is in Google's index, but Googlebot couldn't read any usable content from it — possible causes include a server/CDN block, cloaking, an empty render, or an unsupported format. Not the same as a page-level robots.txt block.

Parent concept: Page Indexing report · Related: Rendering, JavaScript SEO, Indexing

Page indexed without content

“Page indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. without content” (sometimes shown as “Indexed without content”) is a status in Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason.. It means the URL is in Google’s index, but when GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. crawled and rendered it, Google could not read any usable content. Google’s own docs name cloaking or an unindexable format as possible reasons, and are explicit that this is not the same thing as a page-level robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. block, which has its own separate reason in the report.

That makes it different from “Crawled — currently not indexed” and “Discovered — currently not indexed”: those pages aren’t indexed at all, while this one is. The problem here is an index entry with nothing usable in it, not a missing URL.

Possible causes include a server or CDN block that starves GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. of content (documented in at least one case as often IP-based and low-level, not reproducible from outside), client-specific serving or cloaking (serving Googlebot something different from what users see — cloaking specifically requires intent to manipulate rankings under Google’s spam policy), a JavaScript or renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. failure that leaves the rendered HTML empty, content gated behind a click or scroll, a genuinely blank page, or a format Google can’t index. The fix is rarely “add more words” — you diagnose it by inspecting the URL and looking at the rendered HTML and HTTP response tied to the indexed status (a screenshot is available only in the live test, which can’t directly re-test this specific status).

Parent concept: Page Indexing report · Related: Rendering, JavaScript SEO, Indexing

Changelog