Content update evidence log
A practical record for showing what changed on a published page, which evidence supported the edit, and which release checks confirmed the result.
content update evidence log
A content update evidence log explains why a published page changed. It connects the old passage, the new passage, the supporting source, the editorial decision, and the released result. Without that chain, a later editor can see the current copy but cannot tell which part was corrected, reconsidered, or simply restyled.
The log should be small enough to complete during ordinary editing. Record one entry for each material claim or reader instruction that changes, then group closely related copy edits under the same decision.
Do not use a new date as a substitute for this record. A truthful update starts with a material review and ends with a checked live page, not with a timestamp added to make an old article look recent.
Open the record before changing the page
Create the entry when an update is accepted, before the draft begins. Name the canonical route, the reader task, the update owner, the reviewer, the reason for review, and the specific sections in scope. This keeps a narrow correction from quietly becoming an unreviewed rewrite.
Save the current title, H1, visible publication date, visible modification date if one exists, canonical tag, and relevant structured data. For the affected passage, quote enough of the old wording to identify it after surrounding paragraphs move.
Add the trigger as an observation rather than a conclusion. A source changed, a reader reported a broken step, or an internal review found a claim gap describes what started the work. It does not yet prove which edit is appropriate.
Match evidence to the exact claim
For each changed claim, record the source owner, page title, direct URL, access date, and the passage or section that supports the edit. A link to a broad home page makes later review slow and may hide that the cited material never covered the sentence's full scope.
Write a short support note beside the source. The note should state what the source establishes and any limit that must remain visible in the article. If the source describes one product, region, date, or method, do not turn it into a general rule.
When evidence conflicts, preserve the disagreement. Identify which source governs the decision and why its scope fits the page. If no source supports the intended wording, narrow the claim, mark it for further review, or remove it instead of borrowing authority from a nearby fact.
Record the editorial decision, not just the diff
A code diff shows changed characters. The evidence log should explain the reader consequence. State whether the edit corrects an error, replaces stale instructions, adds a missing qualification, improves navigation, or changes the answer the page gives.
Capture the old and accepted new wording for material passages. Then add one plain sentence explaining why the new version fits the evidence and the reader task. This is more useful than labels such as refreshed or improved, which say nothing about the decision.
Keep factual correction separate from style work. A revised sentence may need both, but the log should show which words changed because the evidence changed and which changed for clarity. That separation makes future claim review faster and protects a sound correction from later copy edits.
Use modification dates truthfully
Keep the original publication date as the page's history. Add or change a modification date only when the accepted work materially affects the article, such as correcting a factual claim, replacing obsolete guidance, or revising a substantial section after review.
Small spelling fixes, whitespace changes, and routine build activity do not tell a reader that the article was materially reconsidered. Record them in version control when needed, but do not promote them into a freshness claim.
Date signals should agree. Google Search Central recommends using visible dates together with datePublished or dateModified structured data and advises against confusing dates on the page. Check the visible label, structured data, sitemap value, and any share metadata that carries a date before closing the update.
Protect route identity during the update
An evidence log should name any change to the URL, title, canonical, indexability, or primary reader task. These fields affect how the page is found and understood, so they need a specific decision rather than being treated as incidental editing details.
If the route moves, record the old URL, destination, redirect behavior, internal link changes, and sitemap ownership. A redirect belongs only when the destination satisfies the same reader task. Otherwise, preserve the route or document a different retirement decision.
Review links and media in the edited sections. A source may still load while no longer supporting the attached sentence, and an image may still render while describing an outdated workflow. The log should identify what was checked, not merely report that the page opened.
Tie approval to an immutable release
The accepted entry should point to the exact reviewed content state. Record the reviewer, decision time, accepted source set, and immutable commit or release identifier. If the page changes again before deployment, the earlier approval no longer proves that the released version matches the review.
Keep draft exports, private comments, and rejected wording out of the public route and release package. The evidence log can reference controlled records without exposing credentials, customer information, internal discussions, or material that was never accepted for publication.
Do not close the entry at merge or deployment start. Those events show movement through the release process. They do not prove that the intended page reached the production domain or that its rendered content still matches the accepted decision.
Verify the live page and close the loop
Request the canonical production URL after deployment. Compare the title, H1, updated passages, source links, byline, visible dates, media, internal links, canonical tag, and structured data with the accepted record. Check the sitemap entry and confirm that the route returns the intended page.
Save the verification time, deployed revision, result, and any defect. If one representation is stale, keep the entry open and name the owner and next check. A correct body beside an old date or conflicting structured data is still an incomplete update.
End with the outcome the reader can now rely on, plus any future review trigger. Do not attach a ranking promise to the change. The log exists to prove the editorial decision and release state, while later search or reader behavior remains evidence for a separate review.
Sources
- Add a byline date to Google Search results, Google Search Central. Supports the practice of using clear visible dates, datePublished or dateModified structured data, and consistent date signals without artificially refreshing a page.
Related GTM guides
Frequently asked questions
What should a content update evidence log contain?
Record the canonical route, reader task, update trigger, affected passage, old and new wording, supporting source and access date, editorial decision, reviewer, immutable release, and live verification result. Include date, canonical, sitemap, media, link, and structured data checks when they are affected.
Does every copy edit need a new modification date?
No. Preserve minor spelling, whitespace, and style changes in version control without presenting them as a material refresh. Use a modification date when the accepted work changes a factual claim, instruction, substantial section, or another part a reader would reasonably recognize as updated.
When can the evidence log be closed?
Close it after the accepted immutable revision is deployed and the production route matches the record. Verify the visible copy, dates, source links, internal links, media, canonical, structured data, and sitemap entry, then save the deployed revision and verification time.