How to Set Up a Custom Domain for an AI-Built Website

If you are building with Claude Code, Codex, or another agent in a real Linux environment, the first production milestone is usually the same: set up a custom domain for an AI-built website. A subdomain is fine for testing, but a real domain makes the site feel legitimate, helps with email, and avoids the “temporary project” vibe.

The hard part is not buying the domain. It is getting DNS, SSL, and hosting aligned without waiting hours to discover a typo in an A record. This guide walks through the practical version: what records you need, how to point the domain to your server, how to verify it, and how to avoid the mistakes that cause most launch-day failures.

What you need before you point the domain

Before changing any DNS, make sure you already know where the site will live. For a typical AI-built website, that means you have:

• A registered domain, such as example.com
• Your hosting server’s public IP address or load balancer hostname
• Access to the DNS provider for the domain
• A web server configured to answer requests for the domain
• SSL/TLS ready, or at least a plan to issue certificates after DNS updates

If your hosting platform handles provisioning automatically, even better. On Vibesies, for example, custom domains are part of the normal workflow on paid tiers, so you are not manually stitching together a bunch of half-finished setup steps. But the DNS principles are the same whether you are using Vibesies or a box you manage yourself.

Custom domain for an AI-built website: the DNS records that matter

Most people only need two records to get started:

• A record for the root domain (example.com) pointing to your server’s IPv4 address
• CNAME record for www.example.com pointing to example.com or to a canonical host name provided by your platform

Here is a common setup:

@     A      203.0.113.10
www   CNAME  example.com

That means someone typing either example.com or www.example.com ends up at the same site.

Some hosts also support AAAA records for IPv6. If you have IPv6 configured end to end, it is worth adding one. If you are not sure, skip it for now. A broken IPv6 record can create confusing partial outages that only show up for some users.

When to use CNAME flattening or ALIAS records

DNS has one annoying rule: a traditional CNAME cannot live at the root of the domain. So if your provider gives you a hostname instead of an IP address, you may need one of these:

• ALIAS or ANAME records, if your DNS provider supports them
• CNAME flattening, if your provider offers it
• An A record, if you have a stable IP

If you are using a managed hosting stack, the platform may tell you exactly which record type to use. Follow that instruction rather than guessing. The wrong record type is one of the fastest ways to waste an afternoon.

How to set up a custom domain for an AI-built website step by step

Here is the simplest reliable process:

1. Decide on the canonical version — usually either example.com or www.example.com
2. Create the DNS records — add the A/CNAME/ALIAS records your host requires
3. Wait for propagation — usually a few minutes, sometimes longer
4. Verify the DNS response with dig, nslookup, or an online checker
5. Configure the web server to answer for the new hostname
6. Issue SSL certificates with Let’s Encrypt or your host’s built-in automation
7. Test both HTTP and HTTPS on the root domain and www

That sounds basic, but the order matters. If you issue SSL before the domain resolves to the right server, validation may fail. If you update the web server but forget DNS, the site will work locally and fail publicly. If you only set one hostname, the other one may show a certificate warning or a 404.

Example: root domain plus www

Let’s say you want example.com to be the main site and www.example.com to redirect to it.

Your setup might look like this:

• @ A 203.0.113.10
• www CNAME example.com
• Web server returns a 301 redirect from www to the root domain

This is a clean pattern because it keeps one canonical URL for SEO and analytics. Search engines and social previews behave better when there is one preferred version.

SSL is not optional

If you are putting a custom domain on an AI-built website, you need HTTPS from the start. Browsers expect it, users expect it, and many third-party tools assume it.

The usual options are:

• Let’s Encrypt with Certbot or another ACME client
• Managed SSL from your hosting platform
• Reverse proxy termination at the edge, if you are using a load balancer or CDN

With a Linux host, the most common pattern is nginx in front, a site-specific server block for the domain, and automatic certificate renewal. If you are on a managed platform like Vibesies, SSL is typically part of the deployment workflow, which saves you from having to babysit renewal jobs.

Certificate checklist

• Certificate covers both example.com and www.example.com
• Renewal is automated
• Port 80 is available long enough for HTTP validation or redirect handling
• Redirects go to HTTPS, not the other way around

A surprisingly common mistake is to force HTTPS before the certificate exists. That creates an endless loop or a browser warning page that makes the site look broken even though the backend is fine.

Common DNS mistakes that break AI-built websites

Most domain setup problems are boring, which is exactly why they get missed. Here are the ones worth watching for:

1. Editing the wrong DNS zone

People often buy a domain from one provider and host DNS at another. If you update the registrar’s default zone instead of the active nameserver zone, nothing changes publicly.

2. Forgetting the apex domain

Only setting www and forgetting the root domain means half of your traffic may hit an error page or a parked domain.

3. Mixing old and new records

Leaving an old A record in place while adding a new one can send visitors to two different servers. That becomes a mess during deploys, especially if the machines do not share the same content.

4. Pointing DNS at a server that is not configured yet

DNS can be live long before the web app is ready. If your web server is still showing the default nginx page, people will see that instead of your site.

5. Caching assumptions

DNS propagation is not magic, but caches do make timing unpredictable. Some resolvers refresh quickly; others hang onto old answers longer than you expect.

If you need to make a change under pressure, lower the TTL ahead of time rather than the minute before launch. That way future changes roll out faster.

A simple launch checklist for a custom domain

Use this before you announce the site:

• Confirm the domain resolves to the correct server
• Test example.com and www.example.com
• Verify HTTPS loads without warnings
• Check the certificate subject and expiry date
• Make sure HTTP redirects to HTTPS
• Pick one canonical hostname and redirect the other
• Update your analytics, sitemap, and Search Console property
• Send a test request from a different network or device

If you are deploying frequently, keep this checklist in the repo or in your runbook. Domain setup is not something you should relearn from scratch every time you ship a new project.

How this affects SEO and trust

A custom domain for an AI-built website is not just a branding detail. It affects indexing, link equity, and user trust.

A few practical SEO notes:

• Use one canonical domain and redirect everything else to it
• Make sure your XML sitemap uses the canonical URLs
• Update internal links after choosing the final hostname
• Add the domain to Google Search Console and Bing Webmaster Tools
• Keep title tags and metadata consistent after the move

If you are moving from a temporary subdomain to a custom domain, expect some churn while search engines recrawl the site. That is normal. What matters is that your redirects, canonicals, and sitemap all agree.

Where Vibesies fits in

If your site is already being built inside a sandboxed Linux environment, a managed host can save you from wiring together the last mile by hand. Vibesies is one example of that model: you can keep working with your AI engineer while the hosting layer handles the container, deployment, and domain plumbing.

That does not remove the need to understand DNS. It just means you spend more time shaping the site and less time chasing certificate edge cases.

Final thoughts

The best way to set up a custom domain for an AI-built website is to keep the system boring: one canonical hostname, clear DNS records, working SSL, and a quick verification checklist before launch. If you get those parts right, your site looks professional from day one and future deploys are much easier to manage.

For most teams, the path is straightforward: choose the domain, point DNS correctly, confirm HTTPS, and make sure your host answers on the exact hostname you want search engines and visitors to see. Do that once, document it, and you will avoid the most common production headaches later.