The Yearly Quiet-Site Audit for WordPress

Once a year, set aside three hours and run an audit on your WordPress site. Not because it is failing, but because it is not, and you want to keep it that way. The point is to find the small drifts that have accumulated unnoticed before they turn into the visible problems you would otherwise have to fix in a hurry.

This post is the script, with a note on how to prepare, what to write down and what to do with what you find. It assumes a site that is working. If yours is already on fire, start with an incident plan instead and come back to this when things are calm.

Before you start

Prepare in ten minutes. Make sure you have administrator access to WordPress, access to your hosting control panel, access to your domain's DNS settings, and last year's audit report if you wrote one. Take a fresh backup before you touch anything, and if you can, do the checks on a staging copy so that a slip cannot affect visitors.

Open an empty document and keep it open as you go. You are going to write down what you find, and the document you end up with is the most useful output of the whole exercise.

Hour one: inventory

Inventory is about knowing what you have. Most problems on long-lived sites come from things nobody remembers adding.

• Plugins. Open the plugins page and list every plugin. For each one, write a sentence: what does it do, and what would happen if it disappeared tomorrow? If you cannot answer the second part, mark it for review. Remove anything that is inactive.
• Users. Open the user list. Confirm that every administrator belongs to someone who still works with you, and disable the accounts that do not. Check that each remaining account has the smallest role it needs.
• Themes. Confirm that only the active theme and one fallback are installed, and delete the rest. Unused themes still need updates and are still code on your server.
• Files. Look through wp-content/uploads/ for files that are not images, videos or documents. PHP files in that folder are almost always bad news.
• Media. Most sites carry many media files that were uploaded once and never used. They do no harm, but they make backups bigger and the library harder to navigate. If you trust a cleanup tool, use it on a copy first.

Hour two: configuration drift

Drift is the slow movement of settings away from what you intended. Open wp-config.php and confirm four things:

• WP_DEBUG is set to false.
• The database password matches what your password manager holds.
• The secret keys and salts are set to unique values and are not the defaults.
• There are no leftover constants for plugins you have removed.

Next, check the software underneath. Look up your PHP version and compare it with the supported versions list. A version that has dropped off the list no longer receives security fixes, so schedule the upgrade now, on your timetable, rather than waiting for a disclosure to force it. Do the same for WordPress itself: if you are behind the current release, plan the update, test it on staging and apply it. Doing major upgrades on your own schedule beats doing them under pressure.

Check your DNS. Confirm that the records pointing at your host are correct, that the certificate for your domain is valid and renewing automatically, and that the email authentication records for any mail you send (SPF, DKIM and DMARC) are present and valid. These are the records that fail silently when someone changes providers and forgets to update them.

Finally, check your backups. When was the last successful backup? When was the last successful restoration test? If the second answer is "never", book the next hour and run one. A backup you have never restored is a hope, not a control.

Hour three: performance and security

Run a performance report on the homepage and your three most visited pages. Note the server response time, the transfer size and the number of blocking resources, and compare them with last year's notes. If a number has got noticeably worse, find out why before you close the audit. A new plugin or a new tracking script is the usual cause.

Look at your access logs for an ordinary 24 hours. Note the total number of requests, the busiest addresses, how many server errors there were and how many requests hit wp-login.php. A high count of login requests is expected, because automated scanning is routine, and what matters is whether any of them succeed.

Check whatever security logging you have. If you use a security plugin, read its log. If you do not, at least confirm three things: no new administrator accounts you did not create, no unexpected file changes under wp-content/, and no sudden spike in outgoing email.

Confirm that two-factor authentication is enabled on every administrator account, including any added during the year.

What to do with what you find

Sort every finding into one of three buckets, so the audit leads to action instead of a long list:

Write the report

Write a one-page audit report. Yes, an actual document. Give it three sections: what changed since last year, what is working, and what to fix in the next six months. Add the performance numbers you measured so that next year's audit has something to compare against.

Save it where you will find it. Read it next year before you start the audit again. The report is not about paperwork; it is about continuity, so that the person doing the audit next year, who may not be you, does not start from nothing.

Why it is worth the three hours

The point is not the report. The point is the discipline of doing this once a year, every year, while the site is healthy. Most sites that get compromised, drift into poor performance or accumulate operational debt do so in the years when nobody was looking. The audit is the act of looking.

It takes three hours. In almost any given year, you will spend more than three hours wishing you had done it.

Photo: Sydney Sang on Pexels