Skip to content
WP Visibility

Docs

Install WP Visibility, configure your SEO, and review the permissions before connecting an assistant. Start with Getting Started on a new installation.

On this page

Docs by task

One problem per page, with the answer first. The sections below this list are the longer reference; start with the doc that names your task.

Start here

Connect an assistant

  • Create the Application Password Your Assistant Signs In With: A remote assistant connects as a WordPress user, normally through an Application Password. Make a dedicated user, give it only the role the work needs, and name the password after the client.
  • Connect Claude Desktop: Claude Desktop connects through a small local bridge that holds the site address and the Application Password. Paste one block into its config file and restart it.
  • Connect Claude Code: Claude Code speaks to the plugin's endpoint directly over HTTP with an Authorization header. One command adds it; no bridge, no config file to edit.
  • Connect ChatGPT: What Works Today: ChatGPT's developer mode connects MCP servers with OAuth or no authentication. The plugin's endpoint needs an Application Password, so ChatGPT cannot reach it directly today.
  • Connect Cursor, Copilot or Another MCP Client: Two routes cover most clients: a URL plus an Authorization header when the client can send one, or the local bridge when it can only run a command. Here is how to tell which yours is.
  • The Assistant Gets 401, 403, 404 or Sees No Tools: Each row matches one symptom to one cause, such as the credential, the user's role, a module, or the transport. Find yours and fix that one.

Review and control

  • Approve or Reject a Proposal: A queued change waits in WP Visibility → Review queue with a before and after diff. Approve applies it, reject discards it, and both work in bulk and from the keyboard.
  • Undo a Change the Assistant Made: An applied proposal keeps a snapshot of what it replaced. Revert puts that snapshot back, overwriting later edits to the same values, and is not a site rollback.
  • Stop the Assistant Now: One button pauses every assistant tool call. Guard mode decides whether supported writes wait for you, the hourly write limit bounds how many get through, and revoking the password ends the connection.
  • See What the Assistant Did: Every completed WP Visibility ability call is logged with the user, the client's label, the target and the outcome, in a hash-chained table you can verify. Direct WordPress edits are outside it.
  • The Assistant Says It Changed Something and the Queue Is Empty: Either the call never reached the queue, or it is there and the filter hides it. Four checks, run in order, find which.

Switching

  • Migrate from Yoast SEO: Run the import while Yoast's data is still on the site: preview first, then import titles, descriptions, canonicals, indexing choices and category SEO. Redirects move separately.
  • Migrate from Rank Math: Preview, then import titles, descriptions, canonicals, social text, indexing choices and term SEO from Rank Math. Redirections come over from a Rank Math PRO CSV, on a separate page.
  • Migrate from SEOPress: Preview, then import titles, descriptions, canonicals, social text and indexing choices from SEOPress. Category and tag SEO is not imported from this source; plan to re-enter it.
  • Migrate from The SEO Framework: Preview, then import titles, descriptions, canonicals, social text, the social image and indexing choices from The SEO Framework. Category and tag SEO does not come across.
  • Migrate from All in One SEO: Preview, then import titles, descriptions, canonicals, social text and noindex choices from All in One SEO's own table. Images, category SEO and sitewide settings do not come across.
  • Move to Another SEO Plugin: Your data stays in the database when WP Visibility is deactivated. Copy the redirects and settings the next plugin cannot read, check the new sitemap address, then deactivate.

Everyday SEO

  • Set Title and Description Templates: Nine templates on the settings screen build the default titles and descriptions; any post, page or term can override its own on its edit screen, and an empty field means the template.
  • Keep a Page Out of Search: Set Noindex on one post from the editor sidebar, or on a whole post type or taxonomy from the Indexing section. The sitemap stops listing it; Google drops it once it recrawls the page.
  • Submit Your Sitemap: The sitemap index is at /sitemap.xml and is named in the robots.txt WordPress generates. Submit that one address in Search Console and Bing Webmaster Tools; the per-type files are linked from it.
  • Redirect a Changed URL: Turn the Redirects module on, add a rule with a source path, a target and a status, and check it. Slug changes get a 301 automatically, direct loops are refused, and chains are flagged.
  • Set the AI Crawler Policy and Serve llms.txt: Two settings, one for model training crawlers and one for AI search crawlers, write the matching robots.txt rules. A switch serves an llms.txt file with an editable body.
  • Set Your Site Identity to an Organization or a Person: Choose what the site represents in the Schema section, fill in the name, logo or user, and add your official profiles. Every page's structured data then names that publisher.
  • Set a Default Social Image: Pick one image in the Social section to use when a page has no image of its own. Each page chooses its own social image first, then its featured image, then the default.
  • Fix the Wrong Image in a Social Link Preview: Check which image the page's og:image tag names, fix it at the level that chose it, then make the network fetch the page again. If the tag is right, the network is probably showing a cached copy.
  • Add a Visible Breadcrumb Trail: Place the [wpvis_breadcrumbs] shortcode where the trail should appear. It prints plain, accessible markup you style in your theme; the breadcrumb structured data prints either way.
  • Turn On IndexNow and Check a Submission: Switch on the IndexNow module and publishing or updating an indexable post tells Bing and the other participating engines which URL changed. Google does not take part, and a submission is not indexing.
  • Verify Your Site with Search Console and Bing: Choose a URL-prefix property, copy only the code from the HTML tag method, paste it into the Site verification section, then click Verify. A domain property needs a DNS record instead.
  • Run the Site Audit and Read Its Checks: Run wp visibility audit for the site and post-audit for one post. Each check reports pass, warn or fail with a plain reason; the results are a checklist, not a ranking score.
  • Find Orphan Pages with the Link Graph: Turn on the Link Graph module, build the index once with wp visibility links rebuild, then list orphans, hubs and link suggestions. The report reads your published content only.
  • What WP Visibility Stores, and What Uninstall Removes: Settings and state live in a few options, SEO fields in at most one meta row per post and term, and four optional modules add tables. Deleting the plugin keeps all of it unless you opt in to removal.
  • WP-CLI Command Reference: Every wp visibility command in one place: what it does, its main arguments and flags, and an example. Run commands as an administrator with the global --user flag.

Start here

Getting Started

Requirements

WP Visibility requires WordPress 7.0 or newer and PHP 8.1 or newer. On an unsupported environment the plugin does not load its SEO modules and shows one admin notice naming the versions you are running; that notice, and how to clear it.

To check your versions, open Tools → Site Health in your WordPress admin and select the Info tab (Site Health screen, checked September 27, 2026). What the license covers is on the pricing page: License, updates, and renewal terms.

Install and activate

Download the plugin zip from your account, upload it under Plugins → Add Plugin (the WordPress 7.0 label, per the core source, checked September 27, 2026), and activate it. A WP Visibility menu appears with Settings; Redirects and Review queue join it as you enable their modules. The step by step, with what the “Get started” checklist does, is in Install WP Visibility and Enter the License Key.

Enter your license key

The license unlocks plugin updates and support. Features are never locked: an expired or missing key only means you stop receiving updates and support. Paste the key into the License section of the settings screen and click Activate; the badge reads Active, Invalid or Could not verify, and the install doc says what each means. One key covers every site you manage: Use the Same License on Another Site.

Preview an import with a dry run

The Import module is on by default and reads Yoast SEO, Rank Math, SEOPress, The SEO Framework, or All in One SEO data in place; it never modifies or deletes the source plugin’s rows. Each entry point has a preview that writes nothing: Preview changes in the Import section of the settings screen, wp visibility import yoast --dry-run (also rank-math, seopress, tsf, or aioseo), or POST /wp-json/wpvis/v1/import/run with its default dry_run: true. The preview counts the posts whose mapped values would change (the settings screen stops after checking 5,000 posts and says so) and shows the title and description before and after for the first ten, with template variables already translated.

Field by field coverage, the robots rules, and what each source keeps that the import does not read are in the switching docs: Migrate from Yoast SEO, Migrate from Rank Math, Migrate from SEOPress, Migrate from The SEO Framework, and Migrate from All in One SEO.

Run the import

Click Import now, or run the same command without --dry-run. Posts are processed in batches of 200; the first live batch also applies the supported settings (title separator, homepage title, homepage meta description; none come from All in One SEO) and, from Yoast SEO and Rank Math, the term data. The preview covers neither. Posts whose mapped values already match are skipped, and repeating an import overwrites edits made in WP Visibility since, in the fields it maps. Take a database backup first: the import cannot reverse itself.

The REST route needs manage_options and does not use the proposal review queue. Leaving WP Visibility is its own page: Move to Another SEO Plugin.

Titles and Meta

WP Visibility builds every document title and meta description from site-wide templates, and lets any post or page override the result from the editor. Configure the templates once under WP Visibility → Settings; override individual posts in the editor sidebar.

How precedence works

For each request the plugin resolves the title in a fixed order. A per-post value entered in the editor always wins. On the homepage, if no per-post value exists, the “Homepage title” field in the General section applies next. Otherwise the template for that page type (post, archive, author, search, 404) renders the title.

Meta descriptions follow the same order: per-post value first, then the “Homepage meta description” field on the homepage, then the matching description template. Search, 404, date, author, and post type archive pages have no description template, so they output no description tag unless code supplies one through the wpvis_description filter.

Per-post values are templates too. Type plain text, or use variables such as {title} and {sep}; both render through the same engine.

Set the title separator

Title separator in the General section replaces {sep} in every template. The default is an en dash; the presets, the custom character, and how leftover separators are tidied when a variable renders empty are in Set Title and Description Templates.

Site-wide templates

The Titles & descriptions section holds six title templates and three description templates, one per page type, and page 2 onward gets the page number appended for you. There is no per post type template; the shared post template can tell types apart with {post_type_singular}. The nine templates and their defaults are listed in the templates table.

Template variables

Variables are lowercase names in curly braces, such as {title}, {site}, {sep}, {excerpt} and {custom_field:KEY}; an unknown name renders as nothing. Every variable, with what it resolves to.

A concrete example

{title} {sep} {site} on a site named Garden Notes with / as the separator renders How to Prune Tomatoes / Garden Notes. More examples, including a date, a post type label and a custom field.

Per-post overrides in the editor

Open the WP Visibility sidebar in the block editor. Search title and Search description in the Search appearance panel override the templates for that post, with a preview and advisory character meters; an empty field falls back to the template; with the default description template, {excerpt}, that is the post excerpt or the start of the content. The classic editor metabox and the term edit form carry the same fields. Override one post.

Schema and Sitemaps

What structured data is generated

When the Schema module is on, WP Visibility prints one JSON-LD @graph in a single <script type="application/ld+json"> tag on each page. The graph contains a publisher node (Organization or Person), a WebSite node, a WebPage node, and a BreadcrumbList. Blog posts also get an Article node with the post author attached as a Person.

Nothing is printed on 404 or search results pages. Author archives get a ProfilePage node instead of a plain WebPage. The built-in schema generators do not add FAQPage, HowTo, or SearchAction markup.

Identify your organization or person

Open WP Visibility → Settings and find the Schema section. Set “This site represents” to “An organization” for a company site or “A person” for a personal site. That choice sets the publisher entity described in your structured data.

For an organization, fill in “Organization name” (leave it empty to use the site title) and pick an “Organization logo”. For a person, enter the WordPress user ID in “Person (user ID)”. Add your official account links under “Social profile URLs”; the plugin includes those links as sameAs properties. It does not verify ownership of those accounts.

The aggregate schema endpoint

“Aggregate schema endpoint”, on by default, publishes a schema document at /wp-json/wpvis/v1/schema-map. The public endpoint gives a tool a single URL to request the site’s entity information. The response is cached for 12 hours, and a “View schema graph” link appears in the Schema section while the toggle is on. Publishing the endpoint does not mean an assistant will discover or use it.

Validate your markup

Load a page, view its source, and find the application/ld+json script tag. Use Google’s Rich Results Test to check supported Google result types and the Schema Markup Validator to inspect the broader schema markup. Recheck after changing Schema settings. Google explains the distinction in its testing tool guide, checked September 13, 2026.

XML sitemaps

With the Sitemaps module on, the index lives at /sitemap.xml and links one file for each page of URLs in each included post type and taxonomy. Documents are generated on request and cached for up to a week; nothing is written to disk. Published public content is listed except attachments, password-protected posts and anything set to noindex, plus term archives with at least one post; featured images and modified dates are included. The Sitemaps section sets URLs per sitemap page, Include featured images and Exclude post types from the sitemap. What is listed, how to exclude a type, and how to refresh a stale file are in Submit Your Sitemap.

Submit your sitemap to search engines

WP Visibility adds a Sitemap: line to the robots.txt WordPress generates, except on a site set to discourage search engines. Submit sitemap.xml once in Google Search Console’s Sitemaps report and in Bing Webmaster Tools; Google documents submitting a single sitemap index file in place of the files it lists (Google, Bing, checked September 27, 2026). Paste meta tag verification codes into the Google Search Console and Bing Webmaster Tools fields of the Site verification section. The optional IndexNow module sends changed URLs to the shared IndexNow endpoint; the participating engines, including Bing and Yandex, share each submission, and Google is not listed among them (IndexNow FAQ, checked September 27, 2026). Steps for both services: Submit it.

The “Breadcrumbs” toggle in the Modules section is on by default. Place [wpvis_breadcrumbs] where the trail should render; pass separator="/" to override the default, which is your “Title separator” setting. In the block editor, add it through a Shortcode block. The plugin adds no breadcrumb block of its own. WordPress instructions checked September 13, 2026.

The shortcode outputs semantic nav > ol > li markup with the class wpvis-breadcrumbs and ships no CSS or JavaScript, so style the trail in your theme. The matching BreadcrumbList JSON-LD comes from the Schema module whether or not you render a visible trail.

Redirects

The Redirects module stores redirect rules in their own database table and answers matching requests before WordPress renders anything else. Each rule records a hit count and last hit time, so you can see which redirects still earn traffic. Turn the module on under WP Visibility → Settings with the “Redirects” toggle in the “Modules” section; once it is on, the manager appears as its own page in the WP Visibility menu.

Add, edit, and delete rules

Rules live on their own page, WP Visibility → Redirects: a searchable table with hit counts, an Add a redirect form, inline edit, delete, and a CSV import with a preview. The same rules are available over REST at wpvis/v1/redirects (list, create, partial update, delete) for users with manage_options; those direct writes do not use the proposal review queue. With the Assistant connection module on, an assistant manages the table through the “List redirects”, “Create a redirect” and “Delete a redirect” abilities. The walkthrough is Redirect a Changed URL.

Source and target rules

The source is a path on your site starting with /; a full URL on your own domain is reduced to its path, the query string is dropped, and a trailing slash is ignored. The target is a site-relative path or an absolute http(s) URL, and the visitor’s query string passes through to it. Regular expression rules match anywhere in the path unless anchored, support $1 backreferences, and are evaluated up to 200 per request. Details and the refusal messages: Create a redirect.

Redirect types

Six status codes: 301 and 308 permanent, 302 and 307 temporary (RFC 9110, checked September 27, 2026), and 410 and 451, which answer in place with no target. Status codes says when to use each.

Loop and chain protection

A rule whose target leads straight back to its source is refused. A rule whose target is another rule’s source is saved with a warning, because the visitor would be redirected twice. When a published post’s slug changes, a 301 from the old path is created, rules that pointed at the old path are repointed, and any rule that would redirect away from the live URL is deleted. Loops and chains.

Import redirects from another plugin

The Redirects page imports a CSV, preview first, in three layouts: the plugin’s own source,target,status,is_regex, a Redirection plugin export, and a Rank Math redirections CSV. Up to 5,000 rows per run; unsupported match types and duplicates are skipped with a message. The SEO importer never moves redirects, and there is no CSV export. Column details: Import rules from another plugin.

Worked example: retire a page

To retire /spring-sale-2025 in favor of /promotions, add a 301 from the old path to the new one while the old page is still published, confirm the old address lands on the new one, then trash the old page. If nothing replaces it, use status 410 with no target. How to confirm it from the command line: Check it.

Social Cards and Open Graph

The Social module adds Open Graph and Twitter/X card tags with your preferred title, description, and image for shared links. The service displaying a link controls its final preview. The module is on by default; the “Social” toggle in the “Modules” section of WP Visibility → Settings turns it off. The Open Graph tag format is described in the Open Graph protocol, checked September 13, 2026.

Sitewide settings

With the module on, a “Social” section appears on the same settings screen. “Output Open Graph tags” and “Output Twitter/X card tags” control the two tag families independently. “Twitter/X card type” chooses between “Summary” and “Summary with large image”, printed in twitter:card as summary or summary_large_image; the default is the large image card.

“X (Twitter) site handle” attributes cards to your account, for example @yoursite. The plugin normalizes the leading @ for you. “Facebook app ID” accepts digits only and is omitted from output when empty. “Default social image” sets the fallback image, “Shown when a page has no image of its own and gets shared on social media.”

What the plugin outputs

On every page except 404s, the Open Graph generator writes og:type (article for single posts and pages other than a static front page, and for the posts page; website elsewhere), og:site_name, og:title, og:description, og:url (the canonical URL), and og:locale. Single posts and pages, other than a static front page, also get article:published_time and article:modified_time. When an image resolves, the plugin adds og:image plus its width, height, and alt text.

The Twitter/X generator emits twitter:card and, when a handle is set, twitter:site. It also emits twitter:title and twitter:description when you set the corresponding per-post overrides.

Per-post overrides in the editor

Open the WP Visibility sidebar in the block editor. The Social sharing panel holds Social title and Social description, which fall back to the search title and description when empty, and a Social image picker. X (Twitter) overrides opens an X title and X description, which fall back to the social values. The classic editor metabox and the term edit form do not carry these social fields. Override it for one post.

How the social image is chosen

The plugin resolves one image per page and reuses it for the og:image tag and for schema; no separate twitter:image tag is printed. The order is per-post social image first, then the post’s featured image, then the “Default social image” from settings. If none of those exist, no image tags are output, and the preview is up to the service showing the link.

The full-size version of the chosen image is used, with its width, height and the attachment’s alt text included when available.

Image size guidance

Choose an image that remains readable as a small preview. Keep essential text and the subject away from the edges, then check a shared link on the services your readers use. Cropping and supported image formats depend on the service.

Set “Default social image” to provide a fallback for the homepage, archives, and posts without an image of their own. Check the resulting image URL in the page source and confirm that it loads without logging in.

Filters for developers

Three filters adjust output in code. wpvis_og_tags and wpvis_twitter_tags receive the property map before rendering; wpvis_social_image receives the resolved image array (url, width, height, alt) or null.

add_filter( 'wpvis_og_tags', function ( array $props, $state ) {
    $props['og:image:secure_url'] = $props['og:image'] ?? '';
    return $props;
}, 10, 2 );

Returning an empty string for a property removes that tag from output.

AI Crawlers and llms.txt

The AI Visibility module publishes crawler preferences in robots.txt, an optional llms.txt file, and an optional Content-Signal line. The module is on by default; the “AI Visibility” toggle in the “Modules” section of WP Visibility → Settings turns it off. Its settings live in the “AI Visibility” section of the same screen.

Set the crawler policy

The AI Visibility section has two switches, Model training crawlers and AI search crawlers, each Allow or Block, plus Per-bot overrides for single crawlers. Blocking training asks the listed crawlers to keep your content out of model training; Google says Google-Extended does not affect inclusion or ranking in Google Search, and OpenAI treats GPTBot and its search crawler as independent settings. Blocking AI search can keep the site out of those engines’ answers: OpenAI says a site that blocks OAI-SearchBot is not shown in ChatGPT search answers, though it can still appear as a navigational link (Google, OpenAI, checked September 27, 2026). These are published instructions, and each operator decides whether to honor them. The crawlers in each group are named in Set the AI Crawler Policy and Serve llms.txt.

What the policy writes to robots.txt

Blocked crawlers are appended to the virtual robots.txt as one group: a User-agent: line per crawler over a single Disallow: /. The Content-Signals policy field adds an optional Content-Signal: line. A physical robots.txt file in the site root is served by the web server instead (the standard WordPress rewrite rules skip WordPress for any existing file, checked September 27, 2026), and on a site set to discourage search engines the plugin adds nothing to robots.txt. The exact output.

Serve an llms.txt file

Serve an llms.txt file answers /llms.txt with the site name, tagline, your optional body and a list of up to 50 recently modified posts and pages, noindexed and password-protected content excluded. It is off by default and labeled experimental: publishing the file does not establish that any assistant reads it. Serve an llms.txt file shows the document.

Edit the llms.txt body

Once the switch is on, the llms.txt body field takes your own Markdown, inserted after the site name and tagline and before the page list. Developers can rewrite the whole document with the wpvis_llms_txt filter. Edit the llms.txt body.

Run the site audit

The audit engine performs read-only checks at the site and post level. Site checks cover search engine visibility, permalink structure, the site’s represented entity, the default social image, and the sitemaps module, plus counts of published posts, missing descriptions, noindexed posts, and redirects.

Per-post checks measure the SEO title against a 30 to 60 character band and the meta description against a 70 to 160 character band, then flag noindex, canonicals pointing to a different host, thin content under 150 words, a missing social image, and more than one H1 in the content.

Results appear where you request them. Run wp visibility audit or wp visibility post-audit <id> in WP-CLI, or call the REST endpoints GET /wp-json/wpvis/v1/audit/site and GET /wp-json/wpvis/v1/audit/post/{id}. When the Assistant connection module is on, your assistant reaches the same engine through the audit-site, audit-post, and get-site-seo-health abilities. Autopilot’s optional “Weekly audit” queues description proposals for eligible posts with missing descriptions. That audit does not apply the proposed descriptions.

Connect Your AI Assistant

WP Visibility includes an MCP endpoint for assistants that support its transport and authentication. Start with the connection instructions generated by your installed plugin. Run this in your site’s WP-CLI environment, replacing seo-agent with the dedicated WordPress user’s login:

wp visibility mcp-config --user=seo-agent

The command prints a client configuration and, on its last line, the direct endpoint URL for that site. In version 2.10.3 the configuration’s WP_API_URL is the site’s home address; replace it with the endpoint, https://your-site.com/wp-json/wp-visibility/mcp. The command does not create a user or password. Follow the setup below before using the generated configuration, and check your client’s support for the connection method it uses.

Turn on the Assistant connection module

The Agent module is off by default. Go to WP Visibility → Settings, open the “Modules” section, and enable “Assistant connection”. Enable “Autopilot”, then confirm that “Assistant changes” is set to “Hold for my review” (the propose mode). All three are needed to queue the supported SEO write abilities. Other write routes have separate authority.

The built-in MCP endpoint

The endpoint lives at https://your-site.com/wp-json/wp-visibility/mcp. It accepts JSON-RPC over HTTP POST with ordinary WordPress authentication, which for a remote client means an Application Password sent as a Basic authorization header, over HTTPS (WordPress Advanced Administration Handbook, checked September 27, 2026). The built-in endpoint has no sessions and no server-sent events; if the separate MCP Adapter plugin is active, it serves this route instead. Clients that can send a header connect directly; clients that can only run a command use a local bridge. The per-client docs: Claude Desktop, Claude Code, ChatGPT, any other MCP client.

Create an application password

Create a dedicated WordPress user with the role the work needs, then add an Application Password on that user’s profile, named after the client. The password authenticates API requests as that user (WordPress Advanced Administration Handbook, checked September 27, 2026), so it carries the user’s whole authority, not only the plugin’s tools, and its label is what the activity log attributes each call to. The full steps, the HTTPS requirement and revocation are in Create the Application Password Your Assistant Signs In With.

Configure your client

Run wp visibility mcp-config --user=seo-agent on the site to print the bridge configuration with the site’s home address as WP_API_URL, the username and a placeholder for the password; change WP_API_URL to https://your-site.com/wp-json/wp-visibility/mcp before using it. Or connect directly with the endpoint URL and a Basic authorization header where the client supports one. Test with a read, then request one supported change and confirm it appears in the Review queue before doing a batch. Per-client instructions are linked above; when it does not connect, this table matches the status code to the cause.

What the assistant can do

The tool catalog depends on the installed version and enabled abilities; permission checks determine which operations the connecting user can run. Reads include post and site audits, SEO fields, settings, redirects, sitemap status, llms.txt, crawler policy, the activity log, and reports from the AI Traffic Lens and internal link modules. Writes include post SEO fields, bulk SEO updates, redirects, settings, llms.txt, crawler policy, imports, and draft content. Draft creation and editing are separate from the SEO proposal workflow.

The “Approve an Autopilot proposal” ability ships disabled by default. That disables this ability only: an administrator credential can still approve proposals through other WordPress routes. Ability calls use capability checks and the plugin’s activity logging. Restrict the WordPress user’s authority and the enabled abilities to the work you intend to allow.

Writes go through your review queue

Turn on both Agent and Autopilot, then choose “Hold for my review” (propose) under “Assistant changes”. This queues the supported abilities for post SEO fields, bulk SEO edits, settings, creating or deleting redirects, llms.txt, and crawler policy. A queued proposal shows the current and proposed fields under WP Visibility → Review queue. These calls can include an optional reason, displayed as the assistant’s rationale.

This review step applies to those ability calls. Imports, draft tools, and direct WordPress write routes are outside that boundary. An administrator Application Password retains its authority to use separate approval, settings, and core content routes, even when the approval ability is disabled. The queue does not create a universal human-only approval or publishing boundary.

A queued response includes a proposal identifier; it does not mean the SEO change has been applied. “Apply immediately” lets the supported abilities write without that review step. Check the selected mode before connecting a client or starting a batch. For help with a particular client’s setup, email support@wpvisibility.com.

The Review Queue and Guardrails

With Agent and Autopilot enabled and “Hold for my review” selected, supported assistant SEO changes become proposals with a before and after diff. Review the proposed fields before applying them. This protects the supported ability workflow; it does not force every WordPress write into the queue or restrict an administrator credential to proposals.

Where the queue lives

Turn on the “Autopilot” toggle in the Modules section of the settings screen. A “Review queue” entry then appears in the admin menu under “WP Visibility”, with a count bubble when proposals are waiting. The page has a Proposals tab and an Activity log tab under a status bar with the agent access state, a Pause agent button, the guard mode, the write-limit usage and the last recorded activity.

Reading a proposal

Each card names its target, source, status and any supplied note, then a diff table with Field, Before and After. Treat the source and rationale as context supplied with the proposal, not proof of who authored it. The full walk through the card, approval, rejection, stale proposals and the keyboard shortcuts is Approve or Reject a Proposal.

Approve, reject, and bulk actions

Approve checks the proposal against the current state and applies it; Reject marks it rejected without applying anything. Bulk actions run each proposal through the same server-side checks. After an approval the card keeps a Revert this change action, which puts back the snapshot saved just before the change was applied (for a post, its whole SEO record). It does not check for later edits, so anything edited since in that snapshot is overwritten: Undo a Change the Assistant Made.

Stale proposals

At proposal time the plugin stores a hash of the target state the proposal covers and checks it again on approval. If the state differs, approval stops and the proposal is marked stale; Refresh diff sets a new baseline for you to read before approving. Bulk approval skips and reports stale rows. Queue housekeeping removes older resolved proposals; the queue is not a permanent backup.

Guard mode, the kill switch, and the write budget

Assistant changes has two values: Hold for my review (propose), which queues the supported write abilities, and Apply immediately, which does not. Pause all agent access stops ability execution for every connected client; it does not revoke the credential. Assistant write limit (per hour) caps write requests per user and client label. All four controls, and the order to use them in when something goes wrong, are in Stop the Assistant Now.

The activity log

Ability calls are recorded in a hash-chained table with the time, user, client label, ability, target, a redacted input excerpt, outcome and duration. Verification checks the chain; it does not prove the history is complete, and direct WordPress writes are outside the log. Reading it, verifying it and its 90-day, 10,000-row retention are in See What the Assistant Did.

Troubleshooting

“The review queue could not be loaded.” means the page’s own REST request to /wp-json/wpvis/v1/ failed: confirm you are logged in with the required permissions, then look for a server error or a security plugin blocking that path, and click Try again. If expected proposals do not appear, this doc runs the four checks in order. For anything else, email support@wpvisibility.com with your WordPress and plugin versions.