Get the checklist
Copy this into a doc, a spreadsheet or a project board. It is ordered by cadence, not by importance, because a task that runs continuously and a task that runs monthly are both required, just not on the same day.
- Uptime monitoringContinuous
- BackupsDaily to weekly, scaled to activity
- Update review, core, plugins and themesWeekly
- Security scanning and hardeningOngoing
- Performance checkMonthly
- Database and log cleanupMonthly
Each line names the task and the cadence only. The next section covers what “correctly” means for each one, because a task run on schedule but run wrong is not much better than a task skipped.
If the list above is more than you want to track by hand, see how NoDrama runs this checklist as a managed routine.
Run each task correctly
Updates, staged and tested
A WordPress core update is not a single event on a single day. WordPress’s 2026 release schedule runs three major releases roughly four months apart, and plugins and themes ship on their own separate schedules on top of that. WordPress’s built-in auto-update system, introduced in WordPress 5.5, checks for available plugin and theme updates twice a day by default.
That default check is not the same as a safe default rollout. WordPress’s own documentation on plugin and theme auto-updates says plainly that you may want to make sure you can roll back to a previous version before enabling them. The correct sequence is staging first, live push second, rollback held ready as the fallback if the live push still breaks something the staging test missed.
The update installs on a clone first. Key pages and forms checked there.
→
Passed on staging. The same update goes to production.
→
The fallback path when the live push breaks something staging missed.
Rollback is a fallback path that depends on a recent backup existing, not an automatic or instant recovery.
After any update goes live, confirm the site’s key pages and forms still load and submit correctly. A staging test that passed is not the same evidence as a live push that held.
Backups, matched to how often the site changes
WordPress.org’s own backup guidance sets the cadence by activity rather than by a flat weekly rule for every site: once a week for smaller sites with fewer posts, daily for high-activity sites with a lot of posts.
A backup has to cover both halves of the site to be useful. WordPress.org is direct about this: you need both the database and the files to fully restore a typical WordPress site, not one or the other. Keep 3 to 5 recent backups stored across at least two locations, so a single storage failure does not take out the only copy.
Actually restore from a backup at least once, on a staging copy, rather than trusting that the backup file exists. A backup nobody has restored is a backup nobody has tested.
Security scanning and hardening
A security scan checks the site’s installed core, plugins and themes against databases of known, disclosed vulnerabilities. That is useful and it is also limited: a scan catches what has already been found and published. It does not catch a zero-day, a misconfigured server, or a weak password, because none of those show up in a vulnerability database.
Hardening is a separate layer that sits alongside scanning rather than replacing it: correct file permissions, disabling the in-dashboard file editor, and protecting wp-config.php from being read directly.
Confirm the scan actually ran and produced a dated result, and confirm hardening settings held after the last update. Some updates reset file permissions or reactivate a setting the update assumed was default.
Uptime monitoring
Uptime monitoring answers one question continuously: is the site responding right now. It does not answer why the site is down, and it does not catch a site that returns a page but is broken in a way that does not trip a downtime alert, a checkout that loads but will not process a card, for instance.
Confirm the monitoring alert path itself still works by triggering a test alert periodically, so the first real outage is not also the first time anyone finds out the alert never fires.
Performance and database cleanup
A monthly performance check catches drift before it becomes a pattern: the same page that loaded fine last month, loading slower this month because of an accumulation of plugins, images or database bloat. It’s the comparison against last month’s result, not a single reading, that reveals the drift.
Database cleanup removes what accumulates in the background and nobody deletes on purpose: old post revisions, expired transients, spam comments and orphaned metadata left behind by deactivated plugins. Left alone, these slow database queries and inflate the size of every backup that follows. Take a fresh backup before running any cleanup, since a cleanup tool that deletes the wrong table row is not something you want to discover without a way back.
Confirm the site still loads and functions correctly after cleanup, the same way you would after an update.
What reviewers and auditors actually check
Anyone reviewing whether this routine actually ran, an auditor, an insurer, a new hire taking over the site, checks for evidence rather than intent. That means:
- What updated, and when, with a dated log rather than a memory of “we keep it current”.
- Whether the last backup completed and whether it has ever been restored, not just whether a backup file exists.
- What the last security scan found, and whether anything flagged was addressed.
- Uptime over the review period, as a record rather than an impression.
A routine that ran but left no trace is indistinguishable, to a reviewer, from a routine that never ran.
What this checklist does not cover
This checklist covers the recurring maintenance work. It is not a security incident response plan for something that has already gone wrong, it is not a compliance program for a specific regulatory standard, and it is not a full site rebuild. Those sit on the other side of a boundary this checklist does not try to cover.
Where teams get this wrong
The same three mistakes show up across sites of every size.
A security plugin gets installed once and never checked again.
Installing a scanner is a decision made on one day. Reading its findings is a habit, and the habit is the part that lapses.
Auto-updates get switched on with no backup and no rollback path behind them.
The update mechanism runs on schedule either way. Whether a bad update costs an afternoon or costs nothing depends entirely on whether a rollback exists to fall back on.
A one-off backup gets mistaken for a routine.
Someone took a backup before a big change six months ago, and the site has changed a dozen times since then without another one.
NoDrama runs this exact checklist every month so nobody has to remember to. For what a managed plan actually covers at each pricing tier, see what each plan includes.
Conclusion
A WordPress maintenance routine is six jobs on six different clocks: updates tested before they go live, backups matched to how often the site changes, security scanning paired with hardening, continuous uptime monitoring, a monthly performance check, and regular database cleanup. Running any one of them on the wrong cadence, or running them without a way to verify they held, is how a routine task turns into a surprise.