Why AI-built websites break after launch
You watched the AI build the website. You watched it work in the preview pane. You clicked through, the pages loaded, the forms felt responsive, the styling looked right. You pushed it live. And now real visitors are landing and reporting that things don't work, or the analytics tools are showing form submissions falling to near zero, or your phone is showing a different site than your laptop is showing.
This gap, between "the site worked in preview" and "the site is failing in production," is one of the most common failure modes for AI-built websites. It happens because the preview environment and the production environment are not the same environment, and the AI was only ever tested against one of them. There are four flavors of live-only failure that show up over and over. Knowing the four lets you test for them before launch instead of after.
Failure one: third-party embeds get blocked
A lot of AI-built websites lean on third-party embeds for forms, chat widgets, analytics, video, calendars, and social proof. The embed loads as an iframe from another domain, and inside that iframe is whatever the third party serves. In the AI's preview pane, those iframes load fine because the AI's environment doesn't run privacy shields. In production, on real visitor browsers, a meaningful slice of those iframes get blocked.
Brave Shields, uBlock Origin, Ghostery, Pi-hole, corporate firewalls, and several privacy-focused extensions all default-block third-party iframes that look like they could be trackers. Form vendors look like trackers. Chat vendors look like trackers. Analytics scripts look like trackers. The visitor sees an empty space where the form was supposed to be, doesn't know what's missing, and bounces.
I hit this directly during the build of this site. The intake form was a third-party embed that worked perfectly in the browser I built it in. Then I tested it in Brave with shields up, which is what a meaningful slice of my actual audience uses (technically literate operators run privacy browsers), and the form was invisible. Default blocked. The fix was to rebuild the form as native code on my own domain, which is what's live now. Useful work, but work that would have been cheaper to scope at the start than as a post-launch pivot.
The diagnostic for this failure is direct: open your site in Brave with shields up, in Chrome with uBlock Origin installed, and in Firefox with strict tracking protection on. If any feature disappears, that feature is blocked for some percentage of your real visitors.
Failure two: environment variables drift
The site uses an API key, a webhook URL, an authentication token, a database connection string, or any other secret. The AI set it up. It worked because the secret was set in the development environment. When the site got deployed, the secret either wasn't carried over or was carried over wrong.
The site looks fine. Pages render. Then a form submit fails silently, or an external integration returns nothing, or an authentication flow loops back to login. Behind the scenes, the production environment is making API calls with empty credentials or wrong credentials, and the failures are showing up at the user-facing layer with no indication that the problem is configuration.
The diagnostic is to walk every external integration in the live site, end to end, and verify it actually does the thing it claims to do. If the form claims to send email, send a real submission and verify the email arrives. If the site claims to capture analytics, verify a real visit shows up in the dashboard. If a third-party service is in the loop, verify the round trip works.
The pattern is the same one I documented in two-bugs-one-symptom: surface signals (the form looks like it submitted) need to be paired with semantic signals (the email actually arrived). Either signal in isolation will lie to you.
Failure three: mobile-specific breakage
The AI built the site against a desktop preview. The desktop preview is roughly 1280 pixels wide. Mobile visitors are roughly 360 to 430 pixels wide. The layout that works at 1280 might not work at 360, and the AI didn't test at 360.
Common shapes this failure takes: a sticky element that covers half the visible viewport on a phone, a nav menu that doesn't open or doesn't close, a form whose input fields are taller than the visible area making it impossible to see what you're typing, hero text that overflows its container, images that load at desktop size on a 3G mobile connection causing the page to take ten seconds to paint, modals that can't be dismissed because the close button is offscreen.
Mobile is also where touch versus pointer interactions diverge. AI tools default to mouse-pointer interactions because that's the dominant input in the AI's environment. Hover states, tooltip popovers, multi-step flows that depend on cursor position. All of these can quietly fail on touch.
The diagnostic is to open the live site on an actual phone (not a desktop browser's mobile emulator, which is close but not the same) and run the visitor path end to end. If you find friction anywhere, that's friction your real mobile visitors are also finding.
Failure four: deployment lag
The site got deployed, but the deployed bundle is the old version. The new file changes exist in the repo, the build command was run, the build succeeded, but what's serving live is the previous build. This can happen because of CDN caching, edge-network propagation, framework-specific incremental static regeneration delays, or hosting platforms that have separate "deployed" and "promoted" steps.
The shape is: a change went live, the team is confident it's there, the analytics show different behavior than expected, and nobody realizes that what visitors are actually loading is the version from before the change.
The diagnostic is to check what's live, directly. Open the page in a private browsing window. View the source. Verify that the change you expect is actually in the served HTML. If it's not, the deployment didn't complete, or it deployed to a different environment than you're inspecting.
Why preview environments lie
The reason all four of these failures show up at launch instead of in preview is that the preview is a managed environment optimized for the AI's workflow. It runs without shields. It has env vars wired up automatically. It loads on a wide viewport. It serves the latest build. None of those conditions hold automatically in production.
Most "the website worked when the AI built it but doesn't work now" stories are stories about the gap between those two environments. The AI did its job. The job just had a narrower definition than the real one.
How to catch these before launch
A pre-launch audit. Run the live site against the four conditions above before traffic arrives. Privacy browser test. Environment variable verification. Real device mobile check. Live deployment confirmation. Each takes minutes. Together they catch the failure surface that only shows up after launch, while it's still cheap to fix.
If your AI-built website is currently failing after launch, the same four conditions tell you which failure you're looking at. Pick the diagnostic that matches your symptom. Run it on the live site. The answer is usually visible within an hour.
If your AI-built website is failing after launch and you can't tell which of the four shapes it is, send the site URL, the failure description, what's been tried, and your timeline. VibeKoded can scope the build, ship the prototype, or hand off the production site. → Work with VibeKoded