In short
Pre-launch QA covers four areas: content and links, functions like forms, technical basics like redirects and tracking, and display across multiple devices. Each area needs its own checklist rather than a general visual pass.
Why a structured list beats “clicking through once”
Free-form click-throughs always check the same areas (homepage, navigation) and miss others (404 page, form validation). A fixed list ensures completeness.
Checking content and copy
Checklist for the content area:
- Spelling and numbers (prices, phone numbers, addresses)
- Placeholder text (“lorem ipsum”) fully removed
- Images have alt text
- Legal pages (imprint, privacy policy) are current and linked
Checking links and navigation
Checklist for links:
- All internal links lead to the correct target
- External links open as intended (new tab or not)
- A 404 page exists and links back to the homepage
- Footer and header links work on every subpage
Checking functions and forms
Checklist for functions:
- The contact form submits and returns a confirmation
- Newsletter sign-up works, including double opt-in if used
- Search returns expected results
- Login/checkout flow is fully tested end to end
Checking technical basics
Checklist for technical setup:
- SSL certificate active, no mixed-content warnings
- Redirects from old URLs are set up (301, not 302)
- Tracking and analytics code is embedded correctly
- Sitemap and robots.txt are configured correctly
- The staging environment is no longer indexable by search engines
Checking performance and load time
Before launch it's worth checking load time under real conditions, not just fast office wifi. Test explicitly on a mobile connection.
Checking mobile devices and browsers
Checklist for devices:
- Display on a small smartphone screen (e.g. 375px width)
- Display at tablet size
- At least one additional browser tested besides the default
- Touch interaction with menus and forms works
Accessibility as part of QA
Four quick checks cover the most common issues: sufficient colour contrast, keyboard operability, sensible heading structure, and alt text for images.
Who should run pre-launch QA?
It works most reliably with someone outside the project team, since they check without bias. The client separately reviews subject-matter content.
Capturing QA feedback in a structured way
Instead of writing findings into an email, record every discrepancy found as its own note directly on the affected element – that prevents items getting lost while they're being worked through.
Keep checking after launch
The first 24 hours after launch deserve a second, short review round: tracking data starts coming in, forms get used for real, and search engines crawl the new structure.
Who is responsible for what?
Pre-launch QA rarely fails from lack of knowledge — it fails from unclear ownership. Assign one responsible person per area: development for technical setup and performance, design for visual consistency, the business owner or client for content accuracy, and a project lead who consolidates the list and gives final sign-off for launch. Without that assignment, several people end up double-checking the same obvious items while less obvious areas like form validation or redirects fall through entirely. Keep ownership noted in the checklist itself, not in a separate document, so it's clear who is allowed to tick off each item.
Common mistakes in pre-launch QA
These patterns regularly cause bugs that only surface after launch:
- QA only happens in the reviewer's desktop browser
- The list gets worked through from memory instead of ticked off in writing
- Forms get looked at but never actually submitted
- The review happens days before launch, and content changes afterward
- No one checks the staging environment for accidental indexing after go-live
Frequently asked questions
How long does thorough pre-launch QA take?
For a mid-size website, usually half a day to a full day, depending on the number of subpages.
Is testing in Chrome enough?
No, at least one other browser and one mobile device should be checked, since display bugs often only show up there.
When should QA happen?
On the staging environment, shortly before the planned launch date, with buffer time for fixes.
Who is responsible if a bug appears after launch?
That should be clarified in the contract beforehand, usually depending on whether the bug would have been visible during QA.
Does every website need an accessibility check?
A basic check never hurts and often covers the biggest issues with little effort.
What's the best way to document QA findings?
As individual notes directly on the affected element with a status, rather than one long list in a document.
Should forms be tested with real data?
Yes, with test data that is removed from the system afterwards so real customer data isn't affected.