WordPress maintenance: the real cost over time, between dependencies and technical debt

WordPress maintenance is usually sold as a package: updates, backups, a monthly security check. Put that way it looks like a fixed cost, the same for everyone. It is not. The time and risk involved in keeping a WordPress site alive depend almost entirely on how many dependencies it has and how tightly they are bound together. That is the real cost to understand before signing a contract, or before building the site.

The dependency graph

A production WordPress site depends on: the PHP version and its extensions, the MySQL or MariaDB version, WordPress core, the theme (and often a parent theme), the page builder and its add-ons, every plugin and the libraries each one brings. Each has its own release cycle and minimum requirements.

The problem starts when these pieces depend on each other:

• the page builder needs a minimum PHP version, but an old plugin does not work with it;
• a builder add-on updates before the builder itself and breaks the layout;
• an e-commerce plugin changes a hook and three extensions stop working;
• the host drops a PHP version and the theme, no longer updated, throws errors.

Every update becomes a compatibility problem to be solved in order. That is what I mean when I say that on many WordPress sites everything is too tightly bound to everything else.

Technical debt that piles up

Postponing updates does not remove the cost, it pushes it forward and makes it grow. A site left untouched for two years is not updated: it is migrated. Multiple version jumps in PHP, the builder and the plugins mean accumulated breaking changes, deprecated code, customisations that no longer apply.

The most common forms of technical debt I find:

• customisations inside the parent theme, lost at the first update;
• code pasted into functions.php from tutorials, with no version control;
• plugins deactivated but not removed, still on the server and still exploitable;
• data tied to the builder (proprietary shortcodes and meta) that turn every theme change into a rebuild;
• no staging environment, so every change is made straight in production.

What serious maintenance must include

More than a list of services, the procedure is what counts.

Staging environment

A synchronised copy of the site where updates are applied and tested before production. Without staging, "updating" means hoping.

Updates by priority

Security fixes are applied immediately, as soon as they are released: that is where the exposure window is decided. Feature updates are grouped, tested and released calmly, reading the changelogs of critical components.

Version control

Custom themes and plugins in a Git repository, deployed from the repository and not over FTP. Every change has an author and can be reverted.

Verified backups

Automatic backups of files and database, stored off the server, and above all tested restores. A backup nobody has ever restored is a hypothesis.

Monitoring

Uptime, certificate, core file integrity, new administrators, PHP errors in the logs, and real Core Web Vitals from Search Console. The aim is to notice before users do.

Reducing dependencies

This is the part almost no package includes, and the one that lowers the cost over time: removing useless plugins, replacing what a heavy plugin does with a few lines of code, moving data that does not belong to the theme out of it. I cover this in Custom or ready-made WordPress themes and plugins.

How to assess an offer

The questions I would ask whoever proposes maintenance:

1. Are updates tested on staging before production?
2. How quickly are critical security fixes applied?
3. Are backups test-restored? Where are they stored?
4. What happens if an update breaks the site: who steps in, and with what priority?
5. Is there periodic work to reduce dependencies, or only updates?
6. Do I get a report of what was updated and what was found?

If the answer to the first question is no, the offer is cheap because the risk is yours.

My take

I love WordPress, but honestly, maintaining many WordPress sites has become out of proportion to what they do. Hours spent updating components nobody really chose, checking compatibility between pieces that should not depend on each other, chasing vulnerabilities in plugins installed years ago for a feature never used.

On projects like Altura Vela, where I look after the WordPress site alongside the management app I built in Nuxt, I see the difference clearly: the WordPress site needs constant attention, the app grows with code I know line by line. That is why, when a site does not need a dynamic admin panel, I suggest moving to a static architecture: the best maintenance is the maintenance you do not need.

That said, when a client chooses WordPress I look after it with the same care as any other project. Discipline makes the difference: a list of components with the reason each one is installed, a review schedule for dependencies, a rule that no plugin goes in without an assessment. Simple habits that turn maintenance from a race to update into planned work.

Why work with me

I have been programming since 1999, delivered more than 300 projects and work as an external developer with about 30 agencies, from Rome and remotely. I do WordPress maintenance with staging, version control and a procedure, and whenever I can I remove a dependency rather than add one.

If you want to understand what your site really costs you and how to lighten it, get in touch: in a call of about 20 minutes we look at what is underneath. The service is in WordPress maintenance.