Guide
Website launch checklist: what to test before go-live
Before a website goes live, test the things that would cost you most if they broke, in this order: the forms and flows that bring in business, the content people read, the browsers and devices they use, accessibility, security settings, search metadata, speed, and finally the release itself.
A launch checklist is only useful if it is ordered by risk. Checking favicons while the contact form sends enquiries to a test inbox is how a business can lose a week of leads without noticing. The list below puts the business-critical checks first, so that if time runs out, what remains unchecked is the least damaging.
Each section gives the checks and a sentence on why they matter. The free QA checklist tool contains the same checks in a form you can tick and export.
1. Forms and flows that carry the business
Start with whatever the website exists to do. For a small organisation, that can mean enquiries, bookings, sign-ups or sales.
- Submit every form with realistic details and confirm the message arrives in the inbox that will be monitored after launch, not a developer's test address.
- Submit each form with required fields missing and check that the errors explain what to fix and keep what was already typed.
- Read every confirmation page and automatic email as a visitor would. Check the wording, the sender name and the links.
- Complete each purchase, booking or account flow from start to finish, using test payment modes where money is involved.
- Check that spam protection works without blocking genuine visitors. A CAPTCHA that fails on mobile is a broken form.
Why first: a broken form produces no error that anyone sees. The site looks fine; the enquiries simply stop. Our guide to testing contact forms goes into detail.
2. Content and links
- Run a link checker across the site, then click through the main menu and footer by hand.
- Search for placeholder text such as "lorem ipsum", "test", "TBC" and "example.com".
- Check phone numbers, email addresses, prices, opening hours and dates against the source of truth.
- Make sure every image has loaded, displays at a sensible size, and has alternative text that serves its purpose.
- Remove test pages, sample products and draft posts, or make sure they are not public.
Why second: wrong prices and phone numbers do direct harm, and broken links make a site look neglected.
3. Browsers and devices
- Test the main templates and flows in current Chrome, Edge, Firefox and Safari on a computer.
- Test on at least one real iPhone with Safari and one real Android phone with Chrome.
- Resize the browser from 320 CSS pixels wide up to a wide monitor and look for overlaps, cut-off text and sideways scrolling.
- Zoom text to 200 percent and check that content still fits and works.
- Turn a phone sideways on key pages.
If you have analytics from an old site, let it decide which browsers and devices matter most. Our guide to cross-browser testing in 2026 explains how to choose.
4. Accessibility
- Unplug the mouse, or simply stop using it, and try to complete each key flow with the keyboard alone. Watch for a visible focus indicator at every step.
- Check that every form field has a visible label and that error messages are given in text, not just with colour.
- Measure text contrast against the WCAG 2.2 minimums on the main templates.
- Check that page titles and headings describe the content.
- Run an automated accessibility checker on key templates and review the results with care. The W3C points out that tools "can not determine accessibility, they can only assist in doing so", so a clean scan is a start, not a finish.
5. Security settings
- Confirm every page loads over HTTPS and that plain HTTP redirects to HTTPS.
- Check the certificate covers every hostname you use, and that renewal is automatic.
- Check for security headers and for files that should not be public, such as backups and configuration files.
- Review admin accounts: remove anyone who no longer needs access and confirm the CMS, theme and plugins are up to date.
The pre-launch security configuration checks guide explains each of these and what a good result looks like.
6. Search metadata
- Give every page its own title and description.
- Remove any noindex rule that was used to keep the staging site out of search. Google's documentation explains that noindex can be set either in a meta tag or in an HTTP response header, so check both.
- Make sure canonical tags use the live domain.
- Submit an XML sitemap that lists live URLs, and check that robots.txt does not block pages you want found.
- If an old site existed, redirect each old address to its closest new equivalent.
A site-wide noindex left over from staging is one of the few launch mistakes that can make a whole website invisible to search, which is why it earns a place on every checklist.
7. Speed
- Test the main templates against Core Web Vitals. web.dev gives good thresholds of 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint and 0.1 for Cumulative Layout Shift.
- Check that images are compressed and not larger than the space they fill.
- List the third-party scripts on the site and remove any that are not needed.
- Confirm caching and compression are on at the server.
8. The release itself
- Take a backup of the old site and the new one, and try a restore before you need it.
- Agree a rollback plan: who decides, who acts, and how long it takes.
- Check that analytics and the cookie banner behave as agreed. The Irish Data Protection Commission's guidance says that where a banner has an accept button, "you must give equal prominence to an option which allows the user to 'reject' cookies".
- Record sign-off from the person who owns the launch.
After go-live: the first hour
Some checks only make sense on the live domain. Within an hour of launch, repeat these on the real site:
- Submit every form again and confirm delivery.
- Visit the plain HTTP and www versions of the domain and confirm they redirect correctly.
- View the source of a few pages and confirm canonicals and robots rules point at live.
- Load the sitemap and robots.txt from the live domain.
- Check that the certificate is valid on the live hostname.
Launch day is also when monitoring starts to matter. An uptime check and an alert on form delivery failures turn a silent problem into a noisy one.
Who does what on launch day
A checklist works better when each section has a named owner. On a small project one person may own everything; on a larger one, split it:
| Area | Suggested owner |
|---|---|
| Forms, flows and content | Site owner or project lead |
| Browsers, devices and accessibility | Tester, internal or external |
| Security settings and hosting | Developer or hosting provider |
| Search metadata and redirects | Developer, with the site owner checking content |
| Release, backup and rollback | Whoever deploys the site |
Write the names into the checklist before launch day. When something fails, there is no discussion about who looks at it.
Questions about launch checklists
How long before launch should testing start?
As soon as the build is feature-complete and real content is in place, with enough time left for fixes and a second round of checks. Testing on placeholder content misses the long headings and real images that break layouts.
Can we skip sections for a small site?
You can shorten them, but keep each one. A five-page site still has a contact form, a certificate and a title on every page. The checks take less time, but they are the same checks.
Who should do the testing?
Ideally someone who did not build the site, because builders know where not to click. That can be a colleague, the site owner, or an outside tester.
What if we find problems the day before launch?
Sort them by severity. Anything that stops a key task or exposes data should be fixed before launch. Cosmetic issues can wait for the first update, as long as they are written down with a fix date.
Sources
- Web Vitals, web.dev
- Selecting Web Accessibility Evaluation Tools, W3C WAI
- Block search indexing with noindex, Google Search Central
- Guidance note on cookies and other tracking technologies, Data Protection Commission
Sources were read on 4 November 2026.
Launch date close and checklist still long?
Send the date and the staging address. A free reply by email, carrying no obligation, says whether we could take some checks off your hands.
- Written scope
- Fixed quote before any deposit
- Plain-language findings