Every change to the site, from a one-word copy fix to a new page, is checked before, during and after it goes live. This page explains how that works, what we look for, and what a full-site QA pass adds before launch.
Each piece of feedback, whether it comes from a feedback tool, an email or a meeting, goes through the same six steps. A change is only marked done after step 6.
The screenshot or document you send is treated as the specification. Before work starts, the ticket gets a written definition of "done": what changes, where, and how we'll prove it. If something is unclear, we ask rather than guess.
If a fix applies to one page, we look for the same pattern on every other page, so it's fixed consistently and doesn't come back as a separate ticket.
The developer measures the result at four screen sizes and takes before-and-after screenshots. They also check the WordPress editor, so what your team sees when editing matches what visitors see.
Someone who didn't build the change reviews it against the ticket's definition of done and repeats the measurements independently.
Every update runs an automated test suite before it can be released. It covers code errors, text and background colour contrast, saved-content consistency, retired-page redirects, and behaviour specific to your site.
After release, the reviewer loads the real published page, with no test settings, and confirms the change is there and nothing nearby has shifted. Only then is the ticket closed.
Layout changes are measured at each of these widths, not just looked at.
These are the areas we check, both on individual changes and across the whole site.
Ticket-by-ticket checks cover what each change touched. Full-site QA steps back and goes through every published page as a whole:
Some outside websites block automated tools. When a site blocks them, for example some government sites, a team member checks those links by hand.