The WordPress Maintenance Checklist: Weekly, Monthly, Quarterly

by Francis Rozange | Oct 2, 2026 | WordPress

Four concentric glass rings turning at different speeds around a glowing core

On March 10, 2026, the owner of a WordPress site received a message from their host: the site had updated itself to version 6.9.2, a security release published about an hour and a half earlier. A few minutes later, they posted on the WordPress support forum: every public page was showing blank. The admin worked, the content was intact, but the site no longer existed for its visitors.

A fix release would arrive about eight hours after 6.9.2 was published. And two weeks later, the WordPress Security Team published a retrospective with a sentence that sums it all up: its own checklist was missing a line.

Maintaining a WordPress site takes far more than clicking “Update”: a rhythm, an owner for each task, a tool, and a check after every action. This guide offers that checklist, organized by frequency: what to automate, and what to do every week, every month and every quarter.

Why a schedule rather than a reflex

The pace of updates

WordPress shipped two major releases in 2025, then aimed for three in 2026, roughly one every four months: 7.0 in May, 7.1 in August, 7.2 expected in December. Between majors, minor releases keep coming: the current branch had ten in the first nine months of 2026, seven of them security releases.

Those minor releases install automatically by default. Major releases do too, but only on installs created since WordPress 5.6. Automatic updates for plugins and themes, on the other hand, have to be turned on one by one.

The schedule itself moves. In April 2025, the project announced a single major release per year, because ongoing legal matters were diverting resources; yet 6.9 shipped in December 2025, and the 2026 plan goes back to three releases. Your maintenance checklist cannot rely on a fixed calendar: it has to absorb an update at any moment.

The pace of threats

According to Patchstack’s report published in February 2026, 91% of the new vulnerabilities found in the WordPress world in 2025 affected plugins. Nearly half had no fix when they were published. And about half of the high-impact flaws were exploited within twenty-four hours. A weekly update round is therefore too slow for critical flaws: they belong to automatic updates or a web application firewall.

Our analysis of WordPress vulnerability data covers these figures and their limits in detail.

One owner per line

Each line of the checklist below names an owner. The site owner, or content lead, validates what touches the business. The technician, in-house or a provider, does the work. The host handles what its plan covers, and every task stays assigned to a named person.

The real case: WordPress 6.9.2, a security release and a blank page

The March 2026 episode is documented by official WordPress announcements, the support forum, the Security Team’s retrospective and Search Engine Journal. It concerns WordPress itself, and it teaches more about maintenance than any generic checklist.

An ordinary security release

On March 10, 2026, WordPress released version 6.9.2, fixing ten security flaws. The announcement stated that sites with automatic updates would receive it without doing anything, and that fixes would be backported to older branches as far as version 4.7.

Less than two hours later, a report arrived on the forum: a site hosted at DreamHost, with the Crio theme, was showing blank pages, even the source code was empty. Other users reported the same symptom. A volunteer advised checking the error log and testing a default theme.

The cause and the fix

A little later, John Blackbourn, who led the release, joined the thread: there appeared to be an incompatibility with themes using a certain development framework. Those themes loaded their templates in a way WordPress does not officially support, and a check added in 6.9.2 blocked them. A community member suggested restoring a single file from the previous version.

About eight hours after 6.9.2, version 6.9.3 fixed the problem. The next day, a new report revealed that three of the ten security fixes had not been merged into the 6.9 branch: version 6.9.4 delivered them the same day. All three versions shipped within twenty-four hours, and sites on automatic updates followed with no intervention.

The missing line

On March 25, the Security Team published its retrospective. The missed merges came down to human error, but nothing in the release process independently checked that every fix had been merged. The text admits it: a checklist oversight that had never been spotted. The team announced an update to that checklist, with double verification of merges and a clear rule: no step is skipped without a written reason.

What the story teaches

Minor releases arrive on WordPress’s schedule, not yours: staging cannot stand in front of them, it is the post-update check that protects you.
The admin worked, the public site was empty: only a check of the public pages’ content, or a human looking at the site, catches this kind of outage.
The owner learned of the update from the host: update notifications must be read.
Turning off automatic updates would have been the wrong answer: 6.9.4 brought security fixes the next day.
A checklist is alive: every “do” must be followed by a “check”.

Every day, without you: what to automate

Backups

An automatic daily backup of the database and files, stored off the server, is the foundation of everything else. It is handled by the host or by a plugin, chosen among the WordPress backup plugins we compared. Owner: the host or the technician.

Automatic updates

Keep WordPress minor updates automatic. Turn them on for low-risk, well-maintained plugins too, and keep critical plugins, such as WooCommerce or a page builder, for a manual update after testing. Since WordPress 6.6, a plugin auto-update that causes a fatal PHP error is rolled back and the old version restored. But that safety net only detects fatal errors: a broken layout or a failing checkout slips through.

Uptime, certificate and domain monitoring

A monitoring service checks that the site responds. But the March 2026 episode shows that a responding server is not enough: prefer keyword monitoring, which checks that a specific text appears in the public pages’ code. Jetpack’s free monitor pings the home page every five minutes but only looks at the response code, not the content; UptimeRobot offers fifty free monitors, keyword monitoring included, but keeps certificate and domain monitoring for its paid plans.

Certificate and domain expiry alerts become essential. Let’s Encrypt stopped sending its expiry emails on June 4, 2025, and itself recommends monitoring to catch a renewal that did not happen.

What WordPress already does on its own

WordPress checks for updates twice a day, runs a Site Health scan every week, deletes expired temporary data every day and empties the trash after thirty days. These tasks depend on WP-Cron, though, which only fires with visits: on a low-traffic site, it is better replaced by a real server scheduled task.

Also declare each copy’s environment type with the WP_ENVIRONMENT_TYPE constant: production for the live site, staging for staging. Some plugins use it, such as WooPayments, which only allows test accounts when the constant is set to staging or development, and some Site Health tests, such as the page cache ones, only run in production.

Every week: fifteen to thirty minutes

Updates, with a staging pass

Once a week, the technician reviews pending updates and automatic update emails. What is minor and low-risk goes to production. What is major, for WordPress, WooCommerce or a page builder, goes through a copy of the site first; on an install that also receives major releases automatically, first limit WordPress automatic updates to minor releases. On the command line, a dry run shows what would be updated, as our selection of essential WP-CLI commands explains.

wp core check-update
wp plugin update --all --dry-run

On the day of a security release, you do not wait for the weekly slot: you apply it the same day.

WordPress’s safety nets have their limits. A failed WordPress update has been rolled back since version 3.7, a manual plugin update since 6.3, a plugin auto-update since 6.6. But none of them checks that the home page shows the right content or that checkout works: that check remains human.

After every update: check the public site

After every update, open the site as a visitor would: the home page, a content page, a form, and for a store, the cart and checkout through to payment in test mode. That is the check that would have caught the blank pages of March 2026 within minutes. Also verify the integrity of WordPress files.

wp core verify-checksums

A glance at the alerts

Look over the Site Health dashboard widget and the week’s monitoring alerts. An alert ignored three weeks in a row stops being read: fix its cause or adjust its threshold.

A column of glowing glass tiles with one dark empty slot

Every month: one to two hours

The Site Health review

The Site Health screen, under Tools, sorts its tests into critical issues, recommended improvements and passed tests. Read it in full once a month. It flags in particular a late or failed scheduled task, background updates that are not working, a site discouraging search engines, or autoloaded options that are too large, above 800 KB.

But Site Health checks neither backups, nor certificate expiry, nor domain expiry, nor plugins removed from the directory, nor administrator accounts: that is why the rest of this checklist exists. Our article on WordPress mistakes to avoid covers its most useful signals.

Error logs

Once a month, go through the hosting’s PHP error log, or WordPress’s own if the WP_DEBUG_LOG constant is enabled on the test copy. Repeated warnings often announce the breakage of the next update. Since WordPress 5.2, a fatal error also triggers an email to the admin address, with a link to a recovery mode: one more reason to make sure that address is read.

Broken links and 404 errors

In Search Console, the page indexing report lists URLs returning a 404 error. Google warns that an empty page can also show up there as a “soft 404”. On the site side, the Broken Link Checker plugin, with more than 500,000 installs, scans links online or on your server, and the Redirection plugin, with more than two million installs, lets you redirect lost URLs.

Performance measured in the field

Search Console’s Core Web Vitals report relies on real Chrome data, over a twenty-eight-day window. A monthly review therefore matches its pace. After a significant change, test with PageSpeed Insights, then wait four weeks to confirm in the field, as our guide to Core Web Vitals fixes explains.

The database

Watch the database size in the Site Health Info tab, and the size of autoloaded options in their dedicated test on the Status tab. By default, WordPress keeps an unlimited number of revisions; one line in wp-config.php limits them.

define( 'WP_POST_REVISIONS', 3 );

Expired temporary data is removed with wp transient delete --expired, after a backup. Our guide to WordPress database optimization goes further.

Backups, checked

Once a month, check that the latest off-server copy exists, that it is recent and that its size is plausible. A backup that has been failing silently for three months is a classic.

Every quarter: half a day

The restore test

The US cybersecurity agency CISA recommends testing the backup procedure to make sure data can be restored quickly, fully or partially. Once a quarter, restore the latest backup onto a copy of the site, time the operation, log in and browse the key pages. Several hosts offer direct restoration to a staging site, which makes the exercise simple.

Repeat the test after any change of host or backup tool: until a backup has been restored, nothing proves it works.

The user audit

Start with the list of administrators.

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

The owner validates the list, the technician removes unneeded accounts, reassigning their content. The departure of an employee or a contractor triggers this audit immediately, without waiting for the quarter. Also check open sessions and application passwords, which give access to the REST API and XML-RPC without the main password.

wp user session list admin
wp user application-password list admin

WordPress also asks the administrator to confirm the site’s contact address every six months: do not click without reading, that address receives the alerts.

WordPress keeps no login history: an activity log plugin fills that gap. Our guide to WordPress user roles covers the principle of least privilege in detail.

The example of the UK Electoral Commission, reprimanded by the data protection authority, shows that these boring lines matter. Attackers got in through a mail server whose patches, released months earlier, had not been applied. And an audit then cracked 178 active accounts whose passwords resembled the ones assigned by default.

The plugin and theme audit

WordPress shows nothing when a plugin is removed from the official directory: it appears up to date. In 2024, according to Patchstack, 1,614 plugins and themes were removed from the directory for unpatched flaws. The following command flags closed plugins.

wp plugin list --fields=name,status,version,update,wporg_status

Delete inactive plugins, as Site Health recommends, and replace those not updated for two years, the definition of abandonment Wordfence uses. Our guide to WordPress security hardening complements this audit.

The theme

The 6.9.2 episode showed it: themes that rely on unofficial behavior break first. Every quarter, check that your theme still receives updates, that it is tested with the latest WordPress version, and that your customizations live in a child theme or in the Site Editor, not in the parent theme’s files, which are overwritten at every update.

The PHP version

WordPress recommends PHP 8.3 or higher. PHP 8.2 loses security support on December 31, 2026: if your site still uses it, plan the migration this quarter, after a test on a copy. Our guide to the right PHP version for WordPress details the method.

Certificates and domains

Since March 15, 2026, a public certificate can no longer exceed 200 days of validity; that will drop to 100 days in March 2027, then to 47 days in March 2029. Let’s Encrypt will shorten its certificates to 45 days by 2028. A certificate renewed by hand once a year therefore no longer exists: automate renewal and monitor it.

For the domain, check every quarter that auto-renewal is on at the registrar, that the payment card is valid and that the contacts are still people working at the company. For generic extensions such as .com, expiry reminders are governed by ICANN.

The ICANN rule provides for a reminder about a month before, another about a week before, then a last one within five days after expiry; once the domain is deleted, most generic domains get a thirty-day redemption period. These rules do not automatically apply to country extensions such as .fr, so check your own registry’s rules.

On the certificate side, Let’s Encrypt warns that renewing at a fixed sixty-day interval will no longer be enough with shorter lifetimes. Renewal clients that support ARI ask the authority when to renew: make sure your host’s does.

At every change: keep a maintenance log

Every intervention gets written down: the date, the author, what changed with the versions before and after, the reason, the check performed and the rollback path. Plugins such as Simple History or WP Activity Log, with more than 300,000 installs each, automatically record actions in the admin.

That is exactly the WordPress Security Team’s lesson: a documented checklist, where every skipped step must be justified in writing. Attach the export of the Site Health Info tab every quarter: it captures the site’s technical state on that date.

Tools that run the checklist for several sites

ManageWP, MainWP and WP Umbrella

At the time of writing, in October 2026, ManageWP, whose connector has more than a million installs, offers a free dashboard for unlimited sites, with paid add-ons per site per month: backups, uptime monitoring, reports. MainWP, self-hosted, has a free version and a Pro version at $199 per year for unlimited sites. WP Umbrella charges about €2 per site per month, monitoring and updates included.

Keep an owner behind the tool

These dashboards centralize updates, backups and monitoring. But their connectors are themselves plugins with admin powers over every site: they belong in the plugin audit. And no tool replaces the person who opens the site after an update.

Summary table

Task	Frequency	Owner	Check
Off-server backup	Daily, automatic	Host or technician	Recent copy every month
Keyword, certificate, domain monitoring	Continuous	Technician	Valid recipients every quarter
Updates	Weekly, same day for security	Technician	Public site opened after each update
Site Health	Weekly glance, monthly read	Technician	Quarterly export
Broken links and 404s	Monthly	Content lead	Indexing report
Field performance	Monthly	Technician	Core Web Vitals report
Database	Monthly review and cleanup	Technician	Size and autoloaded options
Restore test	Quarterly	Technician, signed off by the owner	Timed duration
User audit	Quarterly and at every departure	Owner and technician	Administrator list
Plugin audit	Quarterly	Technician	Closed and inactive plugins
PHP, certificates, domain	Quarterly	Technician and owner	Versions and expiry dates

Frequently asked questions

Should I turn on automatic updates for every plugin?

For simple, well-maintained plugins, yes. For those at the heart of the business, such as WooCommerce or a page builder, prefer a manual update after testing on a copy. In every case, keep WordPress minor releases automatic.

Is Site Health enough to monitor a site?

No. It checks the technical configuration, but not backups, certificate or domain expiry, plugins removed from the directory, or availability as seen from outside.

How often should I test a restore?

Once a quarter is a good pace, and after any change of host or backup tool. No standard sets a frequency: what matters is having done it at least once before you need it.

What do 47-day certificates change?

They make manual renewal impossible to keep up with. Already today, with 200 days at most, automatic renewal and an alert on failure are essential.

Do I need staging for minor updates?

No: they arrive automatically and often urgently. The protection is checking the public site right after, and a recent backup to roll back.

What should I do when an update breaks the public site?

Check the error log, test with a default theme on a copy, and search the support forum: others often have the same problem. Restore the backup if needed, but do not turn off security updates.

Conclusion

Solid WordPress maintenance comes down to four rhythms: what is automated every day, the update review every week, health, links, performance and the database every month, and restores, users, plugins, PHP and certificates every quarter. With, on every line, an owner and a check.

The 6.9.2 episode is the best demonstration: even the WordPress Security Team discovered its checklist was missing a line. Yours will evolve too. Start with this one, keep a log, and add a line every time an incident teaches you something.

Sources

LaFactory designs, builds and maintains WordPress and WooCommerce sites, and develops its own plugins. Talk to us about your WordPress project.

Francis Rozange

Former section editor at Libération, he runs LaFactory, an international web agency since 1996.