Crawled vs Discovered - Currently Not Indexed: What 63 Unindexed Pages Taught Me

Search Console's Pages report puts "Crawled - currently not indexed" and "Discovered - currently not indexed" next to each other, and they sound almost the same. They aren't. One means Google has never fetched the page. The other means it fetched the page and decided not to keep it. The fix for one does little for the other.

On 1 November I checked every URL in this site's sitemap through the URL Inspection API, then asked Google to index 12 of the pages that were missing. Here is what the numbers looked like, what each status meant for my pages, and what changed one day later.

The short version: "Discovered" means Google knows the URL but hasn't crawled it yet. Fix it with internal links from pages that are already indexed, and give it time. "Crawled" means Google read the page and passed on it. Fix it by making the page worth indexing: improve it, merge it into a stronger page, or remove it. Request indexing helped 6 of my 12 pages within a day, but none of the 5 service pages I sent.

What the two statuses mean

Discovered - currently not indexed. Google found the URL in a sitemap or a link, but hasn't fetched it. Google's help page says it usually happens because crawling the site would have overloaded it, so the crawl was postponed. On a small site, it more often means Google doesn't think the URL is important enough to crawl yet. There's no last crawl date, because there was no crawl.

Crawled - currently not indexed. Google fetched the page, read it, and left it out of the index. There's a last crawl date. Google says the page may be indexed later and that you don't need to resubmit it. In practice it's a quality judgement. The page didn't add enough that Google's index doesn't already have.

URL is unknown to Google. This one appears in URL Inspection, not the Pages report. Google has no record of the URL at all, not even from the sitemap.

My numbers: 63 of 219 URLs not indexed

I ran the URL Inspection API over all 219 URLs in the sitemap on 1 November 2026. 156 were indexed. The other 63 broke down like this:

One tag page was excluded by its own noindex tag, which is deliberate. The two problems look very different once you split them by section.

What "Crawled - currently not indexed" looked like

Nine blog posts were crawled and rejected. Seven of them have something in common: they're broad, generic guides from 2025. A Git tutorial, a Python tutorial for beginners, a React hooks guide, a full-stack roadmap, a list of backend project ideas, an AI tools roundup, and a piece on AI and junior developers. Six of those seven were crawled on the same day, 19 August. Thousands of sites cover each of those topics already.

Meanwhile the posts that are indexed are mostly narrow and first-hand: a specific error message, the exact cause, what I tested. My guess, and it's only a guess from this pattern, is that Google read the generic guides and found nothing it didn't already have.

That's why resubmitting a crawled page rarely helps on its own. Google already has the page and already decided. What changes the outcome is changing the page. The day before this check I had unpublished 38 off-topic posts from the site's earlier life (computer tips, YouTube guides), because none had a single click in three months.

What "Discovered - currently not indexed" looked like

The Discovered pages were a different crowd: tag pages, the image converter pages (/tools/image-converter/jpg-to-png and so on), tool category pages and service pages. Many had few or no links pointing at them.

The converter pages are the clearest case. An Ahrefs crawl the same day listed them as orphan pages, meaning nothing on the site linked to them. They were in the sitemap and nowhere else. I added a block of links to them from the main image converter page and deployed it that evening.

I requested indexing for 12 pages. Here is what happened

On 1 November I used Request indexing in Search Console for 12 of the missing URLs, picking the pages that matter most: 5 service pages, 4 blog posts, the portfolio and two tool category pages. I sent about 15 requests in total (a few were repeats) and never saw a "Quota exceeded" message. One day later I inspected the same 12 through the API:

Six of twelve indexed in a day. Two of those had been "Crawled - currently not indexed", so a request can move a crawled page too, at least when the page is decent. But none of the five service pages was indexed. The two URLs Google had never heard of were still unknown a day after a direct request, and one page went from Discovered to unknown, which I can't explain.

Twelve pages over one day is a small sample, so read this as one site's result, not a rule. What it does show is that Request indexing gets a URL into a queue. It doesn't make Google want the page.

How to check all your URLs at once

The Pages report shows examples, not every URL, and it lags. The URL Inspection API gives the same answer as the URL Inspection tool for one URL per call, and you can script it. The quota is 2,000 inspections a day per property, which covers a small site in one run. It can't request indexing. There is no API for that outside job postings and livestreams.

Create a service account in Google Cloud, enable the Search Console API, and add the service account's email as a user on the property in Search Console. Then:

from google.oauth2 import service_account
from googleapiclient.discovery import build

creds = service_account.Credentials.from_service_account_file(
    "service-account.json",
    scopes=["https://www.googleapis.com/auth/webmasters.readonly"],
)
gsc = build("searchconsole", "v1", credentials=creds)

def coverage(url):
    result = gsc.urlInspection().index().inspect(body={
        "inspectionUrl": url,
        "siteUrl": "https://example.com/",   # or "sc-domain:example.com"
    }).execute()
    status = result["inspectionResult"]["indexStatusResult"]
    return status.get("coverageState"), status.get("lastCrawlTime")

print(coverage("https://example.com/blog/some-post"))

Loop that over the URLs in your sitemap and count the coverageState values. I called the same endpoint with plain HTTP rather than this library, but the request and response are the same. Keep the service account key out of your repository.

What to do about each status

Discovered - currently not indexed

• Link to the page from pages that are already indexed. A URL that only exists in a sitemap is a weak signal. Check for orphan pages with a crawler first.
• Keep the sitemap clean. Every URL in it should return 200, be canonical and be indexable. My sitemap still listed a noindex tag page, which is a mixed signal.
• Request indexing for the few pages that matter. Not for hundreds of URLs.
• Check the server. If Google says it postponed crawling because of load, slow responses are part of the problem.

Crawled - currently not indexed

• Ask whether the page deserves to be indexed. If it repeats what a hundred other pages say, improve it with something only you can add: your data, your test, your error message.
• Merge thin pages into one stronger page and redirect the rest.
• Unpublish what you wouldn't miss. Fewer weak pages also means less of your site Google has to judge.
• Then request indexing once, after the page has actually changed.

One thing that doesn't help Google here is IndexNow. Bing, Yandex and a few other engines use it, but Google doesn't. I wrote about that in the IndexNow status codes post.

I'll re-inspect the service pages and the rest of the 63 in a week and update this post with what moved.