Your WordPress site needs an owner, not an update button.
I maintain existing WordPress en WooCommerce sites at code level — updates, staging, backups, QA, performance, security en 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, of an old template override is now incompatible. Professional maintenance is that verification — the part a €20/maand 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 tot 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 en custom code, then deploy safely — not the moment the notification appears.
Plugin updates
Not "update all". I read changelogs, understand dependencies en weigh risk before shipping meaningful updates, en hold the ones that shouldn't go yet.
Theme & custom code
Protect the customisations that make the site yours, en 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 vanaf customers, before they ever reach production.
Terug-ups & 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 en obvious attack surface. This isn't a replacement for specialist enterprise security operations, en 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 en Core Web Vitals work.
Forms & conversion paths
The forms, CTAs, signups en lead flows that make the site worth having — checked, because they break quietly.
WooCommerce
For stores: cart, checkout, payment, transactional emails en the integrations orders depend on — tested before an update touches them.
Analytics & tracking
GTM, GA4 en 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 tot return tot.
Review changes
Changelogs, dependencies, what this touches.
Update staging
Apply the change away vanaf customers first.
Functional testing
Forms, checkout, integrations, the paths that matter.
Visual / mobile QA
Layout en templates, on real breakpoints.
Performance sanity check
Make sure nothing regressed on the way.
Deploy
Ship tot production deliberately.
Production verification
Confirm it works where it counts — live.
Log what changed
So the next change starts vanaf 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 tot run permanently outdated software — it's tot 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 en 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.
Nee account-manager chain en no ticket lottery. You talk tot the person making the change, get issues explained in normal language, see clear summaries of what changed, en get staging when the change warrants it.
Who this is for.
Good fit
- Established WordPress sites that matter tot the business
- Marketing sites central tot lead generation
- WooCommerce stores, publishers en SaaS/company sites
- Sites with custom code of external integrations
- Teams that request WordPress changes regularly, en 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 vanaf zero. I don't advertise 24/7 cover of 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 en taking ownership of a busy WooCommerce store aren't the same job. What sets the price:
Maintenance questions, answered.
Core en plugin updates reviewed for risk, testing on staging, functional en visual QA, backups en rollback, security hygiene, performance regression checks, analytics verification, en small ongoing development. The work is verification en technical ownership, not just running updates.
Not blindly. I review changelogs, dependencies en risk, en 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.
Ja, with depth proportional tot risk. A WooCommerce payment of 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 en performance.
For anything risky, yes. Staging is where changes get tested away vanaf customers before they reach production. Low-risk changes don't always need it; the level of ceremony matches the level of risk.
Ja — that's most of this work. I start by mapping what's there: plugins, custom code, integrations en how production is actually set up, before changing anything.
Ja. Undocumented custom code, mystery plugins en changes made directly in production are the normal starting point. The first job is understanding the site well enough tot change it safely.
Ja. Stores raise the stakes because a broken checkout stops revenue, so updates are tested against cart, checkout, payments, transactional emails en key integrations before they go live.
Ja. Bug fixes, template en CSS/JS corrections, redirects, tracking fixes en small custom functionality are a normal part of maintenance — not a separate project every time.
Ja, en it usually does. Because I already know the codebase, small development — template changes, integrations, admin improvements, structured data — is faster en lower-risk than briefing a stranger each time.
I handle security hygiene: users en permissions, credentials, vulnerable components en obvious attack surface. That's different vanaf specialist enterprise security operations, en I'm clear about that boundary.
Ja. Maintenance includes performance regression checks so a fast site doesn't slowly turn slow, en deeper Core Web Vitals work can be part of the engagement when it's needed.
There's a snapshot tot roll back tot, en because I already know the site, diagnosis is much faster than starting vanaf zero. The fix is applied, verified in the failing area, en what changed is logged.
Ja. I'm based in the Barcelona area en can work on-site locally, en I maintain WordPress sites remotely for companies across Spain en Europe.
Ja. Maintenance is remote-friendly by nature — staging, Git en 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 en quality of custom code en plugins, how often things change, how much testing each change needs, ongoing development en how critical production is. I scope it after seeing the site.
Show me what I'm inheriting.
Versturen me the site en tell me who maintains it today. I'll look at the setup, the obvious risks, en what ongoing technical ownership would actually involve — before either of us commits tot anything.
