What belongs on a WordPress maintenance checklist? Weekly, monthly and quarterly tasks

If you would rather not own this list, compare it with handing WordPress upkeep to a support team. Below you get the full checklist with a "how to verify" column for every task, the update routine that keeps a site from breaking, and the clauses to demand in a support contract. All figures are as of September 30, 2026.

Short answer: the checklist on one screen

Plugins are where the risk sits. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025. Of those, 91% were in plugins, 9% in themes, and only 6 in core (Patchstack, State of WordPress Security in 2026, as of September 30, 2026). The same report says 46% of vulnerabilities had no fix from the developer in time for public disclosure. So updating is necessary. It is not enough on its own, and the checklist reflects that.

The time column is a rough estimate for a business site with 15–25 plugins and one editor. A WooCommerce store with 60 plugins takes longer. Treat the numbers as a planning floor.

Weekly tasks

Weekly work is about catching failures early. Each task is short, yet skipping one for a month is how small problems stack.

Back up files and the database. WordPress documentation says a backup has two parts, the database and the files, and you need both to restore a typical site (WordPress Advanced Administration, Backups, as of September 30, 2026). The same page suggests weekly backups for smaller sites and daily ones for busy sites. It also recommends keeping at least 3–5 recent backups in different locations. One copy on the same server as the site does not count. If the server dies, the copy dies with it.

How to verify: open the backup log and check both the date and the file size. A 0 KB archive is a failed backup that reported success.

Update on staging first. Apply core, plugin and theme updates to a staging copy. Click through the home page, a form, the cart if you have one, and the admin editor. Then repeat the same versions on production. The update routine gets its own section below.

Check uptime and SSL. An uptime monitor pings the site every few minutes and emails you when it fails. Look at the weekly report, not only the alerts. Also check the certificate expiry date. Let's Encrypt certificates are valid for 90 days by default, and Let's Encrypt recommends renewing them every 60 days (Let's Encrypt FAQ, as of September 30, 2026). Auto-renewal can fail quietly after a DNS or server change. A weekly glance costs nothing.

Test forms and email. Submit your own contact form. Check that the email arrived and did not land in the spam folder. Forms break silently after plugin updates and mail provider changes. You find out weeks later, from a lead who never heard back.

Monthly tasks

Monthly tasks check that the weekly ones actually work.

Test a restore. This is the task people skip. Take last week's backup and restore it to a staging copy. Log in and open the newest post. If you run a store, open the last order. WordPress documentation itself advises backing up automatic backups with a manual one once in a while to confirm the process works (same Backups page). A backup you have never restored is a hope. You learn which one it is on the worst day.

Scan for malware. Run a server-side or plugin scanner. Then look at /wp-content/uploads/ yourself. PHP files in the uploads folder are a classic sign of trouble. If the scan finds something, stop the checklist and follow the steps for what to do if the site is hacked.

Prune plugins, themes and users. Deactivated plugins still sit on disk. Their code can still be reached. Delete what you do not use. Remove users who left the company. Keep a short inventory: plugin name, why it exists, who owns it.

Find 404s and broken links. Check the Pages report in Google Search Console and run a crawler over the site. Fix links that point to deleted pages. Redirect old URLs that still get traffic.

Check speed. Google's "good" thresholds are LCP within 2.5 s, INP of 200 ms or less, and CLS of 0.1 or less, measured at the 75th percentile of page loads (web.dev, Web Vitals, as of September 30, 2026). Compare this month with last month. A new plugin or a heavy hero image usually shows up here first. When a metric slips, work through these Core Web Vitals fixes.

Clean the database. Post revisions, spam comments and expired transients grow the database month by month. Take a backup first, then clear them out.

Quarterly and yearly tasks

These tasks change slowly. But when they go wrong, they go wrong for months before anyone notices.

PHP version. WordPress recommends PHP 8.3 or greater, with MariaDB 10.11+ or MySQL 8.0+ and HTTPS support (WordPress.org Requirements, as of September 30, 2026). The same page notes that older PHP still runs WordPress but has reached end of life. On the PHP side, 8.2 gets security fixes until December 31, 2026, and 8.3 until December 31, 2027 (PHP.net, Supported Versions, as of September 30, 2026). A site on PHP 8.2 has one quarter left, so plan the switch now. Test it on staging, since old plugins break on new PHP.

Roles and two-factor authentication. List every administrator. Each one should be a named person, not "admin" or a shared agency login. Downgrade editors who only publish posts. Turn on 2FA for every admin account through a security plugin or your identity provider.

Premium licenses. A paid plugin with an expired license stops getting updates, and often nobody notices for months. Check each license date and who pays for it. Put renewals in a calendar.

Accessibility. WCAG 2.2 is the current W3C Recommendation, published December 12, 2024 (W3C, WCAG 2.2, as of September 30, 2026). Once a quarter, walk key templates with the keyboard only. Run an automated checker on the home page, a service page, a form and the checkout. Automated tools catch only part of the issues. The keyboard test catches more.

Yearly audit. Once a year, write it down: where the site runs, what every plugin does, which theme files were edited, and whether your support terms still fit. This is the document you hand to whoever works on the site next.

Updates without breaking the site: staging, auto-updates, rollback

Updates are where maintenance goes wrong. The fix is a routine, and it has four parts.

Staging. A staging site is a copy of production on a separate URL, blocked from search engines. Many managed hosts create one in a click. Update there first. Run the same smoke test every time: home page, a key landing page, a form, the checkout, the block editor.

Auto-updates. WordPress has applied minor and security core releases automatically since version 3.7 (WordPress.org, Updating WordPress, as of September 30, 2026). Major releases still need a click. WordPress 5.5, released August 11, 2020, added per-plugin and per-theme auto-update toggles in the admin (WordPress 5.5 "Eckstine", as of September 30, 2026).

So when do you switch plugin auto-updates on? A workable rule:

• Turn on for small, single-purpose plugins with a clean update history and no effect on checkout or forms.
• Turn on for security plugins, where speed matters more than a rare conflict.
• Keep off for page builders, WooCommerce and its extensions, membership plugins and anything that touches payments.
• Keep off if your theme overrides plugin templates. An update can silently outdate them.

Auto-updates run without staging, and that is the trade. You accept a small risk of breakage in exchange for closing a hole faster. Given that 46% of vulnerabilities went public before a fix existed (Patchstack, cited above), speed on the fixes that do exist has real value.

Rollback. Before each update session, take a fresh backup and note the current versions. If production breaks, restore the backup or reinstall the previous plugin version. Write down what broke and why. Next month, that plugin goes on the "staging only" list.

Change log. Keep one line per update: date, component, old version, new version, result. When something breaks three weeks later, the log tells you where to look.

Doing it yourself vs a support contract

Add up the time column. Weekly tasks take about 40–60 minutes, or roughly 3–4 hours a month. Monthly tasks add about 2–2.5 hours. Quarterly and yearly tasks average about 1 hour a month. That puts a small business site at roughly 6–8 hours a month, before any incident. Stores and membership sites need more.

Doing it yourself works when you have a technical person with those hours, and a staging site. It stops working when the checklist slides because a launch took priority. Look at your last three months honestly. Were restores tested? Were updates staged?

If you hand it off, the contract decides what you actually get. The general side of upkeep for any site, and its costs, is covered in general website maintenance costs. For WordPress specifically, ask for these clauses.

One more test. Ask how the vendor proves a backup works. On our side, the support team checks that a backup can actually be restored before touching anything else. Before the first fix, you get a written audit of the install: hosting limits, plugin inventory, theme edits, error logs and security posture. That document is yours whether or not you continue. The price of ongoing work is an estimate after a brief, based on what the audit finds.