Website Launch Checklist: The 11 Checks We Run Before Go-Live
A website can look finished on the developer’s screen and still fail on launch morning: no padlock on the www address, a contact form delivering to a mailbox nobody reads, a sitemap answering 404. We started running a fixed website launch checklist after warasat.com.pk taught us how those mornings go: the desktop looked finished and the phone told a different story. Every build since, including mtufaildiagnosticcenter.com and truckaxic.com, has gone through the same eleven checks before DNS points at the new site.
The website launch checklist, in order
Each line exists because the failure behind it has shipped at least once on our side, and writing it down is what stops it shipping twice. We run the list once in staging a few days before launch, and again on production the morning DNS goes live, because production behaves differently: a different domain, a different certificate, a different mailbox.
| Check | When | What breaks if you skip it |
|---|---|---|
| HTTPS on every host, www included | staging and launch | a padlock warning on one address |
| Certificate issuer and expiry dates | launch morning | a warning a week later |
| Redirects: http to https, both domain forms to one | staging and launch | duplicate pages, split padlocks |
| sitemap.xml and robots.txt reachable and correct | launch | nothing gets indexed properly |
| Contact form delivers to a mailbox someone reads | launch morning | enquiries disappear |
| Phone number and WhatsApp links dial on a phone | staging and launch | visitors give up before calling |
| Every page opened on a real phone | staging | every action sits below the fold |
| Tap targets big enough for a thumb | staging | mis-taps on the button that matters |
| Images sized per breakpoint in modern formats | staging | a homepage nobody waits for |
| Titles, meta descriptions, favicon on every page | staging | ugly tabs and bad link previews |
| Analytics receives its first real hit | launch morning | a launch you cannot see |
The sections below take the checks that have earned their place the hard way.
HTTPS on every host, not just the one you typed
The first three checks exist because certificate problems are the ones strangers see first. Chrome shows its “your connection is not private” screen when a certificate is missing, expired, or issued by an authority the browser does not trust, which Cloudflare’s SSL explainer documents plainly. The miss we see most often is the second domain form: the certificate covers the bare domain and the www address answers without one.
A certificate is also a date on a calendar. Let’s Encrypt issues certificates valid for 90 days by default and has announced that lifetimes drop to 45 days by 2028, so renewal is a routine to automate, and its FAQ recommends renewing every 60 days. We read the dates off the live site instead of trusting a hosting panel:
openssl s_client -connect dev2production.com:443 -servername dev2production.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -datesRun on 1 October 2026, that command reports our certificate was issued on 9 September 2026 and runs until 8 December. Run the same against the exact host in your launch URL, including the www form and your staging domain. Then set the redirects: http must land on https, and both domain forms should end on the one address the sitemap uses. What the padlock does and does not promise is in what a padlock tells you about your website.
The files the browser and Google ask for
sitemap.xml and robots.txt are the least glamorous files on a site and the ones we check most often. On 1 October we measured the sites we have shipped: warasat.com.pk serves a sitemap of 10,318 bytes, mtufaildiagnosticcenter.com one of 3,473 bytes, and on dev2production.com both paths answer with a 308 redirect, which is fine because the destination is correct. What hurts indexing is a 404, an empty file, or a sitemap listing URLs that themselves return 404, and search engines do not email you about it. The check is a handful of curl calls per domain and a look at the first and last URL in the sitemap.
The contact path is the whole point
mtufaildiagnosticcenter.com carries a detail most sites forget: visitors with JavaScript switched off still see a line in the page source telling them to call +92 300 047 8311 for appointments, which we verified on 1 October. That is the standard a contact path should meet: reachable even when the normal path fails. Our own bar comes from the contact-form work we wrote about in how many contact form fields a small site needs: fewer fields, phone number first. On launch morning we submit the form ourselves and watch the mailbox it is supposed to reach, and we repeat the test once during the first support week, because mail providers change behaviour without telling anyone.
The phone is the site for most visitors
warasat.com.pk is the build that earned this check its place. The desktop layout was finished and approved; on a phone, the hero pushed every action below the fold and a visitor had to scroll before they could do anything. A browser window resized to phone width never shows that, because thumb targets, the sticky call button and the on-screen keyboard only exist on a real phone. So we open every page on an Android before launch and check three things: the main action is visible without scrolling, buttons leave at least 44 px of thumb space, and typing into the form does not hide the field being typed into. We weigh the page too, since a phone on mobile data is the slowest device most visitors will use, and web.dev’s image guidance is where we start when a page needs to lose weight. The per-breakpoint byte counts we check are in image sizes for websites.
What we do not check on launch day
Rankings, lab performance scores and log dashboards stay off the launch list. A launch has one job: put the site where visitors and search engines can reach it. Rankings move over weeks, and a performance score captured on launch morning says little about the next visitor’s experience. What we do wire up in launch week is the quiet infrastructure: uptime monitoring that messages a phone when the site stops answering, and a backup that has been restored at least once. Those are separate pieces, and the monitoring is the one people skip, so we wrote how we monitor website uptime with free tools.
What launch day leaves behind
Eleven checks take most of an hour when you run them slowly, and they are cheaper than the hour they prevent. The misses on our launches were rarely in the code; they hid in the surroundings, a certificate, a mailbox, a phone. If a go-live is coming on your side, run the table above with whoever is deploying and ask them which checks they skip and why. If you would rather hand the launch to a team that runs these checks as a habit, our web development service page describes what we build, and the contact page is the fastest way to start.
Questions before a launch
How long does a website launch checklist take?
About an hour for the full pass on a small site, longer the first time because the failures take fixing. We split it: the staging pass in the days before launch, then the production pass on launch morning, which is mostly the certificate, the redirects, the form and analytics, and takes about twenty minutes when staging was clean.
What should I check before my website goes live?
In this order: HTTPS on the bare domain and the www form, the redirects between them, sitemap.xml and robots.txt reachable, one contact path tested end to end on a real phone, images sized for a phone, titles and descriptions on every page, and analytics receiving its first hit. The table near the top has the full list with the failure each check prevents.
Do I need a checklist if my developer has launched sites before?
Yes, because the launch environment is new every time: a different domain, a different certificate, a different mailbox. Developers who launch weekly still miss the www certificate and the form delivery, which is why the list is written down instead of carried in someone’s head.
What is the first thing to check after a website goes live?
That analytics is receiving real visits and that a form submission from your own phone reached the mailbox. Those two confirm visitors can arrive and reach you. After that, put uptime monitoring and a tested backup in place during the first week.