
How to Fix 'Discovered' and 'Crawled — Currently Not Indexed' in Google Search Console
Practical fixes for the two most confusing Google Search Console coverage statuses, plus how long each one typically takes to resolve on its own.
August 20, 2026 · 5 min read
If you've spent any time in the Coverage report, you've probably seen one of these two statuses sitting next to a page you actually want indexed: "Discovered — currently not indexed" or "Crawled — currently not indexed." They sound similar, Google's own documentation is vague about the difference, and neither one comes with a clear deadline. This guide covers what actually moves the needle for each status, what's a waste of time, and how long a realistic fix takes.
For a full breakdown of what the two statuses mean and why Google treats them differently, see our explainer on Discovered vs. Crawled — Currently Not Indexed. This post focuses on the fix.
Why Google Leaves Pages in Limbo
Both statuses come down to the same underlying decision: Google knows the URL exists, but has decided — for now — that crawling or indexing it isn't worth the resources. That's not a technical error message; it's a prioritization call, and it's usually driven by one or more of these:
- Perceived low value. Thin, duplicate, or near-duplicate content relative to what's already indexed on your domain or elsewhere.
- Crawl budget. Smaller or newer sites get a smaller crawl allowance, and Google spends it on pages it already trusts.
- Weak internal signals. A page with no internal links pointing to it, or links only from other low-authority pages, looks unimportant.
- Site-wide trust. A newer domain with limited backlink history gets indexed more slowly and more selectively across the board.
Neither status necessarily means something is broken. Sometimes it means Google is right — the page genuinely doesn't add much on top of what you already have indexed.
How to Fix "Discovered — Currently Not Indexed"
"Discovered" means Google found the URL (through your sitemap, an internal link, or an external link) but hasn't crawled it yet at all. The fix here is almost entirely about signaling that the page deserves a crawl slot sooner:
- Link to it from an already-indexed, reasonably authoritative page on your own site. Internal links are the cheapest and most direct signal you control.
- Check your sitemap isn't burying it. A sitemap with thousands of low-value URLs dilutes attention across all of them. If your sitemap is bloated with tag pages, filtered views, or thin auto-generated pages, trim it.
- Confirm the page isn't accidentally orphaned — no internal links pointing to it at all is one of the most common causes of a page sitting in "Discovered" indefinitely.
- Don't request indexing yet. If Google hasn't crawled it, manually requesting indexing usually just triggers a crawl that ends in the same "not indexed" outcome, because the underlying value signal hasn't changed.
How to Fix "Crawled — Currently Not Indexed"
This one is more informative, because Google already looked at the page and chose not to index it. That's a content or quality signal, not a discovery problem:
- Compare it against what's already indexed on your site. If it's a thin variation of an existing page — same topic, different filter or sort order — consolidate or canonicalize instead of trying to force both into the index.
- Add genuinely new information. Expand sections that are currently a sentence or two, add original data, screenshots, or examples that don't exist on competing pages.
- Check for accidental duplicate or near-duplicate content, including content syndicated elsewhere, boilerplate-heavy templates, or auto-generated pages with minor variations.
- Improve internal linking from relevant, indexed pages — the same page that ranks for a related term is a good candidate to link from.
- Re-request indexing after making changes, not before. Requesting indexing on unchanged content just gets you the same decision a second time.
When to Request Indexing Manually (and When Not To)
The "Request Indexing" button in Search Console is useful for exactly one situation: you've made a real change and want to speed up Google noticing it. It is not useful for:
- Pages you haven't touched since the last crawl.
- Bulk-requesting many URLs at once (Search Console rate-limits this and it can look like spam behavior).
- Working around a fundamental quality issue instead of fixing it.
Used sparingly, on pages you've actually improved, it can shave days off the wait. Used as a substitute for fixing the underlying issue, it just produces the same status again.
How Long It Actually Takes to Resolve
There's no fixed timeline, but rough patterns hold across most sites:
- Discovered → Crawled: Typically a few days to two weeks after adding strong internal links, assuming your site is crawled regularly.
- Crawled → Indexed: More variable. Meaningful content improvements can get reconsidered within one to three weeks; on lower-authority or newer domains, it can take longer because Google simply revisits the page less often.
- No change after a month: Usually a sign the fix wasn't substantial enough, not that you need to wait longer. Revisit the content itself before requesting indexing again.
Newer domains should expect the slower end of these ranges across the board — this is a trust and crawl-budget issue, not a bug.
Monitoring So You Don't Have to Check Manually
Coverage statuses shift on their own schedule, and checking the Search Console UI page by page doesn't scale once you have more than a handful of URLs to watch. Traffic Monitor tracks your Search Console coverage data alongside rankings and traffic in one place, so a page moving from "Crawled — currently not indexed" to indexed (or the reverse) shows up as a change you'd actually notice, instead of something you have to go looking for.
If you're currently splitting your attention between the Coverage report, Analytics, and a rank tracker, consolidating that into a single view is usually the fastest way to catch indexing problems before they've been sitting unresolved for weeks.
Related posts
Alternate Page With Proper Canonical Tag: Is It Actually a Problem?
Google Search Console flagged a page 'Alternate page with proper canonical tag.' Here's what it means, when to ignore it, and when it's a real issue.
Duplicate Without User-Selected Canonical: What It Means (And How to Fix It)
Confused by "Duplicate without user-selected canonical" in Search Console? Here's what it means, when it's harmless, and how to actually fix it.
Track your blog rankings automatically
Connect Google Search Console and get daily alerts, keyword research, and AI diagnostics — free to start.
Start free →