For twenty years the answer to "how do I make a website?" was almost always the same: WordPress. It was the de facto standard, the obvious starting point for anyone, from freelancer to major publisher. Today that answer is no longer a given. Not because WordPress has become ugly or useless, but because something has changed upstream: artificial intelligence has learned to write production-quality code, and this shifts the center of gravity of what makes sense to do and who it makes sense to rely on.

The interesting question isn't "is WordPress dead?" — it's a provocation you read everywhere but that oversimplifies. The real question is more subtle: if an assistant like Claude can build you a custom site in a few hours, what becomes of the CMS? And above all, who will manage that site after launch? Because it's there, in daily management, that the real game is played.

In this article we try to bring order. We look at real numbers, compare three concrete approaches, and then put our cards on the table: we say openly which approach we choose today for our projects, and why. It isn't a neutral comparison disguised as objectivity — it's our position, argued. The question we care about most, because every client asks it, is twofold: can a person without technical skills really manage a modern setup without breaking everything? And who keeps the site alive when the agency is no longer there? We'll also use as supporting examples two projects we built directly — the new bryan.it and iainazienda.it — because talking about things done is worth more than a thousand theoretical schemas.

The real scenario: WordPress still dominates, but for the first time it's creaking

Let's start with facts, because it's easy to get swept up in the "everything is changing" narrative. WordPress, in mid-2026, still powers about 41-43% of all websites in the world and holds nearly 60% of the CMS market: a dominant position no competitor comes close to threatening (w3techs, Barn2). Those who say WordPress is finished are exaggerating, and by a lot.

But — and this is the new data point — for the first time after years of uninterrupted growth, the share has stopped rising. It went from 43.2% in December 2025 to 41.9% at the end of May 2026, a small but significant drop precisely because it reverses a trend that had been going since 2017 (Sketchweb). It's not a collapse: it's the signal that the mental monopoly of "you just do it with WordPress" is cracking. And it cracks precisely as two alternatives emerge that until recently were reserved for teams with in-house developers: headless CMSs and AI-generated sites.

Three approaches on the table (not two)

The debate is often told as a two-way clash, old versus new. In reality, today there are three viable paths, and they do different things.

1. The traditional approach — WordPress (or Wix, Squarespace). A "monolithic" system: content management and graphic presentation live in the same place, tightly coupled. You install themes and plugins, and the site is ready. It's the model we all know.

2. The modern headless approach — a CMS like Sanity + a frontend on Vercel. Here the content backend is completely separated from the frontend. Sanity stores content as "pure data" in a central repository, and the frontend (built with frameworks like Next.js and published on Vercel) retrieves it via API and displays it as it likes (Pagepro). Content becomes reusable across multiple channels (site, app, newsletter) because it isn't "glued" to a specific layout.

3. The AI-native approach — a site built from scratch with an assistant like Claude. Here you don't start from a pre-packaged theme: you describe what you want and the AI writes the custom code for the site, clean and without the ballast of dozens of plugins. It's the most recent approach, and it's the one making the most noise.

Let's clear up a fundamental misunderstanding right away, because it's the heart of your question.

Can Claude be "the CMS"? Distinguishing between building and managing

Here we need a sharp distinction, because two different things are being confused.

A CMS — Content Management System — is first of all an editing interface: a panel where a person, perhaps not technical, writes an article, changes a price, adds a page without touching code. The question, then, isn't really "is Claude a CMS?" — it's "what is the best editing interface, a form-based panel or natural-language instructions?".

And here a common misunderstanding must be corrected, because it's the point that changes everything. It's often said that Claude "is for building, not for managing." False, or at least too reductive. If you tell Claude "create a new page with these contents," or "modify this page, move this block higher, that one lower, and add a section with this text," you get the result — and often faster than it would take you to find the right field in a CMS panel. Claude isn't just the developer who builds the site: it's also a natural-language editing interface, and on everything structural or layout-related — precisely the things where CMSs are more cumbersome — it's almost unbeatable.

The honest distinction, then, isn't "panel yes, AI no." It's which model is best, based on three variables: how many people are editing, how often, and what kind of changes they make.

  • The traditional panel (CMS) wins when you have many non-technical editors working in parallel, micro-changes at very high frequency, need for instant self-service preview, and fine-grained permission management. It's the case of editorial newsrooms, large marketing teams, catalogs that change every hour.
  • Editing via Claude wins when you're an owner-operator or a small team, changes have medium-low frequency, and are often structural. The honest caveat: there's a publishing cycle (versions, preview, deploy) and someone comfortable directing the AI is needed — but "knowing how to describe what you want" is a much lower bar than "learning a CMS."

From here two practical strategies emerge, both valid:

  • AI to build + lightweight CMS to manage. Claude builds the site and connects a headless CMS (like Sanity) as a daily panel for those who publish. It's the hybrid approach of bryan.it, suitable when multiple people work on content.
  • AI to build and to modify directly. You skip the traditional CMS and go back to Claude for every update, even entire pages. It works great for projects that are more "product" than "editorial," where one or two people handle everything.

A note of realism on "multi-platform" headless, since that's its main selling argument. The promise — write once, distribute everywhere: web, app, smartwatch, IoT — is real but for a minority of cases: big brands with really multiple channels to feed. For the vast majority of projects, headless means one site only, and therefore it's effectively "a different and better CMS" — not the brochure omnichannel. Not only that: as soon as an editor wants control over layout, you end up adding fields that are presentation disguised as content (spacing, "show only on mobile," background variant, block order). These are fields that only make sense for that specific frontend and pollute the purity of "structured and reusable content." So much so that the industry had to invent visual editors precisely to patch this hole, a sign that the problem is real (Prismic, dotCMS). When the data model didn't plan for drag-and-drop, you have to redo the schemas and add presentation metadata — and there the theory of "clean separation" crumbles. Moral: headless has real advantages, but they should be sought in performance and security, not in the multichannel myth that most sites will never use.

Interestingly, the WordPress world itself is moving toward conversational editing: WordPress.com released a plugin in February 2026 that turns a conversation with Claude into a complete WordPress site, generating block themes and publishing them (WordPress.com). A sign that the fracture isn't "AI vs WordPress," but "AI rewriting the rules for everyone."

What if the site were simply static HTML? Security that disappears

There's a technical corollary that deserves its own paragraph, because it solves a mountain of problems at once: thinking in terms of static HTML pages. Most vulnerabilities of a traditional site arise from three things: a database to query, code executed on the server at every request, and a login panel to protect. A static site has none of the three. There's no database to violate with SQL injection, there's no PHP running on the server to exploit, there's no /wp-admin page to bombard with access attempts. The attack surface is drastically reduced because, quite simply, there's almost nothing to attack: there are only files served by a CDN.

It's exactly the logic of the Jamstack architecture: pre-rendered files served by a global distribution network, without queries or server-side execution on every page (Naturaily). The advantage is twofold — security and speed — and marries perfectly with the AI approach: Claude generates the pages, they get published as static, and what's left to "protect" is minimized. The dynamic features that are really needed (a form, a payment, a search) are delegated to specialized external services that are already hardened, instead of keeping an entire vulnerable stack in-house. For very many showcase sites, portfolios, landing pages, and blogs, this is simply the safest possible setup — and the cheapest to maintain, because there's no server to update every week to close holes. The limit, of course, exists: when the application logic becomes really complex and stateful (private areas, elaborate e-commerce, management systems), "pure static" isn't enough anymore and dynamic parts are needed — but even there the approach remains "static where you can, dynamic only where you must."

The pros and cons (and where we stand)

Let's put our cards on the table right away: for most projects that come to us today we choose the AI approach — alone, or paired with a lightweight headless. Not because it's trendy, but for the concrete reasons we explain below. That said, WordPress remains the right choice in some scenarios, and we say so with the same candor. Here are the three approaches with real pros and cons, and where we stand.

The traditional approach (WordPress)

The advantages remain enormous and explain why it still dominates. The plugin ecosystem is boundless: a non-developer can add e-commerce, SEO, forms, and complex features without writing a line (Cinute). There's a huge community, you can find anyone who knows how to work on it, and for certain scenarios — large editorial sites with thousands of pages and many editors, or WooCommerce stores with complex catalogs and already tested integrations — the workflow is hard to beat (Recursion).

The cons are the flip side of the same coin. The monolithic architecture executes PHP code and queries the database on every load, with possible performance issues. Above all, the plugins that provide all that convenience bring with them technical bloat, conflicts, and a wide attack surface that requires continuous updates for security reasons (Pagepro). In practice: you start fast, but maintenance becomes a permanent cost.

The modern headless approach (Sanity + Vercel)

The advantages are performance and security. Pre-rendered files served from a global CDN load almost instantly, without database queries on every page (Naturaily). Security is centralized and the attack surface is reduced, because the CMS doesn't serve the site directly. Content management is designed for teamwork: real-time collaboration, version history, structured content reusable across multiple channels (Sanity). The backend maintenance load is much lower, because it's handled by the vendor.

The cons: it requires more initial setup and, historically, development skills. The recurring phrase in comparisons between the two worlds is precisely this: WordPress wins when you want advanced features, ease of use, and reasonable costs; Sanity wins when you have strong developers and need deep control over structured, multichannel content (Pagepro). The price, moreover, scales with API usage and number of users. It's precisely on this "requires developers" that AI changes the game.

The AI-native approach (site built by Claude)

The advantages are seductive: custom design for your brand, clean code without bloat, SEO and structured markup taken care of from the start, and elimination of the entire classic burden — logins to protect, plugins to update, vulnerabilities to chase (Recursion). A consulting firm reported having replaced its WordPress site with an AI version in 48 hours (innFactory). And on the frontend side the ecosystem is accelerating: Vercel has pushed hard on v0, its generative UI tool (Naturaily).

The cons must be taken seriously, because they are the ones less talked about in enthusiastic posts. The main risk is maintainability: AI tends to prefer "it works" over "it's maintainable," and over time you can lose track of business logic, with technical debt accumulating if nobody governs the process (Jellyfish). Then there's the topic of lock-in and dependency on a platform: it applies to any service, but it must be factored in. The practical rule is simple: an AI-generated site isn't "set it and forget it," it needs someone — human or well-directed AI — to remain responsible for it.

The question that really matters: can a non-technical person handle it?

It's the right question, because most site owners don't write code and don't want to learn. The answer is encouraging but has conditions.

On the content management front, modern headless CMSs are no longer exclusive developer territory. Once the developer (or AI) has set up the structure, the editor of a CMS like Sanity is designed precisely so that whoever creates content can generate as many landing pages as they want on their own, autonomously, without waiting for the dev queue (Naturaily). The tricky point isn't writing an article — that's easy — but making structural changes without causing trouble.

Not surprisingly, in this area it's been observed how introducing AI into design systems, paired with structured tokens, drastically reduces manual maintenance work and the so-called "design drift": UXPin reports up to an 82% reduction in design-related technical debt (UXPin, Parallel).

The condition, though, exists: this peace of mind isn't automatic, it's designed. Someone must have set up the design system well, separated what the editor can touch from what's locked, and defined a minimum of governance. Once this upstream work is done — and it's exactly the kind of work at which AI excels today — daily management becomes within reach of anyone who knows how to use a web panel.

Two concrete cases: how we worked

Theory is better understood with real examples, and we have two that illustrate the two models above.

bryan.it — the hybrid model (Vercel + Sanity, AI as collaborator). For the new site we started from frontend layouts designed with Gemini, then asked Claude to handle the CMS blocks and all the rest of the implementation, on a Vercel + Sanity stack. It's exactly the "manual" headless architecture described above — fast frontend on Vercel, structured content on Sanity — but with a substantial difference: the part that historically required senior developers (connecting blocks, structuring the content schema, making frontend and CMS talk to each other) was orchestrated with AI. The result is a site with the benefits of headless — performance, security, reusable content — but built without the cost and time of a traditional dev team. And, once up, content is managed from the Sanity panel without touching code.

There's also an aspect that turned out to be decisive during the work, and it's perhaps the least-told advantage of all: we also used Claude to populate the CMS. Instead of sitting down to do data entry block by block — manually inserting dozens of pages, sections, and fields, a mechanical drudgery that eats hours — we asked Claude to do the imports and create the blocks directly. This flips a classic objection to headless: "sure, but then someone has to fill it, and filling it is deadly boring." With AI, that bottleneck largely disappears. It's not just that Claude builds the container: it fills it, turning data entry from repetitive human work into an operation you describe once and delegate. It's a point that applies to any CMS — traditional or headless — because the effort of initial population (and content migration from an old site) is universal, and it's exactly the kind of task where AI excels.

iainazienda.it — the full AI-native model. Here we went further: everything developed from scratch with Claude, including two notoriously complex parts like elearning and course e-commerce. These are precisely the scenarios that according to the common story "require WordPress + WooCommerce + LMS plugins": product catalog, purchase management, delivery of training content. Having built them custom means no plugins to update, no inherited vulnerabilities, and functionality that does exactly what's needed instead of adapting to what a generic plugin allows. It's the case that concretely demonstrates the thesis of those who argue that AI can replace complex stacks — with the caveat, true for all, that a system like this must be overseen over time.

The two projects, taken together, illustrate the range well: bryan.it shows that AI can lower the barrier of professional headless; iainazienda.it shows that it can replace traditional stacks even for complex features.

Who maintains the site when the agency isn't there?

It's the question every client asks, sooner or later, and usually in a low voice: "if you build me a custom site, do I stay tied to you forever?". It's a legitimate concern, and the honest answer changes quite a bit depending on the approach.

Let's start by debunking a myth: maintenance never disappears entirely, for any site. With WordPress, in fact, it's a permanent and often underestimated cost — updates to the core, themes, and dozens of plugins, security patches to apply quickly when a hole is discovered, conflicts after every update. If you don't do it, you pay someone to do it; if no one does it, sooner or later the site gets breached. The "freedom" of DIY is largely apparent, because the load stays there, every month.

With the hybrid model of bryan.it (Vercel + Sanity), daily management is in the client's hands, without us and without code: content is published and modified from the Sanity panel like any CMS. The actual technical updates are much rarer and lighter than on WordPress, because there's no plugin merry-go-round and the attack surface is reduced. And above all: the stack is standard and widespread (Next.js, Sanity, Vercel), not a proprietary black box. The code is the client's; any developer can pick it up. You're not held hostage by us.

With the AI-native model of iainazienda.it the same principle applies, reinforced by a detail that changes the rules: the code is clean, documented, and standard, so any developer can maintain it — but also the same AI that built it. For many changes you don't even need a technician: you describe the change to Claude ("change this price," "add a page," "move this section") and you get it. In other words, the client no longer chooses between "I depend on the agency" and "I learn to code": they can direct the AI, or rely on whoever they prefer to do it. The agency becomes a choice, not a chain.

There's then a structural advantage that reduces the problem at the source: a static site served from CDN doesn't have a server to update every week or a login panel to defend. It keeps working even if no one touches it for months. What we concretely do at handover is exactly this: we transfer repository and access, we leave the project documented, and we make sure the site stands on its own. If then the client wants to continue with us, it's because it's convenient — not because they can't do without us.

The only caveat, valid for any approach: "set and forget" doesn't exist. Someone must remain responsible over time. The difference is that, with the AI approach, the bar for being that someone is much lower than before.

Who's talking about it online

It's not a niche debate: it's discussed a lot, and there's citable material. The provocation "WordPress is dead" is by now a genre of its own — Recursion uses it to argue why AI is replacing traditional CMSs in 2026 (Recursion), while innFactory documented its own 48-hour migration (innFactory). On the opposite front, developers of the WordPress ecosystem like Jonathan Bossenger describe how they built custom block themes using Claude (Bossenger) — proof that the line isn't "AI vs the old world," but AI entering all workflows. The Sanity vs WordPress, traditional vs headless comparison is by now a classic with in-depth guides (Pagepro, Kevin Saffer). And WordPress.com itself publishing a plugin to build sites with Claude is perhaps the most eloquent signal of all (WordPress.com).

So what to choose?

No absolute truths, but a practical compass.

If you have a large editorial site with many editors and thousands of pages, or a very standard e-commerce where WooCommerce and its plugins already do everything, WordPress remains a sensible choice: its strength is the ecosystem and the tested editorial workflow.

If you need a fast, secure site with content reusable across multiple channels, and you want the benefits of headless without paying for a full dev team, the AI + headless (Vercel + Sanity) model of bryan.it is probably the best balance point today: technical barrier torn down, daily management within reach of those who don't write code.

If you have a custom project with specific features — a web app, a training platform, an e-commerce with particular logic — and no off-the-shelf plugin convinces you, the AI-native model of iainazienda.it gives you exactly what you need, provided you factor in that someone (or a well-directed AI) remains responsible over time.

The real change isn't that WordPress is dying — it isn't. It's that, for the first time, the more powerful alternatives are no longer the exclusive preserve of those with in-house developers. AI hasn't so much invented a new way to make sites: it removed the barrier that kept most people away from the better ways that already existed. And this, for anyone who has to decide how to build their online presence, is a story worth telling.

Sources