Old pages rarely fall over. They fade. Your comparison page drifts from the first page of results to the second after a rival changes its prices. A blog post quotes a two-year-old figure, and a sharp-eyed reader emails to say so. A how-to guide points at a feature you renamed in the spring. None of it is broken enough to set off an alarm, so the page just keeps leaking views until somebody trips over it.

We gave that slow leak to an agent on Machine. Every week it checks Search Console for pages that are losing views and clicks, finds them in our content repo, updates the wording, the numbers and the internal links, and opens a pull request. It publishes nothing on its own. A person reviews the change and merges it.

The problem

No one blocks out an afternoon to reread a post from 2024. A piece gets written, goes live, and is left alone unless it visibly breaks. Meanwhile everything around it shifts. Prices move. Products get new names. Competitors rewrite their pages. What people search for changes shape. Search Console records all of this as a gentle slide in views and clicks, page by page. But nobody reads that report on a rhythm, and a line saying "this page is down" gives you no clue what to fix.

Doing it by hand cannot keep up. A disciplined content team might audit a few pages each quarter. A site with hundreds of pages goes stale much faster than that, so the few famous pages get all the care and everything else slowly crumbles in the background.

What we built

A weekly schedule on Machine sends a new prompt to a persistent session, so it is the same agent each time, carrying on from where it stopped seven days ago. It asks Search Console which pages have shed the most views and clicks, matches them to files in our content repo, and takes turns across the list so a few favourites do not soak up every visit while the rest go stale. For each page it picks that week, the agent rewrites tired copy, swaps out numbers that have expired, repairs internal links that point at renamed or replaced pages, and then opens a single PR for the whole run. It never pushes to the live branch, and it never merges its own work.

How it works

The pattern

Each week a cron sends a new prompt to a reusable session. The agent reads which pages are fading in Search Console, uses its own ledger to take fair turns across the site, and makes its edits on a separate branch. What comes out is a PR, and nothing is ever pushed to the live branch.

Guardrails

Because this agent edits our blog and marketing pages, the list of things it may do without a person is short:

• PR only, never publish. It opens a pull request and then stops. It cannot push to the live branch, and it cannot merge what it wrote.
• Isolation. Each run gets a sandbox of its own, which is a fresh cloud computer, plus a branch of its own. The live content branch is never edited directly.
• Scoped secrets. The GH_TOKEN that the gh CLI uses is stored encrypted in the Secrets Manager and only handed to the agents you grant it to, injected into the sandbox when the run starts.
• Read-only search data. The agent can only read Search Console. It sees which pages are fading but cannot change a single setting there.
• Everything is code. The ledger, the refresh rules and the agent's permissions all live as files in the repo, and they change through a reviewed change request, never a switch in a dashboard.

The outcome

Pages that once faded quietly for months are now spotted within a few weeks of slipping. They get refreshed in turn, across the whole site, not just the pages somebody remembered to check. The agent does the digging and the editing. The team still makes the call on what gets published.