How to audit an AI-built website before launch
The cheapest moment to find a problem in an AI-built website is before launch. The most expensive moment is after launch, after real visitors have hit the failure, formed an impression, and left. The gap between those two moments is the audit.
A pre-launch audit isn't a code review. It's a structured walk through the dimensions where AI-built sites tend to fail in ways the build environment can't surface. Most of these failures are predictable, which means most of them are catchable, which means most of them can be fixed before launch instead of after. The audit gives you a defensible answer to one question: is this site ready for real visitors, or is it still a beta.
Below is the checklist I run on AI-built sites before they ship. Ten points, each a different failure mode, each with a concrete diagnostic. If any of the ten surface a real issue, the work is either to fix it now or to delay launch until it's fixed.
1. Privacy-browser visibility
Open the site in Brave with shields up. Open it in Chrome with uBlock Origin installed. Open it in Firefox with strict tracking protection on. Walk every visitor path. If any feature disappears (forms, modals, chat widgets, video players, calendars), that feature is blocked for a meaningful slice of real visitors.
The fix is usually to replace third-party iframes with native code rendering on your own domain. The contact forms post has the architectural detail.
2. End-to-end form submission
Pick every form on the site. Fill it out with realistic data. Submit. Verify the submission arrives at the real destination, not a stale test endpoint. Verify the notification email reaches you, not a deprecated inbox. Verify spam filters didn't eat it.
A form that submits without verifying round trip is a form that may be silently dropping leads.
3. Real-device mobile walk
Pick up an actual phone. Navigate to the site. Walk the visitor path one-handed, with the thumb, on the actual viewport. Note every friction point. Sticky elements covering the form, modals you can't dismiss, layouts that overflow horizontally, input fields that don't trigger the right keyboard, submit buttons below the fold.
A desktop browser's mobile emulator is close but not the same. The real device surfaces real failures.
4. Slow-connection performance
Throttle your connection to 3G in Chrome devtools, or use a real cellular connection on the phone. Load the site cold. Time how long it takes to become usable. Note what loads first, what loads slow, what loads not at all.
Real visitors on real cellular connections experience the site at speeds the AI build environment never saw. If the site takes more than four seconds to become usable on throttled 3G, the performance gate is already failing for some percentage of mobile visitors.
5. Search-engine surface
View the source of each page. Check that every page has a unique title, a meta description, a canonical URL, and the right Open Graph metadata for social sharing. Check that the sitemap exists and lists every page that should be indexed. Check that the robots file isn't blocking pages you want indexed.
AI tools generate these inconsistently. Some pages get full SEO surface, others don't, and the gap can quietly cost you ranking on the pages that didn't.
6. JSON-LD structured data
If the AI generated structured data (BlogPosting, Product, Organization, ContactPage), validate each schema against Google's rich-results test. Check that the structured data derives from page chrome (titles, dates, author) not from user-submitted content. Check that no fields leak internal metadata into the schema.
Structured data is one of the easiest ways to qualify for rich search-result features, and it's also one of the easiest places for AI tools to produce invalid output that quietly fails validation.
7. Environment-variable verification in production
The site uses API keys, webhook URLs, authentication tokens, or database connection strings. Verify each one is set correctly in the production environment, not just in development. Trigger the integration end to end. Verify the external service actually receives the call and returns the expected response.
Most "the site worked when I tested but breaks in production" stories trace back to env vars that didn't carry over or carried over wrong.
8. Deployment verification
Open the live site in a private browsing window. View the source. Verify the change you most recently expected to deploy is actually in the served HTML. If it isn't, the deployment didn't complete, or it deployed to a different environment than you're inspecting.
This sounds obvious until you've shipped something three times because the first two pushes didn't actually go live.
9. Monitoring and alerting
Confirm you have a way to know when the site breaks in production. At minimum, an uptime monitor that pings the site every minute and alerts you if it stops responding. Ideally, application monitoring that surfaces error rates, failed form submissions, slow pages, and unusual traffic patterns.
If the site goes down or starts erroring at 3 AM, you need to find out before your visitors do.
10. Cold-visitor walk
Sit down and navigate to the site as if you'd never seen it. Read every sentence the way a stranger would. Try to complete the conversion task without prior knowledge. Note every moment of confusion, friction, or backtrack.
This is the test that surfaces problems the other nine can't catch: the site might pass every technical gate while still being incomprehensible to its target visitor. The cold-walk is uncomfortable because you have to pretend you don't know what's on each page. The discomfort is the diagnostic.
What the audit produces
The audit produces a decision, not a fix list. The decision is one of three:
The site passed all ten. Launch.
The site failed a few isolated checks. Run a targeted fix pass on the specific failures, re-run those checks, then launch.
The site failed broadly across multiple checks. The site is still a beta. Either delay launch and run a hardening pass, or launch with explicit beta framing so visitor expectations match reality.
The pattern behind the audit is the same one that should govern any production handoff: structure first (does the surface exist), function next (does it work end to end), performance last (does it perform under load). A site that passes structure but fails function isn't shipped. A site that passes function but fails performance isn't shipped either.
Why this beats launching and patching
The shape of "launch first, fix later" is what produces the break-after-launch failures. Real visitors hit the failure, form an impression, leave. The signal that should have surfaced the failure (the form submission, the slow page, the broken modal) never reaches you in time to recover the lost visitor.
The audit costs hours. The lost-visitor cost compounds over weeks. The math is consistent in favor of running the audit first.
If you've never run a pre-launch audit on an AI-built site, the first time is the most surprising. Most sites fail at least three of the ten points on first pass, even when the operator was confident the site was ready. That gap is exactly what the audit exists to surface.
If you're staring at an AI-built site and aren't sure whether it passes the audit, send the site URL, what's been tested already, and your launch timeline. VibeKoded can scope the build, ship the prototype, or hand off the production site. → Work with VibeKoded