Launch day checklist

Everything in the pre-launch checklist should already be done. This is the final, ordered run-through for the actual go-live moment—the small, easy-to-forget steps that turn a finished site into a live one.

Before flipping the switch

1. Confirm every item in the pre-launch checklist is genuinely complete, not just planned
2. Take a final backup of the outgoing site (if replacing an existing one) before making any changes
3. Confirm DNS records are correctly configured and, if changing hosts, that TTL values were lowered in advance to speed propagation
4. Double-check the SSL/TLS certificate covers the exact domain and subdomains being used
5. Remove any staging-only noindex tags or password protection left over from development
6. Confirm robots.txt is not still blocking the whole site
7. Confirm email-sending records (SPF/DKIM/DMARC) weren't disturbed by the DNS changes—see the email deliverability checklist

Go live

1. Point DNS to the production environment, or make the production site publicly reachable
2. Load the live domain in a private/incognito browser window to confirm it resolves correctly with no leftover cache
3. Confirm HTTPS is active and there are no mixed-content warnings
4. Click through primary navigation, forms, and any checkout or sign-up flow on the live domain itself, not just staging
5. Set up 301 redirects from any old URLs to their new equivalents, if this is a relaunch (see the technical SEO checklist and the migration checklist)

Tell search engines

1. Submit the XML sitemap in Google Search Console (and Bing Webmaster Tools, if relevant)
2. Request indexing for the homepage and any especially important pages
3. Confirm analytics and Search Console are both tracking the correct, live property

Cross-check

• The site has been checked on at least one real phone, in addition to desktop
• Forms have been tested end-to-end on the live domain, including that notification emails actually arrive
• Any payment or checkout flow has been tested with a real (or sandbox) transaction, not assumed to work because it worked in staging
• Search functionality, if present, has been tested with a real query
• Social sharing previews (Open Graph/Twitter Card images and titles) look correct when a link is shared

Team communication

• Everyone who needs to know the site is live has actually been told, including support or sales staff who might field questions about it
• A single, clear point of contact is designated for launch-day issues, so problems aren't reported into a void or to three different people at once
• Anyone with deploy or DNS access is aware the launch is happening, so nobody makes an unrelated change at the same time

Timing the launch

• Launch is scheduled for a time when the team can actually monitor and respond, not the last thing before everyone logs off for a weekend or holiday
• If the site depends on a third party (payment processor, booking system, external API), their status is checked before launch rather than assumed fine
• A quiet, low-traffic window is preferred where the business has one, so any issue affects the fewest visitors possible before it's caught

Rollback plan

• A clear, agreed threshold exists for what would trigger rolling back—decided in advance, not improvised under pressure
• The rollback path itself (reverting DNS, restoring a backup, redeploying a previous build) has actually been rehearsed or at least documented, not assumed to be simple
• Whoever can authorize a rollback is reachable and knows they may need to make that call quickly

After launch

• Uptime monitoring is active and alerting the right people
• Analytics is checked within the first 24–48 hours to confirm data is actually flowing
• Search Console's coverage report is checked over the following days for unexpected crawl errors
• Performance is spot-checked in the days after launch, since real traffic and real network conditions sometimes surface issues staging never showed
• Server and application error logs are checked directly in the first day or two, not just inferred from whether anyone happened to complain
• A short retrospective is held once the dust settles—what went smoothly, what didn't, and what should change for next time—while it's still fresh enough to be useful

If anything about the launch feels rushed, it's worth revisiting common mistakes before going live rather than after.