Let AI work on your WordPress site. Keep the undo button.

Respira is the controlled connection between an AI assistant—such as Claude or ChatGPT—and your WordPress site. It gives the assistant tools to inspect and edit the site, while keeping the important decisions with you: every write starts with a snapshot, destructive actions wait for approval, and every action leaves a receipt.

no card required. your 7-day trial starts when you connect the first WordPress site.

Layered paper plans preserve an original beneath a proposed change, connected by one emerald thread that pauses before the final step.

Six safeguards between AI and your live WordPress site

These are not promises written into an AI prompt. They run inside the Respira plugin on your WordPress server, where they still apply if the assistant misunderstands a request.

Restore any AI edit without rebuilding the page

Respira stores the previous state before it changes a page, so going back is a restore rather than a rebuild. You can diff two snapshots to see exactly what moved, line by line, before deciding whether to keep it.

get_snapshot · diff_snapshots · restore_snapshot

Destructive WordPress changes wait for your approval

Updating WordPress core, removing a user, deleting a plugin: each one halts and waits for you to approve it explicitly. The assistant cannot talk its way past this. The gate is in the plugin on your server, not in the model.

two-step approval, server side

Read-only mode lets AI inspect without editing

Observe lets an assistant look at everything and change nothing. The read-only flag is enforced on each tool rather than described in a prompt, so a mislabelled tool cannot quietly escape it.

read_only enforced per tool

Edit a duplicate before publishing to the live page

For risky work the assistant duplicates the page, edits the duplicate, and shows it to you. The live page is untouched until you approve the swap. Your visitors never see a draft in progress.

duplicate · approve · reject

Timed-out writes never publish twice

If a request times out, a read can safely be retried and a write cannot. Respira retries a write only when the server states it is replay-safe. The alternative is publishing the same page twice and calling it success.

replay-safe retry only

An independent log records every AI action

What ran, when, against which site, and whether it worked. Not a summary the assistant wrote about itself: the log the plugin recorded independently.

list_activity · audit receipts

Check the vulnerability—and what it may have left behind

Most WordPress security advice stops at “keep everything updated.” That closes a known gap, but it does not remove an unfamiliar administrator, application password, plugin, or PHP file that may already have appeared. Respira checks both sides: whether WordPress is current, and whether the published signs of compromise are present.

Two parallel paper paths: one closes a gap ahead while the other loops back to inspect an earlier layer.

WordPress core advisories currently checked

  • WordPress August 2026 core security release (XSS2Shell login-screen XSS) CVE-2026-64638
  • WordPress wp2shell pre-authentication RCE chain CVE-2026-60137 · CVE-2026-63030
See what the scan checks, and what it misses

From WordPress scan to approved fix, with a receipt

Ask your AI assistant to check a connected site and Respira follows the same supervised path every time.

  1. 01

    Scan

    Respira reads the WordPress version, verifies core file checksums against the official ones, and checks the published indicators for known advisories.

  2. 02

    Know

    You get a plain answer per site: below the patch for its branch, patched, needs investigation, or not enough evidence to say. Never a score with no reasoning attached.

  3. 03

    Approve

    The fix arrives as a prompt you can read before it runs. Every core or plugin update inside it still asks you separately.

  4. 04

    Receipt

    Afterwards: the target URL, the versions, the checksums, what was covered, what was not, and the site fingerprint. Evidence you can hand to a client.

What Respira cannot verify from inside WordPress

Respira can inspect WordPress itself. It cannot inspect infrastructure and accounts that live outside WordPress, so those boundaries stay visible in every result.

  • A patched version does not prove a site was never compromised. It proves it cannot be taken the same way tomorrow.
  • Host cron jobs and web server access logs sit outside WordPress. Respira cannot see them, and says so instead of implying a clean bill of health.
  • Rotating passwords, salts and third-party API secrets happens outside Respira and has to be verified there.
  • Whether an unfamiliar administrator account is legitimate is a question only you can answer. Respira will surface it and refuse to guess.

Respira reports coverage as partial when a scan is truncated, and marks anything it did not measure as not measured rather than clean. An unmeasured zero and a real zero are different facts, and mixing them is how a dashboard ends up reassuring somebody who is exposed.

The same safety controls across 17 WordPress page builders

Every builder stores its content differently, and a write that is safe in one is a corrupted layout in another. The snapshot, approval and receipt guarantees are not per-builder features bolted on; they sit underneath all of them, which is why a rollback works the same whether the page was built in Elementor, Bricks, Divi or blocks.