Launch day is the cleanest your site will ever be, unless you keep checking it. From the moment the client's team gets editor access, it starts to change. New pages, new posts, swapped images, edited links. Each change is small and well-meant. Together, they add up.
Six months later, the site that passed every check at launch has a broken link in the footer, a blog post with a skipped heading and an image with no alt text. Nobody broke it. It just drifted.
Where post-launch issues come from
- New content: posts and pages added by people who weren't part of the build, without the same checks.
- Ageing links: external pages move or disappear. A link that worked at launch can be dead a few months later.
- Edited templates: a quick change to a shared component can affect every page that uses it.
- Leftover drafts: a page duplicated as a starting point, published with filler copy still in it.
A simple schedule
You don't need to check constantly. You need to check at the moments things are most likely to have changed.
Regular post-launch QA is useful work that clients rarely think to ask for. Offering it as part of a care plan keeps the site in good shape and gives you a reason to stay in touch.
Post-Launch QA
5 checksHelp the client's team check their own work
The people adding content after launch usually aren't web specialists. A short checklist for editors goes a long way: check new links work, add alt text to images, use headings in order, don't leave any filler text in a page you've duplicated.
It won't catch everything, but it raises the floor. And it gives the client's team a sense of ownership over keeping the site in good shape.
Know when to rebuild
Post-launch QA also tells you something useful over time. If the same issues keep appearing in the same places, the problem is usually structural: a template that's too easy to break, a component that invites mistakes, a CMS field that should be required. Fixing the cause is cheaper than fixing the symptoms every month.
And if a site has drifted so far that every scan turns up dozens of issues, that's a conversation worth having with the client about a refresh.
Keep the launch-day scan as a baseline. Every later scan can be read against it, so drift shows up as a clear change rather than a vague feeling that things have slipped.
Every plan includes unlimited scans, so checking the live site after a content update costs nothing extra. And because every scan is kept on the project, you can compare against launch day and see exactly what's drifted. Get started with Frank →
Keep It as Clean as Launch Day
Run your QA again after launch, and the site stays the one you handed over.
