How to connect a custom domain to a website in one record

Connecting a custom domain to a website is one DNS record, added wherever your domain's DNS lives. A root domain like example.com takes an A record pointing at the address your host shows you. A subdomain like www.example.com takes a CNAME record pointing at the address your site already has. Add the record, then tell your host to check it.

Your site does not move and is not published again. You are putting up a signpost, not relocating the building.

The rest of this page is the part nobody writes down: what to do when that one record does not work. Most guides come from a single host and describe a single dashboard, so they cannot tell you which half of the problem is theirs and which half is the internet's.

Your site already has an address. The domain is a second door

If an agent built and published your site, it is live right now at a generated address, something like cake-shop.birta.link. That URL is real, people can open it, it has a certificate. Already ahead of a page living in a chat panel, where an artifact has no address to point a domain at.

A custom domain does not replace it. It adds a second name that resolves to the same files, and both keep working. This is the commonest misunderstanding about the procedure, and it makes people delay because they think it is a migration with a rollback plan. Keep editing the live site as before; both addresses show the result.

If you have not published yet, do that first, from Claude Code or any tool you work in. It is easier to point a domain at a site that exists, because then you can tell a DNS problem from a site problem. For the shape of what you are pointing at, see what a static host actually does.

The record goes where your DNS lives, not where you bought the domain

This is the step that eats the hour.

You bought the domain from a registrar: Namecheap, GoDaddy, Porkbun. By default that registrar also answers DNS questions about it, so the record goes in their panel. Hosts call this a third-party domain: registered in one place, pointed at another.

But a domain can delegate that job. If you or anyone before you pointed the domain's nameservers at Cloudflare, Route 53 or a web host's DNS, the registrar no longer answers for it. A perfect A record in the registrar's panel then does nothing, because nobody is asking that panel.

To find where the zone lives, look up the nameservers:

dig NS example.com +short

Whatever comes back is where your records go. nslookup -type=ns example.com does the same on Windows. If the answer is ns1.cloudflare.com, your DNS is at Cloudflare regardless of who charges for the renewal.

A record or CNAME depends on what is in front of the dot

Hosts state this as a rule, root gets an A, subdomain gets a CNAME, and almost never say why. The why is short and saves you from fighting your DNS provider.

A CNAME says "this name is an alias for that other name." RFC 1034, section 3.6.2: "If a CNAME RR is present at a node, no other data should be present." An alias cannot coexist with anything else at the same name.

The root of your domain, the apex, is required to carry other data, because every zone must have an SOA record and NS records at its top node. So the apex can never be a CNAME. It has to be an A record pointing at an IP address.

A subdomain has no such obligation. www.example.com carries nothing by default, so it can be a pure alias, which is why hosts prefer a CNAME there: they can change IP addresses without you touching anything.

Some providers offer ALIAS, ANAME or CNAME flattening, which do alias-like resolution at the apex and hand back an A record. Netlify's domain docs explain this and recommend making www primary on external DNS for exactly that reason. If your provider offers ALIAS, use it. If not, an A record is the normal answer rather than a compromise.

The root and www are two separate names

example.com and www.example.com are different names, resolving independently. Adding one does not add the other.

Decide which one people will type and see in your links, and connect that one first. If you want both, you need a second record or a redirect, and whether you get that free depends on your host. Some do it silently. NationBuilder says plainly that joining a root domain to its www version "is actually a technical process" requiring an HTTP redirect. Check what your host does.

If your DNS provider proxies traffic, verification will fail

This wastes more time than the rest combined, and none of the major host guides mention it.

Cloudflare and providers like it can put themselves in front of your site. In Cloudflare's dashboard that is the orange cloud, and their documentation is explicit: a query to a proxied record "will be answered with Cloudflare anycast IP addresses, shared IP addresses used to route traffic through a nearby data center, instead of" your actual origin.

Read that from your host's side. It verifies the domain by asking DNS where the name points and expects its own address. With the proxy on, DNS answers with Cloudflare's. The record is correct, the domain works in a browser, and verification still fails.

Set the record to DNS only (grey cloud), verify, then decide whether you want the proxy back on.

When Verify says no: five things to check

Before clicking Verify again, check the record yourself. It takes five seconds and tells you whether you are waiting on DNS or on the host:

dig example.com +short

If that prints the address your host asked for, the record is live and the host should accept it. If not, work down this list.

The record is in the wrong zone

Confirm the nameservers first. A record added to a panel that no longer answers for the domain is invisible to everyone.

Old records are still sitting next to the new one

A name can hold several A records at once, and DNS will hand out any of them. Leftovers from a previous host, an AAAA record pointing at an old IPv6 address, or a CAA record restricting which authority may issue certificates all cause intermittent, maddening behaviour. Delete the old entries rather than adding alongside them.

The proxy is on

Grey cloud. See above.

A typo you cannot see

The host field is the usual culprit. Providers disagree about whether the root is written @, left blank or spelled out, and some silently append your domain to whatever you type, so www.example.com becomes www.example.com.example.com. Look at the saved record, not the one you typed.

It really has not propagated yet

Possible, and the least likely of the five if the name never had a record. Which brings us to the number everybody repeats.

How long it actually takes

Every guide says 48 hours. It is not a measurement, it is a worst case that got copied for thirty years.

The mechanism is the TTL, a value on every DNS record that, per RFC 1035, tells resolvers how long they may cache it. Nobody is waiting on your new record to travel anywhere. They are waiting on the old answer to expire out of caches.

That gives you a usable rule:

• The name had no record before. Nothing cached to expire, so usually minutes.
• You changed an existing record. Worst case is roughly the TTL it carried before you edited it.
• You changed nameservers. The slow one, where the 48-hour figure earns its keep.

The spread in the guides tells the same story. Squarespace says "24 to 48 hours". Solo says "up to 48 hours to complete but often faster". GoDaddy is the honest one: "a few minutes to several hours (rarely up to 48 hours)".

HTTPS happens after the domain points at the host, not before

If you open the domain the moment it resolves and the browser warns about the certificate, nothing is broken. A certificate authority issues an SSL certificate for a name only once it can confirm the name points at the server asking for it, and that cannot happen until your record is live. So the order is always: record, resolution, certificate, padlock.

Give it a few minutes after the domain verifies. If the warning persists, raise it with your host.

How many records should this take?

Worth knowing before you assume a long list is normal. This is how many DNS records four hosts ask for, as documented by each of them:

The gap is not technical difficulty, it is product design. Squarespace's sixth record exists so the domain does not fall off later: its own documentation warns that if the verification CNAME is missing or wrong, "the domain will unlink from your site after 15 days." That is a requirement of a product, not of DNS.

Knowing the difference is the skill. A TXT record to prove you own the domain is a host's verification design. An A record at your apex is RFC 1034, and no host can waive it.

Connecting a domain on Birta

Open your project, find the Domain section, enter your domain, and copy the single record it shows. Add that record at your DNS provider, come back, press Verify. Once it passes, the domain is active and the secure connection is set up for you. You can also ask the agent in Birta's chat to connect it; it shows you the same record. A custom domain is part of the free plan.

One record is enough because of how the check works. Birta resolves your domain's A records and looks for its own address among them, and since a resolver follows a CNAME chain on its way to an A record, that one lookup covers both the root and the subdomain case. If the domain already points at us, ownership is proven by that fact, so there is no separate TXT record. The step-by-step guide in the docs walks through it, and the same section exists whether you publish from Cursor or anywhere else.

Frequently asked questions