Create a dedicated WordPress user for the assistant, open that user’s profile, add an Application Password named after the client, and copy it once. The assistant authenticates as that user, and each WP Visibility tool call that WordPress lets run is recorded in the activity log under that user and that password’s name.
Why a dedicated user
An Application Password is a real credential for the user it belongs to. It cannot sign in to the dashboard, but on REST API and XML-RPC requests it carries that user’s whole authority, not only the WP Visibility tools, and WordPress offers no way to scope one password more narrowly (Application Passwords integration guide, checked September 27, 2026). The user’s role is the boundary that matters. For the WP Visibility tools:
- Reading and updating the SEO fields of individual posts needs permission to edit those posts. An Editor covers every post; an Author covers its own (WordPress roles, checked September 27, 2026).
- Site settings, the site audit, bulk SEO updates, redirects, proposal management and the other site-wide tools need
manage_options, which among WordPress’s default roles means an Administrator.
Give the user the smaller role if the assistant’s job allows it. Any role’s password can also reach WordPress routes outside the review queue, and an Administrator’s reaches the most, so choose it deliberately and read what the queue does and does not cover.
Create the password
- Go to Users → Add User, create the user, and assign the role.
- Open that user’s profile (Users → All Users → the user) and scroll to Application Passwords.
- In New Application Password Name, enter a name that identifies the client, for example
Claude DesktoporClaude Code on the laptop, and click Add Application Password. - Copy the password shown. It appears once; WordPress says you will not be able to retrieve it. It is displayed in groups with spaces, and WordPress strips the spaces before checking it, so they may be kept or removed (integration guide, checked September 27, 2026).
Menu and button labels match the WordPress 7.0 source for the Users menu and the user screen, checked September 27, 2026.
The name matters more than it looks: the activity log records the user and this label on each WP Visibility tool call that runs, so one password per client tells you later which assistant did what.
HTTPS
By default, WordPress offers Application Passwords only on sites served over HTTPS, or on sites whose environment type is set to local (wp_is_application_passwords_supported(), checked September 27, 2026). Without HTTPS, the profile’s Application Passwords section says the feature requires HTTPS instead of showing the form. Put the site behind a certificate first. If the section is missing entirely, a plugin or custom code may have turned Application Passwords off, which WordPress allows through a filter (integration guide, checked September 27, 2026).
How the client uses it
Clients that can send an HTTP header use Basic authentication: the header is Authorization: Basic followed by the base64 encoding of username:application-password (WordPress REST API authentication, RFC 7617, checked September 27, 2026). Clients that cannot send headers run a small local bridge that holds the username and password for them. The connection docs for Claude Desktop, Claude Code and other clients show where each one takes it.
Keep any file that contains the password private. It is a credential for your site.
Revoke it
From the same profile section, Revoke ends that password. Requests using it fail from then on. Revoking does not undo work already done, and it does not touch the user’s other passwords; to cut an assistant off completely, revoke its password and, if the user exists only for that assistant, delete the user. WordPress then asks what to do with content the user owns, which includes any drafts the assistant created; choose Attribute all content to and pick another user unless you want that content deleted (WordPress 7.0 users screen source, checked September 27, 2026).