Discovered - Currently Not Indexed: How to Fix It
"Discovered - currently not indexed" means Google knows the URL exists, usually from a link or the sitemap, but has not crawled it yet. Google rescheduled the visit because it expected crawling to overload the site. The fix is in what Google spends its visits on: duplicate URLs, internal links and how fast the server answers.
Requesting indexing works for a handful of URLs. When hundreds of pages wait, the cause is in the site, and that is the kind of problem I solve in Google indexing fixes.
What Google means by "Discovered"
The Page indexing report in Search Console describes the status this way: "The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl."
Two things decide how much of a site Google crawls: how much the server can take without slowing down, and how much Google wants the URLs it knows about. A slow or failing server lowers the first. Thousands of near-identical URLs, pages nobody links to and a large share of weak pages lower the second.
Discovered vs crawled - currently not indexed
| Status | Has Google visited the page? | What it tells you | Check first |
|---|---|---|---|
| Discovered - currently not indexed | No | The URL is waiting in the crawl queue | Crawl stats, server errors, duplicate URLs and internal links |
| Crawled - currently not indexed | Yes | Google read the page and did not keep it | The page itself: duplicate, thin or barely linked content |
When pages move from "Discovered" to "Crawled - currently not indexed", Google has visited them and the problem changes. That case has its own guide: how to fix "Crawled - currently not indexed".
Why Google finds a URL and does not crawl it
The server is slow or failing
When responses slow down or return server errors, Googlebot throttles its requests to avoid overloading the site, and pages wait.
Too many URLs compete for the same visits
Filters, sort orders, tracking parameters, calendars and internal search can turn a few hundred pages into thousands of addresses.
The page is only in the sitemap
A sitemap tells Google a page exists, not that it matters. A URL no indexed page links to looks unimportant.
The site is new or has few links
Google crawls a new domain cautiously. Links from your own indexed pages and from other sites raise its interest.
Most crawled pages were not indexed
If Google keeps visiting pages it then leaves out, it has less reason to fetch the rest. Fixing those often unblocks the queue.
A large batch went live at once
An import, a new section or a programmatic launch puts thousands of URLs in the queue on the same day.
How to find the cause in Search Console
- Open Crawl stats. It is under Settings. Host status shows problems with robots.txt fetching, DNS resolution and server connectivity.
- Read the responses. Most crawl requests should return 200. A visible share of server errors explains a slow queue on its own.
- Watch the average response time. If it climbs when Google crawls more, the server is the limit, not Google.
- Look at the example URLs, not only the count. Parameters and filters point to crawl waste; real pages with no internal links point to the site structure.
- Test a few URLs live. In URL Inspection, Test live URL confirms the page loads for Google and is not blocked.
How to fix "Discovered - currently not indexed"
- Separate the URLs that should never be crawled. Export the examples and set aside filter combinations, sort orders, tracking parameters, internal search results and session URLs. They do not need to be indexed, and most do not need to be crawled either.
- Stop generating them. Link to clean URLs only, remove crawlable links to filter combinations nobody searches for, and block crawl traps such as endless calendars in robots.txt.
- Fix the server. Bring server errors close to zero and keep responses fast. Caching full pages at a CDN usually does more than any other single change.
- Link to the pages that matter. Add links from the home page, menus, categories and related articles. Pages that only the sitemap mentions are the ones that wait the longest.
- Clean the sitemap. List only canonical, indexable URLs, with lastmod dates that change only when the page really changes, so the sitemap points Google at what is new.
- Improve or merge weak pages. If many pages that Google did crawl ended up not indexed, fix those first. A site whose crawled pages get indexed gives Google a reason to crawl more of it.
- Request indexing for a few key URLs. Use URL Inspection for the handful of pages that matter most. It works one URL at a time and does not change how the rest of the site is crawled.
- Track the count per template. Watch the number of discovered URLs for each type of page over the following weeks. It falls gradually as Google catches up, not overnight.
On online stores, most discovered URLs come from filters and variants, covered in ecommerce technical SEO. If the sitemap itself shows an error in Search Console, start with "Sitemap could not be read".
How long can a page stay "Discovered"?
There is no deadline. Google does not promise to crawl or index every URL it knows, so a page can stay in this state indefinitely if nothing changes. On small sites the wait usually ends when the page gets internal links and the site earns some trust; on large sites, when crawl waste is cut and the server keeps up.
When I launched this site in October 2026, every page was linked from the menu and listed in a sitemap generated from the code, and Google crawled and indexed them within a few days. When a small site stays in "Discovered" for weeks, I check the server and the internal links before anything else.
Notes by platform
Shopify
Many themes link to products through collection paths and tag filters. Linking to the main product URL gives Google fewer addresses for the same page.
WordPress
Tag, author, date and attachment archives add URLs that rarely deserve a visit. Most SEO plugins can drop them from the sitemap.
Wix and Squarespace
Crawl waste is rarely the cause on small sites. A new site with few links is; internal links and a few links from other sites help most.
Large and custom sites
Check server capacity when Google crawls most, and whether faceted navigation creates crawlable combinations without limit.
Questions about discovered pages
What does "Discovered - currently not indexed" mean?
It means Google found the URL, usually through a link or a sitemap, but has not crawled it yet. Search Console explains that Google wanted to crawl the page but expected the visit to overload the site, so it rescheduled the crawl. The page has not been judged yet; it is waiting in the queue.
Is "Discovered - currently not indexed" an error?
Not by itself. Every site has URLs in this state, and many of them, like filtered or parameter URLs, should never be indexed anyway. It matters when it holds back pages meant to rank, such as services, products or articles, or when the count keeps growing.
Should I request indexing for discovered pages?
For a few important pages, yes. URL Inspection lets you ask Google to crawl a specific URL. For hundreds of pages it does not scale, and the cause, whether crawl waste, weak internal links or a slow server, stays in place.
Does submitting a sitemap fix "Discovered - currently not indexed"?
No. A sitemap is often how Google discovered these URLs in the first place. It helps when it lists only canonical, indexable pages, but internal links and how fast the server answers decide how soon Google crawls them.
How is it different from "Crawled - currently not indexed"?
With "Discovered", Google has not visited the page. With "Crawled", it visited and chose not to index it. The first points to crawl capacity and links; the second points to the page itself, usually content that looks duplicated or adds little.
Pages stuck in "Discovered"?
Email the site and the number of URLs in the report. I reply with where Google's crawling is going and what would get the important pages crawled.
- Email: calebe.development@gmail.com
- WhatsApp: +55 11 98838-5247
- Who replies: Calebe Araujo, the developer who does the work
Page updated on .