Who edited this page — and what exactly changed?

Why "check the revisions" usually isn't enough

WordPress revisions are genuinely useful, and for plain body-text edits they will often tell you who saved what. But they cover a narrow slice of a modern page:

• Only title, content and excerpt are versioned — and only for post types that support revisions at all.
• Everything in post meta is invisible to them: SEO titles and descriptions, ACF and other custom fields, most page-builder layouts, featured images. (Meta diffing is landing in the next release here too — today the log records that the post was edited, by whom, with the post-level fields diffed.)
• Slug, publish status, author and taxonomy changes leave no revision — a page silently switched to draft, or moved to a new URL, has no history.
• Hosts and optimisation plugins routinely cap or disable revisions to keep the database small, so the trail may simply have been pruned.
• Edits made outside the editor — over the REST API, WP-CLI, or by an import or "AI content" tool — bypass the editing screen people think of when they picture the culprit.

So the failure mode is predictable: the change you actually care about — a rewritten meta description, a swapped price inside a builder widget — is precisely the kind revisions do not capture.

What a field-level activity log records instead

Who Changed It treats every save as a set of named field changes, not one "post updated" event. Today that covers the post itself — title, slug, excerpt, author, parent, password protection and how much the content grew or shrank — each with its old and new value, and the acting user, role and IP attached. Post meta, which is where SEO fields, ACF values and page-builder layouts live, is the next thing landing. The record for a suspicious edit reads:

The old value is always readable on the left, the new one on the right — so reversing a bad edit is a copy-paste, not an archaeology project. You can see this exact interaction in the live demo: open a row and read the diff inline, exactly as it appears on the plugin's own screen.

Finding the edit fast when you have hundreds of events

On a busy site, the hard part is not recording edits — it is finding the one that matters. Two things do that here. Filters narrow the timeline to content events on one target. And behaviour scoring compares each edit to the editor's own baseline (their usual hours, frequency, role and IP), so an account that edits four posts a week suddenly rewriting the pricing page at an odd hour is flagged before you even ask. Every escalation stores a human-readable reason, so the log tells you why it thought a row was worth your attention rather than leaving you to infer it.

Occasionally the answer is that nobody on your team made the edit at all: links appearing in old posts, a meta description rewritten overnight, content changing under an account that was not signed in. That is a compromise rather than an editorial mystery, and restoring the revision only papers over it — the useful next step is a cleanup that also finds the way in. The log is what makes that hunt short, because it gives the responder a timestamp to work backwards from.

Common questions