Practical guides on websites, online stores, and getting found on Google — written for business owners, not developers.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
A WordPress activity log only works if it records the right events, keeps them long enough, and survives an attacker.
Five rogue administrator accounts sat on a client's WordPress site for over a year before anyone noticed. We found them during a hacked-site recovery, and the first question was obvious. When did each one appear?
A WordPress activity log answers that. It's a timestamped record of who changed what on your site, sometimes called an audit trail, and WordPress doesn't keep one by default.
Installing a log plugin takes five minutes. Making it useful takes three decisions: what to log, how long to keep it, and where to store it so an attacker can't wipe it.
WordPress core keeps post revisions, and that's about it. It doesn't record logins, plugin activations, theme switches or role changes. If someone promotes a subscriber to administrator tonight, core won't remember it tomorrow.
An activity log plugin fills that gap. It listens for actions inside WordPress and writes each one to your database, with the user, their role, their IP address, the time and the object they touched. Good plugins also store the value before and after the change.
One note on names. An activity log is a running record. A security audit is a one-time review of your site. You want both, but this guide covers the log.
A busy site logs hundreds of events a week, mostly harmless. These eight are the ones that usually point to a takeover.
Event | Why it matters | Alert |
|---|---|---|
New administrator account | A common first move in a takeover. Our client had five. | Instant |
Role changed to administrator | Same result, with no new account to spot | Instant |
Plugin installed or activated | Our client's backdoor was a plugin that hid itself | Instant |
Theme or plugin file edited in wp-admin | Attackers use the built-in editor to plant code | Instant |
Failed logins, then a success | A brute force attack that worked | Daily digest |
Admin email or password changed | Someone took the account, not just visited it | Instant |
Site settings changed | A new default role or open registration quietly lets people in | Daily digest |
Application password or API key created | Access that survives a password reset | Instant |
Several of these have a fix as well as a warning. Turn off the file editor and the fourth event can't happen at all; we walk through it in how to harden wp-config.php and .htaccess. Lockouts and rate limits blunt the fifth, which our brute force guide covers. The third is how supply chain attacks land on clean sites, and the first two get much easier to spot once you've trimmed who holds which user role.
Leave everything else out of your alerts. Post edits and media uploads matter to editors, but for security they're mostly noise.
Pick one plugin. Two logs on one site just double the noise.
Plugin | Free tier | Default retention | Alerts and off-site copy |
|---|---|---|---|
Simple History | Full log and a weekly email report | 30 days (60 on older installs) | Instant alerts and log forwarding are Premium |
WP Activity Log | Full logging | 3 months, adjustable | Alerts, reports and log mirroring are paid |
Jetpack Activity Log | The 20 most recent events | 30 days on Backup or Security, one year on Complete | Lives in Jetpack Cloud, off your server, but can't be exported |
Choose your plugin from the table.
Install it and check that the first events appear.
Switch off event types you'll never act on. Autosaves and scheduled tasks are the usual noise.
Turn on alerts for every event marked Instant above. Instant alerts are paid on both main plugins, so on a free plan read the Simple History weekly email or the WP Activity Log dashboard widget on a fixed day each week.
Set your retention, using the next section.
Run a trip-wire test. Create a test administrator, confirm the log entry and the alert email, then delete the user.
Our security experts remove malware, fix vulnerabilities, and protect your site.
Plugin defaults run short for a fair reason: logs live in your database and grow. Simple History keeps 30 days on a new install. WP Activity Log keeps three months. Kinsta's guide calls six months fine for most sites.
Security suites aren't much better. We run MalCare on this client's site, and its Activity Log card sits on the dashboard as an ordinary toggle. There's no lock icon, but the feature only exists on Repair (7 days of history) and Fortify (60 days). On the entry plan it just reads "Activity Logging Disabled", which looks like a switch nobody flipped.
Attackers don't work to any of those schedules. On our client's site the oldest rogue account dated back to March 2025. The malware that finally gave the attack away landed in July 2026, about 16 months later. A six month log would have rolled over the break-in long before anyone went looking.
So our rule of thumb is to keep security events (users, roles, plugins, logins and settings) for 12 to 24 months, and let content edits expire after 90 days. If your plugin can't split them, keep everything for 12 months. WP Activity Log lets you change retention for free; Simple History puts that setting behind Premium.
An attacker with administrator access can clear your log or switch the plugin off, and the record disappears exactly when you need it. Three fixes work.
Email alerts to an inbox outside the site. That email is a copy the site can't delete, and even a free weekly digest counts, only slower.
Forward the log off the server to syslog, a webhook or an external database. Simple History and WP Activity Log both sell this as a paid feature.
Use a cloud-side log like Jetpack's.
Also check that the log survives updates. WP Activity Log 5.6.5 broke its Log Viewer with a fatal error on some sites after WordPress 7.1 shipped, and the fix (5.6.6) didn't arrive until 24 August 2026. We open the log after every core update now.
If you already suspect a breach, the log is your timeline. Read it in this order.
Export the log first. Evidence comes before cleanup.
Filter for new users and role changes, oldest first.
Find the first event you don't recognise.
Follow that IP address and that user through the rest of the log.
Check for plugin installs near the same timestamps, then scan the files.
Simple History exports to CSV or JSON. WP Activity Log keeps exports in its paid reports module, so on the free version copy the log table straight from the database.
No log yet? You can still rebuild part of the story. Run wp user list --role=administrator --fields=ID,user_login,user_registered to date every administrator account, then read your server access logs and file modified times.
Sometimes the malware dates itself. On our client's site the attackers named their folders with Unix timestamps. Decoded, the first two landed on 17 July 2026 at 20:30 and 20:32 UTC, and the next wave came 11 hours later at 07:37. Treat clues like these as leads rather than proof, since timestamps can be forged. Our hacked site investigation guide picks up from here.
A log only sees actions that pass through WordPress. It won't see a direct edit to your database, a file changed over SFTP or the host's file manager, or a backdoor that opens its own database connection.
So pair the log with a malware scanner and file integrity checks. The log shows who changed what, and the scanner shows what's now sitting on the server.
Five accounts stayed hidden on our client's site for over a year. A log with a long memory and a same-day alert would have caught the first one within hours. We set up audit trails, test the alerts and review the logs as part of our WordPress security maintenance. If you think someone is already inside, start with our malware removal service.
No. Core keeps post revisions and little else, and WordPress 7.1 didn't change that. You need a plugin to record logins, plugin changes, role changes and settings changes.
Not noticeably. These plugins mostly log admin actions, and Simple History logs nothing on the front end by default. Just watch the log table size.
Keep security events for 12 to 24 months and content edits for about 90 days. Short defaults can delete the evidence before you find the breach.
Yes, if they get administrator access. Send alerts to an inbox they can't reach, or forward the log to an outside service so a copy survives.
Yes. With one administrator, any unexpected event stands out, so the log is easier to read. It matters most when nobody else is supposed to be there.
SEO & Security Expert, AppDeel
Azizul Hakim is an SEO and website security specialist at AppDeel, the agency he founded and where he still handles client work himself. For more than ten years he has helped business owners and eCommerce brands get found in search and keep their websites secure.
Read more posts by Md Azizul Hakim →Does changing the wp_ database prefix stop SQL injection? See what the evidence says, what can break, and when it's still worth doing.
SFTP vs FTP for WordPress: plain FTP sends your password as readable text. See what SFTP fixes, what it doesn't, and how to switch safely.
The exact WordPress file permissions to use: 644 for files, 755 for folders, and what to do differently for wp-config.php. No guesswork, no 777.
A step-by-step guide to hardening wp-config.php and .htaccess in WordPress, with safe syntax for every Apache version and what to do if your host runs Nginx.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
