Your WordPress site needs an owner, not an update button.
I maintain existing WordPress and WooCommerce sites at code level — updates, staging, backups, QA, performance, security and the small development work that keeps production healthy. Not a care plan. A senior developer who takes responsibility for what happens when the site changes.
The update button is the easy part.
A green "Update completed" message doesn't tell you whether GTM stopped firing, your mobile menu broke, or an old template override is now incompatible. Professional maintenance is that verification — the part a €20/month plugin can't do, because it can't tell whether checkout still takes payments.
Sites rarely arrive clean.
These aren't specific clients — they're the technical situations a production WordPress site tends to accumulate. Most maintenance engagements start by finding out which of these are true.
Know what changed. Test what matters. Ship deliberately.
What maintenance actually includes.
WordPress core updates
Review compatibility with the theme, plugins and custom code, then deploy safely — not the moment the notification appears.
Plugin updates
Not "update all". I read changelogs, understand dependencies and weigh risk before shipping meaningful updates, and hold the ones that shouldn't go yet.
Theme & custom code
Protect the customisations that make the site yours, and flag code that shouldn't be living in a parent theme where the next update will wipe it.
Staging → production
Risky changes get tested on a copy of the site, away from customers, before they ever reach production.
Backups & rollback
A backup only matters if there's a clear, tested route back when production fails. That route is the point, not the backup file.
Security hygiene
Users, permissions, credentials, vulnerable components and obvious attack surface. This isn't a replacement for specialist enterprise security operations, and I won't pretend it is.
Performance regression checks
Maintenance shouldn't slowly turn a fast site back into a slow one. When performance needs real work, that's dedicated WordPress performance and Core Web Vitals work.
Forms & conversion paths
The forms, CTAs, signups and lead flows that make the site worth having — checked, because they break quietly.
WooCommerce
For stores: cart, checkout, payment, transactional emails and the integrations orders depend on — tested before an update touches them.
Analytics & tracking
GTM, GA4 and conversion tracking shouldn't silently disappear after a frontend change. If the numbers stop, someone should notice — before the next report.
Small ongoing development
Bug fixes, template changes, CSS/JS fixes, integrations, admin improvements, small custom functionality. Real engineering — not just clicking update.
What happens every time I touch production.
The depth of testing matches the risk. A WooCommerce payment update isn't handled like a harmless admin utility — but the shape of the process is the same.
Snapshot / backup
A known-good point to return to.
Review changes
Changelogs, dependencies, what this touches.
Update staging
Apply the change away from customers first.
Functional testing
Forms, checkout, integrations, the paths that matter.
Visual / mobile QA
Layout and templates, on real breakpoints.
Performance sanity check
Make sure nothing regressed on the way.
Deploy
Ship to production deliberately.
Production verification
Confirm it works where it counts — live.
Log what changed
So the next change starts from a known state.
Sometimes the right update is no update.
Installing a release the moment it appears can be worse than delaying it on purpose. A major version can ship a breaking change; a plugin can drop a feature the site depends on; a dependency can quietly go abandoned. The aim isn't to run permanently outdated software — it's to update when it's safe, not when it's merely available. Maintenance is judgement, not a cron job.
Maintenance turns into development surprisingly often.
A live site is never really finished. It needs bug fixes, small UI changes, new tracking, redirects, structured data, landing-page support, integrations, editor improvements and the occasional performance pass. The advantage of a maintenance relationship is that the developer doing that work already knows the codebase — so a small change stays small instead of becoming an investigation.
WooCommerce changes the risk model.
On a brochure site, a broken component is annoying. On WooCommerce, a broken checkout stops revenue. That's why store updates get tested harder — against the parts customers actually touch.
You deal with the developer doing the work.
No account-manager chain and no ticket lottery. You talk to the person making the change, get issues explained in normal language, see clear summaries of what changed, and get staging when the change warrants it.
Who this is for.
Good fit
- Established WordPress sites that matter to the business
- Marketing sites central to lead generation
- WooCommerce stores, publishers and SaaS/company sites
- Sites with custom code or external integrations
- Teams that request WordPress changes regularly, and agencies needing senior support
Probably unnecessary
- A static five-page site that changes once a year
- A site already maintained by a competent internal WordPress team
- A project expecting unlimited development for a tiny maintenance fee
And when something does break?
White screen, a failed update, a checkout issue, a broken layout, a PHP fatal, a plugin conflict, an unexpected regression. Existing maintenance clients already have someone who knows the site — which makes diagnosis far faster than starting from zero. I don't advertise 24/7 cover or fixed SLA response times I can't guarantee; what you get is a developer already familiar with the setup when it matters.
Maintenance depends on what I'm taking responsibility for.
There's no fixed care-plan tier, because taking ownership of a simple brochure site and taking ownership of a busy WooCommerce store aren't the same job. What sets the price:
Maintenance questions, answered.
Core and plugin updates reviewed for risk, testing on staging, functional and visual QA, backups and rollback, security hygiene, performance regression checks, analytics verification, and small ongoing development. The work is verification and technical ownership, not just running updates.
Not blindly. I review changelogs, dependencies and risk, and update on a cadence that matches the site. A meaningful update ships after it's tested; a risky one may be deliberately held until it's safe. The goal is a healthy site, not a green "all updated" badge.
Yes, with depth proportional to risk. A WooCommerce payment or checkout update is tested on staging before production; a harmless admin utility isn't treated like a release. Testing covers the paths that actually matter — forms, checkout, tracking and performance.
For anything risky, yes. Staging is where changes get tested away from customers before they reach production. Low-risk changes don't always need it; the level of ceremony matches the level of risk.
Yes — that's most of this work. I start by mapping what's there: plugins, custom code, integrations and how production is actually set up, before changing anything.
Yes. Undocumented custom code, mystery plugins and changes made directly in production are the normal starting point. The first job is understanding the site well enough to change it safely.
Yes. Stores raise the stakes because a broken checkout stops revenue, so updates are tested against cart, checkout, payments, transactional emails and key integrations before they go live.
Yes. Bug fixes, template and CSS/JS corrections, redirects, tracking fixes and small custom functionality are a normal part of maintenance — not a separate project every time.
Yes, and it usually does. Because I already know the codebase, small development — template changes, integrations, admin improvements, structured data — is faster and lower-risk than briefing a stranger each time.
I handle security hygiene: users and permissions, credentials, vulnerable components and obvious attack surface. That's different from specialist enterprise security operations, and I'm clear about that boundary.
Yes. Maintenance includes performance regression checks so a fast site doesn't slowly turn slow, and deeper Core Web Vitals work can be part of the engagement when it's needed.
There's a snapshot to roll back to, and because I already know the site, diagnosis is much faster than starting from zero. The fix is applied, verified in the failing area, and what changed is logged.
Yes. I'm based in the Barcelona area and can work on-site locally, and I maintain WordPress sites remotely for companies across Spain and Europe.
Yes. Maintenance is remote-friendly by nature — staging, Git and clear change summaries work the same wherever your team is, in a compatible European timezone (CET).
It depends on what I'm taking responsibility for: WordPress vs WooCommerce, the amount and quality of custom code and plugins, how often things change, how much testing each change needs, ongoing development and how critical production is. I scope it after seeing the site.
Show me what I'm inheriting.
Send me the site and tell me who maintains it today. I'll look at the setup, the obvious risks, and what ongoing technical ownership would actually involve — before either of us commits to anything.
