The Pre-Launch Website Testing Checklist (And What Breaks Anyway)

Almost every launch goes the same way. The site works perfectly on your machine. You click through it one last time, everything's smooth, you ship. Twenty minutes later someone in Slack posts a screenshot: the signup button does nothing on their phone.

It worked for you because you tested the path you built. Your first real users test the paths you forgot.

This is a checklist for the second kind of testing: the stuff that breaks in production even though it looked fine in dev. It's not a generic "did you proofread the footer" list. It's the failures we watch slip through over and over, grouped by where they hide.

Why most launch checklists don't help

The problem with the average pre-launch checklist is that it tests the happy path. Load the homepage, check the logo, read the headline, click the main CTA, done. But the happy path is the one part of your site you've already clicked a hundred times. It's not where the bugs are.

Real breakage lives in the places you rarely visit on purpose: the second step of a form after you've already entered a bad email, the page you renamed last week that three other pages still link to, the mobile layout you glanced at once in Chrome's device toolbar and assumed was fine. Those don't show up when you click through your own demo flow, because you don't naturally do the things that trigger them.

So the goal here isn't "look at every page." It's "deliberately do the things that break."

Before you start: test like a stranger

One mindset shift makes this whole checklist more effective. Open the site in a fresh, logged-out browser (incognito, no saved passwords, no autofill, no memory of how it's supposed to work). You want to hit the site cold, the way someone who found you from a tweet would.

You'll be surprised how much breaks the moment you stop unconsciously avoiding it.

1. Navigation and links

This is the cheapest, highest-frequency category of breakage, and it's almost always invisible until someone clicks.

• Every internal link resolves. Renamed a route, deleted a page, restructured your docs? Something still links to the old URL. The footer is the usual suspect, because it's on every page and nobody re-checks it after a rename. (We wrote a whole piece on why broken links quietly kill trust if you want the long version.)
• Old URLs redirect. Updating the new links isn't enough. Bookmarks, backlinks, and search results still point at the old paths. No redirect means a 404 for everyone who saved your page.
• The nav works on mobile. A hamburger menu that doesn't open, or opens and won't close, strands every phone user at the front door.
• Outbound links still go somewhere. Other people's pages disappear without telling you. A dead link to a partner or a doc makes your site feel abandoned, even though the breakage is theirs.

2. Forms

If your site has a signup, contact, or checkout form, that form is your business. It's also where the nastiest bugs hide, because forms have state and state is where things go wrong.

Don't just submit a valid form once and move on. Try to break it:

• Submit it empty. Do you get a clear error, or does it silently do nothing? Silence is the worst answer; the user thinks they clicked wrong and tries again, then leaves.
• Submit garbage. A bad email like name@, mismatched passwords, a phone number with letters. Plenty of forms happily accept asdf@asdf and then bounce the confirmation email into the void.
• Submit twice, fast. Double-clicks create duplicate accounts and duplicate charges more often than you'd think.
• Watch the submit button. Does it ever re-enable after an error? A button that goes disabled and stays disabled is a dead end the user can't escape.

3. Mobile

Most of your traffic is on a phone, and mobile is where "looked fine in dev" goes to die. Checking it in a desktop browser's responsive mode is not the same as a real device; touch, real viewport sizes, and font rendering all differ.

On an actual phone, look for:

• Horizontal scrolling. If you can swipe the page sideways, something is overflowing. It's the clearest sign of a broken layout and it looks instantly amateur.
• Tap targets that are too small or overlap. Two buttons a thumb-width apart means people tap the wrong one.
• A primary CTA that got pushed below the fold or buried under a sticky banner. On desktop it's front and center; on mobile it's three scrolls down.
• Text you have to pinch to read.

4. Stability and the unhappy path

The happy path works; you've proven that a hundred times. The question is what happens when something goes slightly wrong.

• Empty states. What does an empty search, an empty cart, or a brand-new account with no data look like? Too often it's a blank screen with no guidance, which reads as "this is broken."
• Error states. Kill your network for a second mid-action. Does the app tell the user what happened and how to recover, or does it just freeze?
• Loading that never ends. Spinners that spin forever on a slow connection are one of the most common "is this thing on?" failures.
• Crashes and blank renders. A page that loads to a white screen because of one JavaScript error takes the whole experience down with it.

5. The boring-but-fatal stuff

The unglamorous checks that quietly torpedo launches:

• No placeholder text, lorem ipsum, or "Coming Soon" pages left in production.
• No broken images (the little gray box screams "unfinished").
• Page titles and meta descriptions are real, not the framework default.
• The site loads fast enough that people don't leave during the load.
• It works in more than one browser. Safari in particular has opinions.

The copy-paste checklist

Here's the condensed version to run before every launch, and before every meaningful release after, because all of this breaks again the moment you change routing or ship a new feature:

• Every internal link resolves; no 404s
• Old URLs redirect after any rename or migration
• Mobile nav opens and closes
• Forms reject empty and invalid input with clear errors
• Submit buttons recover after an error; no duplicate submits
• No horizontal scroll on mobile; CTAs visible; tap targets usable
• Empty and error states guide the user forward
• No infinite spinners, crashes, or blank screens
• No placeholder text, broken images, or default meta tags
• Works in Chrome and Safari, desktop and phone

What we see break most often

If you only have time for three checks, make them these; they're the failures that show up again and again when sites get scanned:

1. A broken link on a high-intent page (pricing, signup, checkout). Highest cost, because it stops someone who was about to convert.
2. A form that accepts invalid input. It looks like it works, which is exactly why it survives to production. The damage shows up later as bounced emails and bad data.
3. A mobile layout that breaks the primary action. The button works on desktop, so it passes the founder's click-through, and fails for the majority of actual visitors.

None of these are exotic. That's the point: the things that break launches are mundane, which is why manual click-throughs miss them and why they're worth checking deliberately.

Manual vs. automated pre-launch testing

You can do everything above by hand, and for a small site you should at least once; there's no substitute for clicking through your own product with fresh eyes. The catch is that it's slow, it's easy to skip a step when you're tired and it's launch night, and you have to redo the whole thing every time you ship.

That's the gap automated testing fills. A scanner can walk every page, follow every link, poke at every form, and check mobile and stability the same way every time, in a couple of minutes. It won't tell you whether your copy is persuasive, but it will catch the mechanical breakage (the dead links, failing forms, dead buttons, and crashes) that makes up most of what actually goes wrong. Pair it with a human pass on the judgment calls. (For the broader version of this, see our Website UX Audit Guide.)

That's the half HowsMyApp automates: point it at your site and it drives a real browser through it like a user would, then hands back every broken flow with a screenshot of exactly what went wrong.

Frequently asked questions

How long before launch should I run this? Early enough to fix what you find. A day before is fine for a quick automated pass; if you're testing manually, give yourself a buffer, because you will find at least one thing.

Do I need a QA person to do this? No. The highest-value checks here (broken links, failing forms, dead buttons, mobile breakage) are objective. You don't need QA expertise to notice a button that does nothing or value the fact that it's on your signup page.

We already have automated tests. Isn't that enough? Unit and integration tests check the logic you thought to test. They rarely catch a layout that overflows on mobile, a link that rots after a rename, or a spinner that hangs on a slow connection. Those are exactly the production-only failures this checklist targets.

How often should I re-run it after launch? Every release that touches routing, forms, or layout, which is most of them. A site that's clean today is one refactor away from a broken link tomorrow.

The short version

You can't test your way to a perfect launch, but you can rule out the embarrassing failures. The pattern is always the same: the bug that reaches your users is the one you didn't think to check, on the device you don't use, in the state you didn't expect. Go do those things on purpose, before someone in Slack does it for you.

---

Want the mechanical half done in two minutes? Run a free scan with HowsMyApp. It walks your site like a real user and flags broken links, dead buttons, failing forms, mobile issues, and crashes, each with a screenshot, before you ship.