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 or shop.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. The address it already has keeps working. You are putting up a signpost, not relocating the building.

The rest of this page is about the part nobody writes down: what to do when that one record does not work. Most guides on this subject 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 your site and published it, the site 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. Nothing about it is a draft. That already puts you ahead of a page living inside a chat panel, where an artifact has no address to point a domain at in the first place.

A custom domain does not replace that. It adds a second domain name that resolves to the same files. Both keep working. This is the single most common misunderstanding about the whole procedure, and it causes people to delay connecting a domain because they think it is a migration with a rollback plan attached. It is not. You keep editing the live site exactly as you did before, and both addresses show the result.

If you have not published yet, do that first, from Claude Code, or any tool you already work in. It is easier to point a domain at a site that exists, because then you can tell whether a broken page is a DNS problem or a site problem. If you want the shape of the thing you are pointing at, we wrote separately about 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 name from a registrar: Namecheap, GoDaddy, Porkbun, whoever. By default, that registrar also answers DNS questions about your domain, so the record goes in their control panel and everything is simple. Hosts call this a third-party domain: registered in one place, pointed at another.

But a domain can delegate that job elsewhere. If you or anyone before you ever pointed the domain's nameservers at Cloudflare, Route 53, or a web host's DNS, then the registrar no longer answers for it. You can add a perfect A record in the registrar's panel and it will do nothing at all, because nobody on the internet is asking that panel anymore.

To find out where the zone actually lives, look up the domain's nameservers:

dig NS example.com +short

Whatever comes back is where your records have to 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 you 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 knowing it saves you from fighting your DNS provider.

A CNAME says "this name is an alias for that other name." The rule for it comes from 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, example.com with nothing in front) is required to carry other data. 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, which points at an IP address directly.

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 their IP addresses without you touching anything.

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

The root and www are two separate names

example.com and www.example.com are different names. Not variants, not capitalisations of each other, but different entries in DNS that resolve independently. Adding one does not add the other.

Decide which one people will actually type and see in your links, and connect that one first. If you want both to work, you need either a second record for the second name, or a redirect from one to the other, and whether you get that for free depends entirely on your host. Some do it silently. Some, like NationBuilder, say plainly that joining a root domain to its www version "is actually a technical process" requiring an HTTP redirect. Assume nothing; check what your host does.

If your DNS provider proxies traffic, verification will fail

This one is worth its own section because it 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 about what it does to DNS: 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.

Now read that from your host's side. Your host verifies the domain by asking DNS where the name points, and expects to see its own address. With the proxy on, DNS answers with Cloudflare's address instead. The record is correct. The domain works in a browser. Verification still fails, because from the outside, the domain points at Cloudflare, not your host.

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

When Verify says no: five things to check

Before you click 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 it prints something else, or nothing, work down this list.

The record is in the wrong zone

The one from the section above. 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 will 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 in full, 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 you just added a record to a name that never had one. 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 real mechanism is the TTL, a value carried on every DNS record that, per RFC 1035, tells resolvers how long they may cache it before asking again. 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 rule you can actually use:

• The name had no record before. There is nothing cached to expire. It usually resolves within minutes.
• You changed an existing record. Worst case is roughly the TTL that record carried before you edited it. If it was an hour, wait an hour.
• You changed nameservers. This is the slow one, and where the 48-hour figure earns its keep.

The spread in the guides themselves 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 you about the certificate, nothing is broken. A certificate authority will only issue an SSL certificate for a name once it can confirm the name points at the server asking for it. That confirmation cannot happen until your record is live. So the order is always: record, then resolution, then certificate, then a clean padlock.

Give it a few minutes after the domain verifies. If the warning persists for longer than that, it is a real problem and worth raising with your host.

How many records should this take?

Here is a thing worth knowing before you assume a long list is normal. As checked on August 11, 2026, 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 purely so the domain does not fall off later, because their 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 a requirement of DNS.

Knowing the difference is the actual skill here. When a host asks for a TXT record to prove you own the domain, that is their verification design. When it insists on an A record at your apex, that 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 you. Add that record at your DNS provider, come back, and press Verify. Once it passes, the domain is active and the secure connection is set up for you.

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-domain case and the subdomain case. If the domain already points at us, ownership is proven by that fact, so there is no separate TXT record to add. 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