AIOSEO MCP for its custom tables, not post meta

Finding the posts AIOSEO is quietly templating

An empty title or description in aioseo_posts is not an error. It means AIOSEO falls back to the post type template, and on most sites that is the right answer for the bulk of the archive. The useful question is which posts should not be on the template, and one-post reads cannot answer it. GoBuildWP Pro's plugin-neutral seo-bulk-get-meta can: it reads title, description, focus keyword, canonical, robots and Open Graph text for many posts at once from AIOSEO, with filters for missing descriptions, missing title overrides and duplicate effective titles.

Run it per post type with status publish. A filtered read inspects at most a thousand posts and says truncated when there were more, so a large blog needs several passes or a narrower post type. Duplicate titles are compared with smart tags unexpanded, so two posts both set to #post_title #separator_sa #site_title do not count as duplicates, but two that share the same typed override do. Before changing any of it, read the templates themselves with aioseo-get-settings scope titles, because a weak template is a one-line fix where hundreds of per-post overrides are not.

Bulk title and description changes without an undo

seo-bulk-update-meta writes through AIOSEO's own per-post writer, up to a hundred posts a call, with shared values or per-item values. On most SEO plugins each post's ledger row can be rolled back. On AIOSEO the rows are marked irreversible, because the data lives in aioseo_posts rather than the post row, and the ledger note says how to recover: re-run the bulk update with the before values from that batch.

So the order of work matters more here than on a meta-based plugin. Ask for dry_run true first, which returns each post's before and after and writes nothing, and keep that output. It holds the previous value of every field the call would change, which is what you would write back by hand if the change has to be reversed; it is not an automatic undo, and it does not cover edits anyone makes after the run. Then send the real call with confirm true and check the per-post results, since one failing post never stops the rest. A field AIOSEO does not store through this path fails that post with wppilot_seo_field_unsupported instead of being skipped silently.

• Robots in bulk follow the same all-or-nothing rule: setting index back to default also resets follow, and sending only nofollow to an inheriting post flips its index to index.
• Leave smart tags in place where a template already does the job; overriding a title with plain text freezes it.
• Keep batches small enough to spot-check in the page source before the next one.

Redirect housekeeping on AIOSEO Pro

Old AIOSEO Pro redirect tables pick up temporary 302s that became permanent, chains where a target was itself redirected later, and regex rules nobody remembers writing. aioseo-list-redirects returns compact rows with type, regex and enabled flags, newest first, up to five hundred per page, and its total respects the search filter, so an agent can page through a whole table and build a list of candidates without writing anything.

Fix candidates one at a time with aioseo-edit-redirect, which changes only the fields you send. Disabling a rule by sending enabled false is a gentler first step than aioseo-delete-redirect, which is permanent and asks for confirmation. Test a regex rule against the real URLs it is meant to catch before saving it, because a loose pattern can swallow paths you did not intend.

Pro also creates redirects on its own when a published post's slug changes, and AIOSEO Pro is one of the stores it can write to. Providers are tried in a fixed order, starting with the Redirection plugin, so on a site running both plugins the slug-change redirect may land in Redirection rather than in AIOSEO's table. Check which store holds it before assuming it is missing.