How to Connect a Domain to Web Hosting

Use this practical checklist to connect a domain to hosting, configure DNS, enable SSL, verify propagation, and troubleshoot common errors.

Connecting a domain to web hosting usually involves choosing between changing nameservers and editing individual DNS records. This repeatable checklist explains both approaches, shows when to use A records or CNAME records, and gives you a practical way to verify SSL, propagation, email, and website settings before launch.

Overview

Your domain registration and your web hosting are separate services, even when one company sells both. The registrar manages the domain name and its delegation settings. The hosting provider supplies the website server or platform. DNS connects the two by telling browsers where to find your site.

There are two common ways to connect a domain to hosting:

Change nameservers: You tell the registrar to use the hosting provider's DNS service. The hosting provider then manages the domain's DNS records. This is often the simpler choice for a new site when you do not need to preserve an existing DNS setup.
Update DNS records: You keep the current DNS provider and add or edit records, usually an A record for the root domain and a CNAME record for www. This approach gives you more control and can reduce disruption when email or other services already depend on the domain.

Before changing anything, record the current DNS settings. Pay particular attention to mail-related records, verification records, subdomains, and any services used for analytics, security, or forms. If you are unsure which setup applies, check the hosting provider's connection instructions rather than guessing an IP address or record value.

It also helps to separate the tasks: connect the domain, confirm the site loads, enable HTTPS, test the preferred version of the URL, and then check email and other services. For background on keeping registration and DNS management separate, see how to move DNS to Cloudflare without moving your domain registration.

Checklist by scenario

Scenario 1: A new domain and a new hosting account

Confirm the exact domain you want to use, including whether the site should use the root domain, such as example.com, or the www version.
In the hosting dashboard, add the domain as a primary domain, addon domain, or custom domain, depending on the platform's terminology.
Choose either the host's nameservers or the record values supplied by the host.
If using nameservers, open the registrar's DNS or nameserver settings and replace the existing delegation with the complete nameserver pair or set provided by the host. Save the change.
If using records, create the host's requested A, AAAA, or CNAME records. Do not add an IPv6 record simply because it is available; use it only when the host provides a correct IPv6 destination.
Return to the hosting dashboard and look for a verification or pending-connection status. Some platforms require you to click a confirmation button after DNS changes are made.
Wait for DNS changes to become visible, then open the domain in a private browser window and on a separate connection if possible.

Scenario 2: The domain already has email or other services

Use extra care before changing nameservers. A nameserver change can move responsibility for all DNS records, not just the website. If the host does not automatically recreate your existing records, email delivery and third-party services may stop working.

Export, copy, or screenshot the current DNS zone.
List the records that must remain, including MX, TXT, DKIM, DMARC, verification, and subdomain records.
Prefer targeted record changes if you want to leave the existing DNS provider in control.
Change only the website records supplied by the host. Leave mail records untouched unless the email provider instructs you otherwise.
Test both the website and email after the change.

If your email is hosted through Google Workspace or Microsoft 365, use the provider's documented DNS values and verification process. The guide to setting up custom domain email can help you treat website and email DNS as separate tasks.

Scenario 3: The host gives you an IP address

An IP address generally indicates that the host expects an A record for the root domain. In your DNS manager, set the host name or name field to the root symbol, @, if that is how the provider represents the apex domain. Enter the supplied IPv4 address and use the provider's recommended TTL or leave the default value.

For www, the host may request a CNAME pointing to the root domain or to a platform-specific hostname. A CNAME does not contain an IP address; it points one hostname to another. Do not place a CNAME and another conflicting record on the same name.

Scenario 4: The host gives you a target hostname

A target hostname usually calls for a CNAME record. This is common with hosted site builders, deployment platforms, and some content management systems. Add the record exactly as provided, including the destination hostname, and avoid adding http://, https://, or a page path unless the provider explicitly requests it.

What to double-check

Nameservers versus DNS records

Nameservers determine which DNS provider is authoritative for the domain. Records inside that provider's zone then control the website, email, and subdomains. Editing records at a registrar will not affect the site if the domain's active nameservers point somewhere else. First identify the authoritative DNS provider; then make changes in the correct dashboard.

A record versus CNAME

Use an A record when you have an IPv4 address. Use a CNAME when the destination is another hostname. The correct record depends on the hosting provider's instructions, not on personal preference. Some platforms also request an AAAA record for IPv6 or a TXT record to verify ownership.

SSL and the final URL

DNS only directs traffic; it does not automatically guarantee that HTTPS is ready. In the hosting dashboard, confirm that the domain has been added correctly and that an SSL certificate has been issued or activated. Test:

https://example.com
https://www.example.com
Any HTTP versions that should redirect to HTTPS

Choose one preferred version and configure the others to redirect to it. Check that the certificate covers every hostname you intend to publish. If the certificate remains pending, verify the DNS values, remove conflicting records, and confirm that the hosting account is using the same domain spelling as the registrar.

Propagation and verification

DNS changes do not appear everywhere at the same time. Cached responses can remain visible for a period determined partly by the previous record's TTL and by local resolvers. A DNS propagation checker can show whether different resolvers are returning the new value, but it is not a guarantee that every visitor sees the same result immediately.

Check from more than one network and use command-line tools such as dig or nslookup when you need to see the returned record directly. Compare the result with the value supplied by your host. Avoid repeatedly changing records while waiting, because each change makes troubleshooting harder.

Common mistakes

Changing the wrong DNS zone: The registrar may not be the active DNS provider. Check the current nameservers first.
Replacing nameservers without copying mail records: This can interrupt email or verification services. Preserve required records before delegating DNS to a new provider.
Entering a URL in a DNS field: A record values are IP addresses, and CNAME values are hostnames. They are not full web addresses.
Adding a duplicate or conflicting record: Conflicting A, CNAME, or proxy settings can produce inconsistent results.
Forgetting the hosting dashboard: DNS can be correct while the host still needs the domain added, verified, or assigned to the right site.
Testing only one hostname: Check both the root domain and www, plus any staging or subdomains you plan to use.
Assuming DNS controls redirects: DNS points a hostname to a service; redirects are normally configured by the web server, hosting platform, or application.
Editing during a busy launch without a rollback plan: Save the old values and note the time of every change so you can restore the previous configuration if needed.

When to revisit

Keep this checklist with your domain and hosting records and revisit it whenever the underlying setup changes. The most useful times are before a site launch, before a seasonal campaign, after moving hosting, when changing DNS providers, and when adding email, a CDN, a verification service, or a new subdomain.

It is also worth reviewing the setup when a domain is transferred, when the hosting account changes ownership, or when a provider updates its connection workflow. Record the registrar, authoritative DNS provider, hosting account, preferred URL, current nameservers, and important DNS records in a secure internal note. Do not store account passwords in that note.

For a final launch check, work through this short sequence: confirm the domain is not expired, verify the active nameservers, compare the website records with the host's instructions, preserve email records, confirm SSL, test the root and www hostnames, check redirects, and monitor the site from more than one network. If the domain and hosting costs are also under review, compare the full ownership picture rather than only the introductory price using the domain registration cost calculator.