The WordPress plugins

WordPresto publishes two first-party plugins for WordPress sites. They do completely different jobs and neither depends on the other:

• WordPresto Connector — the MCP plugin. It is what makes WordPress a full two-way destination: importing a live page as a real editable document, and publishing it back unchanged.
• WordPresto Tag Injector — the Site Signals plugin. It puts the Site Signals tag on your pages so the project gets first-party behavioural data.

You can connect a WordPress site without either of them, and the standard REST connection still publishes drafts and live posts. This guide covers what each plugin adds, and what you give up without it.

WordPresto Connector (the MCP plugin)

The Connector adds one authenticated MCP server to your site at /wp-json/wordpresto/v1/mcp. It is built on WordPress’s own official MCP adapter and the Abilities API in core, so the protocol, transport and authentication are WordPress’s, not homegrown plumbing. It needs WordPress 6.9 or newer (that is where the Abilities API lands) and PHP 7.4 or newer.

Why it exists

WordPress’s REST API does not always hand back the raw stored content of a page. On plenty of real installs it returns rendered HTML instead — a server strips the authorization header, or the connected user does not have the permission REST wants for edit-context reads. When that happens without the Connector, an import degrades to text only: still useful for reading and rewriting, but it has lost the block structure, so it can publish to Sanity or Astro and cannot publish back to WordPress. WordPresto says so on the document rather than pretending the import was complete.

The Connector is the second way in. It reads the raw stored post_content — Gutenberg block markup intact — over an authenticated call, so the round trip stays lossless.

What it unlocks

• A capability manifest — the site reports what it actually is: WordPress and connector versions, whether writes are enabled, which integrations are really active (Elementor, ACF, Yoast, Rank Math, WPBakery — detected live, not assumed), and every REST-exposed post type with the connected user’s real per-type permissions. This is what the WordPress card shows instead of a generic “connected” badge.
• Block-native import — the raw stored content of a post or page, so the document you edit in the Canvas is the real thing and publishes back in place.
• Content listing and incremental sync — paginated listing of a post type with honest totals, and a modified-since cutoff so a refresh does not re-read everything.
• Create and update content — created posts are marked as WordPresto-managed and default to draft; an update writes back to the same post id rather than making a second one.
• Yoast SEO fields — only when Yoast is active. The Connector writes the SEO title, meta description and focus keyphrase through Yoast’s own path, which replaces WordPresto’s older guess at REST meta keys (a guess Yoast does not honour for writes). Rank Math is not part of the Connector — Rank Math sites keep the REST mapping described in “Publishing to WordPress”.
• ACF fields — only when Advanced Custom Fields is active: the real field groups and their definitions, plus reading and updating field values on a post.

Integration abilities are registered only when their plugin is actually active on the site, so the Connector never advertises something that would fail. Elementor and WPBakery are currently detected but not editable — the manifest reports no abilities available for them, so nothing upstream assumes an editing surface that does not exist yet.

Installing it

1. Download it: wordpresto-connector.zip
2. In WordPress, go to Plugins → Add New → Upload Plugin, choose that file, install and activate it. Nothing else to set up on the site — it is an ordinary plugin install.
3. Create an Application Password for the WordPress account you want WordPresto to act as (Users → Profile → Application Passwords). This is the same credential the standard connection uses — the Connector does not add a second one.
4. In WordPresto, open Project Settings → Destinations → WordPress, make sure the site URL and Application Password are saved, then press Detect connector.

The plugin needs no configuration screen of its own: once it is active, everything is driven from WordPresto over the Application Password you just issued.

Detection is an explicit action

WordPresto never probes your site on page load. Detection runs when you press the button, and the result is stored, so the status you see is the last real answer rather than a live guess. Each outcome names itself:

• connected — you get the connector version, and a line listing the integrations the site reports active. If the site has writes switched off, it says so.
• not installed — the plugin’s REST namespace is not registered; the project keeps the standard REST integration and is reported as exactly that.
• Application Password rejected — the credential is wrong or revoked; regenerate it.
• Application Password never arrived — WordPress saw the request as logged out even though the credential was sent, which means the server is stripping the authorization header (common on nginx-only or FastCGI vhosts). Different problem, different fix, so it is reported differently.
• unreachable — the site could not be read at all.
• manifest failed / could not be validated — the Connector answered but could not report what it can do; update the plugin and detect again.

Re-detect after you install or update anything relevant on the site — activating Yoast, for example, only becomes visible to WordPresto on the next detection. If a site has never been checked at all, the first import checks once and stores the answer rather than silently skipping the Connector.

Permissions and safety

• The transport requires an account that can edit posts, and every ability re-checks the specific permission it needs on top of that. Publishing needs the real publish capability. The Connector never grants more than the WordPress user already has.
• Site owners can switch off all Connector writes without deactivating the plugin, using a constant or a filter. Reads keep working, and the manifest reports writes as disabled honestly — WordPresto shows that on the card rather than failing at publish time.
• It collects no visitor data, runs no background tasks and makes no outbound calls of its own. It only answers authenticated requests. Revoking the Application Password ends its access immediately.

Without it

The standard REST connection still publishes drafts and live posts, still maps Yoast or Rank Math where the site exposes those fields, and still runs the post-publish verification loop. What you lose is the guaranteed lossless block round trip on sites where REST will not return raw content, Yoast writes on sites that do not expose them over REST, and ACF entirely.

WordPresto Tag Injector (the Site Signals plugin)

Site Signals is WordPresto’s own first-party analytics, and it works by one script tag on your pages. The Tag Injector plugin exists to put that tag there and nothing else. It needs WordPress 5.8 or newer and PHP 7.4 or newer.

You do not have to use it — the Site Signals card gives you the snippet, and pasting it into your theme or tag manager works exactly the same. The plugin is for sites where editing the head is awkward, or where you want the tag to survive a theme change.

Installing it

1. Download it: wordpresto-tag-injector.zip, then install and activate it under Plugins → Add New → Upload Plugin.
2. In WordPresto, open the Site Signals card in Integrations. It reads the project’s own site URL and generates the site’s unique id and install snippet — this card is the only place a site id is ever created.
3. On the site, go to Settings → WordPresto, paste in the Site ID (the data-site-id value from that snippet) and save.
4. Back in WordPresto, press Check now on the card. It reports honestly whether events are arriving, when the last one was, and how many arrived in the past hour — no green tick until a real event lands.

What it does and does not do

• It prints nothing at all until a Site ID is saved. There is no anonymous or default fallback.
• It only touches front-end pages, never wp-admin.
• It collects no data itself. The plugin adds one <script> tag; the hosted script it points at does the measuring, in the visitor’s browser, like any other analytics tag. The plugin makes no outbound calls and stores nothing but the Site ID, which it deletes when you uninstall it.
• AI-crawler tracking is separate. AI crawlers run no JavaScript, so they are invisible to any tag — including this one. Those hits are captured server-side, using the site id and write key from the same Site Signals card, wired into the site’s host or edge layer. The Tag Injector does not do that part.

Which one do I need?

• Publishing approved content to WordPress, and importing live pages to edit → Connector (download).
• First-party behavioural data (sessions, engagement, AI-assistant referrals) → Tag Injector (download), or paste the snippet yourself.
• Both, on the same site, is normal. They share no settings and neither is aware of the other.