WordPress Activity Log: Who Changed What, and Why You Need One
A page vanished, a setting flipped, a user appeared. Without a log you are guessing. With one you have a timeline, a name and a time.
On this page
A WordPress activity log is a record of who did what on your site and when: logins, failed logins, posts published or deleted, settings changed, plugins activated, users created or promoted. WordPress does not keep one. The moment something goes wrong, a vanished page, a changed homepage, a mystery admin account, you are left guessing. A log turns the guess into a timeline. Here is what one should record, what it should leave out, and how to run one without creating a privacy problem.
What WordPress remembers on its own
Almost nothing. Post revisions show how a post’s content changed and who saved each version. That is it. There is no record of:
- Who logged in, from where, or who failed to log in
- Which settings were changed, or what the old value was
- When a plugin or theme was activated, deactivated, updated or deleted
- When a user was created, deleted or given a new role
- When a page, media file or comment was trashed
So when a client asks “who deleted the pricing page”, the honest answer without a log is “I do not know”. That is an uncomfortable answer to give.
What a good log records
The events that matter fall into three groups.
Accounts. Logins and failed logins with the IP address, logouts, password resets, user creation and deletion, role changes, profile email changes. These are the events that reveal a compromised account.
Content. Posts and pages created, published, updated, trashed and restored; media uploaded or deleted; comments approved or removed; menu changes. These answer the “what happened to my page” questions.
Settings and site. Options changed, with the old and new values where sensible; plugins and themes installed, activated, updated or removed; WordPress core updates; new scheduled tasks. These are where a hack or a misconfiguration leaves footprints.
Each entry needs four fields: the user, the action, the object (which post, which option, which plugin) and the timestamp. An IP address for login events is useful. Beyond that, more data is not better; it is just more to store and more to protect.
Filters, search and export are the whole product
A log you cannot query is a wall of text. The three things you will actually do with it:
- Filter by user or by event type. “Everything this account did last week” is the most common security question.
- Search by object. “Every event touching the Pricing page” or “every change to the siteurl option.”
- Export to CSV. For handing to a client, a developer or, in bad cases, your host or insurer.
DevDome Activity Log covers these: a local audit trail for account, content and settings changes, filters and search in the admin, CSV export, and a 90-day default retention you can adjust. All of its features are free and no account is needed. We make it, so weigh that; the feature list is what to look for in any log.
Keep it bounded
Two settings decide whether a log stays useful or becomes a liability.
Retention. Ninety days covers nearly every real investigation. Most hacks are noticed within weeks, most content mistakes within days. A log that keeps two years of events is slow to search and a larger privacy exposure for no benefit. Set a window and let old rows expire.
Scope. Log actions, not content. The log should say a password was changed, never what it was changed to. It should say a private field was edited, not what the field contained. Anonymising or dropping IP addresses after a short period is a reasonable extra step.
The privacy side
Logging what your own contributors do on your own site for security purposes is generally defensible, but it is still processing personal data about them. Three habits keep you on the right side:
- Tell your team and contributors the log exists and why.
- Record only what you need and keep it only as long as you need it.
- Protect the log like the rest of the admin: it is visible to administrators only.
If your contributors are in the EU or UK, this is the kind of thing a privacy notice should mention. That is not legal advice; it is the shape of what the regulators publish.
When the log earns its keep
Three situations, all common:
The mystery admin. A new administrator account appears. The log shows which account created it and when. That account’s login from an unfamiliar IP the day before tells you where the compromise started.
The vanished page. A client calls about a missing page. The log shows an editor trashed it on Tuesday. Restore it from the trash, no drama.
The broken site after an update. Five plugins updated overnight and the checkout stopped working. The log lists exactly which five, in order. Roll back the last one first.
In every case the log is only useful because it was already running. Install it on a quiet day, not after the incident.
Pair it with a scanner
An activity log sees actions taken through WordPress. It cannot see a file uploaded through a vulnerability or edited over FTP. A malware scanner that verifies files against their official copies covers that gap. Together they answer both halves of “what happened”: who did it through the admin, and what changed on disk.
Related reading: How to Scan WordPress for Malware (and Read the Results).
Disclosure: DevDome publishes this blog and makes the products it mentions. We describe what they do rather than promise results.
Key takeaways
- WordPress keeps no history of logins, settings changes or deletions by default. Post revisions are the only built-in trail.
- A good activity log records account, content and settings events with who, what and when, then lets you filter, search and export.
- Keep it local and keep it bounded: a 90-day retention window covers nearly every real investigation.
- Privacy matters: log the action, not the content of passwords or private fields, and tell your team the log exists.
- The log is most useful after a hack or a mistake, so turn it on before you need it.
Sources
- WordPress.org: Revisions : the only history WordPress keeps by default, and only for post content
- WordPress.org: Hardening WordPress : logging and monitoring in the official hardening guidance
- ICO: Lawful basis for processing : legitimate interests as a basis for security logging
Links last checked October 17, 2026.
Frequently asked questions
Does WordPress have a built-in activity log?
No. It stores post revisions, which show content changes to a post, but there is no record of logins, settings changes, plugin activations, user role changes or deletions. A plugin adds that.
Will an activity log slow my site down?
A well-built one writes a small row per event and nothing on normal page views, so visitors are unaffected. The only cost is database size, which retention limits keep in check.
Is logging user activity legal under GDPR?
Logging administrative actions on your own site for security is widely considered a legitimate interest, as long as you record what is necessary, keep it for a limited time and tell users it exists. This is not legal advice; check your own obligations, especially if contributors are in the EU.
Should the log be stored off-site?
For most small sites a local log with a CSV export is enough. If you worry that an attacker with admin access could wipe the log, export it regularly or use a service that mirrors events elsewhere.