Start with the Activity log tab on WP Visibility → Review queue. The log records ability calls that completed; a call that was refused or failed normally leaves no row. If one of the held writes (step 3) is there with the outcome ok while Hold for my review was selected, and it was not a bulk dry run, the call created a proposal; step 1 finds it. The proposal ID went back to the assistant in its response; the log does not show it. If the call is not there at all, either it failed and the error went to the assistant (step 4), or the assistant did not go through the plugin, and what it changed, if anything, went through a WordPress route the queue does not see. The Review queue is in the menu only while Autopilot is on; without it, wp visibility agent log prints the same rows.
1. Check the filter
On the Proposals tab set Show to Needs review, the default view. Applied, rejected, reverted and failed proposals are under their own filters, and All shows every proposal. The list does not refresh by itself: click Refresh if the tab was already open when the proposal was created, and reload the page to update the menu count.
2. Check the three settings
Assistant writes are held as proposals only when all three hold:
- The Assistant connection module is on (Settings → Modules).
- The Autopilot module is on.
- Assistant changes is set to Hold for my review. With Apply immediately selected, supported writes are applied at once and never appear as proposals; look for them in the activity log instead.
3. Check what the assistant actually called
Seven abilities are held as proposals: updating a post’s SEO fields, bulk SEO updates, settings changes, creating a redirect, deleting a redirect, editing llms.txt and changing the AI crawler policy. One more, propose-brand-fix, always queues its change as a proposal while Assistant connection and Autopilot are on. Anything else does not create a proposal, by design:
- A bulk update runs as a dry run unless the call sets
dry_runtofalse. A dry run is a preview and creates nothing. - Creating or editing a draft is content work and is separate from the SEO queue.
- Imports run directly.
- A change made through the core WordPress editor or a core REST route such as
/wp/v2/postsis not a plugin ability and is never queued, even when the assistant’s credential made it. The activity log will not show it either.
Ask the assistant which tool it used. If it used one of the seven and the call succeeded, the activity log has the row; with Hold for my review on, and unless it was a bulk dry run, the response the assistant received includes a proposal_id.
4. Read the error the assistant received
A refused or failed call is normally not logged, so ask the assistant for the exact error text it got back and match the code in it.
| Error | Meaning |
|---|---|
agent_paused |
The assistant is paused. Nothing was queued or written. |
ability_invalid_permissions or rest_ability_cannot_execute |
WordPress refused the call before it ran. Through the built-in MCP endpoint a pause is reported this way too, so check the pause first. Otherwise the connecting user lacks the capability for that ability. Post SEO needs edit rights on the post; bulk updates, settings, redirects, llms.txt and the crawler policy need manage_options, which by default only administrators have (WordPress roles and capabilities, checked September 27, 2026). |
rate_limited |
The hourly write limit for that user and client was reached. Nothing was written. |
queue_full |
500 pending proposals are already open. Approve or reject some, then try again. |
A proposal_id in the response |
The proposal exists. Go back to step 1. |
If the queue itself will not load
“The review queue could not be loaded.” means the page’s own request to /wp-json/wpvis/v1/proposals failed. Confirm you are still logged in as an administrator, then look for a security plugin or firewall blocking that path, and click Try again.
Still stuck? Write to support@wpvisibility.com with the error text, the activity log row if there is one, and your plugin version.