The launch checklist we use

Start with the two we got wrong

A checklist assembled from things that have never gone wrong is a checklist of things nobody forgets. These two are on this list because we shipped both, on this site, and neither was caught by a test suite that was otherwise green.

The first was a page that returned 200 with an empty body. Our contact page rendered nothing inside its main element in production, and every gate passed, because no gate had ever looked at a rendered page. Status codes were checked. Content was not. A page can be perfectly healthy by every automated measure and still be blank.

The second we found on 25 August 2026, and it is still open as this is published. Our apex domain returns 200. The www hostname returns 404, with no security header on the response, because the host resolves and reaches the platform but no domain mapping matches it. Anyone typing the www form of our address gets an error page. We had never checked, because you do not visit your own site by typing the address.

Both share a shape worth internalising. They are failures of a thing nobody was looking at, rather than failures of a thing that was tested and passed. That is what a launch checklist is genuinely for, and it is why most of the items below are about looking rather than about testing.

Before the site goes live

1. Look at every page, rendered, at a phone width and a desktop width. Not the code, the page. Automate it if there are more than a few: we screenshot every public route at 390px and 1440px and check three independent signals, because any one of them is foolable on its own.
2. Check that each page has a non-empty main element and a non-empty h1. This is the check that would have caught our blank contact page, and it costs almost nothing.
3. Confirm the page is in the HTML a crawler receives, with no JavaScript run. Fetch it with curl and read it. A page that only assembles in a browser is invisible to a lot of what you want to be visible to.
4. Give every page a title inside the width a search result shows, and a written meta description rather than a clipped first paragraph. A description that stops mid-word is a defect visible to everyone except you.
5. Set a self-referential canonical on every page, and make sure the sitemap lists what exists and nothing that does not.
6. Decide what robots.txt allows before launch, not after. A staging block left in place is the single most expensive one-line mistake available at this stage.
7. Run the accessibility pass. Keyboard through the whole thing once, including any form and any menu. It takes ten minutes and finds things no automated score does.

On measurable budgets, assert numbers rather than intentions. Ours are Google's "good" Core Web Vitals boundaries rather than numbers reverse-engineered from whatever the site currently scores, so a failure is a finding instead of a miscalibrated gate.

The hour after it goes live

This is the part that gets skipped, because launching feels like the end. Every item here is something that can only be checked once the site is actually reachable at its real address.

1. Request every hostname you own, not just the one you use. The apex, the www form, and http as well as https. We missed exactly this, and it cost us an unknown number of visitors landing on a 404.
2. Confirm the redirects preserve the path. A redirect from www to apex that drops everything after the slash sends every deep link to your home page, and it looks fine if the only URL you test is the root.
3. Check the certificate covers every hostname that resolves, including the one you just redirected.
4. Confirm the security headers are actually on the response, on a real request, in production. Header configuration that is present in a config file and absent from the response is common and invisible.
5. Submit the sitemap, then come back in a few days and check the discovered URL count is in the right order of magnitude.
6. Send a real enquiry through your own contact form and confirm it arrives where a human will see it. Then check it survived being stored, not just being sent.
7. Load the site on a phone, on mobile data, off your own network.

The form one deserves emphasis. A contact form that silently fails is worse than no contact form, because you believe you have a channel and the enquiries simply stop existing. Test the whole path, including where the message ends up, not just that the page said thank you.

What a checklist cannot do for you

A list catches the things you already know to look for. Both defects at the top of this page were invisible to a full green pipeline, and adding them here does not protect against the next one of the same shape.

What helps more is a habit: after every launch, ask what nobody looked at. Not what failed, which you already know, but what no gate, no test and no person ever actually observed. Our blank page and our 404 both lived in that gap, and both were obvious the moment somebody looked.

• Which pages has a human seen rendered, at a real size, since the last change?
• Which hostnames have been requested, as opposed to configured?
• Which user journey has been completed end to end, by a person, on the live site?
• What does the site do when something it depends on is slow or missing?

Write down what you find and add it to your own version of this list. A checklist inherited from someone else encodes their failures. The valuable one encodes yours.

What this does not cover

• This is our list, shaped by our stack and our own failures. It is not exhaustive and it is not an industry standard. A site handling payments, personal data at scale, or regulated content needs checks that are not on it.
• The www defect it describes is still open at the time of publication. It is a configuration change on our hosting account and it is written up here as a live example rather than a resolved one.
• The performance thresholds are lab assertions against a deployed site. They are not field data, which is the only thing Google actually ranks on, and a site can pass all of them and still fail for real visitors.
• Nothing here covers the legal and compliance side of a launch: cookie consent, privacy notices, accessibility statements or anything jurisdiction-specific. Those matter and we are not lawyers.
• It says nothing about migrating an existing site, which brings its own set of problems around redirects from old URLs and preserving whatever the old pages had earned.

Sources

• whatscene.in performance budgets, lighthouserc.json. Assertions run against the deployed site, three runs per URL with the median taken. Thresholds are Google's published boundaries rather than values fitted to current scores. Run: lighthouserc.json, read 2026-08-25.
• whatscene.in rendered-page manifest, 21 public routes. Every public route screenshotted at 390px and 1440px, then checked for three independent signals of a blank render: PNG byte size, visible text length inside main, and a non-empty h1. Written after a page shipped that returned 200 with an empty main. Run: scripts/shoot.mjs, evidence/SCREENSHOTS.md.
• whatscene.in hostname check, apex and www. Each hostname requested directly and the status code and response headers recorded. Found the www host returning 404 with no HSTS header while the apex returned 200 with one. Run: data/site-audit/README.md, 2026-08-25.
• Web Vitals, Google. Retrieved 25 August 2026.

Revisions

• 25 August 2026 First published, built from our own gates and two defects we shipped.

This page is revised in place rather than replaced, so its address does not change.