Crawled vs Discovered Currently Not Indexed: What Each Means and How to Fix It

Two rows in the Page indexing report look like the same problem with a different first word. They are not the same problem. One says Google has not spent a fetch on your URL. The other says Google fetched it, read it and passed.

“Discovered – currently not indexed” means Google waited. “Crawled – currently not indexed” means Google declined. The first is about crawl demand and crawl capacity. The second is about quality and duplication. The fixes barely overlap.

If you want the tour of every row, start with the report-wide guide to the Page indexing report. This post is the deep dive on these two rows only. Each label gets 320 US searches a month (DataForSEO, US, October 2026), and forum threads outrank the guides for both.

Two statuses, two different verdicts

Think of indexation as two gates. At the first, Google decides whether a URL is worth fetching. At the second, it decides whether what it fetched is worth keeping. Each status tells you which gate your URL stopped at.

The fastest way to tell them apart on a single URL is the last crawl date in URL Inspection. Empty means Discovered. A real date means Crawled. Google's help page says the same thing in fewer words.

A note on where the timing rows come from. Google ran its Search Central Live Deep Dive in Barcelona from 30 September to 2 October 2026 and published no official recap. I was not there. Everything I cite from it is attendee-reported, mainly John Campbell's daily recaps for ROAST.

Why Google has not crawled it yet: demand and capacity

According to Campbell's Day 1 recap, Cherry Prommawin described crawl budget as two parts, and a Discovered URL is stuck on one of them.

• Crawl rate limit, also called hostload. How much fetching your host can take. It is reported as shared across all of Google's crawlers, so Ads and Images draw on the same allowance as Search. It is driven by connection time, time to first byte, and 429 or 5xx responses.
• Crawl demand. How much Google wants your URLs. It is reported as driven by three things: site quality, how often URLs change, and how popular they are on the web.

Google's help page for the status leans on the capacity half. It says that typically Google wanted to crawl the URL but expected the fetch to overload the site, which is why the last crawl date is empty.

Capacity is the easy half to rule out. Open the Crawl stats report and look at response time and the error share. If the server is quick and clean, you are looking at demand, and a WAF handing Googlebot 429s is not your problem.

The parent path problem: how a weak directory taxes new URLs

One line in the Day 1 recap changed how I read this status. When Google does not know the quality or popularity of a URL, Campbell reports, it uses the aggregate for the URL's parent path. If that tells it nothing, it uses that path's parent, and so on up.

A brand new URL has no history by definition. So the crawl decision gets made on the reputation of its neighbours. Here is an illustration with a made-up site. It is not data, and the outcomes are my reading of the reported mechanism.

• /guides/new-guide/ sits under /guides/, a section of original pages that are linked from the nav and updated often. It borrows a strong aggregate and is likely fetched soon.
• /tag/new-tag/ sits under /tag/, hundreds of near-identical listing pages with few links in. It borrows a weak aggregate and is likely to sit in Discovered.
• /blog/page/47/ sits under /blog/page/, deep pagination nobody links to or lands on. Same weak inheritance, same likely result.

The practical consequence is uncomfortable. A weak directory is not only a set of pages that fail on their own. If the reported mechanism holds, it also taxes every new URL you publish under it, including the good ones.

It also gives you a test. Export the Discovered URLs and group them by folder. If most of them share one path prefix, the prefix is the finding, not the individual URLs.

Why Google crawled the page and declined

A Crawled URL cleared the first gate. Google spent the fetch, so demand and capacity are no longer the question. What it found is. The Day 2 sessions in Barcelona, as Campbell reports them, give four concrete ways a fetched page comes up short.

• Main content carries the weight. Gary Illyes is reported as saying main-body content counts for more, while navigation, footers and boilerplate count for less. A page that is mostly template has little left to judge.
• Soft 404s. Pages that return 200 OK but look like errors or are empty. The reported causes were thin content, server or CMS errors, and JavaScript problems. Day 1 added a newer one: a CAPTCHA challenge page served with a 200.
• The rendering viewport does not scroll. Erin Sparling is reported as saying Google loads pages in a viewport about 10,000 pixels tall and does not scroll or click. Content that waits for a scroll event is never seen.
• robots.txt blocking JavaScript. In a lightning talk, Rebecca Yu named this the top rendering problem. If the scripts are disallowed, Google cannot build the page, even though it looks fine to visitors.

The last one has a wrinkle. Scripts loaded from another host follow that host's robots.txt, not yours, so your own file can look clean while the page still fails to render.

Duplication is the other route. John Mueller is reported as describing how Google clusters similar pages, picks one canonical, and consolidates signals onto it. A page that loses that contest often shows a duplicate status instead, and canonical changes take weeks to register.

Discovered – currently not indexed: diagnosis and fixes

Work from the cheapest check to the most expensive. The flow below covers both statuses. The lists under it give the detail.

Diagnose in this order:

1. Confirm the status on a live URL. Inspect three or four URLs and check the last crawl date is empty. The report can lag behind reality.
2. Rule out capacity. In Crawl stats, look for rising response time, 429s and 5xx. If you find them, stop here and fix the server, WAF or CDN.
3. Check for inbound links. Does any indexed page link to the URL? A URL that exists only in the sitemap has given Google no popularity signal at all.
4. Group the URLs by directory. Look at what the siblings are. Thin or near-identical siblings point to a weak parent path.

Then fix what you found:

• Capacity: make the server faster and stop serving errors to Googlebot. Campbell's own note from the session reads “You can buy crawl budget, get a better and faster server”. He recorded it without further context.
• Links: add internal links from pages that already earn crawls and clicks. Orphan pages are the extreme case.
• Weak parent path: prune, merge or improve the directory. If the new page is good and its folder is not, publish it under a stronger one.
• Infinite URL spaces: calendars and parameter combinations were named in the session as crawl budget waste. Close them off.

Crawled – currently not indexed: diagnosis and fixes

Here the question is what Google received, so start with the rendered page and only then judge the writing.

Diagnose in this order:

1. Read the rendered HTML. Run a live test in URL Inspection and search the rendered HTML for a sentence from your main content. If it is missing, you have a rendering gap.
2. Check robots.txt for blocked scripts. Include every host the page loads scripts from, not only your own.
3. Check the status code against the content. A 200 on an empty template, an error message or a challenge page is a soft 404 in the making.
4. Strip the template in your head. Ignore the header, footer and sidebar. Is what remains unique on your site and useful on its own?

The free page indexability checker covers the plain blockers for a single URL in one pass: noindex tags, X-Robots-Tag headers, robots.txt blocks, canonicals pointing elsewhere, redirects and thin content.

Then fix what you found:

• Rendering gap: unblock the scripts, and render the main content without waiting for a scroll or a click.
• Soft 404: return a 404 or 410 for pages that are gone, and fix whatever makes real pages render empty.
• Thin or duplicate: rewrite the page so it says something the others do not, or merge several thin pages into one.
• Not worth indexing: leave it. Some URLs belong in this row, and a tag archive nobody searches for is one of them.

My honest reading of the soft 404 material: it has its own row in the report, but milder versions of the same causes are a plausible explanation for many Crawled URLs. That is an inference from the recaps, not something Google said.

When to stop waiting

Both labels end in “currently”, and both can clear with no action from you. The useful question is how long is normal. The best public yardstick is the set of timing tables Gary Illyes presented on Day 3, which I cover in full in the indexing timeline post.

Treat these with care. They are typical and slowest times as reported by Campbell and reproduced by Search Engine Roundtable. Illyes told Barry Schwartz the slides were “an exercise to see if the audience can relate to the numbers we pulled internally”. They are not service levels.

With that caveat, here are the thresholds I use. They are my rules of thumb built on the reported figures, not Google's.

• Discovered, under two weeks: wait. That is inside the reported slowest case for sitemap processing alone.
• Discovered, past two weeks: stop treating it as a queue. Run the diagnosis. Past a month, assume a demand problem.
• Crawled, under a week: wait. Rendering can sit in a queue for days at the slow end.
• Crawled, past four weeks: treat it as a decision. Typical indexing is reported in hours, so a month is not a backlog.

What does not work

Both of the reflex responses are a way of asking the same question louder. Neither changes the answer.

• Repeated Request Indexing. On a Crawled URL, fetching was never the problem. Google's help page says there is “no need to resubmit this URL for crawling”. On a Discovered URL it can force one fetch, which often just moves the URL into Crawled.
• Resubmitting the sitemap. A Discovered URL is already known. The reported slowest case for sitemap processing is “never (quality)”, which tells you a sitemap is a hint and not a lever on demand.
• Tuning the server for a Crawled URL. Speed helps capacity. A page that was already fetched and declined does not have a capacity problem.
• Fixing URLs one at a time. Both verdicts are usually about a group. Fix the template or the directory and the group moves together.

Request Indexing does have one honest use: once, after you have materially changed a page, to shorten the wait for the recrawl.

How to check both statuses at scale

The report shows a sample of example URLs per status, and clicking through them one by one does not scale. The URL Inspection API does better. A poster at the event, as Campbell reports it, put the limit at 2,000 inspections per site per day.

Google's usage limits page confirms the figure: 2,000 queries per day and 600 per minute for each site. That is too few to inspect a large site in full and plenty for a sample. A week of full quota is 14,000 URLs.

1. Sample by directory. Take a few hundred URLs from each top-level section rather than the first 2,000 in the sitemap.
2. Record two fields. The coverage state and the last crawl time are enough to separate waited from declined.
3. Pivot by path. Count Discovered and Crawled per directory. The sections with the worst ratios are your parent path suspects.
4. Repeat monthly. You are looking for movement after a fix, and both verdicts move slowly.

What this means for you

• Agencies: report the two rows separately. A single “not indexed” number hides whether the client needs a developer or an editor.
• In-house teams: send Discovered findings to whoever owns templates, navigation and hosting. Send Crawled findings to whoever owns the content.
• Consultants: group by directory before you present anything. A path-level finding is one recommendation. Four hundred URL-level findings is a spreadsheet nobody acts on.
• Founders: if the pages that matter for revenue are indexed, a long tail of tag and pagination URLs in either row is not an emergency.

Where CrawlRaven fits

Search Console gives you the verdict and stops. It does not say that a Discovered URL has no internal links, or that a Crawled URL shares a thin template with hundreds of siblings.

CrawlRaven joins Search Console, GA4 and a 200-point crawl into one ranked plan, so the status sits next to the evidence: internal links in, depth, status codes, and whether the page earns any clicks.

Sources used in this post

• ROAST: Search Central Live Deep Dive Barcelona, Day 1 recap (crawling)
• ROAST: Day 2 recap (indexing, rendering, URL Inspection API poster)
• ROAST: Day 3 recap (the timing tables)
• Search Engine Roundtable: the timing data and Gary Illyes' comment on it
• Search Console Help: Page indexing report, status definitions
• Google Search Console API: usage limits

Related reading on CrawlRaven

• The Page indexing report, row by row
• How long Google takes to index a page
• The 429 status code and Googlebot
• How long canonicalisation changes take
• Reading the Crawl stats report