Twenty-one tasks, grouped by when they are due
The WordPress Maintenance Checklist: 21 Recurring Tasks
Perform every recurring WordPress maintenance task on the interval it is genuinely due, instead of when something breaks. Twenty-one tasks grouped daily, weekly, monthly and quarterly, each with the time it takes and what goes wrong on a site where it gets skipped. Tick them off in the checklist below — it keeps your place between visits.
A WordPress maintenance checklist groups recurring work by how often it is due: daily backups and uptime checks, weekly updates and login reviews, monthly restore tests and performance data, quarterly database, PHP and access audits. Twenty-one tasks, each on a real interval rather than on demand.
Tick what you already do
- A backup job failing for six weeks is discovered during the recovery, not before it
- An overnight outage runs unattended until a customer reports it
- An infection sits live for days, and the search engines find it before you do
- One bad release reaches the live site with no tested rollback, usually during a campaign
- A broken checkout runs for days because nobody opened it after the update
- A brute force campaign runs for a month before anyone reads the log
- Spam accumulates into indexed pages and rogue subscriber accounts
- Enquiries stop arriving and nothing on the site looks broken; this is the most expensive silent failure on the list
- Dead internal links waste crawl budget and dead outbound links date the page
- An untested backup is a hypothesis, and restore failures are found during the disaster
- A performance regression compounds for a quarter before traffic makes it visible
- Indexation problems and manual actions go unnoticed until rankings fall
- A drop caused by a broken tag or a deindexed section runs a full quarter
- Deactivated plugin files stay on disk and stay executable, and they are a recurring entry route
- The site goes down at a moment nobody chose, and a lapsed domain is not fixed by a backup
- Former staff and old contractor accounts keep full access indefinitely
- Tables bloat until the admin crawls and the backup runs past its window
- The host drops support for the version the site runs on, to a deadline you did not set
- Stolen session cookies stay valid, and a permission opened during a fix stays open
- Nobody knows the real recovery time until it is happening, and it is always longer than assumed
- An abandoned plugin stops receiving security patches while staying active on the site
Tick the tasks you already run. Where you stand, what the gaps cost and which ones matter appear here.
How often each task is actually due
| Task group | Interval | What goes wrong when it is skipped |
|---|---|---|
| Backups and the backup log | Daily | A backup that has silently failed for six weeks is discovered during a recovery |
| Uptime and scan review | Daily | An outage or an active infection runs unattended overnight |
| Updates, staged then promoted | Weekly | Version drift makes every subsequent update riskier than the last |
| Login, spam and form checks | Weekly | A brute force campaign runs for a month, and a broken contact form loses enquiries silently |
| Restore test | Monthly | An untested backup is a hope, and the test is the only thing that turns it into a backup |
| Performance and search data | Monthly | A ranking or speed regression is reported by the client rather than found by you |
| Database, PHP and access audit | Quarterly | Tables bloat, and the host drops support for the PHP version the site is running |
| Full recovery drill | Quarterly | Nobody knows how long a real restore takes until it is happening |
The interval is the whole point
Most WordPress maintenance checklists are lists of good ideas. What makes a list usable is not its contents but its schedule: every task carries an interval, and the interval is what turns intention into a routine somebody actually follows.
The twenty-one tasks below are grouped into four cadences — daily, weekly, monthly and quarterly. Daily work is automated and reviewed. Weekly work is where updates happen. Monthly work is verification: restore tests, search data, account audits. Quarterly work is the deep maintenance nobody does under pressure and everybody needs.
The three tasks people skip
Across the sites that arrive here after something has gone wrong, the same three omissions appear.
Nobody reads the backup log. The job is scheduled, the plugin reports success in a dashboard nobody opens, and the archive has been missing the uploads directory since a plugin update in March. The daily task is not taking the backup — it is reading whether the backup happened.
Nobody tests a restore. A backup is a hypothesis until it has been restored somewhere. Once a month, restore it to a scratch environment and open the site. That single hour is the difference between a bad Tuesday and a lost business.
Nobody deletes plugins. Deactivating leaves the files on disk, still reachable, still executable, still carrying whatever vulnerability prompted the deactivation. Delete what is unused.
Staging is the difference between maintenance and gambling
Updating a live site directly works almost every time, which is precisely why people keep doing it. The failure rate is low enough to feel safe and high enough to be certain, over a year, of one broken checkout or one white screen at the worst possible moment.
A staging copy costs twenty minutes a week: apply the updates, load the pages that earn money, promote. The cost of skipping it is not the average week. It is the one week in fifty, and it lands during a campaign.
What a checklist does not do
A checklist standardises the routine so that attention is available for the parts that need judgement. It does not tell you that a plugin author stopped shipping updates eighteen months ago, that a theme is holding the site on an unsupported PHP version, or that the contact form has been posting to a mailbox nobody monitors since someone left.
Those are found by looking, on the quarterly pass, at a site somebody understands. The list keeps the routine from consuming the time that looking requires.
Two items on this list carry most of the risk and most of the benefit: updating without breaking the site, which is where outages come from, and caching, which is where the visible speed comes from. The full set is on the WordPress maintenance guides.
The procedure, step by step
- Start from the interval, not the taskA checklist organised by topic gets read once. A checklist organised by when each item is due gets used, because it answers the only question anyone actually has on a Tuesday morning: what is due today.
- Automate the daily threeBackups, uptime checks and malware scans run unattended. The human task is not performing them — it is reading the result. A backup job reporting failure for six weeks into an inbox nobody opens is the single most common finding on a site that arrives here after a disaster.
- Stage the weekly updatesApply to a copy, load the pages that carry revenue, then promote. Twenty minutes on staging is cheaper than an afternoon rolling back a live checkout, and it is the difference between maintenance and gambling.
- Test one restore every monthRestore a backup to a scratch environment and open the site. Backup software reports success on files it wrote correctly and cannot tell you the archive is missing the uploads directory. Only a restore tells you that.
- Read the search data monthlyCoverage errors, manual actions and Core Web Vitals field data all move slowly enough that monthly is the right cadence, and all three surface problems weeks before traffic reflects them.
- Run one real drill a quarterRestore the entire site somewhere else and time it. The number you get is your actual recovery time, and it is almost always several times the number people assume when they agree to an availability target.
Tools worth using, and what each misses
| Tool | What it does well | What it misses |
|---|---|---|
| UpdraftPlus or BlogVault | Scheduled off-site backups with a workable restore path | Restore testing stays manual, and it is the step that gets skipped |
| Wordfence or Sucuri | File-integrity monitoring and malware scanning | Alert volume trains people to dismiss alerts, and a scan is not a clean-up |
| WP-CLI | Scriptable updates, database optimisation, bulk checks across sites | No visual check — it reports a successful update on a page that renders broken |
| ManageWP or MainWP | One dashboard across a portfolio of sites | Dashboards report that an update ran, not that the site still works |
| Search Console | Coverage, manual actions and Core Web Vitals field data, free | A 28-day lag on vitals, and nothing about the front end you control directly |
When it needs handing over
WordPress price and package specialistsCompare three levels of ongoing WordPress care, priced per month and set out feature by feature so you can see exactly what each tier patches, backs…
More guides
Questions people ask before calling
How long does WordPress maintenance take each month?
Add up the minutes on the checklist above and a single site kept current comes to about ten hours a month. The eight critical tasks account for five and a half of those on their own. Tick what you already do and the tool totals only the gaps. A site left for a year takes far longer, because every deferred update has to be applied and tested against the ones stacked behind it.
Which tasks matter most if I only do three?
Tested off-site backups, staged updates, and reading the results of both. Those three prevent the failures that end in data loss. Everything else on the list prevents slower, cheaper problems.
Can this be fully automated?
The execution, largely. The judgement, no. Automated updates apply patches and also break layouts, and no automation opens the checkout to see whether it still works. Unattended tooling handles the routine and creates the emergencies.
Why delete a plugin instead of deactivating it?
Deactivated plugin files stay on disk and stay executable. A vulnerability in a deactivated plugin remains reachable, and deactivated plugins are a recurring entry route in the compromises we clean up.
How often does the database really need optimising?
Quarterly on most sites. Post revisions, expired transients and orphaned metadata accumulate steadily, and on a site with a heavy page builder or a store they are the difference between an admin that responds and one that crawls.