The best launch days are the ones nobody remembers. The site goes live, someone refreshes the homepage a few times, the team says nice things in the chat, and by mid-afternoon everyone is back to their normal work. No war room, no crossed fingers, no heroics.
That calm is not luck, and it is not bravado either. It is a checklist. Over the years we have turned launch preparation into a written routine we run before every site goes live, and it has grown a line every time something surprised us. Here is what is on it, and why each part earns its place.
The performance pass
A week or two before launch we do a dedicated performance pass. Caching gets checked page by page: what is cached, for how long, and whether it correctly refreshes when content changes. Images get reviewed for sizing and formats. The heaviest pages, usually listings, searches, and anything with maps or media, get exercised properly rather than loaded once and declared fine. Because our staging environments run the identical production stack, the behavior we measure there is the behavior launch day will have, which turns performance from a hope into a measurement.
The goal is not a perfect score in some tool. It is that the site feels quick on an ordinary phone on an ordinary connection, on the pages people actually visit. Scores are useful as a thermometer, but the pass is judged by how the site behaves in someone's hand, because that is the version of the site your visitors will meet.
SEO metadata and redirects
If the new site replaces an old one, the redirect map is one of the most valuable pieces of SEO work in the whole project. Every old URL that ever earned a link or a ranking gets a redirect to its new home, and we check them one by one rather than assuming the pattern holds. Alongside that we go through page titles and meta descriptions on the key pages, the XML sitemap, and canonical URLs.
Then there is the small toggle with outsized consequences: the setting that tells search engines whether to index the site. Staging must say no, production must say yes, and flipping it at launch is an explicit checklist line because forgetting it in either direction hurts. Our monitoring keeps checking indexability after launch too, so a mistake here would not linger unnoticed.
Forms, tested end to end
Every form on the site gets submitted the way a real visitor would submit it: on a phone, with realistic data, and with wrong data too, so we see the validation behave. But the half of form testing that is easiest to skip is the far end: does the email actually arrive? A contact form that stores the submission but never notifies anyone fails silently, and silent failures are the expensive kind, because nobody knows how many messages were lost before someone asked why it has been quiet.
Transactional mail on our platform goes through authenticated SMTP with SPF and DKIM set up properly, which gives messages a fair chance of reaching an inbox rather than a spam folder. During development and staging, non-production environments cannot send real mail at all: everything lands in a mail catcher where we can inspect content and formatting safely. Before launch we verify real delivery from the production setup and check where the messages land. "The form works" only counts once a real notification has arrived in a real inbox.
Backups configured and a restore rehearsed
Backups are switched on before launch, not after, with daily, weekly, and monthly copies retained on an automatic schedule. That covers the quick mistakes and the slow ones: the bad edit noticed within a day, and the subtle problem noticed a month later.
Then comes the step that matters more than the schedule: we rehearse a restore of this specific site. Not a dashboard that says backups exist, an actual restore, brought up and looked at. A backup nobody has ever restored is a green checkmark, and green checkmarks have a way of staying green right up until the day you need them. Launch week is exactly when you want to know, rather than believe, that the site can be brought back.
Monitoring switched on before the traffic arrives
Before the site goes live, uptime monitoring is already probing it from multiple locations, and anything the probes catch is tracked as an incident from the first minute. The ordering matters: monitoring turned on after launch tells you about the future, monitoring turned on before launch also catches the launch itself. The first hours get human eyes on top of the probes, watching logs and traffic while the DNS change settles, because that window is when surprises prefer to appear.
Tracking things as incidents, rather than as alerts that scroll past, is the part clients feel. An incident has a beginning, an owner, and an end, so "the site was slow for a bit last night" turns into a record of what happened, what we did, and what we changed so it does not repeat. Launch week is when that discipline starts, not something we add once the site has a history.
TLS and security headers
Certificates are issued and verified, and their renewal is automated, so nobody is doing certificate surgery on a deadline some months from now. HTTP redirects to HTTPS everywhere, security headers are reviewed, and the managed firewall in front of the site starts in detection mode, learning what normal traffic looks like before it begins enforcing. Automated and datacenter traffic is identified and rate-limited at the edge from day one, so bots do not get to be the biggest audience on launch day.
Editor training closes the loop
The last section of the checklist is about people, not servers. The editors who will run the site day to day get trained before launch, on the real site, doing their real tasks: creating a page, updating a menu, swapping an image, publishing a news item. We leave behind a short cheat sheet and record quick videos for the workflows that are hard to write down. The bar we hold ourselves to is simple: the first content change after launch should be made by your team, without us, and it should be uneventful.
That is the theme of the whole list, really. Launches are boring because the checklist is not. Every line on it exists because at some point something taught us it needed to. We would rather do the remembering in advance, so that on the day itself there is nothing left to do but watch a healthy site meet its visitors.