A WordPress activity log: how to find out who changed your site, and when

An administrator nobody remembers adding shows up on your site, or a plugin is gone and nobody knows who removed it. The question is who did it, and when. WordPress can answer part of that. It keeps a history of changes to post content, but it does not record logins, plugin installs or settings changes. For those you need an activity log, which is a plugin that writes such events down, and for anything serious, your host's server logs as well.

This article covers what you can see without extra tools, what a good log should record, why an ordinary log in the database can be wiped quietly, and how to detect that.

What WordPress records by itself

• Revisions of posts and pages. Each time content is saved, WordPress keeps a revision with its author and time, unless your host or developer turned revisions off. You can compare two revisions and restore an older one.
• The last modified date of a post or page.
• The registration date of each account in the user list.

What it does not record: who signed in and when, who installed, updated or deleted a plugin or theme, who changed an account's role, and who changed the settings.

Server logs: where to look when there is no activity log

Your host keeps its own logs: every request to the site, with the IP address, the time and the page requested. The WordPress.org guide to hardening WordPress (as updated on 14 October 2026) notes that these logs do not tell you which user name signed in, but they do show the IP address, the time and the actions taken.

In practice that is a lot of digging: thousands of lines, and no account name in them. Hosts also keep them for a limited time, so ask yours how long before you need them. An activity log inside WordPress gives you the same story in plain terms: the account, the event, the time, the address.

What a good activity log should record

• successful and failed logins, and lockouts after too many attempts,
• new accounts, role changes and deleted accounts,
• plugins and themes installed, updated, deactivated and deleted,
• theme switches and WordPress updates,
• settings changes, security settings above all,
• scan results, if the log is part of a security plugin.

Each entry should say what happened, when, from which account and from which address.

The weak spot of any log: it lives in the same database

Most activity logs keep their entries in the site's database. Someone who gets into the database, for example through a hole in an outdated plugin or with the password from a backup file left on the server, can delete the entries about themselves. An ordinary log has no way to notice that something is missing. It simply shows a shorter history.

There are two ways around that:

1. Ship a copy off the server. Entries go to an outside service or another server as they happen. This takes setting up, and often a paid service.
2. Make changes visible. This is what "tamper-evident" means. Each entry gets a signature computed from its content and from the signature of the entry before it, using a secret key that is not stored in the database. Editing one entry, or deleting one from the middle, breaks every signature from that point on, and a check points to the entry that no longer matches.

The second approach does not stop anyone deleting entries. What it gives you is proof that it happened. It has a limit too: someone who has both the database and the file holding the key can recompute the signatures from scratch. That is why, for a serious incident, your host's logs still matter.

How to judge an activity log plugin

1. Where it stores entries. A table of its own copes with large numbers of entries. A log kept as one setting with a cap of a few hundred items soon loses older events.
2. How long it keeps them, and whether you can change that. The period should cover the time it realistically takes you to notice a problem. Anything longer is data you are holding for no reason.
3. Whether you can export it. A CSV file opens in a spreadsheet and can go along with a ticket to your developer or host.
4. Whether lockouts crowd out other events. Bots can produce thousands of failed logins a day. If each one is a separate entry in the same pool, the events that matter get pushed out.
5. What it keeps about failed logins. People sometimes type their password into the user name field, so a log that stores every typed name can end up holding pieces of passwords. IP addresses and account names can count as personal data, so a log should keep only what it needs and delete it after a set period. The article on GDPR and website security has more on that side.
6. Whether it detects changes to its own entries. The plugin's description should say so plainly.

When to open the log

• an administrator appears whom nobody remembers adding,
• the home page looks different or sends visitors somewhere else,
• an email says an administrator account was locked,
• you stopped working with an agency, or someone left, and you want to see what they did last.

Export the log, find the first unusual event and note its time. With that time, your host's logs are much easier to search. Change the administrator and database passwords from a computer you trust. Signs your website was hacked covers the first hour after a break-in.

How Ensomedia Security does it

Ensomedia Security is a free plugin in the WordPress.org directory that I built for ShieldWave. Its log is called History and works without an account. The facts, from its listing and its code:

• it records scans, problems found and fixed, new administrators, updates, settings changes and lockouts,
• entries are kept in a database table of their own,
• every entry carries an HMAC-SHA256 signature keyed with the site's auth salt from wp-config.php, which is not in the database, and the signature includes the signature of the entry before it,
• Check history integrity tells you whether an entry was edited or deleted outside ShieldWave, and cutting off the newest entries is noticed too,
• someone who can write to the database but cannot read wp-config.php cannot change or delete an entry without the check showing it,
• lockout entries are aggregated and kept out of the signature chain: editing them is noticed, deleting them is not,
• if you replace the security keys in wp-config.php, the check says that older entries can no longer be verified, which is expected after you rotate the keys, for example after a break-in,
• entries are kept for 7 to 730 days (90 by default) and can be exported as CSV,
• for a failed login, the typed user name is stored only if that account exists. Otherwise only its keyed hash is kept.

It is not a full web application firewall, and it does not clean malware out of files. You, your developer or your host make the change it explains. The plugin's page lists its other features, and the screen by screen guide shows how to read History day to day.

What to do today

1. Find out whether your site has any activity log at all, and since when.
2. Ask your host how long it keeps the server logs.
3. Decide how long you want to keep entries, and set that in the log.
4. Once a month, go through the list of administrators and compare it with the log.

Check your site from the outside. Enter your address at shieldwave.io. It takes about 90 seconds and needs no password and no plugin.