Identify the change
Change ID · date in UTC · client/site · page URL · category · field or element
Record the exact page-level change, before-and-after evidence, approval, validation, rollback plan, and outcome—without rebuilding a spreadsheet from scratch.
“Changed the homepage” is not enough when traffic moves, a client asks what happened, or a release needs to be reversed. A reliable row preserves the exact affected URL and field, the old and approved values, the intended outcome, and the evidence required to validate it.
Use one row per meaningful page-level decision. Duplicate the workbook by client or keep one filtered master log, depending on who needs access.
The blank download contains these 18 fields in a practical review order. The example file shows how three fictional SEO changes can be documented without exposing any real client.
Change ID · date in UTC · client/site · page URL · category · field or element
Before value · after value · reason or hypothesis
Requested by · implemented by · approval status · approved by
Ticket or reference · validation check · rollback plan
Outcome review date · outcome or notes
Summer Footwear
→ Trail Shoes for Weekend HikesApprovedConfirm 200, canonical, and live titleReview scheduledRollback value preservedAll company names, URLs, tasks, and values in the example are fictional.
Keep the spreadsheet for intent, ownership, experiments, and outcomes. Use public-page monitoring for the different question: did a protected field change later, including through an unlogged CMS edit, template, plugin, cache, or deployment?
Start monitoring free ↗APPROVED https://example.com/serviceLIVE https://example.com/↳ Confirm the change was approved. Otherwise restore the protected canonical target.
The template is the manual decision record. These free RankLatch resources help with current-state verification and launch control.
A change log is most useful when it preserves decisions the team could otherwise misremember—not when it becomes another unchecked box.
An SEO change log is a dated record of intentional changes to pages and technical signals. It preserves what changed, the previous and approved values, why the change was made, who approved it, how it was validated, and when the outcome should be reviewed.
The downloads are standard UTF-8 CSV files. They open in Excel, Google Sheets, Apple Numbers, LibreOffice, and most database tools. The blank version contains the 18 agency-focused columns; the example includes three fictional rows.
No. Both files download directly, with no account, email gate, tracking parameter, or locked template platform.
Log deliberate changes that could affect discovery, search snippets, targeting, or page behavior: titles, descriptions, canonicals, robots directives, redirects, headings, copy, schema, internal links, image alt decisions, templates, and important response changes.
Use judgment. The log is most useful for changes with a testable reason, meaningful search or conversion impact, approval requirement, or rollback risk. Recording every typo can bury the decisions the team will need later.
No. A manual log records changes people remember to enter. It cannot detect an unlogged CMS edit, template release, plugin change, CDN rule, or accidental removal. RankLatch addresses that separate problem by comparing approved public-page snapshots.
Set the review date when the team can reasonably evaluate the intended result using the relevant evidence. Search performance often needs more time than a response or indexability validation, so do not use one fixed review window for every change.
Yes. Rename, reorder, filter, or extend the CSV for your workflow. Keep the before value, after value, reason, approval, validation, and rollback fields if the log must support reliable incident review.