Website with or without a CMS? Security, Maintenance, Performance – and What AI Agents Change

Four builds compared directly

Behind “with or without a CMS” there are in practice four builds. For many smaller companies, one of the two in the middle is the best answer: the hosted system, or the static website with an editing interface.

• Self-hosted CMS: the software runs on your server and generates every page from a database, for example WordPress or TYPO3. You have full access, but you also carry the responsibility for updates and security.
• Hosted system: builders such as Wix and Squarespace and shop systems such as Shopify are content management systems too, only the provider runs the technology. You pay a subscription and work within its limits.
• Static website: finished HTML files, written by hand or built from text files with a generator such as Hugo, Astro or Eleventy. No program runs on the server, it only delivers files.
• Static with an editing interface: content is maintained in an interface and static pages are built from it – either through a headless CMS that outputs content only via an interface, or through a Git-based CMS such as Decap CMS, which stores changes directly as files in the code repository.

The table shows the real trade-off: a CMS shifts costs from the individual change into continuous operation. Every text change is cheap, but the website also costs maintenance when nobody changes anything for a year. With a static website it is the other way round.

Maintenance: what comes up regularly – and what happens when nobody looks

The biggest difference shows when nobody touches the website for a year: the static one keeps running unchanged, the CMS becomes more vulnerable with every month without updates. For a self-hosted CMS these tasks therefore belong firmly in the calendar:

• Install updates and check afterwards. WordPress updates the core automatically for new installations since version 5.6; for plugins and themes, automatic updates can be switched on individually since version 5.5. An automatic update can still break a layout – somebody has to look.
• Backups whose restore has been tested. A backup that has never been restored is an assumption. Restore it on a test environment once a quarter.
• Raise the PHP version of the hosting. WordPress recommends PHP 8.3 or newer and points out that the old minimum versions from PHP 7.4 have already reached their end of life. The switch can break older plugins and has to be tested.
• Check the external resources of your extensions. Themes and plugins like to load fonts or scripts from third-party servers. In 2022 the Regional Court of Munich awarded a visitor 100 € in damages because a website loaded Google Fonts from Google’s server without consent (case 3 O 17493/20). After every new plugin it is worth checking which connections the page opens.

With a static website, updates, database backups and PHP switches fall away, because no program code runs on the server that could age. Domain, certificate, accounts and embedded third-party scripts still need an occasional look. Maintenance shifts to the moment of the change: the generator, the Node version and the libraries the site is built with keep moving. Anyone who wants to change something after a two-year pause often has to repair the toolchain first, before the first sentence goes online. An AI agent can take that work on today, but it has to be planned for.

With hosted systems the provider handles the technology entirely. The price for that is the subscription, which rises with every additional feature, and the tie to that one provider.

AI agents and MCP: how an AI maintains your website, with and without a CMS

AI agents change the calculation from the comparison above in one fundamental way: they can carry out changes that previously required a person with technical knowledge. That makes the static website a real option for companies without a developer – and gives the CMS a new job as the rulebook that defines what an agent may do.

What MCP is and why it matters for your website

The Model Context Protocol (MCP) is an open standard through which AI applications work with other systems – with your CMS, Search Console or a shop, for example. Anthropic published it in late 2024 and in December 2025 handed it over to the Agentic AI Foundation under the Linux Foundation, which Anthropic founded together with OpenAI and Block. For you that means: a CMS with an MCP connection can be used by different AI assistants without a separate integration for each one.

With a CMS: the agent works through the interface

With a CMS the agent does not reach files or the database but the official interface – with the same rights as a human user. For that, WordPress has offered application passwords since version 5.6: they inherit the role of their user, can be revoked individually and are no use for logging into the back end. With WordPress 6.9 the Abilities API arrived in December 2025, through which WordPress and plugins describe which actions they offer. The official MCP Adapter plugin makes those actions usable for AI agents – and checks the user’s rights on every call. Hosted systems are following: Shopify provides MCP endpoints for catalogue, cart and checkout, where only approved agents may complete a purchase.

The advantage of this route: the CMS stores every version, and rights can be limited per user. That the agent only creates drafts, however, is something you have to set up yourself. The standard Editor role may publish and delete other people’s pages; the Contributor role may only create drafts but cannot upload images. What usually fits is a custom role that may write drafts and upload images but publishes nothing – via a role plugin or a few lines of code. This is exactly how MCP SEO works too: through the official interface of the CMS, without access to server or database.

Without a CMS: the agent works in the code

With a static website the agent changes the text files directly in the code repository. How far that carries today is shown by the IT company innFactory. According to its own account, it moved its WordPress website to the Hugo generator with Claude in under 48 hours in January 2026 – including redirects for all old URLs. The AI costs came to around 150 €. The team has maintained content as text files via GitHub ever since.

Approval here runs through the software development workflow. The agent works in a branch of its own, and hosts such as Cloudflare Pages or Netlify build a preview from it under its own address. Only when you accept the preview is the change merged and published. That works well as long as you really check the preview. Rights per section of the site, such as “may change blog posts but not the legal notice”, are not a given here. With GitHub they can be rebuilt through rules for file paths and code owners. Without such rules, approval before the merge is the only barrier.

A worked example: where agents fail at the interface

Having an interface does not mean an agent reaches everything through it. This website runs on WordPress with the Bricks page builder, and the guides are created as drafts through the REST interface – with a user account and application password of their own. While setting that workflow up in October 2026, three gaps turned up:

• Images: the MCP server in use sends all data as JSON, but the WordPress media interface expects a file transfer. Uploading was not possible that way – solved with a small plugin of my own that accepts images as JSON.
• Language versions: which language a post has and which translations belong together is managed by the Polylang plugin. In the free version running here, that is neither readable nor changeable through the interface; only Polylang Pro supplies those fields. Solved with an extra route in my own plugin.
• Page builder pages: Bricks stores the content of its pages in data fields of its own rather than in the regular content field. An agent editing the content field through the interface changes nothing visible on those pages.

Before deciding on a system, a theme or a builder, it is therefore worth testing exactly the tasks an agent is meant to take on later:

• Read pages and posts, create them as drafts and edit them
• Upload images, with alt text and file name
• Set title and meta description in the field of the SEO plugin
• Assign language versions and link them to each other
• Create redirects
• Limit rights per user and revoke access keys individually
• Trace every change with date and author

If one point fails, that is not a reason to rule the system out, but it is a cost item: somebody has to close the gap, or the task stays manual work. Anyone building new and planning AI maintenance is best off creating content in the standard blocks of the CMS – or checking beforehand where the chosen page builder stores its content.

Security with agents: rights, approval, hidden instructions

An agent with administrator rights is an administrator that can accept instructions from any text it reads. The OWASP list of the biggest risks for AI applications therefore puts prompt injection in first place: instructions hidden in web pages, files or form entries that change the model’s behaviour. If your agent reads comments or contact enquiries, those may contain “delete all pages”. OWASP recommends least privilege and human approval for risky actions, among other measures – and points out that there is no watertight protection. For your website that means:

• Least necessary rights: a separate user per agent with a role that may create drafts but not publish or delete. Installing plugins or creating users is never part of it.
• Approval before every publication by a human, with static websites through a protected main branch that nobody may write to directly.
• Revocable keys: set up the application password or repository token so that you can block it within a minute.

Switch or stay: when a move is worth it

Changing the build is only worth it for a concrete problem that cannot be solved in the existing system. Being unhappy with WordPress is not such a problem on its own – usually it is the theme, the builder or the missing maintenance. Good reasons for moving to a static website are:

• Maintenance costs more in the long run than the editing interface brings in, because hardly anyone changes content.
• The website has been attacked repeatedly despite updates.
• Loading speed stays poor after a thorough optimisation because the builder determines the markup.

Conversely, a move is a bad idea when several people on the team publish regularly. OpenProject moved from WordPress to a static website in 2021 and describes the price openly: editors have worked with Markdown and Git ever since, and a change takes up to 30 minutes to go live. For a website whose content rarely changes that was the right call – for a newsroom with daily posts it would be a brake.

There is often a middle way: stay in the CMS but replace the page builder with standard blocks. That can solve speed and agent problems without changing the editorial workflow.

Whoever moves risks rankings above all – not through the new technology but through changed addresses. Every old URL needs a 301 redirect to its new counterpart. The list for that comes from the old sitemap, the page report in Search Console and the pages with external links. Forms, the search function, language versions and the cookie banner have to be solved anew in the new build; they are the things most often missing after a move. How a move runs without losing rankings is covered under relaunch support.