What to check before pointing a domain at an AI-built site

In short

Before you point a domain at a site built with an AI builder, test five things on the preview address: the contact form actually delivers, the payment keys are live not test, no secret file such as .env is reachable, the email records for the domain exist, and every address variant redirects to one canonical https URL. Do them in that order, because that is the order in which they cost you money. Each takes under ten minutes and none needs a developer.

Why does an AI-built site need checking before launch?

An AI-built site is a site whose pages, layout and copy were generated by a tool such as Lovable, Bolt, v0, Cursor or Replit from a prompt, and whose invisible plumbing was often left as a placeholder. The generated pages look finished, which is the problem: a form that shows "Thanks, we will be in touch" and a form that sends an email look identical to you and to the tool that built them.

SiteHealth is plain-English website monitoring that checks exactly these invisible parts, so we see the same handful of launch faults repeat. The pattern is consistent enough that you can test for all of them yourself in an afternoon, before the first customer ever sees the site.

Pointing the domain is the moment the stakes change. Until then, only you know the preview URL. After it, the site is in search results, on your business cards and in every email signature, and a silent fault runs at full volume with nobody watching.

What should you test first: the contact form

Start with the form, because a dead contact form is the fault that loses the most customers and shows no error to anyone. The test is simple: submit the form from a phone on mobile data, using a real email address you can read, and wait ten minutes for the message.

1. Open the preview URL on your phone with wifi off, so you are on a different network from the one you built on.
2. Fill in the form with a message you will recognise, such as the date and time.
3. Submit it and note whether you see a thank-you state.
4. Check the inbox that is supposed to receive it, including the spam folder, for ten minutes.
5. If nothing arrives, look in the builder's project for the form action or the API route that handles it, and confirm it calls a real mail provider with a real key.

A thank-you screen only proves that the button worked. AI builders wire up the button state because it is part of the visible design; they rarely wire up the sending because that needs an account with a mail provider and a key they do not have. Our earlier guide walks through how to tell whether your contact form sends anything and the three usual causes.

Are the payment keys live, not test?

Look at the page source for the string pk_test_. If it is there, every purchase your customers make goes to Stripe test mode: the card is never charged, no order reaches you, and the customer sees a success page. Stripe issues two pairs of keys per account and the builder almost always started with the test pair, because that is what you use while developing.

The fix is a swap, but it has to be done in two places. The publishable key pk_live_ goes into the page, and the secret key sk_live_ goes into the server environment, never into the page. Stripe's own documentation on API keys describes the difference between publishable and secret keys and why a secret key must stay server-side; you can read it at the Stripe API keys reference.

While you are in the source, search for sk_ as well. A secret key in the page means anyone who views the source can charge cards and read your customer list. That is not a launch-day item; it is an emergency, and the key has to be rolled in the Stripe dashboard before anything else.

Then make one real purchase of the cheapest thing you sell and refund it. That single transaction proves the live key, the webhook, and the confirmation email in one go.

Can anyone download your hidden files?

Type the preview address with /.env on the end. An error page is the good result. A page of KEY=value lines means your database password and every API key are public, and the tool that built the site probably put them there because that is where it kept them during development.

Try these paths in the same way. Each should return an error, not content:

• /.env — environment file with passwords and keys
• /.git/config — the repository, which usually contains the full source and history
• /config.php, /config.json, /settings.py — framework configuration files
• /backup.zip, /site.tar.gz, /database.sql — backups left in the web folder
• /uploads/ or /files/ — a folder that lists its contents instead of showing an error

If any of these returns real content, do two things in order. First block the path or move the file outside the public folder. Second, change every password and key the file contained, because you have to assume it was read the moment it was public.

This is also the point where doing it by hand stops scaling. You can test five paths once; you cannot test them again every hour after the builder republishes. SiteHealth's exposed-files and browsable-folders checks run those probes on a schedule and tell you the hour something becomes public, alongside the contact-form and payment checks above. The full list is on the features page, each check explained in one sentence.

Does the domain have its email records?

Pointing a domain at a site does nothing for the email that domain sends. Mail from your contact form and from your own inbox needs three DNS records or it drifts into spam: SPF, which lists who may send for the domain; DKIM, which signs each message; and DMARC, which tells receivers what to do when the first two fail.

Most AI builders do not touch these because they do not host email. If you use Google Workspace or Microsoft 365, each provides the exact records to copy; the values differ per provider, so use theirs rather than a generic example. A plain-words walk-through of all three is in why business email goes to spam.

The order matters because you will change DNS twice in the same week: once for the site and once for mail. Add the mail records first, while nothing depends on them, then add the site record. Doing it the other way round tends to leave the mail records forgotten until the first quote lands in a customer's spam folder.

Do all four address variants reach the site?

A domain has four common spellings: http://example.com, https://example.com, http://www.example.com and https://www.example.com. All four should end at one of them over https, with a single redirect. On a fresh AI-built deploy it is common for the www version to return an error because only the bare domain was added at the host, or for http to serve the page without redirecting to https.

Test each of the four in a private browser window and watch the address bar. The end address should be identical in all four cases. If one of them fails, add the missing hostname at the host and turn on the host's "force https" setting, both of which are usually a single toggle.

This is also where the certificate comes from. Hosts that use Let's Encrypt issue a certificate per hostname, so a www name that was never added has no certificate and shows a browser warning. The Let's Encrypt documentation explains the ninety-day lifetime and the automatic renewal that most hosts handle for you; what it cannot handle is a hostname that was never added.

When should you actually switch the DNS?

Switch when the five tests above pass on the preview URL, and switch on a day you can watch it. Lower the TTL on the existing record the day before, so the change spreads in minutes rather than hours. Then change the record, test the four address variants again on the real domain, and send yourself one more contact-form message from the real domain because some builders bind form handling to the hostname.

Keep the preview URL alive for a week. If the real domain misbehaves, you can point back at it while you fix the fault, which is faster than debugging under load.

The objection at this point is usually cost of time: the builder shipped the site in an afternoon, and an afternoon of testing feels like it doubles the work. It does. The alternative is finding out about the dead form from a customer who mentions, weeks later, that they tried to reach you twice, and never knowing how many did not mention it. Two hours before launch is the cheap version of that lesson.

Run the free check on the preview address now

Paste your preview URL into the free website health check on the SiteHealth homepage. It runs the public, non-intrusive checks from this guide in about a minute and returns a plain-English report you can work through before you touch DNS. No account is needed for the free check. If you want the same checks to keep running every hour after launch, and an email or push alert the hour something breaks, that is what a paid plan adds.