# Royal MCP on SiteGround: The Complete Setup Playbook

> Royal MCP on SiteGround takes three fixes in order: nginx path intercept, static-file Content-Type and SG Optimizer Dynamic Cache exclusions, in 15 minutes.

- Canonical: <https://royalplugins.com/support/royal-mcp/royal-mcp-on-siteground/>
- HTML version: <https://royalplugins.com/support/royal-mcp/royal-mcp-on-siteground/>

---

SiteGround is a good WordPress host that happens to have three specific infrastructure characteristics that stack together to make Royal MCP’s OAuth flow tricky. None of them are SiteGround being difficult; it’s just that Royal MCP’s OAuth flow lands on paths and Content-Types that SiteGround’s optimization layers treat differently than most WordPress requests. Fix all three in order and it works cleanly. Under 15 minutes end-to-end.

📍 Do the three layers in order

Each layer masks the next. If you skip Layer 1, Layers 2 and 3 have nothing to work with. If you fix Layer 3 without Layers 1 and 2, OAuth discovery still fails at first contact. The good news: you only have to do this once per site.

## Prerequisite: Royal MCP 1.4.14 or newer

The Royal MCP `1.4.14` release fixed a `GET /mcp` returning `405` that Claude.ai treats as “server unreachable”, which stops the OAuth flow before it starts. Anything from `1.4.14` onward has this fix. Confirm your version at WP Admin → **Plugins → Installed Plugins**, and update if needed before working through the three layers below.

## The Three Layers, in Order

#### Layer 1: SiteGround’s nginx intercepts `/.well-known/*`

**Symptom:** curl on the OAuth metadata URL returns a tiny `404` with `Server: nginx` and no `X-Httpd` header. WordPress never sees the request.

**Verify:**

```
curl -sI https://your-site.com/.well-known/oauth-authorization-server
```

Windows PowerShell users: use `curl.exe` for every curl in this playbook, and skip the `| grep` pipes further down (just read the full response and eyeball the header instead).

**Fix in one line:** create two static JSON files in your webroot at `/.well-known/oauth-authorization-server` and `/.well-known/oauth-protected-resource`. SiteGround serves anything that physically exists at `/.well-known/`; it just refuses to fall through to WordPress otherwise. Full walkthrough with the exact file contents:

[SiteGround Returns 404 for `/.well-known/`

Step-by-step: create the static files via SiteGround File Manager or SFTP, with the exact JSON body to paste.](https://royalplugins.com/support/royal-mcp/siteground-well-known-404/)

#### Layer 2: Those static files get served as `text/plain` not `application/json`

**Symptom:** after Layer 1, the same curl now returns `200` with the JSON body, but the `Content-Type` header shows `text/plain` (or nothing at all). RFC 8414 requires OAuth discovery to serve `application/json`. Strict MCP clients (Claude Desktop, mcp-remote) reject the metadata even though the body parses.

**Verify:**

```
curl -sI https://your-site.com/.well-known/oauth-authorization-server | grep -i content-type
```

**Fix in one line:** a free Cloudflare Transform Rule at the edge overrides the response `Content-Type` to `application/json`. Since SiteGround moved to Google Cloud infrastructure they no longer make per-customer nginx overrides, and `.htaccess ForceType` is silently ignored because nginx serves `/.well-known/` files directly without falling through to Apache. The Cloudflare edge is the working path. Two-minute setup:

[Fix `/.well-known/` Content-Type with a Cloudflare Transform Rule

Step-by-step Cloudflare dashboard walkthrough. Free plan works. No SiteGround support ticket needed.](https://royalplugins.com/support/royal-mcp/siteground-cloudflare-content-type-fix/)

#### Layer 3: SG Optimizer Dynamic Cache poisons the OAuth handshake endpoints

**Symptom:** after Layers 1 and 2, discovery works but Claude.ai still shows “Authorization with the MCP server failed” after clicking Authorize. The `/authorize`, `/token`, or `/register` endpoints return stale cached responses from earlier probe attempts.

**Verify:**

```
curl -sI https://your-site.com/authorize | grep -iE 'x-cache|x-proxy-cache'
```

If any of these headers appear in the response with a non-empty or `HIT` / `True` value, cache is in the way. SiteGround emits `x-cache-enabled` and `x-proxy-cache-info`; other stacks use HIT / MISS on `x-cache`.

**Fix in one line:** in **SG Optimizer → Caching → Dynamic Cache → Exclude URLs**, add `/wp-json/royal-mcp/*`, `/.well-known/oauth-authorization-server`, `/.well-known/oauth-protected-resource`, `/authorize`, `/token`, and `/register`. Then **Purge SG Cache** from the toolbar. The purge is critical, without it any cached 4xx responses from earlier attempts keep getting served regardless of the new exclusions. Full walkthrough with screenshots:

[OAuth Fails on Managed Hosts (SiteGround, o2switch, LiteSpeed) → Option A

SG Optimizer exclusion list + purge instructions + how to spot cache-hit headers on the OAuth endpoints.](https://royalplugins.com/support/royal-mcp/oauth-fails-on-managed-host/#fix)

## Verify the Connection Works

After all three layers are in place, add the connector in Claude.ai (or Claude Desktop) with just your MCP URL and Advanced Settings empty. What success looks like:

1. Claude’s OAuth consent screen appears (you grant access).
2. Claude shows the connector as connected in Settings.
3. Try a prompt like “list my last 5 WordPress posts” and real data comes back.
4. WP Admin → **Royal MCP → Activity Logs** shows an `oauth:register` row followed by `oauth:authorize` and `oauth:token` Success entries.

## Need It Working Today? Skip OAuth Entirely with Claude Desktop

If you can use Claude Desktop instead of Claude.ai web, you can sidestep all three layers above. Royal MCP supports API-key authentication via `mcp-remote`’s `--header` flag, no `/.well-known/` discovery, no consent screen, no Cloudflare Transform Rule. Confirmed working on SiteGround. Two-minute setup:

[Connect Claude Desktop via API key

Paste 8 lines into your Claude Desktop config, restart, done. Bypasses OAuth completely.](https://royalplugins.com/support/royal-mcp/connect-claude-desktop-api-key/)

## Related Docs

[OAuth Fails on Managed Hosts (broader coverage)

Same class of edge-cache issue on o2switch, LiteSpeed Cache, and Cloudflare APO. Applies if you’re not on SiteGround but hit similar symptoms.](https://royalplugins.com/support/royal-mcp/oauth-fails-on-managed-host/)
[Troubleshooting Start Here (all connection issues)

Full symptom router if you’re not sure the SiteGround setup applies, or if your issue turns out to be something else after Layer 1.](https://royalplugins.com/support/royal-mcp/troubleshooting-start-here/)
[Diagnose Royal MCP with curl

Deeper protocol-level curl walkthrough. Useful for verifying each layer is fixed and hunting anything the three-layer playbook doesn’t cover.](https://royalplugins.com/support/royal-mcp/diagnose-mcp-with-curl/)

Credit

The three-layer breakdown in this playbook was distilled by [@vipestudio on the wp.org forum](https://wordpress.org/support/topic/siteground-wordpress-claude/#post-19011005) after working through the full sequence himself. His summary captured what several rounds of our own support responses hadn’t yet consolidated in one place. Thanks Ivan.

[Back to Troubleshooting Start Here](https://royalplugins.com/support/royal-mcp/troubleshooting-start-here/)
[Royal MCP Support Hub](https://royalplugins.com/support/royal-mcp/)