A neglected site does not break down overnight. It degrades slowly, and you find out at the moment when bringing it back up to standard costs more than the upkeep you avoided.
The sentence comes up often: “the site is running, we do not touch it”. It is reassuring and it describes exactly the situation that produces unpleasant surprises. A site is not an inert object: it depends on a software base that moves, on extensions maintained by third parties, and on a server permanently exposed.
A site does not break down, it degrades
That is the difference that explains why the subject is badly handled. A breakdown is visible, so it gets dealt with. A degradation triggers no alert: it advances a point a month, nobody notices, and it is discovered at the moment it has become a redesign.
Four degradations happen in parallel, and each is unremarkable taken on its own.
The images added along the way
Every publication adds images, often uploaded as they are from a camera or a stock library. They display correctly, so nothing signals the problem. Page weight rises, display speed falls, and the effect shows first on mobile, which is to say on most visitors.
The third-party scripts that accumulate
A measurement tool added for one campaign, a chat module tried and then forgotten, an advertising pixel installed by an agency that is no longer around. Each adds a request and some execution time. After three years, a site often carries a dozen of them whose purpose nobody knows any more.
The extensions that age
An extension left un-updated keeps working, which is precisely the trap. It stops being maintained, its known vulnerabilities stay open, and its incompatibility with recent versions of the base is discovered on the day an update has become urgent.
That maintenance load is the real criterion when choosing a foundation, and we cost it in Webflow or WordPress.
The content that dates
Pages describing an offering that has been dropped, prices that are no longer right, a team member who left two years ago. It is not a technical problem, it is the most visible one to a visitor, and the easiest to fix if somebody takes care of it.
What happens when a way in is found
The usual picture is of a targeted attack. The reality is more mundane and more worrying: most compromises come from automated sweeps testing thousands of sites for a known weakness. Nobody chose you, your site answered.
What follows does not match the popular image either. A compromised site almost never displays a triumphant message. It keeps working normally, while a discreet administrator account has been created, invisible pages are being published, or emails are going out in your name.
The consequences, on the other hand, are plainly visible: your domain ends up flagged as dangerous, your legitimate emails stop arriving, and the site drops in the rankings while it is cleaned up. Putting things right costs several days, and the lost trust takes longer to come back.
The non-negotiable minimum
It comes down to five points, and none of them is expensive next to what it prevents.
- Automatic backups, tested. A backup that has never been restored is not a backup, it is an assumption. The test is done once, calmly, not on the day you need it.
- Updates applied regularly, base and extensions, on a set rhythm rather than at the mercy of alerts.
- Accounts kept up to date. Access for people who have left must disappear, and the list of administrator accounts must be known. One account too many is the most discreet way in there is.
- Unique passwords per site. A reused password turns the compromise of one service into the compromise of all the others.
- Monitoring that alerts a human. An anomaly recorded in a log nobody opens amounts to an anomaly not detected.
We apply this list to our own sites as well as to those we host, and we verify it automatically rather than on trust. A check that rests on somebody’s memory always ends up being skipped once.
What inaction costs, compared with upkeep
Upkeep is a regular cost, small and predictable. Bringing things back up to standard is a one-off cost, large and unpredictable, and it almost always arrives at the wrong moment.
The difference is not only financial. An update applied calmly can be tested and corrected without pressure. The same update applied urgently, because a vulnerability is being exploited, is done under pressure and breaks things more often.
It is also why performance and search are not dealt with once and for all: a site slowing by a point a month loses ground without any report flagging it. We set out that mechanism on the SEO and performance page.
Handling upkeep in-house or entrusting it
The question is settled on two criteria, and on no argument of principle.
The first is availability, not skill. Applying updates and checking a backup does not call for rare expertise; it calls for somebody to do it on a fixed date, even in a busy period. What is missing is regularity, almost never the know-how. A company where the competent person is also the one handling emergencies will not keep the rhythm, and that is predictable from the outset.
The second is what happens when things break. An update that breaks a site happens, even when done well. The real question is not avoiding it but knowing who restores, how quickly, and from which backup. An in-house team that has never restored a backup will discover on that day that the procedure was not the one they thought.
Our position does not systematically push towards outsourcing. A simple site, with few extensions and somebody available one hour a month, is maintained very well in-house, provided the procedure has been written down and a restore tested at least once.
Entrusting upkeep becomes justified when the site carries a real share of the business, when it is connected to other tools, or when nobody in-house can guarantee a quick reaction. In those cases, what you are buying is not technical skill, it is the guarantee that somebody is watching and that somebody answers.
What we refuse, in either case, is the in-between: a support contract that commits to nothing verifiable, or in-house management whose safety net nobody has ever tested.
When to rebuild rather than maintain
Three signals, and they are clear enough not to be debated for long.
When an update to the base breaks the site because the theme or the extensions no longer keep up, and nobody maintains them. When the number of extensions installed exceeds what anybody can explain. And when the slightest content change requires a technical intervention, which means the site can no longer be administered by the people who have to keep it alive.
In those three cases, upkeep becomes an expensive sticking plaster. A framed redesign comes out cheaper than a year of successive fixes, and above all it puts the site back in the hands of its owner.
