What should be on a website launch checklist?

Only the things that change at the moment of switchover: DNS records and TTL, TLS certificate issuance on apex and www, the canonical entry points and their redirect hops, the old-URL redirect map, the edge and browser cache, form delivery and email authentication, analytics and consent, indexing directives, and the rollback. Anything that does not change at the switch belongs to QA two weeks earlier, not to launch day.

Who should own the rollback decision during a launch?

One named person, agreed in writing before the launch window, with the trigger expressed as a number rather than a feeling. Rollback authority given to a team becomes a discussion; authority given to one person with a reachable phone becomes a decision. That person must also be able to stop ad spend and scheduled emails, not just the deploy, because those keep sending traffic to a broken page.

Which launch settings cannot be undone quickly?

HSTS submitted for preload, deletion of the old-URL redirect map, decommissioning the previous host, and any public announcement of the new URL. HSTS preload entries are compiled into browsers and take months to reach stable, and the preload project itself warns that removal is slow and painful. Those items need two signatures before launch, one from someone who does not work on the site.

Launch day fails on ownership, not code

A launch almost never fails in the code the team spent three months on. It fails in the eight or ten items nobody owned: the TTL nobody lowered, the certificate that could not be issued because DNS moved first, the form that returned a success message and delivered nothing, the rollback nobody had the authority to call at 11pm. The fix is not a longer checklist. It is a name on every line, an artifact proving the line passed, and one person who owns the way back.

We have run launches as the agency and been called into the aftermath of launches run by someone else. The post-mortems rhyme. Nobody says the templates were wrong. They say the mail went to spam for two days, or that both the developer and the marketing lead assumed the other one had checked the redirect for the old pricing page.

That is an ownership failure, and it is structural rather than personal. A launch is the one moment when the project leaves the repository and touches a registrar, a certificate authority, a cache, a mail domain, an analytics property and a handful of ad accounts. Those systems have different logins and, in most companies, different owners. The team that built the site usually holds none of them.

Why "it's built" is not a launch state

A finished build is a state of the repository. A launch is a state of the internet. Between the two sits a short list of items that are configured outside the codebase, verified from outside the network, and owned by someone who was probably not in the build standups.

Most launch-day damage comes from that gap rather than from defects. A defect is visible in a browser and gets fixed in an hour. A missing redirect for a page that used to rank is invisible for three weeks and then shows up as a revenue line. A form that posts to a working endpoint but delivers into a spam folder looks perfect in the network tab. These are quiet failures, and quiet failures are the ones that need a named human to look on purpose.

The nine items, their checks, and their owners

Every row below is something that changes at the moment of switchover. Each has a check you can run from outside the company, and each needs exactly one name next to it. The right-hand column matters most: a stop condition written before launch is the difference between a decision and an argument.

#	What breaks	Why it happens	The check	Sign-off owner	Stop condition
1	DNS still answers from the old host	Resolvers cached the previous TTL and the record was changed at the last minute	`dig +short A example.com @1.1.1.1` and again against a second public resolver, plus one phone on mobile data	Whoever holds the registrar login	TTL reduced to 300 seconds or less at least 48 hours before the switch
2	Browser warning on apex or on `www`	Certificate issuance depends on DNS already pointing at the new host, and on port 80 being reachable for HTTP validation	`openssl s_client -connect example.com:443 -servername example.com` for both hostnames, then load both in a clean browser profile	Infrastructure or hosting owner	Valid certificate covering both hostnames, more than 30 days of validity
3	Four URLs serve one page	HTTP, HTTPS, apex and `www` are each handled by a different layer	`curl -I` on all four entry points and count the `Location` hops in each chain	Whoever owns redirect rules	One canonical host, one hop, permanent redirect not temporary
4	Old URLs return 404	The redirect map was written from memory instead of from a crawl	Diff the old sitemap and the top landing pages against the new map, and assert that no row points at another redirect	SEO or content owner	Every row reaches a 200 in a single hop
5	Visitors still see the previous site	The cache in front of the origin is still holding the old bytes	Purge the changed paths, then re-request each one and read the cache status header on the response	The one person with purge access	No response reports a cache hit after the purge
6	Form returns success, message never arrives	The sending domain changed, authentication broke, or the new sender has no reputation	Submit from three different providers, including one corporate domain, and confirm inbox placement, reply-to and attachment limits	Whoever owns the sending domain	Three of three delivered, authenticated, and replyable
7	Analytics reports nothing from hour one	The stream still points at the old hostname, or the consent gate blocks the tag before it fires	One real event, watched in debug view, from a cold browser with cleared storage	Marketing operations	One session visible with the correct hostname and consent state
8	The entire site is invisible to search	A staging `noindex` or staging `robots.txt` shipped with the build	Fetch `robots.txt`, grep the rendered HTML for robots directives, count URLs in the sitemap	SEO owner	`robots.txt` allows crawling, no stray `noindex`, sitemap count matches live URLs
9	Nobody can decide to go back	Rollback was described as "we can always revert it" and never rehearsed	Execute the rollback once against pre-production before launch day	One named human, not a team	Rollback completed end to end inside the agreed window

Nine rows is not a coincidence. It is roughly the number of items that genuinely change at switchover. The usual launch checklist, with sixty boxes covering typography and browser versions, hides those nine inside noise.

A name, not a team

Four rules make the table work, and they are cheaper than the table itself.

One name per row. "The platform team" and "development" are not owners; they are places to look for someone to blame. If the name is a person, the check happens. If it is a department, the check happens only if someone in that department happens to remember.

Every sign-off is an artifact. A command output, a screenshot with a visible timestamp, a link to the live URL. "Looks good" is not a sign-off, because it is indistinguishable from "I did not open it". The artifact also settles the post-launch conversation: you can see which row was accepted and what it looked like at the time.

The builder does not accept their own work. They run the check; someone else accepts the result. This is not distrust, it is a second pair of eyes on the item the builder is most confident about, which is exactly where confidence is least reliable.

Run the checks from outside. Phone on mobile data, incognito profile, no VPN. A large share of launch-day problems do not exist inside the office network: internal DNS overrides the record, a proxy caches an old asset, a firewall allows a port that the public internet cannot reach. The only environment that matters is the one your customers are in.

Who owns the rollback

This is where most launches are actually undecided, and where an opinion is worth stating plainly: rollback authority belongs to one named person, agreed in writing before the launch window, with the trigger expressed as a number.

If the trigger is a judgement call made at 11pm by a group chat, it will be debated instead of executed. Numbers end debates. Form submissions at zero for ninety minutes during business hours. Server errors above one percent of requests for fifteen minutes. Payment or checkout failures on the primary path. Two independent reports of a broken page from outside the company. Those are decidable at 11pm.

Two details that get left out of the plan:

Undo and fix-forward are different operations with different owners. Restoring the previous version is a rollback. Patching production on launch night is a hotfix. A launch whose only plan is fix-forward has no rollback, and a launch whose only plan is undo will be rolled back for cosmetic reasons and lose the day. Name both, and name who decides which one applies.

Rehearse it once. Execute the rollback against pre-production before launch day. The first time a procedure runs should not be the night it is needed, because the useful output of a rehearsal is not confidence, it is duration. If restoring takes forty minutes, you now know that a bad launch costs forty minutes of downtime, and that is a business decision someone above the launch team has to accept before, not during.

The rollback owner also needs authority beyond the deploy — to pause ad campaigns, stop a scheduled email, and post the holding message. A rollback that leaves paid traffic pointed at a broken page is not a rollback.

Irreversible items get their own gate

Some launch settings cannot be undone in an afternoon. Those need explicit approval before the window, from someone senior enough to accept the cost of being wrong.

HSTS with the preload directive. Preload entries are compiled into browser source and reach the stable channel over months. The preload project itself states that preloading is not recommended by default and that removal tends to be slow and painful for sites that enabled it by accident. Sending preload is a one-way door, and the person who signs it must own every subdomain, including internal ones.
Deleting the old-URL redirect map. Google's guidance is to use permanent redirects and to avoid chains, and the map has a second life you cannot see: printed material, QR codes, partner pages, email templates and old ad creatives keep pointing at the previous URLs for years. Keep the file even when it looks untidy.
Decommissioning the previous host. Once mail, DNS and any legacy integration are gone, "put it back" means rebuilding it, not switching it on.
Announcing the new URL publicly. Listings, profiles, ad accounts and press mentions unwind more slowly than they change.

The rule we use: an irreversible item takes two signatures, and one of them belongs to someone who does not work on the site. A person with no emotional investment in shipping today is the right person to approve a door that only opens one way.

The one-page launch record

A launch document that people actually fill in fits on one screen. Ours has ten lines:

Release identifier and what is shipping.
The launch window, in a single timezone.
Rollback owner, with a phone number next to the name.
Rollback trigger, as numbers.
Date of the last successful rollback rehearsal.
Irreversible items approved, and by whom.
The nine-row table, each row with an owner and a status.
The two external checkpoints — mobile data, private window — and who ran them.
Who is watching analytics and form delivery for the first two hours.
Where the previous version is kept and how it is restored.

Ten lines is the point. A forty-tab spreadsheet is opened once, by the person who built it, and never by the person who has to decide at midnight.

What we would remove from the usual checklist

Two things, and they are the two most common entries. Cross-browser matrices and full copy proofing belong two weeks before launch, not to launch day: they do not change at the switch, and putting them on the launch list guarantees the list is too long to run under pressure. Launch-day checks are for state that flips at switchover. Everything else is QA with a deadline attached.

The uncomfortable implication: if your launch checklist is long, it is probably measuring the wrong moment. The nine items above are short enough to run in under two hours and specific enough that a stranger could audit them.

If a switchover is coming up, we plan it around exactly this table — the web design and development service page describes how we scope the build, and the launch record starts here. Related reading: what a migration really costs in redirects and lost URLs, the build limits that decide your deploy, and whether you need a patch, a redesign or a rebuild.