
Every write below goes through the same shape: the agent reads first, shows a plan, and nothing is written until you approve it — with the whole run in the audit log.
Use this shape every time and bulk editing stops being scary:
# step 1 — find, don't change
List published posts in "Tutorials" older than 24 months with no featured image.
Table: title, slug, date, word count. How many in total?
# step 2 — propose
For those posts, propose a new category assignment based on their content.
Show old → new for every row. Change nothing yet.
# step 3 — apply
Apply rows 1-50. Summarise what changed, then wait.
nibwp snapshot create --post-type post -o before-bulk.json
# ...run the edit, check the result...
nibwp snapshot restore before-bulk.json # only if needed
One command turns a bad bulk edit from an incident into an inconvenience. Make it a habit for anything touching more than about twenty records.
For SEO-specific bulk work — titles, descriptions, schema — the dedicated workflow is in SEO at scale.
Most bulk-edit accidents are filter accidents. Some patterns that consistently produce the set you intended:
Merging a messy category structure — a job that is genuinely unpleasant by hand:
# 1 — see the mess
List every category with its post count, ordered by count ascending.
Flag ones with fewer than 4 posts.
# 2 — propose
For each small category, propose the best merge target based on the
actual content of its posts. Table: category, count, proposed target, why.
# 3 — apply, carefully
Merge only the rows I confirm. For each: reassign posts, keep the old
slug as a redirect to the target, then delete the empty category.
Report per merge.
The redirect line is the part people forget and regret. Deleting a category with inbound links silently creates 404s; keeping the slug as a redirect costs nothing at the time and saves the traffic.
Three checks that catch nearly everything, and take two minutes:
Yes — categories, tags, SEO meta, status, dates, featured images, custom fields and content patterns — using typed tools, with a plan shown before anything is written.
With the three-step pattern (find and count, propose old → new, apply in batches) plus a snapshot beforehand, yes. The risk is skipping the count, not the AI.
Yes, when your MCP server has an integration for your fields plugin — ACF, Meta Box, Pods and similar — so values are written through the plugin rather than as raw post meta.
Restore the snapshot you took first. Failing that, the audit log shows exactly which records changed and to what, so a targeted fix is possible.
Hundreds comfortably in batches. For tens of thousands of rows, a server-side tool like WP-CLI is the better instrument — agents excel where judgement is needed, not raw throughput.