AI Website Maintenance: Let the Agent Fix It on a Branch, and Keep the Merge for Yourself

Every site I have ever owned has had the same quiet problem. Nothing breaks on a Tuesday. It breaks over about six weeks, in pieces nobody sees: a dependency two versions behind, a page returning an error to one visitor in fifty, a form that stopped sending mail in March.

The usual answer is a monthly maintenance retainer, which mostly buys you a person who looks at the site once a month. The answer people reach for now is an AI agent that fixes things for you. That one has a worse failure mode, because an agent that can change your live site on its own is a very fast way to turn a small problem into a large one.

There is a version in the middle that works. The agent does all the looking and all the drafting. You keep the merge. Here is how that setup works, and why each rule is there.

What is AI website maintenance, really?

Search for the term and you find two camps. One treats it as content upkeep: an agent that flags outdated pages and rewrites them. The other treats it as a dependency bot with a language model attached, one that bumps packages and opens pull requests.

Both are real, and both are narrow. Website maintenance in practice is five jobs that nobody owns at the same time:

1. Is it up, and is every path that matters actually working? Not the home page. The checkout, the signup form, the page your best article lives on.

2. What is erroring in production? Real errors from real visitors, grouped so you read one problem instead of four hundred lines.

3. What is going stale? Packages, lockfiles, and known security advisories.

4. Did the platform drift? The domain registrar, the host and the database should still match what you think you are running.

5. What small changes are waiting? The backlog of fixes a developer defers because none of them is urgent.

An agent can do all five. The question is not whether it can. The question is what you let it touch.

What should an AI agent be allowed to change on your site?

My answer is the same as for every agent I run: it can read anything, and it can only write to a place where you can undo the write.

For a website that place is a git branch. Every change the agent makes lands as a pull request, never as a push to the live branch. The agent opens it, you read it, you merge it. Your host already deploys from the main branch, so merging is the only action that changes what visitors see.

You can enforce that at the platform level instead of trusting the agent's instructions. GitHub's protected branch settings can require a pull request and a passing check before anything reaches the main branch. Turn that on. An instruction file saying never push to main is a hope. A branch rule is a wall.

I wrote about the same split in what to gate and what to let run unattended. Website changes land firmly on the gated side, because the cost of a bad change is paid by visitors before you hear about it.

How does an agent find problems before your visitors do?

The first daily job is a sweep, and the rule is that it checks from the outside. It requests every path you declared the way a visitor would, and records one dated observation per site: status, response time, and whether the page still contains the thing it is supposed to contain.

That last check matters more than it sounds. A page can return a perfect 200 and still be an empty shell, because the database behind it timed out and the template rendered nothing. I covered the false alert side of this in AI website change monitoring. The short version is to assert on content, not only on status.

The second half of the sweep is the part that saves the most reading time. It takes every new production error and groups it into a fingerprint: the same error from the same place, counted once with a tally beside it. You do not read four hundred log lines. You read nine fingerprints, ranked by how many visitors each one touched.

What does a safe fix look like?

When the agent works a fingerprint, the output is a branch with three things on it, and I will not merge one that is missing any of them.

• The change itself, kept small. One problem per branch. A branch that fixes an error and also tidies unrelated files is a branch you cannot review quickly, so you will review it badly.

• The project's own gate, passed. The agent runs the same build and checks you would run by hand, and the result is attached. If the gate fails, the branch says so instead of hiding it.

• A rollback line. One sentence at the bottom naming exactly what to revert if the change misbehaves after the merge.

The rollback line is the habit I would copy first. It costs the agent nothing to write, and it is the difference between a two minute undo and an hour of reading a diff while visitors hit the problem. For the retry side of this, meaning which failures the agent should try again and which must stop the run, see AI agent error handling.

How should an agent handle dependency updates?

Dependency debt is the one place where agents are genuinely better than people, because the work is dull, constant and easy to get wrong when you are tired.

The rule that keeps it safe is to split updates by blast radius. Patch versions and lockfile refreshes, the changes that are not supposed to alter behaviour, go on a branch automatically, one project at a time. Anything bigger, a major version or a framework upgrade, is held back with the evidence written down: what changed, what it would touch, and why it was not bumped.

GitHub's own documentation on version updates describes the same shape: updates arrive as pull requests, grouped by package, on a schedule you set. The agent adds the part that bots skip, which is reading the result and telling you which ones are safe to merge without thinking.

For security advisories, use the audit the package manager already gives you. The npm audit command reports known vulnerabilities in your dependency tree. Have the agent run it weekly and report the count with the packages named, rather than fixing everything it finds. A vulnerability in a package you only use in a build step is a different problem from one in code your visitors execute, and that call is yours.

How do you give it more freedom without losing control?

This is the part most guides skip, and it is why the setup survives past the first month.

An agent that can only ever open pull requests for you to merge is safe and, after a while, tedious. You will start merging without reading. So the permissions should move with the evidence.

Once a month the agent reviews its own record: how many of its branches you merged unchanged, how many you edited, how many you closed. Where a kind of change has been merged clean for a long streak, it can propose widening what it may do unsupervised for that kind of change only. Where one of its changes was reverted, it narrows immediately and does not wait for a streak.

The asymmetry is deliberate. Trust should take weeks to earn and one bad merge to lose. If your agent can widen its own permissions, make sure the proposal still goes to you, and that tightening needs no approval at all.

What about performance and the platform underneath?

Two weekly jobs round it out.

The first is a platform check. Read only, it confirms the registrar, the host and the hosted database still match your inventory, and names any drift with both values side by side. Most expensive website surprises are not code bugs. They are a domain that expired, a billing plan that lapsed, or a database that moved region.

The second is a performance pass. Google's Core Web Vitals documentation defines the three field measurements worth tracking. Have the agent record them for your key pages weekly and flag a regression with the date it started, which usually points straight at the change responsible.

How do you set one up?

You do not need to design this from scratch. I packaged the whole thing as the Web Dev Employee, one of the eight open source AI Employees, and its first run does the setup itself: it reads your repositories and hosts, writes an inventory of what you actually run, sets an opening policy for what it may change, and registers its own schedule.

It stops once, on the first reviewable change, so you can see what a fix looks like before anything runs on a timer. I walked through the roles, including this one, in the Open Source AI Employees session, and the full replay is available instantly if you want to watch an install happen.

If you want the rest of the set, plus the Masterclass and a library of software you can deploy for clients, the Agent Ops Club has a free plan. You can look around before deciding anything.

FAQ

Can an AI agent maintain a website on its own?

It can do the looking and the drafting on its own: checking pages, grouping errors, and writing fixes on a branch. It should not do the merging on its own. Keep the final step human until the agent has a long record of changes you merged untouched.

Is it safe to let an AI agent update dependencies?

Patch and lockfile updates are low risk when each one goes through your normal build and checks on a branch. Major version changes carry real risk and should be held for you with the evidence written down.

What is the difference between a dependency bot and an AI maintenance agent?

A bot opens pull requests on a schedule. An agent reads the result, runs your checks, groups production errors, and tells you which changes are safe to merge. The bot is one input to the agent, not a replacement for it.

How much does AI website maintenance cost compared with a retainer?

A retainer is a fixed monthly fee for a person's attention. An agent runs on the subscription or API usage you already pay for, and its cost is mostly tokens per run. For a handful of sites that is far smaller than a retainer.

What should I never let the agent touch?

Billing settings, domain records, and anything that deletes data. Give it read access to those and have it report drift, but keep every write with you.