Audit and normalize a post-meta key across posts

MaintenanceAdvanced~20 min

Before you start

A connected site with content reads on and the update-post-meta write ability enabled. The meta key must be one your allowlist exposes; protected and underscore keys are out of reach. Back up the database first, since meta writes are not saved in post revisions.

Custom fields drift the way everything drifts: one author typed the value in title case, another in lowercase, a third left a trailing space, and a fourth pasted a date in a format nobody else used. On their own each is harmless, but a template or a filter that keys off that field starts behaving differently post by post, and you cannot see why until you line the values up side by side.

This prompt lines them up for you. It reads one meta key across the posts you name, groups the mess so it is obvious, and normalizes only the values you sign off on.

The prompt
I want to audit and tidy up the [subtitle] custom field across [the posts in
the "Reviews" category]. Work in two passes and write nothing in the first.
First pass: pull the current value of that meta key on every post and group
them so the mess stands out, mixed casing, stray whitespace, different date
formats, blanks, whatever you find. Show me a before-and-after table for the
first [15] with your suggested normalized value beside each current one.
I will say which fixes to keep. Only then, write the approved values back one
post at a time in small batches, showing me each batch before it saves. Post
meta is not covered by revisions, so keep a running list of every post and
value you change and hand it to me at the end.

Why this is safe to run

The first pass is all reads. Listing the posts and reading their meta writes nothing, so you see every proposed change as a before-and-after table before a single value is saved. The reads themselves stay inside the allowlist: protected keys, underscore-prefixed keys, and anything non-scalar are never returned, so the agent cannot even see internal or plugin-private data, let alone change it.

The write half needs one honest caveat, so this recipe leans on it hard. Post meta is not part of the revision history, so unlike a body edit there is no one-click restore. That is exactly why the flow writes only what you approved, works in small batches you can watch, and returns the full list of changed posts and values as your record. Take a database backup before a large run, and the approved table plus the Activity Log tell you precisely what moved.

Already connected? Skip the paste. Ask your agent for the “audit and normalize a post-meta key” recipe, or just name the field and the posts, and it runs the same two-pass flow on your own site.

How it works

  1. List the posts you name and read the target meta key on each one.
  2. Group the values so the inconsistencies stand out, like mixed casing or stray formats.
  3. Show a before-and-after table for a sample and wait for your approval.
  4. Write the approved, normalized values back one post at a time, in small batches.
  5. Return every post it changed so you can review the run.

Questions

Can it undo a meta change?
Not through revisions. Post meta is not stored in the revision history, so the before-and-after table you approve and the Activity Log are your record. Back up the database first.
Which meta keys can it touch?
Only allowlisted scalar keys. Protected keys, underscore-prefixed keys, and non-scalar values are excluded by design, so the agent cannot reach internal or plugin-private data.