You can spend three months building a good website and undo it in the thirty seconds it takes to flip it live with the wrong setting. The launch isn't the finish line — it's a test of whether every promise the site makes still works the moment a stranger touches the live version.
Here's the takeaway up front: a good launch is boring. Nothing surprising happens on go-live day because you already found the surprises on a staging copy. A website launch checklist exists to move failures out of production and into a dress rehearsal, so the version real customers see has already been proven to render, submit, track, and rank. This guide gives you that checklist — grouped so you can hand parts off — plus the SEO checks that quietly sink good launches and the order to run the cutover.
What "launch-ready" actually means
Launch-ready doesn't mean "the pages look done." It means you have a staging environment that matches production — same platform, configuration, and content — and you've verified the site there first. Most launch disasters aren't broken code; they're a gap between staging and production: an unset environment variable, a payment key still in test mode, or the "block search engines" flag that protected staging riding along to the live site.
Two rules make the rest work. First, test on parity: check everything on an environment that mirrors production, then re-check on the real domain right after cutover. Second, freeze scope — launch day is not the time to add a feature or reword the homepage, because every last-minute change is untested. Lock the build, then run the list below.
The pre-launch checklist
Work through these on staging first. They're grouped so a marketer, a developer, and an operations lead can each own a section rather than one person guessing at all of it.
Content and links - Every page proofread; names, prices, phone numbers, and email addresses correct. - No placeholder text, "coming soon" blocks, or lorem ipsum left behind. - Every internal link resolves — and none of them point at the staging domain. - Images load, are the right ones, and have descriptive alt text.
Forms and functionality
- Every form submits and the submission actually arrives — check the inbox or CRM, not just the thank-you page.
- Buttons and CTAs go to the right place; tel: and mailto: links work on a real phone.
- Checkout runs a real transaction in live mode (then refund it); logins, search, and filters all exercised.
SEO and indexing
- Remove the noindex meta tag and the Disallow: / in robots.txt that were hiding staging.
- Titles and meta descriptions are present and unique per page.
- Canonical tags point at the live domain, not staging.
- An XML sitemap is generated and ready to submit.
- For a redesign: a 301 redirect from every old URL to its new equivalent.
Analytics and tracking - Analytics is installed and firing on the live domain — confirm in the real-time report. - Key conversions defined as goals or events (form submit, purchase, signup), or you launch blind. - The cookie-consent banner works and honors the visitor's choice. - Any test or dev tracking IDs are removed.
Performance - Run Core Web Vitals on your real templates, throttled to mobile. Aim for LCP under ~2.5 seconds; if it's slow, diagnose it before launch — our guide to fixing a slow LCP walks the method. - Images are sized and compressed; caching and text compression (gzip/Brotli) are on.
Devices, browsers, and accessibility - Test on a real phone, not just a resized desktop window. - Check at least three engines — Chromium (Chrome/Edge), WebKit (Safari), and Firefox — since rendering and form behavior still differ between them. - Keyboard navigation works with a visible focus ring; headings run in order; text has readable contrast.
Technical and hosting
- HTTPS everywhere: a valid certificate that auto-renews, with http:// redirecting to https://.
- A helpful custom 404 page instead of a dead end.
- Favicon and Open Graph title/image set so shared links don't look broken.
- Email DNS records — SPF, DKIM, and DMARC — set so form and transactional email reach inboxes, not spam.
- Automated backups switched on and uptime monitoring configured.
Legal - Privacy policy, terms, and a cookie notice present and linked in the footer.
The SEO checks that quietly sink launches
Three items on that list cause more damage than the rest combined, because they fail invisibly — the site looks perfect while it quietly bleeds traffic.
The noindex / robots block left on. Teams hide an unfinished site with a noindex tag or a Disallow: / in robots.txt on staging, then forget to remove it at launch — leaving the new site hidden from search for weeks before anyone notices the missing traffic. Verify directly: check the page source for a stray noindex and open yourdomain.com/robots.txt.
Missing redirects on a redesign. If any URLs change, every old address needs a 301 redirect to its new home. A 301 says "permanently moved" and passes the ranking equity along; a 302 says "temporary" and doesn't — so use 301 for a real move. Skip it and the rankings and backlinks you spent years earning point at 404s. Map each old URL to a destination and test a sample after launch.
Canonicals pointing at staging. A canonical tag tells search engines which URL is the "real" one. If your CMS baked the staging domain into them, you're telling Google the authoritative page lives on a site nobody can reach. Confirm canonicals reference the live domain before cutover.
Launch day: the order of operations
Sequence matters as much as the checklist. Run it in this order so problems are cheap to reverse.
- Lower your DNS TTL 24–48 hours ahead. A short time-to-live means the switch propagates fast and you can roll back quickly if something's wrong. Raise it again once you're stable.
- Freeze content and back up the current live site. That backup is your undo button.
- Deploy to production and smoke-test before pointing the domain. Reach the production server by a temporary URL or a hosts-file entry and confirm it works there first.
- Cut over. Point DNS at the new site.
- Immediately re-run the critical checks on the live domain: homepage returns HTTP 200, a form submission lands, checkout works, analytics fires, the certificate is valid, and
noindexis gone. Ten minutes here catches the parity gaps that only appear in production. - Submit the sitemap and request indexing so search engines discover the new pages quickly.
A scheduling note: launch when you can watch it. A mid-week morning gives you a full team and a full day to respond; a Friday-evening cutover hands any silent failure an unmonitored weekend.
The first 48 hours after go-live
Launch isn't done when DNS flips; it's done when the site has proven itself under real traffic.
- Watch your uptime monitor and error logs for spikes in 500s, and a jump in 404s — that's where broken redirects and missed links surface first.
- Keep analytics real-time open: confirm traffic arrives and that conversion events fire.
- Keep the old site or backup ready to restore for a short window.
- Don't ship anything that isn't fixing a launch bug. You're stabilizing, not iterating.
Once the numbers hold steady, restore your DNS TTL and move from launch mode into the ongoing work of growth.
FAQ
What should be on a website launch checklist?
At minimum: proofed content and working links; forms and checkout that genuinely deliver; SEO and indexing (remove noindex, unique titles, canonicals, a sitemap, and 301s for a redesign); analytics firing with conversions defined; Core Web Vitals on mobile; cross-browser and accessibility testing; and the technical basics — valid HTTPS, a custom 404, favicon, email DNS records, backups, and uptime monitoring. Run it on staging, then re-verify on the live domain after cutover.
What's the most common website launch mistake?
Leaving the search-engine block on. Teams hide staging with a noindex tag or a Disallow: / in robots.txt and forget to remove it at launch, so the new site is invisible to Google until the missing traffic becomes obvious. A close second is forms that show a success message but email nobody. Both fail silently, which is why they belong at the top of the list.
How long before launch should I start the checklist?
Begin at least a week out so there's time to fix what you find, and lower your DNS TTL 24–48 hours before cutover. The checklist isn't a launch-morning task; it's a staging rehearsal run with enough runway that a broken payment flow is an inconvenience, not an emergency.
Do I need to redirect old URLs when I launch a redesign?
Yes, whenever URLs change. Map every old address to its new equivalent and set a 301 (permanent) redirect so rankings and backlinks carry over. Without redirects, existing search traffic lands on 404s and the authority those pages earned is lost. Test a sample right after launch.
How do I test a form before launch?
Submit it as a real visitor would and confirm the message actually arrives where it should — the inbox, CRM, or database — not just that the thank-you page appears. Check spam folders too; if notifications land there, your SPF, DKIM, and DMARC records need attention before go-live.
Next step
A launch feels risky only the first time anyone tests the site end to end. Run the pre-launch checklist on a staging copy, follow the launch-day sequence, and watch the first 48 hours — go-live becomes the boring non-event it should be. If you'd rather have a team own the rehearsal and cutover with you, talk to Whelex.
