WordPress Audit Log

An audit log is a record of who did what, and when. WordPress does not keep one. Simple History adds it — free, with no configuration — and this page explains what belongs in a WordPress audit log, how long to keep it, and how to hand it to somebody who is asking.

What WordPress records on its own

Very little, and none of it is an audit trail.

WordPress keeps post revisions, so you can see that a page changed and roll it back. It records the date a user registered. Some plugins write their own notes. That is close to the whole list.

What is missing is everything you actually want when something has gone wrong: who logged in and from where, who failed to, who deactivated a plugin, who changed a setting, who deleted the page, who edited the user account, who installed the thing that broke the site. None of that is written down anywhere by default. When you go looking for it after the fact, it does not exist — and that is usually the moment people discover they needed an audit log.

What belongs in a WordPress audit log

A useful audit log records the event, the person, the time, and enough context to understand it without guessing. In practice that means:

• Logins and login failures — who signed in, from which IP, and which usernames are being tried by people who should not be signing in at all
• User accounts — created, deleted, role changed, password reset, email changed
• Content — posts and pages created, edited, trashed, restored, published; media uploaded and deleted
• Plugins and themes — installed, activated, deactivated, updated, deleted, and by whom
• Settings — WordPress options changed, with the old and new value
• WordPress itself — core updates, including the automatic ones nobody watched happen
• Menus, widgets, comments, exports — the smaller changes that are invisible until somebody asks about one

Simple History records all of these out of the box. You install it and it starts writing; there is nothing to configure first.

How long you keep it is the part people get wrong

An audit log is only worth having for as long as it goes back. Most questions arrive late — a client asks in March what changed in January, an auditor asks for the last twelve months, a security review asks when an account was created.

Simple History keeps 30 days by default. That is a deliberate choice: an activity log that grows forever quietly becomes the largest table in your database, and most sites do not want that. If you need longer, Simple History Premium lets you set any retention period you like, including keeping everything indefinitely.

The practical advice: decide the number before you need it. Working out in March that you only kept 30 days is not a problem you can fix in March.

Proving it to somebody else

There is a difference between having an audit log and being able to hand one over. Three things make that easier:

• Export — any filtered view of the log can be exported as CSV or JSON, so “send me everything user X did in Q2” is a search and a download rather than a project
• Forwarding — send events out of WordPress to syslog, Datadog, Splunk, a webhook or a separate database, so a copy lives somewhere a WordPress administrator cannot edit
• Alerts — be told when something happens rather than reconstructing it later

That second point is the one that matters to a reviewer. Anyone with admin access to WordPress can, in principle, reach the log stored in the same WordPress database. A copy streamed to an external system as events happen is a much stronger answer to “how do you know this has not been altered”.

Who ends up needing one

Broadly four groups, wanting different things from the same record:

• Agencies and freelancers — several people with admin access to a site nobody remembers changing. The audit log settles it without anyone being accused of anything
• Editorial teams — who edited the page, who unpublished it, who moved it
• Security-minded owners — failed login patterns, unexpected new accounts, plugin changes nobody authorised
• Organisations under an audit — ISO 27001, SOC 2, and GDPR accountability obligations all expect that changes to a system are recorded and reviewable

A note on that last group, because it gets oversold elsewhere: no plugin makes you compliant with anything. Standards ask for evidence that changes are recorded, retained, and reviewable. An audit log is how you produce that evidence. The certification is still work you do.

Common questions

What is a WordPress audit log?

A record of every meaningful change made on the site — logins, content edits, plugin and theme changes, user account changes, settings changes — with the person who did it and the time it happened. WordPress does not keep one on its own, so it takes a plugin.

Is an audit log the same as an activity log?

They usually mean the same thing. “Activity log” tends to be used for day-to-day visibility — what is happening on my site — and “audit log” when the record has to satisfy somebody else, like an auditor or a client. Same data, different reason for wanting it.

Does WordPress have a built-in audit log?

No. Post revisions are the closest thing, and they only cover content. Logins, plugin changes, user changes and settings changes are not recorded anywhere by default.

How long should I keep a WordPress audit log?

Long enough to cover the questions you get asked. Thirty days handles “what happened last week”. A year is a common answer where clients or auditors are involved. Keeping everything forever is possible, but a log that grows without limit becomes a database problem of its own — so pick a period deliberately rather than by accident.

Will an audit log slow down my site?

Writing an event is one small database insert on actions that are already happening — someone saving a post, someone logging in — and nothing at all on ordinary page views by visitors. The log data lives in your own database; nothing is sent anywhere unless you deliberately configure forwarding.

Can I see who deleted a page in WordPress?

With an audit log installed before it happened, yes — the event names the user, the page and the time. Without one, no: WordPress does not record it, and there is nothing to recover after the fact. This is the main reason to install one before you need it rather than after.

Add an audit log to your site

Simple History is free on WordPress.org, installed on more than 300,000 sites, and starts logging the moment you activate it. Longer retention, export, alerts and forwarding come with Premium.