Connect a Domain to an AI-Generated Website

Connect the domain only after the new static site works at its host-provided preview address. Add the owned domain to the hosting project, copy the exact DNS instructions for that project, and change only the website records at the authoritative DNS provider. Keep the old destination and a dated record of the old DNS values until you have checked both the site and email. Do not copy an A-record IP from a general tutorial: the host's project instructions are the source of truth.

This guide starts with a deployed set of static files and an owned domain. For the file-to-host step, use the static publishing guide. A registrar transfer is a different job. So is moving a site from Wix, Squarespace, or another builder while keeping its other services.

What must be ready before DNS changes?

Open the new site's preview URL in a private browser window. Visit the homepage and every important route. Confirm that assets load without the local development server. If a contact form, checkout, or login is only a visual mockup, do not call it a working feature. Resolve it before traffic moves.

Then confirm that you control the domain and know which provider holds its authoritative DNS zone. The registrar and DNS provider may differ. Save a full export or screenshots of the zone. Record the old A, AAAA, and CNAME values for the website hostnames. Also record MX, TXT, CAA, and any verification records. Mark mail-related MX and TXT values as protected. SPF, DKIM, and DMARC often live in TXT records; deleting them can damage mail delivery even while the website appears healthy. The email-preservation guide explains that boundary in detail.

Before cutover, ask the domain owner to check the CAA policy that applies to each new hostname against the certificate authority the new host uses. A restrictive CAA record can block HTTPS issuance even when the website's A or CNAME record is correct. If the policy does not permit that authority, stop and get the owner's approval for the specific CAA authorization the host requires. Keep existing authorizations and other security controls unless their owners approve a separate change. Never delete all CAA records to make certificate issuance pass. Vercel lists unauthorized CAA records as a certificate failure cause; your host may use a different authority.

Choose a primary address, such as https://www.site.test/, and decide whether the root domain should redirect to it. Check which behavior the new host supports. Add both names to the hosting project when needed. Some hosts require a domain-ownership TXT record. Add only the value shown for your project. Vercel's domain guide, for example, distinguishes apex A records, subdomain CNAME records, and ownership verification. Those are examples of record types, not values to reuse on another host.

How do I make a cutover sheet?

This is an illustrative worksheet, not a report of a live migration. Replace every sample value with values copied from your DNS zone and hosting dashboard.

Write the time, operator, provider, and old values next to the table. Keep the old host active through the cutover. If the provider asks you to change nameservers, stop and plan a whole-zone move. Nameserver changes can make the old zone irrelevant. Recreate all records that must survive in the new authoritative zone before that switch. Vercel explicitly notes this risk in its custom-domain instructions.

How do I verify the new destination?

Make the smallest approved record change. Wait for the new records to appear in the host's domain status and in a public DNS lookup. DNS caches can show different answers for a while, so check more than one resolver. Do not treat a successful DNS lookup as proof that the right site serves traffic.

Open https:// for the primary and alternate names in a private window. Confirm that the certificate matches the domain, that the final address is the planned one, and that the response is the new site rather than the old host's fallback page. Test a deep route directly, not only through a homepage click. Check images, CSS, and scripts for failures or insecure HTTP requests. Hosts commonly issue certificates after DNS validation; Vercel documents that dependency. If the certificate is pending, keep the old service available and follow the host's status page. Do not announce the cutover as complete on HTTP alone.

Compare MX and protected TXT records with the saved zone. Send a test message to the domain and another from it. A DNS record can look unchanged while a linked mailbox subscription or forwarding service has ended, so the live mail test matters.

What triggers rollback?

Set the rollback rule before editing DNS. For this worksheet, a failed HTTPS page, the wrong site at either hostname, a missing critical route, or failed inbound mail is a stop condition. Put the old website records back using the saved values at the current authoritative DNS provider. Keep mail records intact. If you changed nameservers, restoring only an old A record in the former zone will not repair the active zone. Recheck the public answer and the browser after the rollback; caches may delay what visitors see.

The domain is connected only when the intended page, HTTPS, deep routes, and email all pass. Record the tested URLs and time, then hand the site to a separate launch acceptance review. This domain procedure does not give Figment control of DNS. Figment's AI editor is still access-gated and works on a separate static copy; it does not promise custom-domain setup. You can prepare a site-change prompt now or check editor access.

Sources and access date

Vercel's custom-domain instructions and certificate guidance were accessed 2026-09-23. They illustrate host behavior. Use the instructions for your actual project.