Website technical debt: how to recognise it and regain control of maintenance
Is your site working but every change feels risky? Regain control with clear insights on access, forms, backups, and sustainable maintenance options.
Sur cette page6 sections
Your site opens normally, the pages are there, and you simply want to add an attachment to the contact form. Yet, no one wants to touch the form until they've figured out how emails are sent, which plugin manages it, and why the last update broke notifications. The change seems small. Everything you need to understand before making it no longer is.
This is often the moment when technical debt becomes tangible for the site owner. Not as a red alert, but as a "whatever you do, don't touch that." J’ai déjà expliqué the principle of technical debt dans un autre article. Here, the idea is more practical: how to know what is actually blocking maintenance, and how to regain control without deciding to rebuild everything at the first sign of trouble.
Conversely, an old site isn't necessarily bad. If it still fulfills its role, its components can be maintained, and you know how to evolve it, its age alone doesn't justify a rebuild. A recent tool can be much more painful if every modification relies on an assembly that no one understands.
What I would look for are the moments when a normal operation becomes abnormally uncertain. An update that is systematically postponed. A fix that comes back three times. A form where you no longer know who receives the emails. These are clues, not yet a diagnosis: you need to understand what causes them.
The problem can be quite local: a forgotten sending setting, an obsolete address, or a specific incompatibility. In this case, a targeted fix may suffice. It can also reveal a broader issue: several different forms, each with its own way of working, and no reliable way to test changes.
It's not the same intervention. Saying "the site is poorly built" doesn't help distinguish them, nor does directly proposing a new site. I prefer to show what is failing, why, and what each option would actually solve.
An essential and well-maintained plugin is not equivalent to an unused plugin kept because you're afraid to delete it. Same for no-code: it's not the name of the tool that determines quality. The problem starts when workarounds accumulate to the point that a mundane modification becomes a project in itself.
Illustrative photo, not the diagnosis of this installation. For your site too, knowing which element is connected to what is more useful than judging the whole by its appearance.
The inventory must lead to something you can understand: critical elements, missing access, observed difficulties, and options for addressing them. Not just a list of technical terms accompanied by an invoice.
Rolling back also deserves thought. Restoring an old copy of a shop can cause orders received since that copy to disappear. Therefore, you don't treat a showcase site and a site that records transactions in exactly the same way.
Next, we establish a few simple tests on important user journeys: sending a request, receiving the notification, booking or paying if the site allows it. This gives a point of comparison before and after the intervention. Otherwise, "it seems to work" becomes our only means of control.
A rebuild can be justified when the foundation no longer allows for the maintenance of necessary functions under acceptable conditions. But it doesn't make business needs, content to be migrated, or connections to email and other tools disappear. You have to compare a restoration to a reconstruction by counting all of that, not pitting an old, imperfect site against an imaginary new site that would have no problems.
J’ai détaillé cette comparaison dans l’article sur website redesign. The right choice is the one that puts your operations back on a manageable foundation, not necessarily the one that produces the most new pages.
The result I'm looking for is quite simple: when you request a modification, we know where to intervene, how to check the result, and what to do if things go wrong. You don't need to know every file on the site. You do, however, need to know who provides maintenance, what is being monitored and what remains to be addressed.
If every change has become a source of anxiety, we can review your site. I prefer to start from its actual blockages and explain the options to you rather than selling you a rebuild just because the term "technical debt" sounds scary.
This is often the moment when technical debt becomes tangible for the site owner. Not as a red alert, but as a "whatever you do, don't touch that." J’ai déjà expliqué the principle of technical debt dans un autre article. Here, the idea is more practical: how to know what is actually blocking maintenance, and how to regain control without deciding to rebuild everything at the first sign of trouble.
A working site can be difficult to maintain
Seeing a page display proves that the page displays today. It doesn't tell you if someone knows how to modify it, if requests are going to the right place, or if a restoration is possible in case of a problem. It's a bit like a car that starts: it's reassuring, but it's not its service history.Conversely, an old site isn't necessarily bad. If it still fulfills its role, its components can be maintained, and you know how to evolve it, its age alone doesn't justify a rebuild. A recent tool can be much more painful if every modification relies on an assembly that no one understands.
What I would look for are the moments when a normal operation becomes abnormally uncertain. An update that is systematically postponed. A fix that comes back three times. A form where you no longer know who receives the emails. These are clues, not yet a diagnosis: you need to understand what causes them.
Let's go back to our form
Before adding the attachment, I would want to trace the path of a request: where it is entered, where it is saved, how the email is sent, and who receives it. If the form displays "message sent" but the mail server rejects the email, the visitor thinks they've contacted the company while the company sees nothing.The problem can be quite local: a forgotten sending setting, an obsolete address, or a specific incompatibility. In this case, a targeted fix may suffice. It can also reveal a broader issue: several different forms, each with its own way of working, and no reliable way to test changes.
It's not the same intervention. Saying "the site is poorly built" doesn't help distinguish them, nor does directly proposing a new site. I prefer to show what is failing, why, and what each option would actually solve.
Taking inventory isn't just counting plugins
First, I want to know who owns the accounts: domain, hosting, email, payment tools if any. Then which building blocks serve what purpose, which are still maintained, and where the customisations are. A list of twenty plugins without an explanation of their role doesn't give much leverage over the problem.An essential and well-maintained plugin is not equivalent to an unused plugin kept because you're afraid to delete it. Same for no-code: it's not the name of the tool that determines quality. The problem starts when workarounds accumulate to the point that a mundane modification becomes a project in itself.
Illustrative photo, not the diagnosis of this installation. For your site too, knowing which element is connected to what is more useful than judging the whole by its appearance.
The inventory must lead to something you can understand: critical elements, missing access, observed difficulties, and options for addressing them. Not just a list of technical terms accompanied by an invoice.
Before repairing, check that you can roll back
I wouldn't start a major series of updates directly on the live site. You need a suitable backup, verify it can be restored, and, when possible, replicate the site in a test environment. A file called "backup" doesn't offer much if no one knows what it contains or how to use it.Rolling back also deserves thought. Restoring an old copy of a shop can cause orders received since that copy to disappear. Therefore, you don't treat a showcase site and a site that records transactions in exactly the same way.
Next, we establish a few simple tests on important user journeys: sending a request, receiving the notification, booking or paying if the site allows it. This gives a point of comparison before and after the intervention. Otherwise, "it seems to work" becomes our only means of control.
Repair, simplify, or rebuild: the answer depends on the blockage
If a specific component is at fault and the rest is maintainable, I would prioritise its correction or replacement. If several components do the same thing, simplifying can avoid having to maintain three versions of the same functionality. If problems always recur in the same place, treating their cause is generally more worthwhile than stacking another fix.A rebuild can be justified when the foundation no longer allows for the maintenance of necessary functions under acceptable conditions. But it doesn't make business needs, content to be migrated, or connections to email and other tools disappear. You have to compare a restoration to a reconstruction by counting all of that, not pitting an old, imperfect site against an imaginary new site that would have no problems.
J’ai détaillé cette comparaison dans l’article sur website redesign. The right choice is the one that puts your operations back on a manageable foundation, not necessarily the one that produces the most new pages.
Maintenance must become a normal operation again
I would set priorities in this order: regain access and responsibilities, secure the ability to restore, re-establish the journeys that drive the business, then eliminate the causes of recurring incidents. The rest can be planned without pretending to fix the entire past all at once.The result I'm looking for is quite simple: when you request a modification, we know where to intervene, how to check the result, and what to do if things go wrong. You don't need to know every file on the site. You do, however, need to know who provides maintenance, what is being monitored and what remains to be addressed.
If every change has become a source of anxiety, we can review your site. I prefer to start from its actual blockages and explain the options to you rather than selling you a rebuild just because the term "technical debt" sounds scary.
