Why

We want to connect Claude to the WordPress blog via MCP (the Royal MCP plugin) to read existing posts, use them as context, and occasionally publish. Claude's MCP client authenticates through OAuth discovery, and it requires the issuer host in the discovery document to match the URL it connects to. Today that match fails at the public blog URL, so MCP cannot connect.

Why it fails today (current setup)

www.alpy.com/blog is served by the Cloudflare Worker blog-worker-proxy, which reverse-proxies WordPress (running at blog.alpy.com) and rewrites blog.alpy.com → www.alpy.com/blog in HTML responses only. JSON responses — including the REST API and the OAuth discovery document — are passed through untouched. So the discovery doc keeps advertising blog.alpy.com as the issuer while we connect at www.alpy.com/blog → host mismatch → MCP can't register/authenticate.

In short: the blog only looks like it lives at www.alpy.com/blog. WordPress still believes it is blog.alpy.com. The HTML-rewrite proxy is a cosmetic layer, not a real migration.

The proper fix (not the rewrite hack)

Make WordPress genuinely serve itself at www.alpy.com/blog, so every response — HTML and JSON — is natively correct and no rewriting is needed. The database has already been search-replaced from blog.alpy.com → www.alpy.com/blog, so the content side is done; the remaining work is the Worker config, the origin host, and a clean redirect.

Current Worker variables (confirmed via https://www.alpy.com/blog/__worker_version__):

BLOG_ORIGIN_HOST = blog.alpy.com
BLOG_FORWARD_HOST = blog.alpy.com
BLOG_PATH_MODE = strip

What to do (in this order — order matters)

Websupport (origin): Configure the hosting to serve the WordPress site for Host: www.alpy.com (ServerAlias / add the domain to the account) with a valid TLS cert covering it. Until this is true, do not change the Worker — sending Host: www.alpy.com to an origin that only knows blog.alpy.com returns the wrong vhost / 404 for the entire blog.
Dedicated origin hostname (needed for the redirect): Create an internal hostname the Worker uses to reach WordPress (e.g. origin.alpy.com → the Websupport server). Required because blog.alpy.com currently does double duty — both the public legacy URL and the Worker's only route to the origin — so the step-6 redirect would otherwise cut the Worker off from WordPress.
Worker variables (blog-worker-proxy → Settings → Variables — no worker.js code change needed):
- BLOG_ORIGIN_HOST → origin.alpy.com (the new internal hostname)
- BLOG_FORWARD_HOST → www.alpy.com
- BLOG_PATH_MODE → leave as strip (WordPress is installed at the origin root)
- rewriteBody simply becomes a harmless no-op once WordPress emits the correct URLs natively.
Cloudflare SSL: Set SSL mode to Full (strict) once the origin has a valid cert for the host the Worker connects to.
WordPress WP_HOME flip: With the Worker change live and posts confirmed loading, set WP_HOME = https://www.alpy.com/blog (WP_SITEURL is already that). DB is migrated, so it resolves immediately. Must happen after step 3, never before — flipping it first re-creates the redirect loop we already hit.
301 from the old URL: Add a permanent redirect blog.alpy.com/* → www.alpy.com/blog/* (preserve path + query) so the external / paid inbound links we don't control keep working.

Rollback

Worker deployments and variable changes are versioned — roll back to the current version (deployed ~1 day ago) in one click from the Worker's Deployments tab. No data migration is involved, so rollback is clean and instant.

Note (interim)

This ticket is specifically about making MCP work cleanly at the public www.alpy.com/blog URL as part of finishing the migration properly.

Summary table