Monitoring and Audit Logs: Knowing When Something Is Wrong

Most WordPress compromises are not discovered by the site owner. They are discovered by Google flagging the site for malware, by a hosting provider suspending an account for outbound spam, or by a customer complaining that checkout redirects to somewhere strange. By the time any of that happens, the attacker has usually had days or weeks of quiet access. Monitoring closes that gap. It will not stop an attack on its own, but it shortens the distance between “something is wrong” and “I know exactly what changed and when.”

You do not need an enterprise security operations setup to get real value here. Three layers cover most of what matters: uptime monitoring, file-change detection, and activity logs. Add basic log review on top and you have a same-day detection capability with a few hours of setup.

Uptime monitoring: the baseline everyone skips

Uptime monitoring is the easiest layer to set up and the one most site owners still skip. An external service that requests your homepage every few minutes and alerts you on failure catches a wide range of problems: server outages, expired SSL certificates, misconfigured redirects, and yes, some attacks (a defaced homepage, a malicious redirect chain, a site stuck in a crash loop after an infected plugin file is quarantined).

• Check from outside your own network and hosting provider, not just from your office connection.
• Monitor a real page load, not just a TCP ping. A server that accepts connections but serves a fatal PHP error still “looks up” to a simple port check.
• Set alert thresholds that avoid noise. A single failed check might be a blip; two or three consecutive failures is worth waking up for.
• Route alerts somewhere you will actually see promptly: email is fine for low-traffic sites, SMS or a chat webhook is better for anything revenue-generating.

If you run Cloudflare in front of the site, its dashboard also gives you visibility into traffic anomalies, a sudden spike in requests to wp-login.php or xmlrpc.php is a signal worth watching even before it becomes an outage.

File-change detection: catching the thing prevention missed

Hardening reduces the odds of a break-in. File-change detection tells you when one happens anyway. The core idea is simple: WordPress core files, and to a lesser extent plugin and theme files, should not change outside of a deliberate update. When they do change unexpectedly, that is a strong signal.

wp-cli gives you a built-in way to check core integrity against the official WordPress checksums:

wp core verify-checksums

Run this after every core update to confirm nothing was tampered with during the update itself, and run it periodically (a weekly cron job is reasonable) to catch drift. It will flag any core file that does not match the official release, which is exactly what a webshell dropped into wp-includes would trigger.

Plugins and themes do not have an equivalent official checksum registry built into wp-cli, so for those, the practical approach is either a security plugin with a file-change monitoring feature, or your own periodic hash snapshot: generate a checksum of every file in wp-content/plugins and wp-content/themes right after a known-good state, store it somewhere outside the webroot, and diff against it later. A change to a plugin file that was not part of an update you performed is worth investigating immediately, not next week.

Also check for anything scheduled to run that you did not schedule:

wp cron event list --fields=hook,next_run_gmt

Malicious code frequently installs its own cron hooks to re-infect files after cleanup. An unfamiliar hook name in that list is a red flag.

Activity logs: who did what, and when

WordPress does not log user actions by default. There is no built-in record of who logged in, who changed a password, who installed a plugin, or who edited a page, beyond whatever your database happens to retain in post revisions. That absence is a real gap, because when something does go wrong, the first question is always “was this a compromised account or a legitimate admin who made a mistake?” Without a log, you cannot answer that with confidence.

An activity log plugin (there are several well-regarded free and paid options) fills this gap by recording:

• Successful and failed login attempts, with IP address and username tried.
• Password resets and changes to user roles.
• Plugin and theme installs, activations, and deactivations.
• Core, plugin, and theme updates.
• Content changes: post publish/edit/delete, especially on pages that handle payments or forms.

Pair this with the standard hardening levers you should already have in place: strong unique passwords with two-factor authentication, limits on login attempts, XML-RPC disabled if you are not using it, DISALLOW_FILE_EDIT set in wp-config.php to block the theme and plugin editor in the dashboard, and least-privilege roles so contributors and editors are not carrying administrator capabilities they never use. None of that is exciting, but each one narrows the window an attacker can exploit and makes the activity log easier to read, because there are fewer legitimate accounts capable of the actions you are watching for.

Quickly auditing your current admin accounts is a good habit whenever you review logs:

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

If you see an administrator account you do not recognize, or one with a registration date that does not line up with anyone on your team, stop and investigate before doing anything else.

Server and edge logs worth a periodic look

Beyond WordPress itself, two log sources are worth checking on a schedule rather than only during a crisis: the PHP error log (repeated fatal errors from an unfamiliar file path often mean something was dropped into the filesystem that should not be there) and, if you run Cloudflare, the firewall events log, which shows you what the WAF and bot mitigation are already blocking before it ever reaches your origin. If your DDoS resilience depends on keeping the origin IP unpublished, reviewing these edge logs occasionally also confirms traffic is actually routing through Cloudflare and not leaking around it.

Managed hosts vary in how much of this they hand you out of the box. Hosts like ServerBorn run file integrity checks and centralize logging across the stack, which saves you from wiring up your own monitoring infrastructure from scratch, though it is still worth understanding what is being watched and where the alerts land.

Putting it together without drowning in noise

The goal is not to log everything and read nothing. Pick one alerting channel you will actually check, keep the signal-to-noise ratio manageable by tuning thresholds rather than logging every minor event at the same urgency, and review the activity log and checksum results on a fixed cadence, weekly is reasonable for most small to mid-size sites, even when nothing seems wrong. A quiet log you glance at weekly is worth far more than a detailed log nobody ever opens.

The takeaway

Uptime checks tell you the site is reachable. File-change detection tells you the codebase is intact. Activity logs tell you who did what. None of these three things is a substitute for the others, and none of them prevents an attack by itself. Together, they turn a compromise that would otherwise sit undiscovered for weeks into something you catch, and can act on, the same day it happens.