Website Testing Checklist Before Launch

Before a new website goes live, test that it works for real visitors on the browsers and phones they use, that every form, email and payment reaches the right place, that it is usable with a keyboard and readable on a small screen, that it loads quickly, that no links are broken, and that security headers and analytics are in place. A one-day test pass against a written checklist catches most of the problems that customers would otherwise find for you.

This checklist is for business owners, marketers and project managers signing off a new site or redesign. It covers quality assurance (QA): does the site work? Search engine settings such as redirects, sitemaps and indexing are a separate job, covered in my website launch SEO checklist.

#Why test before launch

Launch-day bugs cost more than they look. A contact form that silently fails loses every enquiry until someone notices, often weeks later. A checkout that breaks on one phone browser loses sales from everyone on that phone. And first-time visitors who hit a broken page rarely come back to try again.

Testing is not about distrusting your developer. Anyone who builds a site sees it on their own screen, in their own browser, with test data. QA is the step that looks at it the way customers will: on other devices, with real details, in the wrong order, on a slow connection.

The order matters, because some checks depend on others:

#Browsers and devices

Test on what your visitors use, not on what the team uses. If you are replacing an old site, its analytics shows the real split of browsers, devices and screen sizes. For a new business, cover the main mobile and desktop browsers at minimum.

Use real phones for at least one Android and one iPhone. Browser tools that imitate a phone are useful, but they miss touch behaviour, on-screen keyboards covering form fields and real network speed.

#Forms and emails

Forms are where websites lose the most money quietly. Test every form on the site, not just the main contact form.

1. Submit each form with real-looking details, including one with a long name and an international phone number.
2. Submit with required fields empty and with a badly formatted email, and check the error messages are clear and point to the field.
3. Confirm the notification email arrives in the right inbox, not in spam, with all the fields included.
4. Confirm any auto-reply to the customer arrives and reads correctly on a phone.
5. If forms feed a CRM or spreadsheet, check the record arrives with the right source and owner.
6. Check the spam protection blocks junk without blocking real people.

If notification emails land in spam, the cause is usually email authentication. Google's sender guidelines require every sender to Gmail to set up SPF or DKIM for the sending domain and to use TLS. A site that sends mail directly from the web server often fails these checks, which is why a proper SMTP or transactional email service matters. My guide on business email and domain setup explains the records.

#Payments and checkout

If the site takes money, payments get their own test pass. Use the gateway's test or sandbox mode first.

• A successful card payment and a successful UPI or wallet payment, where offered.
• A failed or cancelled payment: the order should stay unpaid and the customer should be able to retry.
• A customer who closes the browser right after paying: the order should still be marked paid (this depends on the gateway's webhook).
• A full and a partial refund from the admin screen.
• Coupons, shipping charges and taxes: the amount charged must match the order total exactly.
• Order confirmation emails to the customer and the store.

After launch, make one small real payment and refund it, because live keys and test keys are separate and a mismatch only shows up with real money. For WooCommerce stores, my article on payment gateways in India has a fuller payment test table.

#Responsive layout and content

"Responsive" means the layout adapts cleanly to every screen size. Look at every page template at phone, tablet and desktop widths, not just the home page.

• Menus open and close on phones, and the mobile menu reaches every important page.
• Images are sharp but not oversized, and none are stretched or cropped badly.
• Tables, pricing grids and comparison sections stay readable on a phone.
• Pop-ups and cookie banners can be closed on a small screen and do not cover the main button.
• No placeholder text, test products, dummy prices or "Lorem ipsum" anywhere.
• Contact details, prices, opening hours and legal pages (privacy, terms, refunds) are correct.
• The 404 "page not found" page is helpful and links back to the main sections.

#Accessibility basics

Accessibility means people with disabilities can use the site, including people using a keyboard, a screen reader or zoomed text. The current standard is WCAG 2.2, published by W3C in October 2023 and updated in December 2024, and most organisations aim for its AA level.

You do not need to be an expert to run the basic checks W3C suggests for a first review:

These basics catch the most common failures. A full audit goes further, with screen reader testing and every WCAG criterion. My article on website accessibility for business covers why it matters commercially and legally.

#Performance

Speed affects both visitors and search rankings. Google's Core Web Vitals give three targets, measured at the 75th percentile of page loads on mobile and desktop:

Largest Contentful Paint (LCP): main content visible

2.5 s

Interaction to Next Paint (INP): response to taps and clicks

200 ms

Cumulative Layout Shift (CLS): how much the page jumps

0.1

Before launch, test key pages (home, a service or product page, a blog post, checkout) in PageSpeed Insights. A brand-new site has no real-visitor data yet, so the report uses lab data from Lighthouse, which Google describes as useful for debugging but which may not capture real-world bottlenecks. Treat the lab results as a guide, then check the real-visitor data a few weeks after launch. My guide to Core Web Vitals for business websites explains each metric in plain words.

#Broken links, security headers and analytics

These three are quick to check and embarrassing to miss.

#Broken links

Run a link checker or site crawler over the whole site. Fix every internal link that returns a "404 not found" error, every image that fails to load and every link still pointing at the staging address. Check external links to partners, social profiles and maps too.

#Security headers and HTTPS

Every page should load over HTTPS, and the plain HTTP address should redirect to it. Then check the response headers, which tell browsers how to protect your visitors. The OWASP HTTP Headers Cheat Sheet recommends, among others:

OWASP also recommends removing headers that reveal your server software, such as X-Powered-By. Content Security Policy is the hardest to get right, so test it carefully: a strict policy can break chat widgets, maps and payment forms. My web application security checklist covers the wider picture.

#Analytics and tracking

Confirm analytics is installed once (not twice), that page views appear in real-time reports, and that your key events, such as form submissions, calls and purchases, fire on success. Make sure the cookie banner controls the tags where consent is needed. My guide to GA4 and Google Tag Manager explains how a proper tracking setup fits together.

#When to get help

A small brochure site can be tested by the owner in an afternoon with this checklist. Bring in a professional QA pass when the site takes payments or bookings, has logins or customer accounts, feeds leads into a CRM, replaces a site with existing traffic, or must meet accessibility requirements. Those are the cases where a missed bug costs real money or reputation, and where a tester who did not build the site finds what the builder cannot see.

My website testing and QA service covers devices and browsers, forms, emails, payments, accessibility basics, speed and security headers, with a written report of what was tested and what needs fixing. For deeper work, there is a separate website accessibility audit and website performance optimisation.