Can I Use My Own Domain With an AI Website Builder?

Yes. Every Zugo project publishes to a free address like your-project.zugo.run, and you can connect a domain you own instead. You add the domain in the project, point a DNS record at Zugo, and the site serves from your address. You buy and keep the domain yourself; nobody registers it on your behalf.

That last sentence is the part that decides everything else. A domain is an asset you rent directly from a registrar, which is why moving a site between hosts is an afternoon rather than a migration, and why it is worth owning one before you need it.

What is the difference between the two addresses?

One is instant and shared, the other is yours and takes a DNS change. Functionally the site is identical: same pages, same speed, same behaviour. The difference is what the address says about the thing it points at.

your-project.zugo.run exists the moment you publish. It is a real, live, shareable URL, which makes it perfect for the phase where you want reactions rather than customers. Sending a link that works on a phone beats describing an idea, every time.

Your own domain is the version you use when the project stops being an experiment. It carries your brand, it survives a change of tooling, and it is the address you print on things. Connecting a custom domain sits on the paid plans; Pro is $25 per month and Business is $99 per month, while Free comes with 5 credits and publishes to zugo.run as normal.

How do you actually connect a domain?

Four steps, and only one of them involves waiting.

1. Buy the domain, if you have not already, from any registrar. This is a purchase you make directly, and the annual fee goes to the registrar rather than to Zugo.
2. Add it in the project settings. You are telling the host which address to expect and answer for.
3. Create the DNS record at your registrar, pointing at the target Zugo gives you. This is the step people fear and it is a single row in a table.
4. Wait for propagation and check. DNS changes take time to spread. Minutes is common, longer is normal, and the fix for "it is not working yet" is almost always patience rather than another change.

The most frequent mistake is editing DNS in the wrong place. If you bought the domain at one company but its nameservers point somewhere else, the records you need to change live at the second company, not the first. Check which nameservers are authoritative before you start typing.

Which route should you pick?

Three shapes cover almost everyone, and they are not equally good for the same job.

The third row is real, not a formality. Vercel is a built-in connector, so a project can deploy to your own Vercel account, and after a GitHub export you can deploy the repository yourself in the ordinary way. If your company already has a deployment story, use it, and see can I export the code from an AI builder for what you get.

When is a custom domain worth paying for?

When somebody other than you is meant to trust the page. That is the whole test, and it cuts more cleanly than any feature comparison.

Anything commercial qualifies. A page that takes payments, collects an email address, or represents a business is judged partly by its address, and a builder subdomain quietly costs you credibility with exactly the visitors you were trying to convince. Ask for a card on something.zugo.run and a portion of people will simply close the tab.

Anything you intend to link to for years qualifies too. Links accumulate, and the value accumulates to whoever owns the address, which is an argument for putting your content on a name you control before it starts earning attention rather than after.

What does not qualify: prototypes, playtests, portfolio demos, and the fortnight where you are still deciding whether the idea works. The free address is genuinely enough there, and buying a domain for something you might abandon on Thursday is a small, cheerful waste of money.

Can you move a domain between projects or away from Zugo?

Yes, because the domain was never held here. You own it at your registrar, and the DNS record is a pointer you can repoint. Changing where a domain sends visitors is a routine edit, not a request you file with a support desk.

That is the concrete meaning of the ownership claim. Combined with GitHub export, it means a project can leave entirely: the code goes to your repository, the data stays in your Supabase project, the payments were always in your Stripe account, and the domain follows a DNS change. Nothing has to be recreated from scratch.

Worth planning for the gap, though. If you move hosting, keep the old deployment live until the new one answers, because DNS does not switch for every visitor at the same instant. A short overlap avoids the window where some people see the new site and others see nothing at all.

What should you check after it goes live?

Open the real address, not the builder preview. That is the context a visitor gets, and it is where the difference between "published" and "actually working" shows up.

A quick pass that catches most problems: load the domain with and without www, open it on a phone, click every navigation item, and submit any form on the page for real. Every build is booted in a sandbox before it reaches you, and one that fails to load is reported as a failure rather than handed over. That lowers the odds of a blank page and does not remove them, and it says nothing about whether a DNS record has finished propagating.

If the site does not appear, work backwards rather than rebuilding. Does the zugo.run address still work? Then the build is fine and the problem is DNS. Does the record exist at the authoritative nameserver? Then it is propagation, and the answer is to wait. Rebuilding a project to fix a DNS problem costs credits and changes nothing.

Does a custom domain help with search?

It helps in the sense that it is the prerequisite, not the technique. Search engines index either address perfectly well; what your own domain gives you is a place where authority accrues to you instead of being scattered across a shared subdomain.

The things that actually move rankings are unchanged: pages that answer a real question, a clear structure, honest content, and links from elsewhere. A domain is where those benefits land. Pick one early if you can, because switching later means redirecting links you have already earned.

For an ecommerce project the argument is stronger still, since a store lives or dies on trust signals and the address is the first one a visitor reads. That case is covered in does an AI builder work for ecommerce, and the full DNS walkthrough lives in AI app builder custom domain.

The sensible order is to build first and buy the name once the thing exists. Describe the site at zugo.dev, publish it to the free address, show it to somebody whose reaction you trust, and connect the domain when the answer is yes.