Website Launch QA Process: A Repeatable Workflow for Web Agencies

A website launch QA process is a repeatable sequence of gates every project passes before and after go-live: freeze staging, run automated checks, run manual checks, triage issues, get client sign-off, launch in an agreed window, then recheck at 24 hours and seven days. Each gate has a named owner, and nothing moves forward until it passes.

Most agencies have a launch checklist. Fewer have a launch process. The difference shows up at 5 p.m. on launch day, when the checklist exists but nobody is sure who ran it, which version of the site it was run against, or whether the fix someone pushed an hour ago broke something else.

This guide is about the process around the checks: the order, the owners, the gates and the parts worth automating. For the technical items themselves (DNS, HTTPS, redirects, email records), our website launch checklist has the full list with configs. Here we're concerned with how an agency runs that list the same way on every project.

Why launch QA needs a workflow, not just a checklist

A checklist tells you what to check. A workflow answers the questions that cause real launch problems:

• When does QA start, and what is frozen while it runs?
• Who runs each check, and who decides an issue is a blocker?
• What happens when a fix lands: does everything get rechecked, or just the item that was fixed?
• How does the client sign off, and on what exactly?
• What gets checked after launch, and by whom?

Without answers, QA depends on whoever is free that afternoon. Coverage varies from project to project, and the same mistakes return.

The launch QA gates

Gate 1: Freeze staging

QA against a moving target is wasted effort. Agree a freeze date with the client when the project plan is set, not the week before launch. After the freeze, only fixes from QA go in, each logged against an issue.

Content is the usual exception. If the client is still adding pages, agree which sections are frozen and which aren't, and make sure late pages go through the same checks.

Gate 2: Run the automated checks

This is where automation earns its place, because these checks are identical on every project and quick to repeat. A typical automated pass against staging covers:

1. Links and status codes. Crawl every page for broken internal and external links and error responses. The free broken link checker handles spot checks.
2. Redirect map. Compare the old site's URLs, taken from its sitemap or analytics, with the new structure. Every old URL with traffic or links needs a 301 to its closest equivalent. Test samples with the redirect checker or upload the whole map to the bulk redirect checker, and see 301 vs 302 redirects for when each applies.
3. Metadata. Missing or duplicate titles and descriptions, missing H1s and placeholder text such as "Lorem ipsum" or "Just another WordPress site". The meta tag checker shows what each page outputs.
4. Robots rules. Staging should block crawlers. Production must not. Keep two expected robots files and test the live one with the robots.txt tester on launch day.
5. Certificates and security basics. Confirm the production certificate covers every hostname you'll serve, including www, with the SSL checker.
6. Images and performance. Flag oversized images and pages that load slowly on mobile.
7. Automated accessibility scan. Run a WCAG-based scanner and list issues by page and severity.

The output is a single report, with each item labelled pass, fail or needs review. Store it with the project so the client can see what was tested.

The most valuable part of automating Gate 2 is the re-run. When a developer fixes five issues, the whole suite runs again in minutes. That catches the common case where fixing one template breaks another.

Gate 3: Run the manual checks

Some things a crawler can't judge:

• Forms end to end. Submit every form and confirm the message reaches the right inbox or CRM, the autoresponder arrives and doesn't land in spam, and test submissions are deleted afterwards.
• Devices and browsers. Check the key templates on the browsers and devices agreed in the contract.
• Accessibility by a person. Automated tools catch only some WCAG issues. Keyboard navigation, focus order, screen reader announcements, captions and whether link text makes sense need a human. Our guide to making a website accessible covers the manual tests.
• Content sense check. Prices, phone numbers, legal pages, cookie banner wording and anything time-sensitive.
• Analytics and consent. Confirm tags fire only as the consent setup intends, and that conversions are recorded.

Gate 4: Triage

The project lead sorts every open issue into one of three buckets:

• Blocker: launch can't happen. Broken checkout, forms not delivering, missing redirects for high-traffic pages, the site blocked from search engines.
• Launch-day fix: must be fixed in the launch window or within an agreed time after.
• Backlog: logged, agreed with the client, scheduled.

Triage is a judgement call, so it stays with a person who understands the client's business. A typo on a terms page might be backlog for one client and a blocker for a regulated one.

Gate 5: Client sign-off

Ask the client to approve three things in writing: the content as it stands, the function they've tested, and the launch date and window. Attach the QA report and the backlog list so the approval covers known issues. A recorded approval protects everyone if questions come up later.

Gate 6: Go-live

Launch in a window when the developer, the client contact and the hosting provider are all reachable. Avoid Friday afternoons. Before switching anything, confirm a backup of the old site and a rollback plan.

After the switch, re-run the critical subset of Gate 2 on the live domain: robots rules, indexability of key pages, redirects, certificate, forms and analytics. The named developer makes the go-live call and the rollback call. Neither should ever be automated.

Gate 7: Post-launch rechecks

Schedule the full automated suite to run on the live site after 24 hours and again after seven days, with the report sent to the project lead. Many launch issues appear only once real traffic, caches and search engines arrive: redirect loops on old URLs, a CDN rule overriding headers, a plugin update the client ran on day three.

After the seven-day check, hand over to the care plan or support team with the final report attached.

What to automate and what stays with people

That split matches how Make It Flow approaches automation for web agencies: routine checks run on their own and produce reports, and the decisions stay with the people accountable for the site.

Accessibility and consent: check the rules where you operate

Launch QA is where agencies most often meet legal requirements on a client's behalf. A few examples, all of which change over time:

• United States: the ADA is widely used in website accessibility claims against businesses. For state and local governments, the Justice Department's Title II rule adopts WCAG 2.1 AA, and an interim final rule in April 2026 extended its compliance dates to 2027 and 2028 depending on population size.
• European Union: the European Accessibility Act applies to many consumer-facing products and services, including e-commerce, from June 2025.
• United Kingdom: the Equality Act 2010 requires reasonable adjustments, which can include an accessible website.
• Canada and Australia: accessibility duties come from laws such as Ontario's AODA and Australia's Disability Discrimination Act.
• Cookies and tracking: in the UK and EU, non-essential cookies generally need consent before they're set, so testing banner behavior belongs in Gate 3.

An agency can test against WCAG and report the results, but whether a client's site meets its legal obligations is for the client and its advisers. Say so in your contract and in the QA report.

FAQ

What is the difference between a launch checklist and a launch QA process?

A checklist lists what to verify, such as redirects, robots rules and forms. A QA process adds the order, owners, gates and re-checks: when QA starts, who decides a blocker, how fixes are retested and how the client signs off. Agencies need both, and the process is what makes the checklist run consistently.

How long should website QA take before launch?

It depends on the site's size and complexity. Plan enough time after the staging freeze for a full automated pass, manual checks, at least one round of fixes and a complete re-run. Squeezing QA into launch day is the most common cause of avoidable post-launch problems.

Can website QA be fully automated?

No. Automation handles repeatable checks well: links, status codes, redirects, metadata, certificates and part of accessibility testing. Form delivery, content accuracy, keyboard and screen reader testing, triage and the go-live decision need people. Automating the repeatable half frees time for the manual half.

Who should sign off a website before launch?

The client should approve content, function and the launch date in writing, with the QA report and known backlog attached. Inside the agency, a named developer or project lead makes the technical go-live call. Keeping both approvals on record avoids confusion if issues surface later.

What should you check after a website launch?

Re-run your automated suite on the live domain right after go-live, then again at 24 hours and seven days. Focus on robots rules, indexing, redirects from old URLs, certificates, forms, analytics and speed. Then watch search console data for crawl errors over the following weeks.

Does an agency guarantee a site is accessible?

An agency can design and test against WCAG and document the results, but it can't usually guarantee legal compliance, which depends on the client's content, updates and jurisdiction. Contracts should say what was tested and to which standard, and clients should take advice on their own obligations.