How to Connect a Domain to Web Hosting

Use this practical DNS checklist to connect a domain to hosting, protect email and SSL, manage propagation, and troubleshoot launch problems.

Connecting a domain to web hosting usually means changing nameservers or adding a small set of DNS records, then verifying that the website, email, and SSL certificate still work. This reusable checklist explains which method to choose, what to record before making changes, how long DNS updates may take, and how to troubleshoot the most common launch and migration problems.

Overview

Your domain registration and web hosting are separate services, even when you purchase them from the same provider. The registrar manages the domain name, while the host stores and delivers the website. DNS connects the two by telling browsers where to find the website when someone enters your domain.

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

Change nameservers: Replace the domain’s current nameservers with those provided by the hosting company. The host then manages the domain’s DNS zone. This is often the simpler option for a new website or a setup where the host should control all DNS records.
Edit DNS records: Keep the existing nameservers and change individual records, such as the A record for the root domain or a CNAME record for www. This offers more control and is usually preferable when email, verification records, or other services already depend on the current DNS provider.

Before changing anything, identify where DNS is currently managed. It may be your domain registrar, hosting provider, website builder, CDN, or a separate DNS service. Changing nameservers without copying important records can interrupt business email, subdomains, domain verification, or other connected tools.

If you are still deciding how to organize the project, estimate the full domain-and-hosting budget with the Domain and Hosting Cost Calculator. For platform-specific instructions, see How to Point a Domain to Shopify, Squarespace, Webflow, or WordPress.

Checklist by scenario

Scenario 1: A new domain and a new hosting account

Confirm that the domain is registered and not locked against changes.
Find the host’s connection instructions. Look for nameservers, an IPv4 address, an IPv6 address, or a target CNAME.
Choose nameserver delegation if you want the host to manage DNS and the website is not yet using important external services.
Choose individual DNS records if you want to keep DNS at the registrar or another provider.
Add the domain inside the hosting control panel. Many hosts require this before the server will respond to the domain.
Make the DNS change at the current DNS provider, not automatically at the place where you bought the domain unless they are the same.
Wait for the change to become visible, then test both the root domain, such as example.com, and the www version.
Enable the host’s SSL certificate only after the domain points to the correct account. Then test the HTTPS version and redirect behavior.

Scenario 2: Moving an existing website to a new host

Keep the old hosting account active until the new site has been tested and traffic is reaching the new server.
Lowering the DNS TTL before a planned migration may help future changes be recognized sooner, but it does not guarantee instant propagation.
Copy the site files, database, media, redirects, and configuration settings to the new host.
Check the new site using a temporary URL, preview address, hosts-file test, or another method supplied by the host.
Record every current DNS record before switching. Include mail records, subdomains, verification records, and any custom records used by integrations.
Change the A, AAAA, or CNAME records—or change nameservers, if that is the selected migration method.
Confirm that forms, logins, images, redirects, analytics, and scheduled tasks still function.
Do not cancel the old hosting until DNS has settled and the new site has passed a practical review.

Migration planning is also a good time to compare the limitations and support model of your current plan. The guide to hosting for startups can help frame questions about capacity and future growth without treating one hosting type as right for every site.

Scenario 3: Keeping email with a separate provider

Be especially careful when the domain is used for email. Nameserver changes can remove the existing MX records if the new DNS zone does not contain them. Before switching, copy the MX records and any related SPF, DKIM, and verification records according to the email provider’s instructions. After the change, send and receive test messages from more than one account.

If you need a professional mailbox, treat domain privacy protection and business email as separate decisions. Privacy settings affect public registration details where applicable; they do not replace mail security records or mailbox administration.

Scenario 4: Adding a subdomain

A subdomain such as blog.example.com or store.example.com needs its own DNS record unless the provider gives you a different setup. A CNAME commonly points a subdomain to another hostname, while an A record points it to an IP address. Add the subdomain to the destination platform as well as in DNS, then verify its SSL certificate and canonical URL. For broader architecture decisions, read Subdomain vs Subdirectory for SEO.

What to double-check

Nameserver spelling: Copy the exact values supplied by the host. A single character can direct the domain to the wrong DNS provider.
Root and www behavior: Make sure both versions resolve as intended. One may redirect to the other, or both may serve the same site.
Record conflicts: Avoid leaving an old A record in place when the new host requires a different destination. Check for duplicate or conflicting records.
DNS record scope: A DNS change normally affects the domain or hostname named in the record, not every service connected to the domain. Review each hostname separately.
Email continuity: Verify MX, SPF, DKIM, and any provider-specific records before and after a nameserver change.
SSL certificate setup: HTTPS may not work immediately after DNS changes. Confirm that the certificate covers the exact domain and that HTTP redirects to HTTPS only after the secure version loads correctly. Use the SSL Certificate Setup Guide for a separate HTTPS review.
Domain status: Check for expiration, registrar locks, pending transfers, or verification steps that could prevent changes.
Propagation: DNS resolvers can cache previous answers. Results may differ between networks for a period of time, so do not judge the change from one device or connection alone.

Common mistakes

Changing DNS at the wrong provider

The registrar may display the domain while another service controls its nameservers. Check the active nameservers first and make edits in the DNS dashboard they identify.

Deleting records instead of replacing only what is necessary

A website connection may require one or two changes, not a complete DNS reset. Preserve unrelated records unless the new provider explicitly requires a full DNS migration.

Expecting instant results

Browser caches, resolver caches, TTL values, and provider-side systems can all affect what you see. Test with a different network, clear local DNS and browser caches where appropriate, and allow reasonable time before reversing a correct change.

Activating SSL too early

An SSL certificate generally needs the host to verify control of the domain. If the domain still points elsewhere, certificate issuance or renewal can fail. First confirm DNS, then complete SSL setup, then test redirects and mixed-content warnings.

Forgetting the old host during a migration

Switching DNS does not automatically migrate files, databases, mailboxes, backups, or cron jobs. Use a written inventory and confirm each item on the new platform before closing the old account.

When to revisit

Save this checklist and review it whenever the underlying setup changes. Revisit it before a website launch, a seasonal campaign, a domain transfer, a hosting renewal, or a planned website migration. It is also useful after changing a CMS, adding a subdomain, moving email, enabling a CDN, or introducing a new third-party service that requests DNS verification.

Tools and hosting dashboards change over time, so confirm the current instructions from your registrar and host rather than relying on an old screenshot. Before each change, export or copy the current DNS zone, record the intended outcome, and note the time of the update. Afterward, test the website over HTTPS, check both root and www addresses, send a test email, review important subdomains, and monitor the site until the new destination is consistently visible.

If the domain still shows the old site after a reasonable propagation period, work through the checklist in order: verify the active nameservers, inspect the relevant A or CNAME record, confirm the domain is added to the hosting account, check for conflicting records, and ask the host to confirm the server’s expected destination. This sequence separates a DNS problem from a hosting, SSL, or website-configuration problem and makes support conversations much more efficient.