How to verify fixes
Four ways to check whether a fix worked, from a single finding to a full audit, and what each one does NOT verify.
You fixed a finding from the report and want to know whether it worked. We have four ways to check, from cheapest to most expensive, and they differ in WHAT exactly they verify. This page says when to use which, and more importantly what each one does NOT verify, so none of them looks like more than it is.
This holds for all four the same way: “fixed” here always means one thing only, that our check no longer reports the finding on a freshly downloaded page. It never means your site is now better visible in AI search (no check promises that, see each code's manual page), and except for the full audit it does not mean the score moved either.
Four levels
| Level | What it verifies | What it costs |
|---|---|---|
| Verify fix of a single finding | one rule on one page | 30 free/ |
| Verify a group | one rule on ALL pages of the group | same daily allowance as above, price shown before sending |
| Verify run | a fresh crawl of the whole site, deterministic checks only | 3 runs per baseline free/30 days, then 1 + 1 credit/100 baseline pages |
| Full audit | everything, including the model, Chromium and the score | by plan and scope, see pricing |
The rule for choosing is simple: start from the cheapest and move up only when the cheaper one cannot do what you need. Fixed one specific finding on one page? The first level is enough. Fixed the same thing across every product card at once? The second. Went through a round of fixes across the whole site and want an overview without paying for a full audit? The third. Need a new score, or confirmation about a model recommendation, accessibility, colours or speed? Only the fourth can do that.
1. Verify fix of a single finding
The “Verify fix” button sits right next to the finding in the report (docs/). On click we re-download JUST that one page and run JUST that one rule. The result is one of three: fixed (the check no longer reports anything), still present, or page unreachable (timeout, server error).
The first 30 checks per audit per day are free, 1 credit each beyond that, with a hard cap of 100 per audit per day. The same rule on the same page can run again no sooner than 1 minute after the previous attempt, protecting the server we are repeatedly downloading from.
It only works for deterministic rules that can be honestly verified over ONE re-downloaded page: in practice ACC-, STR-, SCH-, SIT-, AUTH- and SEO- codes whose check runs at page level. What this level cannot verify at all:
- Recommendations from a language model (
LLM-). They did not come from a measurement but from a reading: only the next audit verifies them, not a re-download of one page. - Checks that span the whole site, even when the report attaches them to a page: a duplicate title (
STR-03), an orphan page (SIT-01), duplicate schema (SCH-02) or pages outside the sitemap (SEO-03/SEO-05/SEO-12). Over one page such a finding would come back as fixed even if the problem still existed across the rest of the site, and that would be an untrue claim about your site, which we do not make. The button never appears for them. - Anything that needs Chromium: accessibility (
A11Y-), colours (COLOR-) or page speed (SEO-20,SEO-21). Those checks run through a browser, not over bare HTML, and the first version of verification does not launch one. The button does not appear for these either.
2. Verify a group
The same mechanism as above, just over ALL pages one code concerns at once (docs/, 2026-10-08 addendum). The “Verify fix on all N pages” button sits on the finding group's header, no need to expand it.
It draws on the SAME daily allowance as the single-finding check above: there is no separate free batch on top. Before sending, you see the price (how many pages are free, how many are charged, how many are skipped because of the cap), and a non-zero price asks for confirmation separately. One click handles at most 300 findings of a group at a time.
The exact same limits apply as to the single-finding check above: no LLM-, no checks that span the whole site, nothing that needs Chromium.
3. Verify run
A new, cheap audit (docs/) tied to one older audit of the same project, its baseline. Unlike the two levels above it crawls the whole site again, not just the pages with findings, so it also sees newly arisen problems and new pages. But it only runs the deterministic modules that finished in the baseline (crawl, AI-access check, and SEO if the baseline had it); no language model, no Chromium, no file generators run.
The baseline must be a finished REGULAR audit (not another verify run) of the same project, at most 60 days old, and even a free audit can serve as the baseline.
Price: the first 3 verify runs per baseline within 30 days are free, then 1 credit + 1 credit for every started 100 pages of the baseline. Example: a 20-page site costs 2 credits, a 200-page site 3, a 1000-page site 11. Its own cap is 6 runs per project per 24 hours; it does not share the general per-project audit cap, because a verify run needs a finished baseline and therefore cannot create an infinite loop by itself.
The result is a comparison against the baseline in five classes: fixed (the page is still in the crawl, responded, the check ran and the finding is gone), still present, new (on a page from the baseline, or on a page the baseline did not have), unverified (always with a reason: the page now errors, redirects, is disallowed in robots.txt, was out of the crawl's reach, or the check simply did not run this time; never counted as fixed) and not verified by this run, meaning findings from modules the verify run does not launch at all.
What a verify run never verifies: content recommendations from the language model (LLM-), accessibility, colours, design, page speed (Core Web Vitals) or AI citations; all of those only run through a full audit. It does not recompute either the overall score or the SEO score (the report shows a dash with a link to the baseline's score for those); the four deterministic categories (access, structure, schema, authority) it does, because they are computed with the same function as in the baseline. It produces no new downloadable files (llms.txt and similar rest on the language analysis a verify run does not run) and no PDF.
4. Full audit
The only level that runs EVERY module in your plan, including the language model, Chromium (accessibility, colours, design, speed) and AI citations, and the only one that recomputes the score. When you need a new number at the top of the report, or confirmation that a model recommendation or an accessibility finding improved, there is no way around it.
What each level verifies
| What is verified | Single finding | Group | Verify run | Full audit |
|---|---|---|---|---|
Deterministic finding ON A PAGE (ACC-/STR-/SCH-/SIT-/AUTH-/SEO- at page level) | yes | yes (whole code) | yes | yes |
Deterministic check ACROSS the site (STR-03, SIT-01, SCH-02, SEO-03/05/12…) | no | no | yes | yes |
Recommendation from a language model (LLM-) | no | no | no | yes |
| Accessibility, colours, page speed (Chromium) | no | no | no | yes (by plan) |
| Score recomputed | no | no | no (only 4 deterministic categories) | yes |
How to read the word “fixed”
All four levels follow the same rule (CLAUDE.md “do not lie to the customer”): “fixed” means our check no longer reports the finding on a freshly downloaded page, nothing more. It never means the page is now better visible in AI answers: no individual check promises that either (see each code's manual page), let alone a mechanism that merely repeats the same measurement.
Nor does it mean a higher score: except for the full audit, none of these levels recomputes the score. It is a snapshot of the audit it belongs to; only a new full audit gives you a new number.