Most website maintenance checklists are a list of tasks with no sense of priority, which is why they get abandoned by week three. This one is organised by how often each thing actually needs doing, because that is the only version anyone sticks to.
It is written for WordPress, though most of it applies to any CMS.
The Website Maintenance Checklist
| Task | How often | Why it is on the list |
|---|---|---|
| Back up the site offsite and confirm the backup restored | Weekly | An untested backup is a guess. Confirm it works before you need it |
| Update plugins and themes, then load the site | Weekly | 91% of vulnerabilities come from plugins. Loading the site afterwards is the half people skip |
| Check uptime alerts and error logs | Weekly | Catches the failure that started quietly on Tuesday |
| Test the contact form and any booking flow | Monthly | Forms break silently after updates. Nobody reports a form that does not send |
| Review security scan results | Monthly | Malware sits undetected until Google flags the site |
| Check Core Web Vitals and page speed | Monthly | Speed degrades gradually. Monthly checks catch drift before it becomes a rebuild |
| Fix broken links and 404s | Monthly | Accumulates invisibly as external pages move or die |
| Review database size and clean overgrown tables | Quarterly | The single most common cause of a site that got slow for no obvious reason |
| Remove unused plugins and themes entirely | Quarterly | Deactivating removes nothing. The files and their vulnerabilities stay on disk |
| Check SSL certificate expiry | Quarterly | Auto-renewal fails more often than people expect, and the failure is public |
| Audit user accounts and remove old access | Quarterly | Former staff and past contractors frequently still have admin |
| Confirm domain registration and DNS | Annually | An expired domain is the fastest way to lose a business online |
| Review PHP version against what is supported | Annually | Outdated PHP eventually breaks plugins and stops receiving security fixes |
| Test the full restore, not just the backup | Annually | The difference between having backups and being able to recover |
What Most Checklists Get Wrong
Nearly every version of this list treats updating as the whole job. It is not, and the data is unambiguous about why.
Patchstack recorded 11,334 new WordPress vulnerabilities in 2025, up 42% year on year, with 91% originating in plugins and only six in WordPress core, all low priority. So far this supports the update-often advice.
Then the awkward number: 46% of those vulnerabilities were still unpatched on the day they were publicly disclosed. The flaw was announced and no fix existed yet. For nearly half of everything found last year, clicking update achieves nothing, because there is nothing to install.
That is why the list above includes monitoring, account audits and removing unused plugins. Those are the items that matter during the window when an update is not available.
The Signs You Have Skipped Too Many Cycles
| What you notice | What it usually means |
|---|---|
| The site got slow and nothing obvious changed | A database table has grown unchecked, often a log or session table |
| Backups or uploads started failing | The hosting account has hit its inode or storage limit |
| A page looks broken after an update | A plugin conflict nobody checked for, because nobody loaded the site after updating |
| Form submissions stopped arriving | Deliverability or a form plugin update. Usually weeks before anyone notices |
| A browser warning about the certificate | Automatic SSL renewal failed silently |
We have written up the specific database failures in detail, because they are the ones we find most often: WooCommerce session tables in the gigabytes, a backed-up Action Scheduler queue, security logs that were never trimmed, and hosting accounts that ran out of inodes.
None of this needs an expensive toolset. Uptime and spam monitoring, caching and a host that does not oversell its servers cover most of the list between them. We publish the exact stack we use, affiliate links disclosed, on our tools page.
How Long This Takes
On a small site in good condition, the weekly items take about fifteen minutes and the monthly ones under an hour. The quarterly items take longer the first time, because that is when you discover what has been accumulating.
The honest problem is not the time. It is that maintenance is invisible when it works and urgent only when it has not been done, so it loses every scheduling contest against work with a deadline. If the last three months have gone by without any of the above happening, that is the answer about whether to hand it over.
If you are weighing that up, what a WordPress maintenance plan covers and what it costs walks through the comparison, and our managed WordPress hosting covers this schedule.
Website Maintenance Checklist FAQs
What should be on a website maintenance checklist?
Weekly: offsite backups with a restore check, plugin and theme updates followed by loading the site, and a look at uptime and error logs. Monthly: form testing, security scan review, page speed, and broken links. Quarterly: database cleanup, removing unused plugins, SSL expiry and user account audits. Annually: domain and DNS, PHP version, and a full restore test.
How often should a website be maintained?
Updates and backups weekly, functional checks monthly, deeper cleanup quarterly, and infrastructure review annually. The weekly items take about fifteen minutes on a healthy small site. The quarterly items are the ones that decide whether the site is still in good shape in two years.
Is updating plugins enough to keep a site secure?
No. Patchstack found that 46% of the 11,334 WordPress vulnerabilities reported in 2025 were still unpatched on the day they were publicly disclosed. For those, no update exists to install. That is why monitoring, removing unused plugins and auditing user access belong on the list alongside updating.
Does deactivating a plugin make it safe?
No. Deactivating stops the plugin running but leaves every file on disk, including any vulnerable code. Delete plugins and themes you are not using rather than leaving them deactivated.
Why did my website get slow for no reason?
Most often a database table that has grown unchecked, typically a log, session or scheduled-task table that nothing is purging. It is gradual, so there is rarely an obvious change to point at. Checking database size quarterly catches it early.
How do I know if my backups actually work?
Restore one. A backup that has never been restored is an assumption rather than a safeguard, and backup failures are usually discovered at the worst possible moment. Test a full restore at least once a year.
If reading this produced a short list of things nobody has done in a while, that is normal and fixable. Tell us about your site and we will tell you what state it is actually in.
