Archive maintenance is not a project. It is a chore that recurs: every month a few posts ship without meta descriptions, a few images land without alt text, and a policy or price changes somewhere in the back catalog. You do not need an agent that can do the job once. You need one that can do it every week without you re-explaining it, and a live site that never finds out about the drafts. Grok Build handles the first part: it lives in the terminal, reads the AGENTS.md briefing in your folder, and its headless mode runs the same instruction on a schedule, one line in a cron job.
Scratch handles the second part. Your posts, pages, and custom types come down as a folder of files on your machine, and Grok Build does 99% of the work there, in the copy. The last 1% never runs itself. Every change waits in Scratch as a word-level diff, you approve post by post, and only the approved ones write back over the REST API. The schedule prepares the work. You still decide what goes live.
How it works
- Scratch pulls your content into files. Posts, pages, and any custom post types land in a folder on your machine, auto-discovered, one file each, with an
AGENTS.mddescribing the layout, which Grok Build picks up automatically. - Grok Build edits the content.
cdinto the folder and rungrok, in plan mode for a big pass or headless withgrok -pfor a recurring one. Add a meta description under 158 characters to every post that is missing one. It edits the files, never the live site. - You review every diff and publish. Scratch shows each change beside the original, word by word. Approve what ships, and Scratch writes only those posts back over the REST API.
What people use it for
The archive cleanup that never happens because editing posts one at a time is too slow:
- Add a meta description to every post missing one, each under the character limit.
- Fix inconsistent title case and formatting across the whole archive.
- Refresh older posts that still name a product, price, or policy you have moved on from.
- Write alt text across the media library.
- Set the sweep up once, then rerun it headless as new posts accumulate.
Run it on 50 posts to settle the prompt. Then put the pass on a schedule and keep only the review for yourself.
Why not an MCP server?
A WordPress MCP server wires the agent straight to your live database, and a scheduled agent with live write access is the worst version of that: edits land on production while you sleep. You wake up to whatever it did.
Scratch keeps the schedule and removes the risk. Grok Build gets full read and write against a local copy, on whatever cadence you like, and the write to the live site stays separate, manual, and per-post. You wake up to a review queue, not a changed site.
What Grok Build edits in WordPress
- Post and page bodies, with block content preserved
- Titles, slugs, excerpts, and publication status
- Custom post types and taxonomies, auto-discovered
- Advanced Custom Fields and image alt text across the media library
Templates and template parts are excluded, and post meta is hidden by default, so plugin-owned SEO fields stay out of reach unless you expose them. Validators check length caps and any rule you set, and flag failures right next to the diff. For the full picture, see Scratch for WordPress.
Questions people ask
Is this a WordPress MCP server or a plugin?
Neither. Both of those write to your live database from inside the agent loop. With Scratch, Grok Build edits a local copy, and publishing is a separate step you approve, one post at a time.
Can the same cleanup really run on a schedule?
The editing half, yes. grok -p runs headless with the same instruction every time, so a weekly sweep over new posts can prepare its edits unattended. The publish half always waits: diffs sit in Scratch until you approve them, however they were produced.
Will it overwrite the SEO fields my plugin owns?
No. Post meta is hidden by default, so fields managed by your SEO plugin are not in scope unless you explicitly expose them. Templates and template parts are excluded entirely.
Can I roll back a post after it publishes?
Yes. Scratch keeps the original beside the rewrite after publishing, per row. You decide which version stays live.
Can it work a large archive in one pass?
Yes. A 2 million token context lets Grok Build hold a large slice of the archive, plus your rules, while it works, and parallel subagents can split a big backlog into simultaneous passes over the same folder.
Do I need to be technical?
You need to be comfortable in a terminal, and setting up the cron is on you. If you want the same loop without the terminal, the Claude desktop app runs it against the same Scratch folder.
See it on your own archive
The fastest way to trust it is to watch it run on your posts. Book a 30-minute demo on your WordPress site →, or try Scratch free and take the first pass yourself.