Pre-launch website QA checklist for agencies

A pre-launch QA pass should answer one practical question: is this website ready for real people, real content, and real operating conditions? The most useful checklist is not a tour of every page. It concentrates attention on shared templates, critical journeys, risky integrations, and the evidence a team needs after launch.

Agree on scope before testing

Start by naming the supported browsers and devices, the pages that represent each template, and the journeys that matter most. Include login, forms, checkout, search, consent, and error states when they exist. Confirm who can approve content, design, accessibility, analytics, and deployment decisions.

Test with production-like content. Short placeholder copy rarely exposes wrapping, truncation, empty states, missing translations, or awkward headings. Use realistic images, long names, validation errors, and missing optional data. Record known issues separately from launch blockers so the final decision is explicit.

Check the experience people receive

Review each critical journey at narrow and wide viewport sizes. Make sure navigation remains understandable, controls are large enough to operate, overlays can be dismissed, and the page does not create unexpected horizontal scrolling. Check loading, empty, error, and success states—not only the ideal path.

For accessibility, combine automated checks with keyboard and human review:

Run an automated scan on every representative template.
Navigate interactive elements using only a keyboard and keep track of visible focus.
Confirm headings and landmarks describe the page structure.
Check that fields have useful labels, instructions, and error messages.
Review alternative text and control names in context.
Zoom and reflow the page without losing content or actions.

Automation can identify repeatable, machine-detectable failures, but it cannot decide whether a journey makes sense. The guide to automated vs manual accessibility testing explains where each method belongs.

Verify performance under realistic conditions

Measure representative pages more than once. A single Lighthouse run can move because of browser state, network timing, third-party scripts, or server warm-up. Compare the median result, investigate large variation, and review the underlying metrics rather than approving a launch from one composite score.

Pay particular attention to the largest above-the-fold asset, late-loading fonts, layout movement, render-blocking resources, and scripts added by analytics, chat, consent, or advertising tools. Core Web Vitals monitoring for agencies covers how repeat lab measurements can become a useful post-launch baseline.

Confirm the operational details

A polished page can still fail as a launch if its surrounding systems are not ready. Before approval, verify:

Area	Pre-launch evidence
Forms	Valid submissions arrive, errors are understandable, and spam controls work
Links	Internal, external, email, telephone, download, and redirect targets behave correctly
Metadata	Titles, descriptions, canonicals, social previews, robots rules, and sitemap URLs match the launch
Analytics	Consent choices are respected and important events are recorded once
Security	HTTPS, permissions, secrets, dependency review, backups, and rollback ownership are confirmed
Operations	Error monitoring, uptime checks, domain access, and escalation contacts have owners

Test redirects from the current production site before switching traffic. Keep a rollback plan that states who can make the call and which data or content could be affected. Take a dated record of the approved release, including the pages, environment, checks, known issues, and approvers.

Turn launch evidence into a baseline

Immediately after deployment, repeat the critical journeys against the public site. Confirm certificates, redirects, forms, analytics, caching, and third-party integrations in their real environment. Avoid treating a successful deployment command as proof that the release works.

Once the smoke test passes, preserve the accessibility and performance results as a known baseline. Scheduled website QA monitoring for agencies can then highlight meaningful drift instead of rediscovering the same launch-day backlog. Assign alerts to an owner and define when a change should be investigated, fixed, accepted, or added to a planned manual review.

A launch checklist is finished when it creates a clear decision and a usable record. The goal is not a page full of ticks; it is shared confidence about what was tested, what remains, and how the team will notice when the website changes.