Not Indexed: Why Google Skips Your Pages and What to Do

You open Search Console, click Indexing → Pages and scroll down to “Why pages aren't indexed”. Two rows stare back at you. “Crawled - currently not indexed”: Google came over, looked at your page and left without it. “Discovered - currently not indexed”: Google knows the page exists and hasn't bothered to visit. It's hard not to take that personally.

Google's own help page for this report is surprisingly relaxed about it: “If your site has fewer than 500 pages, you probably don't need to use this report.” It even has an FAQ entry, “Is it OK if a page isn't indexed?”, with a one-word answer: “Absolutely.”

So forget getting these numbers to zero. Nobody gets there, and Google doesn't expect you to. Look at which pages are in there and whether any of them should be in Google. Then work through the fixes further down, in order.

In short
“Discovered - currently not indexed” means Google knows the URL but hasn't crawled it yet. “Crawled - currently not indexed” means Google crawled it and decided not to index it, for now. Neither is an error. Google never indexes every page. Look at which pages are affected: if they're filter, search or tag pages, that's normal. If they're pages you need in search, make them worth indexing, link to them from pages that matter, make sure your server copes, request indexing once, and then wait. Clicking the button again doesn't help.

What the two statuses mean

Google's own definitions are short. For Discovered: “The page was found by Google, but not crawled yet.” Google adds: “Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl.” That's also why the last crawl date in the report is empty.

For Crawled: “The page was crawled by Google but not indexed.” Google calls it “a common message for many sites”.

The help page makes Discovered sound like a server problem. Google's own people tell a different story. Martin Splitt said in 2024 that “The other far more common reason for pages staying in discovered currently not indexed is quality though.” And Gary Illyes admitted that Crawled is basically a catch-all: “ideally we would break up that category into more granular chunks, but it’s super hard because of how the data internally exists.” So one label can mean several different things. Comforting, isn't it.

Is it a problem for your site?

It depends on which pages are in there. A webshop with 40,000 filter combinations will always have thousands of URLs in these two rows, and it should. A ten-page business site with its services page in there has a real problem.

The report doesn't make this easy. It shows at most 1,000 example URLs per status, and it never tells you why a page is in there. You work that out from the URLs.

How long can it last? John Mueller answered that in 2022: “That can be forever. It’s something where we just don’t crawl and index all pages.” On a new site, he added, it's normal for a lot of fresh content to sit in Discovered for a while.

And when quality is the reason, Google may be judging the whole site. In a Search Off the Record episode this July, Mueller said that “if our systems are seriously worried about the quality of a website, that they will reduce the number of pages that they index.” He also explained why site owners find this hard to see: “it's your baby, and of course it's the best baby ever.” Fair.

Why Google skips pages

When it's Discovered

Google wants to crawl, but something holds it back. Often it's your server. Google's crawl budget guide says that when a site responds slowly or “with server errors”, “the limit goes down and Google crawls less.” New sites get the same cautious treatment, because “Every site starts with the same default, conservative crawl capacity limit.”

Then there's the clutter. Filters, sorting parameters, tag pages and calendar pages can easily outnumber your real pages, and Google spends its visits on them while your new article waits in line. A page linked only from page 9 of an archive, or only from the sitemap, doesn't look important either. And if Google has seen a pattern of thin pages on the site, Splitt says the new ones “might stay in discovered”.

The crawl budget guide is written for big sites, the ones with over a million pages. It makes one exception: sites with “a large portion of their total URLs classified by Search Console as Discovered - currently not indexed”. If that's you, read it.

When it's Crawled

Google fetched the page and decided it isn't worth keeping, at least for now. The usual reasons:

• The page is thin, or nearly empty: a product with one line of text, a category with two items, a tag page with one post.
• A very similar page is already indexed. Illyes calls this dupe elimination: “we crawl the page and then we decide to not index it”, because the other version “has better signals”.
• The text only appears after JavaScript runs, and what Google sees first is an empty template. Onely, an SEO agency that studies indexing, calls an empty JavaScript shell thin content, and thin content “the most common reason for this status”.
• Google has doubts about the site as a whole. Illyes: “If the number of these URLs is very high that could hint at general quality issues.”
• The page was indexed before and then dropped. A quick test: if a page in this status had impressions in the Performance report at any point in the last 16 months, it must have been indexed once.

What to do, in this order

1. Find out which pages they are. In the Page indexing report, switch the filter at the top from “All known pages” to “All submitted pages”. Now you only see URLs from your sitemaps, the ones you said you care about. Export the list and group the URLs by pattern. Most sites end up with two or three groups, not hundreds of separate problems.
2. Decide whether each group belongs in Google. Filter results, internal search pages, tag archives and sorting variants usually don't. Leave them, take them out of the sitemap, and stop linking to them from everywhere. If there are so many that Google wastes its visits on them, the crawl budget guide suggests blocking unimportant URLs, such as sorted versions of the same list, in robots.txt. It also says not to use noindex to save crawl budget, because Google still has to fetch a page to see the noindex.
3. Make the pages worth indexing. Add what a reader would actually come for, or merge several thin pages into one good one. Splitt's advice for Discovered fits Crawled too: “rework the content to be of higher quality and make sure your internal linking relates this content to other parts of your existing content”.
4. Link to them from pages people visit. Not from the footer of every page, but from the category, guide or article where a reader would want to go next. Our posts on click depth and pages with few internal links go deeper.
5. Check that your server copes. Open Settings → Crawl stats in Search Console and look at host status and response times. If URL Inspection says “Hostload exceeded”, Google thinks your server is at its limit.
6. Request indexing once, then wait. Google's recrawl documentation is blunt: “requesting a recrawl multiple times for the same URL won't get it crawled any faster”. Clicking it every morning with your coffee doesn't count as a strategy.

What about Validate fix?

Validate fix is Search Console's version of the close-door button in a lift. Pressing it feels productive, and you're never quite sure it does anything. Google hasn't been sure either. In January 2025 Mueller wrote on Reddit that it “will only track how things are being reprocessed. It won't speed up reprocessing itself”. In July 2026 he said that if a sample of the pages you marked as fixed really is fixed, Google will usually trigger “a faster recrawl of the other pages.” Neither version makes Google want a page it didn't want. With these two statuses there's usually nothing concrete for Google to check, so the counter won't drop because you clicked a button.

What DeepSpider checks

DeepSpider can't see Google's index from the outside, so it looks for the reasons Google gives. A DeepSpider audit flags pages with little main content, near-duplicate and duplicate pages, soft 404 candidates, orphan pages and pages with few internal links, pages too many clicks from the home page, sitemap entries that aren't indexable, URL parameters that multiply into hundreds of variants, server errors and slow responses. That covers most of the reasons in the two lists above.

If you also bring in your Search Console data, by uploading the Performance export, DeepSpider puts Google's numbers next to the audit. It shows indexable pages that get impressions but no clicks, and pages Google shows in search that the audit found broken, redirected or noindexed.

For a single page, the free Indexability Checker tells you whether anything on your side blocks indexing: robots.txt, a noindex in the HTML or the HTTP header, an odd canonical tag or an error status. It doesn't run JavaScript and it can't see whether Google indexed the page. That's what URL Inspection in Search Console is for.

FAQ

How long does indexing take?

Longer than you'd like. Google says “It can take a week or so for Google to start crawling and indexing a new page or site” and that indexing “typically takes only a day or so, but can take much longer in some cases.” For pages in Discovered, it can take months, or never happen.

Can a good page stay unindexed?

Yes. Mueller, in 2023: “A page can be of high quality and still not be indexed - it's not guaranteed.” Annoying, but honest.

Will submitting a sitemap fix it?

Not for these two statuses. A sitemap helps Google find URLs, and Google has already found these. It's still useful for telling Google which pages you care about, and for filtering the report to them.

One of our own sites

For a real example we opened Search Console for another, small website we run. Not deepspider.ai: with 61 pages, that one sits well under Google's 500-page line. On 6 November the other site's Page indexing report said 48 pages indexed and 64 not indexed. More not indexed than indexed. That looks alarming until you read the Source column.

41 of the 64 say Website: redirects, noindex tags, removed pages and blocked URLs. Those are the site's own choices, and most of them do exactly what they're supposed to. Only 23 are Google's own decision, the two statuses this post is about. So before you read anything into the big number, sort by Source.

The Discovered row is a single URL, and somebody (fine, us) had already clicked Validate fix on it. As the section above explains, that's mostly for our own peace of mind.

The 22 Crawled pages looked like a lot of work. Next to 48 indexed pages, they are a lot. The export from the overview doesn't list them, which surprised us: you have to click the row and export again from there. So we did, and the 22 broke down like this:

• 17 were RSS feeds, the /feed/ addresses WordPress creates for the site, for every category and for many posts. A feed is an XML copy of articles Google already has, so there's nothing for it to add. One of them was literally /search/{search_term_string}/feed/rss2/, a template placeholder that ended up looking like a link. Google tried it. Of course it did.
• 2 were /go/ links that send visitors on to partner sites with a redirect. They were never meant to be in search.
• 3 were real articles: full pages, each with its own canonical tag and no noindex.

So 22 became 3. And that's the point of this whole post: most of the list never belonged in search, and only the short list that's left needs you. For those three we're going through the steps above, starting with what makes them different from similar pages that did get indexed, and whether any page people actually visit links to them.

One more thing the chart showed. In mid-August the site had 34 pages indexed and 35 not indexed. In November, 48 and 64. Both numbers grew together as the site grew, which is exactly what they should do. If your Not indexed number goes up while you publish, check which rows grew before you check your blood pressure.

Sources