Last year I published a general website maintenance guide. This year I wanted to write something different — not a checklist you can find on any hosting company’s blog, but a practical guide based on what I’ve actually learned managing over 70 WordPress sites for UK agencies and businesses.
This is what matters in 2026 if you’re running WordPress seriously.
Security Is Not a Plugin — It’s a Practice
Most WordPress security guides tell you to install Wordfence and call it a day. That’s a start, but it’s not enough.
In January 2026, I dealt with a server that had been compromised by a cryptominer. The attacker didn’t exploit WordPress at all — they got in through a default SSH key left on the server. Once inside, they installed 14 separate persistence mechanisms: cron jobs in /etc/cron.d/, systemd services, init.d scripts, and even protected their malware files with immutable attributes so standard rm commands wouldn’t work. The miner hid from ps output by rapidly spawning and killing processes.
The point isn’t the technical detail (though I’ve written about the full incident response on WP Maintenance PRO). The point is that WordPress security starts at the server level, not the plugin level.
What actually matters for WordPress security in 2026:
Enforce SSH key-only authentication and disable password login entirely. Remove any default keys that came with your server provider — these are publicly known and actively scanned for. Enable two-factor authentication on every WordPress admin account, not just the main one. I recently sent a security enhancement email to all my clients after the M&S and JLR breaches, and the response was overwhelmingly positive — most site owners simply don’t think about 2FA until someone prompts them.
Audit your server’s user accounts regularly. Run cat /etc/passwd | grep -v nologin and make sure you recognise every account with a shell. Check for unauthorised SSH keys in /root/.ssh/authorized_keys and any user home directories.
Keep your server software updated independently of WordPress. Ubuntu 24.04 LTS is the right choice for production servers in 2026 — avoid non-LTS releases like 25.04 which only get 9 months of support.
For a deeper look at our security monitoring approach, including incident response and post-breach hardening, see our dedicated security page.
Database Performance Will Make or Break Your WooCommerce Site
If you’re running WooCommerce, your database is your single biggest risk. I’ve seen sites where a single table — wp_options — brought down an entire server.
The pattern is almost always the same: WooCommerce stores transient data (cached calculations like product category counts) in the wp_options table. Under load, multiple PHP workers try to update the same row simultaneously. This creates lock contention — queries that should take milliseconds start taking minutes because they’re waiting for each other. I’ve measured individual queries running for 376 seconds on a client site. MariaDB was consuming 1,479% CPU and 21.4GB of RAM. The site was completely unresponsive.
The fix wasn’t complicated, but it required understanding the root cause rather than just restarting services. Installing Redis as an object cache moved transient storage out of the database entirely. Converting tables from MyISAM to InnoDB enabled row-level locking instead of table-level locking. Adding the correct indexes to wp_options (which should exist by default but sometimes don’t) resolved the query performance. And critically, tuning PHP-FPM’s pm.max_children setting prevented the worker explosion that amplified the problem.
I’ve written about this in detail: WooCommerce Database Meltdown — From 376-Second Queries to Under 1 Second.
Monthly database maintenance that actually matters:
Run mysqlcheck --optimize on your WordPress tables to reclaim space from deleted rows. Clean up post revisions — a site with 5 years of content can have tens of thousands of revisions consuming gigabytes. Clear expired transients with wp transient delete --expired. Monitor your slow query log regularly — enable it with long_query_time = 2 in your MySQL/MariaDB config and review it weekly.
For WooCommerce specifically, keep an eye on the Action Scheduler tables (wp_actionscheduler_actions and wp_actionscheduler_logs). These grow indefinitely and can reach millions of rows. Clean completed actions older than 30 days. My Failed Actions Monitor plugin can alert you when scheduled tasks fail, which is often the first sign of database trouble.
If you need help with WordPress database optimisation, we offer both one-off performance audits and ongoing monitoring.
PHP-FPM Tuning: The Setting Nobody Configures
Here’s something that almost no WordPress maintenance guide mentions: your PHP-FPM configuration is probably wrong.
Most servers ship with pm.max_children set to something like 50. That sounds fine until you do the maths. Each PHP-FPM worker on a WordPress site consumes roughly 50-150MB of RAM. On a 4GB server, 50 workers could theoretically consume 7.5GB — nearly double your available memory.
Under normal traffic, this isn’t a problem because only a few workers are active. But during a traffic spike — or worse, during a DDoS attack — the server spawns workers until it runs out of RAM. The Linux OOM killer then terminates the largest process, which is usually your database. Your site goes down, your database potentially corrupts, and the error logs just say “MariaDB service was killed.”
I see this at least once a quarter across the sites I manage. The fix takes five minutes:
Calculate your pm.max_children like this: take your available RAM, subtract what MySQL/MariaDB and the OS need (roughly 1-1.5GB combined), and divide by the average worker size (usually around 80-100MB for WordPress). On a 4GB server, that gives you 15-20 workers maximum, not 50.
Set pm.max_requests = 500 so workers recycle periodically, preventing memory leaks from poorly-coded plugins from accumulating over time.
I wrote about a real incident where this exact scenario played out: PHP-FPM Worker Exhaustion — When a DDoS Kills Your Database.
This is the kind of server-level optimisation that’s included in our WordPress server management service.
Updates: The Boring Part That Breaks Things
Everyone knows you should keep WordPress, plugins, and themes updated. Fewer people know how to do it without breaking things.
The biggest mistakes I see:
Automatic updates without staging. WordPress now auto-updates minor releases by default, and some hosts enable auto-updates for plugins too. This is fine for simple brochure sites. For WooCommerce stores processing orders, it’s a risk. One plugin update during a sale period can take your checkout offline.
Not testing after updates. Updating isn’t the task — verifying is. After every update batch, check the checkout flow end-to-end, verify that forms submit, confirm that payment gateways process test transactions, and review the error log for new PHP warnings.
Ignoring PHP version compatibility. PHP 8.3 is the current standard for WordPress in 2026. If you’re still on 8.1 or earlier, you’re missing both performance improvements and security patches. But upgrading PHP without testing will break sites that use deprecated functions — I still see get_magic_quotes_gpc() calls in legacy plugins, which was removed back in PHP 5.4.
The approach I use for my managed sites: updates happen weekly on a fixed schedule. I review changelogs before applying. Critical security patches go out same-day regardless of schedule. And every site has a backup taken immediately before updates, verified as restorable.
Backups: The One You Don’t Test Doesn’t Exist
Daily backups are table stakes. But a backup you’ve never tested restoring is a false sense of security.
Every month, pick a random site from your portfolio and restore its backup to a staging environment. Time how long the process takes. Verify the restore is complete — check the database, check the uploads folder, check that the site actually loads. If you can’t restore a backup in under an hour, your backup strategy needs work.
Store backups off-server and ideally off-provider. If your server gets compromised (or your hosting provider has an outage), your backups need to be somewhere else entirely. Encrypted, GDPR-compliant storage with at least 30 days retention.
For the sites I manage, we maintain 50-day backup retention with daily automated backups, and restoration is included at no additional cost. This is part of every WordPress care plan we offer.
Monitoring: Know Before Your Client Tells You
The worst way to discover your site is down is an email from your client. The second worst way is a phone call.
Set up proactive monitoring using tools like Uptime Kuma (which I use for all my managed sites), paired with Healthchecks.io for cron job monitoring and Telegraf + InfluxDB + Grafana for server metrics.
What to monitor at minimum: HTTP response code and response time for your homepage. SSL certificate expiry. Disk usage (WordPress uploads grow silently). Database size growth. PHP error log for new fatal errors. WooCommerce Action Scheduler for backed-up or failed jobs.
The goal is to catch problems during the “slow degradation” phase, before they become the “site is down” phase. A database that’s growing by 500MB a month will eventually fill the disk. A slow query that takes 3 seconds today will take 30 seconds when traffic doubles.
The Maintenance Schedule That Actually Works
After managing 70+ sites, here’s the schedule I’ve settled on. It’s not the most comprehensive possible — it’s the one that actually gets done consistently without consuming entire days.
Daily (automated): Backups run and verify. Uptime monitoring checks every 60 seconds. Security scanning runs. Error logs are reviewed for new fatal errors.
Weekly (manual, 15-20 minutes per site): WordPress core, plugin, and theme updates — applied, tested, and verified. Quick review of site performance metrics. Check Action Scheduler for failed or backed-up jobs.
Monthly (manual, 30-60 minutes per site): Full security scan including server-level checks. Database optimisation — clean transients, optimise tables, review slow query log. Review disk usage and clean up unnecessary files. Performance audit — check Core Web Vitals, identify any new bottlenecks. Generate and send maintenance report to client.
Quarterly: PHP version review — are we on the latest stable version? Server software updates — OS patches, MariaDB/MySQL updates, Redis updates. SSL certificate audit across all sites. Review and update firewall rules. Test a backup restoration.
When to Get Help
If you’re a site owner running one or two WordPress sites, you can probably handle the basics yourself with a good checklist and some discipline.
If you’re an agency managing client sites, or you’re running WooCommerce with real revenue at stake, the cost of getting maintenance wrong is significantly higher than the cost of having someone handle it properly. A single WooCommerce outage during a busy period can cost more than a year of maintenance.
We offer WordPress care plans from £27.99/month covering everything in this guide — updates, backups, security monitoring, uptime monitoring, and performance optimisation. For WooCommerce sites, our WooCommerce maintenance plans include specialist support for payment gateways, subscription management, and database performance.
For agencies looking to offload maintenance for their client portfolio, we offer dedicated agency partnerships with white-label options.
And if something’s already broken — site down, hacked, database corrupted — our emergency support service starts at £50/hour with a no fix, no fee guarantee.
This guide is updated annually based on real experience managing WordPress sites for UK agencies and businesses. For the previous version, see Essential Steps for 2025. For questions or to discuss your maintenance needs, get in touch.
Photo by Justin Morgan on Unsplash
