Website QA Checklist Before Launching a Business Website

QA is a journey test, not a spelling pass

The most damaging launch problems are rarely decorative. They are broken contact paths, a call button that disappears on mobile, a production page carrying noindex, an analytics event that fires twice or a form that reports success without delivering anything.

I test a website from the perspective of the visitor and the owner. Can someone understand the offer, complete the intended action and receive an honest response? Can the owner measure that action and maintain the site after launch?

1. Test the final content and real data

Placeholder content hides layout and credibility problems. Long service names, real phone numbers, real project images and realistic error messages change how a page behaves. Before launch, check every public claim, price, date, location, contact detail and external link against the approved source.

For case studies, distinguish delivered value from measured results. A clearer booking path can be described as a design outcome; a conversion increase cannot be claimed without evidence.

• Remove placeholder copy, sample reviews and test credentials.
• Confirm names, locations, legal text and contact details.
• Check image crops and alt text against the final visual.
• Search the code and rendered pages for outdated URLs or claims.

2. Check mobile, tablet and desktop journeys

Responsive QA is not just shrinking a browser window. Use representative phone, tablet and desktop sizes, then test navigation, headings, cards, forms, sticky elements, tables and long URLs. Rotate a mobile viewport and check keyboard input on form fields.

Pay special attention to the first screen. If the visitor cannot understand the offer or reach the main action without fighting the layout, a high desktop score will not compensate.

3. Exercise forms and every conversion path

Check required fields, useful validation, focus movement, disabled and loading states, server errors, spam protection and success messaging. A production HTTP 200 response proves only that an endpoint answered; it does not prove that an email reached the correct inbox.

During automated QA I use invalid or honeypot requests so no real enquiry is sent. Final delivery verification should be an explicit owner-led test with the receiving mailbox open.

• Click phone, email, WhatsApp and external booking links.
• Test keyboard-only submission and visible focus.
• Confirm the form prevents duplicate submissions.
• Validate actual delivery separately from interface behaviour.

4. Validate search metadata and indexability

Every indexable page needs one descriptive title, one useful meta description, a self-referencing canonical, a clear H1 and crawlable internal links. Check the sitemap contains only canonical indexable URLs. Confirm privacy, staging or utility pages use the intended index controls.

Open the rendered HTML, not only the source component. Verify structured data is valid JSON and matches visible facts. After launch, inspect representative URLs in Search Console and Bing Webmaster Tools because production delivery can differ from a local build.

5. Verify analytics as a measurement plan

Page views alone do not explain whether the website is helping the business. Define events for meaningful actions—service selection, project exploration, contact starts, form success, calls or messages—and include useful parameters such as page and label.

In the browser, trigger each event once and confirm it appears once. Nested click handlers or duplicated analytics attributes can make a single click look like two conversions, which is worse than having no number because it creates false confidence.

6. Check performance and accessibility together

Use optimised images with reserved dimensions, load the hero deliberately and lazy-load below-the-fold media. Review Core Web Vitals with both lab tools and field data once enough traffic exists. Performance should support the journey, not become an isolated score-chasing exercise.

Check headings, landmarks, labels, contrast, alternative text, focus order, keyboard navigation and reduced-motion behaviour. WCAG provides the formal framework, but a short manual keyboard pass often exposes issues an automated scanner cannot.

7. Repeat the checks on the live domain

Deployment changes the environment: domains redirect, environment variables differ, CDNs cache resources and third-party scripts load under real consent and network conditions. Recheck the canonical hostname, HTTPS, redirects, 404s, robots.txt, sitemap, forms, console and the most important journeys after production promotion.

Record the deployed version and any owner-side actions. A launch is complete when the live experience is verified, not when the build command finishes.

My minimum launch gate

I would block a launch for a broken primary journey, an unsafe form, incorrect public facts, accidental noindex, invalid canonical routing, a serious accessibility barrier or a reproducible runtime error. Minor visual polish can follow; trust and recoverability cannot.