Your website is not a thing you build once. It’s more like a car — it runs fine for months, and then one day it doesn’t, usually at the worst possible moment.
WordPress sites are made of lots of moving parts that all update themselves on their own schedules. Most of the time that’s fine. Occasionally one of those updates disagrees with another, and something breaks — often the part that takes payments, which is the part nobody checks until a customer emails to say they couldn’t buy anything.
Maintenance & Support means someone is watching. Updates get tested somewhere safe before they touch your live site. Backups are stored somewhere separate and actually tested. Your site is checked around the clock — including whether people can still complete a purchase, not just whether the homepage loads. And when something does go wrong, you have one person to contact who already knows how your site works, with an agreed response time in writing.
1. Core, theme, and plugin updates run on staging first
An update is a code change, and code changes get tested. Every core, theme, and plugin update is applied to a staging clone of your site first, where we check the pages that matter — checkout, forms, key templates — before anything reaches production. If something conflicts, it’s found on a copy nobody can see rather than by a customer trying to pay you.
Updates are batched and scheduled at low-traffic hours, with a documented rollback point for each release window. Where a plugin is abandoned or an update introduces a breaking change, you get told what your options are instead of silently being left on an old version.
2. Off-site backups with tested restores, not just scheduled ones
A backup you have never restored is a hypothesis. Your site is backed up to storage that is physically separate from your hosting account — so a compromised or suspended server doesn’t take the recovery copy with it — with database and files versioned on independent schedules.
Restores are then actually performed, on a recurring basis, into a throwaway environment to prove the archive is complete and the site comes back up intact. Retention is set to a window that matches your business, and you’re told the recovery point and recovery time you’re realistically working with, rather than a vague promise of daily backups.
3. Uptime, error-log, and checkout monitoring with alerts
Homepage monitoring tells you the server is on. It doesn’t tell you the payment gateway started declining every card an hour ago. Monitoring here runs at three levels: external uptime checks from multiple regions, server-side PHP error and fatal-log watching, and synthetic transaction checks that walk the actual purchase path on a schedule.
Alerts are routed to a person, with thresholds tuned so genuine failures are loud and noise stays quiet. You get a short monthly view of what fired, what caused it, and what was changed so it doesn’t fire again.
4. Malware scanning and hardening review
WordPress sites are attacked constantly and impersonally — automated scanners looking for a known vulnerable plugin version, an exposed admin path, or a weak password. Files and database are scanned on a schedule for injected code, unfamiliar admin users, and modified core files, with anything suspicious investigated rather than auto-quarantined.
Alongside that runs a periodic hardening review: user roles and capabilities, file permissions, login protection, disabled file editing, security headers, and removal of plugins that are no longer maintained. If something needs fixing, you get the fix and the reason, ranked by actual risk.
5. Defined response window for site-down and payment failures
Support is only worth having if you know when it arrives. Issues are triaged into agreed severity levels — site down and checkout broken sit at the top with a committed response time, everything else falls into a normal queue — and those windows are written into your agreement rather than implied.
You contact one person who already knows your stack, your hosting, and your customisations, so there’s no re-explaining the site before work starts. Incidents get a short written follow-up covering what failed, what was done, and what changed to prevent a repeat.
Your site is either being maintained or it’s drifting.
Send me the URL and I’ll tell you what’s out of date, what’s exposed, and what would break first — before you commit to anything.