Using AI to Update ACF Fields and WordPress Content

AI plus WP-CLI plus ACF is the canonical pattern for bulk content updates that used to take a careful afternoon and now take twenty minutes. The throughput win is real. The safety patterns are not optional. Used carelessly, this stack can rewrite thousands of ACF field values in minutes, and the rollback is "restore from backup, hope you have one." Used carefully, it is the highest-leverage thing I do on the directory sites I run. Here is the canonical pattern.

Jump to:

• The canonical pattern: AI plans, WP-CLI runs, you approve
• Pattern 1: schema-aware update_field at scale
• Pattern 2: content rewrites with a quality gate
• Pattern 3: image alt-text backfills
• Pattern 4: data normalization across many posts
• Pattern 5: Flexible Content layout migrations
• The safety patterns that prevent disasters
• What I will not delegate

The canonical pattern: AI plans, WP-CLI runs, you approve

Every AI-driven content update on the sites I run follows the same three-stage shape:

1. Describe the goal in plain language. "Update the phone ACF field on every listing post to normalize the format to +1-XXX-XXX-XXXX." Include constraints, edge cases, expected outcomes.
2. AI proposes a WP-CLI command or script. A wp eval-file script, a custom WP-CLI command class, or a sequence of wp invocations. Always with --dry-run support.
3. You read the proposed code, run dry-run, eyeball the output, then approve the real run.

The AI never runs writes on production directly. Staging takes the agentic loop; production goes through a code-reviewed deploy. Covered in detail in Using AI with WP-CLI for Faster WordPress Operations.

Pattern 1: schema-aware update_field at scale

The most common use case. Update an ACF field across thousands of posts based on a transformation rule.

Real prompt:

Write a WP-CLI script that:
- Iterates every "listing" post.
- Reads the ACF field `address_state` (a text field with the full state name).
- Maps it to the two-letter postal code using a hardcoded lookup table.
- Writes the result to a new ACF field `address_state_code`.
- Leaves `address_state` untouched.
- Supports --dry-run that logs the planned change without writing.
- Logs each affected post ID with before -> after.
- Outputs a summary at the end.

Do not run it. Save to /tmp/migrate-state-codes.php and print
the invocation command.

The output is a clean script using update_field with the right shape per field type, dry-run guarded, logging cleanly. You read it, run dry-run on staging, verify the planned changes are correct, run for real on staging, then deploy to production.

The acceleration: a script that would have taken 90 minutes to write and test by hand takes about 15 minutes including review.

Pattern 2: content rewrites with a quality gate

For content rewrites (e.g., "rewrite every listing's short_description to be more concise"), AI generates one rewrite per post. The crucial pattern: never auto-publish. Stage rewrites to a holding field for editorial review.

Write a WP-CLI script that:
- Iterates every published "listing" post.
- Reads the current `short_description` ACF field.
- Uses the Anthropic API to generate a tighter version (max 240 chars).
- Writes the new version to a holding field `short_description_pending`.
- Leaves the original `short_description` untouched.
- Stops after 50 posts (chunk size).
- Logs each post: ID, before length, after length, preview.

Do not run. Save to /tmp/rewrite-descriptions.php.

After it runs, the editor reviews the holding field's values, approves the good ones (which writes them to the live field), discards the bad ones. The editor stays in the loop on every published change.

This pattern is the one that distinguishes responsible content-update workflows from disasters. The script writes to holding fields, not live fields. The human approves before anything user-facing changes.

Pattern 3: image alt-text backfills

Accessibility audits often surface "many images on the site have empty alt text." AI is well-suited to generating descriptive alt text from image filenames, captions, and surrounding context.

Write a WP-CLI script that:
- Finds every attachment in the media library with empty
  _wp_attachment_image_alt meta.
- For each, fetches the image (or reads it locally), generates
  descriptive alt text via the Anthropic API based on the image
  visual content plus the attachment title/caption.
- Writes to _wp_attachment_image_alt.
- Skips images that are clearly decorative (icons, spacers, logos).
- Outputs a CSV of post_id, filename, generated alt for editor review.
- Supports --dry-run.

Do not run. Save to /tmp/backfill-alts.php.

Variation: write the generated alts to a custom meta key (_generated_alt_pending) and surface them in a wp-admin UI for editor approval before promoting to the real alt meta. Same approval-loop discipline as Pattern 2.

For the alt-text mechanics in ACF specifically, see How to Get ALT Text from an ACF Image Field.

Pattern 4: data normalization across many posts

The "the data is inconsistent and I need it consistent" case. Phone number formats, address capitalizations, URL schemes (http vs https), date formats stored as strings.

Write a WP-CLI script that normalizes the `phone` ACF field on every
"listing" post:
- Strip all non-digit characters.
- If 10 digits, format as +1-XXX-XXX-XXXX.
- If 11 digits starting with 1, format as +1-XXX-XXX-XXXX.
- If anything else, leave unchanged and log as "needs review".
- Output a report of all "needs review" entries.
- Supports --dry-run.

Do not run. Save to /tmp/normalize-phones.php.

Data-normalization scripts are usually safe (the transformation is deterministic, the rollback is "re-run from backup"), but always dry-run first to catch the edge cases the prompt did not anticipate.

Pattern 5: Flexible Content layout migrations

The most complex pattern. When a Flexible Content layout needs to be restructured (renamed, merged with another, or split apart), AI can write the migration that walks the existing data and produces the new shape.

Write a WP-CLI script that migrates the `page_builder` Flexible Content
on every "page" post:
- Find all rows where acf_fc_layout == 'old_hero'.
- Convert each to acf_fc_layout == 'hero_v2' with these sub-field
  mappings:
    - heading_text -> heading
    - sub_text -> subheading
    - cta -> Group field with sub-fields (cta.label, cta.url)
- Leave all other layouts untouched.
- Write the modified page_builder back via update_field.
- Outputs each migrated post ID with before/after.
- Supports --dry-run.

Do not run. Save to /tmp/migrate-hero-layouts.php.

Flexible Content migrations are the most error-prone because the data shape is nested. The dry-run output should be reviewed carefully: a script that drops sub-fields silently can quietly destroy years of content.

The safety patterns that prevent disasters

Non-negotiable patterns for any AI-driven content update:

• Snapshot before write. The first line of every migration script is wp db export /backups/pre-migration-$(date +%Y%m%d).sql.gz. The rollback is wp db import of that file.
• --dry-run flag on every script. Test mode that logs intent without writing. Never accept a script that lacks one.
• Run on staging first. Always. Even if staging is out of sync; even if "the script is obviously safe." The cost of staging-first is one extra wp db pull from production; the cost of skipping is a production outage.
• Holding fields for human approval on content rewrites. Never auto-publish AI-generated text directly to live fields. Always stage to a parallel field, surface for review.
• Chunk large operations. A script that touches 50,000 posts should process them in batches of 100-500, with a checkpoint between batches. Avoids long-running PHP that times out and leaves the database in a half-migrated state.
• Log every write. Per-post log of "I changed field X on post Y from value A to value B." If something goes wrong, you have the full record.
• Never let the AI run production credentials. The agent can SSH to staging; production deploys go through the normal pull request and CI pipeline.

What I will not delegate

A non-exhaustive list:

• Direct production updates. Always staging first, then deploy.
• wp db reset, wp db drop, wp site empty, or any equivalent destructive operation.
• User account deletion at scale.
• Anything that touches authentication, payment, or PII without explicit human review of every line.
• Auto-publish of AI-generated content to user-visible fields.

For the broader AI-in-agency workflow patterns (covering more roles than just developer), see How Small WordPress Agencies Can Use AI in 2026, by Role. For the Claude CLI side of these patterns, see Using Claude CLI to Manage WordPress Sites.

The honest take after two years of running this workflow on directory sites with thousands of ACF fields: AI accelerates the migration script work dramatically. It does not accelerate the judgment about whether a migration is correct, what the edge cases are, or whether the dry-run output looks right. Those still take human attention. What AI removes is the typing.