What your agent needs to update a client site safely
How AI agents for client work can update a live website safely: the request, the facts, a copy to work on, a version to roll back to, and a check first.
A dentist emails on a Tuesday: change the Saturday hours to 9 till 1, and add the new hygienist to the team page. It's a two-minute job, so you ask your agent to do it and go back to what you were doing.
The agent does both. It also notices the footer looks untidy and tidies it, removing the practice's registration number on the way. The change goes straight to the live site. Nobody notices until a patient asks why the number has gone. It's the risk a one-person AI agency takes whenever an agent touches a live site.
Nothing about that was malicious or even unusual. The agent was trying to help. What was missing was the setup around it. An AI agent can update a client's live website safely when it has five things: the exact request in writing, the client's current facts, a copy of the site to work on rather than the live one, a saved version to go back to, and a check of what changed before anything is published. This article goes through each one.
What does your agent need before it starts?
Three things, all written down.
The exact request. Copy the client's words into the task: "Saturday hours: 9am to 1pm. Add our new hygienist to the team page, name and photo attached." Don't paraphrase it. If the request is vague ("freshen up the home page"), ask the client before you ask the agent.
The client's current facts. Hours, phone number, address, services, prices, staff, and anything the business must show, such as a registration number. The agent should read these from the client's notes, not from the old website, which may already be out of date. Connecting your agent to your notes, rather than pasting them in each time, is what MCP is for.
The limits. Tell it which pages it may change and that it shouldn't touch anything else. "Change only the opening hours on the contact page and footer, and the team page. Don't change anything else. If you think something else needs fixing, tell me instead." That last sentence turns a helpful urge into a useful note.
If you're testing a new model for this kind of work, run it through a small test on a past project first; Claude Sonnet 5 for web development describes one.
Should the agent work on the live site?
No. Let it work on a copy.
For a site you build as files, the copy is your project folder with version control (a tool such as Git that records every change and lets you go back). For a site on a builder or a content system, it's a staging copy (a private duplicate of the site) if the platform offers one, or at least a fresh backup before you start.
Working on a copy does two things. Mistakes stay private until you've checked them. And the agent doesn't need the password to the live site, which is one less thing that can go wrong by accident.
The same goes for other logins. An agent updating opening hours doesn't need the client's domain account, their email password or their payment settings. Give it access to the project and the notes it needs for the task, and keep the rest with you. If a change genuinely needs a live account, such as updating the hours on the client's Google listing, do that step yourself, or check the agent's draft and make the change by hand. A short list of what the agent may and may not touch, kept with the client's notes, saves you deciding afresh every time.
If a tool you use makes changes on the live site itself, as some website builders with AI features can, check how it handles backups and staging before you let it near a client's site. The 10Web review looks at one of the AI WordPress builders in more detail.
How do you roll back a website version?
You can only go back to a version you saved. So save one before every change, even the small ones, and give it a name you'll recognise: "Before Saturday hours change, 21 July".
If you build with Claude Code, it has a related feature called checkpoints. Its documentation says Claude Code captures the state of your code before each prompt, and you can rewind to an earlier point with /rewind. It also lists the limits: changes made by commands the agent runs in the terminal aren't tracked, and checkpoints are meant for quick undo within a session, not as a replacement for version control. Use them as a safety net while you work, and keep your own saved versions for anything that goes live.
A good rule: every version that has ever been live should be one you can put back in a few minutes.
What should you check before it goes live?
Look at what changed, not only at the finished page. Most version control tools and many hosts can show a comparison of two versions. Then check:
| Check | What to look for |
|---|---|
| Only the asked-for pages changed | Nothing in the footer, menu or other pages unless you asked |
| The facts match the client's notes | Hours, names, spellings, phone numbers |
| Nothing required went missing | Registration numbers, legal notices, cookie banners |
| It works on a phone | Open the changed pages on a real phone |
| Links and forms still work | Tap any link or button near the change |
| The agent told you what it did | Its summary matches what you see in the comparison |
The last check catches a surprising amount. If the agent says "updated the hours" and the comparison shows ten files changed, you've found the problem before the client does.
Who approves the change?
You do, every time: you publish only the version you've checked.
For some changes the client should approve too. Agree which in your care plan. Opening hours, a new photo or a typo can usually go live once you've checked them. A new service, a price change or new words about the business should go to the client first, as a link to the exact version, not a description of it. Approving one exact version explains why the version matters: "yes, that's fine" should refer to one thing, not to whatever the site looks like later.
Showing the client that version clearly is its own skill; website revision approval covers how to send a version a busy owner will actually look at. And whatever goes out to the client, approving what your agent sends keeps you as the one who decides.
What does the whole routine look like?
For the dentist's request, from email to live site:
- Copy the request word for word into the task, with the limits.
- Save a named version of the current site.
- Let the agent make the change on the copy.
- Read its summary, then compare the two versions.
- Check the facts, the phone view and the links.
- Publish the checked version, or send it to the client first if the care plan says so.
- Tell the client it's done, and keep a note of the version and the date.
It adds a few minutes to a two-minute job. It also means the registration number is still there on Wednesday.
Where Volant fits
Volant has version history for every website, so you can compare versions and go back to any earlier one. You choose which one goes live. The page on building, reviewing and delivering client websites shows how that works from the first draft to the latest update.