- Getting indexed is a four-stage pipeline: discovered → crawled → rendered → indexed. A page can stall at any stage for a different reason.
- “Crawled – currently not indexed” almost always means a quality or duplication signal, not a technical block.
- Fix discovery first (sitemaps, internal links, direct push), because nothing downstream matters if Google never finds the URL.
- Verify with the URL Inspection API or a live index check — don't trust that a submission equals an indexing.
Most people treat indexing as a single yes-or-no event: Google either indexed the page or it didn't. That framing is why so many fixes miss. Indexing is a pipeline, and a URL can get stuck at any one of four stages — each with its own symptoms and its own fix.
If you work the stages in order, you stop guessing. Here's the whole map.
The four stages, in order
| Stage | What Google is doing | Where it shows up |
|---|---|---|
| Discovered | Found the URL, hasn't fetched it yet | "Discovered – currently not indexed" |
| Crawled | Fetched the HTML | "Crawled – currently not indexed" |
| Rendered | Ran JavaScript, built the final DOM | Missing content in the rendered HTML |
| Indexed | Stored it as eligible to rank | "URL is on Google" |
A page only ranks if it clears all four. The mistake is spending a week on render issues when the URL never got past discovered. Always diagnose top-down.
Stage 1 — Discovery: Google doesn't know the URL exists
This is the most common failure for new sites, new backlinks, and deep pages, and it's the easiest to fix.
Google finds URLs three ways: your sitemap, internal links, and external links pointing at the page. If a URL isn't in any of those, it effectively doesn't exist.
If a page has no internal links pointing to it, it's an orphan — and orphans are the single biggest source of "my page was never indexed."
The fix:
- Make sure the URL is in an XML sitemap that's submitted in Search Console.
- Link to it from at least one already-indexed page (ideally several).
- For time-sensitive pages and backlinks, use a direct push / indexing API rather than waiting for the next crawl.
Why speed matters for backlinks: a backlink passes almost no value until the page it sits on is crawled and indexed. Getting that page discovered quickly is often worth more than building another link.
Stage 2 — Crawled, currently not indexed
This status trips everyone up because the page was fetched — so it feels like Google is ignoring good work. It usually isn't a technical block. It's a judgment: Google crawled the page and decided it wasn't worth storing yet.
The usual causes, in rough order of frequency:
- Thin or templated content — the page is too similar to thousands of others, or has little unique value.
- Duplication — it's a near-copy of another URL and Google folded it into a canonical.
- Low site-level signals — new or low-authority sites get a smaller share of indexing.
- Crawl happened during a bad moment — a 5xx, a timeout, or a soft 404 at fetch time.
The fix: improve the page itself (depth, originality, internal links from strong pages), then request a fresh crawl. Re-submitting an unchanged thin page does nothing — Google already saw it.
Stage 3 — Rendering: the content isn't there when Google looks
If your content is injected by JavaScript after load, Google has to render the page to see it. Rendering is deferred and imperfect. Common traps:
- Content behind a click/scroll that never fires for a bot.
- Data fetched client-side that fails or times out for Googlebot.
robotsmeta tags injected by JS after an initialnoindex.
<!-- A trap: the server ships noindex, JS "fixes" it later. Google may cache the first one. -->
<meta name="robots" content="noindex">
The fix: serve the primary content and the final robots directive in the initial HTML (SSR or static). Check the rendered HTML, not the view-source, using the URL Inspection tool's "View crawled page."
Stage 4 — Indexing blockers you can rule out in five minutes
Before blaming quality, confirm none of these are quietly excluding the page:
noindexin a meta tag or theX-Robots-TagHTTP header.- A
robots.txtrule blocking the path (this blocks crawling, which can also prevent seeing a noindex — messy). - A
canonicalpointing at a different URL. - The page returning a soft 404 (200 status, "not found" content).
- Redirect chains that dead-end.
The header noindex is the sneaky one. It's invisible in the page source. Always check response headers, not just the HTML.
A diagnostic order that actually works
- Is it discovered? Search
site:yourdomain.com/exact-url. Nothing? It's a discovery problem — fix sitemaps, internal links, push it. - Is it blocked? Run the five-minute blocker checklist above.
- Does the rendered HTML contain the content? If not, it's a rendering problem.
- Still "crawled – not indexed"? It's a quality/duplication signal. Improve the page, strengthen internal links, then request indexing.
Work it in that order and you'll almost always land on the real cause instead of the first plausible one.
Where InstantIndexingPro fits
We built the product around exactly this pipeline: every URL you submit gets a pre-flight check for the blockers in stages 3 and 4, then a direct push through our discovery network for stage 1 — and we verify it in Google's index on day 4 and day 14 so you're never guessing whether a submission actually became an indexing. If it's still not indexed after 14 days, we re-submit it through every channel, free.
The point isn't to spam Google. It's to make sure the pages you worked hard on actually clear all four stages.
Mara Kessler
Mara has spent a decade untangling why pages don't get indexed — from crawl budgets on million-URL sites to a single stray noindex header. She leads indexing strategy at InstantIndexingPro.
Stop guessing whether Google indexed your pages
Paste your backlinks or new pages. We check each one for indexing blockers, push it through our discovery network, and verify it in Google's index on day 4 and day 14 — with proof.
Check up to 5 pages free