Website Launch Checklist: Domains, DNS, Hosting, SSL, Email, and Testing

Overview

A reliable launch starts with a clear record of what is changing, where each service is hosted, and who controls the relevant accounts. Before editing DNS or moving a live site, document the domain registrar, DNS provider, hosting account, email provider, current nameservers, and any third-party services that depend on the domain.

The order of work matters. Build and test the website before changing public DNS where possible. Lowering DNS record time to live (TTL) ahead of a planned migration can help resolvers refresh records sooner, but it does not eliminate caching. A DNS propagation checker can show how different resolvers currently answer; it cannot make an incorrect record correct or guarantee instant global change.

Keep a dated copy of the existing DNS zone before making changes. Include A, AAAA, CNAME, MX, TXT, and any verification records. This creates a rollback reference and helps prevent an unrelated service, such as business email, from being interrupted during a domain and hosting setup.

For background on selecting and managing the pieces of a launch, see the web hosting control panel comparison and the guide to what hosting uptime guarantees actually mean.

Checklist by scenario

Launching a new website

• Choose the canonical domain. Decide whether visitors should use the apex domain, such as example.com, or the www hostname. Configure the other version to redirect consistently.
• Register or confirm the domain. Check the spelling, renewal settings, registrant contact details, transfer lock status, and domain privacy options where available. Use a registrar account protected by a strong, unique password and multi-factor authentication.
• Select hosting that matches the site. Confirm the runtime, database, storage, traffic expectations, backup options, access methods, and deployment workflow. A small brochure site may fit shared hosting, while an application with custom services may need cloud web hosting with more control.
• Create the site before pointing DNS. Use a temporary hostname, staging address, or hosts-file test to review the site without making it public. For WordPress, a staging workflow can make content and configuration checks safer; see the WordPress staging guide.
• Connect the domain. Either change nameservers to those supplied by the hosting or DNS provider, or keep the current nameservers and update the required A, AAAA, or CNAME records. Use one approach deliberately; mixing instructions from different providers often creates conflicting records.
• Enable HTTPS. Install an SSL certificate for the chosen hostnames, confirm that it renews correctly, and test both the root domain and important subdomains. Then redirect HTTP to HTTPS only after confirming that assets, forms, scripts, and callbacks work securely.
• Configure search basics. Check the site title, page metadata, canonical URLs, robots.txt, XML sitemap, indexability settings, and redirects. The robots.txt and XML sitemap guide covers the files most often overlooked on a new launch.

Migrating an existing website

• Inventory the current site. Record URLs, databases, uploads, cron jobs, forms, payment or booking integrations, analytics, redirects, certificates, and email-related DNS records.
• Take verified backups. Save both the database and files, and confirm that a restore is possible. A backup that has never been tested should not be the only migration plan.
• Prepare the destination. Match required PHP, application, database, web server, and environment settings. Copy the site to the new host and test it privately before changing DNS.
• Plan the final sync. If the site receives orders, messages, registrations, or other changing data, identify a short freeze window or use a final database synchronization method. This reduces the chance of losing changes made during the DNS transition.
• Preserve URL behavior. Map old URLs to their new destinations with permanent redirects where appropriate. Do not redirect every old page to the homepage if a more relevant destination exists.
• Switch DNS and monitor. Change only the records required for the website, then check the old and new environments, HTTPS, forms, logs, and key transactions during the transition. Keep the previous hosting available until the new site is confirmed stable.

This approach supports a website migration without downtime, although no DNS change can guarantee that every visitor will move at the same moment. For redirects and HTTPS details, review how to force HTTPS without breaking redirects or SEO.

Adding business email to a website domain

• Choose the email provider separately from web hosting if needed. Website hosting and email hosting can use different providers. The MX records determine where incoming mail is delivered.
• Publish the provider’s exact records. Add the required MX records and any SPF, DKIM, and DMARC records supplied by the email provider. Avoid inventing values or combining multiple SPF policies incorrectly.
• Test both directions. Send messages to and from several external addresses, verify delivery, inspect authentication results where available, and test aliases, forwarding, shared inboxes, and mobile access.
• Protect continuity. Do not remove existing MX records until the new mailboxes are ready and the migration plan is understood. The business email setup guide explains the role of each record.

What to double-check

Run the following checks from a private browser window and, where practical, from more than one network or device:

• Domain resolution: Confirm the apex domain, www, and every required subdomain resolve to the intended destination. Check for stale AAAA records if the server is not configured for IPv6.
• HTTPS behavior: Test certificate validity, mixed-content warnings, HTTP-to-HTTPS redirects, and both domain variants. Confirm that canonical URLs use the intended protocol and hostname.
• Navigation and content: Follow menus, internal links, search, pagination, downloads, images, and embedded media. Look for staging URLs, placeholder text, exposed debug messages, and broken assets.
• Forms and transactions: Submit contact forms, account creation, checkout, booking, and password-reset flows. Confirm that notifications reach the correct inbox and that users receive a useful success or error message.
• Performance: Test representative pages on mobile and desktop. Review large images, unnecessary scripts, caching, compression, database queries, and third-party calls. A fast DNS provider helps the lookup stage, but it does not fix slow application code or oversized assets.
• Security: Remove test accounts, rotate temporary credentials, restrict administrative access, update dependencies, confirm backups, and check file permissions. Ensure security headers and firewall rules do not block legitimate users or integrations.
• Measurement: Verify analytics, consent controls where applicable, search-console or webmaster verification, conversion events, and error monitoring. Test that tracking does not expose private form data.
• Recovery: Record the hosting support route, renewal dates, DNS access, deployment steps, rollback procedure, and backup location. Another administrator should be able to follow the record without guessing.

Common mistakes

• Changing nameservers without copying the DNS zone. This can remove mail, verification, and service records even when the website itself works.
• Using the wrong record type. An A record points a hostname to an IPv4 address; an AAAA record is for IPv6; a CNAME points one hostname to another. Follow the receiving provider’s instructions and check for conflicting records.
• Forgetting the non-canonical version. Testing only www or only the apex domain can hide a certificate, redirect, or cookie problem on the other version.
• Publishing a staging site. Remove noindex controls only when the production site is ready, and ensure the live site does not expose test data, administrative tools, or temporary credentials.
• Breaking email while connecting hosting. Web records and MX records serve different purposes. Change only what is needed for the website and preserve mail records.
• Relying on a single propagation check. Results vary by resolver, location, and cache. Compare expected records over time and use the provider’s diagnostic tools when answers disagree.
• Redirecting without a URL map. A redesign can create broken links and lost landing pages if old paths are not inventoried before launch.

When to revisit

Keep this website launch checklist as an operational document rather than a one-time note. Revisit it before seasonal campaigns, product launches, major content releases, domain renewals, hosting changes, and planned migrations. Review it whenever the team changes its deployment workflow, DNS provider, email platform, analytics tools, or security controls.

After launch, schedule a short follow-up review. Check uptime and error logs, certificate renewal, backup results, email deliverability, search indexing, form submissions, and the most important conversion path. Repeat the review after the first meaningful traffic increase or application change.

For the next launch, begin with four actions: export the current DNS records, create a tested backup, write down the rollback plan, and assign an owner to each test. Then verify domain resolution, HTTPS, email, redirects, forms, analytics, and backups before declaring the site live. That small record of decisions is often more valuable than a long list of unverified assumptions.