Currently Not Indexed in GSC: 2026 Fix Guide

Administrator in Search Engine Optimization Oct 13 / 4 days ago

The gray rows in the Search Console Page indexing report cause website owners a lot of worry. The worst ones say Google discovered a page but did not crawl it, or crawled it and decided to leave it out. Both look like a broken switch, but they are not the same problem, and they do not share the same fix.

This guide is for website owners, content leads and developers in the United States, Europe and South Korea, whose important pages sit in "Discovered - currently not indexed" or "Crawled - currently not indexed". We will identify the stage each status points to, examine the page, fix the underlying cause, and then validate, using Google's official documentation as of October 13, 2026.

What do the two "currently not indexed" statuses mean?

Both statuses mean Google knows the page exists but has not added it to its index. The Discovered status means Google located the URL and has not crawled it yet, while the Crawled status means Googlebot fetched the page and Google chose not to index it, for now. In our view, one is a queue question and the other is a value question.

Google's guide to how Search works describes three stages: crawling, indexing and serving. Search Console Help for the Page indexing report explains that a page in "Discovered - currently not indexed" was discovered but not crawled yet, and that a page in "Crawled - currently not indexed" was crawled but not indexed and may or may not be indexed later. Our take: most failed fixes treat both rows as one technical bug and keep pressing Request indexing, when the two rows sit at different stages and need different work. Our complete Search Console guide covers every other report.

Is a page that is not indexed always a problem?

No. Google's documentation for the Page indexing report explains that a URL can stay out of the index for the right reasons, and a robots.txt rule, a noindex rule, a duplicate URL or a 404 for a removed page can all be acceptable. The problem starts when a page you need in Google Search sits in a gray row.

Google's report documentation is blunt: "Don't expect every URL on your site to be indexed." The same documentation asks you to read the reason for each URL that stays out, and Google's guide to how Search works adds that Google does not promise to crawl, index or serve a page, even one that follows Search Essentials. In our view, a "not indexed" count is not a score, and a page that is currently not indexed only matters if you want people to discover it.

Why would Google crawl a page and then leave it out?

Google's crawl budget guide states that each crawled page is still evaluated, grouped with similar pages and judged before it joins the index, which means a page can pass the crawl and still fail that review. Google's guide to how Search works names low quality content and a website design that makes indexing difficult among the common causes.

That Google guide states plainly that "Indexing isn't guaranteed", and in our view the fix for the Crawled status is usually the page itself, not the technical plumbing. Google's page on helpful content asks a pointed question: "Are you mainly summarizing what others have to say without adding much value?" That Google page also describes pages generated from feeds or AI text without oversight as "little to no effort". For example, a recipe blog in Denver, Colorado might publish many near-identical tag and archive pages that list the same posts. You have three options: merge, improve or remove. Our helpful content guide covers the improve side, while our content pruning playbook covers merging and cutting.

How do the two statuses compare side by side?

The Discovered status means Google has not fetched the page yet, and the report displays no last crawl date, while the Crawled status means Googlebot fetched it and Google held it back. Google names a cause only for the first, typically a crawl that was expected to overload the website, and in our view resubmitting helps neither.

The first four rows follow Google's Page indexing report help, and the last row is our own view.

Read the table from left to right before you change anything, and begin your work in the matching column.

Why would Google know a URL but not fetch it?

Google discovered the URL but has not spent a crawl on it yet, and Google's report documentation explains that the crawl is typically rescheduled to avoid overloading the website. On a very large website that can be a real server limit, but on smaller websites we think it more often points to weak internal links and too many low-value URLs.

Google's crawl budget guide explains that the crawl capacity limit rises when a website responds quickly and stays stable, and it falls with slow responses, 5xx errors or HTTP 429 replies. On perceived inventory, the guide says: "This is the factor that you can positively control the most." Google describes the guide as intended mainly for very large websites, websites with rapidly changing content, and websites with a large share of URLs in "Discovered - currently not indexed". When the URL Inspection tool displays "Hostload exceeded", the crawl budget guide suggests adding server resources if that makes sense for your business. Our log file analysis guide explains how to see what Googlebot fetches, while our crawl stats report guide explains how your server responds.

Does pressing Request indexing again help?

No. Google's recrawl documentation states that there is a quota for individual URL requests, and asking again for the same URL does not get it crawled any faster. For a page in "Crawled - currently not indexed", Google's report documentation explains that there is no need to resubmit, and in our view one request after a real change is enough.

Google's guide to asking for a recrawl is direct: "Requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all." The next line of that guide matters more: "Our systems prioritize the fast inclusion of high quality, useful content." The same recrawl guide explains that crawling can take a few days to a few weeks, and Search Console Help also notes a daily limit on inspection requests for each property, which means pressing the button every morning only spends that limit. If your website is new, our guide to SEO on a brand new domain covers what to do while you wait.

Can the Indexing API or a paid service force a page in?

No. Google's Search Central quickstart for the Indexing API states that the API can only be used for pages with job posting or livestream markup, which means a blog post or a product page does not qualify. As for paid indexing services, we would avoid them and fix the reason the page sits in a gray row instead.

Our guide to XML sitemaps and the Indexing API explains where the API fits for job posting and livestream pages. Google's guide to how Search works states that Google does not accept payment to crawl a website more often, and we think that money is better spent on the page itself.

What should you check in the URL Inspection tool first?

Start with the indexed result, not the live test, and read the last crawl date, the Google-selected canonical and how Google discovered the URL. Search Console Help explains that the live test does not check duplicates, sitemaps, referring pages or quality, which means a clean live test does not guarantee the page will be indexed.

Search Console Help for the URL Inspection tool explains that the live test cannot predict the Google-selected canonical. In our view, you should work through these checks in order.

• Last crawl: if you fixed the page after this date, Googlebot has not seen the fix.
• Google-selected canonical: a different URL here signals a duplicate question, not a quality one.
• Discovery: note the sitemap and the referring page, if Google lists them.
• Crawl allowed and indexing allowed: a noindex rule keeps the page out of the index, and a robots.txt rule stops the crawl.
• The rendered page: confirm that the main text appears after scripts run.

Our JavaScript SEO guide walks through rendering, and our guide to canonical tags explains the signals behind that canonical field.

How do sitemaps and internal links change what Google crawls?

Google's report documentation explains that Google needs a way to discover a page, either a link from a known page or a sitemap, and both can lead to a crawl. In our view, internal links do more work and also show which pages you treat as important, while a sitemap entry on its own is a weak hint.

Google's guide to how Search works calls this URL discovery, with the example of a category page that links to a new blog post, and Google's link best practices add that Google can reliably crawl a link only when it is an anchor element with an href attribute. Google's sitemap guide states that one sitemap can hold up to 50,000 URLs or 50MB uncompressed. For a page in the Discovered status, we think a link from a strong hub page beats resubmitting the sitemap. Our internal linking strategy guide covers hubs and anchor text, and our guide to faceted navigation and crawl traps explains how filter URLs pile up.

Which technical mistakes push good pages into these rows?

We think the usual mistakes waste Googlebot's crawling on the wrong URLs. Soft 404 pages, long redirect chains, slow or failing servers and noindex rules used to steer crawling all appear in Google's crawl budget guide as things to avoid, and each one leaves less room for the pages you care about.

Do not noindex pages to save crawl budget, because Google's crawl budget guide explains that Googlebot still requests the page, then drops it when it sees the noindex rule, which wastes crawling time. For pages you removed permanently, that guide recommends returning a 404 or 410, and it warns that soft 404 pages keep getting crawled. Google's report documentation defines a soft 404 as a friendly "not found" message without a 404 code. The same documentation notes that "Duplicate without user-selected canonical" is a separate row, where Google chose another page as canonical and calls this working as intended. Our guide to HTTP status codes and our robots.txt and noindex guide cover the mechanics.

What changes for sites that serve Europe or South Korea?

In our reading, nothing changes in how Google assigns these statuses, and every country sees the same report and the same rules. What changes is the number of URLs, and each language version is its own page that has to earn its place in the index on its own merits.

For example, a furniture shop in Rotterdam, Netherlands might run Dutch and English pages, and if the Dutch pages are thin machine-made copies of the English ones, they can sit in "Crawled - currently not indexed" while the English pages become indexed. Our hreflang guide covers how to connect language versions. Many European websites also receive Bing traffic, and Bing offers IndexNow, which our Bing SEO guide covers. A software firm in Seoul, South Korea, for example, should examine Naver's own tools too, as Naver keeps its own index. A gray row in Google tells you nothing about Naver, and our Naver SEO guide explains that side.

When should you click Validate fix, and what happens next?

Click Validate fix once, after you have fixed every page in the group, because Google's report documentation states that you should not click it again until validation has passed or failed. That documentation explains that validation "typically takes up to about two weeks" and can take much longer, while Search Console sends progress emails throughout.

Google's report documentation describes the end states: Passed means all known instances of the issue are gone, and Failed means enough pages still show the issue after you started validation. We see validation as a receipt, not a lever, and it cannot make Google retain a page it does not value.

The gray rows in the Page indexing report are not a verdict on your website but a map of where each page stopped on its way into Google. Identify the stage, fix the page or the path to it, and give Google time to look again. Pages that are currently not indexed for legitimate reasons can stay gray without any harm.

Frequently asked questions about pages that are not indexed

Why is the last crawl date empty for a Discovered page?

Google's report documentation explains it directly: for a page in "Discovered - currently not indexed", Google discovered the URL but has not crawled it yet. The documentation says: "Typically, Google wanted to crawl the URL but this was expected to overload the site". Google then rescheduled the crawl, which is why the date field is empty, and in our view it only becomes a concern when important pages stay there for a long time.

Can a page leave the Crawled status without any change?

Yes, and Google's report documentation states that a page in "Crawled - currently not indexed" may or may not be indexed in the future, adding that there is "no need to resubmit this URL for crawling". To us, a page that sits there for a long time is telling you something about its value. Waiting is reasonable for a fresh page, but for an older page with thin content a rewrite or a merge is the better option.

Why does the report not list all my URLs?

The report's help page states that the list of example URLs is limited to 1,000 items and is not guaranteed to show every URL in a status, even when there are fewer than that. For patterns and totals, use the Page indexing report, and for a single page, use the URL Inspection tool, which the same documentation recommends for that job. Export the examples, group them by folder, and look for a shared cause.

Does a passing live test mean the page will be indexed?

No. Search Console Help states that the live test does not check sitemaps or referring pages, does not test whether a page is a duplicate, and does not check quality and security guidelines, manual actions or removals. It also explains that the Google-selected canonical appears only in the indexed data. In our view, a clean live test shows Googlebot can fetch and render the page today, but it says nothing about whether Google will choose to retain it.

Should I noindex weak pages to save crawl budget?

No, because Google's crawl budget guide explains that Googlebot will still request a page with a noindex rule, then drop it, which wastes crawling time. If you want Google to stop crawling a group of URLs, the same guide points to robots.txt for pages you never want crawled, and a 404 or 410 for pages you removed permanently. Use noindex only for pages that should stay out of Google Search, not as a crawl control.

Do the priority and changefreq values in a sitemap help?

No. Google's sitemap guide states that Google ignores the priority and changefreq values, and it uses the lastmod field only when the date is "consistently and verifiably" accurate. To us, a lastmod date that changes every night with no real edit fails that test, and you should keep it honest, list only URLs you want indexed, and let internal links show which pages matter. A sitemap helps Google discover URLs, but it does not make Google retain them.

How long does a new page take to get indexed?

There is no fixed answer. Google's report documentation states that it can take "a week or so" for Google to begin crawling and indexing a new page or website, while Google's recrawl guide explains that crawling can take from a few days to a few weeks. Neither documentation page promises indexing, and our advice is to use that window to add internal links from strong pages and inspect the URL in Search Console once, then leave it alone.

Does a drop in indexed pages mean Google penalized my site?

Not by itself. Google's help for this report states that a drop in indexed pages without more errors can mean you are blocking pages with robots.txt, a noindex rule or a required login, and the same documentation suggests looking for a spike in non-indexed URLs that lines up with the drop. Examine those blocks first. We see a penalty as a different thing, which we would expect to appear as a manual action in Search Console, not as pages moving into a gray row.