How We Check a Website Before It Ships

Why "it looked fine to me" isn't a QA plan

Most website problems aren't dramatic. They're small and invisible from a desk: a heading that's the wrong size on one phone, a button a screen reader can't name, a link that quietly goes nowhere, a page that scrolls sideways on a narrow screen. Nobody spots them in a demo. Your customers spot them eventually.

So we don't trust our eyes alone. Every build gets two kinds of checks: scripts that look at everything, and a person who looks at what matters.

Step 1: Everything lands on staging first

We never build on your live site. Changes go to a separate staging copy first, and nothing reaches your real domain until it passes the checks below and someone says yes. Often, that someone is you.

Step 2: The scripts

Scripts don't get bored on page 47. They check every page, every time:

• Structure: exactly one main heading per page, headings in order, page titles and descriptions in place.
• Accessibility: image descriptions, form labels, color contrast, and a name for every button and link.
• Responsiveness: nothing spills off the side of the screen, from wide desktop monitors down to small phones.
• Links: every link goes somewhere real, including the footer ones nobody clicks.
• Structured data: the code that tells search engines and AI tools who you are is valid and accurate.

Under the hood Accessibility runs through axe, the open-source engine behind the accessibility audit in Google Lighthouse. Layout checks load each page in a real headless browser and measure for sideways overflow at eight screen widths, from 2560 pixels down to phone size. Structured data gets parsed and validated rather than eyeballed. All of it runs against the published staging site, not the editor, because the editor isn't what your visitors see.

Step 3: The copy sweep

Words get their own pass. A script reads every published page for the stuff proofreading misses: leftover placeholder text from a template, British spellings sneaking onto an American business's site, business hours worded one way on one page and another way on the next, and punctuation that broke on the way in. It sounds fussy. It is fussy. It also catches things a careful person reading the page three times can still miss.

Step 4: The human check

Then a person goes through the site the way a visitor would. Does the story make sense? Does the important stuff come first? Does the form actually reach the right inbox? Does it feel like your business? A script can tell you a heading exists. Only a person can tell you it's the right heading.

Step 5: Compare before it goes live

When we update a site that's already live, we compare the staging version against your live site before publishing, so the only thing that changes is the thing we meant to change. No surprise side effects, no "why did the footer move?"

Why this is how we work now

Since March 2026 our studio runs on AI-assisted tools, and they made this level of checking practical on every project, not just the big ones (here's that story). Speed is the dividend, not the pitch. The point is that a six-page site and a sixty-page site get the same scrutiny.

It's a big part of what we mean by big-agency range with boutique attention: the kind of process you'd expect from a much bigger team, run by people who know your site by name. It's also why a migration with us ends with a full check of the live site (here's what a migration involves). And after launch, your team can fix content themselves, which is why editable sites matter.

Curious how your current site would hold up? Book a free consult and we'll take a look together. Fair warning: it's usually humbling.