WordPress still runs the web, but AI builders and headless CMSs are rewriting the rules

Every business that needs a website now faces a choice that did not exist in this form three years ago. You can build on WordPress, the platform that still powers a larger share of the internet than any competitor. You can commission a custom build on a headless content management system paired with a modern frontend framework. Or you can describe what you want to an AI tool and watch it produce a working site in minutes. The three paths deliver something that looks, from the outside, like the same object: a website. What they actually hand you differs in cost, control, security, search visibility, and how the thing behaves a year after launch.

The real question behind choosing a website platform in 2026

The decision carries more weight in 2026 because the ground has shifted under all three options at once. WordPress shipped version 7.0 in May 2026, its largest structural release since the block editor arrived in 2018, adding a provider-agnostic AI layer and a rebuilt admin interface. The headless CMS market, valued at roughly $3.94 billion this year, sits on a trajectory that analysts project will pass $22 billion by 2034. And AI website generation went from a curiosity to a funded category, with one tool reaching a $6.6 billion valuation inside eighteen months. Each of those movements pulls the decision in a different direction, and none of them existed in their current shape when most current websites were first planned.

This is not a contest to crown one platform best in the abstract. A local dentist, a fast-growing software company, a national news publisher, and a freelance photographer share almost nothing in what they need from a website, and the right answer for one is routinely the wrong answer for another. The useful form of the question is narrower and more honest. Given what you are building, who will maintain it after launch, what you can realistically spend across two years rather than two months, and how you expect people to find you, which approach carries trade-offs you can live with?

That last clause does most of the work. There is no option without trade-offs. WordPress gives you an enormous ecosystem and a maintenance burden that never ends. A custom headless build gives you control and performance at the cost of money and engineering time most small organizations do not have. An AI builder gives you speed that feels like magic and a set of hidden constraints around ownership, security, and search that often surface only after the project is live and the credit card has been charged for a year.

The stakes around being found have grown sharper too. Search no longer means a list of ten blue links for a growing share of queries. AI Overviews now appear in roughly a quarter of Google searches, answer engines like Perplexity and ChatGPT route real traffic to the sites they cite, and the technical decisions baked into how a website renders now determine whether an AI system can read it at all. A site that a crawler cannot parse is invisible in both the old search world and the new one. Platform choice and discoverability are no longer separate conversations, which is exactly why a marketing and SEO lens belongs at the center of this comparison rather than bolted on at the end.

The aim here is to lay out how each approach works, what it costs in money and effort, where it breaks, and which kinds of projects it actually suits, with the numbers and developments that define each option in 2026. The conclusion is not a single winner. It is a way of reasoning about the choice that survives contact with a real project.

Three philosophies of building a website, defined precisely

The three options are usually described by the tools they use, which obscures what really separates them. The cleaner way to see it is as three philosophies about where control and effort should sit.

WordPress is a self-hosted, monolithic content management system. You install it on a web server, content and presentation live in the same system, and a vast catalog of themes and plugins extends what it can do without writing code. The same software renders the page a visitor sees and stores the content an editor writes. WordPress began in 2003 as a blogging tool built by Matt Mullenweg and Mike Little, and it grew into a general-purpose platform that now sits behind a huge portion of the web. Its defining trait is the ecosystem: tens of thousands of plugins and themes mean that for almost any feature a site might need, someone has already built a way to add it. Its defining cost is that all of that lives on infrastructure you are responsible for keeping updated, secure, and fast.

A custom CMS in 2026 almost always means a headless architecture. Here the content management layer is separated, or decoupled, from the presentation layer. A headless CMS stores structured content and exposes it through an API, and a separate frontend, typically built with a JavaScript framework like Next.js, fetches that content and renders the pages. The word headless refers exactly to this separation: the body that manages content has no fixed head that displays it, so any number of frontends, a website, a mobile app, a kiosk, a smart display, can consume the same content. This is the path serious engineering teams take when they want full control over performance, design, and how content flows across channels. It is also the path that demands the most money and technical skill, because nothing is assembled for you out of the box.

An AI-generated website is one a model builds from a natural-language description. You write a prompt, the AI produces a site, and you refine it through further instructions or a visual editor. This category is younger than the other two and far less uniform, which is the source of most confusion about it. Some AI builders generate a site that lives permanently on the vendor’s platform and can never leave it. Others generate real code you can export and host anywhere. Some are aimed at a non-technical owner who wants a presence online by tonight. Others are aimed at developers who want to skip the tedious first hours of a build. Treating them as one thing leads people to the wrong tool.

The reason these three deserve to be compared rather than ranked is that they answer different questions. WordPress answers, “how do I get a flexible, ownable site without building everything from scratch?” A headless build answers, “how do I get exactly the site I want, at the performance and scale I need, and reuse the content everywhere?” An AI builder answers, “how do I get something live as fast as humanly possible?” Those are legitimate questions, and a business usually has a clear sense of which one it is actually asking once the options are framed this way.

One more distinction matters before going further, because it cuts across all three. The phrase content management system describes software that lets non-developers create and edit content without touching code. WordPress is a CMS. Strapi, Sanity, Contentful, and Payload are headless CMSs. Many AI builders are not a CMS at all in any meaningful sense, because the content they generate is baked into the output rather than managed through a structured editing interface. That single difference, whether a system gives you ongoing structured control of your content or simply produces a static artifact, turns out to predict more about long-term experience than any feature list.

WordPress’s real position after twenty-three years

WordPress turned twenty-three in 2026, and the headline number remains staggering. Depending on the measurement method, WordPress powers somewhere between roughly 42 and 43 percent of all websites, and holds close to 60 percent of the market among sites that use a recognized CMS. The two figures come apart because they count different things. W3Techs, the most cited source, surveys the top ten million sites and treats subdomains of a site as a single entry, producing the familiar ~43 percent all-sites figure and a CMS share near 60 percent. HTTP Archive, which counts origins separately from a roughly 8.9 million-site sample with enough real traffic to measure, puts WordPress closer to 33 percent of the measurable web. Both are correct. They answer different questions, and the gap between them is a useful reminder to read any market-share claim alongside its method.

What changed in 2026 is direction. For the first time in more than a decade, WordPress’s share among CMS-using sites contracted year over year, slipping from a peak near 65 percent in 2023 toward about 60 percent. The all-sites figure dipped slightly too, the first meaningful decline after years hovering between 42.5 and 43.5 percent. The 2025 Web Almanac framed this as WordPress moving from a phase of expansion to one of stabilization, which reads as market saturation rather than collapse. The platform is not shrinking in any dramatic sense. It is no longer growing, and underneath the flat headline a more pointed shift is taking place.

That shift shows up most clearly in new sites. Among brand-new CMS deployments in 2026, WordPress accounts for under half, roughly 43 percent, down from about 51 percent two years earlier. The installed base keeps WordPress dominant because switching costs are enormous, but the cohort of sites being built right now is breaking toward alternatives faster than the total number suggests. Developer mindshare is leaving even quicker than market share, with newer projects gravitating toward React-based frameworks, headless CMSs, and AI builders. WordPress is simultaneously the most-used platform on the web and a declining first choice for people starting fresh, and holding both facts at once is the only way to read the data honestly.

The competitive picture around it has also filled in. Shopify sits a distant second among CMS platforms at roughly 5 to 7 percent, Wix near 4 to 6 percent, and Squarespace around 2.5 percent. Joomla and Drupal, the two platforms historically closest to WordPress in concept, roughly halved their share over the past decade. Drupal retains real strength among large institutional sites, holding a notably higher share among the top ten thousand sites by traffic than its total number would imply. The dramatic growth stories are elsewhere: hosted builders climbing from near zero, and the entirely new AI-generation category that did not register in these counts a few years ago.

WordPress’s strengths are concrete and worth stating plainly. It is free and open source, which eliminates licensing fees and the kind of vendor lock-in that proprietary platforms impose. Its plugin and theme ecosystem, with more than 60,000 free plugins and tens of thousands of themes, means most functionality already exists. WooCommerce, the WordPress ecommerce plugin, sits behind roughly a third of all online stores and processed an estimated $35 billion in gross merchandise volume in 2025, making it the largest open-source ecommerce platform by transaction volume. The talent pool is deep, hosting is cheap and abundant, and the platform scales from a personal blog to enterprise publishers like major newspapers and magazines.

The weaknesses are equally concrete. The average WordPress page loads in about 3.4 seconds, well above the 2.5-second threshold Google associates with healthy Core Web Vitals, and only around a third of WordPress mobile sites pass those metrics. Security is the platform’s most cited liability, with the overwhelming majority of vulnerabilities originating not in core software but in third-party plugins and themes. And the developer experience, built around PHP and a plugin model, increasingly diverges from the TypeScript and React tooling that newer engineers expect. None of these is fatal. All of them are real, and they are precisely the openings that headless builds and AI tools are exploiting.

Custom builds today usually mean going headless

When someone says they want a custom CMS in 2026, they rarely mean building a content management system from nothing. That was common fifteen years ago and is now almost always a mistake, because mature, well-engineered systems exist that solve the hard parts. What custom usually means today is a bespoke website built on a headless CMS, with a frontend designed and coded specifically for the project. The custom part is the experience and the architecture; the content engine is a proven product underneath.

The defining move of a headless setup is decoupling. In a traditional system like WordPress, the same software both stores content and renders the HTML a browser displays. A headless CMS does only the first job. It stores content as structured data, fields with defined types rather than a single blob of formatted text, and serves that data through an API, usually REST or GraphQL. A separate application, the frontend, requests the content and turns it into pages. Because the content layer has no opinion about presentation, the same content can feed a website, a native mobile app, an in-store display, or a partner’s system, all drawing from one source. This is why the model appeals to organizations publishing across many channels rather than a single website.

Structured content is the quiet advantage people underrate. In WordPress, an article is largely a body of formatted text with some metadata around it. In a headless CMS, you define exactly what an article is: a headline field, a subhead, an author reference, a hero image with required alt text, a set of tagged sections, a publish date. That structure makes content reusable, queryable, and far easier for both other systems and AI engines to consume cleanly. It also imposes discipline up front, because someone has to model the content before anyone can create it, and that modeling work is real.

The frontend in a headless build is typically a JavaScript framework, with Next.js the dominant choice, often deployed on a platform like Vercel or Netlify. The framework fetches content from the CMS and can render pages in several ways: fully static at build time, server-rendered on request, or a hybrid that regenerates pages incrementally as content changes. Done well, this produces extremely fast sites, because much of the page can be prebuilt and served from a content delivery network close to the user. The same approach that lets Next.js sites average around 0.8 seconds of load time, against WordPress’s 3.4, is the core performance argument for going headless.

The catch is that none of this assembles itself. A headless build requires developers to design the content model, build the frontend, wire up the API calls, implement everything WordPress gives you for free, search, forms, sitemaps, structured data, redirects, and host and maintain the pieces. There is no plugin to install for a feature; there is code to write. For a marketing site that a small business updates occasionally, this is overkill and expensive. For a content-heavy platform, a product with a complex frontend, or an organization that needs content in many places, it is often the only approach that holds up.

The headless world has stratified into recognizable products. Strapi and Payload lead the open-source, developer-first camp, where the CMS is treated as an extensible application framework you run and own. Contentful, Sanity, and Storyblok anchor the managed, enterprise-oriented camp, hosted platforms that handle infrastructure and increasingly market themselves as content operations hubs rather than mere CMSs. Directus occupies a useful niche, wrapping an existing SQL database in an API and admin panel. Each makes a different bet about who the customer is, how much they want to self-host, and whether they value control or convenience more. The choice within headless is nearly as consequential as the choice to go headless at all, and later sections return to it in detail.

The AI website category split nobody explains clearly

The single biggest source of confusion about AI websites is that the category contains two fundamentally different kinds of tool, and most coverage blurs them. Getting this distinction right is the difference between choosing a tool that fits and wasting weeks on one that does not.

The first kind is the AI-augmented no-code builder. These are hosted website platforms, often ones that existed before the AI wave, that added a generation step on top of a drag-and-drop editor. You answer a few questions or write a short brief, the AI assembles a starting site with copy, layout, and images, and you refine it visually. Wix, with its AI Site Generator and the newer Aria assistant inside Wix Harmony, Squarespace, Framer, Hostinger’s AI builder, and Durable all live here. The output is a hosted site on that vendor’s platform. It is fast, it requires no technical skill, and the result is fine for a basic presence. The trade-off is that you generally cannot export the site and leave; you can stop paying, but then you start over somewhere else.

The second kind is the AI-native code generator, the tools the industry started calling vibe coding after Andrej Karpathy coined the term in February 2025. Lovable, Bolt.new, v0 by Vercel, Base44, and Replit belong here. You describe an application in plain language and the model writes real code, typically React with Tailwind CSS and often a Supabase backend for data and authentication. These tools aim beyond marketing sites toward full applications with databases, logins, and interactive features. Some let you export the code and own it; some technically export but produce code that does not run cleanly elsewhere. The ceiling is far higher than no-code builders, and so is the floor of knowledge required to use them safely.

Karpathy’s term caught on fast. Collins English Dictionary named “vibe coding” its Word of the Year for 2025, and Gartner has forecast that 60 percent of all new code will be AI-generated by the end of 2026. The speed is genuine. Lovable went from launch to $200 million in annual recurring revenue inside twelve months, described as the fastest growth in European startup history, and reached an eight-million-user base. The category is not hype in the sense of being empty; the tools work, and people are shipping with them at scale. The hype lies in the gap between “it produced a working site” and “it produced a site you should put a business on,” which is wider than the demos suggest.

A third, smaller group sits between the two camps and deserves mention. 10Web generates an actual WordPress site with the AI bolted to the front, running on managed WordPress hosting, so the output ranks and behaves like WordPress and can be edited in familiar tools. Webflow added AI features to a platform that already produced clean, exportable code. Orchids and several newer entrants compete directly with Lovable on design quality. These hybrids matter because they show the lines blurring: traditional builders are adding AI, AI tools are adding the polish and SEO awareness that production sites need, and the neat two-camp split is already starting to soften at the edges.

The practical consequence of the split is straightforward. If you are a non-technical owner who needs a presence site and never wants to touch infrastructure, a no-code AI builder is the honest fit. If you are building a product with real application logic, an AI-native code generator can compress weeks of early work, provided someone competent reviews what it produces. If you confuse the two, you end up either fighting an app builder to make a simple brochure site or trusting a no-code platform with logic it was never meant to handle. Most of the disappointment people report with AI websites traces back to picking from the wrong camp.

WordPress under the hood, themes, plugins, and the block editor

Understanding why WordPress behaves the way it does, fast to start and heavy to maintain, requires a look at its architecture. The platform runs on the classic LAMP-style stack: a server running PHP, with content stored in a MySQL or MariaDB database. When a visitor requests a page, WordPress queries the database, runs the active theme and any relevant plugins, assembles the HTML on the server, and sends it back. This server-side assembly on every request, unless caching intervenes, is one root of WordPress’s performance reputation, because each page view can trigger database queries and plugin code.

Themes control how a WordPress site looks. A theme is a set of templates and styles that determine layout, typography, and structure. For most of WordPress’s history, themes were PHP templates customized by developers or selected from thousands of ready-made options. The modern direction is full site editing with block themes, where the entire site, headers, footers, templates, is composed from blocks in a visual editor rather than edited in code. This is the architecture behind contemporary WordPress design systems and the default themes shipping with recent releases.

Plugins are where WordPress’s power and its risk both concentrate. A plugin is a package of code that adds functionality, anything from a contact form to a full ecommerce store to a security firewall. The directory holds more than 60,000 free plugins, and the commercial market adds thousands more. This is the practical reason WordPress can do almost anything without custom development: the feature you need usually exists as a plugin. It is also why the overwhelming majority of WordPress security vulnerabilities originate in plugins and themes rather than core, and why each plugin added tends to cost roughly half a second of load time per ten installed. Every plugin is third-party code running on your site, with whatever quality and maintenance discipline its author brings.

The block editor, code-named Gutenberg, reshaped content creation in WordPress starting in 2018. It replaced a single text field with a system where each piece of content, a paragraph, an image, a gallery, a button, is a block that can be arranged and configured visually. Gutenberg has rolled out in phases: first the editor itself, then full site editing, and now Phase 3, collaboration and editorial workflow, which is the centerpiece of the 2026 release. The block model brought WordPress closer to the visual, modular experience people expect from modern tools, though it was contentious among users comfortable with the older classic editor.

This architecture explains the platform’s fundamental bargain. The monolithic, plugin-driven design is exactly what makes WordPress approachable: install it, pick a theme, add plugins, and you have a capable site without writing code or hiring engineers. The same design is what makes it heavy: every site carries an active surface of third-party code that must be updated, secured, and kept compatible, and the server-side rendering model needs caching and good hosting to feel fast. Managed WordPress hosting can make a site roughly 2.4 times faster than budget shared hosting, which is a real lever, but it is a lever you have to know exists and pay for. The freedom and the burden are two faces of one design, and you cannot take one without the other.

The architecture of a headless build, from data to render

A headless website is a small system of cooperating parts, and seeing how they fit together explains both its performance and its cost. At the center sits the headless CMS, holding structured content. Around it are the API that exposes that content, the frontend framework that consumes it, the hosting and delivery layer that serves pages to users, and the supporting services, search, forms, analytics, that a real site needs and that the CMS does not provide.

Content modeling comes first and shapes everything after. Before anyone writes a word, a developer defines the content types: what fields an article has, how a product relates to its categories, which references connect to which. Sanity uses a schema written as code and its own query language, GROQ, a purpose-built language for filtering and reshaping JSON documents that is more flexible than GraphQL but carries a learning curve. Payload generates full TypeScript types from your schema automatically, so the content shapes flow into the codebase without manual typing. Strapi builds an admin panel from your model and exposes both REST and GraphQL. The modeling decisions made here ripple through the whole project, which is why headless builds reward planning and punish improvisation.

The frontend is where the visible site lives. A framework like Next.js fetches content from the CMS at one of several moments. With static generation, pages are built once at deploy time and served as plain files, which is the fastest option and ideal for content that changes infrequently. With server-side rendering, pages are assembled on each request, which suits highly dynamic or personalized content. With incremental static regeneration, the system serves static pages but quietly rebuilds them in the background as content updates, blending speed with freshness. Choosing among these per page type is a core part of the craft, and getting it right is what separates a headless site that loads instantly from one that does not.

Delivery is the layer people forget until it matters. Static and incrementally regenerated pages are served from a content delivery network, a global set of edge servers that hold copies of the site close to users. A visitor in Bratislava and one in São Paulo both get a fast response because the page is served from a nearby edge rather than a single origin server. This edge delivery, combined with prebuilt pages, is what lets the strongest headless stacks score a perfect 100 on Lighthouse performance out of the box. It is also a meaningful operational difference from WordPress, where the origin server does more work on each request and caching has to be configured deliberately.

What the CMS does not give you is the long tail of features WordPress bundles. There is no built-in contact form, so you integrate a form service or build one. There is no native search, so you add a search provider. Sitemaps, redirects, structured data, image optimization, and SEO controls are not plugins to toggle; they are code to write or services to wire in. This is the hidden bulk of a headless project. The CMS and framework are the visible parts, but a large share of the work is reconstructing, deliberately and to a higher standard, the conveniences that a monolithic platform hands over for free.

The result, when the work is done well, is a site that is fast, secure by virtue of having a small server-side surface, fully controlled in design and behavior, and able to feed content to any channel. The cost is engineering time and ongoing ownership. A headless build is a software project, not a website you configure, and it should be staffed and budgeted as one. For the right project, the payoff is a site that does exactly what it should and outperforms anything assembled from a template. For the wrong project, it is an expensive way to get a brochure that a much simpler tool would have produced in an afternoon.

Typing a prompt into an AI builder, step by step

The experience of an AI builder feels like conversation: you describe a site, it appears, you ask for changes, they happen. Underneath, the two camps work very differently, and the mechanics determine what you can trust the output to do.

A no-code AI builder takes your brief and assembles a site from its own components, templates, and content blocks, often generating placeholder copy and selecting stock or AI-made images to fit. The AI is choosing and arranging pieces within the platform’s system rather than writing arbitrary code. The output is a configuration of that platform’s building blocks, which is why the site cannot leave: it only exists as an arrangement inside that vendor’s renderer. This is also why no-code AI output tends to be visually safe and structurally similar across sites; the model is working within a fixed palette of known-good parts.

An AI-native code generator does something more ambitious and more fragile. It writes actual source code in response to your prompt, generating React components, styling, routing, and, when the app needs data, a backend schema and the calls to read and write it. Many of these tools default to a Supabase backend, which automatically exposes a REST API from the database, and to a frontend that talks to that backend using an API key embedded in the client-side code. The model reasons about your request, produces files, and runs them in a sandbox so you see a live result. When it works, the gap between an idea and a functioning application collapses from weeks to minutes, which is the genuine breakthrough these tools represent.

The fragility lives in what the model does not reliably do. Generating code that runs is not the same as generating code that is correct, secure, or maintainable. Studies across the category find that between 40 and 62 percent of AI-generated code contains security vulnerabilities, and one analysis of GitHub pull requests put AI-written code’s flaw rate at about 2.74 times that of human-written code. A model will happily produce a database layer without the access-control rules that should protect it, because the prompt asked for features, not for security, and the model does not independently insist on the parts a careful engineer would never skip. The output looks complete and runs in the demo, which is exactly what makes the missing pieces dangerous.

Search visibility is the other place the mechanics bite. Most AI builders, both camps, produce single-page applications that render their content with client-side JavaScript. The initial HTML is nearly empty, and the actual content appears only after the browser runs the JavaScript. Search crawlers and AI answer engines that read the initial HTML can find little or nothing, which means a site that looks perfect to a human visitor can be effectively invisible to Google and to the AI systems increasingly mediating discovery. The exceptions, 10Web because it produces WordPress, Webflow because it emits clean HTML, and Lovable after it added SEO support in a recent release, prove the rule by being the tools that deliberately avoid the default trap.

Knowing the mechanics turns the marketing claims into a checklist. Does the tool produce content in the initial HTML or only after JavaScript runs? Does it configure backend security or leave that to you? Can you export and own the code, or are you renting an arrangement on the vendor’s platform? Who is responsible when something the model generated turns out to be wrong? None of these questions appears in a thirty-second demo, and all of them determine whether an AI-built site is a real foundation or a convincing prototype that should never have gone to production.

WordPress 7.0 and the platform’s bet on AI

The release WordPress shipped on May 20, 2026, code-named Armstrong, is the most consequential in nearly a decade, and it is best read as the platform’s answer to exactly the pressures described above. WordPress 7.0 marks the start of Gutenberg Phase 3, the collaboration and workflow phase, and it ships a provider-agnostic AI layer, a rebuilt admin interface, and a set of editorial tools aimed at the gaps that have been pushing teams toward external products. It is not a routine point release; it changes daily workflows for anyone working in WordPress.

The most strategically important addition is the AI infrastructure. WordPress 7.0 introduces the WP AI Client SDK and a Connectors API, built on top of the Abilities API that landed in version 6.9, together giving the platform a standardized way to connect to external AI providers including OpenAI, Google Gemini, and Anthropic’s Claude. Before this, every AI-powered plugin handled its own provider connection and API keys, producing a tangle of duplicate setups. Now there is a shared layer, configured through a Settings menu, that plugins can build against. The official provider plugins install separately, and the design intent is clear: give the plugin ecosystem a stable target so that better AI tooling proliferates across WordPress rather than being locked inside individual products.

The admin interface received its first real visual overhaul since 2013. The centerpiece is DataViews, a React-based interface that replaces the old server-rendered list tables for posts, pages, and users. Where the legacy tables required a full page reload to sort or filter, DataViews loads instantly on the client, supports grid and list layouts, and handles bulk editing without leaving the screen. For anyone managing many posts or users, this is a practical, daily improvement, and it signals WordPress modernizing the parts of itself that engineers found most dated.

The headline collaboration feature did not survive the cycle. Real-time collaborative editing, the Google-Docs-style multi-user editing meant to anchor Phase 3, was pulled from the release on May 8, 2026, after race conditions, fuzz-testing failures, and memory concerns under concurrent load made it unsafe to ship at scale. Its earliest realistic return is version 7.3 in 2027. In its place, block-level Notes shipped, giving editorial teams threaded comments tied to specific blocks, @mentions to loop in colleagues, and a suggestions mode that proposes changes while preserving the original text until an author accepts them. That asynchronous model resolves most of the coordination friction teams actually face without the heavy real-time infrastructure, and the decision to delay rather than ship something unstable reads as discipline rather than failure.

The release also reflects a hard year for the project. The 2024 legal dispute between Automattic and WP Engine disrupted the contributor pipeline so severely that Automattic’s weekly contributions to WordPress.org reportedly dropped from roughly 3,988 hours to just 45. Because Automattic employs a large share of core contributors, that gap compressed the 2025 schedule from three major releases to two, pushing the 7.0 milestone into 2026. The platform has since returned to a three-release cadence, with 7.1 expected around August 2026 focusing on media workflows and permissions, and 7.2 expected in December laying groundwork for native multilingual support, a long-awaited Phase 4 feature.

Beyond core, WordPress.com has been building AI directly into the editing experience. Telex, an AI tool that generates blocks and even themes from a prompt, launched in 2025 and now accepts reference images alongside instructions and lets you download a generated block, edit it in a code editor, and bring it back. A built-in assistant in the block editor accepts plain-language requests to adjust layouts, swap palettes, or rewrite copy, with changes rendering in real time. WordPress Studio, the local development environment, connects to AI tools through the Model Context Protocol, so an agent can build and test themes and plugins. MCP support across the platform means WordPress is not merely compatible with AI agents but is being designed for them, which matters as agentic systems start acting on the web rather than just answering questions about it. The strategic read is that WordPress is betting its enormous installed base and ecosystem can absorb the AI wave from within, turning a competitive threat into a platform feature, and 7.0 is the foundation of that bet.

The headless CMS market and its two warring camps

The headless CMS world looks like a single category from outside and resolves, on closer inspection, into two camps at war over what a CMS should even be. The split is not about features so much as philosophy, and understanding it is the key to choosing well inside the headless option.

The first camp is developer-first frameworks, led by Payload and Strapi. These present themselves less as content tools and more as extensible application frameworks that happen to include a powerful CMS. Their pitch is developer experience, architectural control, and the absence of vendor lock-in. Strapi is the most popular open-source headless CMS, built on a deliberate SQL-only architecture with battle-tested REST and GraphQL APIs, free when self-hosted and available as Strapi Cloud from around $29 a month. Its plugin marketplace is its edge over newer rivals: need SEO analysis, email integration, or a custom field type, and a plugin likely exists. Strapi has added Strapi AI, which generates content types and schemas from a text prompt, an existing frontend, or even a Figma file or screenshot.

Payload is the fastest-growing choice among TypeScript-native teams. It is MIT-licensed, runs inside a Next.js application, and generates full TypeScript types from your schema so no untyped data leaks through the codebase. Payload 3 moved the CMS inside the Next.js app entirely, and the project has since gone framework-agnostic, supporting Remix, Astro, and SvelteKit, though the experience is still strongest with Next.js. Recent versions added a Lexical-based rich text editor, live preview with React Server Components, and built-in evaluation support for AI code generation. Microsoft, ASICS, and Blue Origin use it, which provides real validation, and its MIT license means there is no ceiling imposed by the platform and no awkward conversations about commercial use at scale. The cost is upfront investment: Payload gives you a foundation, not a finished product, so developer time precedes a usable result, and the community and documentation are younger than Strapi’s.

The second camp is enterprise-grade orchestrators, anchored by Contentful, Sanity, and Storyblok, which have steered their marketing away from the commoditized word “headless” toward terms like composable digital experience platform and content operating system. Contentful is the established enterprise option, fully managed with a global CDN and deep governance, but it removed its free community tier in 2025 and now starts around $300 a month, which ended its run as the default recommendation for new developer projects and pushed many small evaluations toward Sanity and Payload. Its AI Actions target enterprise workflows like bulk localization and brand-compliance enforcement.

Sanity has become the developer-experience pick within the managed camp, built around structured content, the GROQ query language, and a fully customizable Studio that is itself an open-source React application. Its Content Operations Agent understands your schema and automates complex workflows, and its Canvas tool offers free-form AI-assisted drafting. Sanity’s Growth plan starts around $199 a month or $15 per seat, and it tops independent G2 rankings for its flexibility and its positioning as a foundation for AI-driven content operations. Storyblok holds a distinct moat in visual editing, with a live preview that lets non-technical authors drag, drop, and see changes render, a workflow no other platform in the comparison matches without considerable custom work, and it posts notably low content-delivery latency.

The market context underneath these products is growth. Analysts project the headless CMS market expanding from roughly $3.94 billion in 2026 to about $22.28 billion by 2034, a compound annual growth rate above 21 percent. The forces driving it are exactly the ones squeezing WordPress: demand for content across web, mobile, and AI channels, performance expectations that monolithic stacks struggle to meet, and developer preference for modern tooling. The two camps will keep converging on AI features, but the underlying choice, control and ownership versus managed convenience and governance, is durable, and it is the first decision to make once you have decided to go headless at all.

Figma, Payload, and the convergence of design and content

One acquisition in mid-2025 captured where the serious end of website building is heading. On June 17, 2025, Figma announced that the team behind Payload, the open-source headless CMS, had joined the company. Figma is the dominant design and prototyping platform, and its move into content management signals a belief that design, content, and production code should stop being separate worlds handed off between separate teams.

The logic is one every agency and product team recognizes. Designers create polished, consistent components in Figma. Developers then recreate those components in code. Content teams then struggle to keep everything maintained, often duplicating content across spreadsheets and the CMS. The gap between design and code has persisted for years, and a fragmented CMS usually makes it worse rather than better. Figma’s bet is that owning a developer-friendly CMS lets it close that gap, mapping designed components directly to real content and data so a design can flow toward production without being rebuilt from scratch at each stage. The acquisition aligns with Figma Sites, the company’s tool for building responsive websites, and a Figma CMS it has signaled is coming.

For existing Payload users, the immediate practical news was reassuring with one caveat. Payload remains MIT-licensed and open source, the GitHub repository stays active, and self-hosting is unaffected; the entire team moved to Figma, and Payload Cloud paused new sign-ups while a replacement is built. Teams running Payload were advised to confirm their hosting plans, since the managed offering is in flux, and to keep an exit plan, mirroring their repository and content, as a hedge against any future strategy shift, sensible advice for any platform under new ownership.

The deeper signal is about AI’s effect on this whole space. Figma’s leadership has been explicit that large language models can now generate interface code, which threatens the role of a pure design tool, and that as AI makes it easier to produce code and content, the ability to control what you actually deploy and to fine-tune the end-user experience becomes more important, not less. In other words, when generating a rough site becomes trivial, the value shifts to structured content, design fidelity, and controlled production, the parts that a serious CMS and a real design system provide and that a one-shot AI generation does not. Figma is positioning to own that higher-value layer.

For the three-way comparison, the acquisition matters as a leading indicator. It tells you that the people building the next generation of professional tools believe the future is headless, component-driven, and tightly integrated across design and content, rather than either a monolithic CMS or a disposable AI-generated artifact. It also tells you that the open-source, developer-first model Payload represents is now backed by a company with the resources to push it into the mainstream. Whatever an individual business chooses today, the direction of serious tooling is toward closing the design-to-content-to-code gap, and that direction shapes which skills and which platforms will compound in value over the rest of the decade.

The money behind the AI builder boom

The capital flowing into AI website and app builders is the clearest evidence that this is a real category and not a passing demo, and the numbers also explain why security and quality have lagged. The incentives reward speed and growth, and the funding has followed exactly that.

Lovable is the defining story. It reached $4 million in annual recurring revenue in its first four weeks, $10 million within two months, and $200 million within twelve months, the fastest growth in European startup history by several accounts. It raised $200 million at a $1.8 billion valuation in July 2025, then $330 million at a $6.6 billion valuation in December 2025, more than tripling its valuation in five months, with a user base around eight million served by a team of roughly fifteen people at the earlier milestones. Those figures are the envy of the software industry and the root of a structural problem: a company growing that fast, that lean, faces enormous pressure to keep shipping features and almost none to slow down for security review.

The acquisitions tell a parallel story. Wix paid $80 million in cash, with potential earnouts running through 2029, for Base44, a vibe-coding tool that was roughly six months old at the time. Base44 had launched in late 2024, became profitable within months, and positioned itself as the most approachable vibe-coding experience, the “Squarespace of vibe coding,” with fully automated backend setup for non-technical founders. A six-month-old company commanding an eighty-million-dollar acquisition by an incumbent is a measure of how seriously the established players take the threat and the opportunity. Wix’s own AI direction, the Aria assistant inside Wix Harmony, runs in parallel, hedging across both the no-code and code-generation approaches.

The rest of the field is funded and active. Bolt.new, which runs full Node.js environments in the browser through WebContainer technology and is powered by Claude, and v0 by Vercel, which generates production-quality React components using real libraries like Tailwind and shadcn/ui, both occupy strong positions, with v0 deeply tied to the Vercel and Next.js ecosystem. Replit, Orchids, and a steady stream of newer entrants compete on price, design quality, or deployment simplicity. Security firms have raised money specifically to clean up after this boom: Escape raised $18 million to replace manual penetration testing with AI agents scanning vibe-coded apps, an investment thesis that exists only because the problem is large and growing.

The pricing models reveal the consumer-facing economics, and they are less generous than the marketing implies. Most AI builders advertise a sticker price between roughly $15 and $25 a month but obscure how many AI messages or credits that actually buys. Lovable’s $25 plan provides around 100 credits, which translates to roughly twenty to thirty real prompts before top-up charges begin. Hostinger advertises a low promotional price with just five credits a month, then jumps at renewal. Bolt’s generous-sounding token allowance can be consumed in days on a real project. The credit limit is the column competitors hide, and it is the one that determines whether the advertised price bears any relation to what a working project costs.

The investment picture supports a clear-eyed conclusion. The money confirms that AI generation is a durable part of how websites and apps get built, and the speed it enables is genuine and valuable. The same money, chasing growth above all, helps explain why the security and quality track record is poor: the market pays for shipping fast and getting big, and only recently, under pressure from researchers and breaches, for getting it right. A business adopting these tools is buying into both halves of that bargain, and the next sections trace exactly where the second half comes due.

Cost compared honestly across the three paths

Cost is where the three approaches diverge most sharply and where the advertised numbers mislead most reliably. The honest comparison spans years, not months, and counts effort as well as money.

WordPress has the lowest software cost and a wide hosting range. The software is free. Hosting runs from a few dollars a month on budget shared plans to managed WordPress hosting that can make a site roughly 2.4 times faster but costs more, typically tens of dollars a month for a small business and into the hundreds for high-traffic sites. Premium themes and plugins add one-time or recurring fees, a serious site often paying for a page builder, an SEO plugin, security, backups, and a few feature plugins, which together can reach a few hundred dollars a year. A capable WordPress site is realistically a few hundred to a couple thousand dollars a year all-in for a small business, before any paid development.

A custom headless build inverts the ratio: low recurring software cost, high upfront and ongoing engineering cost. The CMS itself can be free if self-hosted, like Strapi or Payload, or a managed subscription. Strapi Cloud starts around $29 a month, Payload Cloud around $35, Directus Cloud around $99, Sanity’s Growth plan around $199, and Contentful around $300 at its current entry point. Frontend hosting on a platform like Vercel adds its own tiers. The dominant cost, though, is people. A headless site is custom software, so the build is a development project costing thousands to tens of thousands of dollars depending on scope, and maintenance is ongoing engineering rather than plugin updates. The platform fees are almost a rounding error next to the human cost.

AI builders front-load convenience and back-load surprises. The advertised range clusters between roughly $15 and $25 a month, with budget options near $2 to $3 promotionally and premium AI-plus-human services reaching $399. The trap is the credit system: the sticker price buys a limited number of AI interactions, and real projects exhaust them quickly, triggering top-ups. Lovable’s $25 plan yields roughly twenty to thirty real prompts; Hostinger’s low promo price includes five credits a month before a sharp renewal increase. Custom domains, email hosting, transaction fees, and form-submission caps add costs that the first-year headline conceals, and the cheapest year-one plan is frequently not the cheapest in year two.

Approximate cost profile by approach

These figures are representative ranges drawn from 2026 pricing and vary widely by provider, project scope, and traffic; treat them as a frame for budgeting rather than a quote.

The reframing that helps most is to stop comparing monthly stickers and start comparing two-year totals including labor. On that basis, an AI builder is cheapest for a simple site you maintain yourself, WordPress is cheapest for a flexible site where cheap labor or your own time covers maintenance, and a headless build is most expensive by a wide margin and justified only when performance, control, or multi-channel content delivery pays back the engineering investment. A business that picks on monthly price alone routinely discovers the real cost after the architecture is locked in, which is the worst time to learn it.

Total cost of ownership beyond the sticker price

Total cost of ownership is the number that should drive platform decisions and almost never does, because it is harder to see than a monthly fee. It includes maintenance, security, the labor to operate the thing, the cost of fixing what breaks, and the eventual cost of leaving. Each approach carries a distinct ownership profile that the sticker price hides.

WordPress’s ownership cost is maintenance that never stops. Core, themes, and every plugin require updates, and because the overwhelming majority of vulnerabilities arrive through plugins and themes, skipping updates is a security decision with consequences. Plugins occasionally conflict, an update can break a site, and someone has to test and resolve it. For a business with technical staff or a maintenance retainer, this is a managed line item. For a small business going it alone, it is a recurring tax of attention that, when neglected, produces the hacked-WordPress-site story everyone has heard. The platform is free; keeping it healthy is not.

Headless carries the highest and most misunderstood ownership cost, and the open-source “free” label is where people deceive themselves. Self-hosting Strapi or Payload costs nothing in license, but operating a self-hosted CMS reliably, handling upgrades, backups, monitoring, and plugin compatibility through major versions, typically consumes between a quarter and a half of a senior engineer’s year. At a loaded senior-engineer salary, that is roughly $50,000 to $100,000 a year in real cost, which dwarfs the price difference against a managed CMS. The honest conclusion, repeated by agencies that ship these builds, is that self-hosting is the right choice when you genuinely need it for compliance, data residency, or control, and the wrong choice when you adopt it merely to save money, because it does not.

AI builders defer their ownership cost into lock-in and risk. The monthly fee is small, but the site lives on the vendor’s platform and usually cannot leave, so you are renting indefinitely, and your costs are subject to whatever the vendor decides to charge next year. If the tool generated code with a security flaw, the cost of that flaw is yours. If the vendor changes terms, raises prices, or shuts a product, you absorb it. The category’s track record makes this concrete: with so much AI-generated code containing vulnerabilities and so many vibe-coded sites exposed publicly by default, the deferred cost can arrive as a breach rather than an invoice, which is a far worse way to pay.

A migration cost waits at the end of every path, and it is real regardless of approach. Moving content between headless CMSs is typically a four-to-eight-week project for a meaningful site, dominated not by extracting content but by remapping the schema, asset references, and downstream integrations. Leaving a locked AI builder usually means rebuilding entirely. Migrating off WordPress means recreating in a new system whatever plugins provided. Whatever you choose, you are also choosing how expensive it will be to choose again, and that future cost belongs in the present decision. The platform that is cheapest to start is frequently the most expensive to own and to leave, and the only defense is to count all three costs, start, run, and exit, before committing.

Speed of getting live, and what that speed hides

Time to launch is the dimension where AI builders win cleanly and where the win is most often misread. They are genuinely the fastest way to get a site online, and that speed solves a real problem for people who need a presence now. The misreading is treating launch speed as if it were the same as being ready, which it is not.

The ranking on raw speed is not close. An AI builder can produce a live, working site in minutes from a prompt, and a no-code AI builder aimed at a non-technical owner can take someone from idea to published URL in well under an hour. WordPress is fast but not that fast: installing it, choosing and configuring a theme, adding the plugins a site needs, and entering content is a matter of hours to days for a simple site, faster with a page builder, slower for anything custom. A headless build is the slowest by design, because it is a development project, with content modeling, frontend coding, and integration work measured in weeks to months. If the only goal is to exist online by tomorrow, the order is clear.

The gap narrows the moment quality and fit enter the picture. Every AI builder produces somewhat generic initial output, and most realistic projects need one to two hours of refinement regardless of tool just to stop looking templated. A no-code AI site is fast to a first draft and then constrained by the platform’s components when you want something specific. WordPress’s few extra hours buy a level of customization and an ecosystem that an AI builder’s speed does not, and a headless build’s weeks buy exactly the site you specified rather than the nearest thing a model could assemble. Speed to a generic result and speed to the right result are different races, and the order of finishers changes between them.

The deeper hazard is the distance between “working” and “production-ready,” a gap that AI builders make especially easy to ignore. A founder can ship a functional application in a weekend with an AI tool, complete with authentication, a database, and a polished interface, and have it pass a security scanner, and still be exposed. The widely cited pattern is a site that looks finished and is quietly insecure, because the model generated features but not the access controls and secrets handling that protect them. Speed that hides this is not a benefit; it is a liability with a delay on it. The faster a tool lets a non-expert deploy something real, the more important it becomes that someone competent reviews what was deployed before customers and their data depend on it.

There is also a quieter speed cost in the other direction. WordPress and headless builds are slower to launch but often faster to change safely afterward, because they are built to be edited, extended, and maintained. A locked AI-generated site can be quick to produce and then frustrating to evolve, since you are working within a platform’s limits or, in the code-generation case, on top of code no human carefully designed. The total time that matters is not time to launch but time across the life of the site, and on that measure the fast-to-launch option is not always the fast-to-live-with one.

The sensible way to use launch speed is to match it to stakes. For a temporary campaign page, an event microsite, a prototype to test an idea, or a personal project, an AI builder’s speed is close to pure upside, and the risks are small because little depends on it. For a site that will hold customer data, represent a brand for years, or carry a business’s revenue, launch speed is the least important variable, and trading a few weeks for control, security, and maintainability is almost always the better deal. The tools that launch fastest are the right answer precisely when speed is what you actually need and the wrong answer when you have mistaken it for everything else.

Performance and Core Web Vitals as a competitive line

Performance stopped being a nicety and became a ranking and conversion factor, which turns it into one of the sharpest lines between the three approaches. How a site is built largely determines how fast it loads, and the differences are now large enough to show up in both search rankings and revenue.

The benchmark numbers are stark. The average WordPress page loads in about 3.4 seconds, against roughly 0.8 seconds for a well-built Next.js site and about 1.4 seconds for Webflow, and only around a third of WordPress mobile sites pass Google’s Core Web Vitals thresholds. Those vitals, which measure loading, interactivity, and visual stability, feed directly into search rankings and correlate with conversion: slow pages lose visitors before they convert. The performance gap is WordPress’s growing competitive disadvantage, and it is structural, rooted in the server-side, plugin-laden architecture rather than in any single fixable setting.

Headless builds win on performance for architectural reasons, not luck. Prebuilt static pages served from a content delivery network, combined with modern frameworks, let the strongest headless stacks score a perfect 100 on Lighthouse out of the box. The page a user requests is often already assembled and waiting on an edge server near them, so there is little for the server to compute on each request. This is the core technical argument for going headless: when performance is a business priority, the decoupled, statically generated, edge-delivered model wins by a margin that template-based platforms cannot easily close. The cost, as always, is the engineering to build and maintain it.

AI builders are a mixed and often poor performer, and the reason ties back to how they render. Most generate single-page applications that lean on client-side JavaScript, which can produce heavy bundles and slow interactivity, and Wix in particular is known for JavaScript bloat that drags performance down. The exceptions track the tools that emit clean output: a Lovable-plus-Vercel static stack can reach top Lighthouse scores, Webflow performs well because it produces lean HTML, and 10Web inherits WordPress’s performance characteristics. The lesson is that AI generation does not determine performance by itself; the output format does, and a tool that ships a bloated client-side bundle will be slow no matter how the demo felt.

WordPress’s performance is improvable but never free. Managed hosting can roughly double a site’s speed, good caching can cut load times substantially, and disciplined plugin use matters because each ten plugins tend to add around half a second. Version 7.0 brought performance gains and moved image resizing and compression into the browser to reduce server load. A carefully optimized WordPress site on quality hosting can be genuinely fast. The point is that this is work and money spent to reach a baseline that a headless build starts at, and that most WordPress sites in the wild do not do that work, which is why the average is 3.4 seconds.

For a site where speed affects the bottom line, an ecommerce store losing sales to slow pages, a publisher whose ad revenue tracks pageviews, a brand competing on a polished experience, performance should weigh heavily in the platform decision rather than being treated as something to fix later. The fast options are headless and the cleaner AI stacks; the option that needs the most effort to be fast is WordPress; and the option that is often slow by default is the typical client-side AI build. Knowing that before choosing prevents the common and expensive mistake of picking a platform on other grounds and then spending months trying to make it fast enough to compete.

Control, ownership, and the lock-in question

Ownership sounds abstract until a vendor changes its terms or a project needs something the platform will not allow, and then it becomes the most concrete consideration there is. The three approaches sit at very different points on the spectrum from total control to total dependence, and where a project lands shapes its options for years.

WordPress sits near the open, ownable end. It is open-source software you install on hosting you control, your content lives in a database you can export, and you are free to move the whole site between hosts or modify anything. There is no company that can lock you out or force a change, which is a large part of why WordPress won and why it remains attractive to anyone wary of dependence. The ownership is not absolute, because individual commercial plugins and themes carry their own licenses and lock-in, and migrating away from a plugin-heavy site means replacing those features. But the core platform belongs to you in a way that hosted alternatives do not, and that durability has real value over a long horizon.

Headless builds, done with open-source tools, offer the strongest ownership of all, at the price of responsibility. Self-hosted Strapi or Payload under permissive licenses, the MIT license in Payload’s case, means no licensing ceiling, no vendor able to revoke your software, and complete control of your data and implementation. You own the code, the content, and the infrastructure. The flip side is that owning all of it means operating all of it, which is the engineering cost discussed earlier. Managed headless platforms trade some ownership for convenience: with Sanity or Contentful, the vendor runs the infrastructure and holds your content within their system, and while these expose enough API surface to extract content if you leave, you are dependent on the provider while you stay, including on its pricing decisions, of which Contentful’s removal of its free tier is a recent reminder.

AI builders are where lock-in is most severe and least visible at decision time. No-code AI platforms like Wix, Squarespace, Durable, and Hostinger’s builder generally do not allow full code export, so the site exists only as an arrangement on their platform; you can leave, but you start over. Even code-generation tools that nominally export are uneven: Lovable’s export goes through GitHub but the exported code often does not run cleanly elsewhere because of its dependence on the platform’s forked services and captive runtime, while Bolt exports through StackBlitz, and v0, Webflow, and 10Web produce code or sites you can genuinely take with you. The lock-in column is the one that should be read most carefully before adopting any AI builder, because it determines whether you are buying an asset or renting one indefinitely.

The ownership question has sharpened because of how AI changes the calculus. When a rough site can be generated in minutes, the durable value moves to the things you control and can carry forward: structured content you own, a design system, code you can host anywhere. A site you cannot export is a site whose entire value is hostage to one vendor’s continued existence and goodwill, which is a fragile position precisely when the vendors are young, fast-moving startups whose products and prices change rapidly. The Payload-to-Figma transition, even handled responsibly, prompted the standard advice to mirror your repository and keep an exit plan, and that advice applies with far more force to a platform you cannot export from at all.

The practical rule is to decide how much ownership the project actually requires and choose accordingly, rather than discovering the answer after lock-in. A throwaway or short-lived site can accept heavy lock-in because little is at stake in leaving. A site meant to last years, hold accumulated content and SEO value, or anchor a business should favor approaches you can own and move, which points toward WordPress or open-source headless and away from platforms that trap the output. Ownership is cheap to secure at the start and expensive to recover later, and the businesses that regret their platform choice most are usually the ones that optimized for convenience and found themselves unable to leave.

The security reckoning around vibe-coded sites

The security record of AI-generated sites is the most important and least advertised fact in this entire comparison, and 2025 and 2026 turned a theoretical worry into a documented crisis. The pattern is consistent enough across independent studies that it should change how anyone thinks about putting an AI-built site into production with real data behind it.

The headline studies are alarming and corroborated. One assessment of more than 200 vibe-coded applications in early 2026 found that 91.5 percent contained at least one vulnerability traceable to AI-generated mistakes. A separate scan of 1,072 Supabase-backed vibe-coded apps found that 98 percent had at least one security flaw, with only 26 of them clean. In that scan, 172 sites allowed anyone to delete database records with no authentication, another 172 allowed unauthenticated modification of records, and dozens exposed sensitive personal data including emails, hashed passwords, authentication tokens, and phone numbers. These were live production systems, discoverable in hours, not lab constructs.

The root cause is structural and worth understanding because it explains why the problem is so widespread. Many AI builders generate a frontend that talks directly to a hosted backend like Supabase or Firebase using an API key embedded in the client-side code, which is a normal pattern only when database access rules are configured correctly. Supabase exposes a REST API from the database automatically, and security depends entirely on row-level security policies that restrict who can read and write what. The AI generates the database layer but routinely fails to generate those access controls, and a non-technical builder does not know the rules exist, so the database happily serves every row to anyone who asks. This became formal as CVE-2025-48757, documenting insufficient row-level security in Lovable-generated Supabase projects and exposing data across more than 170 production applications, roughly one in ten of the apps Lovable showcased on its own marketplace.

The breaches made the statistics concrete. The vibe-coded social network Moltbook was compromised within three days of launch, exposing about 1.5 million API authentication tokens, more than 35,000 email addresses, and thousands of private messages, because row-level security was disabled while the public API key sat in the client code. A separate consumer app exposed roughly 3.2 million user records through an unauthenticated backend. An October 2025 scan of 5,600 vibe-coded apps found over 2,000 high-impact vulnerabilities, more than 400 exposed secrets, and 175 instances of exposed personal data including medical records and bank account numbers. Israeli firm RedAccess discovered 380,000 publicly accessible vibe-coded assets, of which about 5,000 held sensitive corporate data, findings independently verified by major outlets. In one widely reported incident, an AI coding agent autonomously deleted a company’s entire production database during a routine task.

A compounding problem is that these apps default to public and get indexed. Privacy settings on several vibe-coding platforms leave apps publicly accessible unless a user manually switches them to private, and search engines index them within hours, so an internal tool a product manager built over a weekend and connected to a live customer database can be discovered by anyone scanning the web. This is the production layer of what security teams call shadow AI, and traditional asset-discovery tools cannot see it, because it deploys on rotating platform subdomains behind CDN layers that never appear on any inventory. IBM’s 2025 breach research found that incidents involving shadow AI cost on average $670,000 more than other breaches, pushing the average toward $4.63 million.

The industry’s response shows both the severity and a path forward. Lovable partnered with a security firm to add automated penetration testing, and Wiz worked with Lovable to change its global system prompt so it treats embedding client-side secrets as a security risk, while specialized firms raised capital to scan and remediate the category at scale. None of this absolves a business that ships an insecure AI-built site; responsibility for the data sits with whoever deployed it. The defensible position is to treat any AI-generated application as untrusted until reviewed: search the deployed code and bundle for exposed credentials, verify that database access rules deny by default and grant only what is needed, and have someone competent audit the trust boundaries before real users and their data arrive. Used as a fast prototyping tool with that review step, AI generation is reasonable. Used as a way for non-experts to ship production systems unreviewed, it has a documented record of exposing exactly the data it was trusted to protect.

WordPress security in its own right

Singling out AI builders for their security record would be unfair without an honest look at WordPress, whose security reputation is its own well-earned cautionary tale. The difference is not that WordPress is safe and AI builders are not; it is that WordPress’s risks are well understood, well documented, and manageable with known practices, while the AI-builder risks are newer and frequently invisible to the people taking them.

The scale of attacks on WordPress is enormous precisely because the platform is enormous. WordPress sites face on the order of 90,000 attacks per minute across the web, a direct consequence of running close to half of all sites and therefore being the highest-value target for automated attacks. A vulnerability in a popular plugin can expose millions of sites at once, so attackers scan continuously for known weaknesses. Ubiquity is a security liability in itself, and WordPress carries it.

The concentration of risk is the most useful fact for anyone running WordPress. The overwhelming majority of WordPress vulnerabilities, commonly cited around 97 percent, originate in third-party plugins and themes rather than in WordPress core. Core itself is maintained by a large contributor base and patched promptly. The danger lives in the ecosystem that makes WordPress powerful: every plugin is third-party code with its own quality and maintenance, an abandoned plugin stops receiving security fixes, and a site with many plugins has a correspondingly large attack surface. This is the precise trade-off of the plugin model, the same extensibility that lets WordPress do anything also widens the ways it can be compromised.

The mitigations are well established, which is what separates WordPress from the AI-builder situation. Keeping core, themes, and plugins updated closes the majority of holes, since most attacks target known vulnerabilities that patches already fixed. Choosing well-maintained plugins, removing unused ones, running a security plugin or firewall, using strong authentication, and hosting with a provider that hardens the stack together reduce the risk to a manageable level. A WordPress site that is actively maintained by someone who follows these practices is reasonably secure. The hacked-WordPress stories overwhelmingly involve neglected sites, outdated plugins, and absent maintenance rather than failures of properly tended installations.

The honest comparison, then, is about the nature of the risk rather than its mere presence. WordPress’s risk is known, documented, and addressable with mature practices, but it demands ongoing discipline that many site owners do not maintain. The default WordPress install is not enterprise-grade without hardening, and a business running WordPress should treat security as a continuing responsibility with real cost, whether handled in-house or through a managed host or maintenance retainer. The platform does not protect a negligent owner, but it gives a diligent one everything needed to stay safe.

Set against the AI-builder record, the contrast is instructive. A neglected WordPress site is vulnerable through known plugin flaws that patches and basic hygiene would close; a vibe-coded site is frequently vulnerable through missing access controls that the builder never told the owner to configure and that no routine scanner flags. One failure mode is a discipline problem with a known cure; the other is an architecture-and-awareness problem that the tooling actively obscures. Neither approach is safe by default, and a custom headless build is not automatically secure either, since it depends entirely on the engineering team’s practices, though its small server-side surface helps. Security on any platform is a function of competent, ongoing attention, and the platforms differ mainly in how visible they make the work that attention requires.

SEO foundations across the three approaches

Search visibility is where a marketing lens reshapes the whole comparison, because a beautiful site that cannot be found is a failed site, and the three approaches start from very different positions on being found. Traditional search engine optimization, the discipline of ranking in Google’s results, depends on a crawler being able to read your content, on fast and stable pages, and on structured signals that help search engines understand what a page is about. Each approach delivers those differently.

WordPress has the deepest SEO support of the three, earned over two decades. Mature plugins like Yoast and Rank Math handle titles, meta descriptions, sitemaps, structured data, and on-page guidance, and the platform’s server-rendered HTML is fully readable by crawlers. This is a genuine strength: WordPress sites rank well partly because the SEO toolchain is so well developed and so easy to apply without technical skill. The weak spot is performance, since Core Web Vitals are a ranking factor and the average WordPress page is slow, but the content and structure that search engines read are present and well-handled by default, and the tooling to refine them is the best in the field.

Headless builds can achieve excellent SEO but require you to build it deliberately, because nothing is bundled. A headless CMS does not improve or hurt SEO by itself; the frontend implementation determines everything, and you are responsible for structured data, meta tags, sitemaps, and crawlability rather than toggling a plugin. Done right, the payoff is large: static generation and edge delivery produce the fast load times that Core Web Vitals reward, and clean semantic HTML with proper heading hierarchy is exactly what both search engines and AI engines prefer. The risk is a team that builds a fast, beautiful frontend and forgets the SEO plumbing, shipping a site that renders server-side but lacks the structured signals to rank. The ceiling is higher than WordPress; reaching it takes expertise WordPress hands you for free.

AI builders are where SEO most often goes wrong, and the cause is technical rather than incidental. Most AI builders generate single-page applications whose content renders only after client-side JavaScript runs, leaving the initial HTML nearly empty, which means search crawlers reading that initial HTML find little to index. A site that looks complete to a visitor can be close to invisible to Google. The exceptions are the tools that avoid client-side-only rendering: 10Web produces WordPress and therefore ranks like WordPress, Webflow emits clean crawlable HTML, and Lovable added SEO support in a recent release, while a Lovable-plus-Vercel static stack can produce semantic HTML and strong vitals. The default AI build, though, often sacrifices the one thing a content site most needs, and people discover this only when the traffic never arrives.

The structural SEO advice is consistent across all three and worth stating plainly. Server-render the content you want found, or ensure it is present in the initial HTML rather than locked behind JavaScript; keep pages fast; use clean heading hierarchy and valid structured data; and never block the crawler. WordPress satisfies most of this by default and needs help on speed. Headless satisfies all of it if you build it that way. AI builders satisfy it only if you choose one of the exceptions or do substantial work to fix the rendering. For any business that depends on organic search, this single technical fact, how the site renders to a crawler, should weigh heavily in the platform choice, because it is far cheaper to choose a crawlable architecture than to retrofit one.

Generative engine optimization and the new visibility war

Search is no longer only about ranking in a list of links, and the shift toward AI-mediated answers has opened a second front in the visibility war that platform choice directly affects. Generative engine optimization, or GEO, is the practice of structuring and sourcing content so that AI answer engines like ChatGPT, Perplexity, and Google’s AI Overviews cite it when they generate answers. Where traditional SEO tries to win a ranked link, GEO tries to win a sentence inside the answer, and the technical requirements overlap with SEO but are not identical.

The stakes are growing fast. AI Overviews now appear in roughly a quarter of Google searches, and their effect on clicks is severe: studies show organic click-through rates dropping by around 60 percent on queries where an AI Overview appears, with one analysis finding position-one click-through falling from about 7.3 percent to 1.6 percent. For a widening share of informational queries, the AI answer is the whole result and a handful of cited sources sit beneath it. The blue links still exist, but fewer people scroll to them, which means appearing in the answer is becoming as important as ranking below it.

The discipline has a research foundation worth knowing. The term was formalized in a 2024 study from researchers at Princeton, Georgia Tech, the Allen Institute for AI, and IIT Delhi, which tested optimization strategies across thousands of queries and found that adding relevant quotations lifted visibility by around 41 percent, statistics by roughly 30 percent, and citations by about 30 percent. The practical takeaway is that AI engines favor content that is well-sourced, specific, and easy to extract as a self-contained claim. The shape that works is direct: open a section with a clear answer in a few dozen words, support it underneath, use tables for comparisons because models lift them almost verbatim, and put the most important claims early, since a large share of citations come from the first third of a page.

The key connection for this comparison is that GEO depends on the same technical floor as SEO, and that floor is set by platform choice. Google’s own guidance confirms that AI Overviews and AI Mode rely on core Search systems and the same Googlebot crawler, with no separate AI crawler, so content that is invisible to the crawler is invisible to the AI answer. AI engines generated in near-real-time can time out before heavy client-side JavaScript renders, which means a site that hides its content behind client-side rendering can be excluded from AI answers for the same reason it struggles in search. Server-rendered content in the initial HTML, valid structured data, and fast pages are the price of entry to citation, and they map exactly onto the rendering differences between the three approaches.

That mapping favors the same options as SEO, with a sharper edge. WordPress and headless builds that server-render are well positioned for GEO because their content is present for the crawler and can carry the structured data that improves citation odds; the typical client-side AI build is poorly positioned for the same reason it struggles in search. There is a real opportunity hidden in the data: analyses find that a large majority of AI Overview citations come from pages outside Google’s organic top ten, and the overlap between top-ranking links and AI-cited sources has fallen sharply, which means a well-structured page that never cracked page one can still be the source an AI quotes. For a young site, that is the most level playing field search has offered in years, but only if the site is built so the AI can read it.

The strategic conclusion ties the technical and the editorial together. Being found in 2026 means being readable by crawlers, fast, structured, and genuinely authoritative, and the platform decision sets the technical baseline for all of it. A business serious about both search and AI visibility should choose an architecture whose content lives in the initial HTML, invest in structured data and clean semantics, and pair that with original, well-sourced content that gives an AI a reason to cite it over a competitor. The platforms that make this straightforward are WordPress and properly built headless; the platform that most often undermines it is the default client-side AI build. GEO does not replace SEO so much as raise the cost of getting the technical foundation wrong, and that foundation is poured the moment you choose how the site is built.

Content operations and the daily editor experience

The launch is a moment; editing the site is the rest of its life, and the daily experience of the people who actually update content differs enormously across the three approaches. This is the dimension that decision-makers most often ignore and that the content team feels every single day, which makes it worth as much weight as cost or performance.

WordPress is built around the editor and shows it. A non-technical author logs into a familiar dashboard, writes in the block editor, adds images, sets categories, and publishes, all without involving a developer. Two decades of refinement have made this approachable, and version 7.0’s block-level Notes added threaded comments, @mentions, and a suggestions mode that lets teams collaborate on drafts asynchronously, closing much of the gap that pushed editorial teams toward external tools like Google Docs. The editing experience is one of WordPress’s strongest and most underrated advantages: the people who maintain the site can do so independently, which is exactly what a content-driven organization needs.

Headless splits the editor experience in two, and the split is the whole story. The content team works in the CMS’s editing interface, which can be excellent or awkward depending on the platform, while the live site is rendered by a separate frontend, so editors do not always see their changes in context as they work. This is the friction headless introduces, and the platforms address it very differently. Storyblok’s visual editor with live preview lets authors drag, drop, and see changes render, the closest headless gets to the WordPress experience, while Sanity’s customizable Studio can be shaped into a tailored editing experience at the cost of building it. Contentful and Strapi offer structured, form-based editing that developers like and some content authors find less intuitive. The editor experience in headless is a feature you choose and often build, not one you get for free, and underestimating it produces a fast site that the content team quietly hates.

AI builders vary from genuinely good to barely-a-CMS, and the difference matters most after launch. A no-code AI builder typically gives a reasonable visual editor for ongoing changes, since the platform is built for non-technical owners to maintain their own sites. But an AI-native code generator often produces a site or app whose content is baked into code rather than managed through a structured interface, so changing content can mean prompting the AI again or editing code, neither of which is real content operations. The question to ask of any AI builder is whether it leaves you with an editable, structured site or a one-time artifact, because that determines whether updating the site is a routine task or a project.

The deciding factors come down to who edits and how often. An organization that publishes frequently and wants non-technical staff to maintain the site independently is best served by WordPress or a headless platform with a strong visual editor; an organization where content rarely changes can tolerate a more developer-dependent or rebuild-on-change model. The Figma-Payload direction points at where this is heading, toward closing the gap between how a site is designed and how its content is maintained, so editors work closer to the real experience. Until that future arrives, the practical advice is to weigh the editor experience as heavily as the visitor experience, because a site no one can comfortably update is a site that goes stale, and stale content fails in both traditional search and AI citation regardless of how the site was built.

Scaling from a brochure site to a real platform

Many websites start small and are expected to grow, and the three approaches handle growth very differently. The platform that suits a five-page brochure site may be exactly wrong for the same business two years later running a busy store, a member portal, or a high-traffic publication. Knowing where each approach breaks under growth prevents the painful, expensive rebuild that happens when a site outgrows its foundation.

WordPress scales further than its reputation suggests but demands more care as it does. It runs everything from a personal blog to major newspapers and magazines and high-traffic enterprise sites, so the platform itself is not the ceiling. What changes at scale is the operational burden: a busy WordPress site needs serious hosting, aggressive caching, careful plugin management, and often a content delivery network and database tuning to stay fast. The plugin model that makes small sites easy becomes a liability at scale, where each plugin is performance and security overhead multiplied across heavy traffic. WordPress can grow with a business, but the cost and complexity of keeping it fast and secure rise steeply, and at the top end it often needs the kind of engineering attention that blurs into a custom operation.

Headless is built for scale and is frequently the destination businesses migrate toward when they outgrow simpler tools. The decoupled architecture, static generation, and edge delivery that make headless fast also make it handle traffic gracefully, since prebuilt pages served from a CDN absorb load that would strain an origin server. Content reuse across web, mobile, and other channels becomes more valuable as an organization grows and its content needs multiply. This is why large content operations and complex products tend to land on headless: it is the approach designed for the demands that break other platforms. The cost is the same one that applies at every size, engineering, but at scale that cost is easier to justify because the alternative is a platform fighting its own architecture.

AI builders hit walls earliest, and the walls are both technical and architectural. No-code AI builders are built for simple sites and constrain customization, so a business that needs anything beyond the platform’s components quickly runs out of room. AI-native code generators can technically produce more complex applications, but the quality and security concerns compound as the application grows, and code no human carefully designed becomes harder to extend and maintain over time. The honest framing from practitioners is that these tools can build the surface layer of something ambitious, product pages, a storefront front-end, a prototype, but real complexity, inventory, payments, tax, reliable data handling, exceeds what they reliably deliver. AI builders are excellent for the small end and for getting started, and they are the first approach to break as ambitions grow.

The strategic question is whether to choose for where you are or where you are going, and the answer depends on how confident the growth is. A business certain it will scale into a complex platform may be better served starting on an architecture built for that, typically headless, even though it is overkill at first, to avoid a disruptive migration later. A business unsure of its trajectory might reasonably start on WordPress, which scales reasonably far and is widely supported, keeping options open. A business testing an idea is right to start on an AI builder for speed and accept that success will mean rebuilding on something sturdier. The mistake to avoid is choosing purely for the launch and ignoring the growth path, because a migration forced by outgrowing a platform is one of the most expensive and disruptive events a digital operation can face, and it is largely avoidable with honest forecasting at the start.

Ecommerce realities on each platform

Selling online raises the stakes on every dimension already discussed, because an ecommerce site handles money, inventory, customer data, and transactions that must work reliably. The three approaches meet that bar very differently, and the gap between looking like a store and being one is wide.

WordPress dominates open-source ecommerce through WooCommerce, and the scale is real. WooCommerce sits behind roughly a third of all online stores and processed an estimated $35 billion in gross merchandise volume in 2025, making it the largest open-source ecommerce platform by transaction volume. It turns a WordPress site into a full store with products, carts, checkout, payments, and a large extension ecosystem for shipping, tax, subscriptions, and more. The strengths are flexibility, ownership, and cost control; the weaknesses are the same as WordPress generally, the maintenance and performance burden, amplified because a store cannot afford downtime, slow checkout, or a security lapse involving payment data. WooCommerce is the natural choice for a business that wants an ownable, customizable store and can support it properly.

Hosted and headless commerce occupy the higher-control and higher-convenience ends respectively. Shopify leads hosted ecommerce by gross merchandise volume among dedicated platforms, and it is increasingly used in a headless configuration, where Shopify handles the commerce backend and a custom frontend, often Next.js, delivers the storefront for speed and design control. Enterprise headless commerce pairs a commerce engine with a headless CMS for content and a custom frontend, the approach large retailers take when performance and bespoke experience justify the engineering. This is powerful and expensive, suited to businesses where the store is the core of the operation and the investment pays back in conversion and scale.

AI builders are the weakest fit for serious ecommerce, and the reason is fundamental rather than incidental. They can build the surface of a store, product pages and a storefront, but real ecommerce requires inventory management, shipping logic, tax calculation, and payment processing, which exceed what these tools reliably deliver. A prompt can produce something that looks like a shop; running an actual business on it is a different matter, and the security record makes trusting a vibe-coded store with payment and customer data especially unwise given how often such apps expose exactly that kind of data. For selling at any real scale, the AI-builder speed advantage is outweighed by the reliability and security a store demands.

The practical guidance follows the stakes. A small to mid-size store that wants ownership and flexibility is well served by WooCommerce on well-managed hosting; a store where commerce is the core of the business and performance drives revenue may justify Shopify or headless commerce; and AI builders are appropriate only for the simplest storefronts or for prototyping a concept before building it properly. The thread through all of it is that ecommerce removes the margin for the shortcuts that AI builders rely on, because the moment real money and customer data are involved, looking like a store stops being enough and being a reliable, secure, maintainable store becomes the only thing that matters.

Multilingual reach, localization, and global audiences

Reaching audiences in multiple languages is a requirement for many businesses and a genuine differentiator among the three approaches, because handling content in several languages well is harder than it looks and the platforms are at very different stages of solving it.

WordPress handles multilingual through plugins today and is building it into core tomorrow. The platform supports more than seventy languages for its own interface, and multilingual content has long been delivered through established plugins that manage translations and language switching. The notable development is that native multilingual support is a Phase 4 priority, with version 7.2 expected in December 2026 laying the groundwork, which would move a capability that has always required third-party plugins into the platform itself. For now, multilingual WordPress means choosing and configuring a translation plugin, which works well but adds another piece of third-party code to maintain, and the quality of the experience depends on the plugin chosen.

Managed headless platforms treat localization as a first-class enterprise feature, which is part of their appeal at scale. Contentful is known for strong localization and translation workflows, with AI Actions targeting bulk localization, and it manages multiple locales as a core capability rather than an add-on. Headless architecture suits multilingual content structurally, because structured content with locale fields can feed localized frontends cleanly, and the same content model can serve many languages and regions. This is one of the areas where the enterprise headless platforms justify their cost: organizations operating across many markets get localization tooling and governance built for exactly that complexity, rather than bolted on.

AI builders are the weakest on serious multilingual needs, consistent with their pattern of handling the simple case well and the complex case poorly. A builder can generate content in a given language, but managing a genuinely multilingual site, with proper language switching, localized URLs, correct hreflang signals for search engines, and a workflow for keeping translations in sync, exceeds what most of these tools provide. For a single-language site this is irrelevant; for a business serving multiple markets it is a real gap, and one that often surfaces only after the site is built and the need to expand internationally arrives.

The guidance scales with how central multiple languages are to the business. A business with light multilingual needs can use WordPress with a translation plugin or wait for native support; a business operating seriously across many markets is well served by an enterprise headless platform built for localization; and a business with real multilingual requirements should be cautious about AI builders, which handle this least well. Multilingual capability is easy to defer and expensive to retrofit, so a business that knows it will serve multiple languages should weigh this in the platform choice from the start rather than discovering the limitation when expansion is already underway and the architecture is fixed.

Accessibility, compliance, and data handling

Accessibility and regulatory compliance are easy to ignore until they become a legal or ethical problem, and the three approaches differ in how much they help you meet obligations that apply regardless of how a site is built. These requirements do not go away because a tool made the site quickly; they attach to the business operating the site.

Accessibility, making a site usable by people with disabilities, is both a legal requirement in many jurisdictions and a matter of reaching all of an audience. WordPress accessibility depends heavily on the theme and plugins chosen, with the project maintaining accessibility standards for core and default themes while third-party code varies widely in quality. Headless builds put accessibility entirely in the hands of the developers building the frontend, which can be excellent when the team prioritizes it and poor when they do not, since nothing enforces it. AI builders are a mixed picture: generated code may or may not follow accessibility best practices, and a non-technical owner is unlikely to know whether it does, which means an AI-built site can quietly fail accessibility requirements its owner does not realize exist. Across all three, accessibility is something you must deliberately ensure rather than assume, and the platform mainly determines how much help you get.

Data handling and privacy regulation raise the stakes further, especially where the security record intersects with compliance. A site handling personal data carries obligations under regimes like GDPR regardless of how it was built, and a vibe-coded application handling protected information carries the same legal exposure as one built by a professional team, but usually without the security review, testing, and audit logging that a professional process includes. The documented pattern of vibe-coded apps exposing personal data, including in some cases medical records and financial information, is a direct compliance liability, and the shadow-AI breach cost data shows the financial scale of getting it wrong. A business subject to data-protection rules should be especially wary of trusting an unreviewed AI-generated system with regulated data, because the convenience does not reduce the legal responsibility and the track record suggests the risk is real.

Compliance and governance at the enterprise level are where managed headless platforms differentiate themselves, which is part of what their higher price buys. Contentful and similar enterprise platforms emphasize governance, content controls, and the kind of compliance features large regulated organizations require, and a custom headless build can implement whatever auditing and controls a regulatory regime demands, because the team controls the whole stack. WordPress can meet compliance needs with appropriate configuration, plugins, and hosting, though it requires deliberate work. AI builders, by contrast, generally lack the governance and audit capabilities that regulated industries need, reinforcing their fit for low-stakes rather than high-compliance contexts.

The principle across all of it is that obligations attach to the business, not the tool. A site that quietly fails accessibility, mishandles personal data, or lacks the governance a regulated industry requires is a liability no matter how it was built or how fast it launched. A business in a regulated sector, or one handling sensitive personal data, should treat compliance and accessibility as requirements that constrain the platform choice, favoring approaches that support proper controls and review, and should be especially cautious about tools whose record shows them exposing exactly the data that regulation exists to protect.

The agency and freelancer perspective

The people who build websites for a living, agencies and freelancers, see this choice from an angle that clients rarely consider, and their economics shape what gets recommended. Understanding that perspective helps a business read a proposal critically and understand why a particular shop pushes a particular approach.

For agencies and freelancers, WordPress has long been the dependable default, and the reasons are commercial as much as technical. The enormous talent pool means staffing a WordPress project is easy, the ecosystem means most client requests can be met with existing plugins rather than custom work, and the maintenance burden creates recurring revenue through retainers. A WordPress practice is straightforward to run profitably: builds are predictable, the skills are common, and ongoing maintenance is a steady income stream. This is part of why WordPress is so often recommended, it genuinely suits many clients, and it also fits the agency business model well, and a buyer should understand both motivations are in play.

A growing set of agencies has bet on headless as a differentiator and a higher-value offering. Shops that adopted Payload or similar tools before the Figma acquisition describe choosing them for being modern, open-source, and built to scale, integrating cleanly with AI workflows and marketing tools, and producing faster, lighter, more maintainable sites than legacy stacks. Headless work commands higher fees because it is genuine software engineering, and it appeals to agencies positioning themselves as premium technical partners rather than template configurators. For a client, an agency that does headless well is a different kind of vendor than a WordPress shop, more expensive, more technical, and appropriate for more demanding projects, and the Figma-Payload move validated that direction for the firms that took it early.

AI builders are reshaping agency economics in ways still settling out. They let a small shop or solo freelancer produce more, faster, compressing the early hours of a build, but they also threaten the low end of the market, where simple sites that once paid the bills can now be generated by clients themselves. Forward-looking agencies are using AI tools to accelerate their own work while moving up-market toward the strategy, customization, security review, and ongoing partnership that AI cannot replace, exactly the work that the security record shows AI-built sites need. The agencies most exposed are those whose value was producing simple sites cheaply, since that is the work AI builders attack most directly, and the agencies best positioned are those offering judgment and capabilities the tools lack.

For a business hiring help, the agency perspective yields practical guidance about reading recommendations. A shop that only does WordPress will recommend WordPress; a headless specialist will steer you toward headless; and an agency leaning heavily on AI builders may be optimizing for its own margin rather than your long-term interest. The most trustworthy partners explain trade-offs honestly, match the approach to the project rather than to their default, and are candid about maintenance, ownership, and what happens if you part ways. The same questions that drive a good self-directed platform decision, what am I building, who maintains it, what does ownership look like, are the questions to put to any agency, and the quality of their answers reveals whether they are matching the tool to your needs or to theirs.

Sector by sector, who should pick what

General principles only go so far, and the clearest guidance comes from matching approaches to the kinds of organizations actually making this choice. The right answer changes dramatically by sector, because what a local service business needs from a website has almost nothing in common with what a software company or a national publisher needs.

A local service business, a dentist, a plumber, a restaurant, a small law firm, needs a credible, fast, findable presence without ongoing technical overhead. For most of these, WordPress on managed hosting or a no-code AI builder is the honest fit, WordPress when they want ownership and an ecosystem and have someone to maintain it, an AI builder when they want the fastest possible route to a decent site and will keep it simple. Local SEO matters enormously here, so crawlability and structured data should not be sacrificed, which argues against the client-side AI builds that struggle with both, and for WordPress or a builder like 10Web that ranks properly.

A content publisher or media brand lives and dies by content operations, performance, and search and AI visibility, which raises the bar. A serious publisher is well served by WordPress, which runs many major publications and has the deepest editorial and SEO tooling, or by a headless build when performance and multi-channel content delivery justify the engineering. The structured content, speed, and clean rendering of a good headless setup suit a publisher’s needs for both Core Web Vitals and AI citation, while WordPress offers the familiar editorial workflow and the strongest plugin-based SEO. The default client-side AI build is the wrong choice for a publisher, since invisible-to-crawlers content defeats the entire purpose.

A software company or startup building a product, with application logic, user accounts, and a need for design control, has different priorities again. A headless build or a Next.js frontend with a headless CMS fits a product company that needs control and performance, while AI-native code generators are genuinely useful for prototyping and early validation, provided the output is reviewed before it carries real users. This is the one sector where vibe-coding tools have a strong, legitimate role, compressing the path from idea to working prototype, as long as the team treats generated code as a starting point to audit rather than a finished product to trust.

Recommended approach by sector and priority

This table maps common situations to sensible defaults; every real project has specifics that can shift the answer, so treat it as a starting point rather than a verdict.

Enterprises and regulated organizations need governance, compliance, scale, and reliability above speed or cost. These are best served by managed headless platforms built for governance, by enterprise headless commerce for large stores, or by properly hardened and supported WordPress, and they are exactly the contexts where vibe-coded applications are most dangerous because of the data and compliance stakes. At the other end, a portfolio or personal site is where AI builders shine with little downside, since the stakes are low and speed and cost dominate, and over-engineering such a site on headless is a waste of money and effort. The pattern across sectors is consistent: match the approach to what the organization actually needs and can support, and the supposedly universal best platform dissolves into a set of sensible, situation-specific answers.

Five honest failure modes to plan around

Every approach can fail, and the failures follow predictable patterns. Naming them in advance is the cheapest insurance available, because most platform regret traces back to one of a small number of avoidable mistakes that were visible at the start to anyone looking for them.

The first failure mode is lock-in that traps you on a platform you have outgrown or want to leave. This bites hardest with no-code AI builders that do not allow export, where the entire site exists only on the vendor’s platform and leaving means rebuilding from nothing. It also affects managed platforms whose pricing or terms change, as Contentful’s removal of its free tier showed. The defense is to know the exit cost before entering: favor approaches you can own and move, like WordPress and open-source headless, when the site matters long-term, and accept lock-in only for sites where leaving is cheap because little is at stake.

The second failure mode is security exposure, most acutely with unreviewed AI-generated applications. The documented record, with the large majority of vibe-coded apps containing flaws and many exposing personal data publicly by default, makes this the most dangerous and most underestimated failure. It arrives not as a warning but as a breach, often discovered by a researcher or an attacker rather than the owner. The defense is to treat any AI-generated application as untrusted until audited, to verify access controls and secrets handling, and never to put regulated or sensitive data behind a system no competent person has reviewed. WordPress’s version of this failure, compromise through neglected plugins, is more familiar and more easily prevented with maintenance discipline.

The third failure mode is performance debt that undermines search and conversion. A site chosen on other grounds, then found to be too slow to rank or convert, forces an expensive retrofit. WordPress sites that skip the hosting, caching, and plugin discipline needed for speed fall here, as do client-side AI builds that ship heavy JavaScript bundles. The defense is to weigh performance in the platform decision rather than treating it as something to fix later, since the fast options are headless and the cleaner AI stacks, and retrofitting speed onto the wrong architecture is far harder than choosing a fast one at the start.

The fourth failure mode is abandonment, when the tool or vendor you depend on changes course or disappears. The AI builder market is young and fast-moving, valuations and products shift rapidly, and a tool that anchors your site today may pivot, raise prices sharply, or shut a product tomorrow. Even responsible transitions, like Payload joining Figma with Payload Cloud paused, prompt the standard advice to keep an exit plan. The defense is to mirror what you can, prefer open-source and exportable approaches for anything important, and avoid betting a critical site entirely on a single young vendor’s continued goodwill.

The fifth failure mode is the skills gap, choosing an approach your team cannot actually maintain. A headless build handed to an organization without engineering capacity becomes an unmaintainable liability the moment the original developers leave. An AI-built application whose generated code no one understands becomes impossible to extend safely. The defense is brutal honesty about who will maintain the site and what they can handle: a small business without technical staff should not own a self-hosted headless build, and an organization without security expertise should not ship unreviewed AI-generated applications. Matching the approach to the team’s real capabilities, not its aspirations, prevents the most common slow-motion failure, where a site degrades because the people responsible for it cannot keep up with what it requires.

The thread through all five is that the failures are visible in advance to anyone who looks. Lock-in, security exposure, performance debt, abandonment, and the skills gap are all predictable from the platform choice and the organization’s situation, and all of them are cheaper to prevent at the decision point than to fix after launch. A few honest questions at the start, about ownership, security responsibility, performance needs, vendor risk, and maintenance capacity, surface every one of them, which is why the decision deserves more thought than the speed of modern tools tempts people to give it.

A decision framework you can actually use

Reasoning through this choice does not require technical expertise, only honest answers to a sequence of questions in the right order. The framework below moves from the questions that most constrain the choice to the ones that refine it, and working through it in order tends to eliminate the wrong options before the close calls even arise.

Start with the question that constrains everything: who will maintain this site, and what can they actually handle? If the answer is a non-technical owner with no support, that rules out self-hosted headless and unreviewed AI applications, pointing toward WordPress on managed hosting or a no-code AI builder. If the answer is a capable engineering team, headless becomes viable. If the answer is an agency or maintenance retainer, the choice widens. This question does more to narrow the field than any other, because a site no one can maintain fails regardless of its other merits, and answering it first prevents falling for an approach the organization cannot sustain.

Next, ask what you are really building and how long it needs to last. A throwaway campaign page, a prototype, or a simple personal site has low stakes and favors speed, which points to AI builders. A site meant to last years, anchor a brand, or carry a business has high stakes and favors ownership, control, and maintainability, which points toward WordPress or headless. The lifespan and stakes of the site determine how much the lock-in, security, and performance considerations matter, and a clear answer here often settles the choice on its own.

Then ask how you expect to be found. If organic search and AI visibility are central, the site must be crawlable, fast, and structured, which favors WordPress or properly built headless and argues strongly against default client-side AI builds. If discovery comes mainly through other channels, paid ads, direct traffic, social, this matters less. For most businesses, search and AI visibility are central enough that crawlable rendering should be close to a requirement, which is one of the most decision-relevant technical facts in the whole comparison.

Follow with what you can spend across two years, counting labor. Not the monthly sticker price but the real total: build, hosting, plugins or platform fees, maintenance, and the labor to operate it all. An AI builder is cheapest for a simple self-maintained site, WordPress is cost-effective when cheap labor or your own time covers maintenance, and headless is most expensive and justified only when its performance, control, or multi-channel benefits pay back the engineering. Counting honestly here prevents the common mistake of choosing on monthly price and discovering the real cost after the architecture is locked.

Finally, ask the refining questions that separate close calls: does the project need ecommerce, multiple languages, complex application logic, or strict compliance? Each pushes toward specific answers, WooCommerce or Shopify for serious selling, enterprise headless for heavy localization or governance, headless or reviewed AI code generation for application logic, and away from AI builders for anything involving regulated data or real transactions. Worked in this order, who maintains it, what it is and how long it lasts, how it gets found, what it costs over two years, and what special requirements it has, the framework eliminates wrong options before the close calls arise, and the approach that remains is usually clear without needing a single universal verdict, because the right answer was always specific to the project rather than to the platform.

Migrating between the three without losing everything

Platform choices are not permanent, and many businesses will eventually move from one approach to another, whether because they outgrew a tool, hit its limits, or want to leave a vendor. Migration is always more work than expected, and understanding the cost in advance both informs the original choice and prevents the worst surprises when the move comes.

Migrating between headless CMSs is a defined, sizeable project dominated by an unglamorous task. A meaningful commerce or content site typically takes four to eight weeks to migrate between headless platforms, and the bulk of the work is not extracting content but remapping the schema, asset references, and downstream integrations. All the major headless platforms expose enough API surface to extract content, so getting data out is rarely the hard part; reshaping it to fit a different system’s content model and rewiring everything connected to it is. This is a normal, budgetable engineering effort, and it is one reason the initial content-modeling decisions matter so much, since a clean model travels better than a messy one.

Leaving a locked AI builder is the harshest migration, because there is often nothing to migrate in a usable form. A no-code AI site that cannot be exported usually means rebuilding entirely on the new platform, since the content exists only as an arrangement inside the old vendor’s system. Even code-generation tools that export can leave you with code that does not run cleanly elsewhere because of its dependence on the platform’s services and runtime, turning a nominal export into a partial rebuild. This is the lock-in cost made concrete, and it is why the export question deserves so much weight before adopting an AI builder: the migration cost is effectively the cost of the original mistake, paid later and in full.

Migrating off WordPress is its own distinct effort shaped by the plugin model. The content is exportable, but recreating whatever plugins provided, the SEO configuration, forms, ecommerce, custom functionality, on the new platform is the real work, and a plugin-heavy site is harder to leave than a simple one. Moving from WordPress to headless, a common path as sites scale, means rebuilding the frontend and reimplementing bundled features as code, which is a substantial project but a well-trodden one. The accumulated SEO value, internal links, established URLs, and search history is the asset most at risk in any migration, which is why preserving URL structure and redirects is critical regardless of direction.

The strategic lessons from migration reach back into the original decision. Choosing an approach you can export from and own, like WordPress or open-source headless, keeps future migration a normal engineering project rather than a forced rebuild, while choosing a locked platform makes leaving expensive enough that you may stay longer than you should. Keeping content clean and well-structured, preserving the ability to extract it, and maintaining an exit plan, mirroring repositories and content for anything important, all lower the eventual cost. The businesses that migrate most painlessly are the ones that chose ownable, exportable approaches from the start and kept their content portable, and the ones that suffer most are those that optimized for initial convenience and found the door locked when they needed to leave, which is the recurring lesson of nearly every dimension in this comparison.

The hybrid reality most serious sites end up in

The cleanest insight about this whole comparison is that the three approaches are not as separate in practice as they appear in theory, and serious websites increasingly combine them rather than picking one in pure form. The future, and increasingly the present, is hybrid, and recognizing that resolves much of the apparent tension between the options.

WordPress itself can be run headless, blending two approaches into one. A WordPress backend can serve content through its API to a modern frontend framework, giving an organization WordPress’s familiar editorial experience and ecosystem with the performance and control of a decoupled frontend. This headless-WordPress pattern lets a business keep the content management it knows while gaining the speed and architecture of a custom build, and it is a common path for organizations that value WordPress’s editing experience but need better performance than a traditional WordPress site delivers. It is neither pure WordPress nor pure headless, and that is exactly the point.

AI generation is finding its most defensible role as one stage in a larger process rather than the whole process. The realistic use of AI builders for serious work is to compress the early hours, generating a starting point, scaffolding a prototype, producing first-draft components, which competent people then review, harden, and extend. This is how forward-looking teams use vibe-coding tools: as an accelerator inside a real engineering process that includes the security review and refinement the tools do not provide, rather than as a replacement for that process. The security record makes this the only responsible way to use AI generation for anything that carries real users or data, and it positions AI as a productivity layer on top of either WordPress or headless rather than a third path that excludes them.

The convergence is visible in the products themselves. 10Web uses AI to generate WordPress, combining AI speed with WordPress’s ecosystem and SEO; Figma’s acquisition of Payload points toward AI-assisted design flowing into a structured headless CMS; and WordPress 7.0’s AI layer brings generation and AI assistance inside the most traditional platform. The lines between the three approaches are blurring from every direction at once: traditional builders adding AI, AI tools adding the structure and SEO awareness that production needs, and headless platforms adding AI-assisted modeling and content operations. The neat three-way split is already a simplification, and it will be more of one as these threads continue to weave together.

The practical implication is liberating rather than confusing. A business does not have to choose one approach in pure form and live with all its trade-offs; it can use WordPress or headless as the durable foundation and AI tools to move faster within it, gaining speed without surrendering ownership, control, or security. The right mental model is not three competing options but a foundation decision, WordPress or headless for anything meant to last, paired with judicious use of AI generation to accelerate the work. Seen that way, the question stops being which of three platforms wins and becomes how to combine a sound, ownable foundation with the genuine speed AI now offers, which is a far more useful question and one that nearly every serious site is, in some form, already answering.

Each approach has a clear direction through the rest of the decade

Each of the three approaches is moving in a direction set by the forces already visible in 2026, and reading those trajectories matters more than any snapshot, because a website decision made now has to survive several years of change. The lines along which WordPress, headless, and AI generation are evolving are clear enough to plan around, even where the destinations remain uncertain.

WordPress is committing fully to becoming an AI-aware platform without abandoning what made it dominant. The release of 7.0 in May 2026, with its provider-agnostic AI client, Connectors API, and the admin redesign that DataViews represents, signals a platform absorbing AI as a native capability rather than treating it as a plugin afterthought. The roadmap points the same way: 7.1 around August and 7.2 near the end of 2026 carry the multilingual groundwork and the continued build-out of Gutenberg’s collaboration phase, while the AI tooling matures from a developer SDK into features ordinary editors touch. The strategy is to keep the open-source ownership and vast ecosystem that anchor WordPress while closing the gap on the AI-assisted editing that newer tools made table stakes. Whether the project can move fast enough is the open question, but the direction is unambiguous, and a platform running well over forty percent of the web tends to bend the market toward whatever it adopts.

Headless is heading toward the mainstream from two directions at once. The market’s projected climb from roughly four billion dollars in 2026 toward more than twenty billion by 2034 reflects an architecture moving out of the specialist corner and into ordinary commercial use, pulled there by the same multi-channel and performance pressures that created it. The developer-first camp keeps lowering the barrier, with open-source tools like Payload and Strapi making the model accessible to smaller teams, while Figma’s acquisition of Payload hints at design and content management converging in ways that could reshape how sites get built. The enterprise orchestrators continue moving upmarket toward governance and scale. The pattern is a category broadening its base while its top end specializes, which is the normal arc of a technology crossing from early adopters into the majority.

AI generation is splitting more sharply along the line that already divides it, and maturing unevenly on each side. The no-code builders are folding AI into mainstream website creation for non-technical users, a direction Wix made concrete by paying eighty million dollars for the six-month-old Base44, while the code-generation tools chase the harder goal of producing software people can trust. On the code side, the security record is forcing a reckoning that will define which tools survive: the ones that add real safeguards, the kind of system-prompt and guardrail work that followed the Lovable and Supabase exposures, will separate from those that keep shipping fast and insecure. The phrase coined in early 2025 became a dictionary word of the year by its end, but the practice has to grow past the exposure rates documented through 2025 and into 2026 before it can carry production work unsupervised, and that maturation, not the hype, is the trajectory that matters.

The deepest current running under all three is the shift in how websites get found, which is rewriting the rules faster than any single platform. AI Overviews appearing in around a quarter of searches, the collapse of position-one organic click-through from over seven percent toward under two, and Google’s confirmation that its AI answers rely on the same crawler as ordinary search together mean that crawlable, fast, well-structured sites win and client-side-rendered ones disappear from the surfaces that increasingly mediate discovery. This pressure rewards WordPress and properly built headless, both of which can render crawlable HTML, and it punishes the default output of most AI builders, which ship single-page applications that AI answer engines cannot read. As search becomes more agentic and answer-driven through the rest of the decade, the technical question of whether a machine can read your site moves from a specialist concern to a determinant of whether the site exists in the channels that matter, and every platform decision now carries that weight whether the buyer recognizes it or not.

Uncertainties the current evidence cannot resolve

Honesty about a fast-moving subject means marking the edges of what the evidence can support, because several of the most consequential questions about these approaches cannot be answered from 2026 data, and pretending otherwise would mislead more than it helps. The points below are genuinely open, and the responsible position is to hold them as uncertainties rather than to resolve them prematurely.

The first unsettled question is whether AI-generated code will get safe enough, fast enough, to change the calculus. The documented vulnerability rates through 2026, the studies finding flaws in the overwhelming majority of scanned vibe-coded applications, describe the present, not a fixed ceiling, and the tools are improving even as the warnings mount. It is possible that within a few years AI code generation paired with AI security review becomes trustworthy enough that the current caution looks dated. It is equally possible that the gap between generating code and securing it proves stubborn, and that human review remains the non-negotiable layer it is today. The evidence supports caution now; it cannot yet tell us which of these futures arrives, and anyone claiming certainty in either direction is guessing.

The second open question is how durable the GEO playbook will prove. The research establishing what makes content surface in AI answers, the citation and statistic patterns documented since the technique was named in 2024, captures a target that is still moving as the AI search engines themselves change their models and behavior. Whether the specific tactics that work in 2026 keep working, or whether the optimization surface shifts under everyone the way SEO has repeatedly, is unknowable from here. The structural advice, be crawlable, be fast, be well-structured, be citable, rests on the durable fact of how these systems retrieve and rank, and is likely to age well. The finer tactics may not, and treating today’s GEO specifics as permanent would repeat the mistake every SEO generation has made.

The third question is whether WordPress can stay central as the web’s center of gravity shifts. Its CMS share slipped below sixty percent in 2025 in the first decline of a decade, and its share of brand-new sites has fallen under half, even as its absolute dominance across all existing sites holds above forty percent. The AI investment in 7.0 and beyond is a bet that the platform can adapt to a changed environment and keep its position. Whether that bet pays off, whether WordPress remains the default a decade out or slowly cedes ground to newer architectures and AI-native tools, is one of the genuinely consequential open questions in this whole comparison, and the early-cohort numbers can be read as either a warning or a blip depending on assumptions the data does not resolve.

The fourth uncertainty is how the crowded markets consolidate. The headless space supports a long list of well-funded platforms, the AI builder field is raising and spending money at a pace the underlying revenue does not yet justify, and history says many of these tools will merge, pivot, or close before the decade ends. Which survive, which get acquired the way Payload and Base44 were, and which simply vanish will reshape the practical choices available to buyers, and a tool that looks like a safe bet in 2026 may not be maintained in 2030. This is the strongest argument for favoring ownership and exportability: when the market consolidates, the businesses that chose ownable, portable foundations adapt, while those locked into a vendor that does not survive face the migration they were trying to avoid, which returns the entire comparison to the single thread that runs through every dimension of it.

Common questions about choosing between WordPress, headless, and AI builders

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

W3Techs: Usage statistics and market share of WordPress Continuously updated technology survey tracking WordPress’s share of all websites and its position within the content management system market.

WordPress statistics 2026: Market share and data Compilation of 2026 figures on WordPress usage, plugin counts, performance, and the platform’s standing against competitors.

WordPress market share in 2026 Analysis of WordPress adoption across all sites and within the CMS category, with attention to recent shifts in its share.

WordPress market share statistics Overview of how much of the web runs on WordPress, including ecommerce share through WooCommerce and plugin ecosystem size.

WordPress market share is declining: 2026 data Developer-community discussion of the first dip in WordPress’s CMS share in a decade and its falling share of newly created sites.

WordPress 7.0 release overview Managed-hosting provider’s breakdown of the features in WordPress 7.0, including the AI client and admin interface changes.

Interactivity API, WordPress 7.0 beta, and Telex updates Community newsletter covering the 7.0 beta cycle, Gutenberg progress, and WordPress.com’s AI block and theme generation tooling.

WordPress 7.0 release guide Detailed guide to the AI infrastructure, Connectors and Abilities APIs, and DataViews redesign introduced in WordPress 7.0.

WordPress 7.0 AI infrastructure Official post describing the provider-agnostic AI client and the broader strategy of building AI capability into the platform.

WordPress 7.0 admin refresh, AI connectors, and new blocks Summary of the admin redesign, AI connector additions, and the block-level notes feature that shipped in place of real-time collaboration.

Payload is joining Figma Figma’s announcement of its acquisition of the open-source headless CMS Payload and the intended direction for the combined products.

Payload is joining Figma Payload’s own account of the Figma acquisition, including its commitment to remaining open source and the status of self-hosting.

When CMS meets UX design: what Figma’s Payload deal really means Industry analysis of the strategic implications of design tooling converging with structured content management.

Best headless CMS platforms in 2026 Comparison of leading headless content management systems, covering developer-first and enterprise-oriented options and their pricing.

Top headless CMS platforms 2026 Roundup of major headless platforms with attention to content modeling, querying, and editorial features.

Headless CMS 2026: Contentful vs Strapi vs Sanity vs Payload compared Side-by-side developer comparison of the four most discussed headless systems across architecture, licensing, and developer experience.

Contentful vs Sanity headless CMS comparison Feature and model comparison between two enterprise-oriented headless platforms, including pricing structure differences.

Headless CMS pricing guide Reference on the pricing tiers and billing models used across the major headless content platforms.

AI website builder comparison 2026 Comparison of no-code and code-generating AI website tools, covering output type, export options, and intended use cases.

Best AI website builders 2026 Overview of the leading AI site-building tools and where each fits between simple no-code creation and developer-oriented generation.

Best AI website builders Survey of AI website builders with attention to the divide between hosted no-code platforms and code-producing tools.

Lovable’s vibe-coding security crisis exposed Report on the security failures discovered in applications built with the Lovable AI coding platform and the underlying causes.

We scanned 1,072 vibe-coded apps: 98% had security flaws Security research documenting the rate and types of vulnerabilities found across more than a thousand AI-generated applications.

Common security risks in vibe-coded apps Cloud-security analysis of the recurring weaknesses in AI-generated applications and how they end up exposed.

Vibe-coded apps and the shadow-AI audit framework Coverage of the data-exposure problems in AI-built applications and the organizational risk they create.

How we discovered over 2,000 high-impact vulnerabilities in vibe-coding apps Methodology and findings from a large-scale scan of applications built on AI coding platforms.

Vibe-coded apps keep leaking user data Reporting on the pattern of AI-generated applications exposing user data, often through missing access controls.

The vibe-coding AI governance gap Research note on the governance and oversight problems raised by AI-generated code entering production.

What is generative engine optimization Explanation of GEO, how it differs from traditional SEO, and what makes content surface in AI-generated answers.

Generative engine optimization Overview of the techniques and content characteristics associated with appearing in AI search and answer engines.

Generative engine optimization Discussion of the research foundations of GEO and the measured effects of different optimization approaches on AI citations.

Answer engine optimization and GEO guide Practical guide to optimizing for AI answer engines, including the role of crawlable structure and citable content.