Who Changed My WordPress Site? How to Find Out Exactly
You log in on a Tuesday and something is off. A landing page reads differently than it did last week. A setting you were sure about is flipped. A plugin you didn't touch is suddenly deactivated, and half the site is throwing errors. You ask the team in Slack — three editors, a developer, a freelancer with admin access — and every single reply is "wasn't me."
On a single-author site you'd shrug and fix it. On a multi-user site, "wasn't me" isn't an answer. You need to know who changed my WordPress site, exactly what they changed, and when — so you can fix the right thing and make sure it doesn't happen again.
This post walks through why WordPress alone can't tell you, what you can squeeze out of post revisions, and the real fix: an activity log that records every change with a before/after diff and the user and IP behind it.
Why WordPress can't tell you on its own
Here's the uncomfortable truth: out of the box, WordPress keeps almost no history.
It tracks post revisions — and that's it. There is no built-in record of:
- Who changed a setting in Settings → General, Reading, or Permalinks.
- Who activated, deactivated, installed, or updated a plugin or theme.
- Who created, edited, or deleted a user — or changed someone's role to administrator.
- Who edited a menu, a widget, or a WooCommerce / SEO configuration.
- When any of the above happened, or from which IP address.
So when a setting flips or a plugin disappears, WordPress has no memory of the event. The change is just… there. You can see that the site is different. You cannot see who made it different, or when, which is exactly the information you need to fix it and to hold the right person accountable.
This is the gap that catches teams off guard. They assume "the database must know" — but the database only stores the current state, not the history of how it got there.
What post revisions can (and can't) show you
Post revisions are the one place WordPress does keep history, so start there if the change was to a page or post body.
Open the page in the editor and look for Revisions in the sidebar (under the Post panel). Click it and you get the revision comparison screen — a side-by-side of two versions with added text highlighted in green and removed text in red. At the top of each revision you'll see the author name and a timestamp.
For a straightforward "someone rewrote this paragraph" mystery, that's often enough. You can see who edited the page in WordPress, when, and roll back to the previous version with one click.
But revisions have hard limits:
- They only cover post and page content. Settings, plugins, themes, users, menus, widgets — none of it is versioned.
- Autosaves muddy the trail. A revision attributed to an editor might just be an autosave that fired while a different change was in flight.
- No IP, no context. You get a name and a time, nothing about where the login came from.
- They get pruned. Sites often cap revisions (or strip them for performance), so the version you need may already be gone.
- Deletions vanish. If a post was deleted, there's no revision left to inspect.
So revisions answer "who edited a page in WordPress" some of the time, for body content only. For everything else — and for the IP and accountability you actually want — you need a proper activity log.
The real answer: an activity log
An activity log records every meaningful event on your site as it happens, and keeps it. For each event it stores who did it, what they did, when, from which IP, and — for changes — a before/after diff so you can see exactly what was altered.
That's the difference. Revisions tell you a page changed. An activity log tells you that editor-jane changed the homepage SEO title from "Home" to "Welcome" at 14:32 GMT on Monday, from an IP in a city you don't recognise. One of those is a guess. The other is an answer.
Logify is a WordPress activity log plugin built exactly for this. It records posts, pages, settings, plugins, themes, users, menus, and WooCommerce and SEO changes — each with a before/after diff, the acting user, and the source IP with location mapping. If you want the full background on activity logging, the WordPress activity log guide covers the concept end to end.
Step by step: find the culprit with Logify
Here's the workflow when something has changed and you need to pin it down.
1. Install Logify and let it record
Install the plugin from Plugins → Add New, activate it, and it starts logging immediately — no configuration required to begin capturing events. The getting started guide covers the first-run setup. (Worth doing before an incident, obviously — Logify can only show you events that happened after it was recording. If it's already installed, skip ahead.)
2. Open the activity log
Go to Logify → Activity Log. You'll see a reverse-chronological list of every recorded event — each row showing the event, the user, the IP, a severity badge, and a timestamp. The full reference for this screen is in the activity log docs.
3. Filter by the date range around when it broke
This is the fastest way to cut a noisy log down to the suspects. Use the date filter to narrow to the window when the change must have happened — "sometime between Friday's working version and this morning." Everything outside that range disappears.
4. Filter by user or by event type
Now narrow further. If you suspect the change came from a particular account, filter by that user. If you know what changed but not who, filter by event type instead — for example, narrow to plugin events to find who deactivated the plugin, or to settings events to find who flipped a configuration. Filtering by IP is useful too when you're chasing a single source rather than a single person.
For a quick mental model: filter by event type when you know the what, filter by user when you know (or suspect) the who.
5. Open the entry and read the before/after diff
Click the matching event to expand it. This is where Logify earns its keep — you see the before and after values side by side, so there's no ambiguity about what actually changed. A settings change shows the old value and the new one. A user change shows the role before and after. Alongside the diff you get the acting user and the source IP with its mapped location, so "wasn't me" stops being a defensible position.
At that point you have your answer: who, what, when, and where from. Fix the change, and move on to making sure it doesn't catch you off guard next time.
Going forward: catch the next change before you have to hunt
Finding the culprit after the fact is good. Being told the moment it happens is better.
Set alerts for sensitive changes
Configure notifications so Logify taps you on the shoulder when something high-impact happens — a plugin is deactivated, a user is promoted to administrator, a critical setting changes. Alerts can go to email, Slack, or a webhook. Instead of discovering a broken site on Tuesday, you get a message the moment the change lands, while it's still easy to reverse.
This pairs naturally with watching for failed login attempts — if a change came from a compromised account, the failed-login trail often tells the story leading up to it.
Reduce noise with exclusion rules
A log that records everything can bury the events that matter. Use exclusion rules to drop the noise at the source — your own admin user during heavy maintenance, a cron monitoring service's IP, autosave churn. Excluded events never hit the database, so dashboards, alerts, and exports stay focused on activity that actually means something. On busy multi-author sites this is essential; the multi-author user activity guide goes deeper on keeping a shared site's log readable.
If something does go wrong with logging itself, the troubleshooting docs cover the common cases.
Conclusion
WordPress can't tell you who changed your site, because — beyond post revisions — it doesn't remember. Revisions help for page and post content, but they skip settings, plugins, themes, users, and the IP and accountability you actually need. An activity log closes that gap: it records every change with the user, the time, the source IP, and a before/after diff, so "wasn't me" gives way to a name and a timestamp.
With Logify installed, finding the culprit is a three-step filter — date range, then user or event type, then open the diff. And once you add alerts for sensitive changes, the next mystery turns into a notification instead of an afternoon of detective work.
FAQs
Can WordPress show me who edited a page?
Partly. WordPress post revisions show who edited a page's content and when, with a side-by-side diff you can roll back. But revisions don't cover settings, plugins, themes, or user changes, and they don't record IP addresses. For full coverage you need an activity log like Logify.
Do post revisions track settings and plugin changes?
No. Revisions only version post and page content. Changing a setting, activating or deactivating a plugin, updating a theme, or editing a user leaves no revision behind. Those events are only captured if you run an activity log that records them.
Can I see the IP address and location of who made a change?
Yes — Logify records the source IP for every event and maps it to a location, so you can see not just who made a change but where the request came from. That's often the detail that resolves a "wasn't me" dispute.
Can I get alerted when something sensitive changes?
Yes. Logify's notifications can alert you by email, Slack, or webhook the moment a high-impact event happens — a plugin deactivation, a user promoted to admin, a critical setting change — so you hear about it immediately instead of discovering it later.
Does it track changes made by administrators too?
Yes. Logify records activity from every user, administrators included. If you want to suppress your own admin noise during maintenance, you can do that deliberately with exclusion rules — but by default, admin changes are logged like any other.