Crawled - currently not indexed: why validation failed

You fixed the pages, clicked "Validate fix", waited a week or two, and Search Console sent back one word: Failed.

Here's what that word really means for the "Crawled - currently not indexed" row, what I found when I sorted the 25 URLs in my own report today, and how to set up the next validation so it has a fair chance of passing.

What does "validation failed" mean for Crawled - currently not indexed?

It means Google rechecked the URLs in that row and found some that were still crawled but not indexed, so it stopped. It doesn't prove your fix is broken. For this row, "fixed" means Google chose to index the page, or the URL left the row, for example because it now redirects or has noindex.

"Noindex" is a tag or header that tells Google not to show a page in search. I'll come back to why that matters.

The thing is, this row is different from most rows in the Page indexing report. Its Source column says "Google systems", not "Website". Google's Page indexing report help page says you can generally fix only the issues whose source is your website. For this row, the same page says the URL may or may not be indexed in the future, and there's no need to resubmit it for crawling.

So a validation on this row is really asking Google: "Will you index these now?" If Google's answer for even some of the URLs is still "no", the run fails.

How a validation actually runs

Google checks a few URLs first, then works through the list in that row, and stops when it finds a URL that still has the issue.

This is all from Google's own Validation details help page, in my words:

1. Quick sample. As soon as you click Validate fix, Search Console checks a few of the URLs. If the issue is still on any of them, the run ends there and the state doesn't change.

2. Started. If the sample looks fixed, the state becomes Started. Google then rechecks only the URLs listed in that row, not your whole site.

3. A state for every URL. Each URL gets one of four states: Pending (waiting), Passed (issue gone), Failed (issue still there) or Other (Google couldn't reach the URL). Google treats Other the same as Passed.

4. Failed. If a checked URL still has the issue, the row turns Failed and the run ends. The help page also says Failed means a certain number of pages still have the issue, but it doesn't give the number.

5. Passed. If every URL is fixed, the row shows Passed. Google says validation "typically takes up to about two weeks", and in some cases much longer.

One line on that page changes how you should prepare. If a page isn't available to Google for any reason (removed, marked noindex, behind a login), Google counts the issue as fixed for that URL. So a URL doesn't have to get indexed to stop failing your validation. It just has to leave the row for a clear reason.

What I found when I sorted my own 25 URLs

On my own site, most URLs in this row should leave it on their own, and the ones most likely to fail a validation aren't pages at all.

On 2 November 2026 I opened the Page indexing report for sandipandas.dev. The "Crawled - currently not indexed" row lists 25 URLs. Its validation state is "Not Started" (I've never clicked Validate fix on it), it was first detected in February 2025, and the report's "Last update" date is 23 October 2026.

I checked each URL in a normal browser while logged out (whether it loads, where it redirects, and any robots tag), then sorted them by what they are today:

Then I ran Google's URL Inspection tool on 6 of the 25. This is Google's own data for one URL at a time, so it's the closest thing to "what Google sees":

What this told me:

• The report was behind. 3 of the 6 URLs I inspected are already indexed, but the report still lists them. Always check a few URLs in URL Inspection before you decide anything.

• Redirects should clear on their own. The tesla-electrical-company address was indexed when Google last crawled it on 25 October. Today it redirects to the new project address, so its next crawl should find a redirect, not this issue. That's my reading of Google's rules, not something I've watched happen yet.

• The two files are the real risk. A feed and an llms.txt file aren't pages people search for, and both are still in the row. If I clicked Validate fix today, these are the URLs I'd expect to keep failing it.

What I didn't test: I didn't click Validate fix, so there's no real Passed or Failed result here yet. I couldn't run a fetch with Googlebot's user agent (the name a crawler sends with each request) from my test setup today, so the Google-side check is URL Inspection only. I didn't use the live test button, and I didn't check the 3 staging URLs.

Before you click Validate fix again: sort the list

Put every URL in the row into one of five groups, and only act on the groups that need it.

Only the "real page, still not indexed" group needs work on the content itself. Everything else is either already fine or a quick setting. If your list is long and you'd rather have someone sort it with you, my team's website audit covers this report.

Two ways to keep junk URLs from failing your validation

Either validate only the pages you care about, or tell Google clearly which files aren't meant for search.

1. Validate by sitemap (no code)

Google's validation help page has a tip for this: make a sitemap (a file that lists the pages you want Google to find) with only your most important pages, filter the report by that sitemap, then click Validate fix. The validation then covers only the URLs in that sitemap at that moment, and Google says a smaller set can finish faster.

One catch: the sitemap has to list the exact addresses you use. My own sitemap lists every URL on sandipandas.dev without "www", while the site serves www. Filtering by it wouldn't match my www pages. I wrote about that problem in my Discovered - currently not indexed guide.

2. Add a noindex header to files (Next.js)

For files like a feed or llms.txt you can't add a meta tag, because they aren't HTML. Instead you send an HTTP header, a short note the server sends with the file that visitors never see. Google's robots meta tag guide says you can use the X-Robots-Tag header for non-HTML files. In Next.js, the built-in headers() setting does it for every listed path in one place:

// next.config.ts — checked on Next.js 16.4.4
import type { NextConfig } from "next";

// Files that are useful to tools and feed readers,
// but that you never want as a Google search result.
const notForSearch: string[] = ["/feed.xml", "/llms.txt"];

const nextConfig: NextConfig = {
  async headers() {
    return notForSearch.map((source) => ({
      source,
      headers: [{ key: "X-Robots-Tag", value: "noindex" }],
    }));
  },
};

export default nextConfig;

I ran this today in a small test project on Next.js 16.4.4, React 19.3.1 and TypeScript 5.9.3. next build and tsc --noEmit --strict both passed. Then curl -I showed X-Robots-Tag: noindex on /feed.xml (a route handler, which builds the file in code) and /llms.txt (a plain file in /public), and no such header on the home page. Change the list to your own file paths.

Three things to know before you use it:

• Don't also block these files in robots.txt (the file that tells crawlers where they may go). Google's guide says crawlers can only follow noindex if they're allowed to fetch the file.

• Noindex doesn't lock the file. It only asks search engines not to list it. Feed readers and tools can still open it.

• Leaving them alone is fine too. Google says not to expect every URL on your site to be indexed. Option 1 is enough if you'd rather not touch code.

To be fair to you: my own site doesn't send this header yet. Both files are served without it today.

If it already failed: how to restart

Deal with the URLs that failed, then restart from the validation log. Don't keep clicking Validate fix.

1. Open the "Crawled - currently not indexed" row and click See details to open the validation log.

2. Look at the URLs marked Failed. Put each one into a group from the table above.

3. Fix the real pages, let redirects be, and add noindex or a login to anything that shouldn't be in Google.

4. Check a few of those URLs in URL Inspection.

5. Click Start new validation.

Google's help page says a restart rechecks URLs marked Pending or Failed, plus new ones found since the last run. URLs marked Passed or Other aren't checked again. It also says to wait for one run to finish before you start another.

And remember, validation is optional. Google updates the count whenever it recrawls a URL, whether you asked for validation or not. For a row whose Source is "Google systems", I'd treat the button as a progress tracker, not a fix.

What's easy to get wrong

• Reading "Failed" as "my fix is broken". For this row, it often just means Google still isn't indexing some URLs.

• Validating with feeds, staging pages and search-result URLs still in the list. These can fail the run for reasons that have nothing to do with your real pages.

• Trusting the report's date. In my test, half of the URLs I inspected were already indexed. Check single URLs before you act.

• Blocking a file in robots.txt and adding noindex. Google can't see the noindex if it can't fetch the file.

• Clicking Validate fix again while a run is going. Google asks you to wait until it passes or fails.

• Expecting every URL to be indexed. Google says plainly that this isn't the goal.

For this row, "Failed" usually means Google hasn't changed its mind yet, not that your fix is broken.

Read next

• How to fix "Crawled - currently not indexed", the main guide for this row

• Discovered - currently not indexed: why, and how to fix it

• Google Search Console SEO audit: five reports, in order

• Free SEO checker for a quick look at any single page

• Technical SEO services

If you'd rather have someone do this

I've been building and fixing websites since 2017, and Search Console clean-ups are part of my team's technical SEO work. If you'd like my team to sort your list, fix what can be fixed and run the validation for you, book a short call and we'll take a look together.