Search Console Says “Discovered—Currently Not Indexed”—What Should You Fix?
A new page is live, included in your sitemap and visible when you open it—yet Google Search Console reports “Discovered—currently not indexed.” The wording is important: Google knows the URL exists, but has not crawled it yet. Until that crawl happens, Google cannot evaluate the page for indexing.
This is different from “Crawled—currently not indexed,” where Google fetched the page and then chose not to index it. The right fix is therefore not an immediate rewrite. Start by finding why the URL remains in the crawl queue and whether your site is asking Google to spend time on too many low-priority URLs.
What “Discovered—currently not indexed” means
Google’s Page indexing report documentation explains that the URL was found but not crawled. Google may postpone the crawl when fetching the site at that moment could overload it. Discovery can happen through a sitemap, an internal link, an external link or another known URL.
The report is a status, not a penalty. A few recently published pages can sit there temporarily. A large or persistent group deserves investigation, especially when important product, service or location pages remain uncrawled while filtered, duplicate or outdated URLs keep consuming discovery signals.
First confirm that you are diagnosing the right problem
Inspect the exact canonical URL—not a parameter variation, an old slug or a redirected version. Then compare its status with related URLs. If Search Console shows that Google already fetched the page, follow Webcurry’s guide to Crawled—currently not indexed instead.
Also separate this status from Page with Redirect, soft 404, canonical conflicts and noindex exclusions. Those problems require different evidence and different fixes.
Step 1: Verify that the URL is genuinely crawlable
A discovered URL may still be difficult or impossible to fetch. Test the public page while logged out and confirm that it returns a normal HTTP 200 response without requiring cookies, a login, a geographic redirect or a JavaScript-only navigation event.
Check robots.txt for a rule that blocks the page path or a required resource.
Confirm the final URL does not redirect through a chain or loop.
Verify that the canonical points to the same preferred indexable URL.
Make sure the page does not return intermittent 5xx, timeout or rate-limit responses.
Check mobile and desktop behavior because Google primarily crawls the mobile version.
Confirm that a firewall, CDN or bot-protection rule is not challenging Googlebot.
Search Console’s URL Inspection live test can show whether Google can access the current version. If the live test fails, fix access or server behavior first. Repeated indexing requests will not repair a URL that Googlebot cannot reliably fetch.
Step 2: Strengthen internal discovery and page priority
A sitemap tells Google that a URL exists, but internal links explain how the page fits into your site. Google recommends standard crawlable anchor links—an HTML a element with an href attribute—because script-only buttons and click handlers may not expose a dependable crawl path.
Link the page from a relevant category, service hub, navigation path or established article. Use descriptive anchor text and make sure the link appears in the rendered mobile page. A page linked only from another weak or uncrawled page remains several steps away from the site’s trusted structure.
Add one or more contextual links from closely related indexed pages.
Include the page in an appropriate hub or category page.
Avoid creating an orphan page that exists only in the sitemap.
Keep important pages within a sensible click depth from the homepage.
Remove internal links to obsolete parameters, test URLs and redirecting variants.
Do not add dozens of unrelated links solely for crawling. A small number of useful contextual links is clearer for visitors and search engines than a sitewide block of forced keyword anchors.
Step 3: Audit the sitemap as an inventory, not a magic switch
A sitemap should contain canonical URLs that you genuinely want in search. Google describes sitemaps as discovery signals, not commands. Submitting the same unchanged sitemap repeatedly does not force an immediate crawl.
Check whether the affected URL appears once, uses the preferred HTTPS hostname and matches its canonical. Remove redirected, noindex, error, parameter and duplicate URLs from the indexable sitemap. Accurate last-modified dates can help Google understand meaningful updates; automatically changing every date on every publish weakens that signal.
Wix automatically updates its sitemap when the site changes, so normal content edits do not require repeated sitemap submissions. The better action is to verify the page entry, improve its internal links and request inspection for the exact canonical URL after the page is complete.
Step 4: Reduce low-value URL inventory
Google has finite crawling resources. On a small business site, a true crawl-budget shortage is uncommon, but a messy URL inventory can still make discovery less efficient. Faceted navigation, tag archives, internal-search URLs, calendar combinations, tracking parameters and duplicated language or print versions can create far more URLs than the site has useful pages.
Map the URL patterns reported in Search Console and server logs. Look for many variations that resolve to nearly identical content. Consolidate duplicates with clean internal links, consistent canonicals and platform-appropriate controls. Do not use robots.txt casually: blocking crawling can prevent Google from seeing redirects, canonicals or a removed noindex directive.
Step 5: Check whether the server is asking Google to slow down
Google adjusts crawling so it does not overwhelm a host. According to Google’s crawl-error troubleshooting guidance, new pages may wait when the site reaches serving capacity, returns errors or exposes inefficient URL inventory.
Review hosting and CDN logs around Googlebot requests. Repeated 500, 502, 503, 429 or timeout responses are more useful evidence than a generic speed score. Also check whether a security service begins challenging bots during traffic spikes or whether uncached dynamic pages are unusually expensive to generate.
Stabilize server errors before requesting more crawling.
Cache public pages appropriately without serving stale indexing directives.
Avoid blocking verified Googlebot through aggressive rate limits.
Fix redirect chains and slow database queries that increase response time.
Use log data to distinguish an actual Googlebot crawl from spoofed user agents.
Wix, WordPress and Shopify checks
Wix
Publish the page, confirm search indexing is enabled and verify that it appears in the automatically generated sitemap. Add a normal text or button link from a relevant indexed page. If the URL is dynamic, confirm the CMS item is not empty, hidden or restricted and that the dynamic page resolves consistently. The Wix SEO checklist covers the broader setup.
WordPress
Check Settings > Reading, the page’s robots controls and the XML sitemap produced by the active SEO plugin. Review tag, author, date, filter and attachment URLs so the sitemap does not compete with a large archive inventory. Inspect caching, security and maintenance plugins if Googlebot receives a different response from visitors.
Shopify
Confirm that the product or page is published to the Online Store channel and linked from a collection, menu or relevant content page. Audit collection filters, search parameters and app-generated landing pages. Keep unavailable or duplicate variants from creating unnecessary crawl paths, while preserving crawlable links to canonical products and collections.
What not to do
Do not request indexing every day while the underlying crawl path remains weak.
Do not keep resubmitting an unchanged sitemap.
Do not rewrite a useful page before confirming that Google has ever crawled it.
Do not add index directives as if they force crawling or indexing.
Do not block duplicate patterns without checking whether Google needs to crawl their redirects or canonicals.
Do not assume every newly published page must appear in search immediately.
A practical validation sequence
Confirm the exact canonical URL returns HTTP 200 to a logged-out visitor.
Verify that robots.txt allows the URL and essential resources.
Check that the page appears once in the correct sitemap.
Add contextual links from relevant indexed pages.
Remove or consolidate wasteful duplicate URL patterns.
Investigate server errors, rate limits and crawl logs.
Run Search Console’s live test, then request indexing once.
After making changes, allow time for Google to revisit the site and update the report. An accepted indexing request is not a guarantee, and a sitemap submission does not reserve a crawl time. Watch whether Googlebot begins fetching the affected pattern and whether URLs move from discovered to crawled states.
Fix the crawl path before polishing the page again
“Discovered—currently not indexed” is primarily a crawling-stage diagnosis. Make the important URL easy to reach, keep the indexable inventory clean and ensure the server can respond reliably. Once Google crawls the page, content quality, duplication and canonical selection become the next questions.
If a group of business-critical pages remains discovered but uncrawled after the crawl path and server checks are clean, collect the affected URLs, sitemap entries, internal-link sources and server-log evidence. A documented pattern is far easier to diagnose than isolated manual submissions. For a technical review, contact Webcurry with the affected URL set and Search Console screenshots.
Comments