How to Connect a Domain to Web Hosting: DNS Records, Nameservers, and Troubleshooting

Overview

Your domain registration and web hosting are related but separate services. The domain is the address visitors type, while hosting stores the WordPress files, database, and related services that deliver the site. DNS management connects the two by telling browsers which servers should answer for that domain.

Before changing anything, collect these details from your WordPress hosting provider:

• The hosting account's nameservers, if you plan to use provider-managed DNS.
• The server IP address for the domain's A record, if you will keep DNS at the registrar.
• The required CNAME record for www, if one is provided.
• Any email-related MX, SPF, DKIM, or other TXT values already in use.
• Instructions for issuing an SSL certificate and selecting the site's primary domain.

There are two standard approaches. A nameserver change delegates DNS management to the hosting provider. It is often simpler for a new site because the provider can supply a complete DNS zone. Editing individual records keeps DNS at the registrar or another DNS provider and can be preferable when the domain supports email, subdomains, verification services, or other systems that must remain under centralized control.

Do not change nameservers or delete records without first recording the existing configuration. A website may be new, but the domain could already be supporting email, redirects, analytics verification, staging environments, or third-party services.

Checklist by scenario

Scenario 1: A new domain and a new WordPress hosting account

1. Confirm that the domain registration is active and not locked by an incomplete verification or billing step.
2. Open the hosting control panel and add the domain to the account. Some hosts call this an “add-on domain,” “site,” or “domain mapping” step.
3. Choose either the provider's nameservers or the supplied A and CNAME records.
4. If using nameservers, replace the domain's current nameserver entries at the registrar with the exact values supplied by the host.
5. If using records, point the root domain, often written as @, to the hosting IP with an A record. Point www with the host's recommended CNAME or A record.
6. Install WordPress only after the hosting account recognizes the domain, unless the provider's setup process combines these steps.
7. Enable SSL, then test both https://example.com and https://www.example.com.

Scenario 2: An existing WordPress site moving to new hosting

1. Build or migrate the site on the new host before changing DNS. Check the files, database, WordPress address, site address, plugins, media, and permalinks.
2. Lowering DNS TTL before a planned change may help resolvers refresh sooner, but it does not guarantee instant propagation.
3. Preserve the old hosting account until the new site, email, redirects, forms, and SSL have been verified.
4. Change DNS during a period when you can monitor the site and respond to errors.
5. After the change, test the homepage, key pages, login, contact forms, checkout functions, images, feeds, and any connected applications.

For a broader pre- and post-launch review, use the Website Launch Checklist. If the move is part of a larger maintenance routine, the WordPress Website Maintenance Guide can help organize follow-up checks.

Scenario 3: You need to protect existing email

Changing only an A record can leave email working, provided the MX and related records remain unchanged. Changing nameservers is different: the new DNS provider must contain every required email record before delegation changes. Copy MX records and relevant TXT records first, then recreate and verify them in the new DNS zone. Avoid assuming that a hosting provider automatically imports your email configuration.

What to double-check

Root domain and www behavior

Decide which version is primary: the root domain or the www hostname. Both should resolve to the intended WordPress installation, with the other redirected consistently. A root domain generally uses an A record, while www commonly uses a CNAME. DNS providers use different labels for the root, including @ or a blank host field, so follow the provider's field instructions.

DNS propagation versus an actual error

After a DNS change, different networks may continue using cached answers for a while. Check from more than one network or DNS lookup service, and compare the returned A, CNAME, MX, and TXT values with the intended configuration. If every location shows the old value, the change may not have been saved or may have been made at the wrong DNS provider. If results differ, caching or propagation is a likely explanation.

SSL and WordPress URLs

DNS only directs traffic; it does not automatically make the site secure. Confirm that the certificate covers the hostname visitors use and that the hosting account has completed its SSL process. In WordPress, check the WordPress Address and Site Address settings after HTTPS is active. Mixed-content warnings may indicate that images, scripts, or stylesheets still load through HTTP.

DNS authority

Identify where the domain's active DNS zone is hosted. If nameservers point to the registrar, edits made in the hosting panel may have no effect. If nameservers point to the host, edits made in the registrar's DNS editor may also be irrelevant. The authoritative nameservers determine which zone visitors receive.

Common mistakes

• Changing nameservers without copying email records: This can make the website work while mail delivery fails.
• Using the wrong IP address: Shared hosting, staging, and production accounts may have different destinations. Copy the value from the active hosting account.
• Creating conflicting records: Multiple A records or an A record and CNAME for the same hostname can produce inconsistent results. Follow the host's exact configuration.
• Testing only one hostname: Check the root domain, www, HTTPS, and any important subdomains separately.
• Deleting the old site too soon: Keep the previous hosting environment available until DNS, SSL, email, and WordPress functionality are confirmed.
• Forgetting caching: Browser, WordPress, CDN, and hosting caches can make a correct DNS change appear ineffective. Clear or bypass caches before diagnosing the records again.
• Editing DNS during an unrelated migration: Keep a change log so you know which adjustment caused a new symptom.

When to revisit

Revisit this checklist before a domain transfer, hosting migration, seasonal campaign, major WordPress redesign, or change to business email. It is also useful when adding a subdomain, connecting a CDN, moving from staging to production, or changing the site's primary hostname.

When a site appears offline, use this order: confirm the domain has not expired; identify the authoritative nameservers; compare A and CNAME records with the hosting instructions; verify MX records if email is affected; check SSL; then test WordPress and application logs. Record the current DNS zone before each planned change and note the date, purpose, old value, and new value.

Finally, add DNS ownership and recovery details to your website records. Store registrar access securely, document who controls the hosting account, and keep a backup of important DNS settings. For ongoing WordPress operations, pair this process with the WordPress Website Maintenance Checklist and an uptime monitoring routine. That turns a one-time connection into a repeatable part of responsible site management.