Website CMS maintenance: how to keep your site in your own hands

The practice moves its Friday consultation hours to the morning. The website still shows the old time, and the staff on the phones wonder whom they should call. The web designer from back then has since changed careers, and emails no longer arrive. Nobody in the practice knows whether a login even exists or where it is kept. This scenario is invented, but the pattern behind it is not.

In situations like these, technology is rarely what stands in the way. What is missing is an answer to three simple questions: who may change what, where are the access credentials, and what happens if the service provider drops out? The system itself, whether site builder or CMS, is often perfectly fine. The problem is a business that had a website built without commissioning its upkeep.

That is why we look not only at the choice of a content management system but at the entire life cycle of a website: maintaining content, keeping software up to date, backing up data, monitoring hosting and, if need be, being able to switch cleanly. Anyone who understands “website CMS maintenance” as a single task makes better decisions than someone who merely picks a tool.

A typical starting picture in a small business looks like this: the website was built a few years ago by an external person, a login is on a slip of paper or in an old email, and changes are reported to the service provider by message. As long as he or she is reachable, it works. It is an arrangement that rests on goodwill and has no structure, and goodwill is a poor foundation for something that receives customers every day.

The first is usability. An editing system that the developer enjoys using is often a maze of menus, blocks and fields for the practice manager, where one wrong click breaks the layout. People who are afraid of the system do not maintain it, and an unmaintained site quietly goes out of date. Outdated opening hours, prices or contacts cost trust long before anyone notices.

The second is invisible maintenance. Security updates for the core, extensions and server software do not run by themselves. With a classic CMS with plugins, dependencies accumulate and go out of date one after another. A site builder takes this burden off you but ties you to one provider. Both routes are legitimate, yet both have costs that often disappear into the small print of quotes.

The third is ownership. If the agency registers the domain in its own name, the code sits in its repository and the hosting runs through its account, then at its core the business owns only the content. This is not malicious, just often solved for convenience. It only becomes a problem when you want or need to switch.

There is also a fourth, less tangible reason: nobody feels responsible. Management sees the website as a marketing matter, marketing sees it as a technical question, and the technical side sees it as the service provider's business. A named person in charge, with a deputy, solves more problems than any software decision. Without one, tasks stay undone until an incident makes them visible.

Site builders such as the big website services bundle editor, hosting, security and updates into one subscription. For a business with few pages and few special requests, this is often the calmest solution, because there is nothing you have to patch yourself. The limits show with custom structure, fine-tuning of performance and export: content can often be taken with you only to a limited extent or in unwieldy formats.

The classic CMS, in the German Mittelstand usually WordPress or a similar system with a plugin ecosystem, offers the widest choice of features and service providers. In return it demands operation: updates, backups, hosting, hardening. Well maintained, it is straightforward and inexpensive to move; unmaintained, it is the most common entry point for attacks, because vulnerabilities in old extensions are publicly documented.

Headless systems separate content from presentation. Editors work in the CMS, and the website is rendered by a separate application. This brings speed, clean structure and freedom of design. But it also brings two systems that have to work together, and usually a developer who is needed for every major change to the presentation. For a craft business with ten pages, this is rarely the right scale.

Our assessment is accordingly sober. Small, stable sites often belong in a site builder or a lean, carefully configured classic CMS. Headless pays off when several channels use the same content, when there are high performance requirements, or when a development team is involved anyway. The deciding factor is a clear answer to the question of how much operational work you are prepared to carry.

A feature table is misleading here, because almost every system gets almost every function somehow. We ask instead what will actually happen over the next three years: how often does content change, who changes it, how many page types are there, and who looks after the technology when things are quiet? The result is rarely the name of a system, but a profile against which systems can be tested.

The question of responsibility weighs particularly heavily. A system that requires maintenance by third parties has to actually commission those third parties. That means a maintenance contract with clear services, response times and a right to terminate, or an internally named person in charge. Forgetting both at once is the most common mistake.

Then there is the effort of switching. We estimate how expensive a move would be in five years and weigh that in. A site builder with poor export is cheap today and expensive later. An open system with a cleanly documented setup is more expensive today and calm later. Both decisions are defensible, as long as they are made deliberately.

One test step has proved its worth: before the choice is made, we play through a realistic editorial case. Create a new service page, swap an image, change a time, take a page offline again. Anyone who tries this with the person who will later do it learns more in an hour than from any product brochure. If the test is hard, the cause is the system or its setup, and both can still be changed beforehand.

Be wary of promises along the lines of “everything is easy”. What is easy is what a specific person does at their specific workstation without asking for help, not what looks good in a demo. We therefore assess usability using your own content, not the manufacturer's sample pages.

For a website with three people, a simple split is often enough: an administrator who is responsible for structure and technology, and editors who may change content but do not install extensions or touch settings. Anyone who may do everything can also destroy everything, usually without any bad intent. The principle of least privilege sounds strict, but it protects against the most common mishaps.

An editorial workflow does not have to be complex. What matters is that every change is assigned to a person and that there is one point that approves what is visible when legal matters, prices or medical statements are involved. In small businesses this means two pairs of eyes on a page, nothing more. Draft, preview, publication: every system should be able to keep these three states cleanly apart.

This includes a short, written guide. It describes which fields exist, how images are prepared, which wording to avoid, and what to do when in doubt. Two pages are enough. The guide relieves the person who would otherwise answer every question by phone, and it is the most important building block when staff change.

The design should also catch mistakes. Instead of free-form page builders in which every font size and every colour can be chosen, fixed building blocks work well: text block, image caption, service card, contact box. The editorial team fills in fields, the design stays consistent. This restricts and protects at the same time, because a page that still looks the way it did on day one after two years is rarely the result of discipline, but of sensible limits.

Updates are not a project but a rhythm. With a classic CMS you check the core, themes and extensions at fixed intervals, install them on a copy first and then live. Security updates should be installed promptly; for larger version jumps, a planned window is enough. Anyone who only reacts when something is broken pays considerably more later.

Fewer extensions mean less attack surface. Every plugin is someone else's code that has to be maintained. Before each installation we therefore check whether a function can also be solved without an add-on module, whether the module is actively developed and how many others use it. With site builders the provider takes over part of this work, but responsibility for access and passwords stays with you.

Backups follow a simple rule that has proved itself over the years: several copies, in separate places, regularly, and above all tested. A backup that has never been restored is a hope. We define how often backups are made, how long versions are kept and who can trigger a restore. Part of the test is actually starting the copy in a separate environment.

Added to this are small watchdogs: availability monitoring, a notice about expiring certificates, a notification of failed logins. They do not prevent attacks, but they make sure you learn about problems before your customers do.

With hosting, concrete questions matter more than marketing terms: where are the servers, how long are backups retained, how quickly does support respond, and can an older software version continue to run for a while? Cheap mass hosting is often enough for simple sites but becomes tight when several sites, many forms or bookings are running. Switching host is feasible if backups and documentation are in order.

Passwords are the most common way into a system, and it is a banal one. A password manager, individual accounts and two-factor login remove most realistic risks without needing a security project. In addition, you should not leave the CMS login page unprotected against constant bombardment by automated attempts, and you should remove unused accounts regularly.

Domain, hosting contract, code, design files and accounts for analytics, maps or newsletters belong in the business's name, with an email address that is not tied to a single person. This can be set up in an hour and saves weeks later. We consider it the most important measure of all, even if it seems the least spectacular.

The code also raises the question of usage rights. What you have paid for you may use, but to what extent, whether it can be modified, whether it can be passed on is governed by the contract. For third-party components such as themes or extensions, their licences apply. We are deliberately cautious here: this is guidance, not legal advice, and for binding statements a contract with clear rules should be on the table, legally reviewed if necessary.

In practice a simple handover document helps: a list of all accounts with holder, purpose and person responsible, without plain-text passwords, which are kept in a password manager. Add a description of the setup, the maintenance routines and the recovery procedure. It is the insurance against the call that sits unanswered for three weeks, and it is the first thing a new service provider needs when you switch.

The service provider drops out, the hosting is cancelled, a site builder changes its plans, or the site is hacked. Each of these cases is conceivable, none is exotic. An exit scenario therefore describes in advance what to do in such a situation, who does it and how long it takes. It does not have to be perfect, but it has to exist.

In the event of a compromise a fixed order applies: put the site into maintenance mode, change access credentials, restore a clean version from a backup, find the cause, bring updates up to date, and only then release it again. With a site builder the path stays shorter because the provider carries part of it; with a classic CMS it depends on your preparation. Anyone who has reused passwords cleans up there first.

When switching service providers, what counts is whether the content is available in a readable format. Images and texts are quickly copied; harder are redirects, SEO settings and form destinations, which are easily lost in a move. We recommend recording the list of existing addresses before a switch so that no page is unintentionally dropped after the move.

A special case is businesses with several people and changing staff. Accounts of departed employees should be blocked on their last working day, not weeks later. This also applies to accounts with third-party services that a website uses only indirectly, such as booking tools or maps.

The benefit of a well-maintained website shows first in small things. Changes are published the same day instead of weeks later, and nobody has to ask for help to change a phone number. This can be measured simply: time between trigger and publication, number of open change requests, age of the most recently reviewed page. These are figures from your own business, not other people's benchmarks.

On the technical side, a check of update levels, a documented restore and monitoring alerts help. Search Console also shows whether errors such as unreachable pages appear. Loading time and stability can be tracked with PageSpeed Insights and a look at response times. Statements about how this affects enquiries or rankings would be speculation.

What cannot be promised should be put openly on the table. No system is invulnerable, no backup replaces care with passwords, and no hosting guarantees uninterrupted availability. Costs cannot be named in general terms either: they depend on the system, the effort and the service provider. What is honest is a range after an initial review, not before.

An example of how to read the figures: if it regularly takes several days after a trigger for a change to go online, the bottleneck is usually responsibility, not the system. If the restore test shows gaps, such as missing media files, that is a good find, because it comes before an emergency. Such observations are the real yield of regular maintenance.

A website that the business can maintain itself is less a question of system than of organisation. The best CMS is of little use if roles are unclear, updates are left undone and nobody knows where the domain is registered. Conversely, a simple site builder goes a long way if responsibilities, backups and ownership are settled. The technology is interchangeable, the order is not.

Your first step costs nothing. Make a list: domain, hosting, CMS or site builder, newsletter, analytics, maps, booking, each with holder, access and person responsible. Check whether someone in-house could log in and change an opening time. If an answer is missing, you have found your most important task before you have even requested a quote.

We are happy to help with the assessment, with a look at your existing system, an honest view on whether staying or switching makes more sense, and a maintenance concept that fits your size. A maintenance contract is an option here, not an obligation. What matters is that you know at all times where your site is and who may touch it.

Two principles remain from this look. First: choose the system according to the maintenance effort you can actually bear, not the range of features you might one day need. Second: write down what has so far been in one person's head. Both cost little and prevent a website from becoming a dependency that you only notice in an emergency.