Website Rollback Plan: How to Undo a Change Safely

The short answer

For every change, write down five things before you publish: where the change lives, where the previous version is kept, who can restore it, what would trigger a rollback, and what you will check afterwards. Roll back at once for breakage; for disappointing numbers, wait until the measurement window ends. Then log the rollback like any other change.

What a rollback plan is, and is not

A rollback plan is a short, specific note attached to one change. It is not a backup policy or a disaster recovery plan, although it depends on both. Backups protect you if the site is lost; a rollback plan gets one page, template or setting back to how it was, quickly, when a change you just made turns out to be wrong.

It sits between two other habits. The approval step decides whether a change should go live at all (see human-in-the-loop website changes), and the website change log records what changed and when. The rollback plan covers the gap: what to do if the approved change misbehaves.

Why speed matters, and why it is not the whole story

Some mistakes cost you while they are live and keep costing you after you fix them, because search engines react to what they saw. Google's own documentation gives three examples worth knowing:

Server errors. 5xx and 429 errors "prompt Google's crawlers to temporarily slow down with crawling"; already indexed URLs are preserved for a while, "but eventually dropped" if the errors persist¹.
A stray noindex. When Googlebot next crawls a page with a noindex rule, Google will "drop that page entirely from Google Search results"². Removing the rule does not restore the page until Google crawls it again.
robots.txt. Google "generally caches the contents of robots.txt file for up to 24 hours"³, or longer if Google cannot refresh it, so reverting a bad robots.txt does not take effect in Google straight away.

After a revert, Google has to recrawl the affected pages. You can ask it to with the URL Inspection tool in Search Console, but there is a quota, "crawling can take anywhere from a few days to a few weeks", and "requesting a recrawl multiple times for the same URL won't get it crawled any faster"⁴. The faster you catch the problem, the less there is to recover.

Know where each change lives

The way back depends on where the change was made. A single "website change" often touches more than one place: a new services page might involve page content, a template tweak, a redirect and a new tracking tag. List each one.

Where the change lives	Typical way back	Watch out for
Page content in a CMS	The CMS's revision history	Revisions may not cover every field. WordPress, for example, tracks title, author, content and excerpt by default⁵, so plugin fields such as SEO titles may need their own copy
Templates, theme or code	Redeploy the previous version from your hosting or deployment platform	Data changes are separate. Cloudflare's Workers documentation, for example, notes that "resources connected to your Worker will not be changed during a rollback"⁶
Tags and scripts	Publish the previous container version in your tag manager	Google Tag Manager keeps container versions and a publish history; publishing an earlier version restores it⁷
Redirects and URLs	Restore the old redirect rules	Do not simply delete redirects that are already live. Google advises keeping site-move redirects "generally at least 1 year"⁸
robots.txt and meta robots	Restore the previous file or tag	Google's cache and recrawl delays, described above
CDN, cache and DNS settings	Restore the previous setting	Cached copies may keep serving the bad version until you purge them
Forms and integrations	Restore the previous form or connection	Submissions made while it was broken may be lost or misrouted

For each entry, save the previous version somewhere you can reach without the system that just broke: an export, a copy in the change ticket, or the version number in your deployment tool.

Decide the triggers before you publish

The hardest moment to decide whether to roll back is when something looks wrong and people disagree. Agree the triggers in advance, in two groups.

Roll back at once: breakage

The page returns an error, or a redirect loops.
The title, main heading or main content is missing or wrong.
A noindex rule or a robots.txt block appears where it should not.
The layout is visibly broken on mobile or desktop.
A form or call to action does not work.
Analytics or key event tracking stops recording.
The page now says something inaccurate, such as a wrong price or a claim nobody approved.

Do not roll back on noise: performance

A dip in clicks or enquiries in the first few days is usually not evidence of anything. Decide the measurement window before publishing, wait for all of it, then decide. If the result is unclear, our guide to inconclusive website test results covers what to do. A rollback made on noise throws away the change and the learning.

Check straight after publishing

Most breakage shows up within minutes, if someone looks. Run the same short checks after every publish, and again after every rollback. A few lines of shell are enough for the basics:

url="https://www.example.com/services/payroll/"
curl -s -o /dev/null -w "%{http_code}\n" "$url"     # expect 200
curl -s "$url" | grep -io '<title>[^<]*'          # expect the approved title
curl -s "$url" | grep -ic 'noindex'                 # expect 0
curl -sI "$url" | grep -i 'x-robots-tag'              # expect no noindex
curl -s https://www.example.com/robots.txt          # expect no new Disallow lines

Then look at the page yourself on a phone and a desktop, submit the form once with a test entry, and confirm that the visit and the test submission appear in your analytics.

Release in stages where you can

Google's SRE workbook defines canarying as "a partial and time-limited deployment of a change in a service and its evaluation", and when a canary looks bad, it suggests that the team "pause and roll back the deployment"⁹. Most marketing teams cannot route a share of traffic to a new version, but the same idea scales down:

Change one page before changing the template that a hundred pages share.
Publish early in the working week, when the people who can roll back are around, not on a Friday evening.
Avoid publishing during a campaign launch, when the cost of breakage is highest.

Roll back or fix forward?

Sometimes the fix is a one-line edit and faster than a revert. Use a simple rule: if you know exactly what is wrong and can fix it within minutes, fix forward and log it. If you are not sure what is wrong, or the fix needs testing, roll back first and investigate on the restored site. A known good version is a better place to think than a broken one.

What a rollback cannot undo

Search engine state. Pages dropped or recrawled while the change was live recover only when they are crawled again.
Cached copies. CDN and browser caches may keep the bad version until they expire or are purged.
Data. Form submissions, sign-ups and analytics recorded while the change was live stay as they are. Note the period so you can exclude or explain it.
Things people saw. Emails sent, ads approved and links shared during the window still point to what was live then. If URLs changed, keep redirects in place.

After a rollback

Run the same checks as after publishing.
Purge caches if the old version is still being served.
Request recrawling of the affected pages in Search Console, if search was affected.
Log the rollback in your change log, with the time, the reason and who did it. Any measurement window for the change ends here.
Tell the people who approved the change and anyone who relies on the page.
Write two or three lines on why it happened and what would have caught it earlier.

A rollback plan template

Attach this to each change. For a small copy edit it takes two minutes; for a template or URL change, take longer.

Change:           [what is changing, on which URLs]
Lives in:         [CMS / template / tag manager / redirects / robots / CDN]
Previous version: [where it is saved, version or revision ID]
Can roll back:    [name], backup: [name]
Publish window:   [day and time; avoid campaign launches]
Checks after:     status 200, approved title, no noindex, layout, form, tracking
Roll back now if: errors, missing content, noindex or block, broken form or tracking
Decide later on:  [primary metric] at the end of [measurement window]
After rollback:   checks, purge cache, request recrawl, log, tell approvers

Practise once

A rollback that nobody has tried is a guess. Pick a low-risk page, make a harmless change, then roll it back using the plan, and time it. You will find out whether the person named has access, whether the CMS keeps the fields you need, and how long your cache takes to clear, before any of it matters.

The checklist

Check	Pass if
Scope	Every place the change touches is listed
Previous version	Saved for each place, reachable without the changed system
People	A named person and a backup can roll back, and have access
Triggers	Breakage triggers and the measurement window agreed in advance
Timing	Published when the people who can roll back are available
Checks	Run after publishing and after any rollback
Search	noindex, robots.txt and redirects checked; recrawl requested if needed
Record	Publish and rollback both logged with time, reason and person
Practice	The rollback route has been tried at least once

For how rollback fits into the wider optimisation loop, see our guide to AI website optimisation.

Where Artiweave fits

Artiweave builds part of this plan into each change it publishes: the previous version is kept, the page is checked after publishing and rolled back automatically if it breaks, and each publish and rollback is recorded. The triggers that depend on judgement, such as a claim your team no longer stands behind, stay with the person who approved the change.

Frequently asked questions

What is a website rollback plan?

A short note attached to a website change that says where the change lives, where the previous version is kept, who can restore it, what would trigger a rollback, and what to check after publishing and after reverting.

When should I roll back a website change?

At once if something is broken: errors, missing content, an unexpected noindex, a broken form or lost tracking. If the change works but the numbers look worse, wait for the measurement window you agreed before publishing, then decide.

Does rolling back a change fix my Google rankings straight away?

No. Google has to recrawl the affected pages, which can take from a few days to a few weeks. Google also caches robots.txt for up to 24 hours. You can request recrawling of key pages with the URL Inspection tool in Search Console.

Should I roll back or fix forward?

Fix forward only if you know exactly what is wrong and can fix it within minutes. Otherwise roll back to the last known good version first, then investigate.

Sources

All sources accessed 3 November 2026.

Every change approved, every change reversible.

Artiweave publishes only the website changes your team approves, keeps the previous version, rolls back automatically if a page breaks, and reports each outcome honestly. It is in private beta.

Join the waitlist