How to launch a website: end-to-end checklist

A good launch is a controlled change, not a ceremonial button press — and definitely not a Friday-afternoon surprise. Before anything moves, settle three things: who can change traffic, who verifies the result, and what evidence sends you back to the old site.

1. Freeze scope and ownership

List the pages and functions required for launch. Assign owners for content, code, DNS, analytics, accessibility, security, and business approval. Defer optional additions that increase risk without blocking the outcome.

Document the launch window, communication channel, rollback authority, and support contacts.

2. Prepare production

Deploy the release to the production environment without directing public traffic to it. Configure environment values, database access, file storage, scheduled jobs, outbound email, and error reporting.

Test through a hosts-file override or provider preview URL without changing public DNS. Verify forms, transactions, authentication, search, redirects, error pages, and third-party integrations.

3. Prepare domain and DNS

Confirm ownership, renewal, registrar security, authoritative nameservers, and current DNS records. Lower only the web-record TTLs before the change. Preserve MX and email-authentication records.

Record the old and new values with timestamps. Follow how to point a domain to a host for the cutover.

4. Configure HTTPS and canonical URLs

Issue a certificate covering every public hostname. Test HTTPS directly on the new origin. Choose one canonical host—such as https://example.com—and redirect all HTTP and alternate-host requests to it without loops.

Update canonical tags, sitemap URLs, robots rules, and social metadata. Do not enable HSTS until HTTPS works reliably across every affected hostname.

5. Verify quality and accessibility

Check heading order, keyboard navigation, visible focus, form labels, error messages, contrast, and image alternatives. Test at narrow and wide viewports and with reduced motion.

Review titles, descriptions, indexability, canonical URLs, structured data, and internal links. Ensure staging URLs and private content are not in the production build.

6. Establish recovery and monitoring

Create a current backup and prove it can be restored. Keep the old environment intact. Configure uptime, certificate-expiry, application-error, and business-transaction monitoring.

Define rollback triggers: widespread errors, failed checkout, data corruption, login failure, or unavailable critical pages.

7. Change traffic and validate

Apply the planned DNS or routing change. Verify authoritative answers, recursive answers, certificate coverage, redirect behavior, key pages, forms, and logs. Test from more than one network.

Monitor error rate, latency, business events, and support reports during the observation window. Restore the previous traffic target if a rollback trigger is met.

8. Close the launch

Raise TTLs after stability is established. Submit the sitemap where appropriate, annotate analytics, and write down what went sideways while it’s still fresh — your next launch borrows this runbook. Keep the old environment for the agreed retention period, then retire it deliberately once nothing — traffic, jobs, files, or mail — still depends on it.