A website change log should tell you enough to understand what changed, why it changed, how it was verified, and how to respond if the site behaves differently later. "Updated plugins" is not enough. Neither is a screenshot of a successful progress bar.
The useful unit is a decision with evidence. When every entry connects purpose, scope, approval, recovery, and result, the log becomes part of operating the website instead of a diary nobody reads.
Record the reason before the mechanics
Start with the problem or requirement the change is meant to address. That might be a security update, a broken form, an outdated service description, a performance bottleneck, or a new business workflow. Then state the intended result in observable terms.
For example, "replace the contact form plugin" describes an action. "Restore reliable lead capture while preserving the current fields, notifications, stored entries, and confirmation path" describes the job. The second statement helps the reviewer decide whether the proposed action is proportionate and what must be tested afterward.
Identify the exact scope
Record the site, environment, object, component, and version involved. Use stable identifiers when they exist: WordPress post ID, page ID, media ID, plugin slug, theme, file path, setting name, or redirect ID. Include the old and new values for consequential settings, but never place passwords, API keys, tokens, or private customer data in the log.
If several changes were bundled together, list them separately inside the same approved window. A broad entry such as "site cleanup" makes later diagnosis harder because no one can tell which page, plugin, account, or configuration actually moved.
A website ownership map complements the change log: the map explains who controls each system, while the log explains what changed within those systems.
Capture authority and approval
Write down who requested the change, who approved it, who performed it, and who can decide whether to keep or reverse it. These may be different people. A developer may be authorized to apply an approved patch without being authorized to change pricing, publish copy, remove an account, or accept a new operational risk.
Approval does not need to become bureaucracy. A short, specific record protects the owner and the operator from relying on memory when the consequences appear days later.
Attach recovery information to the change
Name the backup, revision, export, prior value, or other recovery artifact created before the change. Record where it is stored, when it was made, and what it actually covers. Do not write "backup available" if nobody has confirmed whether it contains the database, files, configuration, and external-system state the change may affect.
WordPress revisions can preserve earlier title, content, excerpt, and author states for posts and pages. They are useful for content recovery, but they are not a replacement for a site-level backup or a rollback plan covering plugins, themes, settings, integrations, and databases.
Define and record verification
Before the change, state what will prove success. Afterward, record the observed result. Good evidence may include an independently fetched CMS object, a rendered-page check, a controlled form submission, a status report, a log window, a checksum, or a business-workflow test.
Verification should match the layer that changed. If a post was updated, read back the exact post and review its rendered output. If a plugin was updated, test the critical workflows that depend on it. If DNS changed, verify the intended records and the services that rely on them.
Also record what was not verified. An honest "mobile checkout not tested because the approved sandbox was unavailable" is more useful than a blanket PASS.
Keep one compact entry per change
A practical entry can use these fields:
- date and time, including timezone;
- site and environment;
- request or problem;
- exact objects and prior state;
- approved action and authority;
- recovery artifact or rollback path;
- implementation result;
- verification performed and evidence;
- unresolved items, owner, and next review date.
The log should be searchable and stored where the people responsible for the site can retrieve it during an incident. If screenshots or large reports support the entry, link to them instead of burying the decision inside attachments.
A good change log does more than prove that work happened. It shortens diagnosis, preserves accountability, and tells the next operator where safe recovery begins. Build it into your WordPress maintenance routine before the next urgent change makes everyone depend on memory.