Workflow
Marketing
Website and CMS content updates
Small website changes wait weeks behind whoever holds the CMS login. An agent takes each request to a saved draft with the before and after side by side, and a named reviewer decides what goes live.
The short answer
Short answer
You keep website content current by letting an agent take each change request to a saved draft in your CMS, with the before and after side by side.
It edits only drafts, checks links, alt text and redirects, and logs what changed. A named person reviews every draft and publishes it.
Today
Why do small website changes sit for weeks?
The request is small: a new price, a team bio, an event date, a broken link someone noticed on a call. It lands in an inbox or a chat thread and waits for whoever has the CMS login and a free afternoon. By the time it ships, two more requests are queued behind it, and the wrong page has been wrong in public the whole time. Nobody owns the queue, so nobody can say what was asked for, what changed, or when.
Who is this for?
A business whose website runs on a CMS, where marketing or operations staff ask for changes and one or two people can make them. It suits a steady flow of small edits to pages that already exist. A redesign, a new template or a change to how pages are built is design and development work, and it stays with the people who do that work.
What changes when an agent takes the request?
| Part of the update | Request in an inbox | With an agent drafting |
|---|---|---|
| Where the request lives | An email or a chat message that scrolls away | A written request with the page and the change named |
| Who makes the edit | Whoever has the login, when they get to it | The agent, in a draft, as the request arrives |
| What the reviewer sees | The live page, after the fact | The current copy and the proposed copy together, with check results |
| What goes live | Whatever was typed into the editor | Only a draft a named reviewer published |
| The record | Scattered across threads, if it exists | One log entry per change: who asked, who approved, when |
| Undoing a mistake | Someone remembers what the page said before | The earlier version is restored from the page history |
How it works, step by step
Each step takes one request from arrival to a decision. The agent works inside the access you grant and nowhere else.
01
Take the request in writing
Every change starts as a written request: the page, the change, and the reason. A request that names no page, or asks for something the agent cannot find on the site, goes back to the person who sent it with a question attached.
02
Find the page and copy what it says now
The agent locates the page in your CMS and copies the text it is about to change, so the reviewer can read the old and new wording next to each other.
03
Write the change into a draft
It writes the edit into a draft or a pending revision, never into the published page. In WordPress, the revisions system stores a record of each saved draft or published update, so every draft lands in the page's own history.
04
Check what the edit touches
Hand edits tend to break the same things: links that stop resolving, images with no description, headings out of order. The agent checks each one on the draft. WCAG 2.2 sets the rule for images: all non-text content that is presented to the user has a text alternative that serves the equivalent purpose, with listed exceptions. When a change moves or renames a page, the agent drafts a redirect so the old address keeps working. Google Search Central recommends a permanent server-side redirect whenever possible when the URL of a page as it is shown in search engine results has to change.
05
Human gate: the page owner publishes
The draft goes to the person who owns that page, with the before and after and the check results attached. They publish it, send it back with a note, or reject it. Nothing reaches the live site without that decision. Approval gates explains why the sign-off belongs to one named person.
06
Log the change
Each update gets one entry: who asked, what changed, who approved it and when it went live. The log is what you read when someone asks why a page says what it says.
07
Keep the queue in view
Open requests, drafts waiting for review and recent changes sit in one list. Anyone on the team can see what is pending without asking the person with the login.
Guardrails
What should an agent never do on your website?
Publish on its own
It saves drafts. Publishing is the reviewer's action.
Change design or code. It edits copy, links, images and page settings inside the layouts you already have. Themes, templates, plugins and code stay with your developers.
Write claims nobody approved
Prices, offers, testimonials and legal wording come from the requester or the page owner, word for word.
Hold more access than the work needs
Where your CMS has a role that can save drafts without publishing, the agent's account uses that role.
Make a change you cannot reverse. The page history keeps the earlier version, and the log names the request that changed it.
Where this fits
Workflow / Automate a Workflow
This is a Tier 1 engagement, Automate a Workflow: one process, end to end. Website updates make a sensible first candidate when requests arrive often, follow a pattern and already end with someone checking the page. Run the readiness checklist against your own request flow first. Start in shadow mode, with the agent preparing drafts beside the person who does the updates today, so you can compare its drafts with theirs before any reach a reviewer alone. The use case library has the neighbouring workflows.
How does this differ from a content pipeline?
| Question | Content production pipeline | Website content updates |
|---|---|---|
| What starts it | A content calendar and a brief | A request to change a page that already exists |
| What it produces | A new piece, from outline to publish-ready draft | An edit to existing copy, links or images |
| What it checks | Brief, voice and schedule | Links, alt text, headings and redirects on the changed page |
| Who signs off | The editor who owns the calendar | The person who owns the page |
Related reading
- Content production pipelines that ship on schedule: new pieces taken from brief to a publish-ready draft.
- FAQ and help content that updates itself: keeping help articles in step with the questions customers ask.
- Approval gates: why each sign-off belongs to one named person.
Tier 1 / Prove
How It Works
Questions, answered
No. Every change goes to the page owner, a one-word fix included. A typo fix is also the quickest draft to review, because the before and after differ by a single word.
AI Opportunity Audit · Website updates
Clear the website changes waiting in the inbox
Bring the list of website changes waiting in someone's inbox.
Related use cases
Back to Use Cases
Workflow
Marketing
Content production pipelines that ship on schedule
A piece slips because its stage, its owner and the claim that still needs a source are written down nowhere anyone can look. An agent
Learn More
Workflow
Customer operations
FAQ and help content that updates itself
The help centre was accurate when it was written, and nobody finds out otherwise until a customer says so. This is how an agent starts
Learn More
Workflow
Back office
Knowledge base maintenance that doesn’t rot
An article goes stale because it has no owner and no date by which anyone was going to look at it again. This is how
Learn More