Connecting a custom domain to free cloud hosting involves two separate jobs: directing DNS records to the correct deployment and verifying HTTPS for the domain visitors use. This reusable checklist explains the order of operations, the records to expect, practical propagation checks, and the fixes for common DNS and SSL errors.
Overview
A hosted website usually has at least two identities: the provider's temporary address, such as a project subdomain, and your custom domain, such as example.com. Your hosting platform must know that the domain belongs to the project, while your DNS provider must send visitors to the platform. HTTPS is then issued for the domain after the host can verify that connection.
Do not change records until you know which hostname you are configuring. The apex domain is the bare domain, such as example.com. The www hostname is separate: www.example.com. Decide whether one should be the primary address and redirect the other. A typical setup uses either an apex record pointing to the host and a www alias, or the reverse. The exact target values come from your hosting provider, so treat the provider's domain instructions as authoritative.
DNS changes and certificate issuance are separate steps. A domain can resolve correctly while HTTPS is still pending, and a certificate can be issued for one hostname but not another. Test the exact addresses visitors will use.
Checklist by scenario
Scenario 1: Connecting a new domain to a hosted site
- Publish or deploy the site first. Confirm the temporary hosting URL loads the intended page, assets, forms, and redirects.
- Add the domain in the hosting dashboard. Enter both the apex domain and
wwwif you plan to serve both. Some platforms ask you to verify ownership before displaying DNS targets. - Record the required DNS values. Note the record type, host or name, target or value, and any required verification token. Do not substitute an IP address for a hostname unless the host specifically instructs you to do so.
- Open the DNS provider's zone editor. Remove only obsolete or conflicting records. Keep mail-related records, including MX, SPF, DKIM, and DMARC records, unless you are intentionally moving email too.
- Add the web records. Common patterns include an A or AAAA record for an apex domain, and a CNAME for
www. Some DNS providers support ALIAS or ANAME behavior for an apex domain. Use the provider's documented option. - Wait for resolvers to observe the change. Check authoritative results first, then compare results from more than one public resolver.
- Enable HTTPS in the hosting dashboard. After DNS points to the correct deployment, select the platform's certificate or HTTPS option and wait for domain validation.
- Test both HTTP and HTTPS. Confirm that
https://example.comandhttps://www.example.combehave as intended, and that the unwanted version redirects to the preferred version.
Scenario 2: Adding www after the apex domain works
Add the www hostname to the hosting project before creating its DNS record. Then create the CNAME target supplied by the host. If the host gives a single canonical hostname, do not add a trailing period unless the DNS editor expects fully qualified values. Check that no old A, CNAME, or forwarding record already exists for www.
Scenario 3: Moving an existing site to free cloud hosting
Lowering a DNS TTL before the move can make a later change easier to observe, but it does not force every resolver to refresh immediately. Prepare the new deployment, verify it on a temporary URL, copy important DNS and email records, then change only the website records during the cutover. For a broader migration plan, see How to Move a Website to Free Cloud Hosting Without Losing Traffic.
Keep the previous hosting active until the new site, redirects, forms, and HTTPS have been checked. Search engines and visitors may reach different destinations while DNS caches expire.
What to double-check
DNS record types
| Purpose | Typical record | Check |
|---|---|---|
| Apex domain | A, AAAA, ALIAS, or ANAME | Use the host's exact target and confirm the DNS provider supports the record at the apex. |
www hostname | CNAME | Point it to the platform target, not to a full URL containing https://. |
| Ownership verification | TXT | Paste the complete token and preserve other TXT records. |
| MX, SPF, DKIM, DMARC | Do not delete these while changing web hosting. |
Propagation and response checks
Use the following commands from a terminal, replacing the domain as needed:
dig A example.com +short
dig CNAME www.example.com +short
dig TXT example.com +short
nslookup -type=NS example.comFor a more complete answer, omit +short and inspect the answer and authority sections. Query a specific resolver when comparing results:
dig @1.1.1.1 A example.com
dig @8.8.8.8 A example.comThese resolver addresses are examples of public DNS services; use the resolver you trust and label any result with the time it was collected. Online DNS propagation checkers can provide a useful second view, but they show cached observations, not a guarantee that every visitor sees the same answer.
HTTPS validation
Certificate automation commonly validates domain control through HTTP or DNS. With HTTP-based validation, the host must reach a temporary path on the domain. With DNS-based validation, the required TXT record must be visible. Do not remove a validation record until the hosting platform confirms issuance if the platform says it is needed.
After issuance, inspect the actual response:
curl -I http://example.com
curl -I https://example.com
curl -I https://www.example.comLook for the expected status code, Location header, and absence of a certificate warning in a browser. A TLS checker or the browser's certificate viewer can help identify hostname mismatches, expired certificates, or incomplete chains. The certificate must cover every hostname you intend to publish.
Common mistakes
| Symptom | Likely cause | Remediation |
|---|---|---|
| “Domain not connected” | The record is at the wrong DNS provider, has the wrong host name, or still conflicts with an old record. | Check the domain's authoritative name servers, compare the dashboard value character by character, and remove only the conflicting web record. |
| “Certificate pending” | DNS has not reached the host, the hostname was not added to the project, or validation is blocked. | Verify A, AAAA, CNAME, or TXT results, then retry issuance only as the platform recommends. |
| “Too many redirects” | Both the host and an external proxy or forwarding service are rewriting HTTP and HTTPS. | Choose one HTTPS redirect owner, disable the duplicate rule, and retest in a private browser window. |
Works on www but not the apex | The two hostnames have different records or only one is attached to the project. | Add both hostnames in the hosting dashboard and configure the record pattern documented by the host. |
| Email stopped after the website move | Mail records were replaced or the DNS zone was changed incompletely. | Restore the email provider's MX and authentication records, then confirm mail delivery separately from web testing. |
Another frequent error is entering a URL in a CNAME field. A CNAME target is normally a hostname, not a path or protocol. Also check for duplicate records: an apex A record and an incompatible forwarding rule can produce inconsistent behavior even when each entry looks plausible by itself.
For sites built with a static generator or a visual website builder, confirm that the deployed build contains the intended canonical URL, asset paths, and redirect rules. The Static Site Hosting Guide covers deployment checks, while the website performance audit checklist can be used after the domain is live.
When to revisit
Keep this checklist with your domain records and use it whenever you connect a new domain, add a subdomain, change DNS providers, move a site, or renew a hosting arrangement. Recheck the preferred hostname and redirect behavior after a redesign, platform migration, or change to a proxy or CDN.
Review the workflow before seasonal planning or a major campaign so that DNS, forms, analytics, and HTTPS are not changed at the same time as launch content. Revisit it after the hosting provider changes its control panel or certificate process. Platform instructions, validation options, DNS editor behavior, and browser requirements can change, so the provider's current documentation should take priority over a saved screenshot or old value.
Final action list: save the provider's DNS targets, record your current DNS zone, verify the apex and www responses with dig, issue HTTPS only after DNS is correct, test redirects with curl and a browser, and keep email records untouched unless email is also moving. If you are launching a small business or portfolio site, pair this domain review with the Free Cloud Hosting Launch Checklist.
