How to Connect Claude to Every WordPress Site You Own (Without One Connection Per Site)

Updated August 2026.

Connecting Claude to one WordPress site takes about five minutes. Connecting it to twenty, using the default method, takes about 100 minutes and leaves you with twenty MCP servers in your config, twenty application passwords to rotate, and an assistant that can only see one site per conversation. Two of the four methods below reduce that to a single connection that does not change as you add sites — setup drops to roughly two minutes per site with no client reconfiguration at all.

This guide covers all four, what each is good at, and how to verify the connection actually works before you trust it.

Key takeaways

• The official path — Automattic’s wordpress-mcp — is one server per site. Correct for one or two sites, painful past five.
• wp-mcp-router (free, open source) puts one router in front of many sites and routes by a site argument.
• InstaWP Account MCP gives one account-level connection for content and site operations.
• xSpeed Hub gives one connection for performance work across a fleet, with cross-workspace switching.
• Whichever you pick, verify with a read call before granting write access.

Why the default setup does not scale

An MCP server is a process that exposes tools to an AI client. Automattic’s wordpress-mcp plugin runs inside a single WordPress install, so it exposes that one site’s tools and nothing else.

The useful analogy is phone numbers. The default setup gives every site its own number: to speak to site twelve, you dial site twelve. A router or hub setup is a switchboard — you dial one number and say which site you want. The switchboard knows the extensions.

That distinction is the entire decision. Everything below is a variation on “do I dial direct, or through a switchboard?”

Which method fits you

Work out your branch before touching any config:

Do you manage more than ~3 WordPress sites?
├─ No  → Path A (official plugin, per site). Simplest, nothing extra to run.
└─ Yes → What is the AI actually for?
    ├─ Content, posts, users, settings
    │   ├─ Comfortable self-hosting a router → Path B (wp-mcp-router)
    │   └─ Prefer a managed account         → Path C (InstaWP Account MCP)
    └─ Site speed, caching, Core Web Vitals → Path D (xSpeed Hub)

Action: count your sites, then answer one question — “do I want the AI to write posts, or to make pages faster?” Those are different tool sets, and no single server currently does both well.

Still choosing a server rather than wiring one up? 10 Best WordPress MCP Servers in 2026 ranks the category on live install data.

---

Path A — Official plugin, one connection per site

Free · Best for 1–3 sites · ~5 min per site

Automattic maintains wordpress-mcp, the reference implementation. WordPress.com has supported MCP natively since October 2025, and the official WordPress MCP Adapter shipped in February 2026 as part of the AI Building Blocks initiative, converting abilities registered through the Abilities API into MCP primitives.

1. In WordPress, go to Plugins > Add New > Upload Plugin and install wordpress-mcp, then click Activate.
2. Go to Settings > MCP and tick Enable MCP functionality.
3. Go to Users > Profile, scroll to Application Passwords, type a name such as claude-mcp, and click Add New Application Password. Copy the 24-character password — it is shown once.
4. In Claude Code, run:

   claude mcp add --transport http mysite https://example.com/wp-json/wp/v2/wpmcp \
     --header "Authorization: Basic <base64 of user:app-password>"

5. Repeat steps 1–4 for every additional site, giving each a distinct name (client-alpha, client-beta).

Trade-off: nothing extra to run and nothing to trust. But the work is linear in site count, and the assistant sees one site per named server — you must say which one every time.

---

Path B — wp-mcp-router, one router in front of many

Free, open source · Best for 4+ sites, self-hosted · ~15 min setup, ~2 min per site

wp-mcp-router sits in front of your sites and routes calls by a site argument, so the AI client holds one connection. It discovers each site’s ability catalogue and caches it.

1. Install the router per its README and give it a config listing each site’s URL plus its application password.
2. Create an application password on each site as in Path A step 3 — the router still authenticates per site.
3. Point your client at the router once:

   claude mcp add --transport http wp-router http://localhost:PORT

4. Address sites by name in conversation: “List draft posts on client-alpha.”

Trade-off: one connection and full control, but the router is infrastructure you run, patch, and keep available. Its credential file holds every site’s password, so it needs to be treated as a secret store.

Warning: do not put the router on a public address without authentication in front of it. It is a single point of access to every site in the config.

---

Path C — InstaWP Account MCP

Best for content work across a managed account · ~2 min per site

InstaWP distinguishes Site MCP (inside one site) from Account MCP (across the whole account). Account MCP is one connection covering the account, and with the opt-in “act inside sites” capability it can reach the MCP inside each site beneath it.

1. Connect each site to your InstaWP account.
2. In InstaWP, mint an Account MCP connection.
3. Enable act inside sites only if you want the AI reaching into individual installs.
4. Add the connection to your client once:

   claude mcp add --transport http instawp <account_mcp_url>

Trade-off: nothing to self-host, and adding a site does not touch the client. You are trusting a third party as broker, and the tool surface is content and site operations rather than performance.

---

Path D — xSpeed Hub, one connection for performance

Free tier · Best for caching and Core Web Vitals across a fleet · ~2 min per site

This is the path we build, so treat the framing accordingly: it covers performance only. It exposes no tools for writing posts or managing users. If your job is content, Paths B and C are the right ones and this will not help.

For caching work specifically, WP Rocket also shipped an MCP in 3.23, though its documentation notes that “each website must be connected individually” — which puts it in the Path A shape. We compare the two tool by tool in xSpeed Cache MCP vs WP Rocket MCP.

Connect each site (no token to copy anywhere):

1. Open the xSpeed Cache dashboard on the site and click Connect Hub in the top bar — or open the xSpeed Hub tab in the MCP Server panel under AI & agents.
2. Click Connect via xspeedcache.com.
3. Sign in with Google or an emailed magic link, then click approve on the attachment screen.
4. You land back on the site with the connection confirmed. The Hub measures it immediately, so its first speed score is already there.

Connect your AI client once:

5. In the Hub, open Connect and mint a connection.
6. Choose its scope — full access is the default, or restrict to read-only, to specific sites, or with named tools denied.
7. Paste the config into Claude, ChatGPT, or any MCP-compatible client.

Every site added later appears in the existing conversation. The client is never reconfigured.

Requirements: a free account at app.xspeedcache.com, xSpeed Cache 1.1.0+ active on each site, and administrator access to attach.

Exclusion: local and development sites are skipped, because PageSpeed cannot reach them.

---

How to verify it actually worked

Do this before granting write access. Ordered easiest to most rigorous.

1. List the sites (10 seconds)

Ask the assistant to list what it can reach. On xSpeed Hub the underlying call is list_sites, and each row must read:

status: "verified"      ← required
scopes: ["read", ...]

Success threshold: every site you attached appears, and none shows status: "unreachable". An unreachable site fails silently inside a fleet-wide call — the call reports success overall while quietly skipping that site.

2. Read something real (30 seconds)

Ask for a live metric — cache status, or hit ratio. A healthy, warmed page cache reports a hit ratio of 90–99%. Anything under ~50% usually means the cache is cold rather than broken; run the preloader and re-check.

Failure looks like: an authentication error, or an empty result where a site should be. First debugging step is re-minting the connection — expired or mis-scoped credentials are the common cause.

3. Confirm the fleet is really one connection (1 minute)

The real test of Paths B, C and D: attach one more site, then ask the assistant about it without touching your client config. If it answers, the switchboard works. If you had to edit config, you are effectively still on Path A.

For multi-workspace setups, list_workspaces should return each workspace with reachable: true. A workspace showing reachable: false means you belong to it but did not grant it at consent — no tool call can widen that; reconnect and tick it.

Warnings and exclusions

• Take a backup before granting write scope. Write access is genuinely useful and genuinely consequential.
• Start read-only. Widen scope after you have watched the assistant work for a few days.
• Never commit application passwords to Git. Paths A and B both produce credentials that end up in config files.
• One MCP server per job. Running several with overlapping tools confuses the client and widens exposure.
• Firewalls block this. WP Rocket documents “Couldn’t reach [connector]” errors when a host blocks Anthropic IP ranges; the same class of rule affects every server here. Allowlist the client’s IPs.

Maintenance

• Rotate application passwords on a schedule for Paths A and B — they do not expire on their own.
• Re-check scopes quarterly, especially after someone leaves a team.
• Detach sites you no longer manage. With xSpeed Hub, removing the site from either side kills the Hub’s credential immediately; caching on the site is unaffected.
• Watch for unreachable. It is the failure mode most likely to go unnoticed, because fan-out calls report partial success as success.

Troubleshooting FAQ

It says “Couldn’t reach [connector]” — what do I do? Your host is almost certainly blocking the AI client’s IP ranges. Ask them to allowlist Anthropic’s, or test from a different network to confirm before changing anything.

A site shows status: "unreachable" — is it broken? Not necessarily. It usually means the site is down, behind HTTP auth, or its credential was revoked. Re-run the connection flow from the plugin side. Until it reads verified, fleet-wide calls will skip it.

A workspace shows reachable: false — how do I fix it? You belong to it but this connection was not granted it. No tool call can widen a connection’s reach — reconnect from xspeedcache.com and tick that workspace at the consent screen.

The assistant says it has no tools available. The connection was added but not authorized. Check the credential, and confirm the client actually restarted after the config change — Claude Desktop needs a full quit, not just a window close.

Can I use ChatGPT instead of Claude? Yes. MCP is an open standard, so any MCP-capable client works. Vendors document Claude most often because it shipped support first.

Do I have to pay for any of this? No. Automattic’s plugin, wp-mcp-router, and xSpeed Cache’s free tier all include MCP at no cost.

Can the AI break my site? It can change settings if you grant write scope. Back up first, start read-only, and prefer servers that verify or roll back their own changes.

Can one connection do both content and performance? Not today. Content servers expose posts, users and settings; performance servers expose caching and metrics. Running one of each is the current answer.

Does connecting to a hub mean my pages are served by someone else? Not with xSpeed Hub — it brokers control only; your pages are still cached and served by your own site. NitroPack-style cloud services are different and do sit in the delivery path.

Which to choose

Your Situation	Path	Setup Cost
1–3 sites, any purpose	A — official plugin	~5 min per site
4+ sites, content, self-hosted	B — wp-mcp-router	~15 min + 2 min per site
4+ sites, content, managed	C — InstaWP Account MCP	~2 min per site
Any number, performance work	D — xSpeed Hub	~2 min per site
Agency, separate client accounts	D — with workspaces	one connection, many workspaces

Start with Path A even if you plan to scale — connecting one site teaches you what the tools actually do, and it is five minutes you will not regret. Move to a switchboard when the config file starts annoying you, which in practice is around the fourth site.

Related reading

• 10 Best WordPress MCP Servers in 2026 — pick a server before you wire one up
• xSpeed Cache MCP vs WP Rocket MCP — the two performance servers, compared tool by tool
• 9 Best WP Rocket Alternatives in 2026 — caching plugins ranked on Core Web Vitals field data

Working on performance specifically? The xSpeed Cache MCP tool reference documents all 26 tools, connecting to xSpeed Hub covers the attachment flow in more detail, and scoped AI connections explains how to restrict what an assistant may touch.