Does your website still need a CMS? What LLMs and MCP really change

In our initial calls, the same question now comes up regularly: «If AI writes and publishes my content, why do I still need a content management system?» It is a fair question. A language model can rewrite a page today, translate it into German and deliver the code for it in one go.

My answer has two parts. Small websites don't necessarily need a CMS. An LLM client serves them very well. Large websites want to keep their CMS: for compliance and for sovereignty. Between the two runs a line you can draw yourself with a handful of criteria.

In this article we first define the terms. Then I walk you through both worlds and their limits, explain the role of MCP and give you a table to place your own website. Finally, I tell you what we recommend to which audience.

Three terms carry this article. Here is the short version:

The key distinction is between operation and responsibility. A CMS has always done both: it makes content editable without programming skills, and it records who approved what and when.

The LLM client takes over the operation. It writes, translates and publishes. It does not take over responsibility. That decides whether you need a CMS: the more responsibility you have to organise, the more the system behind it matters.

Take the typical case: a craft business, a law firm or a consultancy with eight to fifteen pages. One person maintains the content, and changes happen four to six times a year. For exactly these websites, a CMS was always a heavy backpack: logins, plugin updates, security holes and an interface you forget between two edits.

The content lives as text files in the website's code repository, in other words in Git. Your LLM client is connected to that repository. The process has four steps:

The result: no CMS licence, no admin login that can be attacked, no plugin maintenance. Git provides the version history at no extra cost. Translations and simple accessibility checks, such as missing alt text, are handled by the client in the same pass if you ask for them.

For this to work, you need a one-off setup. It is smaller than setting up a CMS, but it is manual work:

For a small website we budget one to two working days for this. After that, you maintain the website in the same application you already use for AI work.

To be completely honest: this model has limits too. First, it stands or falls with the setup above. Without a separation of text and layout, the client can easily change the page grid while swapping a phone number.

Second, the preview remains mandatory. If you merge changes unseen, sooner or later you will publish an invented sentence. Third, the model ends as soon as several people with different permissions maintain content. A repository knows write access to code, but no permissions for individual content and no editorial approval stages.

The bottom line for small websites: the best CMS is none at all, as long as a human checks the preview.

Now to the other end: a mid-sized company with 300 pages in three languages, product data from the ERP, a legal department and twelve people from marketing, sales and HR who maintain content. Here the calculation flips. Not because AI writes worse, but because the organisation around it has rules.

In large organisations no text goes live without approval. Product management checks product claims, sales checks prices, legal checks legal texts. A CMS maps these stages and records who approved what. A chat history does not.

Since 2 August 2026 there is another reason: Article 50(4) of the EU AI Act requires disclosure when AI-generated text informs the public on matters of public interest. The obligation does not apply if a human has reviewed the text and someone holds editorial responsibility.

For most product pages, the rule is unlikely to apply. For press releases, expert articles or public statements, it can. If you ever need to prove the human review, you need a system that records it. That is exactly what a CMS with a defined approval process does. Read more in our article on the EU AI Act for software buyers.

HR may edit job ads but not prices. The agency may create drafts but not publish anything. Such permissions belong to the content, not to access to the code. A repository that twelve people plus their AI agents can write to is a security risk, not an editorial system.

Large websites rarely show text alone. Product data comes from the ERP or PIM, job ads from the applicant tracking system, contacts from the CRM. This data flows daily and automatically, not on request in a chat.

A CMS is the hub where these streams meet and are combined with editorial text. We show what that looks like in connecting Sanity to ERP and PIM. An LLM client that edits files in a repository does not replace this hub.

The third reason is often underestimated. Sovereignty means three things here: you decide where your content lives. You decide who can access it. And you can switch AI vendors without moving your content.

A CMS with structured content is the layer that exists independently of the language model. Today Claude writes into it, tomorrow a European model, the day after your own. If you take data sovereignty seriously, you even run the CMS yourself, for example Payload on your own servers in the EU. The point: the model is replaceable, your content must not be.

The good news for large websites: you don't have to choose between CMS and AI. MCP makes sure the agent works inside the CMS instead of around it. The major vendors now offer their own connections:

What matters is which permissions the agent works with. For remote servers, the MCP specification describes authorisation via OAuth 2.1. Once it is in place, the agent acts with the permissions of the person using it. If an editor may only create drafts, their agent may only create drafts too.

An MCP server is connected quickly. The questions behind it take a little longer. We settle four of them in every project before an agent writes into the CMS:

This is also how we work on our own website: an agent creates drafts through the Sanity API, a human proofreads and approves. The CMS remains the authoritative source, and AI becomes the fastest editor on the team.

To help you decide, I have collected the criteria that tip the balance in our projects. Read the table row by row: the more hits in the right-hand column, the more clearly you need a CMS.

A rule of thumb from our practice: with up to two hits on the right, an LLM client and Git serve you well. From three hits on, a CMS pays off, ideally one with cleanly modelled content and an MCP connection.

Costs follow the same line. A brochure website costs from €9,000 with us. An SME website with a headless CMS, multiple languages and integrations costs from €24,000. You will find the details on our B2B website page.

And the middle ground? A headless CMS such as Sanity is worthwhile even for smaller teams if the website is clearly going to grow. Moving from a repository to a CMS later is possible, but it means rework. If you have two hits today and expect five in a year, start with a CMS right away.

The table above helps you assess your own situation. Here is our own position on top: what do we advise each type of company if it asks us today? These recommendations are based on the projects we have built and maintained in recent years.

We see two setups regularly, and we advise against both:

Our position comes down to one sentence: the question is no longer «CMS or no CMS», but «who carries the responsibility, and where is it recorded?»

The CMS is not dying. It only loses its mandatory role for small websites. For large websites it becomes more important: as the home for approvals, permissions and data sovereignty, with AI agents docking on via MCP.

If you want to know which side of the line your website is on, let's go through it together. In 30 minutes you will know whether you need a CMS and which one fits your team. Book a no-obligation video call here.