Ongoing WordPress maintenance and technical support
Maintenance is not applying updates. It is deciding when to apply them, testing them somewhere that is not the live site, knowing how to reverse them, and being the party who notices when a backup stops completing.
Maintenance is usually absent until it is urgent
A WordPress site needs a cadence of small work. Updates have to be applied while they are still routine, backups have to be verified rather than scheduled, plugin compatibility has to be checked before it becomes an outage, and somebody has to notice when something stops behaving. In most organisations this work happens when somebody has time, which means it happens after something has already gone wrong.
- Updates are applied rarely, in a batch, and with visible risk
- Plugin updates are deferred because the last one broke something
- Backups are scheduled and nobody has confirmed a restore works
- A failed update is discovered by a visitor rather than by monitoring
- Small bugs wait behind larger development work in a queue
- The person who can safely change the site is the person who built it
- Nobody notices a plugin has been abandoned until it breaks
- There is no record of what changed, when, or who changed it
The people who usually bring us this problem
A business with a site and no technical staff
The site matters and nobody is responsible for it between projects. You want that responsibility to exist before something fails rather than after.
A marketing team that owns the site
You can handle content and you need the technical layer maintained by someone accountable for it, without having to become the expert on it.
Agencies or partners with a site they maintain for a client
You want the platform layer maintained to a documented standard rather than absorbed into whoever is available.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
Deferred updates accumulate into a forced, risky upgrade
Each version skipped makes the next one less tested against your configuration and more likely to break something. What would have been routine maintenance becomes an unplanned project, usually with a security deadline attached.
An unverified backup is discovered at the worst possible moment
Nobody tests a backup until they need it. A restore that has never been rehearsed is a routine rather than a recovery capability, and the difference is discovered during an incident.
Small defects spend months in a queue
Without a triage path, every small fix waits behind whatever development is scheduled next. The cost is not the fix; it is the workarounds that accumulate around a defect nobody has capacity to address.
Undocumented changes make the next person slower
A site maintained without a change log becomes harder to reason about every month. That cost is invisible until it is paid all at once by whoever inherits it.
Capabilities
Each of these is work we carry out, not an area we advise on.
Audited onboarding
Before maintaining anything, establishing what is there: platform and plugin versions, what is abandoned, where the theme has been modified directly, whether staging exists, and whether the backups actually restore. Our working assumption is that we are inheriting a state rather than a setup.
Scheduled updates with testing and rollback
Updates applied on a defined cadence, tested in a staging environment first where the site's configuration warrants it, with a rollback available for each change. The commitment is the process, not the speed.
Plugin compatibility and lifecycle
Tracking which plugins remain maintained and which have been abandoned, and identifying conflicts before they surface in production rather than during an update.
Backup monitoring, not backup scheduling
Confirming that backups complete and that a restore works. Most inherited arrangements have the first and have never done the second, and the second is the only one that is evidence.
Security posture as routine work
Version currency, access review and administrative surface hygiene handled continuously rather than as a periodic assessment. Most WordPress compromises begin with a component that was knowably out of date.
Triage and small improvements
A defined path for defects and small changes, so issues that fall below the threshold of a development project still get resolved. Scope and response expectations are stated rather than left to be inferred.
Change record
What was changed, when, and why, kept as the site is maintained. It is what makes the site legible to whoever is working on it next — including us.
Recurring reporting
A regular written summary of what was done, what was found, what needs attention and what has been deferred. Maintenance that is invisible is maintenance that gets cancelled in a difficult quarter.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Audit before accepting responsibility
We do not take on maintaining a site until we can describe its current state. That inventory is the first deliverable, and it frequently changes the scope — an abandoned plugin or an unrestorable backup is a finding, not an onboarding step.
Establish the recovery path early
A tested restore is confirmed before routine changes begin, because until it exists every update carries avoidable risk. This is the least visible part of maintenance work and the one that most justifies it.
Update on a cadence, with a way back
A schedule rather than a policy, staging where the configuration warrants it, and a rollback for each change. Emergency updates occasionally happen and are always a signal that the cadence was interrupted.
Maintain a stated boundary
What is included, what is not, and how a request outside it is handled. Most dissatisfaction with maintenance arrangements comes from an unstated boundary rather than from the work itself.
Record as you go
The change log is written during the work rather than reconstructed at handover. It is what allows someone else — including a future us — to understand the site without re-deriving it.
Report so the work is visible
A recurring summary means the value of maintenance is legible rather than assumed. The failure mode of a maintenance arrangement is a quiet quarter in which someone decides it was never needed.
What an engagement produces
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Onboarding audit
- Platform, plugin and theme version inventory
- Abandoned or unmaintained dependency identification
- Direct theme and platform modification review
- Backup configuration reviewed and a restore tested
- Staging environment assessment
- Written statement of what needs attention before routine work begins
Routine work
- Platform, plugin and theme updates on a defined cadence
- Staging validation and rollback for each change
- Backup completion monitoring and periodic restore testing
- Access review and administrative surface hygiene
- Uptime and error signals, where covered by the agreement
- Triage and resolution of reported defects and small changes
Reporting and records
- Recurring written report of work completed and issues found
- Change log attributed, dated and kept current
- Escalation path for anything outside the agreed scope
- Documentation maintained as the site changes
Architecture and technology
Scope: what a maintenance agreement is
- A defined cadence of updates, applied and tested
- Backup verification, including restore testing
- Compatibility and lifecycle tracking of dependencies
- Triage and small fixes within an agreed boundary
- Reporting, a change log and an escalation path
Scope: what it is not
- Content marketing, copywriting or SEO campaign work
- Unlimited development — larger features are scoped separately
- Guaranteed 24/7 response unless separately contracted
- A guarantee that no update will ever cause a problem; the commitment is that problems are detected, reversible and owned
- Hosting or infrastructure provision, which is a separate engagement
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
The site needs building or rebuilding rather than running
Platform, theme and content-model work.
WordPress developmentThe server needs an owner rather than the site
Runtime, database and infrastructure operations.
Server managementA compromise has already happened
Incident response is a different engagement with a different sequence.
Hacked website recoveryPerformance is the recurring complaint
Systematic performance work rather than configuration tweaks.
Website performance engineeringFrequently asked
Can you take over maintenance from another agency or a previous developer?
Yes, and it is most of what we take on. It begins with an audit rather than a login: what versions are running, what has been modified directly, whether the backups restore, and whether a staging environment exists. We would rather tell you what we are inheriting before accepting responsibility for it than discover it in the first month.
Are feature requests included?
Small changes are, within a boundary that is agreed in writing rather than guessed at. Larger development is scoped and priced separately, which is the honest arrangement for both sides — an agreement described as unlimited development is either mispriced or quietly limited. What matters is that you know which category a request falls into before you make it.
What happens if an update breaks the site?
It is reverted and investigated, and the revert is possible because the change was made in a way that could be reversed. That is the purpose of staging and rollback rather than a promise that nothing will break — on a platform where any update touches third-party code, no responsible party guarantees that. What we commit to is that a failed update is detected, reversible and owned rather than discovered by you.
Do you provide 24/7 support?
Not unless it is separately contracted, and we will not imply otherwise. A small practice advertising round-the-clock cover it cannot staff is making a promise that fails precisely when you rely on it. What is agreed is an escalation path and a response expectation for your engagement, stated in writing.
Is maintenance really necessary? We have not updated anything for two years.
That is the situation the page is written for, and the honest answer is that two years of deferral has already created work. It is not necessarily expensive, but it is not a clean slate: the first thing we do is establish what has drifted and what has to happen before routine maintenance can begin. Platforms and plugins that have not been updated have usually also stopped being maintained upstream, which changes the job from applying updates to replacing components.
Related capabilities and work
Bring us the problem you have not been able to fix
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.