Connecting a domain to a website comes down to a few records. Your hosting provider tells you what to add. Usually it’s an A record with an IP address, or a CNAME with a provider hostname.

The hard part isn’t typing them in. It’s translating the instructions correctly and then checking your work in the right order.

Translate literally

Each instruction maps to one field type:

an A value is an IPv4 address
an AAAA value is an IPv6 address
a CNAME value is a hostname
@ means the zone apex, example.com itself
www means www.example.com inside the example.com zone

Never paste a URL like https://myapp.pages.dev/ into an address or CNAME field. DNS holds names and addresses. Schemes, ports, and paths don’t belong there. Strip it down to myapp.pages.dev.

Apex and www are two names

Decide up front whether both example.com and www.example.com should work. They’re separate DNS names and often need separate records, and separate custom-domain entries at the host.

Redirecting one to the other is an HTTP job, done by the web server after DNS. A CNAME doesn’t change what the browser shows in the URL bar.

Look before you add

Before saving, check what already lives at that name. A CNAME can’t coexist with A, AAAA, TXT, or MX records on the same owner. The dashboard will either refuse or, worse, let you break something.

Be careful when deleting old records. That odd TXT at the apex might be the verification Google Workspace depends on. Find out what uses a record before you remove it.

Verify one layer at a time

Now let’s check the result, from the bottom up:

dig A example.com
dig AAAA example.com
dig CNAME www.example.com
curl -I https://example.com/

First confirm the authoritative servers publish what you expect. Then compare a couple of recursive resolvers. Only after DNS is right do you move on to the connection, the TLS certificate, and the HTTP response.

Keep the layers apart in your head. A correct address doesn’t prove the web server knows your hostname. If dig is right and curl shows a certificate error, the fix is at the host, not in DNS.

If a proxy is in front

With Cloudflare’s proxy enabled, public DNS returns Cloudflare’s addresses, not your origin. That’s expected. If you then see a Cloudflare error page, DNS is doing exactly what you configured. The problem is the origin, the TLS mode, or the application behind the proxy.

Try this: take one hosting provider’s domain instructions and turn them into a table with owner, type, value, proxy status, and purpose. Then verify the DNS answer and the HTTPS response as two separate checks.

Connect a domain to a website