Search Console "Discovered / Crawled - currently not indexed": The Difference and What to Check
'Discovered - currently not indexed' and 'Crawled - currently not indexed' stop at different stages. What each status means, what to check for each, and why the report and site: show different numbers.
Your posts don't show up in search
Open the Page indexing report in Google Search Console and two lines often show up among the reasons pages aren't indexed:
- Discovered - currently not indexed
- Crawled - currently not indexed
They read almost the same, so they look like one problem. But they stop at different stages, and so what you should check is different too. This blog ran into both, and this post sums up what I checked.
First: the stages before a post appears in search
To appear in Google Search, a page goes through discovery → crawling → indexing in order. A Search Console status tells you which stage it stopped at.
| Stage | What happens | If it stops here |
|---|---|---|
| Discovery | Google learns the URL exists, from links or a sitemap | Google doesn't know the URL at all |
| Crawling | Googlebot actually fetches and reads the page | Discovered - currently not indexed |
| Indexing | The content is analyzed and stored for use in search | Crawled - currently not indexed |
| Serving | Shown in results when it matches a query | Indexed, but ranks low |
Submitting a sitemap helps the first stage, discovery. Being in a sitemap doesn't guarantee crawling or indexing.
"Discovered - currently not indexed"
Google knows the URL exists but hasn't fetched it yet.
Summarizing Google's help page: Google wanted to crawl the URL but expected that to overload the site, so it rescheduled the crawl. That's why URL Inspection shows the last crawl as "N/A". It has never been fetched.
Here's what URL Inspection showed for one post on this blog:
URL is not on Google
Page is not indexed: Discovered - currently not indexed
Referring page: /?tag=nodejs, /ko/javascript-nullish-..., /blog/js-data-01
Last crawl: N/A
The referring page tells you where Google first learned about the URL. Here, Google found it through a tag filter URL on the list page and through an old post URL (/blog/...) from before the site moved its post addresses.
What to check
| Check | Why |
|---|---|
| Is there a regular link (<a href>) to the post inside the site? | A post that's only in the sitemap with no links gives Google little to judge its importance by. Posts hidden behind a "Load more" button are a typical case |
| Is the server slow, or returning errors (5xx)? | Slow or failed responses make Google crawl more slowly |
| Did many new URLs appear at once? | Right after a URL migration or a burst of new posts, crawling takes time to catch up |
| Are there many low-value URLs, like filters and search results? | Many addresses with the same content can use up crawling that should go to real posts |
People often blame "crawl budget," but according to Google's docs, crawl budget is mainly a concern for very large sites. For a personal blog with dozens of posts, suspect a new site with low priority, or a weak link structure first.
"Crawled - currently not indexed"
Google fetched and read the page, but decided not to index it (for now).
Unlike "Discovered," crawling is already done. Google's help page says such a page may or may not be indexed in the future, and there's no need to resubmit it for crawling. It's Google's judgment, not a technical error.
What to check
| Check | Why |
|---|---|
| Is the content nearly identical to another page? | When several pages have the same content, Google indexes only one. Filter URLs and tag list pages are common causes |
| Is the content very short or empty? | A page with almost no body may be judged not worth indexing |
| Was the page working when it was crawled? | If it showed an error page or an empty list then, Google may have judged it in that state |
| Does canonical point to the right URL? | If canonical points elsewhere, this page isn't a candidate for indexing |
Once you've fixed it, click Validate fix on that item in the report. This blog has started validation for 2 pages in this status.
The two statuses side by side
| Discovered - currently not indexed | Crawled - currently not indexed | |
|---|---|---|
| Stopped at | Before crawling | Before indexing |
| Did Google read the page? | No (last crawl: N/A) | Yes |
| Suspect first | Link structure, server health, many new URLs at once | Duplicates, thin content, the page's state when crawled |
| What to do | Add internal links, request indexing for key posts | Improve content, clean up duplicates, then Validate fix |
When the numbers disagree: report vs URL Inspection vs site:
The most confusing part on this blog was the numbers. The Page indexing report said 8 pages were indexed, but a site: search showed far more results, across 4 pages.
| Tool | As of | Notes |
|---|---|---|
| Page indexing report | The "Last updated" date on screen | Updates days late. I checked on Oct 14, and it was last updated Oct 9 |
| URL Inspection | Nearly now | The latest state of one URL. Changes before the report does |
| URL Inspection live test | This moment | Checks "could this be indexed if fetched now," not whether it actually is indexed |
| site: search | Now | The result count is approximate. Don't treat it as an exact index count |
When I opened the report's 8 indexed pages, every one was an old address (/blog/...) from before the move, and every last-crawl date was before the Oct 8 move. The report only shows "what Google knew as of that date."
"URL is available to Google" in the live test and "URL is on Google" in the Google Index tab are different. The first means "fetching it now would be fine." Only the second means it's actually indexed.
Requesting indexing repeatedly doesn't make it faster
Request indexing in URL Inspection is useful for telling Google about important posts. But according to Google's docs, there's a quota, and requesting the same URL multiple times won't get it crawled any faster. Crawling can take anywhere from a few days to a few weeks.
So this order works best:
- Fix the cause first (link structure, errors, duplicates).
- Request indexing for only your most important few posts.
- Make sure your sitemap is up to date.
- Wait until the report's "Last updated" date moves past the day you fixed things, then check again.
Summary
| Status | In one line | Check first |
|---|---|---|
| Discovered - currently not indexed | Google hasn't read it yet | Is there an <a href> link to the post? |
| Crawled - currently not indexed | Read, but not indexed | Is the content duplicated or thin? |
Neither status is an "error." Both mean the page hasn't made it through every stage yet. Read which stage it stopped at from the status text, then check what matters for that stage. And since the report updates late, don't judge by the numbers right after a fix.
The concrete case that was blocking the "discovery" stage on this blog is in the next post: "Load More" Buttons and SEO