# How we keep our content from going stale Once a week an agent on Machine spots blog and marketing pages that are slipping in Search Console, freshens their copy, numbers and internal links, and opens a pull request for review. Canonical page: https://themachine.myapps.ai/use-cases/content-refresh 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. - **Team:** Machine - **Runs on:** Once a week, on a schedule - **Connected systems:** Google Search Console · GitHub - **Mode:** Same session each week · opens PRs, never publishes ## 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 ### Pick up the same session each week A **cron trigger** wakes the agent weekly, and instead of starting from scratch it sends a fresh prompt into a **reusable session**. That choice is deliberate. Rewriting every slipping page in one go would cause chaos, so the agent works in turns, and taking fair turns only works if it remembers which pages it has already handled. ### Spot the pages that are slipping A scoped **connector**, meaning a narrow connection with the key held on our servers, lets the agent read the site's Google Search Console data. It compares views and clicks per page for the latest period against the period before. The pages falling fastest, weighted by how much traffic they still bring in, make the shortlist. ### Check the ledger and share the attention Before choosing this week's pages, the agent consults its **ledger**: a record of which pages it has refreshed, and on what date. Something it fixed three weeks ago moves down the queue even if it is still sliding. A page it has never opened moves up. That simple rule stops the agent from fussing over the same handful of popular pages every single week. ### Update the wording, numbers and links For each page in the batch, the agent opens the source file in **GitHub**. It rewrites lines that now sound dated, replaces figures that have gone out of date, and points internal links away from pages that were renamed or retired. All of this happens on a separate branch. The live branch is left alone. ### Open a pull request and stop there At the end of the run the agent opens one PR that explains which pages changed, what changed and why. It does this through the **`gh` CLI**, signed in with a narrowly scoped `GH_TOKEN`. It does not publish and it does not merge. A person reads the diff and chooses what goes live. > **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 - **Every week:** A fresh set of fading pages found and brought up to date - **PR only:** Nothing goes live until a person has reviewed it - **0 repeats:** The ledger shares turns fairly, so no page hogs the attention 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.