How to Fix "Discovered – Currently Not Indexed" in Search Console

By the Mayab Media Team · Level: Intermediate · Time: 1–2 hours

In the Page indexing report you see Discovered - currently not indexed next to a growing number of URLs. When you inspect one, the Last crawl field is empty, which means Google knows the page exists, probably from your sitemap or a link, but it has never fetched it.

Google's help page explains the usual reason: it wanted to crawl the URL, but expected that doing so would overload the site, so it pushed the crawl back. On small sites, though, the cause is more often about priorities than server load. Google found the URL, compared it with everything else waiting in line, and decided it could wait.

So the fix splits into two questions: can your server handle more crawling? and are you giving Google a clear, short list of pages worth crawling, with links that show they matter? This guide covers how to check both and what to change.

Quick answer

1. Inspect a few affected URLs to confirm Last crawl is empty and nothing blocks them.
2. Open Settings > Crawl stats and check Host status and Average response time for server trouble.
3. Cut crawl waste: stop generating or linking to parameter, filter, tag and duplicate URLs.
4. Link important stuck pages from your homepage, menus and related, already-indexed pages.
5. Keep your sitemap clean (only indexable, canonical URLs with honest lastmod dates), request indexing for a few key pages, and wait two to four weeks.

Before you start

You need Owner or Full user access in Search Console. The Crawl stats report only works on root-level properties, meaning a Domain property or a URL-prefix property at the site root such as https://www.example.com/. If you only have a subfolder property, ask the owner to add you to the root.

Have access to your hosting dashboard or server logs, and to your CMS and SEO plugin. Your developer or host will need to be involved if the problem turns out to be server speed or errors. Before changing robots.txt or removing URLs, save a copy of the current robots.txt file and your sitemap.

Step 1: Check how big the problem is

Go to Indexing > Pages and click Discovered - currently not indexed in the Why pages aren't indexed table. Look at how many URLs are affected. Then look at which ones.

Figure 1. A steadily rising line usually means Google keeps finding new URLs faster than it wants to crawl them. Illustrative numbers. Illustration of the screen. Labels can differ slightly in your account.

1. The Source is Google: nothing is broken on your end in a strict sense, Google chose to wait.
2. A climbing trend points to a site that's producing many new URLs, often by accident.

Export the list and sort by URL path. Two very different situations tend to show up.

• A handful of new pages, like last week's blog posts. This is often just a queue, and it resolves on its own within days or weeks.
• Hundreds or thousands of similar URLs with parameters (?color=, ?sort=, ?sessionid=), filter combinations, calendar pages or tag archives. That's crawl waste. It's the main thing to fix.

Step 2: Inspect a sample of URLs

Paste three to five affected URLs into URL inspection. Pick both important pages and junk-looking ones so you can compare how Google found each.

Figure 2. The referring page tells you where Google found the URL. Here it's a filter link on a category page. Illustration of the screen. Labels can differ slightly in your account.

1. Referring page shows how Google discovered the URL, which is often the clue to the source of crawl waste.
2. Test live URL confirms the page is reachable and indexable right now.

Run Test live URL on the important ones. If the live test fails because robots.txt blocks the URL, or the server returns an error, fix that first. If the live test passes and the URL simply hasn't been crawled yet, move on to the server checks.

Step 3: Check server health in Crawl stats

Click the gear icon (Settings) at the bottom of the left menu, then open the Crawl stats report. This shows how Googlebot has been crawling your site over the last 90 days.

Figure 3. Slow responses and host problems tell Google to back off. Illustrative numbers. Illustration of the screen. Labels can differ slightly in your account.

1. Watch Average response time. A rising line means Google is waiting longer for each page.
2. Host status flags problems with robots.txt fetching, DNS resolution or server connectivity.

Here's how to read the report and what each warning means for you.

• Host status shows problems. Click into it, because failures in robots.txt fetching, DNS resolution or Server connectivity cause Google to slow down or pause crawling. Share the affected dates with your host so they can match them to their logs.
• Response time is high or climbing. Google crawls less when pages respond slowly. Slow database queries, an overloaded shared host or a missing page cache are the usual causes. Caching and a better hosting plan often help more than any SEO change.
• Many 5xx or 429 responses under By response. These directly reduce how much Google is willing to crawl. Find out what's failing, whether it's a plugin, a firewall rule or rate limiting, and fix it.
• A large share of crawls go to redirects or 404s. Google is spending time on dead ends, so update internal links so they point straight at the final URL.

Check that your firewall, CDN or security plugin isn't rate-limiting or challenging Googlebot. Bot protection settings sometimes treat Google's crawler like an attacker, and verified Googlebot traffic should get normal responses.

If Host status is clean and response times are steady, server capacity probably isn't your issue. Focus on the next two steps.

Step 4: Cut the URLs Google doesn't need

Every unnecessary URL Google knows about competes with your real pages for attention. Google's crawl budget guide puts managing your URL inventory at the top of the list of things you control. Small sites don't usually hit crawl limits, but a store with filter links can generate thousands of URLs from a few dozen products.

Work through the patterns you found in Step 1.

Source of extra URLs	Fix
Faceted filters and sort options	Don't output crawlable links for every combination; use canonical tags to the main category; block pure sort parameters in robots.txt if needed
Session IDs or tracking parameters in internal links	Remove them from internal links; keep UTM tags off internal navigation
Endless calendar or date archives	Limit the range, or noindex and stop linking far-future pages
Tag archives with one post each	Merge tags, or noindex and drop them from the sitemap
Duplicate http/https or www/non-www versions	301-redirect to one version everywhere
Internal search result pages	Don't link to them; disallow /search or /?s= in robots.txt
Soft 404s and thin empty pages	Return a real 404, or add content

A note on robots.txt. Google's guide suggests robots.txt for URLs you never want crawled, such as endless sort variants, because noindex still costs a crawl. But blocking also hides any canonical or noindex on those pages. Only block URL patterns that have no value at all, and never block pages you want indexed. Our robots.txt and noindex guide explains the trade-off. This example stops crawling of sort and session parameters only:

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

Sitemap: https://www.example.com/sitemap.xml

Test before you trust it. Check any new rule against a few important URLs with URL inspection before you rely on it. A misplaced wildcard can block a whole section.

Step 5: Make important pages easy to reach

Google decides what to crawl partly by how important a URL seems. Orphans suffer most. Pages that appear only in a sitemap, with no internal links, look unimportant.

For each important page stuck in this status:

• Link it from the homepage, main navigation or a category or hub page.
• Add two or three contextual links from related pages that are already indexed.
• Keep it within a few clicks of the homepage. Deep pagination (page 14 of the blog) is a weak path.
• Use normal <a href> links. Links that only work through JavaScript click handlers may not be followed.

<!-- Crawlable -->
<a href="/guides/roof-maintenance/">Roof maintenance guide</a>

<!-- Risky: no href for Google to follow -->
<span onclick="go('/guides/roof-maintenance/')">Roof maintenance guide</span>

External links help too, since a mention from a relevant site tells Google a page is worth fetching.

Step 6: Clean up your sitemap and request indexing

Open Indexing > Sitemaps and check your submitted sitemap. It should list only URLs that return 200, are indexable and are their own canonical. Remove redirects, 404s, noindex pages and parameter URLs. A sitemap full of junk dilutes the signal.

Figure 4. Compare each sitemap's page count with the number of pages you actually want indexed. Illustration of the screen. Labels can differ slightly in your account.

1. If a child sitemap lists far more URLs than you have real pages, it's probably full of variants or parameters.
2. This link opens the Page indexing report filtered to the URLs in that sitemap, so you can see how many are stuck.

Use lastmod honestly and update it only when the page content really changes. Google uses it to decide what to recrawl, and dates that change on every build teach it to ignore them.

<url>
  <loc>https://www.example.com/guides/roof-maintenance/</loc>
  <lastmod>2026-10-30</lastmod>
</url>

Then inspect your five to ten most important stuck URLs and click Request indexing on each. That's enough, because the daily quota is small, and requesting the same URL repeatedly won't move it up the queue.

Still not working? Common causes

Symptom	Likely cause	Fix
Count jumps by thousands overnight	A new filter, calendar or parameter is spawning URLs	Find the pattern in the export; remove the links or canonicalize
New blog posts sit here for weeks	Few internal links; site posts more than Google wants to crawl	Link new posts from the homepage and related posts; publish fewer, stronger pages
Crawl stats show many 5xx errors	Server overload, plugin errors, hosting limits	Fix errors, add caching, upgrade hosting
Crawl stats show 429 responses	Firewall, CDN or WAF rate-limits Googlebot	Allow verified Googlebot in your bot rules
Response time over a second or two	Slow server, no page caching, heavy database queries	Add page caching and a CDN; optimize the slowest templates
URLs appear only in the sitemap	Orphan pages	Link them from navigation or related pages
Product variants all stuck	Each variant has its own URL with near-identical content	Canonicalize variants to the main product URL
Status turns into Crawled - currently not indexed	Google crawled, then decided not to index	See Fix "Crawled – currently not indexed"
Pages stuck after a migration	Old and new URLs both live, redirect chains	Single-hop 301 redirects; update internal links and sitemaps

Large sites and crawl budget

Google's crawl budget guide is aimed at very large sites (roughly a million or more pages, or tens of thousands that change daily) and at sites where a large share of URLs sit in this exact status. If that's you, read it in full. The same steps apply at bigger scale: server capacity first, then URL inventory, then internal linking. Return 404 or 410 for removed pages rather than leaving them blocked, since blocked URLs stay in the crawl queue longer.

It's normal for a new page to wait

A new page in this status for a few days isn't a problem. Google crawls on its own schedule, so only start investigating if pages stay here for several weeks or the count keeps growing.

How to confirm it's fixed

1. Re-inspect key URLs after one to two weeks. You want a Last crawl date to appear. After that, the status should change to indexed, or to Crawled - currently not indexed if Google crawled but passed on the page.
2. Check Crawl stats again. Response times should be steadier and Host status clean. Total crawl requests often rise once the server responds faster.
3. Watch the Discovered trend in Indexing > Pages. It should flatten, then fall as junk URLs drop out and good ones get crawled.
4. Click Validate fix on the reason once your changes are live. Validation usually takes up to about two weeks but can take longer.
5. Check Performance for impressions on the newly indexed pages.

Give it two to four weeks for small sites. Crawling changes take time to show up in the report, and parameter URLs can linger in the list long after you've stopped linking to them.

FAQ

Is "Discovered – currently not indexed" bad?

Not on its own. A few recent URLs in this status is normal. It becomes a problem when important pages stay here for weeks, or the count keeps climbing.

Does submitting my sitemap again help?

No. Google rereads sitemaps on its own, and resubmitting doesn't raise priority. Fixing what's in the sitemap does more.

Should I block these URLs in robots.txt?

Only if they have no value and you never want them crawled, like endless sort variants. Never block pages you want indexed, and remember blocking hides your canonical and noindex tags.

Will faster hosting fix it?

Sometimes. If Crawl stats shows slow responses or server errors, it often helps a lot. If the server is already fast, the problem is more likely URL waste or weak links.

How many pages can I request indexing for per day?

Google doesn't publish an exact number, only that there is a daily limit per property. Use it for your most important pages and let the sitemap handle the rest.

Stuck on this one? We fix these for clients every week. Book a free audit

Sources

• support.google.com: /webmasters/answer/7440203
• developers.google.com: /search/docs/crawling-indexing/large-site-managing-crawl-budget
• support.google.com: /webmasters/answer/9679690
• developers.google.com: /search/docs/crawling-indexing/ask-google-to-recrawl
• ahrefs.com: /blog/discovered-currently-not-indexed/