How to let software change your website without it going wrong
Automation · 5 min read · Updated
Automated changes to a live website are safe when five things are true: a snapshot of the current state is taken before every write, the approver sees a diff against the page as it is now rather than as it was when the change was drafted, changes are applied one at a time through a single queue rather than in parallel, every write is verified afterwards and treated as a failure if the page did not actually change, and rollback restores the snapshot rather than attempting to reverse the edit. Without all five you do not have automation, you have a process that usually works.
Snapshot before, not diff after
A rollback that reconstructs the previous state by reversing an edit fails the moment anything else has touched the page — and something else always has, because a CMS rewrites markup on save, a plugin injects tags, and a colleague edits the paragraph above.
Storing the actual prior state immediately before writing costs almost nothing and turns rollback from an inference into a restore. The corollary matters as much: a system that cannot read a page is not allowed to write to it. Writing blind means having nothing to restore, which is worse than never having made the change.
Test the restore path deliberately, on a real page, before trusting the system with a hundred. A rollback nobody has ever run is a hypothesis.
The approval has to be about the live page
A change is drafted on Monday and approved on Thursday. In between, somebody edited the page. If the approval screen shows the diff as it was computed on Monday, the approver has agreed to something other than what will happen.
The fix is to recompute the diff against the current live page at the moment of viewing, and to flag it loudly when the page has moved since the action was proposed. An approver who sees a drift warning re-reads; one who sees a clean stale diff clicks.
- Show the diff against the page as it is right now, recomputed on view.
- Flag drift explicitly when the page changed after the action was drafted.
- Require a note from the approver. It is the only durable record of why, and it makes approving-by-reflex slightly harder, which is the point.
- Support more than one approver for changes above a threshold you set, not a threshold the software picked.
- Preview must write nothing, and must be instant. An approver who has to wait for a queued job stops looking.
One lane, not many
Applying, rolling back and restoring must run at a concurrency of one per site. Two writes racing on the same page produce a snapshot of a state that never existed, and the rollback that follows restores something nobody recognises.
The same discipline covers double submission. A job id derived from the action rather than the clock means a double-clicked apply is a single write, because the second job is the same job. An id carrying a timestamp makes it two.
What should never be applied automatically
Some changes are safe to make mechanically and some are not, and the distinction is not about risk of breakage — it is about whether a machine can tell that the result is right.
| Change | Safe to automate? | Why |
|---|---|---|
| Title and meta description | Yes, with approval | Bounded, visible, trivially reversible, and the quality is judgeable from the diff alone. |
| Schema markup | Yes, with approval | Structured and validatable, provided it mirrors what is actually on the page. |
| FAQ blocks | Yes, with approval | Additive, and the markup and prose can be generated together so they cannot drift. |
| Internal links | No — propose only | Correct placement depends on the surrounding prose reading well, which nothing can verify from outside. |
| Body content rewrites | No — propose only | The failure mode is a page that is subtly wrong about your own business, and nobody notices for months. |
| Navigation changes | No — propose only | Site-wide blast radius. One bad write affects every page at once. |
SEOGrowPilot draws the line in exactly those places. Internal links and page updates are proposed with the exact change spelled out, and a person makes them. Refusing to automate something is a feature; the alternative is a tool that will confidently rewrite your prices.
Verify the write, and log it immutably
01Re-read immediately before writing
If the page is not what was priced and previewed, stop. Do not write a change that was approved against different content.
02Write
Through the single lane, with the snapshot already stored.
03Re-read immediately after
Confirm the change is actually present. A write that changed nothing is a failure, not a success — usually a CMS silently rejecting or rewriting the field.
04Record it where it cannot be edited
Who approved it, what changed, when, from what state, and what it was forecast to be worth. An audit log that can be amended after the fact is documentation, not evidence.
05Measure against the baseline taken at apply time
That is the only comparison that means anything, and it is why the baseline has to be captured then rather than reconstructed later.