A client once called me on a Monday morning because their homepage had lost its main call-to-action button. Nobody on their team admitted to touching it. The theme hadn’t been updated. No plugin had changed. We spent the better part of an hour comparing revisions and guessing before we found it: a junior marketer had edited a reusable block on Friday afternoon while fixing a typo on a different page, and the change propagated everywhere that block was used. A WordPress activity log would have answered the question instantly.
With an activity log, that would have taken two minutes. Filter by the date, see “User X edited reusable block Y at 16:42”, done.
Activity logs, sometimes called audit trails, are one of the most underrated tools in WordPress management. They help with security investigations, of course, but most of the time they answer much more ordinary questions. Who deactivated that plugin? When did the site title change? Did the developer actually run the update they billed for?
What WordPress records by default
Out of the box, WordPress records very little about who did what.
Post revisions store previous versions of content along with the author of each revision. That’s useful for content, but it doesn’t cover settings, plugins, themes, users or menus. There’s no record of logins, failed logins or password resets. If someone installs a plugin, changes the permalink structure or creates a new administrator, WordPress keeps no history of it at all.
Server access logs show requests, so technically you can see that someone posted to wp-admin/plugins.php at a certain time. But access logs don’t tell you which user it was, what the request did or whether it succeeded. Piecing that together is slow and unreliable.
That gap is what activity log plugins fill.
What a good activity log should capture
Not every event matters equally. A useful log focuses on actions that change the site or affect who has access to it.
Authentication events
- Successful logins, with username, IP address and time
- Failed login attempts, especially for usernames that exist
- Logouts and session terminations
- Password resets and password changes
- Two-factor authentication changes
User and role changes
- New users created, and by whom
- Role changes, especially anyone promoted to administrator or editor
- Users deleted, and what happened to their content
- Profile email changes, which attackers sometimes use to take over accounts
Plugins, themes and core
- Plugins installed, activated, deactivated, updated or deleted
- Themes switched, installed or edited
- WordPress core updates
- File edits through the built-in theme and plugin editors, if those are still enabled
Content and structure
- Posts and pages published, updated, trashed or deleted
- Changes to reusable blocks, synced patterns, menus and widgets
- Media uploads and deletions
- Template and template part edits in block themes
Settings
- Changes to general settings like site URL, admin email and timezone
- Permalink changes
- Reading settings, especially “Discourage search engines from indexing this site”
- Plugin-specific settings for important tools like WooCommerce, SEO plugins and forms
That last point about search engine visibility deserves a mention. I’ve seen several sites drop out of Google because someone ticked that box during a staging copy and it got pushed live. An activity log shows exactly when it changed and who did it.
Choosing an activity log plugin
There are several mature options. They differ mostly in how much they log, how they store it and how much they cost.
Free plugins such as Simple History and WP Activity Log’s free tier cover the essentials: logins, content changes, plugin and theme actions, user changes and core settings. For a small business site, that’s often enough.
Premium versions of these tools add things like email or Slack notifications for specific events, reports, log search, exporting, storing logs in an external database and integration with WooCommerce, forms and other plugins.
When comparing, I look at these points:
- Coverage. Does it log the plugins you actually use? WooCommerce order and product changes, for example, are only logged by some tools.
- Storage. Where are logs kept? Most use custom tables in the WordPress database. Some can send logs to an external service.
- Retention controls. Can you set how long logs are kept? Unlimited retention can bloat the database.
- Search and filtering. When you need the log, you need to find things fast. Filters by user, date, event type and object are essential.
- Performance. Logging adds database writes on every tracked action. Good plugins keep this light. Test on staging if your site is busy.
The weakness of on-site logs
There’s a problem with any log stored inside WordPress itself. If an attacker gains administrator access, they can deactivate the logging plugin or delete the log entries. The record of their actions disappears along with the evidence.
For most sites, that risk is acceptable. The log is mainly there for everyday accountability and minor mysteries. But for sites where security matters a great deal, such as stores, membership sites and anything handling sensitive data, it’s worth sending log events somewhere the WordPress admin can’t reach.
Options include:
- Sending events to an external log service or SIEM via the plugin’s integrations
- Forwarding to syslog on the server, which can then ship to a central log server
- Email or Slack notifications for critical events, so a record exists outside the site even if the log is wiped
Even a simple rule like “email me whenever a new administrator is created or a plugin is installed” gives you an off-site record of the most important changes.
Notifications that people will actually read
Activity logs are passive. They help when you go looking. Notifications make them active, but only if you resist the temptation to alert on everything.
If your phone buzzes every time someone edits a post, you’ll mute the alerts within a week. Then you’ll miss the one that matters.
Alert on events that are rare and significant:
- A new administrator account is created
- An existing user is promoted to administrator
- A plugin or theme is installed or a theme file is edited
- The site URL or admin email changes
- Search engine visibility is turned off
- Several failed logins for an administrator username in a short time
- A login from a new country for an administrator account, if your tool supports it
Everything else can stay in the log for when you need it.
Using the log during an incident
When something goes wrong, the activity log is often the first place I look, before server logs and before the database.
The process is usually the same:
- Establish when the problem started, as precisely as possible. Ask users, check uptime monitoring, look at analytics for a drop.
- Filter the activity log to a window around that time, a few hours either side.
- Look for changes that could plausibly cause the symptom. Plugin updates and settings changes are common culprits.
- Check who made the change and from where. A legitimate change from a known user is a simple conversation. A change from an unfamiliar IP address or user is a security incident.
- Correlate with server logs if you need more detail, using the timestamp and IP address from the activity log.
For security incidents specifically, export the relevant log entries before you start cleaning up. Restoring a backup may roll back the log tables too, and then you lose the record of what happened.
Logs and privacy
Activity logs record personal data: usernames, IP addresses and sometimes email addresses. Under GDPR and similar laws, that’s fine as long as you have a legitimate reason, which security and accountability usually are, and you handle the data responsibly.
A few sensible practices:
- Mention activity logging in your privacy policy, at least for staff and registered users.
- Set a retention period. Ninety days to a year is typical. Keeping logs forever is rarely justified.
- Limit who can view the log. Usually only administrators need access.
- If a user asks for their data to be erased, consider whether log entries need to be included or whether security obligations justify keeping them.
For customer-facing stores and membership sites, check whether customer actions are being logged and whether that’s necessary. Logging every customer login might be overkill for a small shop.
Keeping the log fast and lean
On busy sites, logs grow quickly. A WooCommerce store with hundreds of orders a day and several staff members can generate thousands of entries daily.
To keep it manageable:
- Turn off logging for event types you’ll never use. Many plugins let you exclude events by type or by user role.
- Set an automatic retention limit so old entries are purged.
- If the plugin supports it, store logs in a separate database or external service rather than the main site database.
- Exclude noisy automated events, such as scheduled actions that run every few minutes.
Check the size of the log tables every few months. If they’re growing faster than you expected, tighten the configuration.
A habit worth building
The best time to install an activity log is before you need it. Logs can’t go back in time, so if something goes wrong today and you didn’t have logging yesterday, there’s nothing to look at.
On every site I manage, an activity log is part of the standard setup, alongside backups, uptime monitoring and security hardening. It costs very little, it rarely causes problems and it saves hours of guesswork every time something unexpected happens.
It also has a quieter benefit. When everyone on a team knows changes are recorded, people tend to be a little more careful. Not because they’re being watched, but because accountability is visible. That alone prevents a surprising number of “nobody knows how this happened” Monday mornings. Set up a WordPress activity log today, and future mysteries will take minutes instead of hours.
Frequently asked questions
Will an activity log slow my site down?
For normal sites, no. The plugin writes a small database row when a tracked action happens, and visitors browsing the site don’t trigger any logging. Very busy WooCommerce or membership sites should test on staging and exclude noisy events.
Can I see who changed a specific page?
Yes, both through post revisions and through the activity log. The log adds context, such as the IP address and whether the change came from the editor, Quick Edit or an import.
Do I need an activity log if I’m the only admin?
It’s still useful. You might not remember every change you made, and if your account is ever compromised, the log shows you what the attacker did. Plugins and automated processes also make changes, and the log records those too.
How long should I keep logs?
Ninety days covers most everyday investigations. For sites with compliance obligations or high security requirements, a year is common. Beyond that, export and archive rather than keeping everything in the live database.
