Is the site ready to go live? A pre-launch testing checklist for your company

"Is the site ready?" usually gets a subjective answer: it looks fine. Testing replaces that feeling with a list of tests actually run, each with a result and an owner, and with a clear line between defects that block publication and ones that get fixed afterward. It serves the company as much as the vendor, because it closes the project without an endless tail of reported issues.

It isn't a design review. It doesn't debate whether you like the color: it verifies that the paths work, that the content is accurate, and that requests reach their destination.

Test paths, not pages

Opening every page one by one gives a false sense of security: pages can look fine while paths break. A path is a sequence a real visitor actually goes through.

• I search your name, land on the homepage, look for a service, read the listing, ask for information.
• I arrive on an internal page from a link I received, without going through the homepage: do I understand where I am and how to proceed?
• I want the phone number from my smartphone: how many taps does it take to find and dial it?
• I'm a customer looking for support or the private account area.

Every path needs to be tested on at least one real phone and one computer, not just by narrowing the browser window. The phone has a keyboard covering half the screen, a finger as wide as ten pixels, and a connection that's sometimes not there: three things you don't see on an office monitor. Test with a slow connection too, and with the phone turned sideways.

The test report

A bare-bones but sufficient tool: a table with one row per test. It avoids the most common end-of-project argument, "we said this" versus "it wasn't in scope." A few example rows follow.

The columns that matter are the last two. A test round with no name next to each row doesn't get done: it gets postponed until someone decides to publish anyway.

Content, links, and where requests end up

The least technical part is the one that causes the most embarrassment, because it concerns what the company says about itself.

• Placeholder text left on the page, generic images instead of your own, names of people who no longer work with you.
• Contact details, hours, and company data: these need to be read by someone who knows them, not by whoever laid out the page.
• Downloadable documents: that they're the latest version and don't contain price lists or data you don't want public.
• Internal and external links: the ones pointing to third-party sites need to be retested, because an external site may have changed address while you were working.
• Where requests end up: every form can write to a different inbox. Test all of them, one by one, checking spam too.
• Legal text and disclosures: these aren't filler content and don't get copied from another site.

The house keys: access, backups, restoring

Before launch, it's worth clarifying who owns what. Right now it costs little; three years from now, with a different vendor, it can block an entire project.

• The domain registered to the company, with access to the management panel in your hands.
• Access to the site, to the hosting space, and to the measurement tools, existing also in the name of someone internal and not only the vendor.
• If backups are provided for: where they are, how often they're made, how far back they go, and — the question no one asks — who has already tested restoring one.

A backup that's never been restored is a hypothesis, not a guarantee. The test is done once, on a working copy, before you actually need it.

Blocking or deferrable

Not every defect blocks publication, and treating all of them as urgent pushes the date back for no reason. Three levels are enough.

1. Blocking: the site states something false, a request doesn't arrive, an important page won't open, private data is visible, a contact or purchase path breaks. You don't publish.
2. To fix right after: visible defects that don't prevent using the site, like a wrong caption, a low-quality image, spacing that's off on a specific phone model.
3. To be assessed: requests that came up during testing but are actually new content or features. These get written down and discussed, not slipped into the launch.

The third item is the one that saves the project. Most delays come from new requests presented as defects.

When you don't publish, and when you publish anyway

What this guide doesn't cover

This guide covers accepting a site before it launches. Testing a business management process — migrated data, permissions, procedures that replace a way of working — follows different rules and requires tests on real data, not a test environment. Accessibility checks and gathering requirements before starting are also covered elsewhere.