There is a version of the “your site is down” message that is much worse than downtime. It is a client forwarding you an email from their host, a customer, or Google Search Console, saying their site is sending spam, redirecting visitors somewhere strange or showing a security warning. By then the problem has usually been there for days.
WordPress security monitoring exists to close that gap. Instead of waiting for someone else to notice, it watches the parts of a site that change when an attacker gets in, and tells you the moment they do. This article covers what to watch, how we do it with WPCentrify, and what to do in the first hour after an alert.
The message worse than downtime
Downtime is loud. The site stops answering, an uptime monitor notices within a minute, and you start fixing it. A compromised site is quiet. It keeps loading and looks normal to its owner, while it:
- serves spam links or pages that only search engines see;
- redirects mobile visitors, or visitors from Google, to another site;
- sends email from your domain, which damages your sender reputation;
- collects form or card details through an injected script;
- quietly creates an administrator account so the attacker can come back.
Each day that goes unnoticed makes the clean-up harder. Search engines may flag the site, hosts may suspend it, and the backups you would restore from may already contain the problem. The point of monitoring is not only to block attacks; it is to shorten the time between something changing and someone knowing.
Prevention and detection are different jobs
Most WordPress security advice is about prevention: strong passwords, two-factor authentication, prompt updates, a firewall, fewer plugins. All of it matters, and the WordPress hardening guide (opens in a new tab) is a good reference. But no prevention is perfect. A plugin vulnerability can be exploited before a patch exists, or a reused password can leak elsewhere. Detection is what limits the damage when prevention fails.
What to watch: files, admins, sign-ins and uploads
You do not need to watch everything. Four signals cover most of what changes during a real compromise.
Files
WordPress core files should only change when WordPress is updated. Plugin and theme files should only change when those are updated. Anything else, such as a new PHP file in a theme folder or a modified wp-config.php, deserves a look.
WordPress file integrity monitoring compares files with a known-good state and alerts on files that were added, changed or removed outside an update. Attackers almost always need to write a file to keep access, which makes this one of the earliest warnings you can get.
Administrator accounts
A new administrator is one of the clearest signs of a compromise, because it is how attackers make sure they can return after you change passwords. WordPress admin alerts should fire whenever:
- a new user is created with the administrator role;
- an existing user is promoted to administrator;
- an administrator’s email address is changed.
On a small business site, any of these is rare enough that every alert is worth reading.
Sign-ins
Watch for patterns rather than single events:
- many failed attempts on one account, followed by a success;
- a sign-in from a country or network the account has never used;
- sign-ins at unusual times for that user;
- several accounts signing in from the same unfamiliar address.
A guessed password that works is the alert you most want to see early.
Uploads
The media library and upload forms are a common way in. An image upload that is actually a script, or a file with a double extension, can give an attacker a foothold. Monitoring should flag executable files in the uploads folder, where they never belong.
What else helps
- Vulnerability matching. Knowing which installed plugin versions have known vulnerabilities lets you patch before anyone exploits them.
- An activity log. A record of who changed what, and when, turns “something is wrong” into a timeline you can act on.
- Off-site backups. If the site has to be rolled back, the backup must live somewhere the attacker could not reach.
How WPCentrify Sentinel alerts you
WPCentrify is our own WordPress management platform, and it is what we use to look after client sites. Its security monitoring is called Sentinel. It covers the four signals above:
- File integrity: alerts when files change outside an update.
- New admins: alerts when an administrator account appears.
- Sign-ins: alerts on sign-in activity, including a guessed password that worked.
- Upload shield: watches files arriving through uploads.
Around Sentinel, the platform adds the pieces that make an alert useful:
| Need | What WPCentrify provides |
|---|---|
| Know which plugins are risky | Vulnerability scanning across every site, matched to installed versions and ranked by exposure |
| See what happened | An activity log for each site |
| Get back to a clean state | Encrypted off-site backups with one-click restore |
| Avoid making it worse | A restore point before every action that changes a site |
| Reach the right person | Integrations with email, SMS, Slack, Microsoft Teams and Discord |
Because every site sits in one dashboard, alerts for the whole portfolio arrive in one place rather than in forty different plugin inboxes, and one-click login takes you straight into the affected site.
How the connection is secured
Handing a platform access to every site you manage is a fair thing to worry about. WPCentrify connects through a small connector plugin on each site. The connector uses a scoped key rather than your admin password, and you can deactivate it from WordPress at any time. The site stays on its existing host; WPCentrify works with WP Engine, Kinsta, SiteGround, Cloudways, Hostinger, cPanel and Plesk servers and others.
Sentinel is part of how our WordPress management service works day to day. You can read more about the platform itself on our WPCentrify page.
What to do when an alert fires
An alert is only useful if someone knows what to do with it. Here is the first-hour routine we follow.
- Confirm it. Check the activity log. Was the new file part of an update someone ran? Did a colleague create that admin account? Most alerts have an innocent explanation, and you should be able to rule it in or out in minutes.
- Contain it. If the change is not legitimate, remove the unknown administrator, reset passwords for every admin account, and end all active sessions. If the site is serving anything harmful, put it into maintenance mode.
- Find the way in. Look at what changed just before the alert: a plugin update, a new plugin, a sign-in from an unfamiliar location. Check the vulnerability scan for the installed versions.
- Clean or restore. If you know exactly which files changed, replace them with clean copies. If you do not, restore from an off-site backup taken before the first sign of trouble, then reapply legitimate changes made since.
- Close the hole. Update or remove the vulnerable plugin, turn on two-factor authentication, and rotate any keys or passwords stored in the site.
- Check what others see. Look at Search Console’s Security Issues report, check that the site is not on email blocklists, and request a review if Google flagged it.
- Write it down. Record what happened and what you changed. The next alert will be faster to handle.
Decide who gets which alert
Not every alert needs to wake someone up. A sensible split for a small business site:
- Immediately, to a person: new administrator, a guessed password that worked, executable file in uploads.
- Same day: changed core or plugin files outside an update, repeated failed sign-ins.
- Weekly review: routine sign-ins and the activity log.
Security monitoring sits alongside the rest of routine care: updates, backups, uptime checks and speed. If you would rather not run that rota yourself, our WordPress management plans cover it on WPCentrify, and our WordPress maintenance checklist sets out the full schedule if you are doing it in-house.