WordPress Maintenance: The Monthly Checklist (and What an AI Agent Does for You)

Almost every big website failure that seems to come "out of nowhere" is really a date nobody saw: a certificate that expired, a backup that stopped, updates that piled up, a PHP version that fell out of support. WordPress maintenance is simply the habit of looking at those dates before they look at us. In our guide to managing a WordPress site with an AI agent we explained what the care involves and why it matters. Here we get practical: what to check, how often, and who does what.

What is WordPress maintenance? A guard's rounds, not firefighting

Picture a night guard in an office building. He doesn't check everything every hour. He checks the main doors on every round, the electrical room once a week, and starts the generator once a quarter, even when there's no power outage. The generator is the best example: nobody wants to find out during a real outage that it won't start.

Site maintenance works the same way. The difference between a site that breaks once a year and one that doesn't isn't luck. It's a regular round, with a different frequency for each checkpoint.

Weekly WordPress maintenance: five checks that take minutes

Weekly checks are the cheapest there are: they change nothing, they just take a look. That's why they're the first thing we hand to the agent. It looks, verifies, and sends you a short report on Telegram. The table shows what it does on its own and what comes to you.

Two of the checks in the table need explaining, because that's where most surprises are born.

Forms: a "thank you" is not proof. A "Thanks, we got it" page proves only that the page loaded. It doesn't prove the email went out, and certainly not that it reached your inbox rather than spam. The real test is a real message sent and received on the other end. So the agent sends an actual inquiry with an agreed marker and confirms that it came through.

Store: the email is part of the sale. In WooCommerce, an order confirmation that never reaches the customer means a customer calling in a panic. According to the official documentation, most email problems are delivery problems: the server sends, but the email never arrives. It's recommended to send through a dedicated SMTP provider and to make sure the sender address is on your own domain, not Gmail. You can also check the WooCommerce logs (under Status) to see whether the system managed to hand the email off.

Core, plugin and theme updates: the monthly part, after testing

We already laid out the safe update order (backup, test, approval, and only then the live site) in the management guide, so we won't repeat it. What's missing there is the logic of the frequency.

The official WordPress documentation stresses backing up before every upgrade, including the database and all files, and checking afterward whether the deployment went wrong or errors appeared. It also notes that automatic minor core updates have been enabled by default since version 3.7. In other words, WordPress handles the small fixes on its own. Everything else belongs to the month.

Our view: batch updates that aren't security-critical into one window per month, rather than installing them every time a red bubble appears. That gives you one concentrated check instead of ten small ones. A security update for a plugin your site depends on doesn't wait for the end of the month, though; it gets its own window. One more rule: don't update on a Thursday afternoon. If something breaks, you want someone around to fix it.

What the agent checks in the test environment (a copy of the site where you can make mistakes without any customer seeing):

1. The home page, a main service page and a product page load without errors.
2. Every form submits, and a real inquiry arrives.
3. In the store: a product goes into the cart, moves to checkout and reaches the payment step.
4. There's no bad news in Site Health that wasn't there before.
5. The site looks right on mobile, because that's where most visitors are.

If everything passes, you get a Telegram message with what was updated, what was checked and what the risk is. You approve, and the update goes to the live site. If something fails, the live site wasn't touched at all.

Security: users, two-factor authentication and forgotten plugins

Most breaches don't look like the movies. They look like an old plugin nobody uses anymore, or a designer's account from three years ago with a password that was never changed.

The official WordPress hardening guide suggests a few simple steps: keep versions current, use strong passwords and two-factor authentication, delete plugins that aren't in use, and transfer files over SFTP rather than plain FTP. These are exactly the lines of a monthly maintenance round.

• The agent does on its own: produces a list of users with their role and last login date (where the data is available), a list of disabled plugins and themes, and flags unusual changes: a new user with administrator rights that nobody created.
• With your approval: removing a user, deleting a plugin, and turning on two-factor authentication for administrator accounts. The reason: removing a user can cut off an employee mid-task, and deleting an "old" plugin sometimes breaks a page nobody remembered depended on it.

The rule we keep to: the agent never gets your administrator password. It gets its own user, in the narrowest role that is enough, so its access can be shut off without touching your account. More on this structure in the guide to AI agent permissions and security.

Site speed: three numbers worth knowing

"The site is slow" is not a diagnosis. Google defined three measurements, the Core Web Vitals, and according to web.dev a site is considered healthy when it meets all three for 75% of visits, on both mobile and desktop.

Source: web.dev, Core Web Vitals. Thresholds are measured at the 75th percentile of page loads.

Once a month the agent measures the home page and your three most important pages, compares against the previous month and reports the change. The measuring tools are PageSpeed Insights and the Core Web Vitals report in Search Console, both of which rely on field data from real visitors.

What does it not do alone? It doesn't compress images on the live site, switch off a plugin or swap a theme. All of those change what customers see, so it proposes and waits. And if the problem runs deep, like a theme that's simply too heavy, that's already a job for a professional.

Broken links and 404 pages: not every 404 is a problem

Here's a common mistake that costs money: someone sees a list of 404 errors in Search Console, panics, and redirects them all to the home page. That is exactly what Google asks you not to do.

According to Google's help page, 404 errors don't hurt your site's search performance, and you can ignore them when the URL is genuinely not supposed to exist. What is worth fixing:

• A URL you submitted in your sitemap that doesn't exist. Fix the sitemap file.
• Content that moved to a new address. Add a redirect to the new URL.
• Common typos in a URL. You can redirect these to the right page.
• Content that was permanently deleted. Leave a 404 or 410. Don't redirect to the home page, because Google calls that a "soft 404" and it can get in the way of how your site is handled.

The division of labor is simple. The agent scans for broken internal links, reads the Search Console reports and prepares a sorted list: "needs a fix" versus "can be ignored." The redirects themselves, which change how the site behaves, come to you for approval.

What has an expiration date: certificate, domain and PHP version

These things don't break. They expire, which is why they're checked on a calendar.

SSL certificate. Since March 15, 2026, public certificates are valid for 200 days at most (down from 398), and according to the CA/Browser Forum schedule the maximum will keep dropping until it reaches 47 days in 2029. What this means for a small business: manual renewal once a year is no longer a model that works. Whoever manages the site needs automatic renewal, plus a check that it really happens. With Let's Encrypt, for example, a certificate is valid for 90 days and the recommendation is to renew every 60. The agent checks weekly how many days are left and warns well before the end.

Domain. An annual renewal that arrives in an old email inbox. We recommend automatic renewal and an address someone actually reads. The agent reports the expiration date; the payment itself is yours.

PHP version. According to the WordPress requirements page, PHP 8.3 or higher is recommended. And according to php.net, the current support status is:

If your site is still on 8.2, you have until the end of the year. A PHP upgrade is done in your hosting control panel, and it can break an old plugin that was never updated. That's why it's tested first in the test environment and goes through your approval. The agent identifies the version in Site Health, warns you and prepares the test.

Quarterly checks: four checks almost nobody does

The most important checks are the ones that get postponed forever, because nothing breaks while they go undone. Until it does.

The first check deserves more detail. The official WordPress guide recommends a weekly backup for a small site and a daily one for an active site, with several copies stored in different places, including off the server. But a saved backup is only half the story. A failed restore is usually discovered at the worst possible moment. That's why we recommend a full restore to a test environment once a quarter. This is our opinion, not an official requirement, and anyone who skips it can't be sure their backup works.

The checklist: the monthly and quarterly round

Check off what's already done and see how much of the round is covered. Your checkmarks aren't saved anywhere, so you can come back here every month. Every line is labeled with its frequency.

Where an AI agent doesn't replace a professional

This needs saying plainly, because it's where people are tempted to exaggerate. An AI agent is good at recurring checks, reports and preparing a case file. It's less suited to:

• Recovering from a breach. Someone has to identify what got in, clean it up and close the door. That's a security professional's job.
• A failure caused by a conflict between two plugins. The agent can identify when it started and prepare a case file, but it can't always solve it.
• A server move and DNS changes. An external change like this requires explicit approval and planning in advance.
• Any result that looks "too good." A report that says "all fine" with no evidence is a reason for suspicion. A good report attaches the backup date, a screenshot of the form test and the speed numbers.

How to start this month

1. Check three dates: when the last backup was, when the certificate expires, and which PHP version you're running.
2. Send a test inquiry through every form and check that it arrived.
3. Decide who does what: which checks go to the agent and which actions wait for approval. Write it down; don't agree verbally.
4. Start with a month of reports only. No changes. See what your site tells you.

If it's still unclear what such an agent even is, start with the guide to AI agents for business. Want to understand how one is built? There's a step-by-step guide to building an AI agent. And if maintenance is only one of your recurring tasks, ten tasks worth handing to an agent has more ideas.

Frequently asked questions

Sources

• https://developer.wordpress.org/advanced-administration/security/backup/
• https://developer.wordpress.org/advanced-administration/upgrade/upgrading/
• https://developer.wordpress.org/advanced-administration/security/hardening/
• https://wordpress.org/about/requirements/
• https://www.php.net/supported-versions.php
• https://web.dev/articles/vitals
• https://support.google.com/webmasters/answer/2445990
• https://developers.google.com/search/docs/crawling-indexing/http-network-errors
• https://woocommerce.com/document/email-faq/
• https://letsencrypt.org/docs/faq/
• https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/
• https://www.digicert.com/campaigns/tls-ssl-certificate-validity