Website Testing Before Launch: A Practical Pre-Launch QA Checklist

Pre-launch testing is the quality control phase where you check every page, form and technical setting of a new website before real visitors see it. In this guide I share the checklist I have refined on client projects since 2012. It covers browsers and devices, forms, speed, SEO tags, 404s, redirects, analytics and security. My goal is simple: give you an order of work you can actually follow on launch week.

What is pre-launch testing for a website?

Pre-launch testing is a structured review of a website's functions, layout, speed, search settings, tracking and security, done on a staging copy before the site goes live. Specifically, its purpose is to catch errors before visitors and Google do. Every check has an owner, a pass criterion and a written result.

The key word here, above all, is criterion. "The form works" is not a result. Instead, write "the form submitted, the notification email arrived within two minutes, and the lead appeared in the CRM." That level of detail removes any debate about who checked what.

Testing is also a team sport. The designer checks layout, the developer checks function, and the marketing side checks tracking and copy. In my experience, the most expensive bugs hide in the items nobody owns. So when I share the checklist, every row gets a name next to it.

Why should you never skip pre-launch testing?

Because a bug found after launch costs far more than the same bug found on staging. A broken contact form silently loses every enquiry until someone notices. Likewise, a forgotten noindex tag can remove the whole site from search results.

Moreover, you only get one first impression. If you start an ad campaign and visitors land on a broken mobile menu, you have already paid for those clicks. In other words, testing is not an extra cost; it protects your ad spend and your SEO investment.

The scenario I see most often goes like this. First, the team launches on Friday evening. Then nobody looks at the site over the weekend. On Monday, someone discovers that the forms have not sent a single email for two days. The fix is simple: launch early in the week and finish testing the day before. That way, the whole team is also around if something breaks.

If you are commissioning a new site, it is fair to ask for testing as a separate line in the proposal. In my web design service, QA is a distinct phase for exactly this reason.

How should you set up a staging environment?

A staging environment should be a separate copy of the site with the same server software, the same PHP or Node version and realistic content. In practice, I usually put it on a subdomain such as staging.yourdomain.com. However, it must stay closed to search engines.

Google Search Central explains that robots.txt only blocks crawling. A blocked URL can still appear in results if other pages link to it. For that reason, I put staging behind HTTP password protection, which keeps both crawlers and curious visitors out.

• Protect staging with a password, not with robots.txt alone.
• Match the live server software and versions.
• Never copy real customer data to staging; use realistic dummy data instead.
• Run the payment gateway in its sandbox or test mode.
• Route staging emails to team inboxes, not to real customers.

That last point matters more than it looks. After all, accidentally emailing your real customer list from a test server is one of the most embarrassing launch mistakes I know.

How do you test browsers and devices?

Plan device testing around the browsers your visitors actually use. Open the Tech report in GA4 for your current site and list the top browsers and screen sizes. As a result, your test matrix rests on data, not on guesswork.

My usual set looks like this: Chrome on an Android phone, Safari on an iPhone, Chrome, Edge and Firefox on desktop, plus one tablet. Do not skip iPhone Safari. Specifically, some CSS and form behaviours differ there. Browser developer tools offer a decent mobile preview; still, they never fully replace a real device.

On each device, ask a few plain questions. Does the menu open and close? Does text fit without overflowing? Are buttons easy to tap? Does a horizontal scrollbar appear? For a deeper look at the mobile side, see my mobile-friendly test guide.

Also, test with a larger system font size. A visitor who has enlarged text on their phone may see overflow you never noticed. Finally, document every issue with a screenshot and the device name. That simple habit helps the developer reproduce the bug much faster.

How do you test forms and conversion flows?

Test every form end to end: filling in, validation messages, submission, thank-you page, notification email and the place where the data lands. Seeing a success message, therefore, is not enough. The real question is whether the enquiry reaches the right person.

1. Submit the form with empty required fields and check that the error message makes sense.
2. Try invalid email and phone formats.
3. Submit valid data and confirm the thank-you page loads.
4. Check that the notification reaches you, and the auto-reply reaches the visitor if you use one.
5. Confirm the record appears in your CRM or admin panel with the right fields.
6. Make sure spam protection does not block real users.

A common failure is notification email landing in spam. In most cases, the cause is simply missing SPF, DKIM or DMARC records. I cover that setup in my business email guide. For the design of the form itself, read my lead form design article; here I focus only on testing it.

How do you measure page speed before launch?

Before launch you rely on lab tools, because there is no real user data yet. Lighthouse and PageSpeed Insights are, therefore, the standard choices. That said, PageSpeed Insights cannot reach a password protected staging site, so use Lighthouse inside Chrome instead.

For targets, I use the Core Web Vitals thresholds that Google publishes on web.dev. An LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less count as good. Still, a lab score is not the same as real user experience. So keep measuring after launch too.

The speed problems I catch most often on staging are uncompressed hero images, font files with weights nobody uses, and plugins that load on every page but serve only one. You can shrink images quickly with my image resizer.

If you are unsure how to read a Lighthouse report, see my Lighthouse performance test guide. For the ranking side of the story, how site speed affects SEO is a good companion.

How do you check SEO tags during pre-launch testing?

Check SEO tags per template type: home page, service page, product page, blog post and category page. On each template, review the title, meta description, canonical, H1, robots meta tag and hreflang where relevant.

During pre-launch testing, the robots meta tag gets my closest attention. Using noindex on staging is correct, of course, and also expected. However, if that setting travels to the live site, Google will drop your pages from search. Therefore the very first launch day check is to view the source of live pages and search for noindex.

Other points to verify:

• Each page has one unique H1.
• No title or description is empty or duplicated.
• The canonical points to the live domain, not the staging domain.
• Structured data passes Google's Rich Results Test without errors.
• Images carry meaningful alt text.

You can preview how a title and description will look in results with my Google SERP preview tool. For writing rules, my meta title and description guide has you covered.

How do you find 404 errors and broken links?

First, use a crawler. A tool such as Screaming Frog walks through the staging site and lists URLs that return 404, broken images and faulty internal links. On a password protected site, you add the credentials in the crawler settings first.

In the crawl I look at three areas in particular. First, links in the main menu and footer. Second, hard coded links that still point to the old domain or to staging. Third, image paths that broke during content transfer. A link to staging that slips into production sends visitors to a password prompt, and that erodes trust instantly.

Next, test the 404 page itself. A URL that does not exist must return a real 404 status code, not 200. Google Search Central flags empty pages that return 200 as soft 404s in its reports. In addition, a helpful 404 page offers a search box and links to main sections.

Also, broken link checks do not end at launch. After go-live, watch the page indexing report in Search Console. My Search Console guide explains how to read it.

How do you verify redirects before launch?

If you are replacing an old site, every old URL needs a permanent 301 redirect to its new equivalent. Map the redirects in a spreadsheet first, then test each row. Google recommends server side permanent redirects for permanent moves.

I test three things on every row. Does the URL really return 301? Is there a chain, where A points to B and B points to C? And does the redirect land on the right page, or does it dump everything on the home page? Sending everything home is easy, so teams do it. Yet it confuses visitors and Google alike.

For spot checks, use my redirect checker. When you have hundreds of URLs, feed the list to a crawler and check them in bulk instead.

Also confirm that HTTP goes to HTTPS, and www to non-www (or the reverse), in a single hop. I cover the full migration process in my website migration SEO checklist; this article stays with the testing step.

How do you test analytics and conversion tracking?

Test analytics by watching events arrive with the right names and parameters. For example, GA4 DebugView exists for exactly this job. Combine it with Google Tag Manager preview mode, and you can see which tag fires on every click in real time.

My tracking checklist includes these questions:

• Does each template send exactly one page view?
• Do form submissions, phone clicks and WhatsApp clicks arrive as events?
• Does the Google Ads conversion tag fire on the thank-you page?
• Does the cookie banner hold tags back until the visitor consents?
• And does a UTM tagged visit show the correct source?

For the last check, build a test link with my UTM builder and confirm the source in DebugView. One warning: keep staging traffic out of your live property. Either use a separate test property or filter internal traffic.

If you have not yet decided which conversions to track, read my guide on setting website conversion goals first. After all, you cannot test a goal you never defined.

Which security checks belong on the list?

The pre-launch security check makes sure you do not ship obvious holes to production. In practice, a full penetration test is a separate project for larger sites. Still, every site needs a minimum baseline.

• Is the SSL certificate valid, and does every page load over HTTPS?
• Is there mixed content, meaning HTTP files on HTTPS pages?
• Does the admin panel use a strong password and two factor authentication?
• Is debug mode off, so error messages do not reveal server paths or database details?
• Can anyone open backup files, the .env file or the .git folder from a browser?
• Do forms have protection against spam and malicious input?

For web application risks, the OWASP Top 10 is a solid reference. Injection and broken access control, for example, are long standing entries on that list. So if your forms write to a database, ask your developer how they guard against those categories.

One practical note: review admin accounts before launch. Teams often create temporary accounts during testing and then forget them for years. My password generator helps you create strong credentials for the accounts you keep.

How do you test payments and orders?

On a site that takes payments, the scope grows, because an error here means lost money. First, switch your payment provider to test mode. Then run successful, declined and abandoned payments with the provider's test cards. After each scenario, confirm that the order shows the correct status in the admin panel.

I also look for answers to a few practical questions. Does a product go out of stock at zero inventory? Is shipping calculated correctly? Does a discount code deduct the right amount? Does the customer receive the order confirmation email? Moreover, if invoicing or accounting is connected, make sure test orders do not create real records there.

As a final step, turn test mode off, place one small real order and run the refund flow. That way you see both money in and money out working in production. On e-commerce projects I handle this as part of my e-commerce consulting work.

Why is content proofreading a separate step?

Because technical teams test functions; they rarely read the copy. As a result, typos, old prices, a wrong phone number or a forgotten block of lorem ipsum can slip into production. These errors look small; however, they hit trust directly.

So I hand content review to the people who know the business best: the owner or the sales team. They spot an outdated price, address, opening hours or service scope at a glance. Likewise, check that legal pages exist and are current, including the privacy policy, cookie policy and any GDPR notices your market requires.

To trim long paragraphs and unclear sentences, run key pages through my readability checker. Clear copy sends a sharper message to visitors and search engines alike.

Finally, click every phone and email link. For example, a tel: link starts a call on mobile. If the number contains a typo, however, your visitor calls a stranger. It is a tiny detail, and one of the most frustrating bugs I see in the field.

How do you run an accessibility test before launch?

Start with automated tools and finish with manual checks. The accessibility section in Lighthouse and browser extensions such as axe quickly catch low colour contrast, missing alt text and unlabelled form fields.

Automated tools miss a lot, though. That is why I also navigate the site with the keyboard alone. Does the Tab key open the menu? Is the focus outline visible? Does Enter submit the form? In practice, this quick test uncovers real problems on most projects.

The W3C's WCAG 2.2 guidelines are the core reference here. For businesses that sell into the EU, accessibility is no longer only good practice, because the European Accessibility Act sets obligations for certain digital services. So if you serve European customers, do not leave this item for the end.

What does a pre-launch QA checklist table look like?

The table below summarises the checklist I use on projects. Each row shows an area, the checkpoint, the tool and the pass criterion. Add or remove rows to fit your own site.

I suggest moving this table into a shared spreadsheet and adding owner and date columns. Then, at the launch meeting, the answer to "who checked this?" sits in front of everyone.

Which checks should you repeat on launch day?

On launch day you quickly confirm that everything that passed on staging also passes live. After all, settings change during deployment. Environment variables, mail settings, caching and robots.txt break most often.

1. Confirm there is no noindex in the source of live pages.
2. Check that robots.txt does not block the whole site.
3. Send one test submission from every form.
4. See your own visit in the GA4 real time report.
5. Try a few old URLs and confirm the 301s.
6. Submit the XML sitemap in Search Console.

If your sitemap is missing or stale, create one with my XML sitemap generator. For robots.txt, my robots.txt generator helps too; however, always read the live version by hand.

What you monitor in the weeks after launch is a separate topic. The job of pre-launch testing is to open the site with a clean start. After that, you need a proper measurement routine of its own.

Which mistakes do teams miss most often?

The mistakes teams miss most sit in the gaps between roles, where nobody says "that is my job." These are the ones I keep finding on my own projects and on sites I inherit:

• A noindex tag or a blocking robots.txt carried over to production.
• Canonicals and internal links that still point to staging.
• Forms whose notification emails never arrive or land in spam.
• A conversion tag that fires twice and inflates ad reports.
• A contact button that hides or fails on mobile.
• Forgotten test accounts and exposed backup files.

Notice that none of these is a hard technical problem. Instead, they are simple checks that slip through. That is why even an experienced team should never work without a checklist. Otherwise, memory is the least reliable tool on a tired launch evening.

The double firing conversion tag is especially costly. Google Ads smart bidding learns from conversion data, so bad data pushes budget in the wrong direction. I review this as part of Google Ads management too.

How long should testing take, and who should do it?

In short, duration depends on size and features. Here is a starting range from my field experience, not a guarantee. For a 10 to 20 page company site, plan one to three working days. For a mid sized site with forms and a member area, plan about a week. An online shop needs longer, because payment and stock scenarios multiply the cases.

As for who does it, three layers work best. The developer tests their own work, the project manager runs the checklist, and the business owner approves content and workflows. Each layer then catches what the previous one missed.

If you are a small business without a QA team, set one rule anyway: the person who built the site should not sign it off alone. After all, spotting mistakes in your own work is hard. Even fifteen minutes from a fresh pair of eyes makes a real difference.

If you want an outside review before launch, reach me through the contact page. If you are planning search visibility alongside the new site, my SEO consulting page explains how I work.

How do you turn pre-launch testing into a habit?

Pre-launch testing should not be a one-off phase. Good pre-launch testing grows with the site. Instead, treat it as a routine you repeat with every significant update. When you add a new template, form or plugin, rerun the matching part of the list.

A checklist is not there to slow the team down; it frees up attention. Because the list is in hand, you stop worrying whether you forgot something. You spend that energy on the problems that need real thought. A new team member can also work at the same standard from day one.

On the other hand, avoid bloating the list. A checklist with hundreds of items soon becomes a document nobody reads. For example, I keep at most ten items per area and move rarely useful checks to a separate appendix for large projects.

My advice is to turn the table above into your own template, copy it into every project, and add a row whenever something slips through. Over time, the list becomes a quality record built for your site. Put simply, a good checklist is experience written down.