Website launch day, without the DNS panic.

The technical part of a launch is almost always the easy part. Push the build, point the domain, propagate. The hard part is logistical — getting the right access from the right people, in the right order, before launch day.

We've turned this into a checklist that runs from kickoff to launch +1. If you're working with us, you'll see this. If you're working with anyone else, steal it.

What we ask for at kickoff.

Day one, before any design or code starts. We ask the client to confirm — in writing — who controls the following:

• The domain registrar. Where the domain was bought. GoDaddy, Namecheap, Google Domains (now Squarespace), etc.
• The DNS host. Sometimes this is the same as the registrar. Sometimes it's Cloudflare, Route 53, or a separate DNS service. The DNS host is where the records actually live.
• The current hosting provider. WP Engine, Webflow, Shopify, custom server. Wherever the existing site is served from.
• The email provider. Google Workspace, Microsoft 365, or something self-hosted. This matters because changing DNS can break email if you're not careful.
• Any third-party DNS records. Verification TXT records, SPF, DKIM, DMARC, custom subdomains pointing to other services.

Half the time, the client doesn't know the answer to one or more of these. That's fine. That's why we ask early.

The access we actually need.

We strongly prefer being added as a delegate or admin user with our own credentials, not sharing logins. Here's what we typically need:

1. Domain registrar admin or delegated access — to update nameservers if needed.
2. DNS host admin access — to add and edit A, CNAME, TXT, and MX records on launch day.
3. New hosting platform access — to deploy and verify the build.
4. Old hosting platform access — read-only is fine. We need it to confirm content parity and capture redirects.
5. Google Search Console and Google Analytics — to capture pre-launch baselines and add the new property.
6. Any verification accounts — Google Business Profile, Bing Webmaster, social platforms with site verification records.

What we do two weeks out.

This is the window where most launches get saved or lost. Two weeks before go-live we do the following:

• Confirm DNS access in a live test. We'll add a temporary TXT record and remove it. If we can do that, we can launch.
• Document the current DNS zone in full. Every record. Every TTL. Screenshot or export.
• Lower TTLs. Drop TTLs on records we plan to change down to 300 seconds, 48 hours before launch. This means the cutover propagates fast.
• Stage the new records. We pre-write the exact A and CNAME records that will go live, so launch day is paste-and-confirm.
• Verify email won't break. MX, SPF, DKIM, DMARC. All preserved. Test email send-and-receive on a staging domain.

Launch day itself.

On launch day, the actual cutover takes about ten minutes if everything else is right. Here's the order:

1. Final QA on the new site, on its temporary URL.
2. Confirm SSL is provisioned on the new host.
3. Update A and CNAME records in DNS.
4. Watch propagation in real time (we use whatsmydns.net and DNS lookup tools, not vibes).
5. Verify email is still flowing.
6. Submit the new sitemap to Google Search Console.
7. Spot-check redirects from the old URL structure to the new one.

What we watch for in the first 48 hours.

The launch isn't done at cutover. The first 48 hours are when issues surface — bot traffic, broken redirects, indexing weirdness, email deliverability bumps. We monitor analytics, error logs, and email logs aggressively in that window.

We also raise TTLs back to normal values once we're confident things are stable.

Every chaotic launch we've ever inherited had the same root cause: the agency didn't ask about access until the week of go-live. Don't be that agency, and don't hire that agency.