When the CMS Takes More Work Than the Website
Gerhard G. StocKinger · Published on June 24, 2026
Many company websites are updated only on an ad hoc basis: a new offer, an event, a case study, or an updated contact person. Nevertheless, a full-fledged content management system runs in the background—with updates, enhancements, user access, backups, and dependencies.
Especially for simple websites, I prefer to avoid large CMS systems: These days, their maintenance can often be organized in a more streamlined and straightforward way. For one client, I therefore fully backed up the existing website, redeployed it as a lean, static site, and set up future maintenance so that changes can be implemented in a controlled manner and with GPT support on demand.
The problem isn't a single CMS
Regular news reports about security vulnerabilities, updates, and conflicts in widely used web systems serve as a constant reminder: Anyone who runs a website also assumes responsibility for its technical infrastructure. This is not a criticism of WordPress or any other CMS. For news portals, online stores, many editorial teams, member areas, or complex integrations, these systems make sense and are often the right choice.
However, with a simple corporate website that is rarely updated, the balance can shift. In that case, the CMS itself becomes the largest running system—even though the actual website consists of a manageable number of pages, images, contact options, and only a few changes per year. With every update, plugin, and technical intervention, you become dependent on an operational model that is larger than the task at hand.
The Real-World Example: Preserving Content, Streamlining Operations
The scope of work was deliberately worded in a straightforward manner: The existing website was to be preserved in its entirety, its content was to be permanently archived in a traceable manner, and future updates were to be possible without an editorial backend. At the same time, URLs, searchability, contact options, and the familiar layout were not to be lost.
The solution wasn't simply to download a website and forget about the rest. A website is more than just its visible pages. That's why we first took stock of the content, images, downloads, page titles, descriptions, redirects, and necessary features.
From a CMS to a Version-Controlled Website
- Take stock: Which URLs, content, media, forms, downloads, and search signals need to be preserved?
- Freeze the website: Pages and assets are saved in a traceable source code repository; the published version remains reproducible.
- Static Delivery: The public-facing site is served as a lightweight HTML, CSS, and JavaScript output. This significantly reduces the attack surface.
- Targeted replacement of features: Contact forms, tracking, and external services remain only where they are truly needed—with clearly defined responsibilities.
- Check first, then take it offline: Links, redirects, metadata, forms, and layout are all verified before the existing CMS is taken offline.
On-Demand GPT—But With a Robust Workflow
“Please add this feature,” “update the date,” or “create a new subpage from this text” are useful instructions for a GPT-based maintenance process. The model can use these to prepare structured changes to the source code: text, page components, metadata, and internal links.
The key is the operating rule: GPT does not work directly and without verification on the live website. Every change goes through a preview, link and structure checks, and human approval. Only then is a new, versioned version published. This way, AI acts as a catalyst for content maintenance—not as an uncontrolled administrator.
What is gained as a result
- The previous website will be preserved as an archived version.
- A simple website no longer requires a CMS infrastructure that runs continuously.
- Changes can be requested in everyday language and implemented in a controlled manner.
- Reliance on plugins, editorial access, and routine updates is decreasing.
- Every published change can be traced back to a specific version.
My Own Website: TYPO3 and Codex
This classification does not mean a complete departure from CMS. My own websites have been running on TYPO3 for more than 20 years. For larger websites with a lot of content, structured processes, and ongoing development, a powerful CMS remains the right tool.
Here, too, AI has changed the way we work: The recent upgrade from TYPO3 13 to TYPO3 14 implemented Codex as an AI-powered coding agent. The subsequent redesign was also carried out using Codex—based on a visual proposal from ChatGPT. AI can thus both maintain a lean website without a CMS and support the further development of a sophisticated CMS project. The key factor is which operating model suits the respective website.
When a CMS Is Still the Better Choice
A CMS remains a sensible choice when many people publish content independently, content changes very frequently, editorial approvals need to be tracked within the system, or e-commerce, login, booking, and data functions are part of the business model. So the question isn’t “CMS or AI?” but rather: Which operating model best fits the actual pace of change and the website’s functions?
For a small, clean website, the answer today can be surprisingly simple: Back up content properly, serve the essentials as static pages, and publish changes that have been prepared, reviewed, and tracked using AI.