How to prove a website fix worked before you send the invoice

Every agency has sent the email. "That's all sorted now." The client reads it, has no way to check it, and either takes your word for it or quietly does not. Three months later the same problem turns up in somebody else's audit, and your word is worth a little less.

"It's fixed" is a claim. The client is paying for the fix, but what keeps them paying is being able to see that the fix happened. Here is how to turn the claim into evidence.

What counts as proof

A fix is proven when the measurement that found the problem is taken again and no longer finds it. That sentence has three parts, and skipping any of them is how a recheck goes wrong.

The same measurement. If the audit found a missing DMARC record by reading DNS, the recheck reads DNS. If it found a slow page in a throttled mobile browser, the recheck uses the same throttling. Checking a slow page on your office broadband and declaring it fast is not a recheck; it is a different test with a happier answer.

The same threshold. The finding was raised because a reading crossed a line: a largest contentful paint over 4 seconds, a security header grade of F, an image with no alt text. The fix is proven when that line is no longer crossed. Not when the number improved a little, and not when somebody decides it is good enough.

A date. A recheck is true on the day it was taken. Write the date down, because a website changes every time somebody deploys to it, and the client will want to know that the fix held as well as that it happened.

Four honest answers

When you recheck a finding there are four possible results, and only one of them is the one you want.

1. Fixed. The rule that raised the finding no longer fires.

2. Still failing. It still fires. The reading may have improved, but it has not crossed the line.

3. Got worse. It still fires, and the reading is worse than when the problem was found. This happens more than anyone admits, usually because a second change undid part of the first.

4. Could not measure. The recheck could not take a reading at all.

The fourth deserves its own section, because it is the one most tools get wrong.

"Could not measure" is not a failure, and it is not a pass

A recheck can fail to read a site for reasons that have nothing to do with the fix. The site was down for a minute. A firewall or a bot challenge blocked the request. A DNS lookup timed out. The page took longer to load than the check was allowed to wait.

None of those tell you anything about whether the fix worked. Reporting them as "still failing" blames your work for an outage. Reporting them as "fixed" claims something you did not see. The only honest answer is that the check could not run, and that you will run it again.

This matters most in front of a client. A report that says "could not measure" and explains why is one they can trust. A report that turns every unreadable check into a green tick is one that will eventually be caught out.

The traps that make a fix look done when it is not

• Caching. A CDN, a caching plugin or the browser can serve the old page for hours after the change. Recheck from outside your own browser, and purge the cache before you do.

• DNS propagation. A new SPF or DMARC record can take as long as its TTL to be visible everywhere. Checking five minutes after publishing it can read the old record.

• The wrong page. The finding was on the mobile home page, and you checked the desktop contact page. Recheck the page the finding names.

• Your own login. Logged-in pages often skip the caching, scripts and redirects a visitor gets. Check as a visitor.

• A second change. The deploy that fixed the headers also reintroduced the old hero image. Recheck everything the deploy touched, not only the line you meant to change.

Some fixes cannot be checked from the website

A new review, a corrected Google listing or a climb in search rankings is real work, but rerunning the website checks says nothing about it. Reviews arrive when customers leave them, listings update when Google processes the edit, and rankings move over weeks. For those, show the trend over time rather than a single recheck, and say plainly that they are measured differently.

How to show it to the client

Keep it short. For each fix: what was wrong, what you changed, the date you checked it again, and the answer. Group the fixes, list anything still failing with what happens next, and leave the technical detail one click away for whoever wants it.

That list is the most persuasive thing in a monthly report, because it is the one part that cannot be read as marketing. It is also the backbone of turning an audit into a retainer: a client who can see the work happening is a client who keeps paying for it.

How SiteAssay checks a fix

In SiteAssay you pick the finding you fixed and recheck it. Only the checks behind that one finding run again, against the site's latest audit, and the new reading is judged by the same rule that raised it, so the report and the recheck cannot disagree about what "fixed" means. The answer is one of the four above, with the reading before and after.

A recheck does not spend an audit, and it is available on every plan, with a daily limit per agency. Findings that come from outside the website, such as reviews, the Google listing and keyword rankings, are not offered one, for the reason above. From the Pro plan up the result also appears in the client portal, so the owner sees it without you forwarding anything. You can start a recheck from your own code too, through the API.

Keeping clients covers the portal and progress emails, and the reports documentation covers rechecks in more detail. To see what an audit finds before there is anything to fix, run a free website audit.