WordPress maintenance: how we keep our clients’ sites healthy

In short: this article explains how we at PaperPlane handle WordPress maintenance: the annual contract that keeps a site secure, updated and monitored, and the hourly packages clients use to grow their site over time. And why the distinction between the two isn’t just contractual, but a matter of method.

When a WordPress site goes live, the natural feeling is that the work is done. You’ve invested time, approved the design, written the content, launched. From that moment the site is there, it works, it does its job.

What you don’t see, until something breaks, is that a WordPress site is a living system. WordPress releases core updates on a regular cadence. Plugins update, change, and are sometimes abandoned by their developers. Servers evolve: the version of PHP supported today may not be the same twelve months from now. Vulnerabilities get discovered and published, and between the moment a flaw becomes known and the moment someone exploits it, hours pass, not weeks.

A site without maintenance isn’t standing still. It’s quietly accumulating technical debt.

The annual contract: what it includes and how it works

The maintenance plan we offer our clients runs annually and covers everything a WordPress site needs to stay stable, secure and performant over time: updates to WordPress core, plugins and theme, periodic backups calibrated to the site’s editorial intensity, uptime monitoring, weekly malware scans, security hardening and periodic performance testing.

It isn’t a service that kicks in only when something breaks. It’s a constant, silent presence: most interventions happen without the client noticing, and that’s exactly the goal. The sign that the work is doing its job isn’t a “problem solved” notification: it’s the absence of problems.

The contract renews every year. Support requests go to a dedicated email address: it’s the channel that triggers response-time monitoring and guarantees that every report is handled with defined priorities. Urgent requests about security vulnerabilities follow a separate protocol, with tighter intervention times.

The difference between an update done and one done well

There’s a widespread idea that “WordPress maintenance” means clicking “Update all” from the admin panel every now and then. It isn’t wrong in absolute terms, it’s far better than doing nothing, but it isn’t what we do, and the difference shows when something goes wrong.

Every update we manage for our clients’ sites follows a precise protocol. Critical security updates are applied within 48 to 72 hours of the vulnerability being disclosed: we don’t wait for the weekly cycle, because some flaws are actively exploited within a few days. Major releases and ordinary updates, on the other hand, are scheduled every seven working days, with a preventive compatibility check before proceeding.

Before proceeding, we read the changelogs. It isn’t a formality: the changelog of a plugin or of WordPress core says exactly what changed, which features were modified, which bugs were fixed, which areas of the code were touched. Reading it lets us understand in advance where to look after the update, which features to verify first, whether there are integrations that might be affected. Updating without reading the changelog is like replacing a part of an engine without knowing what it was connected to.

Where the hosting allows it, the more delicate updates are tested in a staging environment, a separate copy of the site, before being moved into production. If an update introduces a conflict that can’t be resolved quickly, we roll back to the previous stable version. That isn’t a failure: it’s part of the protocol.

This matters most for the more complex sites. On VolumeBK, the cultural e-commerce that brings together books, records, courses and events with over twelve thousand items in its catalogue, a WooCommerce update applied without verification could break the purchase flow in the middle of an editorial launch week. Caution isn’t timidity: it’s respect for the context the site operates in.

Backup, security and monitoring: three things you only notice when they’re missing

Backup

Backup frequency isn’t the same for every site. An editorial site with new articles every day has very different needs from a showcase site that changes content once a month. We calibrate the frequency of saves to the project’s editorial intensity: frequent backups for those who publish often, an optimized frequency for more static sites.

Where the hosting offers a native backup system, we configure it according to the provider’s best practices. Where it doesn’t, we implement a protocol with periodic backups of files and database archived on external cloud storage, separate from the main infrastructure. The goal is that even in the event of a critical hosting failure, a rare but not impossible event, recovery is possible and fast.

Proactive security

Updates are the first line of defence, but not the only one. We monitor failed login attempts to identify brute-force attacks: when we detect suspicious activity or repeated authentication errors, the system temporarily or permanently blocks the IP address responsible. We apply specific hardening configurations to reduce the site’s attack surface: architectural choices that make life harder for anyone looking for a way in.

Every week we run malware scans and verify the integrity of WordPress core files. Not to find serious problems every week, fortunately that’s rare, but to be certain that, if something changes, we know about it before the client does and before it becomes an emergency.

Uptime and performance monitoring

Is the site reachable? It sounds like a trivial question until the answer is “no”. Uptime monitoring lets us intervene immediately in the event of downtime, often before the client notices. Alongside this we run periodic PageSpeed and Core Web Vitals tests, the metrics Google uses to measure user experience, which we cover in our work on web performance, plus periodic database optimization to keep the site responsive over time.

The silent decay no one reports

A WordPress site that gets no maintenance doesn’t break all at once, in most cases. It degrades gradually, almost invisibly. Performance drops by a fraction of a second each month. SEO scores slip because pages become progressively slower. Some feature stops working correctly on certain browsers after an update to the browser itself, not to the site. Until an automatic server update, outside our control, introduces an incompatibility with a version of PHP the site no longer supports.

At that point what looked like “all fine” reveals months of accumulated debt, and fixing it all at once costs far more than preventing it over time.

It’s the same mechanism as a car you never take to the mechanic. It runs, until it doesn’t. And when it stops, it’s often not just a matter of changing the oil.

Hourly packages: to grow the site, not just keep it standing

Annual maintenance guarantees the site is secure, updated and monitored. But it doesn’t include changes: a new section, a graphic update, an extra feature, a page to restructure based on usage data. That’s what the hourly packages are for.

The mechanism is simple. The client buys a package of hours in advance, at a defined hourly rate. The hours don’t expire: they’re used when needed, drawn down progressively, and when they run out the package is renewed. Requests come in by email or WhatsApp, with a description of the problem or the desired intervention.

At any moment the client can request a full report: every intervention carried out with a description, date and duration, the total hours purchased and those still available. There’s no need to wait for a deadline or a renewal to get a clear picture of what’s been done and what’s left. It’s a form of transparency we consider part of the service, not an optional extra.

What changes compared to a one-off intervention isn’t just the price, even if having hours already available is almost always more convenient than an open-ended quote drawn up in an emergency. What changes is the kind of conversation you can have.

With hours available, a client who notices something off can write without thinking “how much will this phone call cost me?”. An idea for improvement can be explored without opening a negotiation. The relationship becomes ongoing, and that continuity makes it possible to work in a smarter way.

Maintenance as a vantage point, not just protection

Whoever follows a site over time gets to know it. They know which plugins have been problematic in the past, they know where the custom theme has certain fragilities, they know which pages get the most traffic and which are ignored. This accumulated knowledge has enormous practical value when it comes to deciding where to invest the available hours.

That’s why, on projects where we work continuously, we integrate maintenance with an analysis activity: Google Analytics 4, Google Search Console and Microsoft Clarity become tools for regular observation, not dashboards you open once a year. The data tells you where people get stuck, which content works, where the site loses opportunities.

In the case of VolumeBK, watching Clarity’s session recordings, we observed precise user behaviours on the search filters: some expected to open a panel, others tried to close the menu by clicking outside the area without managing to. Small frictions, repeated, invisible to anyone who uses the site every day. That data guided the rethinking of the filter system in the redesign: clearer language, more explicit interaction areas. Not because someone had a more authoritative opinion, but because the data showed where people were getting stuck.

Without an ongoing relationship with the site, this kind of observation doesn’t happen. You wait for the next big redesign, which comes every three or four years, and in the meantime the site accumulates frictions that no one ever decided to accept, but that no one ever had the time to fix.

A real limit: what maintenance can’t do

Transparency is part of how we work, so we’ll say it plainly: the maintenance contract has precise boundaries, and outside those boundaries our responsibility stops.

We aren’t responsible for malfunctions, instability or slowness of the hosting server, which depend on the provider’s infrastructure. We can’t guarantee recovery from data loss caused by technical hosting failures or by backups managed directly by the provider. We don’t cover zero-day vulnerabilities, meaning flaws discovered and exploited before a patch exists, nor server-level security breaches.

This isn’t a disclaimer to shed responsibility: it’s an honest description of where the software ends and the infrastructure begins. It’s also why the choice of hosting is part of the same conversation about maintenance. A provider that offers staging environments, reliable native backups and responsive technical support concretely changes what can be done. For our clients’ sites we recommend Kinsta for exactly this reason: a solid infrastructure reduces the perimeter of risks that application-level maintenance can’t cover.

Where to start if your site has never had maintenance

First: find out what state the site is in right now. Open Google Search Console and check whether there are coverage errors or Core Web Vitals issues. Check how long it’s been since WordPress, the plugins and the theme were updated. If you don’t know, a developer can find out in a few minutes.

Second: identify the most urgent risks. Plugins with known vulnerabilities, PHP versions no longer supported, no verified backups: these are the problems to fix right away, before any other consideration.

Third: distinguish maintenance from development. Before deciding what to do, get clear on what you want to achieve. If the site is healthy but you want to improve it, hourly packages are the right tool. If the site isn’t maintained, the annual contract is the starting point.

Fourth: don’t wait for the emergency. The best time to put a maintenance plan in place is before something happens. The second best time is today.

If you want to figure out where to start

If you have a WordPress site and you’re not sure how it’s really doing, we can look at it together. Our WordPress maintenance and security service always starts from an analysis of the project’s real state, not from a generic quote.