The Complete Guide to Routing a Custom Domain to WordPress (Without a Server)

WordPress is one of the best publishing tools available. It's fast, clean, the editor is excellent, and the SEO defaults are sensible. But WordPress's managed hosting (wordpress.com) and most self-hosted setups give you a URL like yoursite.wordpress.com or blog.yourcompany.com — a subdomain that sits outside your main domain's authority.

Moving WordPress to yourdomain.com/blog used to require either paying for WordPress.com custom domain features (which work, but point to a subdomain, not a subfolder) or running your own nginx reverse proxy (which requires a server, SSL setup, and ongoing maintenance).

This guide covers the Furl approach: no server, no code, live in under 15 minutes.

What we're building

Before: your WordPress blog lives at yoursite.wordpress.com or blog.yourcompany.com After: your WordPress blog lives at yourcompany.com/blog

The blog content is still served by WordPress — Furl sits at the edge, between the user and WordPress, and transparently proxies and rewrites everything so the user only ever sees yourcompany.com.

WordPress hosting options and what they support

WordPress can be deployed in several ways. The routing approach differs slightly depending on which you use.

The one requirement: WordPress needs to be publicly accessible at some URL before you set up Furl routing. Furl proxies an existing public WordPress instance — it doesn't host WordPress itself.

Step 1: Confirm your WordPress instance is publicly accessible

Your WordPress origin URL is whatever URL WordPress currently serves content from. For WordPress.com accounts, this is youraccountname.wordpress.com. For self-hosted setups, it's wherever you've deployed it.

Test it: open the URL in a browser. You should see your WordPress site loading normally.

Step 2: Point your domain DNS to Furl

Log into your DNS provider (Cloudflare, Namecheap, GoDaddy, Porkbun — wherever your domain registrar is). Add these two records:

Type          Name   Value              TTL
CNAME/ALIAS   @      proxy.usefurl.com  Auto
CNAME         www    proxy.usefurl.com  Auto

If you're using Cloudflare: make sure the proxy (orange cloud) is disabled on the CNAME record. Furl handles edge proxying via Cloudflare for SaaS — double-proxying through Cloudflare's regular CDN breaks SSL certificate provisioning.

If you already have apex records (@): replace them with your provider's CNAME flattening/ALIAS target to proxy.usefurl.com. If you have an existing website at the root (@), this will affect it — you may want to set up Furl routing for your main site as well, or use a subdomain for the blog path only.

Propagation typically takes 2–10 minutes with Cloudflare, up to 30–60 minutes with other providers.

Step 3: Add your domain to Furl

1. Log into app.usefurl.com and create a new domain workspace
2. Enter your domain (yourcompany.com)
3. Furl will show you the DNS records to add (same as above)
4. Once DNS propagates, Furl will verify and provision SSL automatically

You'll see a green "Verified" status once both records resolve. SSL typically activates within 3–5 minutes of verification.

Step 4: Create the /blog route

In your Furl dashboard, click Routes → New Route and fill in:

• Path: /blog
• Destination: Your WordPress origin URL (e.g. yourname.wordpress.com or blog.yourcompany.com)
• Platform: WordPress ← this enables automatic link rewriting
• Force HTTPS: enabled
• Strip path prefix: disabled (WordPress expects the /blog prefix to be preserved)

Click Save. The route activates at the edge globally within about 1 second.

Open https://yourcompany.com/blog in a private window. You should see your WordPress blog loading.

Step 5: Configure WordPress to know about its new URL

This step is critical and is the most common source of broken links after migration.

WordPress stores its "site URL" in its configuration. Every link WordPress generates — for posts, navigation, RSS, the member portal — is based on this URL. If WordPress thinks it's at yourname.wordpress.com but is being served at yourcompany.com/blog, link rewriting fixes the output, but WordPress's internal logic (membership emails, API responses, webhooks) will still use the old URL.

For WordPress.com users:

1. Go to your WordPress admin panel (yourname.wordpress.com/wp-admin)
2. Settings → General
3. Update Site Address (URL) to https://yourcompany.com/blog
4. Save

For self-hosted WordPress: Edit your WordPress configuration file (wp-config.php) or set the values in your hosting dashboard:

define('WP_HOME', 'https://yourcompany.com/blog');
define('WP_SITEURL', 'https://yourcompany.com/blog');

Then restart your web server or PHP process.

How link rewriting works (and what it covers)

When a user requests yourcompany.com/blog/my-post, Furl:

1. Receives the request at the nearest edge node
2. Forwards it to your WordPress origin (e.g. yourname.wordpress.com/blog/my-post)
3. WordPress returns HTML with internal links pointing to yourname.wordpress.com/...
4. Furl's link rewriter scans the response body and rewrites all internal references
5. The rewritten HTML is sent to the user's browser

What gets rewritten:

What does not get rewritten automatically:

• WordPress's sitemap XML (served directly by WordPress, not through HTML parsing)
• Membership portal URLs in WordPress emails (configured separately in WordPress → Settings → Email)
• Webhook payloads sent by WordPress to third-party services

Handling WordPress's sitemap

WordPress generates a sitemap at /sitemap.xml. After migration, this sitemap still references your WordPress origin URL — it's XML, not HTML, so Furl's link rewriter doesn't touch it.

You have two options:

Option A (simplest): Submit manually to Search Console Don't rely on auto-submission. In Google Search Console, manually enter your sitemap URL: https://yourcompany.com/blog/wp-sitemap.xml. Furl will proxy this correctly.

Option B (cleanest): Custom sitemap If you need full control, generate your own sitemap that uses your production domain. A lightweight Cloudflare Worker or a WordPress sitemap plugin can generate this correctly.

For most sites, Option A is sufficient.

WordPress members and newsletters

If you're using a membership plugin, sessions and email links are scoped to the origin domain. After migration, some users may need to re-authenticate:

For newsletter delivery, update your WordPress email settings or plugin configuration:

• Ensure the sending domain matches your production domain
• Set any portal/member URL to https://yourcompany.com/blog

WordPress admin panel (/wp-admin)

Your WordPress admin will remain accessible at your WordPress origin URL (e.g. yourname.wordpress.com/wp-admin). You don't need to move it — it's a backend tool, not public-facing.

However, if you want your team to access admin via yourcompany.com/wp-admin, add a second Furl route:

• Path: /wp-admin
• Destination: yourname.wordpress.com/wp-admin
• Platform: Other
• Link rewriting: disabled (admin interfaces don't need rewriting)

RSS and podcast feeds

WordPress generates an RSS feed at /rss (or /blog/rss if you've configured WordPress with a /blog content prefix). This feed is consumed by RSS readers and podcast platforms.

If you have podcast subscribers or RSS readers pointed at your old subdomain URL, set up a 301 redirect:

blog.yourcompany.com/rss  →  yourcompany.com/blog/rss  (301 Permanent)

Furl's Redirects feature handles this without any server configuration.

Verifying the setup: a checklist

Common issues and fixes

404 on some blog posts but not others

Cause: WordPress stores posts with a URL structure based on the WordPress URL setting. If you changed the URL after some posts were published, the routing might not match.

Fix: In WordPress admin, check Settings → General → Publication URL. Ensure it's set to https://yourcompany.com/blog. Then re-index in Search Console.

Images showing but content missing (or vice versa)

Cause: Image assets in WordPress are often served from a CDN (WordPress's own CDN or your configured storage). These CDN URLs aren't rewritten by Furl because they're absolute URLs pointing to external origins (intentionally, since they're served correctly from those origins).

Fix: This is expected behavior. Image URLs point to WordPress's CDN directly — this is fine for performance and SEO. The content HTML links are what matter for SEO, and those are rewritten.

WordPress portal not working at production URL

Cause: WordPress's portal JS bundle reads the window.location to determine which domain it's on. If WordPress's "Site URL" config still points to the old domain, the portal won't match.

Fix: Update WordPress's Publication URL in Settings → General (WordPress.org) or config.production.json (self-hosted) to https://yourcompany.com/blog.

SSL certificate not provisioning

Cause: Cloudflare proxy (orange cloud) is enabled on the CNAME record, which intercepts Furl's certificate provisioning.

Fix: Set the CNAME record to DNS-only mode (grey cloud) in Cloudflare DNS. Furl handles edge SSL via its own Cloudflare for SaaS integration.

Performance impact

WordPress on its own is already fast — it was built with performance in mind and the default Casper theme scores well on Core Web Vitals. Furl adds a layer of routing, but because it runs at the Cloudflare edge (260+ locations globally), the routing itself adds negligible latency.

In practice, users in regions far from your WordPress server will see lower latency after Furl routing because:

1. The Furl edge connection terminates near the user
2. The connection from the edge to WordPress is over a private, optimized network
3. Cacheable responses (static pages, images) can be cached at the edge

WordPress(Pro) Business plan includes Cloudflare CDN natively. With Furl routing on top, you're effectively adding an additional edge layer for routing intelligence without sacrificing the CDN cache behavior.

The SEO outcome

Once your setup is live and you've submitted your updated sitemap to Search Console, the SEO benefit accrues over the next 60–90 days as Google re-crawls and consolidates the domain authority.

Based on migrations we've observed:

• Sites with a DR of 40+ typically see 15–25% organic traffic improvement within 90 days
• Sites with strong backlink profiles to their existing blog subdomain see the largest gains
• The improvement compounds — every new backlink earned post-migration flows directly to your main domain

The WordPress-specific aspect that accelerates this: WordPress's default metadata is excellent. Title tags, meta descriptions, Open Graph, Twitter Card, structured data (Article schema) — all are configured sensibly out of the box. You're not fighting the platform; you're just putting it in the right place.