Every platform has a way to change a lot of content at once, and most of them are how catalogs get wrecked. CSV round-trips, live API writes, and admin-panel marathons all share the same gap: nothing shows you what changed before it ships. This post walks through where each one breaks, and how a pull, edit, review, publish loop closes the gap.
The problem with bulk CMS updates
CSV imports are the worst offender. Export a collection, edit a few fields, re-import, and the platform overwrites every column with whatever sits in your file. Unchanged fields get clobbered. Linked records drop because the CSV has no idea how to represent a relationship between two tables.
Direct API writes skip the file step and go straight to the live platform. Zapier, Make, MCP servers, and one-off scripts all share the same flaw. No diff, no review queue, no rollback. You find the mistake after it ships, and the original is already gone.
Manual edits in the admin panel feel safe because you see each change. They fall apart past ten records. Copy-paste errors compound, and nobody catches a transposed field on item 47 of 300.
The stakes scale with the size of the push. One bad bulk update can corrupt linked records across a base, break image references that other items depend on, or silently overwrite a field on hundreds of items at once. You need a layer that shows you every change before it touches anything live, and lets you reverse the ones you got wrong.
How Scratch handles it
Scratch turns every bulk update into a four-step loop. You pull a folder, your AI edits local files, you review the diff, then you publish. The AI never touches the live platform at any point in that loop.
Pulling a folder lands each record as a JSON file on your machine. One Webflow collection becomes a folder of files. One Shopify product becomes a single JSON file with prose and structured fields together. The platform stays untouched while you work.
Your AI edits those files, not the live API. Scratch points the AI at the folder with a pre-written briefing so it knows the project before it starts. Bring whatever AI you already use. Claude, Claude Code, Codex, Cursor, Cline, Windsurf, Copilot, or a plain Python script all work, because the only requirement is that the tool edits local files.
Once the AI finishes, Scratch shows you exactly what changed. You see a table of every edited record and a word-level diff inside each one. You approve the records you like and reject the rest, one record at a time.
Nothing reaches the live platform until you approve it. Click publish, and Scratch writes only the approved edits back through the platform's API, record by record. Rejected edits never leave your machine, so a bad rewrite stays a local file you delete instead of a live mistake you scramble to undo.
What the diff and review layer shows you
The diff layer is the centerpiece of Scratch, and it works on two levels. The first is a table of every record the AI touched. You scan the shape of the run before you read a single word of prose. New records get flagged, deleted images get caught, and fields the AI left alone show up grayed out so your eyes go straight to what changed.
Click into any row and you get the second view. Scratch shows the original and the edited version side by side, down to the word. You see exactly what the AI added and exactly what it removed. No guessing whether a rewrite quietly dropped a sentence or mangled a product spec.
Every record carries its own approve and reject buttons. Approve the ten that look clean, reject the three that don't, and leave the rest for a second pass. The original sits next to the edit the whole time, so you decide with both versions in front of you. Rejected edits never leave your machine.
Mistakes happen even after you approve. Re-pull the record and the original comes back in one click, no digging through platform admin or restoring from a backup. Nothing about the live CMS changes until you say so, and anything you regret reverses per record.
You can't unit test content the way you test code. There's no assertion that catches a tone that drifted or a meta description that lost the point. The diff is the test suite. Every record, every field, the original and the edit lined up so a human reads the change before it ships.
That review gate is the reason a bulk run of three hundred records feels safe. You approved each one, and you can prove it.
Why files beat direct API writes
A file gives you four things a direct API write never does. You get a diff that puts the original and edited version of every record side by side. You get a review queue that collects every change in one scannable table. You get a rule layer that enforces a quality bar before you ever look. And you get a rollback that reverses any change without touching the platform admin.
Validators are the rule layer. They are small Python files Scratch runs against every record before review, catching errors before a human reads a single word. A validator can reject em dashes, flag meta descriptions outside 120 to 160 characters, require tags on every product, or check that every article has a valid author and a recent date.
You don't write the validator yourself the first time. Ask your AI to write one, Scratch saves it alongside the project, then runs it on every future pull. The validator is the contract, and it holds whether you edit ten records or ten thousand.
Direct API writes give you none of this. A Zapier action, an MCP server pointed at a live CMS, or a quick script all push changes straight into production with no diff, no queue, no pre-review gate, and no clean undo. By the time you spot a broken image reference or an overwritten field, the original is often gone. Scratch keeps the original next to the edit until you approve it, and re-pulling a record restores it in one click.
Platform examples
The same loop works across every platform Scratch connects, but the fields it touches and the fields it locks differ by tool. Here is how it plays out where bulk CMS edits hurt most.
Bulk update Webflow CMS items
A CSV reimport into Webflow can blow away an entire collection. It drops linked references, breaks image bindings, and overwrites fields you never meant to touch. Scratch rewrites CMS collection items and page metadata as local JSON files instead. Your designer layout, components, and bindings stay put. You approve every change in the diff before it ships through the API.
Bulk update Shopify product descriptions
Editing product copy through the Shopify admin one listing at a time stops working past a dozen products. A bad bulk import can scramble variants or wipe metafields with no warning. Scratch rewrites product titles, descriptions, tags, and type as files your AI edits locally. Prices, variants, and metafields stay locked by design, so a copy refresh never touches a price. You review each product in the diff and publish only what you approve.
Bulk update Airtable records and push to CMS
Scratch rewrites text and linked-record fields in your Airtable base while formulas, rollups, and autonumber fields stay locked. You pull a table, your AI cleans the records, and you review every change before it writes back. Connect a second source like Webflow and the AI sees both folders, so it works the join between your base and your CMS collection without you mapping fields by hand.
Bulk update HubSpot properties
Scratch rewrites contacts, companies, deals, and tickets while workflows, lists, and emails stay put. Bad CRM writes are the worst kind to undo, since a botched bulk update can corrupt records that trigger downstream automation. The diff layer earns its keep here. You see every property change in a table, approve the ones you trust, and re-pull any record to restore the original in one click.
Bulk update WordPress posts
Scratch rewrites posts, pages, custom post types, taxonomies, and alt text while templates stay excluded. You pull a post type as local files, your AI does the rewrite, and the word-level diff shows exactly what changed before anything hits the REST API. Refreshing meta descriptions across three hundred posts or fixing alt text site-wide stops being a gamble, because you approve each post one at a time and nothing publishes until you say so.
Comparison: Scratch vs. the alternatives
Every tool below can change content in bulk. They differ on what happens before the change goes live, and whether you can undo it after.
| Tool | Diff & review | Linked records | Images | Selective updates | Rollback |
|---|---|---|---|---|---|
| Scratch | Word-level diff per record, approve or reject each one | Reads and writes linked-record fields, works the join across sources | Detects deleted or changed image references before publish | Edits only the fields you touch, locks formulas and computed columns | Re-pull restores the original in one click |
| CSV import/export | None. You upload a file and trust it | Flattens or drops relationships | Breaks references unless you hand-manage URLs | Overwrites every column in the row, including blanks | Manual. Re-import an old export and hope |
| Zapier/Make | None. Writes fire as soon as the trigger runs | Limited. Most steps treat one record at a time | No awareness of image dependencies | Updates mapped fields, but writes live with no preview | None built in |
| MCP server / direct API write | None. The AI calls the API and the change is live | Depends on the AI getting the call right, with no preview | No diff means a wrong image swap ships silently | The model decides what to write, you see it after | None. The original is gone once the call lands |
| Platform bulk editors | Edits show in-grid, but writes are live | Usually disabled for linked fields | Varies by platform, mostly manual | Field-level, but limited to one platform's UI | Manual undo where the platform offers it |
| Custom scripts | Whatever you build. Most teams skip it | Possible if you code it | Possible if you code it | Possible if you code it | Possible if you code it |
Custom scripts can match Scratch on every column. You have to write and maintain that review layer yourself. The MCP row matters most here, because direct API writes give an AI write access with no diff, no queue, and no way back.
When to use Scratch vs. the alternatives
Reach for a CSV when your data is flat and disconnected. Export, edit, reimport works fine for a price list with no linked records and no one waiting to sign off. Add a single relationship or a review requirement and the CSV starts dropping fields silently.
Write a custom script when you have a developer and trust the output enough to skip a review gate. The script publishes straight to the API and lives forever in someone's repo.
Pick Scratch when linked records are in play, when a human has to approve every edit before anything publishes, or when you run catalog-scale work across Webflow, Shopify, Airtable, HubSpot, and WordPress at once. The diff is the difference. You see every record and every field before a single change touches a live platform, and you reverse any edit per record without opening the admin panel.
Getting started
Scratch is free to download and runs on Mac or Windows. Most teams ship their first reviewed edit in about 20 minutes.
Connect one source with OAuth or an API token. Pull a single folder so you start small. Open the records in Claude, Codex, Cursor, or whatever AI edits local files. Review the diff record by record, then click publish.
Download Scratch free, then follow the /start/ walkthrough when you are ready for multi-source workflows and validators. For a real run with the numbers and mistakes left in, read Anatomy of a Scratch run.
See it on your content
If your next bulk update is the kind you don't want to gamble on, book 30 minutes with Curtis. He connects one of your platforms live and runs the loop on your own records, no pitch, no slides.