Back to writing
WordPress 6 min read

My Monthly WordPress Maintenance Routine (And Why Clients Pay for It)

Most WordPress sites don’t die in a dramatic hack. They decay slowly. A plugin stops getting updates. A backup job silently fails. The database grows.

A form stops sending emails and nobody notices for three months. Then one day something breaks, and the owner discovers the site has been neglected for years.

That’s why I offer maintenance to almost every client I build a site for. Not because it’s an easy upsell, but because I’ve cleaned up too many abandoned sites to believe in “launch and forget.”

Here’s exactly what I do every month, and why each step matters.

Step 1: Check the Backups Before Touching Anything

The first thing I do is confirm that backups exist and are recent. Not “the backup plugin is installed,” but actually looking at the latest backup files and their dates.

Backup jobs fail silently more often than you’d think. Storage fills up, an API token for Google Drive or S3 expires, the host changes something. If I don’t look, I won’t know until the day I need a restore.

Once a quarter, I go further and restore a backup to a staging environment. A backup that has never been restored is only a theory. I’ve seen backup archives that were missing the database entirely, and the client only found out after a crash.

Then, before any updates, I take a fresh manual backup. If an update breaks something, I want a restore point from five minutes ago, not from last night.

Step 2: Updates, Done Carefully

Updates are the heart of maintenance, and also where most damage happens when they’re done carelessly.

My process looks like this. First I check what needs updating and read the changelogs for anything significant, especially major version jumps in WooCommerce, page builders, or plugins that handle payments or forms. A major version can change behavior, and I’d rather know in advance.

For important sites, I run updates on a staging copy first. If staging survives, production gets the same updates. For simple brochure sites, I update production directly, but only right after a backup and only when I have time to check the result.

I update in a sensible order: plugins first, then themes, then core for major releases. Minor core releases update automatically, and I leave that enabled because those are usually security fixes.

After updates, I click through the important parts of the site. Home page, a few key pages, the contact form, the checkout if there’s a shop, the login, the mobile menu. Automated tests would be better, but for small sites a ten-minute manual check catches most problems.

Step 3: Make Sure the Forms Actually Work

This deserves its own step because it fails so often and so quietly.

Contact form emails depend on email delivery, which depends on things outside WordPress: SPF and DKIM records, the host’s mail settings, the SMTP service. Any of these can change. When they do, the form still says “Thank you, your message was sent,” but the email never arrives.

Every month I submit a test through each form and confirm the email reaches the inbox, not spam. I also recommend that every site sends email through a proper SMTP service instead of the server’s default mail function. And I suggest enabling a plugin that logs outgoing emails, so if something goes missing, there’s a record.

For a business that gets leads through its website, a broken form is one of the most expensive problems possible, precisely because nobody notices.

Step 4: Security Review

Once a month, I go through a short security checklist:

I look at the list of administrator accounts. Former employees, old agencies, that “temporary” account created for a freelancer two years ago. If someone no longer needs admin access, it goes. Every extra admin account is another door.

I check the security plugin’s logs for unusual activity: repeated failed logins from the same source, file changes I didn’t make, new users I don’t recognize.

I verify core file integrity. If any WordPress core file has been modified, that’s almost always a sign of a compromise.

I check whether any installed plugin has been closed or abandoned. A plugin removed from the WordPress.org repository, or one that hasn’t been updated in a long time, becomes a candidate for replacement.

Step 5: Performance Check

I run the key pages through PageSpeed Insights and compare with last month. Performance rarely collapses overnight. It erodes. A new plugin, a few large images uploaded by the client, a new tracking script from the marketing team.

If the numbers have dropped, I find out why while the cause is still easy to identify. Waiting a year turns a simple fix into an investigation.

I also check the database size and clean up expired transients and excessive revisions every few months.

Step 6: Uptime and Error Logs

Uptime monitoring runs all the time, but I review the monthly report. Short outages that happened at 3 AM might point to a hosting problem that will get worse.

I also look at the PHP error log. Warnings and deprecation notices are often early signs of trouble: a plugin that isn’t ready for the next PHP version, a theme function that will break in a future update. Fixing these early is much cheaper than fixing them during an emergency.

Step 7: A Short Report for the Client

At the end, I send the client a brief summary: what was updated, whether backups are healthy, any issues found and fixed, and any recommendations, like “this plugin is abandoned, we should replace it in the next few months.”

This report matters more than it might seem. Good maintenance is invisible. When nothing breaks, clients can start to wonder what they’re paying for. The report shows the work that keeps nothing breaking.

Why This Is Worth Paying For

A client once asked why they should pay monthly when “the site works fine.” My answer: it works fine because someone takes care of it.

The cost of regular maintenance is small and predictable. The cost of neglect arrives all at once: a hacked site that needs cleanup, a broken shop during a busy season, months of lost leads from a dead contact form, or a full rebuild because the site is too outdated to update safely.

If you run a WordPress site yourself, you don’t need to hire anyone. But put this routine in your calendar. One or two hours a month is a lot cheaper than one bad day.