The Complete Website Launch Checklist: Domains, DNS, SSL, SEO, Speed, and Backups

Overview

A reliable launch has three stages: preparing the site, connecting its infrastructure, and validating the live experience. Whether you use a website builder, a content management system, or a static site workflow, the same principles apply. You need a clear version of the site, a controlled domain change, secure transport, working navigation and forms, and a way to detect problems after launch.

Start by deciding what “launch” means for this project. A brochure site may need only a few public pages, a contact form, analytics, and search indexing. A store, membership site, or application may also require payment testing, account permissions, transactional email, database checks, and a rollback plan. Write down the launch scope before changing DNS so that unfinished features do not quietly become production issues.

Choose hosting that matches the site’s technical needs rather than selecting the most complex setup by default. Managed hosting can reduce routine administration, while cloud infrastructure may provide useful control over deployments, scaling, logs, and backups. For a small business site, check whether the plan includes practical essentials such as automated SSL, a CDN option, backups, monitoring, staging, and support for the applications you intend to run.

If you are still choosing an implementation, compare the trade-offs in Website Builder vs CMS vs Static Site Generator. The best choice is the one your team can update, secure, test, and restore consistently.

Checklist by scenario

For a new website or website builder project

• Confirm the final site name, primary domain, preferred spelling, and any required redirects from alternate domains.
• Complete the essential pages: home, about, services or products, contact, privacy information, and any legal or operational pages appropriate to the project.
• Review every page on a phone, tablet, and desktop-sized viewport. Check headings, spacing, buttons, menus, images, and embedded content.
• Replace placeholder copy, sample images, default titles, dummy links, and test addresses.
• Set a consistent page title, meta description, canonical URL where appropriate, and descriptive heading structure.
• Test the main conversion path from start to finish. A visitor should be able to understand the offer, take the intended action, and receive confirmation.
• Check that images have useful alternative text when they convey information, while decorative images are not given misleading descriptions.
• Preview shared links if your platform supports social or messaging metadata, and confirm that the preferred image and description appear correctly.

For connecting an existing domain to new hosting

• Record the current DNS records before making changes. Include A, AAAA, CNAME, MX, TXT, and any verification records.
• Confirm whether DNS is managed at the registrar, the hosting provider, or a separate DNS service. Make changes in the authoritative location.
• Use the hosting provider’s documented target values for the root domain and the www subdomain. Do not guess whether an A record or CNAME is required.
• Protect email records. Changing nameservers or removing MX, SPF, DKIM, or DMARC records can interrupt mail even when the website works.
• Lowering DNS TTL before a planned migration can make changes easier to adjust, but it does not guarantee instant global propagation.
• Keep the old hosting environment available until the new site, forms, media, and data have been checked on the live domain.
• Test both the root domain and www version, then choose one canonical version and redirect the other.

For a detailed connection process, see this guide to SSL, certificates, redirects, and mixed content. For migrations, also document the old URLs and map them to relevant new destinations rather than sending every retired page to the homepage.

For an existing site migration

• Create a full backup of files, databases, media, configuration, and DNS-related records before migration.
• Build or copy the site into a staging environment and compare representative pages, templates, menus, search, forms, and integrations.
• Export a URL list from the old site and identify pages that need permanent redirects.
• Check differences in PHP, runtime, database, server, or build-tool versions before switching traffic.
• Test login, checkout, subscriptions, contact forms, webhooks, scheduled jobs, and email delivery where relevant.
• Plan a rollback: define who can change DNS or deployment configuration, what condition triggers rollback, and which backup will be used.

The website backup strategy checklist can help you separate backup creation from restore testing, which should be treated as two different tasks.

For a launch focused on search visibility

• Confirm that important pages return a successful response and are not accidentally password-protected or blocked by a staging rule.
• Generate or verify the XML sitemap and submit it through the relevant search management tool if one is used.
• Review robots.txt so it does not block essential pages, resources, or the entire site.
• Check canonical URLs, internal links, redirects, pagination where applicable, and indexability directives.
• Use one preferred URL format and ensure HTTP redirects to HTTPS.
• Verify structured data only where it accurately describes visible page content and can be maintained.

Use the robots.txt tester guide when reviewing crawl rules, and keep the separate SEO, analytics, forms, and indexing checklist available for a more specialized audit.

What to double-check

Domain, DNS, and email

• Verify the authoritative nameservers and confirm that records are published where expected.
• Check A and AAAA records together. An incorrect IPv6 record can send some visitors to the wrong server even when IPv4 appears correct.
• Confirm that the www record points to the intended site and that no obsolete provider record remains.
• Do not remove mail-related TXT or MX records during a website change. Test sending and receiving from more than one mailbox.
• Record the date, purpose, and owner for unusual DNS records so future maintenance does not become guesswork.

SSL and browser behavior

• Open the site using HTTPS and inspect the certificate hostname, validity, and renewal status in the browser.
• Redirect HTTP to HTTPS and test deep links, not just the homepage.
• Look for mixed-content warnings caused by images, scripts, fonts, stylesheets, or embeds still loading over HTTP.
• Confirm that forms, APIs, webhooks, and third-party integrations accept the HTTPS URLs.

Performance and availability

• Compress and resize images before upload, and use modern formats when your platform and browser support make that practical.
• Remove unused plugins, scripts, fonts, and tracking tags. Each dependency adds maintenance and may affect loading.
• Check caching, CDN behavior, compression, redirects, and server response time with more than one representative page.
• Test a page with a slow connection or a lower-powered device. A fast administrative preview does not represent every visitor.
• Set uptime monitoring and decide who receives alerts. Monitoring is useful only when someone knows how to respond.

For operational follow-through, review the uptime monitoring guide. Keep a short incident log containing the time, symptom, suspected cause, action taken, and result.

Security and data

• Remove unused administrator accounts and require strong, unique credentials for remaining accounts.
• Enable multi-factor authentication where the platform supports it, especially for hosting, DNS, email, analytics, and payment systems.
• Update the CMS, themes, plugins, dependencies, and server components before launch, then establish an update owner.
• Confirm that backups run automatically, are protected from the live server, and can be restored to a test environment.
• Limit public access to staging sites, dashboards, debug pages, environment files, and development endpoints.

WordPress users can use the WordPress security hardening checklist as a platform-specific supplement.

Common mistakes

Changing nameservers without documenting email. Website owners often focus on the web record and forget that email depends on a separate group of DNS records. Export or record the complete DNS zone first.

Launching with staging controls still active. A no-index directive, password gate, or broad robots.txt block may be useful during development but harmful after publication. Review these settings on the production environment.

Testing only the homepage. Broken internal links, missing images, invalid redirects, and form failures often appear on deeper pages. Test a representative sample, including the most important conversion and support paths.

Assuming a backup is a recovery plan. A file that exists is not necessarily usable. Restore a copy, verify the database and uploads, and document the recovery steps.

Installing every optimization tool at once. Make one controlled change at a time and measure its effect. Overlapping caching, image, security, and script tools can create harder-to-diagnose problems.

Publishing analytics without testing events. Check that the expected page views, form submissions, downloads, or purchases are recorded once rather than duplicated or omitted. Keep privacy and consent requirements in the project’s review process.

Using online utilities with sensitive production data. Developer tools such as a JSON formatter, JWT decoder, or base64 tool can be useful for troubleshooting, but never paste credentials, private keys, customer data, or live tokens into a tool unless its security and data-handling model are appropriate. The JWT decoder guide explains safer inspection practices.

When to revisit

Run this checklist before the initial launch, after a domain or hosting migration, and whenever a major redesign changes URLs, templates, forms, or integrations. Revisit it before seasonal campaigns or other high-traffic periods, when the cost of a broken checkout, form, or landing page is higher. It is also useful after changing DNS providers, switching SSL management, adding a CDN, installing a major plugin, or moving from one deployment workflow to another.

After launch, perform a short review at a defined interval rather than waiting for a visitor to report a problem. Check uptime alerts, backup results, certificate renewal, software updates, forms, key pages, analytics, and search coverage. Review performance after adding substantial media or third-party scripts. Review security after staff changes, new integrations, or a suspected incident.

Keep a versioned launch record with the production URL, DNS owner, hosting account, deployment steps, rollback method, backup location, monitoring contact, and last test dates. Update it whenever the workflow or tools change. For routine documentation and technical notes, a Markdown editor and preview tool can make the checklist easier to maintain and share.

The final action is simple: assign each unchecked item to a person, record the evidence of completion, and set a date for the next review. A website launch is not one switch; it is a controlled handoff from development to a service that people can find, access, trust, and use.