Discovered, Currently Not Indexed: How to Fix It

What the status means

Search Console lists this reason as Discovered - currently not indexed. Google describes it as a page that was found but not crawled yet, and adds that Google usually wanted to crawl the URL but expected this to overload the site, so it rescheduled the crawl. That is why the last crawl field is empty for these URLs.

It helps to picture how Google works. It keeps a queue of URLs it knows about for your site. Each day it decides how many to fetch, based on two things:

• How much your server can take. If responses are slow, or the server returns 5xx errors or 429 Too Many Requests, Google crawls less to avoid harming the site.
• How much Google wants the URLs. Popular, well-linked, frequently updated pages are fetched first. URLs known only from a sitemap, or that look like endless variations of the same page, wait.

Pages in this status are at the back of that queue. Unlike crawled, currently not indexed, Google has not looked at the content yet, so the quality of the page is not the main factor. The fix is about making crawling easier and the important URLs more obviously important.

The usual causes

Shops with filter navigation are the most common case by a wide margin. Each filter combination creates a new URL, and four filters with ten values each can produce many thousands of addresses for a category of fifty products. The faceted navigation guide and the crawler traps guide cover these patterns in depth.

How to diagnose it

Read the Crawl stats report

In Search Console open Settings, then Crawl stats. Look at three things:

• Total crawl requests over the last 90 days. A sudden fall often follows a spell of server errors.
• Average response time. A line that climbs while requests fall is the classic sign Google is backing off. Aim to keep HTML responses to a few hundred milliseconds.
• Host status. Problems with robots.txt fetching, DNS or server connectivity in the last 90 days are shown here, and any of them can slow crawling across the whole site.

The breakdown by response lets you see what share of requests returned 200, 301, 404 or 5xx. A large share of redirects or 404s means Google is spending its visits on addresses that lead nowhere useful.

Check your server logs

Your access logs show exactly what Googlebot asked for. On a typical nginx or Apache server using the combined log format, this counts Googlebot requests by status code:

grep "Googlebot" /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -rn

And this shows which URL patterns take most of its attention:

grep "Googlebot" /var/log/nginx/access.log | awk '{print $7}' | sed 's/?.*//' | sort | uniq -c | sort -rn | head -20

On Plesk, per-domain logs live in /var/www/vhosts/example.com/logs/. If most Googlebot hits go to filter URLs, feeds or old redirects while your new product pages get none, you have found the problem. Confirm hits are genuine with a reverse DNS lookup such as host 66.249.66.1, which should return a googlebot.com name.

Compare the sitemap with a crawl

Crawl the site from the home page and compare the result with the URLs in your sitemap. Sitemap URLs that the crawl never reached have no internal links. Our robots and sitemap checker also reports sitemap entries that redirect, return errors or carry noindex.

The key changes

Make the server fast and stable

Fix 5xx errors and slow responses before anything else. Turn on full-page caching, fix slow database queries, and make sure your host is not rate-limiting Googlebot. Some security plugins and firewalls return 429 or 403 to bots under load, which looks to Google like an overloaded site. The response time guide and the server error (5xx) guide cover the server side.

Stop generating needless URLs

For filter and sort parameters that never deserve to rank, block crawling in robots.txt. Google supports the * wildcard in paths:

User-agent: *
Disallow: /*?*sort=
Disallow: /*?*size=
Disallow: /*?*sessionid=
Disallow: /calendar/

Test the rules against real URLs before you deploy them so you do not block whole categories by mistake. Filters that match real searches, such as a red dresses page, are better turned into proper, linked category pages with clean URLs.

Clean the sitemap

List only canonical URLs that return 200 and are indexable. Use accurate lastmod dates, because Google uses them when they are consistently reliable. A sitemap file can hold up to 50,000 URLs or 50 MB uncompressed; split larger sets with a sitemap index.

<url>
  <loc>https://example.com/products/trail-boot/</loc>
  <lastmod>2026-10-12</lastmod>
</url>

Link the pages that matter

Add links from the home page, category hubs and related posts to the URLs you want crawled. A product that appears in a category page, a related products block and a buying guide is a far stronger candidate than one listed only in the sitemap. The deep pages guide shows how to bring important pages closer to the home page.

A worked example

An online clothing shop with 1,800 products adds colour and size filters. Each combination creates a crawlable link such as /dresses?colour=red&size=12. Within a month Search Console shows 40,000 URLs as discovered but not indexed, and new products wait three weeks or more to be crawled.

The server logs show 70 percent of Googlebot requests going to filter URLs. The fix has three parts. The size and sort parameters are blocked in robots.txt with Disallow: /*?*size= and Disallow: /*?*sort=. The four colour filters with real search demand become static category pages such as /dresses/red/, linked from the menu. The sitemap is rebuilt to hold only products, categories and those new colour pages.

Over the next six weeks the share of Googlebot requests going to products rises, new products are crawled within days, and the discovered count falls steadily as Google drops the blocked patterns from its queue.

The fix, step by step

Edge cases worth knowing

• Robots.txt and noindex do not mix. If you block a URL in robots.txt, Google cannot see a noindex on it. Blocked URLs can still be indexed without content if other sites link to them. See noindex and disallow conflicts.
• Blocking does not remove URLs from the report at once. Known URLs fade out of the queue over weeks.
• A crawl rate setting no longer exists. Google retired the crawl rate limiter in Search Console. If you need Google to slow down urgently, returning 503 or 429 for a short time works, but leaving it in place for days harms crawling.
• Migrations cause a temporary spike as Google discovers every new URL at once. That is normal if redirects are in place.
• Nofollow on internal links is a hint, not a block, and Google may still crawl those URLs.

Keeping it fixed

Watch the direction of the count, not its size on one day. A falling or flat line means crawling is keeping up. A line that keeps rising means URLs are being created faster than they earn crawling, and you should look for the pattern behind them.

Check Crawl stats monthly for response time and host status, and keep an eye on any new feature that creates URLs: filters, search pages, calendars, tags, or tracking parameters on internal links. Regenerate the sitemap automatically so it never includes redirects or deleted pages. The crawl budget guide has a fuller checklist for larger sites.