Who Changed It/Answers
The layout shifted, a setting is different, a page is gone from Google, and everyone with a login says it wasn't them. Sometimes they're right. Here is how to work out whether it was a person, a machine or an attacker, and where to look for each.
A surprising number of "it changed overnight" reports are not changes at all. Before you go looking for a culprit, check these:
If something genuinely changed, it was one of a handful of things. Most of them involve nobody logging in at all.
| Cause | Typical symptom | Where WordPress leaves a trace |
|---|---|---|
| Automatic updates | Layout or behaviour changed after a plugin, theme or core release. | An email to the site's admin address after each auto-update run. Compare version numbers under Plugins and Themes. |
| Scheduled tasks (WP-Cron) | A post published "on its own", a plugin rewriting a setting, a cleanup job deleting things. | Scheduled posts show as Scheduled before they go live. Other cron jobs leave nothing. wp cron event list shows what is queued. |
| Another user | Content, settings, plugins or menus differ, and it happened during working hours. | Post and page revisions name who saved each version. Nothing records settings, plugins, themes or users. |
| The host | A new PHP version, a plugin switched off, a changed cache or security rule. | Your host's control panel or change notices. Not in WordPress. |
| A restored backup | Recent posts, users or plugin activations "vanished" all at once. | The backup tool's own history. |
| An attacker | An admin account you don't know, strange redirects, spam links, an unfamiliar plugin. | Often none. Attackers clean up. See site hacked: how to find what changed. |
Look at Settings → Reading → Search engine visibility first. That one checkbox, Discourage search engines from indexing this site, is routinely ticked on a staging copy and pushed live with it. Then check individual pages for a noindex set in your SEO plugin. Neither change breaks anything visibly. The site still loads, and the damage only shows up weeks later as missing traffic.
The site's admin email is where password reset links go, and the site and home URLs decide where visitors end up. "Anyone can register" combined with a default role above Subscriber hands out accounts. If any of these changed and nobody can explain it, treat it as a possible compromise, not a mystery.
WordPress deactivates plugins silently when their files go missing, and hosts switch off plugins they know to be incompatible. The whole story is in who deactivated a plugin.
This is the one case WordPress handles: open the page in the editor, and Revisions shows who saved each version and what changed between them. Page builders complicate it. Elementor, for example, keeps its content in post meta, so the ordinary record of an edit can look as if nothing changed. Who edited this page covers that.
WordPress stores the current state of the site, not its history. When a setting changes, the old value is overwritten and no record is kept of who changed it, when, or what it was before. Server access logs can show that someone sent a request to wp-admin/options.php at a certain time from a certain IP, but not which user it was or which setting they changed, and many hosts rotate those logs within days.
So the honest answer to "who changed my site last Tuesday?" is often: if nothing was recording, nobody can say for sure. The fix is to have something recording before the next time.
Who Changed It records changes as they happen, with the user, their IP and the old and new values. It covers logins, users and roles, content, plugins, themes, core updates, use of the file editor, WooCommerce, and Yoast SEO, ACF and Elementor. The event reference has the full list. For settings it watches a curated list of the ones that matter: the site and home URLs, admin email, registration and default role, search engine visibility, permalinks, language, time zone, upload path and site title. You can add your own with a filter.
That turns the table above into a single answer. An automatic update or a cron job shows up as a row with no user, which clears your colleagues at a glance. A colleague's change carries their name. The changes that matter are flagged with the reason written out. A new admin email, site address or default role is dangerous on sight and reaches you straight away by email, Slack, Discord or Telegram. So is the login that usually comes first, if it's at 03:00 from an IP that account has never used.
#51207 · 03:12 · j.doe · option_changed · blog_public 1 → 0 — flagged strange
If you would rather not check the log at all, the optional daily or weekly digest emails you the totals and every flagged event. It is sent even when nothing happened, so a digest that stops arriving is itself worth looking into.
Being straight about the limits: an activity log listens to WordPress. A file edited over FTP or SSH, a row changed directly in the database, or a server-level change by the host goes around WordPress entirely, so no plugin that relies on WordPress's hooks will record it. Use of the built-in theme and plugin file editor is recorded, and is always classified dangerous. For files on disk, compare them against the official checksums with wp core verify-checksums and wp plugin verify-checksums --all.