Discovered currently not indexed is a Search Console status that means Google knows a URL exists but hasn’t crawled it yet. It isn’t a penalty, and it isn’t a verdict on the page’s content, because Google hasn’t fetched the page. It’s a scheduling decision: Google has decided other URLs are worth crawling first. The usual advice, click Request Indexing and wait, works for a handful of URLs and fails for hundreds. The real fix is to work out which URLs in the bucket you actually want indexed, why Google isn’t prioritising them, and whether the rest should exist at all.
What Google Says the Status Means
Google’s Page indexing report help page defines it plainly: “The page was found by Google, but not crawled yet.” It adds: “Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl. This is why the last crawl date is empty on the report.”
That explanation leans on server load, but Google’s own people describe a broader picture. In a 2023 Search Central office-hours answer, John Mueller said that “for large sites, sometimes crawling more is limited by how your website can handle more crawling,” then added: “In most cases though, it’s more about overall website quality.” In other words, Google judges how much of your site is worth crawling from what it has already seen.
Google’s crawl budget guide names this status directly. Its audience includes sites with “a large portion of their total URLs” in this status. That puts the status where it belongs: it’s a crawl budget symptom first, and a content problem only indirectly.
Discovered vs Crawled: Two Different Problems
People confuse this status with its sibling, and the fixes are almost opposite:
| Discovered – currently not indexed | Crawled – currently not indexed | |
|---|---|---|
| Has Google fetched the page? | No | Yes |
| Last crawl date | Empty | Present |
| What Google is judging | Whether the URL deserves a crawl (crawl demand, server capacity) | Whether the page deserves a place in the index (quality, duplication) |
| First fix to try | Internal links, cut competing URLs, server health | Improve, merge or consolidate the content |
| Does editing the page text help? | Not directly, because Google hasn’t read it | Yes, that’s usually the lever |
The last row is the mistake most guides skip: rewriting a page Google has never fetched changes nothing Google can see. The signals around the URL are what matter. If your pages are stuck one stage later, read Crawled – currently not indexed instead.
The Three Real Causes
Nearly every case comes back to one of three causes, often more than one at once:
- Weak crawl demand for the URL. Google’s crawl budget documentation lists popularity as a demand factor: “URLs that are more popular on the Internet tend to be crawled more often.” A page found only in a sitemap, with no internal links and no backlinks, gives Google little reason to fetch it soon.
- Too many URLs competing for the same budget. Google says that without guidance it “tries to crawl all or most of the URLs that it knows about on your site.” Parameter variants, filtered category pages, internal search results and thin tag archives all compete with your real pages. The guide’s first recommendation is to “eliminate duplicate content to focus crawling on unique content rather than unique URLs.”
- Server capacity. Google’s crawl capacity limit drops when a site returns server errors or rate-limiting signals: “the limit goes down and Google crawls less.” Slow or unstable hosting shrinks how much Google is willing to fetch.
Mueller’s quality point sits across all three. Google can’t judge an uncrawled page, so it estimates from the rest of the site. A site full of near-empty pages teaches Google that new URLs on that domain are rarely worth a fetch.
When You Can Ignore It
Not every entry needs action. Asked in a February 2022 office-hours session how long the status can last, Mueller said: “That can be forever.” Google doesn’t crawl and index every URL it finds. Google’s crawl budget guide is aimed at sites with 1 million+ unique pages that change weekly, or 10,000+ pages that change daily.
So ignore it when the URLs are ones you never wanted indexed (feeds, parameter variants, paginated archives), when the pages were published in the last few days, or when the count is small and stable. Act when the bucket contains pages that should earn traffic: products, services, money posts. Also act when the count climbs week after week: the site is generating URLs faster than Google wants to crawl them.
Step 1: Split the Bucket With the Sitemap Filter
The Page indexing report has a dropdown above the chart with four views: “All known pages,” “All submitted pages,” “Unsubmitted pages only,” and any individual sitemap you’ve submitted. Open the Discovered – currently not indexed row in two of those views:
- All submitted pages: URLs you told Google matter, via a sitemap, that it still hasn’t crawled. This is your priority list.
- Unsubmitted pages only: URLs Google found on its own, mostly through links. On many sites this list is mostly junk: sort and filter parameters, session-style variants, attachment pages, staging leftovers. These aren’t pages to get indexed. They’re pages to stop generating.
Two caveats from Google’s help page. The example table “is limited to 1,000 rows” and isn’t guaranteed to show every URL with that status, so treat it as a sample and look for URL patterns rather than counting rows. And the report isn’t meant for checking single pages; for that you need the URL Inspection tool.
Step 2: Check How Google Found Each Important URL
Take five to ten URLs from the submitted list and inspect them. The Discovery section shows two fields that point to the cause. Sitemaps lists submitted sitemaps that include the URL. Referring page shows “a page that Google possibly used to discover this URL.” Google notes that an empty referring page “doesn’t mean that no referring page exists,” so confirm it with your own crawl.
The pattern to look for: sitemap listed, no referring page, no last crawl. That page is effectively orphaned in Google’s eyes. It was announced in a sitemap but nothing on the site vouches for it. Google’s own wording on sitemaps explains why that’s weak: submitting one “is merely a hint.”
Step 3: Fix Internal Links Before Anything Else
Google’s link guidance is blunt: “Every page you care about should have a link from at least one other page on your site.” It also says Google can reliably follow only <a> elements with an href attribute. Links built from script click handlers, or menus that only appear after interaction, may never be followed.
For each priority page, add at least two or three contextual links from pages Google already crawls often: the relevant category or hub, the homepage if it’s commercially important, and related posts. Keep key pages a few clicks from the homepage, not buried behind pagination. Our guide to orphan pages covers how to find pages with no inbound links at scale.
In SEO Rocket, ask the chat whether a page is orphaned and it crawls the live site, reads the real <a href> links, and reports which pages link to the target, the anchors used, and which related pages don’t link to it yet. The site audit records crawl depth and inbound internal links for every URL, so weakly linked pages stand out.
Step 4: Cut the URLs Competing for Crawl Budget
Now go back to the unsubmitted list. Group it by pattern and decide what each pattern should be:
- Duplicate variants (parameters, trailing-slash and case variants, http/https leftovers): consolidate with redirects or canonicals, and stop linking to the variants internally.
- Crawl traps (faceted filters, internal search, calendar pages): block crawling with robots.txt if they have no search value. Google’s crawl budget guide says to use robots.txt for this, not noindex, because Google still has to request a noindexed page to see the tag. Test rules first with the Robots.txt Tester, and see faceted navigation SEO for which filter pages are worth keeping.
- Removed or empty pages: return a 404 or 410. Google warns that soft 404 pages “will continue to be crawled, and waste your budget.”
- Redirect chains: point internal links at the final URL. Google’s guide notes long chains hurt crawling.
Then tidy the sitemap so it lists only canonical, indexable 200-status URLs. Google uses lastmod if it’s “consistently and verifiably” accurate, and it ignores priority and changefreq entirely, so don’t bother tuning those.
Step 5: Rule Out Server Capacity
Open Settings, then Crawl stats in Search Console. Check host status for robots.txt fetching, DNS resolution and server connectivity problems, and watch average response time for spikes. Google says this report “is aimed at advanced users” and that sites with fewer than a thousand pages generally shouldn’t need it. That’s a useful hint: if your site is small and the status persists, capacity is rarely the cause, and links or quality are.
On bigger sites, the crawl purpose breakdown separates Discovery (URLs never crawled before) from Refresh. If almost all requests are refreshes, Google is spending its budget re-checking what it already knows.
A Worked Example (Hypothetical)
A services business with a few hundred pages adds 120 templated location pages. A month later, the Discovered row in the Page indexing report keeps growing. Filtered to submitted pages, almost all of it is the location pages. Filtered to unsubmitted, it’s sort parameters from the blog archive.
URL Inspection on three location pages shows the same thing: listed in the sitemap, no referring page, no last crawl. A crawl confirms that no page links to them; they exist only in the sitemap. Many differ only by the town name.
The fix order: merge the location pages that have nothing unique to say into stronger regional pages, link the survivors from a locations hub and the relevant service pages, block the sort parameters from crawling, and remove them from internal links. Then request indexing for the hub only, and watch two things: last crawl dates appearing in inspection, and URLs moving out of the Discovered row. If some move to Crawled – currently not indexed, that’s progress. Google has now read them, and the question has become content quality.
What Not to Do
- Don’t spam Request Indexing. Google says there’s a quota, and that “requesting a recrawl multiple times for the same URL won’t get it crawled any faster.” Use it on a few hub pages after a real change.
- Don’t re-click Validate Fix. Google says validation “typically takes up to about two weeks” and asks you not to click it again until it succeeds or fails.
- Don’t publish more of the same. Adding pages while hundreds sit uncrawled deepens the problem. Mueller’s quality point means the next thin batch hurts the existing pages too.
- Don’t noindex to save budget. Noindex controls indexing, not crawling.
The playbook behind SEO Rocket, proven across 1,000,000+ ranking pages, comes down to one rule for indexing: fewer, better-linked URLs beat more URLs. If the issue is a whole site missing from search rather than one bucket, start with website not showing on Google.
FAQ
How long does discovered currently not indexed last?
There’s no fixed timeline. Google says crawling after a request can take a few days to a few weeks, and Mueller has said the status “can be forever” for pages Google never prioritises. If a page you care about is still stuck after a few weeks, fix its links and the competing URLs rather than waiting longer.
Is it a penalty?
No. It’s not a manual action and not a judgement of that page’s content, since Google hasn’t fetched it. It reflects crawl demand, server capacity and what Google has learned from the rest of the site.
Will submitting a sitemap fix it?
Usually not by itself. These URLs are often already in a sitemap, and Google calls a sitemap “merely a hint.” Internal links and a leaner site do more.
Should I delete pages stuck in this status?
Delete or merge the ones with no unique value, and block crawl traps. Keep and link the ones that should earn traffic.
