@speed.press/kit

Turn any WordPress site into a fast static site — in one command.

npx @speed.press/kit mirror https://your-wordpress-site.com

No install, no config. You get a deployable Astro project in ./mirror-site — your pages captured with their styling, images and CSS self-hosted, and a Dockerfile. WordPress stays your CMS.

cd mirror-site && npm install && npm run dev     # → http://localhost:4321

Stop the dev server when you have seen enough, then build:

npm run build                                    # → static output in dist/

Requires Node 22.12+ (generated projects build on Astro 7 / Vite 8).

Defaults worth knowing

The one-liner is tuned for a typical site. Three limits, all flags:

| Default | Why it might not suit you | Flag | |---|---|---| | 500 pages, 2,000 assets | A bigger site is captured up to the cap and the rest is left behind | --max-pages, --max-assets — or run xch inventory <url> first and convert in batches | | Video and audio stream from the original host | Lets you cut over without moving gigabytes; but the old host stays load-bearing | --media localize before you retire the source | | Renders with Chromium when Playwright is installed, plain HTML fetch otherwise | Playwright is not a dependency of this package, so a JavaScript-rendered site captures as its pre-render HTML | install both locally (below), then --render chromium |

xch mirror-verify reports which live pages the clone missed, so you do not have to guess whether any of this bit you.

Chromium rendering needs Playwright resolvable from the kit, which an npx run cannot be — it executes out of npm's cache, so a project-local Playwright is not on its resolution path. Put both in one tree:

npm i -D @speed.press/kit playwright
npx playwright install chromium
npx xch mirror https://your-wordpress-site.com --render chromium --out .

Install it properly

npm install -g @speed.press/kit
xch --help

Two engines

• mirror — captures the site exactly as it looks today. Use this when the design should not change.
• scaffold — rebuilds a clean headless frontend from the WP REST API. Use this for blogs, docs and other structured content you want restyled.

Commands

| Command | Does | |---|---| | xch mirror <wp-url> | Exact-capture a site into a deployable static Astro project | | xch mirror-verify | Measure the clone against the live site (--visual adds a screenshot diff) | | xch scaffold <wp-url> | Generate an Astro project + Dockerfile from the WP REST API | | xch analyze <wp-url> | Scan a WP site: post types, theme, plugins, permalinks, menus, taxonomies | | xch inventory <wp-url> | Public post types + counts and a recommended batch plan | | xch verify | Pre-deploy checks: routes, SEO meta, manifest integrity | | xch ai-scan <url> | Score AI & SEO agent-readiness via aiscan.site | | xch ai-ready | Write llms.txt + an AI-friendly robots.txt into a project | | xch covers | Generate 1200×630 social covers for pages missing an og:image | | xch case-studies | Scaffold the two-axis case-study + industry-story system | | xch mcp | Configure, inspect and test agent publishing | | xch sync | Pull latest WordPress content into local cache | | xch dependency-graph | Build the manifest mapping content IDs to URLs | | xch diff | Visual diff between generated Astro pages and source WordPress | | xch deploy | Deploy to xCloud: provision the site, connect GitHub, trigger the first build | | xch plugin-install | Install and configure the xCloud Headless Bridge WordPress plugin | | xch extract-design | Playwright-driven capture of HTML/CSS/screenshots from the live site | | xch build-components | Generate Astro components from a design capture using Claude |

Run xch <command> --help for all options.

Let an agent publish and edit the site

# from inside the generated project
[ -f .env ] || cp .env.example .env      # then point SITE_URL at your deployed HTTPS URL
xch mcp setup --project .

Set SITE_URL before running setup: it defaults to your WordPress address, and setup builds the connector config it prints from that value.

Setup writes the key into the project's .env rather than printing it. Copy it from there into your deployment environment as MCP_PUBLISH_KEY, and set SITE_URL there too — OAuth builds its issuer and endpoints from the deployed value. Then deploy and point Claude at https://your-site.example/api/mcp. It can publish posts straight away.

Page and file edits (edit_page, edit_source) additionally need GIT_REPO_URL and GIT_TOKEN on the container; those are committed to your repo and survive a redeploy. Scope the token to the one repository.

MCP in 3 commands →

Live content updates

Install the companion WordPress bridge plugin (bundled in release tarballs under plugin/) on your WordPress site and give it the container's webhook secret. It then posts on every edit, and the container updates just the affected pages in 1–5 seconds — no rebuild, no redeploy. This needs the container: a plain dist/ upload has no sidecar to receive the webhook.

Links

• Docs, skill, and bridge plugin: github.com/xCloudDev/xcloud-headless
• Hosted flow (convert from the browser, no CLI): Speed.Press (platform repo)

CLI: MIT. The bundled WordPress bridge (plugin/ in release tarballs) is GPL-2.0-or-later. See LICENSES.md for component licenses.