Blog · SEO without the hype
Vibe-Coded Websites: What Actually Breaks After Launch
Vibe-coded sites rarely break at launch. They break months later: rendering, hreflang, forms, consent. What to check before you ship.
Launch day is not when it breaks
Vibe-coded sites almost never fail on launch day. They fail months later, quietly, in ways nobody on the team is watching for.
We build websites for a living, and a growing share of our work is no longer building. It is cleanup. A founder or marketing lead describes a site to an AI builder, gets something that looks right almost immediately, ships it, and calls us later. The complaint is never it looks bad. It is "we get no organic traffic." Or "a lead swears they filled in the form and we never received it." Or "our lawyer asked where the form data is stored and nobody knows."
That is the shape of the problem. Producing pages is now cheap and often good. The expense sits in everything that only fails once real traffic, real leads, real regulators and a second developer arrive. None of it shows at launch. All of it shows on an invoice later.
Here is the failure list we actually see, roughly in the order it bites.
Rendering: test your build, not the internet's opinion of it
The advice you will find everywhere says AI-built sites are client-rendered, crawlers get an empty shell, so you cannot rank. As a blanket rule that is no longer true. Newer releases of the popular builders ship server rendering by default, and projects created since then serve real HTML. What never happened is a migration of existing projects. A site generated a while ago and one generated last month can behave completely differently while looking identical in a browser.
So refuse the generic warning and refuse the generic reassurance. Test your specific build:
- Fetch the page with JavaScript disabled. Use curl, or view source rather than the inspector. If your H1, body copy and links are absent there, they are absent for a large class of consumers.
- Run URL Inspection in Search Console and read the rendered HTML, not just the status code.
- Check server logs for GPTBot, ClaudeBot, PerplexityBot and the rest. Most AI crawlers execute little or no JavaScript. If AI search visibility matters to you, HTML-first stops being optional.
Googlebot does render JavaScript, but rendering goes through a queue. Queued is not never. It is slower and less predictable, which on a commercial site carries its own cost.
Metadata that looks fine and isn't
The most common thing we find on an AI-built site is not missing metadata. It is metadata that exists, is wrong, and gives no visible sign of it from the front end.
- The same title and description on every service page, because the generator wrote one template and never varied it.
- A canonical tag hardcoded to the homepage on every URL, which tells search engines that none of your other pages deserve to exist.
- Two live URLs serving the same content, with and without a trailing slash, each canonicalising to itself.
- Open Graph tags pointing at a placeholder, so every LinkedIn share renders a stock gradient.
- A stray noindex or a robots.txt rule left behind by the preview environment. We have watched that one survive for months.
None of these throws an error. The site works. It simply never accumulates anything, and by the time someone checks, you have burned the ramp-up period you were counting on.
Hreflang goes wrong at scale, silently
If you sell into more than one European market, generated code fails hardest here, because the errors multiply with page count. The patterns repeat: return links that only point one way, which invalidates the whole cluster; language codes that are wrong or not real, such as de-DE applied to a page written for Austria, or en-EU, which is not a valid code at all; no x-default anywhere, or an x-default aimed at a URL that redirects or 404s; a translated slug that changed while its hreflang still points at the old path, so the annotation resolves to a dead page.
Someone hand-building a handful of localised pages catches this. A generator producing hundreds does not, and neither does the person reviewing them, because every page looks correct on its own. Treat hreflang as generated data and run a validator across the entire set. Eyeballing markup page by page will not find it.
Forms that submit nowhere, or somewhere you would rather they didn't
This is the failure that costs real money, and it drives our most common emergency call. The success state was styled beautifully. The submission handler was never wired. The visitor reads "Thank you, we'll be in touch" and the message lands in a console log. Nothing bounces and nothing errors. The lead believes they contacted you. You believe nobody did.
The second version is worse. The form does submit, to a third-party endpoint the AI picked, on infrastructure you never signed anything with, sometimes with an API key sitting in plain sight in the client bundle. We open these bundles regularly and find exactly that: an exposed endpoint, no authentication, no role model, data resting somewhere nobody chose. On a marketing site collecting names, phone numbers and business context, that is personal data with no legal basis behind it.
Usually missing too: rate limiting, a honeypot, a confirmation email to the sender, any handoff into your CRM. Submit every form yourself and follow the record all the way to the place a salesperson will actually look.
Consent, storage and the analytics contract nobody wrote
Generated sites ship cookie banners that are decoration. The banner appears after the analytics and marketing scripts have already fired, and "Reject" changes nothing. GDPR does not treat that as a technicality, and German regulators enforce it. Next to it we routinely find a privacy policy carrying placeholder company details, no named controller, no processor list, and no mention of where form submissions live.
Then measurement. "We installed GA4" is not an analytics setup. Nobody defined a conversion, so the form-submit event fires on button click instead of on server confirmation, and your dashboard counts leads that never arrived. Nobody created a thank-you URL, so paid channels have nothing to optimise against. Half a year in you have traffic charts and no way to name the page that produced a customer.
Write the contract before launch. These are the events. This is what each one means. This is who reads them, and how often.
Accessibility, and the maintenance cliff
Generated markup leans on divs with click handlers, inputs without labels, decorative contrast, and no visible focus state. For a European business selling online to consumers, accessibility duties are already in force: the EU Accessibility Act and its national implementations, including the German BFSG, applied from June 2025. Almost nobody connects that legal conversation to the AI-build conversation, but it is the same site. Even where the law does not reach you, keyboard navigation and labelled inputs move conversion. A form nobody can tab through loses submissions from everyone, not only screen reader users.
The maintenance cliff arrives last and hurts longest. No repository history anyone can read. No tests. No staging environment. No person who understands the architecture, because there was never an architecture, only accumulated prompts. Each new AI fix destabilises something next to it, and the fix cycle gets slower instead of faster. German agencies now sell vibe-code cleanup as an openly advertised service line, which tells you how routine the outcome has become.
The question to ask before you commit is not "can AI build this?" It is "who maintains it next year, and can they read it?"
Where AI builds genuinely work, and what to verify before launch
We are not against any of this. AI builders are excellent for prototypes you intend to throw away, for internal tools behind authentication where SEO and consent do not apply, for a single campaign landing page with one properly wired form, and for exploring several layout directions in an afternoon instead of a fortnight. Trouble starts when a disposable artefact becomes the company's main commercial asset without anyone deciding that it should.
Before you point a domain and a budget at an AI-built site, verify all of this:
- Source HTML contains your real content with JavaScript disabled.
- Every page has a unique title, a unique description and a self-referencing canonical.
- No stray noindex. Robots.txt and sitemap match the live URL set.
- Hreflang validated across the whole set, not page by page.
- Every form submitted end to end, with the record traced to where sales will read it.
- No API keys or credentials in the client bundle, and you know which company stores the data and under what agreement.
- The consent gate actually blocks scripts before opt-in, and the privacy policy names your real entity.
- Conversion events fire on confirmed submission, and a thank-you URL exists.
- Keyboard navigation works, inputs have labels, focus states are visible.
- The code sits in a repository someone on your side can access, with a named person responsible for changes.
Clear the whole list and the site was built with AI and it is fine. Clear a third of it and you do not have a website yet. You have a very convincing prototype with your phone number on it.
Frequently asked questions
Vibe coded website problems?
Vibe-coded sites almost never fail on launch day. They fail months later, quietly, in ways nobody on the team is watching for.We build websites for a living, and a growing share of our work is no longer building. It is cleanup. A founder or marketing lead describes a site to an…
How can yoji studio help with this?
We run a free audit and show what applies to your specific case before you pay for anything.
See also
Get a free express audit of your website
We'll check indexing, speed, content and the backlink profile, name the three biggest problems and the order of work. Real findings, no filler, no strings attached — the report is yours to keep either way.
