A Website Launch Checklist for Domains, Hosting, and Security

A website launch fails in predictable ways: the domain points at the wrong server, the SSL certificate is missing, the contact form sends mail nowhere, or the site goes live with staging credentials still in place. None of these is hard to prevent. Each is hard to fix gracefully once visitors and search engines have seen the broken version.

Use this checklist in order. Each section builds on the one before it, and the sequence is designed to prevent the most common failure: changing DNS before the site, the certificate, and the email are ready.

Phase 1: Domain and hosting (1–2 weeks before launch)

• Confirm domain ownership and access. You can sign in to the registrar, the domain is unlocked for management, and you know the renewal date. If the domain was bought by someone else — an agency, a former employee — transfer or confirm access now, not on launch day.
• Confirm the hosting plan is provisioned. You can sign in to the control panel, the plan covers the site’s needs (storage, bandwidth, databases, email), and you know the renewal price and date. See our guide to comparing introductory and renewal hosting prices if the renewal terms are unclear.
• Decide the canonical domain. Choose www or non-www (for example, www.example.com or example.com) and use it consistently everywhere. Set up a redirect from the other version so both work and only one is indexed.
• Lower the DNS TTL. Reduce the time-to-live on your DNS records to around 5 minutes, 24–48 hours before the launch. This makes the DNS change propagate quickly and gives you a fast rollback if something goes wrong. Remember to raise the TTL back to a normal value (for example, a few hours) after launch.
• Note the renewal dates for the domain, the hosting, and the SSL certificate in a shared calendar, with a reminder 30 days ahead.

Phase 2: Build and content (before the cutover)

• Proofread everything. Read every page on the live staging URL: text, prices, phone numbers, addresses, and links. Check images display correctly and have descriptive alt text.
• Check navigation and links. Every menu item works, there are no broken internal links, and no link points to the staging domain. Search the site for the staging URL before launch.
• Test on real devices. Check the site on a phone on mobile data, not only on desktop Wi-Fi, and in more than one browser. Confirm the mobile menu works, text does not overflow, and forms are usable on a small screen.
• Set page titles and meta descriptions. Every important page needs a unique, relevant title and meta description. Confirm the heading structure is logical (one H1 per page, headings in order).
• Check the sitemap and robots.txt. Confirm yourdomain.com/sitemap.xml and yourdomain.com/robots.txt return the expected content, and that staging restrictions such as noindex or password protection are removed before launch.
• Set up analytics and Search Console. Install the analytics tracking code, verify it records visits on staging, and prepare to submit the sitemap to Google Search Console after launch. Set up Open Graph metadata so links shared on social media show the right title and image.

Phase 3: Security and HTTPS

• Enable SSL and force HTTPS. Confirm the certificate is active, the site loads on https:// with no browser warning, and all pages redirect from HTTP to HTTPS. See our guide to SSL certificates and HTTPS for the details and the common errors.
• Check the certificate covers every hostname visitors will use, including www and any subdomains.
• Remove development secrets. No API keys, passwords, or credentials in the code, in public files, in logs, or in screenshots. Production secrets should live in the hosting environment’s configuration, not in the repository.
• Secure the admin area. Strong, unique passwords, two-factor authentication where available, and no default accounts. Restrict admin access by IP where practical.
• Turn off error display in production. Errors should go to a log file, not to the browser.
• Update everything. The CMS, the theme, plugins, and server software should be on supported versions before launch, not after. Check for known vulnerabilities in the components you use.
• Review security headers where applicable, including content security policy, HSTS, and frame protections, if your hosting or application supports them.

Phase 4: Email — do this before changing DNS

Email is the part most launches break, because DNS and email routing are tightly connected. Do this before the cutover:

• Create mailboxes and aliases for the addresses the business needs, and confirm each one can send and receive.
• Check the MX records point at the right mail provider, and that they will not be disrupted by the DNS change. Review the A, AAAA, CNAME, MX, and TXT records together — changing the website’s A record should not accidentally remove the mail records.
• Set up SPF, DKIM, and DMARC. Publish the records for every service that sends mail as your domain, starting DMARC in monitoring mode (p=none). Our guide to setting up SPF, DKIM, and DMARC walks through the order and the checks.
• Test the website’s forms. Submit each form and confirm the notification arrives in the right inbox — not in spam, and not nowhere.

Phase 5: Backups and the cutover

• Take a full pre-launch backup of the old site if one exists — files and database — and store it outside the production environment. Take a backup of the new site too, before it goes live.
• Confirm the backup can be restored. A backup you have never restored is a hope, not a backup. If your hosting offers a restore test or a staging restore, use it.
• Run a final staging crawl for 404s, redirect chains, and template errors.
• Perform the DNS swap. Point the domain at the new server, then verify from multiple networks or locations that the live URL resolves correctly and the site loads.
• Verify SSL on the live domain as soon as DNS propagates, on the homepage and a few interior pages, with no mixed-content warnings.
• Test the critical paths live: homepage, contact form, checkout or booking flow, login, and search — on desktop and on a phone.
• Check redirects if you are replacing an old site: every important old URL should redirect to the right new URL, not to the homepage.

Phase 6: After launch (first 24–72 hours)

• Submit the sitemap to Google Search Console and request indexing for the homepage and the top priority pages.
• Monitor analytics and error logs for the first day. A spike in 404s usually means a missed redirect; a drop in form submissions usually means a mail problem.
• Monitor uptime from an external service, so you know about outages before your customers tell you.
• Check email deliverability — send test messages to the major providers and confirm they arrive in the inbox.
• Raise the DNS TTL back to its normal value now that the cutover is done.
• Tell people. Announce the launch to customers and on your own channels, and confirm the announcement links point at the live domain.
• Schedule a post-launch review after a week: analytics, Search Console coverage, form submissions, and any issues reported by visitors.

Keep this checklist

Save a copy of this checklist with your launch notes — what was checked, by whom, and when. The next launch, the next migration, or the next redesign will reuse most of it, and the record of what was verified is what turns a checklist into a process rather than a one-off scramble.

Key takeaways

• Work in order: domain and hosting, then content, then security, then email, then DNS.
• Lower the DNS TTL 24–48 hours before the cutover so you can change and roll back quickly.
• Set up email authentication and test forms before changing DNS, not after.
• Take a backup before launch and confirm it can be restored.
• Verify SSL, redirects, and critical paths on the live domain immediately after the cutover, then monitor for the first 72 hours.

Sources

• Paeveul, “The Launch Checklist We Actually Use” — https://www.paeveul.com/blog/launch-checklist-we-actually-use/index.html
• JumboNIC, “How to Create a Website Launch Checklist for Clients” — https://www.jumbonic.com/how-to-create-a-website-launch-checklist-for-clients/
• Trajectory Web Design, “Website Launch Checklist: The 2026 Guide for Going Live” — https://www.trajectorywebdesign.com/blog/website-launch-checklist/
• Resort Web Marketing, “How to Set Up a Website and Email Launch Checklist for a New Business” — https://resortwebmarketing.com/website-email-launch-checklist-new-business/

Sources

• {‘title’: ‘The Launch Checklist We Actually Use’, ‘url’: ‘https://www.paeveul.com/blog/launch-checklist-we-actually-use/index.html’}
• {‘title’: ‘How to Create a Website Launch Checklist for Clients’, ‘url’: ‘https://www.jumbonic.com/how-to-create-a-website-launch-checklist-for-clients/’}
• {‘title’: ‘Website Launch Checklist: The 2026 Guide for Going Live’, ‘url’: ‘https://www.trajectorywebdesign.com/blog/website-launch-checklist/’}
• {‘title’: ‘How to Set Up a Website and Email Launch Checklist for a New Business’, ‘url’: ‘https://resortwebmarketing.com/website-email-launch-checklist-new-business/’}

← All guides · Knowledge Base