You clicked Validate Fix in the Page indexing report, the issue now says “Validation started”, and nothing has changed since. That is normal, and the state name is doing a lot of quiet work that the interface never explains.
Validation started means Google has taken the list of URLs that were affected by that issue at the moment you clicked, put them in a queue, and will recrawl them to see whether the problem is gone. It is a request for a verdict on a specific list. It is not a request for indexing, it is not a priority boost, and it does not include pages that hit the same issue after you started.
What does validation started mean?
Google’s page indexing report documentation describes the sequence, and the first step is the one nobody notices. When you start validation, Google immediately spot-checks a small number of the affected pages. If any of them still show the problem, validation ends there and the state goes to Failed, sometimes within minutes. If that quick check looks clean, the state moves to Started and the rest of the queue is worked through over days.
So a validation that fails almost instantly is telling you something useful: the fix is not live on the pages Google checked. A validation that sits at Started for a week is telling you the opposite, that the fix looked right and Google is grinding through the list.
Two sets of states run at once, which is where the confusion comes from. Each individual URL has a state, and the issue as a whole has a state.
Per URL, you get Passing, Pending, Failed, or Other. Pending means queued but not yet recrawled. Other means Google reached the page and found a different problem, which is worth opening because it is usually the more interesting one.
How long does validation take in Search Console?
Google’s answer is the one to quote, because it sets expectations honestly: validation typically takes up to about two weeks, but in some cases it can take much longer.
Two weeks. Not two days. I have watched people restart a validation three times in a week because nothing was moving, which does nothing except throw away the progress already made and start the queue again from the beginning.
There is one documented way to make it faster, and it is a good one. Validation moves at crawl speed, so a smaller list finishes sooner. If you filter the Page indexing report to a single sitemap that contains only the pages you fixed, and run validation from that filtered view, you are validating a short list rather than the whole property. On a large site that is the difference between a fortnight and a few days. It is worth building a small sitemap for exactly this purpose when you are working through a batch of fixes, and it pairs well with the bulk URL inspection tool for checking the same batch yourself while the queue runs.
Do I have to click Validate Fix at all?
No, and this is the part I find most people do not know. Google recrawls pages anyway. An issue you fixed without ever starting a validation will still clear from the report as those pages get recrawled naturally; the count drops on its own schedule. Validation does not make Google index anything it would not otherwise index.
What validation buys you is a written answer. It tells you when the fix has been confirmed on every affected URL, and it tells you loudly when it has not. On a client account that is worth having, because “the number went down” and “Google checked and agreed” are different statements and only one of them is safe to put in a report.
When I am working through indexing problems, my order is: fix, verify one page myself with the live test, then start validation and leave it alone. The live test answers within seconds whether the fix is actually live, which is the only thing that would make validation fail at the spot-check stage. Starting validation before checking a single page yourself is how you end up with an instant Failed and no idea why.
Why did my validation fail?
Because at least one URL in the affected list still had the issue when Google looked. That is the entire rule. It is not a judgement on the fix in general, and it does not mean the pages you did fix are still broken.
Open the issue, use See details, and Search Console will show you an example URL that failed along with the date it failed. That URL is the assignment. Common reasons it is still failing after a fix that you know works:
- The fix is on the template but the page is served from cache, or from a CDN that has not been purged.
- The list included URLs you did not intend to fix: parameter versions, old paginated pages, staging paths that leaked into the property.
- The page is now fine but was fetched before you deployed. Restarting validation after deployment resolves this one, and it is the only case where restarting is the right move.
- The problem was never the one the report named. Crawled, currently not indexed in particular resists validation, because there is often nothing concrete to fix; the fix is quality and internal linking, and validation on it tends to sit and then fail.
Worth ruling out before you decide a validation is stuck: the reports it depends on are themselves behind, and Search Console’s two to three day data lag makes a fix look ignored for longer than it actually was.
One last piece of housekeeping worth knowing, from the same documentation: an issue with no remaining affected URLs is kept in the report for 90 days and then dropped. So an issue that has quietly vanished from your list is not necessarily one you fixed. It may just have aged out.
Sources
- Google Search Console Help, Page Indexing report, fix validation, validation states, and issue lifetime sections
- Google Search Console Help, URL Inspection tool, live test