Website launch DNS and CDN cutover checklist for redesigns

A website redesign launch can pass visual QA and still fail at the cutover. DNS points to the wrong host, SSL does not cover the apex domain, a CDN caches the staging robots file, redirect rules never reach the edge, or analytics starts a new traffic story right when the client wants proof that launch went well.

This checklist is for website redesigns, Shopify builds, WordPress rebuilds, headless commerce launches, B2B websites, and multilingual sites where the live domain will move or the CDN configuration will change. Run it before launch week, again before the cutover window, and once more during the first day live.

Start with access and ownership. A clean technical plan does not matter if the team cannot edit DNS, approve SSL, change CDN settings, roll back a deployment, or reach the person who controls the registrar. This is where many launch delays begin.

Create a launch ownership table. Include the registrar, DNS provider, hosting platform, CDN, SSL issuer, email provider, analytics owner, consent platform, tag manager, and monitoring tool. For each item, record who can make changes, who approves changes, where credentials live, and what should happen if that owner is unavailable.

• Domains: apex domain, www subdomain, locale subdomains, old campaign subdomains, preview domains, and parked domains.
• DNS records: A, AAAA, CNAME, ALIAS, ANAME, MX, TXT, SPF, DKIM, DMARC, verification records, and any third-party service records.
• Infrastructure: production app, backup deployment, CDN zone, image CDN, redirect engine, web application firewall, and cache purge tool.
• Owners: registrar admin, DNS editor, developer, SEO owner, analytics owner, client approver, and rollback decision owner.

Do not wait until launch hour to discover that a record has a long TTL or that the certificate is still pending. Lower TTL at least one day before the cutover when the DNS provider allows it. Then confirm which records actually need to change and which records must stay untouched.

Prepare the SSL and CDN layer before traffic moves. The live domain should be attached to the production environment, certificates should be issued or ready to issue, HTTPS should redirect cleanly, and the CDN should know how to handle caching, compression, headers, redirects, images, and blocked paths.

• Lower relevant web records to a short TTL, then document when they were changed and when they can be raised again.
• Check certificate coverage for apex, www, locale subdomains, alternate domains, and any legacy domains that still receive traffic.
• Confirm HTTP to HTTPS, apex to www or www to apex, trailing slash policy, and locale routing before launch.
• Review CDN cache rules, bypass rules, security headers, image optimization, WAF settings, and preview or staging exclusions.

A cutover is not the right time for last-minute feature work. Freeze risky changes before the launch window and decide what counts as a launch blocker. The goal is not to avoid every small issue. The goal is to know which issues justify pausing, hotfixing, or rolling back.

Write rollback rules in plain language. For example: roll back if checkout is blocked, lead forms fail, SSL is invalid, the homepage returns a non-200 status, key redirects fail, robots blocks the site, or the CMS cannot publish critical content. If a rollback is technically possible but operationally confusing, the plan is not finished.

• Freeze code, theme settings, plugin updates, DNS changes, redirect imports, CMS migrations, app installs, and tag manager changes during the window.
• Save the previous DNS records, previous CDN rules, previous deployment URL, previous redirect set, and previous robots and sitemap output.
• Define rollback owner, decision deadline, communication channel, and exact rollback steps.
• Keep a launch log with timestamp, changed item, person responsible, expected effect, verification result, and next check.

Before DNS changes, verify the new site through its production preview or temporary domain. This is where the redesign launch connects with technical SEO. Redirects, canonicals, hreflang, robots rules, sitemap output, structured data, and status codes should already be correct before real traffic and crawlers arrive.

Use a sample set, not only the homepage. Include high-traffic URLs, revenue pages, old URLs from the redirect map, localized pages, collection or category pages, blog posts, lead pages, and at least one intentionally removed URL. The sample should represent the real risks of the migration.

• Redirects: old URLs land on the intended new URLs with the right status and without unnecessary chains.
• Indexability: production pages are indexable, staging pages are blocked, and no staging noindex rule is cached into the live path.
• Canonical and hreflang: each page points to the intended canonical and correct language or market alternates.
• Sitemaps and robots: sitemap URLs use the final domain, robots references the correct sitemap, and blocked paths are intentional.

During the cutover, make the smallest possible DNS change first. Update the records that move web traffic, then verify propagation from multiple networks. Avoid changing unrelated email, verification, or third-party service records unless they are part of the launch plan.

After DNS starts resolving to the new stack, verify the live domain before announcing launch. Test the apex and www versions, HTTP and HTTPS versions, important locales, key old URLs, and the primary conversion path. If the site uses a CDN, purge only what is needed and confirm the edge is serving the intended production response.

• Change the planned web records and record the exact timestamp.
• Check DNS resolution from multiple public resolvers and at least one real browser session.
• Verify SSL, redirects, status codes, cache headers, canonical tags, robots, sitemap, and Open Graph output on the final domain.
• Keep support, SEO, development, and client owners in the launch channel until the first verification pass is complete.

A site can load while important systems fail behind the page. After the cutover, test the workflows that depend on the live domain, cookies, CORS rules, webhooks, API origins, payment callbacks, search indexes, form destinations, and tag manager triggers.

For ecommerce and B2B websites, test business paths before polishing minor visual issues. Add to cart, checkout, lead forms, booking flows, quote requests, site search, downloads, consent mode, analytics events, and CRM routing should all be verified from the final domain.

• Commerce: product page, variant selection, cart, checkout, payment method, order confirmation, and email notification.
• B2B: lead form, file upload, booking embed, CRM routing, thank-you page, spam protection, and notification email.
• Headless or app-driven sites: API origin, CORS, preview cookies, webhooks, search index, image delivery, and revalidation behavior.
• Tracking: page view, form submit, checkout step, purchase, consent state, UTM preservation, and server-side events where relevant.

The cutover is not finished when the homepage loads. DNS propagation, crawler behavior, CDN cache, redirects, third-party callbacks, and analytics can reveal issues over the first few hours and days. Treat monitoring as a launch phase, not a nice-to-have.

Create a short monitoring schedule for the first 72 hours. Check uptime, SSL, 404s, redirect errors, server errors, Core Web Vitals field signals when available, analytics events, sitemap fetches, Search Console coverage, product or lead conversion paths, and client-reported issues.

• First hour: uptime, SSL, homepage, key templates, old URL samples, forms or checkout, analytics, and cache headers.
• First day: 404 reports, redirect misses, sitemap fetch, robots fetch, crawl spikes, CDN errors, and conversion tracking.
• First 72 hours: search console data, analytics anomalies, support tickets, client feedback, performance metrics, and long-tail URL issues.
• After stabilization: raise TTL, clean temporary access, archive launch logs, and add any missed checks to the maintenance plan.