A change nobody can undo is not an experiment. It is a commitment with a hopeful story attached.
Four properties of a reversible change
1. one change per merge, so the cause is identifiable
2. the previous value is recorded, not remembered
3. the change lives in a system with history, not a settings screen
4. the window is agreed before the change ships
A filled record
Brightwater Dental, a canonical change that was reverted.
change: add a canonical tag to /pricing and /treatments
reason: two urls served the same page with query parameters, and
the report showed both receiving impressions
shipped: 2026-09-11, one pull request, two files
window: 2026-09-11 to 2026-10-09, 28 days
previous values, recorded before the merge
/pricing no canonical tag
/treatments no canonical tag
baseline, 2026-08-14 to 2026-09-10, 28 days
/pricing impressions 240, clicks 6, position 19.2
/treatments impressions 410, clicks 11, position 14.8
result, 2026-09-11 to 2026-10-09, 28 days
/pricing impressions 210, clicks 5, position 20.1
/treatments impressions 388, clicks 9, position 15.4
comparison set, twelve pages not changed
impressions -2.4%
clicks -1.8%
verdict: inconclusive, and the change was reverted anyway
reason: both pages moved with the comparison set, so there is no
evidence either way, and the owner preferred the previous
state while the query mix is being sorted out.
revert: one pull request, the recorded previous values restored
reverted on: 2026-10-10
The record makes the revert boring. Nothing had to be guessed, and nothing was remembered from a conversation three weeks earlier.
Why the revert happened without a verdict
Inconclusive does not mean keep it. The change is neutral, and the owner prefers the previous behaviour. Reverting is a decision, not a failure.
Acceptance: the change is reversible when
- one merge contains one change
- the previous value is written into the record
- the file and the line are named, not just the page
- the window is agreed before shipping
- the revert needs no discussion about what used to be there
Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| Nobody knows what changed | The edit was made in a settings screen | Screenshot it, add a note, then move it into code |
| The revert broke something | Two changes shared one merge | Split the merge, and revert one |
| The window keeps moving | It was never written down | Write it into the record before the next change |
| A URL change tanked traffic | A redirect was missed | Restore the old path, then plan properly |
| The client wants it kept | The result was inconclusive | Record the decision and the reason |
What to write down before you start
Five lines, and none of them takes more than a minute.
file and line the exact place the value lives
previous value copied, not summarised
who approved it a name, not a team
the window start and end dates
how to revert one sentence somebody else could follow
A change with those five lines can be undone by somebody who was not in the room. A change without them belongs to the person who made it. That is how one departure turns into a permanent problem.
Limits
Reversible does not mean safe. A redirect mistake can still lose a season of traffic before anybody notices.
For anything that touches URLs, take the slower path. Inventory first, one change second, then a week of watching.