How to Connect Your Domain to Your AI-Built Website

Three places, three jobs

Connecting a domain feels like one task, but it involves three different places, and most confusion comes from mixing them up.

• The registrar is the company you bought the domain from; for a .co.za address that's usually a local registrar such as xneelo. It records that the domain is yours and which nameservers answer for it. You don't need to change registrar to connect the domain to anything.
• The DNS host is wherever your domain's records are kept and edited. Often that's the registrar too, but not always: if the domain's nameservers point somewhere else, that somewhere else is your DNS host, and it's the only place where record changes do anything.
• Your AI website builder hosts the site. It doesn't control your domain; it only tells you which records to create and then checks that they're there.

So the whole job is this: get the right records from your builder, and put them in the right place. Our guide to what DNS is explains what each record type does, if you want the background first.

Step 1: Add the domain in your builder first

Start in your AI website builder's domain settings, not at your registrar. Add your domain there and the builder shows you the exact records it expects, with values made for your project. Copy those values straight from the builder rather than from a guide or from memory: builders change their targets over time, and some make a value unique to your domain.

Adding the domain in the builder changes nothing live yet. It only tells the builder which domain to expect. Add the bare domain (yourbusiness.co.za) as well as www if the builder asks for them separately, since most people type the address without www.

Step 2: Find out where your domain's DNS is managed

Look up your domain's nameservers. Your registrar's control panel shows them, and so does any free WHOIS lookup (a public record of who holds a domain and its settings). If the nameservers belong to your registrar, you edit records there. If they belong to another company, such as a previous web host or a DNS service, that company is your DNS host, and records you add at the registrar are ignored.

Some registrars also split billing and DNS into separate logins. Make sure you can open the screen that lists your domain's records before you go further.

Step 3: Choose your route: add records, or move your nameservers

There are two ways to connect the domain, and they aren't equally safe for everything else your domain does.

If you take the nameserver route, first work through the checklist to copy every record further down. Once the switch is done, the builder usually creates the website records itself, so Steps 4 and 5 apply to the add-records route.

Pick one route and finish it. A common mess is starting a nameserver change and then adding records at the old DNS host "just in case". Once the nameservers point to the builder, the old DNS host's records aren't read at all.

What goes on the bare domain: A, ALIAS or ANAME

The bare domain, also called the root domain, is your address without www: yourbusiness.co.za on its own. www takes a CNAME, a record that says "this name is another name". The bare domain can't: the DNS standards don't let a CNAME share a name with any other record, and the bare domain always carries records of its own. Our DNS guide explains that rule. What it means here is that builders ask for something else at the root.

Some give you an A record, which points at a fixed numeric address. Others ask for an ALIAS or ANAME record, which works like a CNAME but is allowed at the root. ALIAS/ANAME isn't part of the DNS standards: each DNS host builds its own version, under its own name, and not every host offers one. Some builders accept an A record where ALIAS or ANAME isn't available; others accept only ALIAS or ANAME. Your builder's domain instructions say which. If your DNS host offers none of the types your builder accepts, use the nameserver route.

Step 4: Clear out the records that conflict

Before you add anything, look at what's already on the bare domain and on www, and delete what would compete with the new records.

• Old A records. A parking page, a "coming soon" page or a previous website often leaves an A record behind. DNS doesn't reject a second A record on the same name; it hands out both, so some visitors reach your new site and some reach the old one. Builders' own instructions commonly warn that a leftover A record can stop the domain working or the security certificate showing.
• AAAA records. These are the newer (IPv6) version of an A record. If one still points at an old server, visitors whose connection uses IPv6 go there instead. If your builder didn't ask for an AAAA record, delete any that's there.
• An old CNAME on www. Replace it; a name can hold only one CNAME.

Leave everything else alone. MX records carry your email, and TXT records often prove to Google or an email service that you own the domain. Deleting those breaks things that have nothing to do with your website.

Step 5: Add the records your builder asked for

A typical set looks like this. The values are placeholders: use exactly what your builder showed you, including the record type.

# A, or ALIAS / ANAME: whichever your builder asks for
# @ means the bare domain, yourbusiness.co.za
Type:  A
Name:  @
Value: the address or target your builder shows you

Type:  CNAME
Name:  www
Value: the target your builder shows you

One detail catches people out. A name that ends in a full stop (target.example.com.) is complete; a name without one can be treated as relative, and some DNS panels quietly add your own domain to the end of it. After saving, open the record again and check it shows exactly the value your builder gave, not that value with yourbusiness.co.za stuck on the end.

Step 6: Wait, then check from somewhere else

Every DNS server that has looked up your domain keeps its answer for a set time, the record's TTL (time to live), before asking again. Until that runs out, it keeps handing out the old answer. That's why a correct change can look broken for a while.

Check from a different network, such as your phone on mobile data, because your own computer and browser also hold on to old answers. Then go back to the builder and let it verify the domain. Clicking verify over and over doesn't speed anything up, and some builders temporarily refuse an action repeated too quickly. Once the builder can see the records, your builder issues the security certificate that gives your site its padlock; you don't have to buy or install one.

How long it takes, and how to shorten the wait

Expect anything from a few minutes to a day or more; your builder's domain instructions give its own estimate. The wait depends mostly on the TTL of the old records, since servers keep the old answer until it runs out. If your DNS panel lets you set the TTL, lowering it on the records you're about to change, a day or so before you change them, shortens the wait. A nameserver change can take longer than a record change, because the change of nameservers has to spread before your new records are even read.

If it still doesn't work after the time your builder quotes, stop waiting and work through the table in “Why verification gets stuck” below.

Before you move nameservers: copy every record

Moving nameservers hands the whole domain to a new DNS host, and records don't come with it. Anything you haven't recreated there stops existing the moment the switch takes effect, including the MX records that deliver your email. So, before you switch:

• List every record on the domain at your current DNS host: take a screenshot or copy the list into a document.
• Find the ones that aren't the website: MX records (email), TXT records (these prove ownership to Google or an email service, and help your email avoid spam folders) and any records for subdomains such as mail or shop.
• Recreate them at the new DNS host before you change the nameservers, or as soon as the new host lets you.
• After the switch, send yourself an email from an outside address and check that any subdomains still load.

Adding records at your current DNS host, the other route, doesn't touch your email at all. That's the main reason it's the default.

Why verification gets stuck

If your builder still can't verify the domain after the time it quotes, one of these is almost always the reason.

The prompt to give your AI

This prompt works in any AI chat. It doesn't need access to your builder or your DNS host: you paste in what they show you, and the AI checks it. Don't paste passwords or login details, only the records.

I'm not a coder. I want to connect my own domain to a website my AI
website builder hosts. Don't guess any values. Work only from what I
paste below.

My domain: [yourbusiness.co.za]

The records my builder says it needs:
[paste exactly what the builder's domain settings show]

The records currently on my domain at my DNS host:
[paste the full list from the DNS panel, including MX and TXT]

My domain's nameservers:
[paste them, from the registrar or a WHOIS lookup]

Tell me, in plain English:
1. Whether the place I've pasted my current records from is the one
   my nameservers point to.
2. Which existing records I must delete, and why.
3. Which records I must keep (email, verification and anything else
   not related to the website).
4. Exactly which records to add, using only the builder's values.
5. Whether my DNS host seems to support the record type the builder
   wants at the bare domain, or whether I should move my nameservers
   instead, and what I'd have to copy across first if I do.
6. How I'll know it worked, and what to check if it hasn't after a day.

If anything I pasted is missing or unclear, say so instead of guessing.

What to check in the AI's answer

• Every value it tells you to add matches what your builder showed. If the AI has "corrected" a target or an address, don't use it; go back to the builder's screen.
• It kept your MX and TXT records. If it tells you to delete everything and start fresh, your email and any domain verification go with it.
• It didn't put a CNAME on the bare domain. That's the rule this page explains above; a CNAME belongs on www.
• It told you to remove old A and AAAA records, not to add the new ones alongside them.
• It confirmed your records came from the DNS host your nameservers point to. If it skipped that, ask again: records in the wrong place do nothing.
• It told you how to confirm it worked, including checking from another network.
• If it suggested moving nameservers, it listed what to copy across first. Moving without that list is how email goes missing.

If the answer and your builder's own instructions disagree, the builder wins: it's the one checking the records.