YouTube video

Marketing consent is needed to play this video

YouTube won’t load until you allow marketing cookies. You can review your choice without leaving this page.

The quickest way to check ‘Discovered – currently not indexed’ is to look for a pattern before changing the page. One new page may only need time. Hundreds of pages from the same section may point to weak links, too many unwanted URLs or a server that limits Google’s visits.

That difference matters because Google hasn’t crawled the reported URL yet. A rewrite or another indexing request may add work without fixing the delay.

What does ‘Discovered – currently not indexed’ mean?

‘Discovered – currently not indexed’ means Google knows that a URL exists but hadn’t crawled it when Google Search Console last recorded the status. A URL must normally be crawled before Google can decide whether to index it and make it eligible to appear in search results.

Google may discover a page through a link or an XML sitemap, which is a file listing URLs that a site considers important. Google’s Page indexing report guidance describes this status as a URL that Google found but hasn’t yet crawled.

The message doesn’t name one cause. It also doesn’t promise that Google will index the URL after a visit. The useful question is whether the wait is normal or part of a wider pattern.

If Search Console says ‘Crawled – currently not indexed’ instead, Google has already fetched the page. Use the separate guide to fix ‘Crawled – currently not indexed’ because the most useful checks then move from crawl access towards index eligibility, duplication and page value.

Should you fix the status straight away?

You don’t always need to fix ‘Discovered – currently not indexed’ straight away. A new page can take time to move from discovery to crawling. A sitemap or indexing request can’t set the date when Google will act.

Before making a change, answer three questions:

  1. Is the affected URL important enough to appear in search as its own result?
  2. Is the URL new or has the same status persisted across several checks?
  3. Is this one page or a repeatable pattern across a template, folder or large part of the site?

A new service page that has waited for a few days is different from 20,000 filtered product URLs that have built up for months. The first may need a clear link and time. The second needs a site-wide check before anyone tries to submit each URL.

Use this six-step check

Work from the smallest reliable facts towards the wider technical causes. Stop when the evidence gives you a clear next action.

Four URL patterns lead to waiting, stronger discovery, less URL waste or a server capacity check

Step 1: confirm the current status and choose a useful sample

Open URL Inspection in Google Search Console and check a key example. The indexed result shows what Google knows about the saved version. A live test checks whether Google can reach the page now. Google’s URL Inspection guidance warns that a good live test doesn’t promise indexing or repeat every check used for the indexed result.

If many URLs are affected, don’t rely on one example. Choose a small sample from each meaningful group, such as:

  • New service or location pages.
  • Products from the same category or template.
  • Blog posts published in the same period.
  • Filtered, sorted or tracking URLs.
  • URLs that Search Console has reported for several weeks.

Record the URL, page type, source if shown, sitemap status and the date checked. This turns a large report into groups you can compare.

Step 2: decide which URLs belong in Google

An excluded URL is only a business problem when the page should help the right visitor. A product, service, location or useful guide with its own purpose may deserve a search result. A tracking URL, empty filter or near-copy may not.

What the URL does Likely decision
Answers a distinct search need and supports a real business purpose. Keep it available for crawling and strengthen its discovery signals.
Repeats another page with a sorting or tracking parameter. Merge the duplicate and stop treating it as a key page.
Creates an empty or near-empty filtered page. Stop the site making the URL where you can do so safely.
Exists only for a signed-in or internal journey. Keep it out of search deliberately.
Has no clear purpose beyond increasing the page count. Review whether the page should exist before asking Google to crawl it.

This choice narrows the work. The aim isn’t to make every known URL indexed. It’s to help Google reach the URLs that matter without a much larger set of unwanted versions around them.

Step 3: make important pages easy to discover

Google explains in its guide to how Search works that it often finds pages through links and sitemaps. Check whether each key example has:

  • A normal HTML link from a relevant page that Google already visits.
  • A place in the site’s menu or a useful category or topic hub where it belongs.
  • The preferred URL in the XML sitemap rather than a redirect or duplicate version.
  • A working response at the final URL without a chain of redirects.
  • The same preferred URL in links and sitemap entries.

A page that only appears in a sitemap can still be found, but that doesn’t make it important. A clear link gives Google context and helps visitors reach the page too.

Use links that make sense for the site rather than adding large sitewide blocks. For example, a new boiler-repair service page might belong in the main services section and in one relevant guide. It doesn’t need a link from every page on the website.

Step 4: inspect the URL inventory around the page

The reported URL may be sound while the site makes far more addresses than useful pages. Filters, calendars, site search, tracking parameters and repeated choices can give Google a vast list to check.

Compare the group with URLs found in a site crawl or Search Console export. Look for:

  • Repeated parameters that change the address without changing the useful content.
  • Filter choices with no products or useful result.
  • Multiple routes to the same page.
  • Old sitemaps that still list redirects or removed URLs.
  • Calendars or page lists that never end.
  • Development or preview addresses linked from the live site.

Google’s crawl-budget guidance says the number of known URLs can affect crawl demand. Duplicate or low-value URLs can waste visits. Remove the source of unwanted URLs, merge duplicates and keep sitemaps focused on preferred pages. Bear in mind, though, that blocking a long list without first finding how the site made it can mask the problem while the waste goes on.

Step 5: check whether the server is limiting crawling

Server checks matter more when Google hasn’t crawled many useful pages, the group keeps growing or logs show that Google visits less often than expected.

Ask the person who manages the website or hosting to check the server logs, which record visits to the site. Look for:

  • Whether Googlebot, Google’s web crawler, receives 429 responses, which mean too many requests.
  • Whether 5xx server errors occur during Googlebot visits.
  • Whether pages slow down when traffic rises.
  • Whether a firewall or content delivery network, which sits between visitors and the host, challenges or blocks verified Googlebot requests.
  • Whether a recent deployment or migration changed response times or availability.

Google says it may crawl less when a site is slow or returns server errors. One delayed page on a small site doesn’t prove a crawl limit. Check logs and hosting only when the wider pattern points there.

If the issue began after a move or platform change, use the site migration monitoring sequence to check access, redirects and indexing in the order Google encounters them.

Step 6: change one supported cause and monitor the group

Choose the smallest change that fits what you found. Record the date, then check the same sample after Google has had time to return.

What you find What to do next
One useful page is new and linked normally. Wait and check again rather than changing several things.
Key pages have no links from known sections. Add useful links from a hub or related page and keep the preferred URLs in the sitemap.
The sitemap lists redirects or duplicate versions. Replace them with final preferred URLs.
Filters or parameters create large numbers of weak URLs. Fix how the site makes and links to them before asking Google to crawl more.
Googlebot receives repeated 429 or 5xx responses. Check server limits, caching and blocks with technical help.
Key clean URLs remain affected after the cause is fixed. Request indexing for a few sample URLs and watch the whole group.

Google calls a sitemap a hint rather than a promise in its sitemap guidance. Treat an indexing request in the same way. It can invite another check, but it can’t force a crawl or an indexed result.

What searchDecoded has seen in practice

searchDecoded has seen ‘Discovered – currently not indexed’ across websites operating in several business sectors, and more often than its reputation as a harmless warning might suggest. The most common affected patterns searchDecoded has encountered have been thin pages, faceted navigation that adds little or nothing new and query-parameter URLs created for tracking or similar purposes. In those cases, even a brief scan of the affected URLs in Google Search Console often made the common pattern clear.

That observation doesn’t prove that thin content caused Google to delay the first crawl of each URL, but it does show why the affected group matters more than one isolated example. A repeated folder, filter or parameter pattern gives you a stronger place to begin than a theory about one page.

searchDecoded has also seen waiting work for genuinely new pages and after a site migration, when Google needed time to reassess the website. Where a useful page lacked enough context, adding high-quality content sometimes came before progress. On category pages, more helpful static copy made the relationship between the category and its listed child items clearer. However, the timing doesn’t prove that the copy alone caused Google to crawl or index those pages, so searchDecoded would still make one supported change and monitor a fixed sample.

searchDecoded wouldn’t ignore the report simply because one delayed URL can be harmless. Assess the pattern early enough to see whether the affected set is stable or growing. If it is only a new, useful page with sound discovery signals, that assessment may still show that waiting is the right choice.

Does ‘Discovered – currently not indexed’ mean a crawl-budget problem?

‘Discovered – currently not indexed’ doesn’t always mean a crawl-budget problem. Google aims its crawl-budget guide mainly at three types of site. These are sites with about one million pages that change often, sites with more than about 10,000 pages that change each day and sites where a large share of URLs stay in the discovered state.

Small sites can still have crawl access, server or page-list problems. However, calling one delayed page a ‘crawl budget’ issue can send the work towards server tuning when the cause is a new page with weak links.

Let the size and pattern guide the next check. Start with links and page purpose on a small site. Move to logs, response codes and site-wide crawl demand when the issue affects many useful URLs or a large section that changes fast.

Should you rewrite the content before Google crawls it?

Rewriting the page isn’t the first fix when Google hasn’t crawled the URL. This status doesn’t show that Google read the copy and turned it down. The reported stage comes before that choice.

Content still matters to the wider site. Clear, useful pages are easier to link from the right hubs. Large groups of thin or repeated pages can give Google a poor list to work through. Improve a page when it lacks its own purpose or a useful answer, but remember that a rewrite may not end the crawl delay.

Once Google has fetched the URL, the status may change to indexed or to another exclusion reason. If it changes to ‘Crawled – currently not indexed’, continue with the post-crawl diagnosis rather than repeating the discovery checks.

When should you ask for technical help?

Diagnosing this problem sits firmly within a technical SEO specialist’s remit. They can bring in a web developer or hosting provider when the evidence points to URL generation, server responses or firewall rules, although many cases won’t need that extra hand-off.

If you manage the website yourself, ask for technical help when you’ve tried the relevant checks and important pages remain affected, you don’t know how to run the checks safely or you can’t give the investigation the time it needs. This isn’t a quick fix with one answer for every site. Help is also a sound next step when:

  • A template makes thousands of filter or parameter URLs.
  • Important pages are only reachable after scripts run.
  • Redirects and preferred URL signs don’t match across a section.
  • Googlebot receives repeated server errors or rate limits.
  • A firewall may be blocking verified crawlers.
  • A site move or code release changed crawling across the site.
  • You need server logs to separate crawler activity from assumptions.

Give the specialist sample URLs from each group, the dates checked, sitemap proof, response codes and the site’s change log. This lets them test one cause at a time instead of starting with a broad site audit.

If Google receives an incomplete page once it does crawl, the rendering audit method can help separate access, HTML, scripts and visible content.

What can these checks prove?

These checks can show whether key pages are linked and listed in the same way. They can also show whether unwanted URLs fill the group or the server returns errors to Googlebot. The same result across one template or section is more useful than one URL checked once.

The checks can’t reveal Google’s full schedule or promise when it will crawl a URL. A page moving after a change doesn’t prove that the change was the only cause. Google may also have returned as part of its normal work.

Record the first sample, the change and the next check date. That short record is what separates a useful test from a guess.

Start with the pattern that Search Console reveals

To fix ‘Discovered – currently not indexed’, first separate a normal wait from a group problem that lasts. Check that the URLs deserve to appear in search, add useful paths to them, cut unwanted copies and only check server limits when the pattern points there.

Request indexing once after a supported change, then monitor the same group. If Google crawls the page but doesn’t index it, move to the separate post-crawl checks rather than repeating the work.