AI website maintenance can be safe when every change can be checked from outside and put back. It does not depend on how clever the AI is. Most of a normal agency retainer passes that test: updates, small content changes, broken links, backups. A few jobs do not, and this guide names them. It is written for an agency owner or freelance developer who does this work by hand today.
In short
- AI website maintenance is safe where the result can be checked from outside and the change can be undone.
- Updates, small content changes, broken links and backups pass, as long as the work is planned first and proved after.
- Database changes, payments and anything irreversible still need a person in charge.
- A version number or a 200 status is not proof. Status and page size per URL, before and after, is.
- Sell the retainer on the proof, not on the hours.
The job-by-job answer
This table covers the jobs on a standard retainer. Safe here means safe to give to an agent that makes a plan first, checks its own work and leaves a record. It does not mean safe to leave alone.
| Job | Safe to hand to AI today? | What a person still does | How you prove it |
|---|---|---|---|
| Plugin and core updates | Yes, once the plan has been read. | Chooses the time. Looks at anything the agent flags. | Backup first. New version read back from the file. Status and size for every key page, before and after. Screenshots. |
| PHP version upgrades | Partly. Preparing and testing yes. The switch itself, no. | Owns the switch and the date. Decides what happens to a plugin that will not run. | The new version tried on a copy first. A readiness scan that was proved on known code before its count is trusted. |
| Security patches on the server | Yes for applying and checking, with a person choosing the window. | Picks the window. Accepts the risk of a restart. | Every service that runs the software listed first and checked after. Every site on the server checked by what it serves. |
| Small content changes from clients | Yes. Text, opening hours, images, a price on a page. | Decides what a client may change. Checks anything about prices, legal wording or payments. | The page before and after, on desktop and phone, and a plain note of what changed. |
| Broken links and forms | Finding them, yes. Fixing them, yes when the fix is small. | Decides where a dead link should point. Confirms enquiries really arrive. | A list of links with a status each. A test message that reaches a real inbox. |
| Backups and restores | Backups, yes. Restores, with a person watching. | Decides where copies live and how long they are kept. | A backup counts once it has content: check the size and open it. A trial restore on a copy. No backup left reachable from the web. |
| Performance fixes | Some. Image sizes and caching, yes. Anything that rewrites CSS or JavaScript needs a closer look. | Judges whether a faster page still looks right at every width. | Timings and screenshots before and after, at desktop and at phone width. |
| Accessibility fixes | Partly. Missing labels and image descriptions, yes. Whether a page makes sense to someone using a screen reader, no. | Walks the page with a keyboard. Judges whether the fix reads well. | An automated check before and after, plus a keyboard-only walk through the page. |
| Monthly reports | Drafting the report from the job records, yes. | Reads it, adds what the client cares about, and sends it. | Each line in the report matches a job record with its own checks. |
Why safe means provable
A job is safe to hand over when someone can check the result without trusting the tool that did it. That is the whole test. In practice it comes down to four checks.
- Status and page size for every key URL, before and after. A 200 on its own is not proof, because an error page can return 200.
- The before taken twice. Some pages change on every load, so one baseline reads moving parts as failures.
- Screenshots before and after, at desktop and phone width.
- The new version read back from the file or from what the site serves.
From our records: 13 failures that were not failures
A Northgate client had 41 sites on one server. Before the change, the agent loaded every site twice and recorded status and page size. On 13 of the 41, a security token in the page changed on every load.
A single comparison after the change would have read 13 false failures. Two baselines showed which pages move by themselves, so those 13 were not mistaken for damage.
Example based on a real job, details changed.
The same applies to version numbers. A version number tells you what was installed. It does not tell you what is running.
From our records: a patched server still serving the old version
A PHP security update went onto a server for an Acme client. The package manager and the version command both said 8.2.35. But 25 customer pools ran under a hand-made service, and that service was still serving 8.2.33 from memory, because the update restarted only the standard one.
It showed up when the check looked at what was running, not at what was installed. The rule that came out of it: list every service that runs the software before patching, then check each one afterwards.
Example based on a real job, details changed.
The risky ones, and why
Four kinds of work stay with a person, whatever tool is doing the typing.
- Anything irreversible. If a change cannot be put back, a person decides. A plan approved in half a minute is not enough.
- Database changes. Files restore from a copy. A database holds orders, enquiries and accounts that keep changing while you work.
- Payments. A change to checkout is tested along the whole path by a person, not only on the page.
- Deploys at busy times. The agent can prepare everything and wait. Someone picks the quiet hour.
PHP upgrades sit in between. The preparation is safe to hand over, if the preparation itself is proved first.
From our records: 20 blockers that were not blockers
Before a PHP 8 upgrade for a Larch client, a search for the removed function each( flagged more than 20 blockers across four well-known plugins. All of them were JavaScript .each( calls or method calls, not the removed PHP function.
- The search was run on a small test file first: three real uses of removed functions and five safe lines.
- A good search flags 3 of 3 and 0 of 5.
- Only then was the count on the real code trusted.
Example based on a real job, details changed.
How to prove AI website maintenance to a client
A client does not want to read a log. They want to know the site is fine and what you did. Send the same short pack each month:
- What was done, in two lines they can read.
- Before and after screenshots of the pages they care about.
- The pages checked, with status and size, and any that moved explained.
- What was left alone and why, such as a plugin held back.
- How to undo it if they disagree.
With the Orchestrator, each job ends with a written validation, screenshots and checks, so most of this exists before you write a word. Any email the agent writes is saved as a draft by default, so a person reads it before it goes.
Pricing a retainer when the hours shrink
The hours go down. The risk does not. The client is paying for a site that stays right, not for time at a desk. We do not set your prices, and we will not guess a figure for you. This is how to think about it.
- Measure first. Track the real time per job for a month before you change a fee. On the Orchestrator you can see what each job cost to run.
- Price the cover, not the hours. Say what you watch, how fast you answer and what you prove.
- Keep a floor. A person still reads every plan and every proof. That time is real.
- Tier by what is covered, such as updates only, updates plus small changes, or both plus a report. Do not tier by hours.
The use-case page shows how the same idea works on a retainer: AI website maintenance for agency retainers.
Where Webgentic fits
Webgentic is two products, and they suit different jobs.
The Orchestrator is for an agency running retainers across many sites. A person approves a plan for each job. The agent works inside a sandbox for that one project and ends with screenshots and checks. We install it and train your team, and it is priced on a call. See how setup works.
Webgentic for sites is for a site whose owner wants to ask for small changes themselves. They type the request on their own site and see the plan. The change appears as it is made, and Stop cancels the job. There is no approval step, so a change is live as soon as it is made. Every change is saved with a plain-English note, and any earlier version restores in one click. On Drupal, restore covers files only, not content kept in the database.
Webgentic for sites does not watch your site for downtime or send alerts, so keep the monitoring you already have. For the security side of the retainer, see security patching and PHP upgrades.
