Most launch-day bugs aren’t exotic. They’re an enquiry form that sends to the old inbox, a menu that doesn’t open on one phone, a “thank you” page that 404s. They slip through because nobody went through the site in a structured way before it went live.
This is the checklist I work through before a website launch, in the order that finds the most important bugs first.
1. The key journeys, end to end
Start by listing the three to five things a visitor must be able to do: send an enquiry, book a call, buy a product, sign up, log in. Then do each one completely, as a first-time visitor would, from the page where they’d start to the email they’d receive at the end.
- Does every step work, and does the journey end where it should?
- Does the confirmation (page, email, account) actually arrive?
- Try the journey again as a returning visitor or logged-in user.
2. Forms and emails
Forms deserve their own pass, because every form is a small program with inputs:
- Submit it empty. Are the error messages clear, and next to the right field?
- Try wrong formats: an email without “@”, a phone number with spaces, a very long name.
- Try names with accents, apostrophes and hyphens.
- Submit twice quickly. Do you get two enquiries?
- Check that the notification reaches the right inbox and doesn’t land in spam.
3. Browsers and real phones
Resizing a desktop browser isn’t the same as a phone. Test the key journeys on at least one real iPhone and one real Android device, plus current Chrome, Safari and Firefox on desktop. Watch for:
- Menus, pop-ups and cookie banners covering buttons
- Sticky headers hiding form fields when the keyboard opens
- Tap targets too small or too close together
- Horizontal scrolling on narrow screens
4. Content and links
- Placeholder text, “lorem ipsum”, test products and staging URLs
- Broken links and links pointing at the staging domain
- Phone numbers and email addresses that should be clickable
- Page titles and the social sharing preview of the homepage
- Legal pages: privacy notice, cookie information, company details
5. The basics of accessibility
This isn’t a full audit, but it catches the most common problems in minutes:
- Go through a key journey using only the keyboard. Can you see where the focus is?
- Do form fields have visible labels, not just placeholder text?
- Is text readable against its background, including text on images?
- Do images that carry meaning have alternative text?
6. What happens when things go wrong
Finally, try the unhappy paths: a page that doesn’t exist, an expired link, a slow connection (your browser’s developer tools can simulate one), the back button in the middle of a form, refreshing on a confirmation page. A site that fails politely keeps visitors; one that fails with a blank page loses them.
Write down what you didn’t test
No pre-launch test covers everything. The last step is a short note of what was tested, on which devices, and what wasn’t. It turns “we tested it” into a decision the whole team can stand behind.
Frequently asked questions.
How long does pre-launch testing take?
For a typical business website with a handful of key journeys, one to two days of focused testing is usually enough to find the bugs that matter. Web apps and shops with accounts, roles or payments need more.
Should I test on staging or production?
On staging whenever possible, with test accounts and test payment details. After launch, repeat a short smoke test on production to confirm the live configuration: emails, payments, analytics and redirects.
Which devices should I test on?
Check your analytics for the most common browsers and phones. Without data, a sensible minimum is current Chrome, Safari and Firefox on desktop, plus one real iPhone and one real Android phone.
