Working with an assistant guide
Turn an Assistant SEO Audit Into a Fix List It Can Execute
Sort every audit finding into a verified fact, an operation the assistant's tools support, or a manual handoff, then approve the smallest useful job first.
On this page
Before an assistant fixes anything from its own audit, sort each finding three ways: what evidence supports it, which of the connected tools could change it, and who should decide. A finding with no tool behind it is a handoff, not a task. A finding the tools can change still needs a person to confirm it is a problem. The fix list you approve is the short set of rows that pass both tests, and the first job is the smallest of those.
This matters because an assistant writes a confident audit whether or not it checked anything. Some of its findings come from tool output you can see. Others come from general SEO advice, a guess about the page, or text on the page itself. Mixing them lets a plausible report quietly widen what you asked it to do.
Ask for the audit with its evidence attached
Start from a request that separates observation from opinion:
Audit these five pages. For every finding, say which tool call produced it and quote the relevant part of the result. If a finding is your own judgment and no tool reported it, label it “judgment”. Do not change anything.
With WP Visibility connected, the audit tools are get-site-seo-health and audit-site for site settings (both need an administrator) and audit-post for one post (needs permission to edit that post). Each check in audit-site and audit-post returns pass, warn, or fail with a reason; get-site-seo-health sums the site checks up as good, fair, or needs attention. The checks and their thresholds are listed in Run the Site Audit and Read Its Checks.
The same approach works with any plugin’s tools. Rank Math’s MCP tools page, checked September 27, 2026, lists its own audit tools, such as rank-math/audit-site-seo and rank-math/analyze-post-content. What matters is the catalog the connection exposes, which you can see in the client’s tool list.
Classify the evidence behind each finding
Put every finding into one of four classes.
| Class | What it means | Example (illustrative) |
|---|---|---|
| Observed | A tool returned it and you can see the value | audit-post warns the description is 41 characters |
| Derived | A reasonable inference from observed values | Two pages share an identical title |
| Judgment | The assistant’s opinion, no tool reported it | “This page should target a different keyword” |
| Unverified claim | A factual statement nobody checked | “The site loads slowly on mobile” |
Keep the false positives in the list. An audit warning is a prompt to look, and several are correct as they stand:
- A canonical pointing to another host can be deliberate on a syndicated post or a headless site.
- A noindex warning is right on a thank-you page you never want in search.
- A 62-character title or a 140-word announcement can be the correct choice.
Google sets no limit on title length (title links) and says it has no preferred word count (helpful content), both checked September 27, 2026. Your SEO Plugin Score Is a Checklist covers this in detail. Mark such findings “no action, reason recorded” rather than deleting them, so the next audit does not raise them as new.
Map findings to the operations available
Next, check each finding against the tools the connection has. For WP Visibility 2.10.3, the audit checks map like this:
| Finding | Supported operation | Who decides |
|---|---|---|
| SEO title too long or short | update-post-seo (the SEO title field, not the post title) |
Reviewer approves the proposal |
| Description missing, short, or long | update-post-seo description |
Reviewer approves the proposal |
| Post set to noindex | update-post-seo noindex, only if the noindex is a mistake |
Site owner |
| Canonical on another host | update-post-seo canonical, only if unintended |
Site owner |
| No social image resolves | update-post-seo og_image_id, with an image already in the media library |
Reviewer; the plugin cannot upload media |
| Thin content | None for published posts; the plugin writes drafts only | Editor, by hand |
| More than one H1 | None for published posts; this is a content edit | Editor, by hand |
Search engines discouraged (blog_public) |
None; a WordPress Reading setting | Site owner, by hand |
| Plain permalinks | None; a WordPress setting that changes URLs | Site owner, with a redirect plan |
| No organization or person set, or no default social image | update-settings with organization_name (or person_user_id) or social_default_image_id |
Administrator approves the proposal |
| Sitemaps module off | None; the abilities cannot turn modules on | Administrator, by hand |
Anything the assistant raised as judgment or an unverified claim also lands in the last column: a person reviews it, or it goes to a different tool (a speed test, Search Console, a content brief).
In 2.10.3, the plugin’s abilities cannot edit a published post’s body, change post titles (update-draft can set a draft’s title), status, categories or tags, publish, touch users, plugins or themes, or upload media. That list comes from the plugin’s capability reference; if a finding needs one of those, the fix is outside this connection.
Check who can run each operation
A row marked “supported” still depends on the connected user. Post SEO needs edit rights on that post. Settings, bulk updates, and redirects need manage_options, which in a default install means an Administrator (Roles and Capabilities, checked September 27, 2026). Approving a proposal on the Review queue screen or over REST also needs manage_options.
The review path depends on configuration too. With the Assistant connection and Autopilot modules on and Assistant changes set to Hold for my review, the supported post SEO, settings, redirect, llms.txt, and AI crawler policy writes become proposals. Other operations, and other WordPress routes the credential can reach, are not held. An administrator’s Application Password can reach core WordPress REST routes directly (REST API authentication, checked September 27, 2026). Build a WordPress Assistant Permission Matrix shows how to test that for your own credential.
Approve the smallest useful job
From the rows marked Observed or Derived, with a supported operation and a reviewer, pick one job:
- One kind of change (descriptions only, not descriptions plus canonicals).
- A named list of targets (five post IDs, not “all short descriptions”).
- An expected result you can check on the live page.
Write it back to the assistant as a new request, separate from the audit, so the audit’s other suggestions do not ride along:
Propose new meta descriptions for posts 112, 118, 121, 130, and 134 only. Use only facts on each page. Do not change titles, canonicals, or indexing. Return each proposal ID.
When that job is reviewed and verified, take the next row. Write an SEO Job Brief That an Assistant Can Stop and Verify has a fuller template for the request.
Hand off the rest with enough detail
For every row with no supported operation, write a handoff line: the page, the finding, the evidence, and the person or tool that owns it. For example (illustrative): “garden.example/services/: two H1 elements in the content (audit-post, single_h1 warn). Owner: content editor.” A handoff with its evidence can be acted on later; a bare “fix H1s” cannot.
Checklist
- Every finding cites a tool result or is labeled judgment.
- False positives kept with a recorded reason.
- Each actionable finding mapped to an operation the connection exposes.
- Operation checked against the connected user’s role and the review setting.
- One small job approved, written as its own request.
- Everything else handed off with page, evidence, and owner.