Pre-launch audits are one of the first things clients ask to cut when a deadline is tight, mostly because it's hard to see the value of a step that's supposed to find nothing wrong. In practice, it's rare for us to run a thorough pre-launch audit and find nothing — there's almost always something worth fixing before real traffic hits the site.
What the checklist actually covers
Cross-browser and cross-device testing catches the most visible issues — a layout that breaks on Safari specifically, a form that doesn't submit correctly on an older Android browser, a navigation menu that overlaps content at a specific tablet width nobody tested at during development. These are the bugs that generate support tickets and lost conversions within hours of launch if they're not caught first, and they're rarely visible on whatever single browser and device the development team happened to test on day to day.
We also run a full broken-link check across the entire site, including anything linking out to external resources, and verify every form actually delivers where it's supposed to — a surprising number of “launch-ready” sites have a contact form silently failing to send anywhere, discovered only when a real customer's inquiry vanishes into nothing and nobody notices for weeks.
The less obvious checks that matter just as much
Analytics and conversion tracking verification is easy to forget and expensive to discover late — a site that's been live for a month with a broken analytics tag means a month of decisions made with no real data, which is a much harder problem to notice than a visibly broken page. We test every tracked event and conversion goal against a real, live version of the site before launch, not just the staging environment, since tracking configuration errors between environments are common.
We check meta tags, canonical URLs, and structured data across every page template too, since these are exactly the kind of thing that gets right on one template during development and quietly missed on another — a blog post template with a perfect canonical tag says nothing about whether the same is true on the product page template built by a different developer weeks later.
Why the timing matters
The value of catching all of this before launch instead of after is mostly about who's affected. A bug caught in a pre-launch audit costs the development team an afternoon. The same bug caught by a real customer costs a lost conversion, a support ticket, and in the worst cases, a customer's trust in a brand they're encountering for the first time. The audit itself typically takes a day or two — a small cost against what it's protecting against.
Building the audit into the schedule, not around it
The single biggest reason audits get skipped isn't that clients don't see the value once it's explained — it's that by the time launch week arrives, there's no slack left in the schedule to absorb even a one-day audit, let alone the time to fix what it finds. We now build the audit into the project timeline from the start, as a named milestone with its own line in the schedule, rather than an optional step squeezed in if time allows. Treating it as load-bearing from day one is the difference between it actually happening and it quietly disappearing under deadline pressure.
We also stopped running the audit against a staging environment exclusively. Staging environments drift from production in subtle ways — different caching behavior, different environment variables, sometimes even different content if a client's team has been editing the live site in parallel. We run the final audit pass against a production-identical environment, or production itself behind a password gate if the client's setup allows it, specifically to catch the environment-specific issues that a staging-only audit would miss entirely.
What we do differently for a redesign versus a net-new site
A pre-launch audit for a redesign of an existing site carries an extra dimension a brand-new site doesn't: comparing the new site against the old one's baseline, not just checking the new site in isolation. We pull the old site's key rankings, top-performing pages, and conversion-tracking setup before it goes offline, specifically so the audit can confirm the new site preserves — or improves on — what was already working, rather than accidentally regressing something that quietly performed well on the old version and nobody thought to check.
An audit doesn't need to be exhaustive to be worth doing — even a focused half-day pass against a solid checklist catches the categories of bugs that are cheap to fix before launch and expensive to discover after. The teams that skip it aren't saving time; they're just moving the cost of finding these issues onto their customers instead.
We also keep a running list of issues found in past audits across all our projects, reviewed every few months, specifically to catch patterns — if the same category of mistake keeps showing up across unrelated client builds, that's a sign to fix it upstream in how we build, not just keep catching it at the audit stage every single time. A checklist that only ever catches problems is less valuable than one that gradually shrinks because the underlying causes are getting fixed at the source.
The goal isn’t catching every possible issue — that’s not realistic on any real timeline. It’s catching the ones a real visitor would hit in their first few minutes on the site, since those are exactly the ones that shape whether that first visit becomes a second one.
