A WordPress maintenance checklist for weekly, monthly and quarterly work
A WordPress maintenance checklist should tell someone what to verify and what evidence to keep. Check backup completion and essential visitor actions weekly, review updates and configuration monthly, and rehearse recovery quarterly. Adjust the cadence to how much content or transactional data the business can afford to lose. Apply urgent security fixes according to exposure instead of waiting for the next calendar slot.
WordPress maintenance checklist by frequency
| When | Work | Evidence to keep |
|---|---|---|
| Weekly | Check backups, update notices, errors and primary visitor workflow | Timestamp, backup location, action attempted and observed result |
| Monthly | Rehearse updates, review account access, inspect scheduled jobs and site health | Versions, staging result, rollback point and owner |
| Quarterly | Restore a backup, test handover and review external dependencies | Restore time, recovered data, missing items and follow-up date |
| After a release or incident | Repeat the affected checks immediately | Before/after state and verification of the specific change |
These intervals are a starting operating schedule. A store that takes orders all day needs shorter recovery intervals than a brochure site that changes once a month. Write down the acceptable age of a restored database and the acceptable time to get online. Those two decisions determine how often to back up and how much recovery practice is needed.
Weekly: find failures while they are still small
Check a completed backup. Record the most recent successful database backup and file backup, their timestamps and where the copies live. Look past a green scheduler icon: confirm the resulting files exist, have plausible size and can be accessed by the recovery owner. An expired cloud credential can stop uploads while a local job still appears to run. Keep an appropriately protected copy outside the hosting account.
Follow the business's primary path. Start signed out at the homepage, navigate to a service or product and reach the action people use. For an inquiry form, periodically send a clearly identified controlled submission with permission. Confirm storage or receipt, the expected recipient and the visitor confirmation. For a store, use staging and the payment provider's sandbox to check checkout. Don't turn a routine check into a live charge or send test email to actual customers.
Review recent alerts and errors. Check unexpected admin accounts, repeated application errors, failed scheduled jobs and reports from real users. A recurring error on a receipt page matters even when the homepage looks healthy. Record the affected URL and time before clearing logs or caches. Escalate suspected compromise promptly. The defacement recovery guide explains what evidence to preserve first.
Look at available updates. Identify the affected core, theme or extension and read its release notes. Treat an actively exploited vulnerability differently from a visual enhancement. Check whether automatic updates already ran and repeat the workflow most likely to be affected. Keep the person responsible for updates and the person able to restore a backup identifiable even during a holiday.
Monthly: maintain the application and its dependencies
Test the planned updates on a copy with representative content and the same relevant PHP version. Confirm a backup and rollback route before changing production. Run through sign-in, editing, media uploads, forms, checkout or bookings as appropriate. Watch the browser console and PHP logs for new errors. For a major change, keep dependent changes in an order you can trace. WordPress's updating guide describes core update procedures and recovery from an interrupted update.
Open Tools → Site Health and review changes since the previous check. The Site Health documentation distinguishes status checks from configuration information. Prioritize findings by their effect on the site. An unavailable loopback request can affect scheduled work, while an optional recommendation may have little relevance to that installation. Keep sensitive configuration information out of public support posts.
Review plugins, themes and tasks nobody recognizes. Determine what each one supplies before removing it. A plugin may generate a rarely used year-end export or a shortcode on an older landing page. Search for its blocks, shortcodes and integrations on staging, and keep the original package and configuration available for rollback. Review administrator accounts, agency access, API integrations and renewal ownership. Remove unnecessary access through the site's normal account procedure and document who made the change.
Inspect recurring tasks whose failure accumulates silently: scheduled posts, transactional email, payment notifications, backups and certificate renewals. Compare one known event with its expected outcome. For example, a form record in the database with no email in a controlled inbox isolates a different failure from a form that never saved. If wp-admin alone becomes sluggish, the slow dashboard guide explains how to capture the specific request.
Quarterly: prove the backup can be restored
- Pick a recent backup and restore it into an isolated environment. Prevent outgoing email, production payment calls and public indexing before opening the copy. Never restore over the only live site to learn whether a backup works.
- Recover the database, uploads, configuration and custom code. Record which credentials or keys had to come from a separate vault. A database dump without the matching uploaded media will restore pages containing broken images.
- Open an old and a recent post, load an image, check a private test account and inspect a recent representative business record. Compare a known timestamp or count with the backup's stated recovery point. Record discrepancies.
- Time the procedure from access to a usable restored site. Include the time needed to locate the backup, gain access and reconstruct external settings. Write down the next change that would shorten a real recovery.
- Confirm who controls the registrar, DNS, host, email, backups, software licenses and payment accounts. Test access through the approved recovery mechanism. The handover document should point to the password manager, not contain passwords or recovery codes.
The WordPress site maintenance guide covers backups and ongoing housekeeping. A successful rehearsal proves the particular backup and procedure you exercised. Repeat after changing hosts, backup providers or the site's storage layout.
Keep a log someone else can use
A row with date, task, result, evidence, owner and next action is enough. “Backup completed at 02:10; restored on staging; last order present was Tuesday's final order” tells the next maintainer more than “backup OK.” Give failed checks a named owner and a retest date. Keep private record identifiers and personal data in the appropriate restricted system.
If maintenance is delegated, agree who applies emergency fixes, how restoration is authorized and which forms or payment flows the provider verifies. For plan scope and current pricing, see WordPress maintenance. The checklist remains usable whether the operator is an internal administrator, a developer or an outside provider.