How to make big changes to a live website safely

What counts as a big change

Anything that touches more than one section at once, or anything that touches the parts that earn money: a new design direction, a restructure into several pages, rewritten services and prices, a new booking setup, or a change of action colour and theme across the site. Small edits such as opening hours don't need this whole routine, though the last two steps still apply.

Before you change anything

1. Write down the current version. Open history in the builder and note the number of the version that's live. Saves are kept as versions you can preview and restore (the most recent ones, up to your plan's number); this one is your way back, so don't let a long run of drafts push it out of the list.
2. List what must still work afterwards. Each form, each buy or booking button, the contact details, and the pages people link to. This becomes your test list.
3. Pick a quiet hour. Look at your daily views in the dashboard and choose the slowest part of the week. For a café that might be Monday evening; for a business-to-business site, a weekend.

Making the change

Editing the project doesn't change the live site; visitors see the published version until you publish again. The exception is CMS content: collection pages such as /menu/ read their entries when someone visits, so an edited entry shows at once. Leave collection edits until the change goes live, or make them knowing they're immediate.

Make the change in sentences ("split this into Home, Services, About and Contact pages and move pricing onto Services"), or by hand in the visual and layout editors. Then review it as a visitor would, at phone and laptop widths, section by section.

Checks before publishing

Release checklist

Runs every publish check without publishing: the Critic's design checks, the design gate's basics and Sentinel's security checks. Fix anything it flags.

Map tab

In Pro mode, it draws the site's sections, forms and connectors and checks nothing broke after a change. A form that disappeared in a rewrite shows here.

A second look

Send a client review link to a colleague or the client. They need no account, can comment on specific sections, and the link can be revoked afterwards.

Automatic checks catch unsafe pages, empty links and design basics; they don't test whether outside links still work. They don't catch a wrong price or a lost paragraph. That's what the second pair of eyes is for: ask them to check content against your test list, not to give an opinion on the design.

Publishing and the hour after

1. Publish at the hour you picked. The server re-runs the security checks that matter for a public page, and a failing page can't go live.
2. Open the live site on your phone, not the preview, and work through the test list.
3. Send a real submission through each form and check it arrives by email and in any connector.
4. Click each buy or booking button and confirm it reaches the right checkout or calendar.
5. Check the next day's views against a normal day, to catch anything that's quietly sending visitors away.

If something breaks

Decide in advance what's bad enough to roll back rather than fix forward: a broken form or wrong prices usually are; a typo isn't. To roll back, open history, preview the version you noted, restore it and publish again. A restore is added as a new version, so the change you rolled back is still in the list to fix later. Separately, Anticode keeps backups of the last ten published versions, and an integrity scan checks each site's published files about once a day. The version history page and the guide to rolling back a website cover the details.

Limits

• No built-in staging site. The preview and review links do that job; a separate test copy at another address would be one you keep in step yourself.
• No scheduled publishing. Someone has to press publish at the quiet hour.
• No split testing. You can't show the new version to some visitors and the old one to others.

Questions people ask

Will visitors see my changes while I'm working?

Not on the published pages: they stay as they were until you publish again. CMS collection pages are the exception, as they show entry edits straight away.

How do I undo a change after publishing?

Open history, preview the version that was live before, restore it and publish. The restore becomes the newest version, so the change you rolled back stays in the list for a while.

What's the single most useful step in how to make big changes to a live website safely?

Testing every form and button on the live site straight after publishing. It's the step most often skipped and the one that catches the costliest breakages.