seo/cleanup-indexables compares the indexable counts against the live content counts, so indexables left behind by deleted posts or terms are visible.
Read-only. Yoast runs its own scheduled cleanup and there is no entry point to force one from a request.
At a glance
| Ability | seo/cleanup-indexables |
| Toolset | Yoast SEO — toolset/yoast-seo |
| Group | Yoast SEO › Indexation |
| Requires | Yoast SEO, active on the site |
| Capability | manage_options |
| Safety | Read-only — changes nothing |
| Repeatable | Idempotent — running it twice leaves the same result |
| Ships in | AcrossAI Abilities Manager 0.0.34 and later |
How it works
When a post is deleted its indexable is supposed to go with it, and usually does. What leaves rows behind is everything that bypasses the normal deletion path: direct database deletes, bulk removal tools, migrations, a plugin cleaning up its own custom post type.
Those rows are not harmful in themselves — they describe pages that no longer exist and nothing renders them — but they inflate every count, they make the indexation figures misleading, and on a site that has been through several migrations there can be a lot of them.
Yoast cleans them up on a schedule of its own. There is no hook, no function and no admin action to trigger that cleanup immediately, so an ability claiming to fix this would be claiming something it cannot do.
Reporting the discrepancy is what is honestly available: the counts side by side, and the gap between them.
If the gap is large and persists across weeks, the scheduled cleanup is not running — which is a WP-Cron problem rather than a Yoast one.
Input
This ability takes no input.
What comes back
| Name | Type | What it is |
|---|---|---|
indexable_counts | object | How many indexables exist per type. |
content_counts | object | How much live content exists per type. |
discrepancy | object | The gap between them. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
Are there stale Yoast indexables on this site?
It resolves to one call:
{
"ability": "seo/cleanup-indexables",
"parameters": {}
}Worth knowing
- Read-only. There is no way to force Yoast’s cleanup from a request.
- Orphaned rows are harmless but make every count misleading.
- A persistent large gap usually means WP-Cron is not running.
- Migrations and direct deletes are the usual source.
Related abilities
- Get Indexation Counts — the counts alone
- Reset Indexation — rebuild from scratch instead
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category