The galleries are holding your archive hostage. The pass your Wix blog needs is ordinary, the 2023 pricing retired from the dozen posts still quoting it, excerpts written for the half that have none, 3 writers' tagging habits collapsed into one list, but a Wix post body is not text. It is rich content, a JSON structure of paragraphs, galleries, button blocks, dividers, and embeds, and every bulk route in or out of Wix treats that structure as a casualty. Flatten it into a spreadsheet cell and a gallery becomes a string. Round-trip it through Markdown and anything Markdown cannot express is gone. The one editor that fully respects the layout is the post composer, one post at a time. So the layout survives exactly as long as a human opens each post, and nobody is opening 300 posts. The archive never gets touched.
The fix is not a better converter, because conversion is what does the damage. It is a loop that never leaves the structure: pull every post into local files with the rich content intact, let your own AI agent edit titles, excerpts, tags, and body text inside that structure, read every change as a word-level diff next to the original, and send back only what you approve. The options below each cover some stretch of that loop. What separates them is whether they can touch the body at all, and whether the layout comes back alive.
Your options
The Wix editor, post by post
The post composer is the one place the layout is never at risk. You see galleries as galleries, the per-post SEO tab edits the slug, title tag, and meta description, and Post History can restore an earlier version of the content. For the 5 posts that need real attention, this is the right room. The cost is multiplication: every excerpt, tag fix, and body edit means opening another post, there is no find and replace across posts, and forum threads asking for one, or for a bulk author change, sit unresolved. Note what Post History restores, too: the content only. SEO settings, categories, and tags are not in the restore.
Wix's native bulk tools
The posts dashboard has multi-select menus, and users report adding a batch of published posts to a category at once; the help center documents little else in bulk. The real scale tools are in SEO Settings: apply a title-tag and meta-description pattern, with variables, to every blog post at once, with per-post overrides, and edit titles, descriptions, and slugs row by row in the Edit by Page table. For the meta layer, use them. They also stop at that layer. A pattern cannot write a unique description per post, nothing native bulk-edits body text, excerpts, or tags, there is no export at all, and a slug changed here gets no automatic 301 redirect, because Wix does not create them for blog pages.
Scripts on the Blog API
The Blog API can do the job, with care. Writes go through draft posts: update the draft, then publish it to push the change to the live post, and a bulk update endpoint exists behind the Manage Blog permission. Reading bodies takes a deliberate step, requesting the rich-content fieldset by name, and editing them means producing valid Ricos JSON. Wix ships a converter between Ricos and Markdown or HTML, but Markdown has no gallery and no button block, so a round trip can only keep what the smaller format can express. Direct node surgery is safer and slower to write. Past the rate limit the API answers 429, and the documented advice is to wait a minute. The review step does not exist until you build it.
Scratch
Scratch pulls every post into local files with the Ricos structure intact, and that is the difference. Your own agent, Claude, Codex, Cursor, or Copilot, edits titles, excerpts, slugs, tags, categories, hashtags, and the body text inside the structure; the gallery node it never touched is the gallery node that goes back. Every edit returns as a word-level diff, validators can lock the slug field outright, and approved changes write back to the draft side of each post through the Blog API, one at a time. Two honest costs: the diffs are real reading, on purpose, and publishing an updated draft to the live site stays a step you take in Wix.
| Option | Whole archive | Body text | Layout survives | Review before it ships | Undo |
|---|---|---|---|---|---|
| Editor, post by post | No | Yes | Yes, by hand | You are the editor | Post History, content only |
| Native bulk tools | SEO fields and categories | No | Untouched | No diff, edits are live | No |
| Blog API scripts | Yes | If your Ricos is valid | Your script's problem | Only if you build it | Only if you build it |
| Scratch | Yes | Yes, your agent | Preserved | Every change, as a diff | Per post |
How the loop works on your archive
- Scratch pulls your blog into files. Every post lands as its own local file: title, excerpt, SEO slug, tags, categories, and hashtags as plain fields, the featured flag, comments toggle, language, and hero image beside them, and the body with its rich-content structure intact. A 300-post archive is a folder. Nothing in Wix has changed.
- Your AI edits with the brief. Point Claude, Codex, Cursor, or Copilot at the folder. Reading 300 bodies through the API is paginated calls with the rich-content fieldset switched on, minutes of waiting before the first edit; the folder greps in under a second. With files, the agent can find every post still quoting the old pricing, build an index of posts missing excerpts, script the tag cleanup, then make the judgment edits one by one. Retire the 2023 pricing wherever it appears, write a 2-sentence excerpt for every post missing one, normalize tags to the attached list, and do not touch slugs or layout blocks. The agent does 99% of the work and holds no Wix credential while it does it.
- You review every diff and approve. Each change comes back word by word next to the original. Validators run first if you set them, and locking the slug field is the sensible default, because Wix creates no automatic 301 redirect when a blog post's slug changes. Approve what is right, and Scratch writes it back through the Blog API at the API's own pace, one post at a time, to the draft side of each post; you publish the updated drafts in Wix. The last 1%, deciding what your readers see, stays with you. Reject a change after the fact and the original goes back the same way.
Why the layout survives
A Wix post body is a Ricos document: a tree of typed nodes, paragraph, gallery, divider, embed, with styling carried as decorations. Anything that flattens that tree to edit it, a spreadsheet cell, a Markdown export, has to rebuild it afterward, and rebuilding is where galleries die. Scratch never flattens it. The structure comes down intact, the agent edits text where text lives and leaves the other nodes alone, and the same structure goes back. A pass like this usually covers more than prose:
- Retire old pricing and product names from every post that still carries them.
- Write the missing excerpts, in your voice, in one batch.
- Collapse three generations of tags and categories into one list.
- Turn comments off across the oldest posts, or set the featured flag on the 10 that still earn their traffic.
Questions people ask
Can AI edit the body without breaking the layout?
Yes. The body stays a Ricos structure the whole way through. The agent edits text inside the nodes that hold text; galleries, dividers, buttons, and embeds are nodes it leaves in place. The diff shows you exactly which words moved, so if a change did touch something it should not have, it is on your screen before it is anywhere near Wix.
Does Wix have a built-in way to bulk edit blog posts?
Partly. The posts list has multi-select actions, and adding several published posts to a category at once is reported to work. SEO Settings can apply a title and meta description pattern, with variables, to every post, and the Edit by Page table edits titles, descriptions, and slugs row by row. Nothing native bulk-edits body text, excerpts, or tags, and a pattern cannot write a unique description per post.
Can I export my Wix blog, edit a spreadsheet, and reimport?
No. Wix Blog has no export; the help center says so in as many words. The CMS route does not work either, because the Posts collection is read-only, so nothing edited in a spreadsheet can come back through it. The importers Wix does ship run one way, from WordPress or from another Wix site. The round trip dies at both ends.
Can I find and replace across every post?
Yes. As files, grep finds every post carrying the old phrase in under a second, the agent makes each replacement with the surrounding sentence in view, and every one still comes back as a diff. The Wix dashboard offers nothing equivalent for blog post bodies.
What happens to my slugs?
Nothing. Slugs change only if you decide otherwise. They are an editable field, but a changed blog slug gets no automatic 301 redirect from Wix, so the default brief says do not touch them, and a validator can lock the field so even a confident agent cannot. If slug changes are the point of the job, you approve each one knowing the redirect work is yours.
Does anything publish without me?
No. The agent works on local files and holds no Wix credential. Scratch writes only approved changes back, to the draft side of each post, one at a time. Publishing an updated draft to the live site happens in Wix, on your say.
Can I undo a change after it goes back?
Yes. The original stays next to every approved change, per post, and rejecting it sends the old version back the same way it went out. Wix's own Post History can also restore an earlier body, but content only; it does not bring back SEO settings, categories, or tags.
Do I need to understand Ricos?
No. You never see the Ricos JSON unless you ask for it. You write the brief in plain English, the agent handles the structure, and what you review is words next to words. The format being the obstacle is exactly what this loop removes.
See it on your own blog
The claim that the layout survives is easier to verify than to believe. See it run on your Wix blog →, or download Scratch free, connect your blog, and grep your own archive this afternoon. Scratch is free to try, and the AI is whichever agent you already pay for.