In early 2025 WordPress powered 43.6 percent of the web. Today it is 41.5 percent, and the decline is speeding up. The interesting question is not the number, it is where the share is going. Not to Wix or Shopify, which are flat. It is going to sites where W3Techs detects no CMS at all. Pantheon co-founder Josh Koenig put it in three words: “it’s vibecoding”.
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.
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.
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_rolekey 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/adminroute 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.
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. 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. Both sites looked flawless on launch day. That is the vibecoding trap: the demo is perfect, and the bill arrives later.
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
| Criterion | Vibecoded site | WordPress run by a senior |
|---|---|---|
| Time to first demo | Minutes | Days |
| Rendering for SEO | Usually client-side | Server-side HTML |
| Access control | None by default, must be added | Roles and capabilities in core |
| Maintenance path | No migrations or backups | Updates, backups, pipeline |
| Growth after a year | Often a rewrite | Iteration on existing code |
| Ownership of failures | Diffuse | One engineer who knows the code |
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.
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 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.
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.
