# Search Console 'Validate fix' vs SEOFix Verify fix: what each actually checks

> Search Console's Validate fix waits on Googlebot and can take two weeks. Verify fix refetches your pages in seconds. What each checks, and when to use both.

Source: https://seofix.ai/blog/search-console-validate-fix-vs-verify-fix  
Published: 2026-10-18  
Updated: 2026-10-09  
Author: SEOFix Team  
Category: Guides  
Tags: Technical SEO, Guides  
Length: 2,182 words, 10 min read

Search Console's **Validate fix** asks Google to recrawl the URLs it knows have an issue and reports when Googlebot no longer finds it. Google says this ["typically takes up to about two weeks, but in some cases can take much longer"](https://support.google.com/webmasters/answer/9216203). SEOFix's **Verify fix** refetches up to 200 of a task's affected URLs with our crawler right after you deploy and reruns the same checks, usually in seconds. The two answer different questions. Verify fix tells you whether the HTML your server returns is fixed. Validate fix tells you whether Google has seen that and updated its records. Use Verify fix first, then start Validate fix once it passes.

The rest of this post goes through what each one checks, what the states mean, why Google's takes weeks, and the order we run them in.

**Disclosure:** SEOFix is our product. Google's behaviour below comes from the Search Console help center, checked on 8 October 2026.

## What Search Console's Validate fix does

Validate fix is a button on an issue in the Page indexing report and the other issue-based reports. Clicking it tells Google you believe you've fixed every instance of that issue. Google's [validation help page](https://support.google.com/webmasters/answer/9216203) describes what happens next, in this order:

1. **A quick spot check.** "When you click Validate Fix, Search Console immediately checks a few pages." If the issue is still on any of them, "validation ends, and the validation state remains unchanged." This is why clicking too early, before your deploy is live or before the CDN cache is cleared, ends the attempt within minutes.
2. **Queueing.** Google then "works through the list of known URLs affected by this issue. Only URLs with known instances of this issue are queued for recrawling." It doesn't recrawl your whole site, only the affected URLs it already knows about.
3. **Recrawl, one URL at a time.** Each URL gets a state as Googlebot visits it. Fixed URLs become passing. A URL that is no longer reachable becomes "Other". If the issue is still present, the issue state changes to **Failed** and validation ends.
4. **New instances join the queue.** "If this is a new page discovered by normal crawling, it is considered another instance." A validation can pick up URLs you didn't know about.
5. **Result.** "When queued URLs have been checked for this issue and found to be fixed of this issue, the issue state changes to Passed."

Google also asks you not to click Validate fix again while a validation is running. Wait until it passes or fails.

### The validation states

At the issue level, from the same page:

| State | Google's definition |
| --- | --- |
| Not started | No validation attempt has been made for this issue. |
| Started | "You have begun a validation attempt and no remaining instances of the issue have been found yet." |
| Looking good | "All issue instances that have been checked so far have been fixed." |
| Passed | "All known instances of the issue are gone (or the affected URL is no longer available)." |
| N/A | The issue was fixed without a validation request. |
| Failed | "A certain threshold of pages still contain this issue, after you clicked Validate." |

Each URL inside the issue has its own state too: **Pending** ("Queued for validation. The last time Google looked, this issue instance existed"), **Passed**, **Failed** and **Other**.

Two details catch people out. "Looking good" is an in-progress state: the URLs checked so far are fine, and the rest haven't been recrawled yet. And "Failed" depends on a threshold Google doesn't publish, so one stubborn URL can fail an issue with thousands of fixed ones.

### Why it takes about two weeks

The validation is only as fast as Googlebot's recrawl of the queued URLs. Google doesn't fetch them all at once the moment you click; they go through normal crawl scheduling. How often Google revisits a page depends on the page. In its noindex documentation Google says that, "depending on the importance of the page on the internet, it may take months for Googlebot to revisit a page" ([block-indexing docs](https://developers.google.com/search/docs/crawling-indexing/block-indexing)). Add report processing on top: Google says Search Console data "should be available in 2-3 days" after it's collected ([About Search Console data](https://support.google.com/webmasters/answer/96568)).

So a validation on 40 well-linked URLs can pass in days, and one on 30,000 deep pagination URLs can sit in "Started" for a month. That's normal and doesn't mean anything went wrong.

### What it can and can't tell you

Validate fix is the authoritative answer to "has Google processed my fix?" Nothing else gives you that for a whole issue. But it has limits:

- **It's slow to tell you that you're wrong.** If the fix didn't deploy to every page, you may only find out when a URL fails days later.
- **It doesn't tell you why.** A failed URL means Google still saw the issue. It doesn't show what HTML or status code Google got.
- **It covers the issues Google reports.** The Page indexing report lists reasons like "Not found (404)", "Server error (5xx)", "URL marked 'noindex'" and "Duplicate, Google chose different canonical than user" ([Page indexing report](https://support.google.com/webmasters/answer/7440203)). It won't flag a title template that cuts off at 74 characters or a missing H1.

For a single URL, URL Inspection's **Test live URL** fetches the page in real time, but Google notes it ["does not test for all possible indexing issues"](https://support.google.com/webmasters/answer/9012289). **Request indexing** queues a recrawl, with "a daily limit to how many index requests you can submit", and indexing "can take much longer" than a day in some cases (same page). Both are fine for five URLs and useless for five thousand.

## What SEOFix Verify fix does

Verify fix answers a narrower question, straight after the deploy: is the issue gone from the pages that had it? From the [Verify fix help page](https://seofix.ai/help/verify-fix):

- It refetches **only the task's affected URLs, up to 200**. A task with more pages is sampled: the 200 with the most Search Console clicks, then URL order.
- It uses the same crawler and user agent as a full audit, fetches each URL once and doesn't follow links.
- It reruns the response checks (`BROKEN_PAGE`, `SERVER_ERROR`, `FETCH_FAILED`, `BLOCKED_BY_FIREWALL`, `PRIVATE_ADDRESS_SKIPPED`), every on-page check (title, meta description, headings, canonical presence, `NOINDEX_PAGE`, Open Graph, images, mixed content, JavaScript redirects, size, response time, structured data syntax) and the three duplicate checks, comparing each rechecked page with the rest of the site's latest full audit.
- It costs 1 credit per URL fetched. Credits are reserved up front and anything not fetched is refunded.
- It needs a verified site, runs at no more than 2 requests per second (or your site's lower speed setting), and stops fetching after 120 seconds. Up to 30 rechecks per hour per team.

In the app it's the "Verify fix" button on a task. An agent calls `verify_fix` over MCP, or `POST /v1/sites/{id}/recheck`:

```bash
curl -s -X POST "https://api.seofix.ai/v1/sites/42/recheck" \
  -H "Authorization: Bearer $SEOFIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"task_key": "3f9c2a71b0d4e8a6"}'
```

### What it can't verify

Anything that depends on the whole site needs a full audit: the internal link graph, sitemaps, orphan pages, robots.txt, canonical and redirect targets, hreflang, external links and changes between audits. Those tasks show `recheckable: false`. The app says "Re-verified at the next full audit" instead of offering the button, and the API answers `422 cannot_verify`. The same goes for the `INDEX_*` tasks built from Google's own indexing data. Only Google can say those are fixed, which is what Validate fix is for.

### The results

Per task, Verify fix returns one of four results:

| Result | Meaning | Task status after |
| --- | --- | --- |
| `fixed` | Every rechecked URL was checked and none has the issue. | fixed |
| `still_failing` | At least one URL still has it. | open |
| `not_checked` | Nothing failed, but some URL couldn't be checked (timeout, firewall challenge, non-HTML answer). | open |
| `cannot_verify` | A recheck can't judge this code, or the duplicate baseline was missing. | open |

Each URL also gets its own result, including `new_issue`: the original issue is gone but the page now has errors or warnings the last audit didn't record. That's how you catch a title fix that also dropped the canonical.

## Side by side

|  | Search Console Validate fix | SEOFix Verify fix |
| --- | --- | --- |
| Question it answers | Has Google recrawled the pages and stopped seeing the issue? | Does the live HTML still have the issue? |
| Who fetches | Googlebot, on its normal crawl schedule | SEOFixBot, immediately |
| Which URLs | All known affected URLs, plus new instances found during the validation | Up to 200 affected URLs (top by Search Console clicks when sampled) |
| Time | "Up to about two weeks", sometimes longer | Seconds; fetching stops at 120 seconds |
| Issues covered | Google's report issues (indexing reasons, enhancements) | SEOFix's page-level check codes; site-wide codes need a full audit |
| Cost | Free | 1 credit per URL fetched |
| Tells you why a URL failed | No | Yes: the status code, the failing check and any new issues |
| Changes Google's index | Indirectly, by queueing recrawls | No |

## When to use which (the answer is both)

Here's the order we use on our own sites:

1. **Deploy the fix and purge the CDN cache** for the affected paths. Google's spot check and our recheck both see what the cache serves.
2. **Run Verify fix.** If it says `still_failing`, look at which URLs fail. It's usually a second template, a cached page or a code path for a subset of records (jobs without a company name, products without a price). Fix, deploy, verify again. Each round takes seconds and costs at most 200 credits.
3. **When the task is** **`fixed`****, start Validate fix in Search Console** for the matching issue, if Google reports one. Now Google's spot check passes, and the recrawl confirms what you already know.
4. **Leave it alone for two weeks.** Don't click Validate fix again. If you need a few important URLs picked up sooner, use Request indexing on those only.
5. **Measure.** Verify fix records a fix event, and SEOFix compares the affected pages' Search Console clicks at 7, 14 and 28 days against the 28 days before ([traffic from fixes](https://seofix.ai/help/traffic-from-fixes)). Without Search Console data the result is "no data", never zero.

The point of step 2 is to stop a broken fix before it costs you two weeks. Google's spot check only looks at "a few pages". A fix that works on those and misses a code path will pass the spot check and fail days later.

Going the other way doesn't work as well. Starting Validate fix first and waiting tells you, a week or two later, that something is still wrong, and then you need a crawler anyway to find out what.

### Mapping the issues

Most Page indexing reasons have a page-level counterpart you can verify immediately:

| Search Console issue | SEOFix check | Verify fix? |
| --- | --- | --- |
| Not found (404) | `BROKEN_PAGE` | Yes |
| Server error (5xx) | `SERVER_ERROR` | Yes |
| Blocked due to access forbidden (403) | `BLOCKED_BY_FIREWALL` (challenge pages), `BROKEN_PAGE` | Yes |
| URL marked 'noindex' | `NOINDEX_PAGE` | Yes |
| Redirect error | `REDIRECT_CHAIN`, `REDIRECT_LOOP` | No, full audit |
| URL blocked by robots.txt | `ROBOTS_BLOCKED` | No, full audit |
| Duplicate, Google chose different canonical than user | `CANONICAL_MISSING`, `DUPLICATE_CONTENT` | Yes |
| Crawled / Discovered, currently not indexed | `INDEX_*` triage tasks | No, only Google can confirm |

The mapping is loose. Google's "Duplicate, Google chose different canonical" is Google's judgement about your pages, and a passing `CANONICAL_MISSING` recheck only proves the canonical tag is there. For those, Verify fix checks your side and Validate fix checks Google's.

## Common problems

**Validation failed straight away.** The spot check found the issue on one of "a few pages". Check that the deploy is live on every server and that the CDN isn't serving old HTML. Run Verify fix or `curl` a few affected URLs before you try again.

**Verify fix passes, Validate fix fails.** Googlebot and our crawler got different responses. The usual causes: a firewall or bot-management rule that treats Googlebot differently, dynamic rendering that serves bots another template, or a URL Google knows about that isn't in your latest audit. Inspect a failing URL in Search Console and compare its crawled HTML with what Verify fix fetched.

**Verify fix says** **`not_checked`** **with reason** **`blocked`****.** A firewall challenge answered instead of your page. Allowlist SEOFixBot ([firewall allowlisting](https://seofix.ai/help/firewall-allowlisting)) and recheck. If the same rule challenges Googlebot, that is the bigger problem.

**Validation stuck on "Started" for weeks.** It's waiting on Googlebot. Large issues on low-priority URLs take longest. Request indexing on the most important URLs and leave the rest.

## FAQ

**Does clicking Validate fix make Google crawl faster?** It queues the affected URLs for recrawling, but they go through Google's normal scheduling. Google's own estimate is "up to about two weeks".

**Can I use Verify fix without Search Console?** Yes. It needs a verified site (DNS, meta tag, file, Cloudflare or Search Console) and credits. Search Console only decides which 200 URLs are picked when a task is sampled, and makes the traffic measurement possible.

**Should I validate every issue in Search Console?** Only issues you've fixed and want confirmed. Issues that describe pages you intend to exclude, such as noindexed search results, don't need validating.

---

Run Verify fix on your own deploys: the first audit is free (up to 500 pages), and the [Verify fix guide](https://seofix.ai/help/verify-fix) covers the API and MCP calls.