Check a site built with Claude or ChatGPT before launch

The site took an afternoon. The homepage looks right, the services page has your real prices, and the contact form says “Thanks, we’ll be in touch” when you press send. Then nothing arrives in the inbox, because the form was never connected to anything.

That form is the most common gap in a website built with Claude Code, ChatGPT or Lovable: it looks finished in a preview and isn’t ready for customers yet. It is also easy to miss, because the screen tells you it worked. Most of the checks below are like that: quiet failures that only show up when a customer, a bot or Google finds them first.

TLDR

Get the code into Git, put it on a real host with your own domain and HTTPS, and send a test message through every form. Search the built files for secret keys, because anything prefixed VITE_ or PUBLIC_ ships to the browser. Add security headers, give every page its own title and description, submit a sitemap in Search Console and check the rendered page with URL Inspection. Then decide who updates it next month.

Get it out of the chat and into Git

Where the site lives today depends on the tool. Claude Code works on files on your machine or in a repository, edits them and runs commands, and it works directly with Git: it stages changes, writes commit messages and opens pull requests. ChatGPT’s canvas renders HTML and React in a sandbox preview and can share a canvas with another user, but a preview is not a hosted website. You export the code and host it somewhere. Lovable hosts the site itself and has a two-way GitHub sync for when you want the code elsewhere.

Whatever the starting point, the site needs one home for its code: a Git repository you own, on GitHub or similar. That repository is what a host builds from, what a developer can review, and what lets you undo a bad change. A folder of files on a laptop, or a chat history, is none of those.

Some of these sites come out as Astro projects, which build to plain HTML files. Others are React apps built with Vite, which build to one HTML shell and a JavaScript bundle. The checks below are the same for both. Where they differ, it is noted.

Put it on a host with your domain and HTTPS

A static site needs a host that serves files, and several do it free for a small business site. The trade-offs between them, including which free plans allow commercial use, are in the guide to hosting a small business site for free.

Connect the host to the repository, so every push rebuilds the live site. Then add your own domain. HTTPS should come with it: Netlify, for example, provisions a Let’s Encrypt certificate automatically when you add a custom domain and renews it for you. Check both versions of the address, with and without www, and make sure one redirects to the other.

Send a real message through every form

A static site has no server of its own, so a form has to post to something: the host’s form feature, a small serverless function, or a form service. If the preview shows a thank-you message and no request leaves the browser, the form is decoration.

Test it the way a customer would. Fill it in on the live domain, from your phone, and wait for the email. Then check where it went: the right inbox, not spam, with a reply-to that is the customer’s address and not your own.

Once the form works, expect spam. A hidden honeypot field catches the simplest bots. For the rest, Cloudflare’s Turnstile is a CAPTCHA alternative that works on any site, without routing your traffic through Cloudflare, and its free plan allows up to 20 widgets with unlimited challenges. The check has to run on the server side as well, or a bot skips the widget and posts straight to the endpoint.

Look for secret keys in the browser bundle

This is the check that costs real money when it is missed. An AI tool asked to “connect Stripe” or “save the form to a database” will often put a key in an environment variable, and whether that key stays private depends on its name.

Vite’s docs are blunt about it: variables prefixed VITE_ are exposed in client-side code after bundling and should not contain anything sensitive. Astro has the same rule with a different prefix: only variables prefixed PUBLIC_ are available in client-side code. Anything with those prefixes is readable by anyone who opens the page source.

Build the site and search the output folder for the shapes of real secrets. Stripe’s live secret and restricted keys, for example, start with sk_live_ and rk_live_, while the pk_ publishable keys are the only ones Stripe says are safe in front-end code.

npm run build
grep -rn "sk_live_\|rk_live_\|sk_test_\|SECRET\|PRIVATE" dist/

Supabase is the other common one. Its publishable key is designed to sit in the browser, but only because Row Level Security does the protecting. Supabase’s own docs say to enable RLS on every table in an exposed schema, and that a table without it “is readable and writable by any role with a grant on it”. If the tool created tables for you, open each one and check RLS is on and has policies.

If you find a secret in the bundle, rotate it with the provider first. Moving it to a server-side variable afterwards does not help a key that has already been published.

Add security headers

Headers are instructions the host sends with every page. A static site has no login to attack, but headers still stop other sites framing yours, stop browsers guessing file types, and keep visitors on HTTPS. On Netlify they go in a _headers file in the published folder:

/*
  Strict-Transport-Security: max-age=31536000; includeSubDomains
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Content-Security-Policy: frame-ancestors 'none'

MDN notes that the frame-ancestors directive in a Content-Security-Policy gives more options than the older X-Frame-Options header. A full Content-Security-Policy that also limits scripts is worth adding, but write it after you know every third-party script the site loads, or it will break the analytics and the form.

Give Google something to read

Google’s guidance is to give every page its own title in the <title> element, with distinct text that describes that page. AI-built sites often ship one title and one description for every page, copied from the homepage. Check each page, and add a canonical link pointing to the page’s own address on your domain, so the host’s preview address does not compete with the real one.

A sitemap is optional for a small site. Google says you might not need one at about 500 pages or fewer if the pages link to each other well. It is still cheap to add, and it gives Search Console a list to report against. Then check robots.txt does not block the whole site, a leftover from a staging setup that turns up more often than it should.

Add the domain to Google Search Console and run URL Inspection on the homepage with a live test. It shows the HTML Google got and a screenshot of the rendered page. For a React app built with Vite, this is where you find out whether Google sees your content or an empty shell. Google still recommends server-side rendering or prerendering, because not every bot runs JavaScript. An Astro site sends finished HTML, so the shell problem does not come up.

Ask before you track

If the site loads Google Analytics or an ad pixel and you have visitors in places that require cookie consent, the tracking has to wait for a yes. Google’s consent mode starts with no values set at all, and its example sets analytics and ad storage to denied by default, scoped to the regions where a banner is shown. An AI tool will happily paste the tracking snippet into the page head with none of that. Either set up consent properly, or skip analytics until you need it. Search Console gives you queries and clicks without a cookie.

Check the basics of accessibility

Run the Lighthouse accessibility audit in Chrome, then check three things it cannot fully judge. Text contrast must reach 4.5:1 for normal text and 3:1 for large text, and pale grey text on white is the usual failure. Every image that carries meaning needs alt text that says what it shows. Every form field needs a visible label, not only placeholder text, and you should be able to reach and submit the form with the keyboard alone.

Decide who keeps it running

The site will need changes: new prices, a new photo, a dependency with a security fix, a form provider that changes its API. Someone has to open the project, make the change, build it and check it before it goes live. If that is you with the same AI tool, keep the repository and the notes on how it deploys in one place, so next month’s session starts from the real code and not from memory.

If it is not you, that is what a care plan is for. Appbuff’s Site care is $79 a month on the retainers page, and what it costs to maintain an Astro site breaks down the real yearly numbers.

When to rebuild instead

Most AI-built sites only need the checks above. A rebuild is worth it when the site is a single page app that Google cannot read without JavaScript and there is no clean way to prerender it, or when every change breaks something else. Moving it to Astro keeps the design and the copy and sends real HTML for every page. That is part of Appbuff’s Astro website development, from $1,500 fixed.

Start with the form. Send yourself a message from the live domain today, and if nothing arrives, every other check can wait until it does.

Questions