A client reports that the homepage changed overnight. A product description is missing, and mobile navigation no longer opens. Several people worked on the site yesterday, while automated updates ran in the background.
You need to establish what changed before deciding what to restore. Guessing from the latest login can blame the wrong person and reverse unrelated work.
WordPress revisions and an activity log provide different parts of that investigation. Neither captures every possible change across WordPress, the filesystem, hosting, and external services. Start by understanding their coverage, then build a timeline you can verify.
Define the change you are investigating
“The homepage is broken” is a report, not yet a reproducible problem. Record the URL, device, affected action, and visible result. Note whether the visitor was logged in and whether consent settings or personalization were involved.
For a content complaint, identify the exact page and the disputed text, image, link, or template section. For a functional complaint, reproduce the failed action without making additional changes. Preserve a screenshot or recording when it helps explain the difference.
Then establish two times: the last confirmed good state and the first confirmed bad state. Record the timezone explicitly. A client’s local time, WordPress’s configured time, and a hosting log’s UTC timestamp can otherwise appear out of order.
Avoid assuming the symptom began when somebody noticed it. A cached page might reveal an earlier change only after its cache expires. A problem limited to logged-out visitors may remain invisible to an administrator.
Our WordPress activity timeline guide explains how recorded events help narrow that interval. The interval gives you a manageable starting point without declaring every nearby event responsible.
Choose the evidence that can answer the question
Different records describe different layers of the site. Use them together instead of expecting one screen to reconstruct everything.
| Evidence | Useful question | Boundary to check |
|---|---|---|
| WordPress revisions | What changed between saved versions of this post or page? | Retention and support for the relevant fields |
| WordPress activity log | Which supported event was recorded, when, and under which account or process? | Event coverage, detail, delivery, and retention |
| Backups | What did files or the database contain at a particular recovery point? | Snapshot timing, completeness, and whether restoration has been tested |
| Git and deployment history | Which tracked code change was deployed? | Untracked files, database changes, and edits made outside deployment |
| Hosting or server logs | Which requests, errors, or infrastructure events were recorded? | Log configuration, access, timestamps, and retention |
| CDN or service-provider history | Did delivery rules, DNS, or external configuration change? | Changes outside WordPress and the provider’s available records |
An activity entry can identify a post update without storing a complete before-and-after copy of every field. A backup can contain an earlier state without telling you which person created it. Match the evidence to the question before promising an answer.
Also distinguish an account from a person. A shared administrator login weakens attribution. An integration, scheduled process, or compromised credential can perform actions associated with an account without proving who operated it.
Use named accounts for routine work and document integrations separately. That makes future event records more useful without pretending they provide perfect identity evidence.
Use revisions for the content they actually preserve
WordPress revisions let you compare saved versions of a post or page. They are usually the first place to inspect a disputed title or body edit. Open the affected item’s revision history and compare the relevant saves.
Record what changed before restoring anything. A useful finding identifies the specific paragraph, link destination, or block removed. “An editor saved the page” gives much less information than a comparison showing the deleted pricing disclaimer.
Check whether the disputed content actually belongs to that post. A header, navigation menu, reusable element, or template may be stored elsewhere. Restoring the page’s body will not necessarily restore those separate objects.
Custom fields also need explicit attention. WordPress provides opt-in revision support for post metadata. You cannot assume every field added by a plugin or page builder participates.
For example, the visible product description may have a usable revision history while a custom delivery field does not. Verify the actual field and plugin behavior in staging. Do not infer coverage from the presence of a Revisions panel alone.
Finally, check how many revisions remain. A retention setting or cleanup process may remove older states. If the disputed version is missing, explain that limit and investigate another source, such as an earlier backup.
Narrow the activity log without losing context
Start with the incident’s time interval and affected object. Filter by relevant event types, then inspect neighboring events that could explain the symptom. Our guide to debugging WordPress changes shows how filters help reduce noise.
For a changed article, investigate its update events and revision history. For a broken menu, inspect theme changes, plugin updates, configuration changes, and deployment records. Do not restrict the search to content edits just because the complaint describes a visible page.
Compare event details with independent evidence. An update entry may identify a plugin and version, while a deployment record reveals accompanying custom code. A performance trace may show that the resulting script now blocks the first interaction.
Scanfully’s WordPress activity log records supported WordPress events and provides a timeline for investigation. Its product coverage includes content, user, plugin, theme, and configuration activity. Verify the particular event and detail you need on your installation.
Treat an absent entry carefully. The event might be unsupported, filtered out, older than retained history, or outside WordPress entirely. Check collection and delivery before concluding that no change occurred.
Our article about an activity log during troubleshooting gives additional context for using those records alongside other site signals.
Build a timeline, then test the suspected cause
Imagine a shop whose mobile product selector stops responding after morning maintenance. The following timeline is illustrative. It is not a report from a Scanfully customer.
| Time, UTC | Recorded observation | What it establishes |
|---|---|---|
| 08:40 | A test purchase completed on the affected template | A confirmed good state under the recorded test conditions |
| 09:03 | A gallery plugin updated | A candidate change requiring investigation |
| 09:07 | An editor changed the product description | Another nearby change, with separate revision evidence |
| 09:12 | The page cache was purged | Cached delivery may have stopped hiding an earlier change |
| 09:20 | A customer reported an unresponsive selector | The first reported failure, not necessarily its starting time |
| 09:28 | The team reproduced a script error | A concrete symptom that can be tested against candidate changes |
The gallery update is a plausible lead, but its timing does not prove causation. The description edit might also contain an embed or malformed custom HTML. Inspect both changes before choosing an experiment.
Reproduce the failure in staging with the relevant versions and configuration. Keep other variables stable while testing one candidate change. Compare the console error and the affected interaction before and after the controlled adjustment.
If reverting the gallery update removes the same error under equivalent conditions, you have stronger evidence. Document what was tested and any remaining differences from production. Avoid claiming certainty when the reproduction depends on missing data or a different environment.
For performance complaints, attach a trace rather than relying only on timing coincidences. Our TBT investigation and LCP diagnosis show how to isolate browser delays.
Restore the smallest verified change
Once the cause is sufficiently clear, choose a recovery method that preserves unrelated work. A disputed paragraph may need a targeted edit from a known revision. It rarely justifies replacing the entire database.
Review a proposed revision restore before applying it. Restoring a previous post version may reverse other edits made afterward. Compare the complete change and preserve later corrections that should remain.
Code rollbacks need their own checks. A plugin update may change stored data or require a compatible version elsewhere. Confirm the supported recovery procedure and test it before replacing files on production.
Be especially cautious with a busy shop’s database. An older snapshot can omit orders, account changes, and other transactions created after the backup. Recovery planning needs to account for those newer records instead of treating the snapshot as a harmless reset.
Preserve the current state before recovery when practical. Then validate the repaired content or action, the related templates, and any affected integrations. Check public delivery after relevant cache invalidation, since the editor preview alone cannot confirm what visitors receive.
If a content edit broke a destination, use the broken-link investigation guide to identify the affected references. Our redirect-or-replace guidance helps choose a repair that fits the missing resource.
When evidence suggests unauthorized access, treat the event as a security incident. Preserve available records and involve whoever manages incident response. WordPress’s hardening guidance provides broader security context; silently undoing the visible edit is insufficient.
Test what your activity log actually records
Before relying on a log during an incident, run a small coverage exercise in staging. Use identifiable test objects and named accounts. Record the expected event, the actual entry, and any missing detail.
| Controlled test | Evidence to look for |
|---|---|
| Edit a test post’s title and body | Object identification, account, timestamp, and available revision comparison |
| Change one relevant custom field | Whether the event and field detail are captured at all |
| Update a test plugin | Plugin identity, version information where available, and event timing |
| Change a test user’s role | The affected account and the recorded role-change detail |
| Change a relevant setting | Coverage for that exact setting, rather than configuration activity in general |
| Perform a scheduled or integration-driven change | How the log identifies the process or acting account |
| Make an approved change outside WordPress | Which hosting or provider record supplies the missing evidence |
Repeat relevant checks after changing the logger, integration, or configuration. Coverage that existed before an update should not be assumed indefinitely. Keep the results with the site’s maintenance documentation.
Also test access during a simulated site outage. If every record requires the broken site’s dashboard, investigation may stall. An external copy can help, provided the events reached that destination before the failure.
Scanfully stores its activity log externally, as described on the product page. That does not remove the need to check collection gaps and retained history. Our explanation of offsite activity logs explores the operational reason for separating records from the monitored site.
Keep useful records without collecting everything
Decide who needs access to the log and how long the team needs its records. Base that choice on the site’s investigation and reporting requirements. Do not retain sensitive material simply because a tool can capture it.
Review recorded fields for personal information and secrets. Avoid including passwords, access tokens, or complete sensitive form submissions in diagnostic notes. When sharing evidence, remove unrelated account details and customer information.
An activity trail can support an audit question, but installing a logger does not by itself establish compliance. The team still needs appropriate coverage, access controls, retention decisions, and a process for reviewing evidence.
For a client incident report, separate confirmed observations from the proposed explanation. Include the affected URL, time interval, relevant changes, tested repair, and verification result. State any evidence gaps explicitly.
For example: “The selector failed after the gallery update. We reproduced the error in staging and verified the repair there and on production.” Follow that with the tested scope, rather than expanding the claim to every device or product.
Leave the next investigator a usable record
Finish the investigation by recording the change that resolved it and the evidence supporting that decision. Keep the revision comparison, relevant event references, and before-and-after test results together. Note who owns any unresolved follow-up.
For recurring maintenance, agree on a small set of post-change checks for the site’s useful workflows. A shop needs purchase-related checks; a lead-generation site needs working forms. The same generic homepage screenshot cannot verify both.
If you use Scanfully, review the relevant history in the dashboard alongside your recovery notes. For client communication, shareable Scanfully reports can complement the incident explanation. A report is most useful when it tells the client what failed, what changed, and what was verified afterward.
Leave a Reply