Install — three steps
SiteHelm registers one REST route and one admin menu. There is no options screen, no dashboard widget to configure, and no cron job.
You will need WordPress 6.6 or newer, PHP 8.1 or newer, and HTTPS. Elementor, ACF, Meta Box, an SEO plugin and WooCommerce are all optional — SiteHelm reports which of them it found rather than requiring any.
From the releases page —
the file is named sitehelm-*.zip.
Choose the zip, Install Now, then Activate.
The endpoint, the credential, and a ready-to-paste config for your client are all on that one screen.
If PHP or WordPress is below the floor, the plugin refuses to boot and shows an admin notice rather than fataling. That is deliberate: a half-loaded plugin with a live REST route is worse than no plugin.
Then symlink or copy the directory into wp-content/plugins/.
SiteHelm speaks JSON-RPC 2.0 over a single authenticated REST route, and authenticates with a WordPress Application Password over HTTP Basic. The route requires a logged-in user, and every operation re-checks that user’s real capabilities.
The agent acts as that account and no other. Give it an editor if you want an editor’s reach; revoke the password on the Connect screen and the agent is out immediately.
Always use HTTPS. An Application Password sent over plain HTTP is a credential sent in the clear.
Clients that only speak stdio need an HTTP-to-stdio bridge for now. A first-party bridge is the top item on the roadmap.
Confirms the gateway is reachable and reports who is authenticated.
Which optional integrations are active, inactive, or blocked on a version.
WordPress and PHP versions, active theme, registered post types and taxonomies.
Two of those cost one call each and tell an agent what is actually
available before it plans anything. Every dispatcher called with no
operation answers with its own catalogue, so the agent
discovers the rest at runtime.
On many servers the Authorization header never reaches
WordPress. The Health tab checks this specifically and prints the
.htaccess fix when it finds it — the same
verdict also appears under Tools → Site Health.
The account is real but lacks the capability for that object. Use an account with the role the work needs.
The plugin an operation depends on is not active. Health names what each blocked module is waiting on.
A refusal here is the system working. It carries the reason and, where one exists, the remedy — and never a stack trace, a filesystem path, or anything else worth handing to a stranger.
The full safety model lists all eleven refusals and what each one means.
SiteHelm