Connecting a domain to web hosting involves more than entering a single address: you need to choose a DNS approach, add the correct records, activate SSL, protect email routing, and allow time for changes to become visible. This reusable checklist explains how to connect a domain to shared or cloud hosting and how to verify the result without overlooking the details that commonly cause downtime.
Overview
A domain is the human-readable address people use to reach your site. Web hosting is the server environment that stores and delivers the site. DNS connects the two by telling browsers which hosting service should answer for your domain.
Before changing anything, collect these details from your hosting provider:
- The hosting server’s IPv4 address, if you will use an A record.
- The IPv6 address, if the provider supports and recommends an AAAA record.
- The provider’s target hostname, if you will use a CNAME record.
- The provider’s authoritative nameservers, if you plan to move DNS management to the host.
- The hostname or control-panel option used to request and activate SSL.
There are two main ways to connect a domain to hosting. You can keep DNS at the registrar and edit only the records needed for the website, or you can change the domain’s nameservers so the hosting provider manages the DNS zone. Keeping DNS at the registrar can make email and third-party services easier to control in one place. Using hosting-provider nameservers may simplify setup when the provider supplies an integrated DNS and hosting workflow. Choose one method rather than applying both at the same time.
If you are still deciding where to register the domain, the guide to choosing and registering a domain name covers the information to gather before you begin.
Checklist by scenario
Scenario 1: Keep DNS at the registrar
This is often the least disruptive option when an existing domain already supports email, verification records, or other services.
- Open the registrar’s DNS management page.
- Find the existing records for the root domain, usually written as
@or left blank. - Replace or add the root-domain A record using the IP address supplied by your host. Do not guess the address.
- Add or update the www CNAME record so it points to the hosting target, if your host provides one. Some setups instead use an A record for
www; follow the provider’s instructions. - Remove conflicting A, AAAA, or CNAME records for the same hostname. A hostname should not have an unrelated CNAME alongside other records that conflict with it.
- Save the zone and record the previous values before making further changes.
Do not delete MX, TXT, or other records simply because they do not appear related to the website. MX records route email, while TXT records may support email authentication, domain verification, or other services.
Scenario 2: Use the hosting provider’s nameservers
Choose this route when the host provides a complete DNS zone and you want it to manage records for the hosted site.
- Copy the exact nameserver hostnames from the hosting account.
- At the registrar, replace the current nameservers with the supplied values.
- Check whether the provider recreated required records for email and connected services.
- Do not continue editing the old DNS zone at the registrar and expect those changes to apply. Once delegation changes, the active zone is controlled by the new nameservers.
- Confirm that the domain is added to the correct hosting account and website, including both the root domain and
wwwif both will be used.
Nameserver changes can affect every service using the domain, not just the website. Review email, subdomains, verification records, and any external applications before switching.
Scenario 3: The site is moving from another host
For a domain and hosting migration, prepare the new site before changing DNS. Upload the files or deploy the application, create the database, import a recent backup, and test the site using the host’s preview address or a temporary local mapping when available. Lowering the DNS TTL in advance may help with a planned change, but it does not guarantee immediate global visibility.
When the new site is ready, update the A record, CNAME, or nameservers according to the chosen method. Keep the old hosting active until traffic is consistently reaching the new environment and essential functions have been tested.
Scenario 4: You need business email on the domain
Website DNS and email DNS are related but separate. The website normally uses A, AAAA, or CNAME records. Email delivery uses MX records, supported by records such as SPF, DKIM, and DMARC when required by your email provider. Copy the email provider’s values exactly, including hostnames, priorities, quotation marks, and trailing dots where its interface requires them. Never replace MX records with web-hosting values unless the hosting provider is also handling email.
What to double-check
SSL and HTTPS
After DNS points to the new host, add the domain in the hosting control panel and request an SSL certificate if activation is not automatic. Include every hostname visitors will use, commonly the root domain and www. Test both HTTP and HTTPS versions, then configure the preferred version to redirect to HTTPS. Check that images, scripts, stylesheets, forms, and API calls also load securely; a page can have a valid certificate while still containing mixed-content references.
SSL is only one part of secure web hosting. You should also confirm that backups, software updates, account access controls, and monitoring are available and configured. The new-domain security checklist provides a broader pre-launch review.
DNS answers and propagation
DNS changes are cached by resolvers according to record TTL values, so different networks may show the old and new destination for a period of time. Use a DNS propagation checker to compare the record returned from multiple locations, but treat it as a diagnostic aid rather than proof that every resolver has updated. Also test from your own network, a mobile connection, and a trusted external resolver.
Check the authoritative nameservers first. If the expected record is missing there, waiting will not fix the problem. If the authoritative answer is correct but some networks still show the previous value, caching may be the explanation.
Application and hosting configuration
- Confirm the domain is assigned to the intended document root or application.
- Verify the site’s configured base URL uses the correct domain and HTTPS scheme.
- Check redirect rules for loops between the root domain and
www. - Test login forms, contact forms, checkout flows, webhooks, cron jobs, and API endpoints.
- Confirm that backups are running and that at least one recent restore point exists.
Common mistakes
- Using the wrong IP address: Copy the address from the hosting account, not from a search result or an unrelated server.
- Editing the inactive DNS zone: After a nameserver change, make records in the zone served by the new authoritative nameservers.
- Creating conflicting records: Duplicate A records can distribute requests between destinations, while an A record and CNAME cannot normally coexist for the same hostname.
- Deleting email records: Removing MX or authentication records while connecting the website can interrupt business email.
- Testing only one hostname: Check the root domain,
www, HTTPS, and any important subdomains separately. - Assuming propagation fixes configuration errors: Time does not correct an incorrect record, an unassigned domain, a missing SSL certificate, or a misconfigured application.
- Ending the old hosting too soon: Keep the previous environment available until the new site and its data have been verified.
For a broader migration plan, review the guidance on staging versus production hosting and website backups.
When to revisit
Return to this checklist before a major launch, seasonal campaign, domain transfer, hosting migration, email-provider change, or DNS-management change. It is also useful after switching from shared hosting to cloud hosting, adding a CDN or reverse proxy, introducing new subdomains, or changing the preferred root-domain and www arrangement.
Before each change, export or record the current DNS zone, list every service that depends on the domain, and identify a rollback value. After the change, verify DNS, SSL, site content, email, forms, monitoring, and backups. Keep the old configuration notes with the project documentation so another administrator can understand what was changed and why.
The practical sequence is simple: prepare the hosting account, choose one DNS method, preserve unrelated records, make the smallest necessary change, allow for caching, and test every important hostname and service. That process makes connecting a domain to hosting predictable whether the destination is shared hosting, a managed application, or a scalable cloud server.
