Setting Up a Custom Domain for Your Storefront: A Checklist

Connecting a custom domain to a storefront is a small, mostly one-time task that's still worth doing carefully, because the ways it goes wrong tend to cause visible downtime right when customers are trying to reach your store — not a quiet background failure, a "the site is down" failure.

Check 1: DNS record type matches what the platform actually needs

Most storefront platforms want either an A record pointing to an IP address or a CNAME pointing to a platform-provided hostname — and using the wrong type, or pointing it at the wrong target, is the single most common setup mistake. Double-check the exact record type and target value the platform's domain settings actually specify, rather than assuming it's the same as a previous setup you've done elsewhere.

Check 2: propagation time, planned for, not assumed instant

DNS changes can take anywhere from a few minutes to 24-48 hours to propagate fully depending on your registrar and existing TTL settings. Switching a live, already-selling storefront's domain without accounting for this window — expecting it to be instant — is how sellers end up with a confusing few hours where some visitors see the new setup and others still see the old one.

Check 3: SSL certificate issued before announcing the new domain

A domain resolving correctly but without a valid SSL certificate yet shows visitors a security warning instead of your storefront — which is worse for trust than the domain simply not resolving at all. Confirm the certificate has actually issued and is active before pointing any marketing or announcements at the new domain.

Check 4: old domain redirect, not just abandonment

If you're migrating from an existing domain (a Shopify default subdomain, say) to a custom one, set up a redirect from the old URL to the new rather than just letting the old one go dead — anyone who bookmarked the old link, or any existing backlinks from other sites, should land somewhere real, not a dead page.

Check 5: test checkout specifically, not just the homepage

The homepage loading correctly on the new domain doesn't guarantee checkout works — payment gateway callbacks and webhook URLs sometimes need their own update when a domain changes. Run a real test order through to completion before considering the migration done.

Why this is worth a checklist rather than winging it

Every individual step here is simple. What causes real downtime is doing them out of order — announcing a new domain before SSL has issued, or switching DNS without planning for the propagation window on a storefront that's actively taking orders. A short checklist, followed in order, turns a one-time task that could cause a bad afternoon into one that genuinely takes twenty minutes.

See My Store: building your own storefront for the fuller context on where custom domains fit. Start free to set one up on your own storefront.

A concrete migration scenario, done right

A seller moving from a Shopify-provided subdomain to a custom domain plans the switch for a weekday morning rather than during a weekend sales push, specifically because of the propagation window — if something's misconfigured, there's time to catch and fix it before the next high-traffic period rather than discovering a problem during peak hours. DNS records are set up two days ahead of the planned cutover where the platform allows pre-configuration, giving propagation time to complete before the actual switch rather than trying to do DNS changes and the switch itself in the same hour.

SSL certificate issuance is confirmed active — not just "requested" — before any announcement goes out on social media or email. A test order is placed and walked all the way through checkout and confirmation on the new domain specifically, not just a homepage load check, catching a webhook URL that still pointed at the old domain before any real customer hits the same issue.

A concrete example of what goes wrong when this is rushed

A seller switches DNS and immediately posts the new domain across social channels, not accounting for propagation. For the next several hours, some visitors (depending on their ISP's DNS caching) see the new setup correctly while others still resolve to the old address or get an intermittent error — a confusing, inconsistent experience that looks like the site is broken, right when a social media post is actively driving traffic to it. The fix isn't complicated — wait for propagation before announcing — but it's exactly the kind of step that gets skipped under the excitement of launching something new.

A final check worth adding to this list

After the switch, monitor for 24-48 hours specifically for anything unusual — a spike in failed checkout attempts, an unexpected drop in traffic that might indicate a DNS issue affecting a subset of visitors. Most domain migrations that go wrong don't fail obviously; they fail quietly for a fraction of visitors whose specific DNS resolver hadn't caught up yet, which is exactly the kind of problem a short monitoring window after the switch is meant to catch.