How to Fix Crawled and Discovered Currently Not Indexed Pages in Search Console

"Crawled - currently not indexed" means Googlebot fetched your page, read it, and chose to leave it out of the index for now. "Discovered - currently not indexed" happens one step earlier, when Google knows the URL exists but hasn't fetched it yet. Both statuses show up in the Page indexing report of Google Search Console, and site owners treat them as errors far more often than they should.

Google never promises to index anything. Its own How Search Works documentation says "indexing isn't guaranteed; not every page that Google processes will be indexed." When a page you care about lands in one of these buckets, the cause usually traces back to how important your site makes that page look, how your server behaves when Googlebot asks for it, or whether the content gives Google a reason to keep it.

What "Crawled - currently not indexed" means

Google's Page indexing report documentation describes this status in one line, "The page was crawled by Google but not indexed." Googlebot requested the URL, got a response, and passed the page on for indexing. Somewhere in that indexing stage, Google decided the page wasn't worth a slot in the index, at least not yet.

That decision is mostly about quality and duplication. Gary Illyes of Google explained in Google's How Search Works video series that index selection "largely depends on the page's quality and the previously collected signals," as Search Engine Journal reported. So by the time a URL sits in this bucket, Google has already seen what's on it and judged the page against the rest of your site and the rest of the web.

The same documentation tells you there's "no need to resubmit this URL for crawling." Pressing Request indexing over and over won't change the outcome, because Google has the page already. You change the outcome by changing the page or the signals around it, and then letting Google crawl it again.

What "Discovered - currently not indexed" means

This status means Google found the URL, usually through a link or a sitemap, and put it in the queue without fetching it. The Search Console documentation says "the page was found by Google, but not crawled yet," and adds that Google typically wanted to crawl the URL but the request "was expected to overload the site," so the crawl got rescheduled. That's why the last crawl date for these URLs shows as empty.

Server capacity is only part of the story. Google's crawl budget guide says crawl demand "varies based on a site's size, update frequency, page quality, and relevance." When Google has a low opinion of the URLs it already crawled on your site, it has less appetite to fetch the new ones, so a big Discovered bucket often points at a quality or site structure problem as much as a hosting one.

Size matters too. The same guide says crawl budget becomes a real concern for sites with more than a million unique pages that change weekly, or more than 10,000 pages that change daily, and it calls those numbers rough guides. A company site with 300 pages and 80 URLs stuck in Discovered almost never has a crawl budget problem. It has a link or quality problem that makes Google decide those 80 URLs can wait.

How the two statuses differ

The two labels look alike in the report, but they sit at different stages of Google's pipeline and need different fixes. The table below lines them up.

One pattern tells you a lot about a site. When most of the problem URLs sit in Discovered, Google is choosing not to spend effort on them before reading them. When most sit in Crawled, Google read them and wasn't convinced. Both are verdicts on value, so the fixes overlap more than the labels suggest.

Check whether the page should be indexed at all

Before you fix anything, open the report, export the URL list, and sort it by pattern. On most sites a large share of these URLs are pages nobody should want in Google's index. Filtered category views, internal search results, tracking parameters, tag archives with two posts, print versions and paginated feeds all pile up here, and Google leaving them out is the correct call.

Group the export by URL pattern and you'll usually find a few buckets that explain most of the count.

• URLs with query parameters such as ?sort=, ?color= or ?utm_source=
• Internal search result pages
• Thin tag, author or date archives
• Pagination deep in a category
• Near-identical product variants or location pages
• Pages that return a 200 status but show an empty or "no results" state, which Google treats as soft 404s
• Old URLs that should redirect but don't

These buckets cost you even when you don't want them indexed. Google's crawl budget guide warns that "soft 404 pages will continue to be crawled, and waste your budget," and that duplicate URLs waste "a lot of Google crawling time." Clean them up with a noindex tag, a canonical, a redirect, a robots.txt rule for parameter patterns, or by removing the internal links that generate them. What remains after this triage is your real list, the pages you want indexed and Google doesn't.

Make important pages easy to reach from the homepage

Google learns which pages matter on your site largely from your internal links. Its link best practices say Google "uses links as a signal when determining the relevancy of pages and to find new pages to crawl," and that "every page you care about should have a link from at least one other page on your site." A page that's only reachable through the sitemap, or buried six clicks deep in a paginated archive, sends a weak importance signal no matter how good it is.

Two measurements tell you where a page stands. Crawl depth is the number of clicks it takes to reach the page from the homepage, and unique inlinks is the number of distinct internal pages that link to it. Google doesn't publish a depth limit, but a sensible working rule is to keep any page you want indexed within three clicks of the homepage and linked from several relevant pages, rather than from one listing page alone. A crawler such as Screaming Frog reports both numbers for every URL, and we've written about reading crawl data alongside indexing problems.

The practical fixes are plain. Link to new articles from older ones on the same topic, add related links on product and service pages, surface priority pages in navigation or hub pages, and cut pagination depth by linking categories more widely. Check that the links are real <a href> elements, too. Google says it "can't reliably extract URLs from <a> elements that don't have an href attribute," so links built only with JavaScript click handlers may as well not exist.

JavaScript rendering creates a related trap. If your internal links or main content only appear after scripts run, Googlebot sees a thinner page on its first pass. Our explainer on the Googlebot render queue covers how that delays indexing, and our free Agent View extension compares the raw HTML with the rendered page so you can see what a crawler gets before JavaScript runs.

Fix server speed and Core Web Vitals

Core Web Vitals and crawl speed get lumped together, but they affect indexing in different ways. Core Web Vitals measure what a visitor experiences, with Google's recommended thresholds being Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. Google's page experience documentation says these metrics "are used by our ranking systems," and also that Google "always seeks to show the most relevant content, even if the page experience is sub-par." Google hasn't described them as an indexing filter, so treat weak scores as a ranking and conversion problem rather than the reason a page is missing from the index.

Server response is where speed hits indexing directly, especially for Discovered URLs. The crawl budget guide says the crawl capacity limit goes up when a site's response times, "including latency and Time-to-First Byte," stay stable or improve. It goes down when the site slows or returns 5xx errors or HTTP 429 rate limiting. Google's How Search Works page puts it bluntly, "HTTP 500 errors mean 'slow down'."

Open the Crawl stats report under Settings in Search Console and look at average response time and the host status checks. If response times climb during traffic peaks, or you see server errors and failed robots.txt fetches, fix hosting, caching and database queries before you touch content. Faster pages also help directly, because the guide notes that "if Google can load and render your pages faster, we might be able to read more content from your site."

Improve content quality and remove duplication

For URLs stuck in Crawled, content is usually the reason. Google's How Search Works page lists "the quality of the content on page is low" among the common indexing issues, and the pages that usually land in this bucket are easy to recognise. They're product pages with only the manufacturer's description, location pages that swap the city name and nothing else, blog posts that cover a topic already covered better on the same site, and category pages with two items and no text.

Compare each page against two things, the best-ranking pages for the query it targets and the other pages on your own site. If a competitor answers the question more completely, the page needs real additions such as original data, specific examples, prices, specs, photos or a clearer answer. If another page on your site already covers the same intent, merge the two and redirect the weaker URL, because Google picks one page from a group of similar pages and Google's documentation says it shows "the one that's most representative of the group" gets shown.

Quality also works at the site level. A site with thousands of thin pages makes Google more cautious about every new URL, which is why the Discovered bucket on a large, thin site keeps growing even after the server gets faster. Pruning or improving the weakest pages often moves the indexing numbers for the rest of the site, and on Squarespace and similar builders, template-generated pages make this worse, as we covered in our post on why Squarespace blog posts drop out of the index.

How to fix Discovered - currently not indexed

Work through the causes in order of how much they move the numbers on a typical site.

1. Shrink the URL inventory Google knows about by blocking parameter patterns, removing links to filtered views and fixing soft 404s.
2. Keep the XML sitemap limited to canonical, indexable URLs that return a 200 status, with accurate lastmod dates.
3. Add internal links to the priority URLs from pages Google already crawls often, such as the homepage, hub pages and popular articles.
4. Check Crawl stats for slow response times and 5xx or 429 responses, and fix the server side.
5. Improve or prune the thin pages that drag down Google's view of the site.

Large sites should read our breakdown of how crawl budget works on large sites, since that's where capacity becomes the limit. If Bing matters to you, Bing supports IndexNow for instant URL notification. Google doesn't use IndexNow, so for Google the sitemap and internal links remain the discovery routes.

How to get Google to look at the page again

After you've fixed a page, use URL Inspection on it and run a live test to confirm Google can fetch it, render it, and see no noindex or conflicting canonical. Then click Request indexing for your most important URLs. Google's recrawl documentation is clear about the limits, though. It says requesting a crawl "does not guarantee that inclusion in search results will happen instantly or even at all," that there's a quota for individual URLs, and that "requesting a recrawl multiple times for the same URL won't get it crawled any faster." For larger batches it recommends a sitemap.

Once a pattern is fixed across the site, use Validate fix in the Page indexing report. Validation "typically takes up to about two weeks," and Google stops it early if it finds a single remaining instance of the issue, so fix the whole pattern before you start. Crawling itself can take "anywhere from a few days to a few weeks," which means you should judge the result over a month, by watching the count of indexed pages in your priority folders rather than the total size of the not-indexed buckets.

Some URLs will stay in these buckets permanently, and that's fine when they're the low-value pages from your triage. The ones that matter are your service pages, products and articles. If those keep getting skipped after the structure, server and content work, the cause usually sits deeper in the site's architecture, and our technical SEO team can audit the full crawl-to-index path with you.