Discovered – Currently Not Indexed: How to Diagnose and Fix It
Quick Answer
“Discovered – currently not indexed” means Google knows a URL exists but has not crawled it yet. Check its internal links, sitemap, public access, and server health first. Google may delay crawling for several reasons, and the status alone does not reveal the exact cause or promise when crawling will happen.
Key Takeaways
These findings help you choose the next step without making changes based on guesses. Start with the checks that show whether Google can reach important pages and whether your site can serve them reliably.
- Google has discovered the URL, but the reported status shows that it has not yet been crawled.
- A successful live URL test does not prove that Google's regular crawler has visited the page.
- Google considers both crawl capacity and crawl demand when deciding how to crawl a site.
- Slow responses, HTTP 5xx errors, HTTP 429 responses, and unstable access can reduce crawl capacity.
- XML sitemaps and useful internal links help Google discover URLs but cannot force crawling or indexing.
- Repeated requests to crawl the same URL do not make Google process it faster.
- Duplicate pages and unnecessary URL variations may be better consolidated than submitted again.
The best response depends on what the evidence shows. Fix confirmed problems, improve discovery where needed, and give Google time to revisit the URL without assuming a fixed deadline.
Understand What the Status Means Before Changing Anything
Google has found your URL, but it has not crawled it yet, according to the reported status. This describes the stage your URL has reached. It does not provide a full diagnosis of your website.
Google Search works through several distinct stages. It discovers URLs, crawls pages, processes them for indexing, and may then show them in search results. Progress through one stage does not guarantee the next. A URL can be known to Google without being fetched. A crawled page can also remain outside the index.
Google's Page Indexing report documentation explains the difference between discovered and crawled URLs. It also describes how Search Console reports indexing states. These reports help narrow an investigation, but they do not reveal every reason behind Google's decisions.
Consider a new article on a small business website. The article exists and its URL appears in an XML sitemap. Yet few pages link to it, and Google has not visited it. The URL may remain discovered while Google decides when to crawl it. The sitemap helps Google find the address, but it does not set a crawl deadline.
Do not assume the page is broken or has received a penalty. The status alone proves neither. First check the URL's importance, discovery paths, access, and site health. Review content quality and indexing rules as part of a wider check, but do not treat them as confirmed causes of a URL that has not yet been crawled.
The next step also depends on whether the page deserves its own search result. An original service page or useful article may warrant further work. A tracking URL or near-duplicate page may not need a separate result at all.
Compare Discovered and Crawled Statuses
The difference between these two statuses determines where troubleshooting should begin. A discovered URL has not yet been crawled. A crawled URL has been fetched, but Google has not included it in the index under that reported state.
Google documents both statuses in its Search Console Page Indexing guidance. Use the comparison below to avoid applying the wrong fix to the wrong stage.
| Reported status | What it establishes | First checks | What it does not prove |
|---|---|---|---|
| Discovered – currently not indexed | Google knows the URL but has not crawled it yet. | Internal links, sitemap, server health, crawl access, and URL inventory. | That the page is broken or has poor content. |
| Crawled – currently not indexed | Google has crawled the URL but has not indexed it. | Page value, duplicate content, canonical selection, and indexing eligibility. | That a technical fault or content problem is the cause. |
| Indexed | The report indicates that the URL is in Google's index. | Check the selected canonical and the context of any conflicting report. | That the page will rank for a particular search. |
For a discovered URL, focus first on how Google finds the page and whether your site can serve it. If the URL later moves to a crawled status, review the new evidence. You may then need to assess content, canonical signals, and other indexing factors.
A status change is useful information, even when the page is still not indexed. It tells you that the next investigation may need to change. Do not keep repeating the same crawl checks after the evidence points to a different problem.
Check Search Console and Record the Current State
Start with the exact URL in Google Search Console. Record the reported status, inspection date, available discovery details, and any crawl information shown. Keep a copy of the results before making changes.
Google's URL Inspection and crawling troubleshooting guidance explains the available checks. Search Console's Page Indexing report shows patterns across groups of URLs. URL Inspection provides more detail about an individual address, subject to the information available for that URL.
A live test and a stored report answer different questions. The stored report describes Google's recorded view. A live test checks the current URL under the tool's test conditions. A successful live test does not prove that Google's regular crawler has visited the page or that the URL will be indexed.
Use this simple record for each important URL:
- URL and page type: Record the exact address and whether it is an article, product, service, or another page.
- Reported status: Save the exact Search Console label and the date you checked it.
- Discovery details: Record any available sitemap, referring page, or other discovery information.
- Live test: Note whether the current test succeeds and record any reported errors.
- Site changes: Record fixes, deployment dates, and the next review date.
Each item serves a purpose. A missing last-crawl date is consistent with the discovered status. It should not be recorded as proof that the server failed. Likewise, a successful live test is evidence of current test access, not proof of a completed regular crawl.
If many URLs share the same status, group them by page type and site template. Test a few representative URLs first. If the same pattern appears across a whole section, investigate the shared template or server behavior before editing each page separately.
Check Server Health and Crawl Access
A site must be able to serve its pages reliably when Google attempts to crawl them. Start by checking the response code, redirects, access rules, and server behavior for affected URLs. Fix an observed fault before trying to increase discovery.
Google's crawl budget guidance, updated July 22, 2026, explains two related factors: crawl capacity and crawl demand. Crawl capacity concerns how much Google can crawl without overloading a site. Crawl demand concerns which URLs Google wants to crawl and how often.
Server health can affect capacity. Slow responses, HTTP 5xx server errors, HTTP 429 rate-limit responses, and unstable availability may reduce Google's ability to crawl a site. Check your hosting logs, monitoring data, and Search Console Crawl Stats where available. Look for repeated failures and periods when response times rise.
An HTTP 200 response only shows that the server returned a successful response for that request. It does not prove that Google has crawled the URL or will index it. A live test can also succeed even when the regular crawl has not yet happened.
Use the actual error to guide the repair. If a URL returns HTTP 429, review rate limits and automated traffic controls. If it returns HTTP 5xx, inspect the server or application error. If it redirects, confirm that the final destination is the intended page. Do not change hosting settings without evidence that they are causing a problem.
Crawl-budget work is not always necessary. Google's guidance gives rough examples of sites that may benefit from a detailed review, including sites with one million or more URLs that change weekly, sites with 10,000 or more URLs that change daily, and sites with a large share of discovered-but-uncrawled URLs. These are examples, not strict thresholds. A small website should usually start with access, links, and sitemap checks.
Improve Internal Links and Sitemap Discovery
Important pages should be reachable through useful links from other accessible pages. Do not rely on the XML sitemap as the only route to a page. A relevant link from a category page, main service page, or related article gives visitors and crawlers another way to find the URL.
Google's crawling troubleshooting guidance recommends reviewing crawl access, internal links, and sitemap setup when diagnosing crawling problems. Use standard crawlable HTML links with clear anchor text. Link to the actual destination rather than sending visitors through unnecessary redirects.
For example, a product page listed in a sitemap may still have few useful links from the rest of the site. Add a relevant link from the product category or a related buying guide if that helps visitors find it. The change improves the page's place in the site structure. It does not guarantee that Google will crawl it immediately.
Check the sitemap itself. It should contain the canonical URLs you want Google to discover. Remove entries that point to redirects or unwanted URL variations. Keep last-modified dates accurate when page content genuinely changes. Do not update dates just to make unchanged pages look new.
A sitemap and internal links serve related but different purposes. The sitemap gives Google a list of URLs that matter to the site. Internal links show how those pages fit into the site's content and navigation. Both can help discovery, but neither forces Google to crawl every listed address.
If the page is important but has no sensible place in the site's navigation, reconsider its role. A useful page should normally connect to related content. If the page serves no distinct purpose and has no clear place in the site, it may not deserve a separate index target.
Review URL Inventory and Page Value
Some sites create far more URLs than they need. Filters, sorting options, tracking parameters, session IDs, and duplicate page versions can create many addresses for similar content. A large URL inventory can make crawl planning more complex, especially when many URLs offer little new value.
Google's crawl budget documentation explains that URL inventory and crawl demand can affect crawling. Its spam policies also address scaled content abuse, including large amounts of unoriginal, low-value content created mainly to manipulate search results. These sources support a careful review, not a claim that every uncrawled page is low quality.
Start by asking what each URL adds. Does it serve a distinct visitor need? Is it a separate product, service, or resource? Does it provide useful details that are not already available elsewhere on the site? If the answer is no, adding more words may not solve the problem.
A short page can be useful when it answers a narrow question well. A long page can be weak if it repeats the same material found on several other pages. Review the actual information, not just the word count. Improve missing details, original evidence, useful examples, and navigation where they help the reader.
For duplicate URLs, decide which version should represent the content. Align internal links, redirects, sitemap entries, and canonical signals with the intended structure where appropriate. Do not create more copies in the hope that one will be crawled first.
The same rule applies to large-scale content publishing. Publishing many pages without a clear purpose can expand the URL inventory without adding enough value. Google's spam policies do not ban all AI-generated content. The concern is content made at scale without useful value, especially when its main purpose is to manipulate rankings.
IndexNowFast already has a broader guide to why Google may not index pages. Use that resource for wider indexing issues. This article focuses on the earlier discovery-to-crawl stage, where access, links, server health, and URL inventory deserve attention first.
Use a Cause-and-Action Decision Framework
Choose your next step from an observed result, not from a list of guesses. The table below brings together the main checks and shows what to do if a possible cause is confirmed. It is a practical synthesis of Google's guidance, not an official Google scoring system.
| Observed symptom | How to check it | Action if confirmed | What remains unknown |
|---|---|---|---|
| The URL returns HTTP 5xx. | Review server logs, application errors, and hosting alerts. | Fix the server problem and retest the public URL. | Whether Google will crawl it next or index it later. |
| The URL returns HTTP 429. | Check rate limits and automated traffic controls. | Adjust an unintended restriction and confirm stable access. | How soon Google's regular crawler will return. |
| Responses are often slow. | Compare server response times and Crawl Stats over time. | Fix the confirmed bottleneck and monitor stability. | Whether slow responses explain every affected URL. |
| Important pages have few internal links. | Review navigation and links from relevant pages. | Add useful, crawlable links where they help visitors. | Whether any one link will trigger a crawl. |
| The URL is absent from the intended sitemap. | Check sitemap entries and the canonical destination. | Add the preferred URL if it belongs in the sitemap. | Whether Google will crawl or index it. |
| Many URLs have similar content. | Group URLs by template, parameters, and page purpose. | Consolidate or exclude unnecessary variations where appropriate. | Whether the remaining pages will be indexed. |
| The URL has no clear reader purpose. | Compare it with related pages and the need it serves. | Improve its unique value or decide that a separate URL is unnecessary. | Whether content value alone explains the status. |
| The live test succeeds, but the URL remains discovered. | Review the stored report, links, sitemap, and crawl history. | Fix confirmed issues, then monitor for a later crawl. | The exact scheduling reason for the delay. |
The table separates evidence from assumptions. A server error supports a server investigation. A weak internal link structure supports a discovery review. Neither observation, by itself, tells you exactly when Google will crawl the page.
Use the checks in order. Start with public access and server health. Then review links, sitemap entries, and unnecessary URL variations. Finally, assess whether the page deserves its own result. This order helps prevent wasted work on pages that are inaccessible or do not need separate index entries.
For bulk status tracking, IndexNowFast offers a Google Index Checker. It can help organize status observations across many URLs. Treat those results as a record of reported status, not a diagnosis of why Google has not crawled a URL. Use Search Console and server evidence for the deeper investigation. For related troubleshooting resources, browse the IndexNowFast blog.
Follow a Seven-Day Review Plan
A seven-day review plan can keep the work focused and create a clear record of changes. It is an editorial schedule for your checks, not a promise that Google will crawl or index the page within seven days.
| Day | Task | Evidence to record |
|---|---|---|
| Day 1 | Inspect the URL in Search Console. | Status, inspection date, and available discovery details. |
| Day 2 | Check public access, response codes, redirects, robots rules, and noindex settings. | Current response and any confirmed access issue. |
| Day 3 | Review the sitemap and relevant internal links. | Sitemap entry and useful linking pages. |
| Day 4 | Check Crawl Stats and server logs if available. | Slow responses, HTTP 5xx errors, HTTP 429 responses, and relevant Googlebot visits. |
| Day 5 | Review URL variations, duplication, and page purpose. | Unnecessary URLs and useful differences between pages. |
| Day 6 | Apply confirmed fixes and request a crawl when appropriate. | Change made, deployment date, and request date. |
| Day 7 | Inspect the URL and compare the recorded evidence. | Current status and the next review decision. |
This schedule is useful because it separates investigation from action. It also prevents several unrelated changes from being made at once. If the evidence shows a server problem on Day 2, address it before spending time rewriting content on Day 5.
Some checks may take longer than a day. Server logs may not be available, and Search Console reports may not show every detail. Mark unavailable information as unknown. Do not turn missing evidence into a confirmed failure.
At the end of the review, decide whether the next step is another check, a focused repair, content consolidation, or continued monitoring. If Google has not crawled the page, that alone does not prove the work failed. Review whether the changes were useful and whether the URL still deserves a separate search result.
Request a Crawl Without Expecting a Guarantee
Request another crawl after a meaningful fix is live and the URL should be discovered. Do not use repeated requests as a substitute for checking server health, internal links, or URL inventory.
Google's guidance on requesting a recrawl explains how to use URL Inspection and sitemaps. Google notes that crawling can take days to weeks in relevant guidance, but this is not a guaranteed time to crawl or index a page. Repeated requests for the same URL do not make crawling happen faster.
For a small number of important URLs, use URL Inspection when appropriate. For a group of preferred URLs, keep the sitemap accurate. Make sure each address points to the intended destination and that the page can be fetched without an unintended block.
Google's official Indexing API documentation has a narrow scope. It is intended for pages with JobPosting structured data or BroadcastEvent embedded in VideoObject. It is not a general method for forcing Google to index standard articles, product pages, or backlinks.
IndexNowFast describes discovery and crawl-verification workflows on its official website. Such services may support submission, discovery, or status tracking, depending on their features. A verified crawl is not the same as final index inclusion. The site's commercial claims should not be treated as independently verified indexing rates.
For help with the next step, IndexNowFast also provides a guide to submitting a URL to Google. Follow the submission steps after checking the URL. A request can support the workflow, but Google's systems still decide when to crawl and whether to index a page.
Some site owners report that URLs remain discovered after sitemap submission or a successful live test. The Google Search Central Community discussion about discovered URLs that remain unindexed illustrates this concern. It is a user discussion, not proof of a universal cause or a reliable time-to-crawl estimate. Another Search Console Community discussion about discovered-but-not-indexed URLs offers additional context from users facing similar reports. Use these discussions to understand common questions, while relying on Google's official documentation and your own site data for decisions.
Keep the result in perspective. If Google later crawls the URL, check the new status and continue from that evidence. If the page remains discovered, revisit the checks that may affect discovery, demand, or crawl capacity. Do not promise a fixed recovery date.
Common Questions About Discovered – Currently Not Indexed
These questions cover the main decisions that arise when Google knows a URL exists but has not crawled it. They address crawl scheduling, site access, discovery paths, and the limits of indexing requests. Use the answers alongside the exact URL's Search Console report and server evidence. The status alone cannot identify a single root cause.
What does Discovered – currently not indexed mean?
It means Google knows the URL exists but has not crawled it yet, according to the Search Console report. The label does not reveal the exact reason for the delay. Check access, internal links, sitemap setup, and server health before making wider changes.
Is Discovered – currently not indexed a Google penalty?
The status alone does not establish a penalty or manual action. It describes a URL that Google has found but not yet crawled. Review the available Search Console evidence before drawing conclusions about a broader site problem.
How long can a URL remain discovered but not indexed?
There is no universal deadline. Google's guidance describes crawling as a process that may take days to weeks, depending on the situation. That guidance is not a promise that every URL will be crawled or indexed within that period.
Does a successful live test mean Google has crawled my page?
No. A live test checks the current URL under the tool's test conditions. It does not prove that Google's regular crawler has visited the page. Compare the live result with the stored report and review discovery paths.
Can an XML sitemap fix the status?
A sitemap helps Google discover URLs, but it cannot force crawling or indexing. Make sure the sitemap lists the intended canonical URLs and uses accurate last-modified dates. Add useful internal links where they help visitors find important pages.
Should I keep requesting indexing?
Request a crawl when a meaningful correction is live and the URL should be included. Google says repeated requests for the same URL do not make crawling faster. Use the time to check real problems and track changes instead.
Should I delete every page that remains discovered?
No. First decide whether the page serves a distinct purpose. Keep and improve useful pages that deserve their own result. Consider consolidation or deliberate exclusion for duplicate, unnecessary, or low-value URL variations.
Can a third-party indexing service guarantee inclusion in Google Search?
No. Submission and crawl-verification tools may help with discovery or tracking, but crawling and indexing are separate processes. No evidence in the reviewed sources supports a guarantee that a third-party service can force Google to include a URL.
Make the Next Change Evidence-Based
“Discovered – currently not indexed” identifies where progress has stopped, but it does not reveal the exact cause. Start with the URL's importance, public access, server health, sitemap, and internal links. Then review URL inventory and page purpose before deciding whether another crawl request makes sense.
If you confirm a technical problem, fix it and record the change. If discovery paths are weak, improve useful internal links and keep the sitemap accurate. If the URL adds little value or duplicates another page, consolidation may be the better choice. Continue to monitor the evidence without expecting a fixed crawl date.
The goal is not to make every URL appear in search. It is to help Google find the pages that deserve to be found, serve them reliably, and understand how they fit into the site.