How to Point a Domain to Shopify, Squarespace, Wix, or Webflow

Overview

What you are doing, technically, is separating two jobs: your domain registrar holds the name, while your website platform serves the site. To point a domain to a site builder, you usually update DNS at your registrar or DNS host so that requests for your domain resolve to the builder's infrastructure.

In most cases, the setup involves some combination of:

• An A record for the root domain, such as example.com
• A CNAME record for www.example.com
• A domain verification step inside the site builder
• An SSL provisioning step after DNS is correctly pointed

The exact values differ by platform and can change over time, so the safest workflow is not to memorize record values. Instead, use a repeatable process:

1. Confirm where DNS is actually hosted.
2. Collect the current records before changing anything.
3. Identify whether the root domain, the www host, or both should point to the builder.
4. Preserve MX, TXT, and other non-web records so email and verification services keep working.
5. Wait for propagation, then verify the site builder connection and SSL status.

If you need a refresher on record types, see How to Set Up DNS Records for a New Website: A, CNAME, MX, TXT, and More.

Before you start, it helps to answer four questions:

• Who is the registrar?
• Who is the DNS provider?
• What currently uses the domain, including email or subdomains?
• Which hostname will be primary: example.com or www.example.com?

That last question matters more than many first-time setups assume. Site builders often support both root and www, but they may recommend one as the canonical version and redirect the other. Decide this early so your redirects, SSL, and external links stay consistent.

Checklist by scenario

Use the scenario below that matches your starting point. The details vary by provider, but the checklist stays useful even when individual record values change.

Scenario 1: You bought the domain elsewhere and want to point it to Shopify

This is the common "point domain to Shopify" case: your domain stays at the registrar you already use, and Shopify becomes the website host.

1. Open your Shopify domain connection instructions first. Do this before editing DNS so you work from the current values shown in your account, not from an old screenshot or blog post.
2. Find your DNS control panel. It may be at the registrar, or your nameservers may point to a separate DNS provider.
3. Export or copy existing DNS records. Capture A, AAAA, CNAME, MX, TXT, and any subdomain records.
4. Update the root domain records as instructed by Shopify. This is typically an A record setup for the apex domain.
5. Update the www host as instructed. This is often a CNAME pointing to a Shopify-managed hostname.
6. Do not delete MX or TXT records unless you intend to replace them. If your business email uses the domain, those records must remain intact.
7. Verify the domain inside Shopify. Most builders need you to confirm or finish the connection from their dashboard.
8. Check SSL and redirection behavior. Make sure your preferred domain version redirects correctly.

Platform caveat: if an AAAA record already exists for the root domain and the platform does not support that configuration, remove or update it according to the platform's current instructions. Old IPv6 records are a frequent source of intermittent behavior.

Scenario 2: You want to connect a domain to Squarespace

When you connect domain to Squarespace, the process usually includes web records plus one or more verification records. That verification step is easy to overlook.

1. Open the domain connection flow in Squarespace. Note every required record, including any verification CNAME.
2. Check whether your domain already has a website on another host. If yes, plan for a cutover window rather than changing records casually during active traffic hours.
3. Replace only the web-serving records required for Squarespace. Leave unrelated email and service records untouched.
4. Add any verification records exactly as shown. Watch for host formatting differences such as @, blank apex fields, or fully qualified names.
5. Set your primary domain in Squarespace after DNS is live. Decide whether the site should resolve to root or www.
6. Test both versions in a private browser window. Confirm that they land on the same canonical site.

Platform caveat: some control panels automatically append the domain name to a host field. If you paste a full hostname where a short host is expected, you can accidentally create a malformed record. Review the saved result after submitting it.

Scenario 3: You are doing a Wix custom domain setup

Wix often gives users more than one path, such as connecting by nameservers or by pointing specific records. The better option depends on how much control you want over DNS.

1. Choose between nameserver connection and point-by-record connection. If you use custom email, third-party subdomains, or many TXT records, point-by-record often gives you finer control.
2. If using nameservers, understand the tradeoff. Moving nameservers usually moves full DNS authority to the new provider. That can simplify website management but requires you to recreate any non-default records you still need.
3. If using point-by-record, follow the current Wix values shown in your account.
4. Inventory all email-related records first. This includes MX, SPF, DKIM, and any domain verification TXT records.
5. Complete the connection inside Wix and wait for SSL issuance.
6. Retest forms, email delivery, and redirects after the site is live.

Platform caveat: nameserver changes are broader than DNS record edits. If your team assumes they are equivalent, you can accidentally disconnect email or other services. Treat nameserver changes like a migration event, not a minor tweak.

Scenario 4: You need a Webflow DNS setup

Webflow is popular with designers and developers, and its domain connection flow is usually clear, but there are still a few areas worth checking carefully.

1. Add the custom domain in Webflow first. Let Webflow show you the records currently required for your project.
2. Update the DNS zone at your current provider. This commonly includes root records plus a www CNAME.
3. Publish the site to the custom domain after records are in place. DNS can point correctly while the project itself still is not published to that hostname.
4. Set the default domain and redirect preference. Pick either root or www and keep it consistent.
5. Test SSL, static assets, and any custom code integrations.
6. If you use multiple subdomains, verify that no broad DNS edits affected them.

Platform caveat: developers sometimes focus only on the top-level domain and forget environment-specific subdomains such as staging, app, docs, or API endpoints. Review the full zone before and after publishing.

Scenario 5: You are moving from one site builder to another

This is where mistakes are most likely, because the domain is already live and may have dependencies beyond the website itself.

1. Lower risk by planning the cutover. If your DNS provider allows it, reduce TTL in advance for the records you plan to change. Do this early enough that the lower TTL has time to take effect.
2. Copy the entire current zone. Keep a rollback record of what is live now.
3. Prepare the new site fully before changing DNS. Content, redirects, forms, analytics, and SEO settings should be ready first.
4. Change only the required records. Avoid broad cleanup until the site is confirmed healthy.
5. Verify the new platform's SSL and redirect behavior.
6. Monitor uptime and endpoint behavior for the next 24 to 48 hours. A simple monitor can catch intermittent failures you might miss manually. See Website Uptime Monitoring Tools Compared for Small Teams.

If the domain move is part of a larger host change, this related checklist may help: Website Migration Checklist: Move Your Site to a New Host Safely.

What to double-check

Most domain connection failures come from a small set of preventable issues. Before assuming propagation is the problem, verify these items one by one.

1. DNS host versus registrar

Buying a domain and hosting its DNS are separate functions. You may have registered the name at one company while delegating nameservers to another. If edits are not taking effect, confirm that you are changing records at the authoritative DNS provider, not just the registrar account where you bought the domain.

2. Root domain and www behavior

Many users update one hostname and forget the other. Decide which should be canonical, then make sure both resolve correctly and redirect to the chosen version.

3. Email records

Website records and email records are independent. Changing A or CNAME records for web traffic should not require deleting MX records. Also keep SPF, DKIM, and verification TXT records unless you intentionally replace them. If email matters for the domain, review your setup against Business Email Setup With Your Domain: Google Workspace, Microsoft 365, and Zoho Compared.

4. SSL status

The site may begin loading before the certificate is fully issued. Test both HTTP and HTTPS, and verify that the builder's SSL status shows healthy before concluding the setup is complete. For more background, see SSL Certificate Guide: Types, Costs, Renewal, and Installation Basics.

5. Proxy and CDN settings

If your DNS provider offers proxying, acceleration, or traffic filtering, understand whether the site builder expects DNS-only records during verification. A mismatched proxy setting can complicate validation or SSL provisioning.

6. TXT verification records

Some builders require a verification record in addition to normal web records. Missing this step can leave the domain in a half-connected state even though the site appears to load.

7. Existing subdomains

Changing the main site should not accidentally overwrite blog, shop, mail, app, or other subdomains. Review the whole zone file, not just the root and www entries.

Common mistakes

Use this section as a pre-flight check before you save DNS changes.

• Replacing nameservers when only A or CNAME edits were needed. This is one of the easiest ways to break unrelated services.
• Deleting MX records during web setup. Your website may come online while email quietly stops working.
• Editing the wrong zone. This happens often with multiple domains in one account or separate DNS providers.
• Using outdated platform record values from old tutorials. Always start from the records currently shown inside your platform account.
• Saving malformed hostnames. Some dashboards want www; others want the full hostname. Double-check how your provider formats records.
• Ignoring AAAA records. An old IPv6 record can override expectations in some environments.
• Forgetting to publish the site after DNS is connected. The domain can point correctly while the project is still unpublished.
• Not setting a primary domain. If both root and www serve separately without redirect rules, you can create duplicate URL paths and a messy user experience.
• Testing too early and trusting one browser result. Use private browsing, multiple networks if possible, and DNS lookup tools when troubleshooting.

If you are still shopping for a registrar before this setup begins, it is worth reviewing privacy and lifecycle details, not just first-year pricing. A good starting point is Domain Privacy Protection: Is WHOIS Privacy Worth It?.

When to revisit

This topic is worth revisiting whenever your domain workflow changes, even if the site already appears stable. A domain connection is not really a one-time task; it is part of ongoing DNS management.

Recheck your setup in these situations:

• Before a redesign or replatforming project. Confirm the current DNS baseline before anyone changes records.
• Before seasonal launches or campaigns. If the domain will support paid traffic, promotions, or product launches, verify redirects, SSL, and uptime in advance.
• When email providers change. Website DNS edits and email edits often collide during migrations.
• When a teammate changes nameservers or registrar settings. Even one control-panel change can move authority away from the place you expect.
• When the site builder updates its connection workflow. Record requirements and verification methods can change over time.
• After domain transfer. A transfer should preserve the domain registration, but DNS hosting and nameserver assumptions still need to be verified.

For a practical maintenance routine, keep a short domain runbook with:

1. The registrar name and login owner
2. The authoritative DNS provider
3. The current nameservers
4. A copy of all active DNS records
5. Your chosen canonical domain version
6. The website platform connected to the domain
7. The email provider and required MX/TXT records
8. The date of the last successful verification

If you want one final action list to bookmark, use this:

1. Open the site builder's current connection instructions.
2. Confirm where DNS is hosted.
3. Back up the existing zone.
4. Update only the web records required for the builder.
5. Preserve email and verification records.
6. Verify the domain inside the platform.
7. Check SSL, redirects, and publishing status.
8. Test root, www, and any critical subdomains.
9. Monitor the site after cutover.
10. Document the final configuration for the next change.

That process works whether you are trying to point a domain to Shopify, connect a domain to Squarespace, complete a Wix custom domain setup, or finish a Webflow DNS setup. The platform-specific values may change, but the operational discipline should not.