Checklist
QA checklist
A QA checklist for a release: what to verify before a build leaves the pipeline, who signs each item, and which failures block the release outright.
The website launch checklist, in blocking order
A launch checklist has to cover eleven areas: content and links, functionality, browsers and devices, performance, accessibility, metadata, redirects if a site is being replaced, analytics and monitoring, legal pages, infrastructure, and rollback. The last one is the one most lists omit, and it is the only item on the list that matters after something has already gone wrong.
- Checklist
- 11 groups
- 40 checks
- Updated
Launch day fails in predictable ways, and almost none of them are the ones the team spent the last week worrying about. The site works; the contact form posts into a mailbox nobody monitors. The design is finished; the old urls all return 404 and the traffic that took three years to earn is gone. Analytics is installed; it was never fired on a real page view, so the first month has no data.
In the checklist
- Content and links 5
- Functionality 5
- Browsers and devices 4
- Performance 3
- Accessibility 4
- SEO and metadata 5
- Redirects, if replacing a site 3
- Analytics and monitoring 3
- Legal and privacy 3
- Infrastructure 3
- Rollback 2
Website launch checklist, ready to copy
Copy it as it is. There is no email step, and nothing on this page is behind one.
Content and links
Functionality
Browsers and devices
Performance
Accessibility
SEO and metadata
Redirects, if replacing a site
Analytics and monitoring
Legal and privacy
Infrastructure
Rollback
The checklist below is ordered by what blocks a go-live rather than by what is easiest to check. Each group ends up owned by a different person, which is the practical reason to write it down: the failures that survive are the ones that fell between two people who each assumed the other had it.
What each group is for
Scroll the table sideways for the examples.
| Group | Why it earns its place | Example |
|---|---|---|
| Content and links | Final copy in every template, no placeholder left behind, internal links that resolve, external ones that go where they claim, alt text on images, and the favicon and social preview in place. Placeholder text reaches production because it lives in the template nobody opened rather than in the page everybody reviewed. | Crawled the staging build for broken links and for the word lorem before the switch. |
| Functionality | Every form submits and the submission arrives somewhere a person actually reads. This is the single most common launch failure, because a form that posts successfully looks identical to one whose destination nobody is watching. | Submit the contact form with real content, then confirm it arrived in the inbox somebody opens. |
| Browsers and devices | The supported browsers on desktop, plus Safari on iOS and Chrome on Android, from your narrowest viewport to your widest. Mobile Safari is where a launch most often breaks, and it is the browser least likely to be on the team's machines. | Checked on Safari 17 on an iPhone, not only in a desktop browser's device emulation. |
| Performance | Core Web Vitals measured on a real mid-range device rather than in the lab, images sized for the slots they occupy, and nothing render-blocking that first paint does not need. A site measured only on the machine it was built on ships that machine's numbers. | LCP measured on a four-year-old Android over a throttled connection, not on the design machine. |
| Accessibility | Keyboard reach on every interactive element, a visible focus indicator on each of them, contrast at the level you are committing to, and one logical heading outline per page. All four are cheap to fix before launch and expensive to retrofit once the templates are in use. | Tabbed the whole home page without a mouse and watched where the focus ring disappeared. |
| SEO and metadata | A unique title and description on every page, canonical urls in the spelling you want indexed, a reachable sitemap, and a robots.txt that allows what should be crawled. A staging robots.txt shipped to production is a recoverable mistake that costs weeks. | Fetched the live robots.txt and confirmed it does not read Disallow: /. |
| Redirects, if replacing a site | Every old url maps to a new one or to a deliberate 404, as a 301 rather than a 302, with no chain longer than one hop. This is the item whose cost is invisible on launch day and severe two months later. | Old /about-us returns 301 to /about. Retired /2019-promo returns 404 on purpose, not a redirect to the home page. |
| Analytics and monitoring | Analytics verified by watching a real page view arrive in the live report, error reporting verified by sending it a test error, and uptime checks pointed at a url that exercises the application rather than a static file. | Loaded the home page and watched the session appear in the realtime report. |
| Legal and privacy | Privacy policy and terms published and linked, and consent behaviour correct before consent is given rather than only after. The pre-consent state is the one that is rarely tested and the one a regulator looks at. | Loaded the site in a fresh profile and confirmed no analytics request fires before a choice is made. |
| Infrastructure | A valid certificate with renewal confirmed to be automatic, TTL lowered before the switch so a mistake can be undone quickly, and a backup whose restore has been tested at least once. | TTL dropped to 300 seconds the day before, restored to its normal value once traffic settled. |
| Rollback | The previous version can be restored, somebody has actually done it once, and a named person can decide to do it out of hours. A rollback plan nobody has executed is a hypothesis. | Rehearsed on staging: previous build restored in under ten minutes by the on-call engineer. |
A launch check that cannot fail, and one that can
Not this
[ ] Forms work
This instead
[ ] Contact form submitted with real content, and the submission confirmed to have arrived in the inbox somebody actually opens
A check nobody can fail is not a check. Forms work gets ticked by watching a thank-you page appear, and a form that posts successfully to a destination nobody is watching looks identical from the browser. This is the single most common launch failure, and the second wording is the one that catches it, because it cannot be ticked without opening the inbox.
Verify the destination, not the submission
The recurring launch failure is a form that works. It validates, it posts, it shows a success message, and the messages go to an address that was correct during development and is nobody's inbox now. The check that catches it is not submitting the form, it is going to look at where the submission landed. The same rule applies to analytics, to error reporting and to alerting: each of them has a happy path that succeeds locally while the far end is not connected to a human.
Redirects are the item with a delayed invoice
Nothing about a missing redirect map is visible on launch day. The site is up, the pages look right, and the old urls that used to bring in traffic quietly return 404 to everyone who follows a link or a search result. By the time the drop shows in a report the cause is a month old. Mapping every url of the old site before the switch is tedious and cheap; reconstructing which ones existed afterwards, from an index that has already forgotten them, is neither.
The pre-launch bug list needs a route
A launch generates a burst of small findings from people who are not testers: a designer spots a wrong font weight, a stakeholder finds a broken link, somebody in support notices the wrong phone number. Those arrive in whatever channel is nearest, which is usually a chat thread that scrolls, and a proportion of them are lost. Deciding in advance where a finding goes, and making that route cheaper than sending a message, is what determines whether the list is complete on the morning of the launch.
Website planning is what the launch gets checked against
A checklist can only verify decisions that were already taken, and planning is where they are taken. The half of a plan that survives to launch day is the half written as statements somebody can check later. A site described as responsive gives the launch nothing to test; a site planned for Safari on iOS at the narrowest viewport the team supports gives it a pass or a fail. A contact form works the same way: naming the address it delivers to, and the person who reads that address, turns a launch item from an opinion into an observation. Sign-off is the same idea read backwards. Somebody has to accept the site, and what they accept is either a set of conditions recorded in advance or an impression formed on the morning itself. Writing those conditions down costs nothing at the time and removes the argument that otherwise happens at the worst possible hour, when the only surviving record of what was intended is what two people remember agreeing.
Common questions
What should be on a website launch checklist?
Content and links, functionality with every form verified at its destination, browsers and devices including mobile Safari, performance measured on real hardware, accessibility, unique metadata and a correct robots.txt, redirects from any site being replaced, analytics and monitoring confirmed live, legal pages, infrastructure and DNS, and a rehearsed rollback.
What is most often missed before a website launch?
Three things recur: forms that submit successfully to a destination nobody monitors, redirects from the old site's urls, and a staging robots.txt shipped to production. All three look fine on the day and become expensive later, which is why they are checked by inspecting the far end rather than the page.
How long before launch should the checklist start?
Early enough that a failure can change the date, which in practice means running it on a production-like environment a week or more ahead rather than on the morning itself. The items that need real DNS or a live payment gateway are the exceptions, and they are worth listing separately as the ones that can only be verified after the switch.
Do you need a rollback plan for a website launch?
Yes, and it has to have been executed at least once. The value of a rollback is that it is available under pressure, at an hour nobody planned for, decided by somebody who has done it before. A plan that exists only as a document has never been tested against the conditions it is for.
What goes in a website planning template?
The decisions a launch will later be checked against: the browsers and devices supported, where each form delivers and who reads that destination, what evidence closes each launch item, and the named person whose approval ends the launch. It is worth having to the extent that every line can be read back as a question with a yes or no answer.
Terms used on this page
More templates
-
Checklist
UAT checklist and sign-off
A copyable UAT checklist and sign-off template: what to confirm before the window opens, how to record each scenario and finding, and what sign-off states.
Checklist
Website redesign checklist
A website redesign checklist for the QA half: the baseline to capture before the old site goes, url and content parity, regression, cutover and rollback.
Or skip the template and capture the fields automatically.
Environment, console and network attach themselves, on the free plan.