Vibecoding vs WordPress

Before deciding whether that is a problem for WordPress, it helps to be precise about the term, because it is spreading fast and means different things to different people.

One caveat about the number itself. Different datasets tell different stories. W3Techs shows the drop and the rise of the category with no detectable CMS, but that is a single measurement built on its own detection method. Other sources place the emphasis elsewhere. It does not change the direction, because the direction is confirmed by several independent observations, but anyone waving one figure around as proof is oversimplifying. The exact percentage is not the point here. The phenomenon is: a slice of the market really is moving away from off-the-shelf CMS platforms towards sites generated from a prompt.

#What vibecoding is

Vibecoding is building an application by describing it to a language model and accepting whatever it produces, without reading the code line by line. The tools are Lovable, Bolt.new, v0 by Vercel, Replit Agent and Base44. You type “build a store with login and payments”, and you get a working frontend, a database (usually Supabase) and a deploy in minutes.

For a prototype, an internal tool or a campaign landing page meant to live a week, this is genuinely good. We use it for our own mockups, to show a client a direction before anyone writes production code. The trouble starts only when that output ships as the foundation of a business.

#Vibe coding vs agentic coding, and the 2026 tool wave

There are now two different things people mean by “letting AI write it”, and the distinction matters before you decide what you are looking at. Prompt-to-app tools (Lovable, Bolt.new, v0, Replit Agent, Base44) generate a whole running app from a sentence and hide the code. Agentic coding tools are the wave that broke through in 2026: coding agents that work inside a real repository (Cursor, Claude Code, and the new agentic IDEs Google Antigravity and AWS Kiro), driven by frontier models like Gemini 3, editing files, running tests and opening pull requests the way a developer would.

The agentic tools produce noticeably more maintainable output than the prompt-to-app generation, because they operate on an actual codebase with version control rather than a sealed preview. That is a real improvement, and it is why the search interest around them is climbing. It is also where the misunderstanding creeps in: better code generation is not the same as accountability. An agentic IDE will still ship a Supabase key in the bundle, still leave an admin route unauthenticated, still render a catalogue only on the client if nobody told it not to, because the model optimises for “the feature works when I test it”, not for “this survives real traffic, an audit and the EU accessibility rules”. The tool climbed a rung. The gap between a working demo and a production system that someone is answerable for did not move. Whichever tool built it, the questions in the rest of this article are the same.

#Where vibecoded sites break

This is not a reflex defence of WordPress. It is a list of what actually turns up when someone arrives with “it worked, and now it doesn’t”:

• Keys in the bundle. The model drops a Supabase service_role key into code that ships to the browser. Anyone with dev tools can read it. Through 2025, leaked keys from Lovable-built apps and Supabase databases with Row Level Security switched off exposed entire user tables.
• Unauthenticated endpoints. The prompt “build an admin panel” produces a panel, but the /api/admin route never checks who is calling. It looks fine because the author tests it while logged in.
• No validation or limits. A contact form with no rate limiting and no sanitisation becomes an open door for spam and injection attempts.
• Invisible to search. Content rendered only on the client, with no server-side rendering, is an empty page to Googlebot. A product catalogue that does not exist in the HTML will not be indexed.
• No maintenance path. No database migrations, no backups, no versioning, no pipeline. The first real change means a rewrite, because nobody, including the person who wrote the prompt, knows why it was built the way it was.
• Email deliverability left to chance. The generated form sends mail through a free provider with no SPF, DKIM or DMARC. Order confirmations land in spam, and the owner hears about it from customers rather than from a dashboard.
• Accessibility ignored. Contrast, focus states, keyboard operation, field labels. The model produces a pretty screen, not an accessible interface. In the EU, under the European Accessibility Act, that is not cosmetic, it is a legal risk.
• Platform lock-in. The code is welded to one preview host and one database. Leaving that ecosystem, once the bills start rising with traffic, means a migration nobody planned for.

Two concrete cases from recent months. A UK startup built a client dashboard in Bolt.new and shipped in a week. Two weeks later, users could see and edit data from other accounts, because the Supabase anon key sat in the code and Row Level Security was never enabled. The fix was not a redesign, it was a policy layer nobody had written, plus a forced key rotation and an awkward email to every affected customer about who could have seen what. A US retailer stood up a store in v0. It was fast and clean, and after three months it had zero traffic from Google, because the whole catalogue rendered only in the browser. The owner had been paying for ads the whole time, reading the paid traffic as proof the site worked, while the organic channel simply did not exist. Both sites looked flawless on launch day. That is the vibecoding trap: the demo is perfect, and the bill arrives later.

#Invisible to Google, and to AI too

There is an irony here. Vibecoding is a product of the AI era, and the sites it produces are often invisible to AI itself. If content appears only after a script runs in the browser, neither Googlebot nor the answer engines behind AI Overviews and similar features can see it. A model that summarises the web reads HTML, it does not render an application. If the catalogue is not in the HTML, it is not in the answer.

That is a double loss. The site sheds traffic from classic results and drops out of the new channel where the buying journey increasingly begins. Visibility in generative features can be measured, which is a subject in its own right, but first the content has to exist in code a machine can read. A site built entirely on the client never clears that bar. You can watch this happen in a crawler: fetch the page as Googlebot renders it and the product grid is there, fetch the raw response the way most answer engines do and it is a shell. The gap between those two views is exactly the traffic the site is quietly losing.

#Why generated code is hard to maintain

The problem does not stop at individual holes. It is about structure. The model optimises for making the screen work now, not for someone extending the code six months later. In practice that means a handful of repeatable patterns: the same logic copied across five places instead of factored out once, no separation into layers, no tests to warn that a change broke something, and dependencies chosen by fashion rather than stability.

Each of those on its own is bearable. Together they produce code where a small change can break something distant, and nobody knows until a customer calls. Maintaining a site is not bolting on features. It is the confidence that bolting on a feature will not topple something else. Generated code does not give you that confidence, because nobody designed it with change in mind.

#How to spot a vibecoded site

You do not need access to the code. A few signals are enough:

• View source (Ctrl+U) shows a nearly empty <body> and one large JavaScript file. Content appears only after the script loads.
• Disabling JavaScript leaves a blank page instead of text.
• In Google, the site has no pages beyond the homepage, even though the browser shows many.
• No login page on the site’s own domain, or an admin panel that leans entirely on an external service with no permissions configured.
• Response headers point at preview hosting (Vercel, Netlify) with no application layer of its own.

None of these on its own is a verdict. Together they describe a site that came out of a prompt and never got a foundation.

#Vibecoding vs WordPress in production

The table does not say vibecoding is bad. It says what each tool fits. For testing an idea over a weekend, vibecoding wins outright. For a site meant to earn revenue a year from now, the foundation wins.

#What an audit of an AI-built site actually checks

When a site like this reaches us, we do not start by rewriting. We start with a diagnosis, because “it worked, and now it doesn’t” usually has several layers. The order is nearly always the same:

1. Security first. Are there keys in the code that ships to the browser that should never be there. Does the database have access rules switched on. Do the endpoints check authorisation. This decides whether the site can even be left online safely while it is repaired.
2. Rendering and indexing. Is the content in the HTML or only in JavaScript. How many pages does Google actually see. Are redirects, canonicals and the sitemap in place. This answers why the organic traffic is not arriving.
3. Data and continuity. Where the data lives, whether there are backups, whether it can be exported. Without this, every further decision is a gamble.
4. The decision: rescue or rewrite. Only now. Sometimes it is enough to add the layer that was missing. Sometimes it is cheaper and safer to move the content onto a foundation that can be maintained. The audit says which of those roads is cheaper over a year, not just this week.

The key point is that this is not a job for another prompt. A prompt will not read someone else’s code with an understanding of responsibility for the consequences. It will happily generate a fresh version that looks like a fix and quietly reintroduces the same missing checks. An engineer will read what is there first, and only then decide what to change.

#Why this is not the end of WordPress

The share is falling because the bottom of the market, the simple sites once built on WordPress by default, is genuinely moving to AI. And that is fine. It was the least profitable, most disposable part of the market. WordPress is losing the work nobody made money on anyway.

What remains is the rest: WooCommerce stores with real revenue, multilingual sites with correct hreflang, GDPR-bound projects, work meant to run for five years and survive a dozen updates. Vibecoding does not reach there, because there the job is not to generate a screen. It is a foundation: security, performance you can measure in Core Web Vitals, maintenance, and ownership of what happens at two in the morning during a Black Friday peak.

WordPress does not win because it is fashionable. It wins because it has two decades of ecosystem, a predictable maintenance path, and a person who knows why something was built the way it was.

#When WordPress is not the answer either

To be fair, not every project is a WordPress project. If you are building a real-time application, a product that is entirely an API, a panel with heavy client-side logic, or something that is by nature an app rather than a content site, other tools will serve you better. WordPress runs content, a store, integrations and search visibility superbly. It is not a universal hammer, and treating it like one ends as badly as dropping a store onto a vibecoded prototype.

The difference is that choosing between WordPress, a bespoke application or something else again is an architectural decision that someone makes deliberately, knowing the consequences. Vibecoding does not make that decision. It generates whatever statistically fits the prompt and leaves the consequences for later.

#Who is accountable when it breaks

That question usually gets asked too late, because it only gets asked once something has already gone wrong. A prompt has no on-call rota. The model will not call back when the store stops taking payments on a Saturday evening. A generated site has no technical owner who knows its history and where to look.

A foundation is not only code. It is someone who takes responsibility for the outcome. In an era where more and more can be generated, accountability is exactly what becomes the scarce good. The point is not to avoid AI. We use it every day, for scaffolding, for first drafts, for the boring parts. The point is to keep a human between the generated screen and the running business, someone who understands the difference and answers for what ships to production. When a payment webhook fails silently at midnight, the difference between a prompt and a person is the difference between a lost weekend of revenue and a five-minute fix by someone who already knows where the log lives.

#When vibecoding fits, and when to call a senior

Simply put: for a prototype, an MVP, an internal tool or a campaign landing page, vibecode away. Fast, cheap, good enough. For a store, a business site, or anything that has to earn and still exist a year from now, you need a foundation, not a generated screen.

Then there is the question of cost, the one that comes up most often: if AI built it in a day, the fix should be cheap. Not always. The effort depends on how deep the problems go. If all that is missing is a security layer and correct rendering, and the content and data can be moved, the work is bounded and predictable. If there is no foundation at all, and the site has already gathered customers, data and rankings in Google, then migrating while preserving all of that is a bigger project than building anew on clean ground. That is why an audit begins with a diagnosis, and the quote is always individual: only after we see what can be rescued can we say honestly which road is cheaper over the course of a year.

If you already have an AI-built site and something is starting to break, from leaks to lost traffic to “we can’t extend it”, it is usually fixable, but not with another prompt. We rescue AI-built websites: a security audit, SEO from the ground up, and a call on what to rewrite and what to keep. The work is done by a developer who reads the code nobody read before.