WP Technical SEO Consultant
"Discovered, currently not indexed" means Google knows your URL exists but hasn't crawled it yet: it found the address and decided fetching it can wait. The cause is almost always crawl priority, your site's crawl budget, server speed, or weak signals telling Google the page isn't urgent.
This status frustrates people precisely because nothing is "broken": no error, no penalty, just a queue your page never seems to leave. The good news is that queues have rules. Here's what puts pages at the back of Google's line, how this status differs from its crawled cousin, and the fixes that actually move the queue.
What does "discovered, currently not indexed" mean?
Google's pipeline runs discover, crawl, render, evaluate, index. This status is a page stopped at stage one: the URL entered Google's to-do list, through your sitemap or a link, and has been sitting there since. Googlebot hasn't fetched the page even once, which means Google knows nothing about its content yet. The judgment being made isn't about quality of the page; it's about priority of the fetch.
That's also why the status often clears on its own for a page or two, and why it becomes a real problem when dozens or hundreds of URLs camp in it for weeks: that's a systemic signal that Google doesn't consider crawling your site urgent.
How is it different from "crawled, currently not indexed"?
They're adjacent lines in the same report and opposite problems:
| Discovered, not indexed | Crawled, not indexed | |
|---|---|---|
| What happened | Google never fetched the page | Google fetched, read, and declined it |
| Problem type | Crawl-side: priority, budget, server | Quality-side: content, duplication, signals |
| What Google knows | Nothing yet | Everything, and it said no |
| Primary fixes | Budget cleanup, speed, link signals | Content consolidation, quality, internal links |
| Wrong response | Rewriting content Google never read | Blaming crawl budget for a quality verdict |
Diagnose before treating: if you're in the crawled bucket, this page's fixes won't help you, and the crawled currently not indexed guide will.
Why does Google delay crawling a page it knows about?
- Crawl budget is being spent elsewhere. Your site exposes thousands of low-value URLs, tags, filters, feeds, archives, and Googlebot's finite attention goes there instead of your new page. The most common cause on WordPress; the crawl budget pillar covers the full cleanup.
- The server is slow or shaky. Google throttles crawling to protect struggling servers. Sustained slow responses or intermittent errors quietly shrink how much Googlebot is willing to fetch, and new URLs feel it first.
- The page's signals whisper instead of shout. No internal links, absent from the sitemap, buried deep in the site: everything about the URL says low priority, so it waits.
- The site is new or lightly trusted. Young domains start with minimal crawl demand. Google fetches cautiously until the site accumulates history, and long discovery queues are part of that phase.
How do you fix it?
In order of effect:
- Clean the crawl surface. Block the parameter and search spaces in robots.txt, prune junk archives, flatten redirect chains: the full sequence in the crawl budget guide. Every wasted fetch you remove is a fetch available for the queued pages.
- Link to the stuck pages from strong pages. Internal links from your homepage or best-crawled content are the loudest priority signal you control. A page linked from home rarely stays discovered-only for long.
- Confirm the pages are in the sitemap, and that the sitemap is clean. A truthful sitemap focuses Google's attention; one padded with redirects and junk dilutes it.
- Fix server speed if Crawl Stats shows strain. Check average response time in Search Console's Crawl Stats. Sustained slowness needs hosting or performance work; that layer belongs to my dedicated speed practice, the WordPress speed optimization service.
- Request indexing for a handful of priority URLs. For a few important pages, URL Inspection's request genuinely accelerates the first crawl. For hundreds of URLs it's not a strategy, it's a coping mechanism; fix the system instead.
- Give new sites time while doing the above. On a young domain, a shrinking discovery queue over weeks is success. A growing one is the signal to work this list harder.
Can you force Google to crawl a page?
Request Indexing is the only legitimate nudge, and it's per-URL and rate-limited by design. Everything else sold as "forcing" a crawl, pinging services, mass submission tools, is noise Google learned to ignore years ago. The honest lever isn't force, it's priority: make the fetch cheap (fast server, clean surface) and make the page look worth fetching (links, sitemap, placement). Do both and the queue moves on its own.
Does hosting speed really matter here?
More than almost anywhere else in SEO, yes. Crawl capacity is explicitly tied to how your server responds: Google crawls less when a site responds slowly or errors. That makes this one of the few statuses where a hosting upgrade or a performance fix directly changes an indexing outcome. If your Crawl Stats response times run high and your pages queue endlessly, speed isn't a nice-to-have, it's the fix.
Pages stuck in the queue for weeks? The crawlability and indexing service diagnoses every queued URL, fixes the budget and signal causes, and tracks your coverage report until it clears, $149 flat. Or start with the $49 health check.