Business Website Launch Checklist: Domains, Hosting, DNS, Security, and Go-Live Steps

Overview

Before starting, assign an owner for each launch task and record the expected result, person responsible, deadline, and status. A simple shared document or project board is enough. The goal is to make invisible dependencies visible before they affect customers.

Keep a written inventory of the business domain, registrar account, hosting account, DNS provider, email provider, content management system, analytics tools, and third-party services. Domain registration and hosting are separate services, even when you buy domain and hosting together. Knowing which account controls each service is essential during a launch or emergency.

For a new website, establish the production environment before changing public DNS. For a migration, create a complete backup and test the new environment while the existing site remains available. Do not treat the DNS switch as the first test of the new site.

Use this status pattern throughout the checklist:

• ☐ Not started
• ◐ In progress or awaiting verification
• ☑ Verified in the appropriate environment

For background on the relationship between the two services, see domain vs. hosting for business owners. If you are selecting a name rather than launching an existing one, review how to choose a domain name for a business that can scale.

What to track

1. Domain and account ownership

• ☐ Confirm the primary domain and all important alternate domains.
• ☐ Verify the registrar account is controlled by the business, not an individual’s personal email.
• ☐ Check the renewal date, payment method, administrative contact, and recovery email.
• ☐ Confirm domain privacy protection and transfer or account-lock settings where appropriate.
• ☐ Record who can approve DNS, registrar, and hosting changes.

Do not rely on memory for renewal information. A domain can remain technically functional while its ownership, payment, or recovery details become outdated. Review the account before launch and include it in your recurring operations calendar. For a reminder of the risks, see what happens if you forget to renew a domain.

2. Hosting and production environment

• ☐ Confirm the hosting plan supports the site’s application, database, traffic pattern, and storage needs.
• ☐ Create the production site separately from staging or development environments.
• ☐ Verify the correct runtime, software versions, extensions, and environment variables.
• ☐ Set resource alerts or review available monitoring provided by the host.
• ☐ Confirm how support is reached and which people are authorized to request changes.

The right business web hosting arrangement depends on the site and the team operating it. A small brochure site may need a simpler setup, while a growing application may require managed hosting, VPS hosting, or another scalable arrangement. Compare the actual requirements rather than choosing solely by storage or a stated uptime guarantee.

3. DNS records and email

• ☐ Identify the authoritative nameservers and DNS provider.
• ☐ Confirm the web records point to the intended production host.
• ☐ Preserve required MX records for business email.
• ☐ Review TXT records used for email authentication, verification, or other services.
• ☐ Check subdomains for applications, portals, stores, forms, or staging environments.
• ☐ Lower DNS record time-to-live ahead of a planned migration only when it supports your change plan.

DNS changes can affect different users at different times, so document the old and new values and define a rollback plan. Use the guide to DNS record types for business owners when reviewing A, CNAME, MX, and TXT records. If you need a procedural walkthrough, see how to point a domain to a new host.

4. Security and access

• ☐ Enable HTTPS and verify the SSL certificate covers the live domain and relevant hostnames.
• ☐ Test HTTP-to-HTTPS redirection and remove mixed-content warnings.
• ☐ Use unique passwords and multi-factor authentication for registrar, hosting, CMS, email, and analytics accounts where available.
• ☐ Remove unused administrator accounts, plugins, integrations, and test credentials.
• ☐ Confirm backups are running and that someone knows how to restore one.

SSL is not a one-time launch task. Record certificate ownership, renewal responsibility, and the domains covered. See SSL certificates for business websites for a focused review of certificate types, costs, and renewal rules.

5. Content, redirects, and measurement

• ☐ Check page titles, headings, contact details, opening hours, pricing, and legal information.
• ☐ Test forms, confirmation messages, file downloads, search, navigation, and checkout or booking flows.
• ☐ Create a redirect map for changed or removed URLs, especially during a migration.
• ☐ Confirm canonical URLs, indexability settings, XML sitemap, and robots directives match the launch plan.
• ☐ Verify analytics, conversion events, consent settings, and search monitoring.
• ☐ Test the site on current desktop and mobile browsers, including slower connections where practical.

Pay particular attention to pages that receive links, search traffic, or direct customer visits. A redesign can look complete while silently breaking old URLs or measurement events.

Cadence and checkpoints

One to two weeks before launch

Freeze major content and code changes long enough to create a reliable final test. Complete the domain, hosting, DNS inventory, backup plan, redirect map, and access review. Confirm the launch window, responsible people, communication channel, and rollback decision-maker.

One to two days before launch

Run the production candidate through functional, visual, performance, accessibility, and security checks. Confirm SSL, email delivery, forms, payment or booking flows, analytics, and redirects. Take a fresh backup of the existing site and database if this is a migration. Record the exact DNS values that will change.

Launch window

1. ☐ Confirm the final backup and that the new production environment is ready.
2. ☐ Apply the planned DNS or hosting change; avoid unrelated edits.
3. ☐ Test the primary domain, key pages, forms, email, and important subdomains.
4. ☐ Check HTTPS, redirects, status codes, analytics, and search visibility settings.
5. ☐ Record the time of each change and any unexpected result.

Use more than one network or DNS lookup method when checking propagation. A successful result from one computer does not prove that every resolver has the same answer.

First 24 to 72 hours

Monitor availability, server errors, response times, form submissions, email, traffic, conversions, and important logs. Compare the results with a normal period where possible, but interpret early traffic carefully because launch activity itself can change visitor behavior. Keep the old environment available for the agreed rollback period if your migration plan requires it.

First 30 days

Review broken links, crawl errors, redirect chains, search indexing, mobile usability, backup completion, security alerts, and resource consumption. Fix recurring issues rather than manually correcting the same symptom each day. Document what changed and update the ownership and recovery records.

How to interpret changes

When something changes after launch, first identify whether the problem is global or limited to one device, network, page, user role, or service. This narrows the likely cause.

• The site is unreachable: check DNS resolution, hosting status, certificate validity, server errors, and recent configuration changes.
• Email stops arriving: check MX records and email authentication records before changing web hosting settings. Web and email may use different providers.
• Traffic falls: inspect redirects, indexability, canonical tags, analytics collection, and the most important landing pages before assuming demand has changed.
• Pages become slow: compare server response time, page weight, database activity, third-party scripts, and hosting resource use.
• Only some users see an old site: review DNS answers, caching, and the timing of the change rather than repeatedly editing records.
• Forms or conversions fall: submit a real test, inspect confirmation and notification delivery, and verify that the analytics event still fires.

For migrations, keep a change log with the original value, replacement value, timestamp, and verification result. This prevents guesswork when several systems are involved. If the issue affects availability or data integrity, prioritize restoration from a known-good backup and escalate to the hosting or application owner.

Track meaningful operating signals rather than every available number. A practical set includes uptime, important error rates, page response times, backup status, certificate and domain renewal dates, form delivery, and key conversion events. For a deeper monitoring framework, see website uptime monitoring for small businesses.

When to revisit

Use this checklist at every new website launch and hosting migration, but also schedule recurring reviews. A monthly check is appropriate for small businesses that make regular site changes; a quarterly review may be sufficient for a stable, low-change site. Teams with frequent releases should include the relevant checks in every deployment process.

Monthly review

• ☐ Check domain, hosting, SSL, and payment renewal dates.
• ☐ Confirm backups completed and test a restoration on a planned schedule.
• ☐ Review uptime, errors, speed, forms, email, and conversion tracking.
• ☐ Remove unused accounts and confirm current owners still have access.

Quarterly review

• ☐ Re-test the complete customer journey on mobile and desktop.
• ☐ Review DNS records and remove obsolete verification or subdomain entries.
• ☐ Check redirects, sitemap, indexability, broken links, and high-value pages.
• ☐ Reassess hosting capacity against current traffic, storage, and application needs.
• ☐ Update the recovery plan, contact list, inventory, and launch documentation.

Revisit the checklist immediately after a rebrand, domain transfer, hosting change, CMS upgrade, security incident, major redesign, email-provider change, or new subdomain launch. Start each review by comparing the current setup with the last approved version. That simple habit makes changes easier to explain and problems easier to reverse.

For a final migration-specific reference, use the website migration checklist for moving hosting providers. Then save this article with your operational documentation, assign the next review date, and leave the status boxes marked so the next launch begins with evidence rather than assumptions.