What should a QA release checklist cover?

At minimum: HTTP status codes on key pages, page titles, one H1 per page, canonical tags, internal links, and forms. Those six checks catch the most common regressions — broken pages, SEO duplication, and dead lead flows — before users do.

When should I run the release checklist — before or after deploy?

Both. Before deploy, run the checks on the staging environment to catch issues while a fix is still cheap. After deploy, run the same checks on production — because staging and production are never identical.

Can I automate the QA release checklist without writing code?

Yes. Mira Checks learns your site and runs the release checklist automatically after every change — verifying status, titles, H1s, canonicals, links, and forms. No scripts, no recordings, no code.

Guide · QA Release Checklist

QA release checklist: what to check before and after every deploy

Every release is a small bet — that a renamed slug didn't orphan a page, that a form still delivers leads, that a new tag didn't break the title. Most releases pay off. The ones that don't are quiet: a page returning 500, a wrong canonical, a contact form that stopped sending. Here's the checklist that catches them first.

The six checks that matter before and after the release

Run these on staging before you deploy, then again on production after. Staging and production are never identical — the checklist is what closes the gap.

1
HTTP status codes
Every key page should return 200, and only intentionally moved URLs should return 301. A 404 or 500 after the release is a page you're losing customers on right now.
2
Page titles
Check that every changed page has a title, that it's unique, and that it matches the intended copy. Missing or duplicated titles degrade your search results silently.
3
One H1 per page
Each page needs exactly one H1 that summarises it. Zero H1s hurts SEO; multiple H1s confuse search engines and screen readers alike.
4
Canonical tags
Confirm every page's canonical points at the URL you want indexed — especially after slug changes, redirects, or protocol switches. Wrong canonicals hand Google duplicates.
5
Internal links
Crawl the main navigation and links in any changed content. Look for 404s from renamed slugs, broken anchors, and redirect loops.
6
Forms
Submit every form — contact, newsletter, lead capture, checkout. Confirm submissions succeed, confirmation messages appear, and data lands correctly.

Why manual checklists don't scale

A thorough manual release pass takes 30–60 minutes — and it competes with the momentum of shipping. Someone must remember every critical page, every form, every changed slug, and do it again in the staging and production environments. Under deadline pressure, the checklist gets skipped exactly when the release is riskiest.

The checklist above is the right foundation. The fix is to make it run itself, on every change, in both environments — not to ask a human to remember it better.

30–60

minutes per manual release pass

environments to check — staging and production

runs on releases that ship on deadline

How Mira runs this checklist automatically

Mira learns your site's pages and critical journeys, then re-runs the release checklist automatically after every change — in staging and production. Each of the six manual checks maps to a check Mira runs continuously:

HTTP status, 404 and 5xx detection

Page title verification

Single H1 verification

Canonical and broken-link checks

Form submission testing

Visual regression detection

See the proof: six acceptance criteria verified in one change validation — status, content, and behaviour checks run against a real change before it ships.

Frequently asked questions

What should a QA release checklist cover?: At minimum: HTTP status codes on key pages, page titles, one H1 per page, canonical tags, internal links, and forms. Those six checks catch the most common regressions — broken pages, SEO duplication, and dead lead flows — before users do.
When should I run the release checklist — before or after deploy?: Both. Before deploy, run the checks on the staging environment to catch issues while a fix is still cheap. After deploy, run the same checks on production — because staging and production are never identical.
Can I automate the QA release checklist without writing code?: Yes. Mira Checks learns your website and runs the release checklist automatically after every change — verifying status, titles, H1s, canonicals, links, and forms. No scripts, no recordings, no code.

Want this checklist to run itself on every release?

Mira is live. Let autonomous website QA run the whole release checklist for you — before and after every deploy.

Try Mira