How to Connect a Domain to WordPress, Shopify, Squarespace, and Wix

Overview

This article will help you point domain to website builder platforms and WordPress setups without losing track of DNS, email, or HTTPS along the way. The exact buttons inside each provider dashboard can change over time, but the connection models stay fairly consistent. That is why the most useful way to approach domain setup is not to memorize one interface. It is to understand the few recurring variables that every domain connection depends on.

At a high level, connecting a domain means telling the internet where requests for your domain should go. You usually do that in one of two ways:

• Change nameservers so the platform manages your DNS zone.
• Keep your current DNS provider and update only specific DNS records such as A, CNAME, or occasionally TXT records.

This is where many beginners get stuck on nameservers vs DNS. Nameservers decide who controls the zone. DNS records decide how the domain behaves inside that zone. If you change nameservers, you move management of all records to the new DNS host. If you only edit records, you keep control where it already exists.

Before you connect a domain to any platform, make sure you know:

• Where the domain is registered
• Who currently hosts DNS
• Whether your email uses the same domain
• Whether an existing site is already live on the domain
• Whether SSL is already configured somewhere else

If your site or email is already in use, make changes carefully. A domain update can fix one problem while creating another, especially if MX, SPF, DKIM, or subdomain records are accidentally replaced. If email matters, keep a record of your current zone before touching anything. Our guides on how to point a domain to your hosting provider, website builder, or server and how to set up MX, SPF, DKIM, and DMARC for a custom domain email are useful companion reads.

Platform-specific connections usually follow these patterns:

• WordPress: either connect to managed WordPress hosting, or point the domain to a self-hosted WordPress server by A record, CNAME, or nameserver changes.
• Shopify: often requires a combination of an A record for the root domain and a CNAME for www, plus domain verification inside the store admin.
• Squarespace: commonly uses several DNS records, including records for verification and a preferred setup for the root and www versions.
• Wix: usually supports connecting by nameservers or by pointing, depending on whether you want Wix to manage the domain configuration.

The details may vary by account type, registrar, or dashboard update, but your working goal is always the same: make the root domain and the preferred subdomain resolve correctly, preserve non-web records like email, and confirm that SSL finishes after propagation.

What to track

The main value of this guide is not just the first connection. It is the checklist you can return to every time a platform changes its default requirements. Track these items before and after making changes.

1. Your current DNS host

Find out whether DNS is managed at your registrar, your web host, Cloudflare, or the site builder itself. If you are unsure, check the nameservers assigned to the domain. This is the first checkpoint because it tells you where future edits must be made.

If you cannot find your records where you expect them, you are probably logged into the registrar while DNS is actually hosted elsewhere.

2. Existing records that should not be lost

Before you connect domain to WordPress, Shopify, Squarespace, or Wix, export or copy the DNS zone manually. Pay attention to:

• MX records for mail delivery
• TXT records for SPF, DKIM, or verification
• CNAME records used by email, support tools, or CDN services
• Subdomain records such as blog, app, or api

This matters most when switching nameservers, because the new DNS provider will not automatically recreate your previous zone.

3. Root domain and www behavior

Decide which version should be canonical: example.com or www.example.com. Most platforms support both, but one is typically set as primary and the other redirects. After setup, test both versions in the browser.

If one works and the other does not, you may be missing a redirect setting or a required DNS record.

4. Platform verification status

Most builders require you to confirm domain ownership or complete a connection step inside the dashboard. DNS alone may not finish the process. Keep track of whether the platform says:

• Domain connected
• Pending verification
• SSL provisioning
• Primary domain not set

These messages tell you whether the problem is DNS, account setup, or simply propagation delay.

5. SSL and HTTPS readiness

After DNS is correct, SSL often still needs time to issue. Do not assume a failed HTTPS page means the DNS change was wrong. Sometimes the domain resolves correctly before the certificate is active. What you should track is:

• Whether the platform shows certificate issuance in progress
• Whether the site loads over HTTP but not HTTPS
• Whether mixed content appears after connection

If you need extra help here, see how to set up SSL for a new website and fix common HTTPS errors.

6. DNS propagation windows

Any time you update records or nameservers, track when the change was made and what TTL values were in place. This makes troubleshooting much calmer. You will know whether you are dealing with a mistake or simply waiting for propagation. For a refresher, read DNS propagation time guide: how long changes take and how to check.

7. Email continuity

This is the most common hidden failure during a website launch. The site goes live, but email stops because MX or related TXT records were removed. After connecting the domain, send a test email in both directions if you use domain-based mail. If you are still deciding on a provider, best email hosting for custom domains compared may help.

Platform-specific tracking notes

WordPress: track whether you are connecting to a managed host, a WordPress.com-style hosted environment, or a self-managed server. The DNS targets differ, but your monitoring points remain the same: root domain resolution, www behavior, admin access, and SSL.

Shopify: track the required root and www records carefully. Shopify connections often fail because an old A record, parking record, or conflicting CNAME remains in place. Also confirm that the desired primary domain is selected in the store settings.

Squarespace: track both connection records and verification records. A domain may partly resolve before the dashboard marks it complete, especially if one required record is missing.

Wix: track whether you chose nameserver connection or pointing. This affects where you make future changes and whether existing records need to be recreated manually.

Cadence and checkpoints

Here is a practical schedule you can use whenever you connect a domain or revisit an older setup. This is especially useful because platform instructions can change on a monthly or quarterly cadence even when the underlying DNS logic stays the same.

Before making changes

• Document the registrar and DNS host
• Copy all current DNS records
• List any critical services using the domain: website, email, CDN, verification, API, or subdomains
• Lower TTL in advance if you have control and enough lead time
• Decide whether you are changing nameservers or only editing records

If this is a migration rather than a first-time connection, use a proper website migration checklist.

Immediately after the change

• Confirm the new records were saved in the correct DNS zone
• Check that there are no conflicting duplicate records
• Verify the domain inside the platform dashboard
• Open both root and www versions in a browser
• Record the exact timestamp of the change

Within the first few hours

• Use a DNS propagation checker or command-line lookup tools to see whether records are resolving as expected
• Test from a different network or device if local caching makes results confusing
• Check whether SSL is pending, active, or failed
• Send and receive a test email if the domain uses custom mail

Within 24 to 48 hours

• Confirm redirects are working as intended
• Confirm the primary domain inside WordPress, Shopify, Squarespace, or Wix is the one you want indexed and shared
• Check for stray DNS records left from a previous provider
• Review whether any old host-specific settings should now be removed

Monthly or quarterly review

This is where the tracker angle becomes useful. Even after the site is live, revisit the setup on a regular schedule and check:

• Has the platform changed its recommended connection method?
• Has SSL remained active without renewal issues?
• Are email records still present after any DNS edits?
• Have you changed hosting, CDN, or security tools that require new records?
• Are there old verification or parking records that should be cleaned up?

This kind of recurring review is especially helpful if you manage multiple domains or client-like environments internally. It prevents drift, where a site still works but the DNS zone becomes cluttered and fragile.

How to interpret changes

This section will help you tell the difference between a normal delay and an actual misconfiguration.

If the domain does not resolve at all

First confirm that you edited the correct DNS host. Then check whether the nameservers now point where you expect. If nameservers were changed, the old DNS records at the previous provider no longer control anything. This is a common source of confusion.

If the root domain works but www does not

You likely have an incomplete record set or no redirect configured. Builders often require a specific CNAME for www, while the root uses an A record or a platform-specific equivalent. Check for typos and conflicting old records.

If the platform dashboard says pending

This often means one required record is missing, misentered, or still propagating. Recheck hostnames carefully. In many DNS panels, entering the full domain where only the subdomain label is expected can create an incorrect record.

If HTTPS fails but DNS looks correct

Give SSL more time, then confirm the domain is fully connected in the platform dashboard. Some providers do not issue certificates until the domain is verified and assigned as primary. If HTTPS errors continue after propagation, review certificate status and platform guidance rather than changing unrelated DNS records.

If email breaks after connection

Look at MX first, then SPF, DKIM, and DMARC TXT records. If you switched nameservers, compare the old zone to the new one. Missing MX is the obvious failure, but missing DKIM or SPF can cause deliverability problems even when email seems partly functional.

If you are moving from one host or registrar to another

Separate the concepts clearly. Domain registration, DNS hosting, website hosting, and email hosting can all live with different providers. Moving one does not require moving the others. If you plan to change registrars, read how to transfer a domain name without breaking your website or email. If you are still deciding on hosting, compare options through best web hosting for beginners compared and shared hosting vs VPS vs cloud hosting.

One more practical note: when something changes in a provider dashboard, do not assume the DNS requirement changed too. Often the labels, menus, or setup wizard differ while the required records remain substantially the same. Your notes from a previous successful connection are still valuable if they focus on records, verification, redirects, and SSL rather than button names.

When to revisit

Revisit this topic any time you make a change that touches domain routing, verification, or security. In practice, that means more often than many site owners expect. Use this action list as your trigger-based checklist.

• When launching a new site: confirm DNS, primary domain, redirects, and SSL before announcing the URL.
• When changing website platforms: compare the old and new record requirements before deleting anything.
• When switching DNS providers or enabling Cloudflare: verify every non-web record, especially email and subdomains.
• When connecting email hosting for a custom domain: recheck MX and TXT records after any website-related DNS edit.
• When a dashboard flow changes: revisit the platform-specific instructions and map them back to the same core DNS model.
• When troubleshooting intermittent issues: review propagation timing, duplicate records, and canonical domain settings.
• On a monthly or quarterly cadence: audit the zone for stale records, verify SSL, and confirm the current setup still matches how the site is hosted.

If you want the shortest practical version of this entire guide, use this six-step routine every time:

1. Identify the registrar and current DNS host.
2. Copy the full DNS zone before changes.
3. Choose between nameserver change or record update.
4. Add only the records required by WordPress, Shopify, Squarespace, or Wix.
5. Verify the connection in the platform dashboard and wait for propagation.
6. Test website loading, redirects, SSL, and email before calling the job done.

That routine is what makes this article worth revisiting. Platform interfaces will keep changing. The safe setup process does not. If you return to these checkpoints whenever you connect domain to WordPress, connect domain to Shopify, connect domain to Squarespace, or connect domain to Wix, you will avoid most of the mistakes that cause downtime, missing email, or half-finished launches.