The Problem With Subdomain Routing
If your blog lives at blog.yourdomain.com instead of yourdomain.com/blog, you're splitting your domain authority. Google treats blog.yourdomain.com as a separate entity from yourdomain.com. Every backlink to your blog post accrues authority to the subdomain — not your main domain.
This isn't a theory. It's well-documented SEO behaviour, and it's why enterprise teams spend significant engineering effort consolidating their content onto a single domain.
The traditional approaches to subfolder routing are:
- Nginx/Caddy reverse proxy — requires a server you maintain, an engineer to configure it, and ongoing ops burden.
- Next.js
rewrites()— works only if your destination is another Next.js app or a compatible endpoint. - Cloudflare Workers — powerful but requires writing and deploying custom Worker code per route.
None of these scale gracefully when a non-technical team needs to add or change routes without a PR.
What "Edge" Actually Means
When we say Furl routes at the edge, we mean your routing logic runs inside Cloudflare's infrastructure — at one of their 260+ data centres globally — rather than on an origin server somewhere in us-east-1.
User request
↓
Cloudflare edge node (nearest to user)
↓ (Furl routing logic executes here)
Origin platform (WordPress, Webflow, etc.)
↓
Response flows back through the same edge node
↓
User receives response
The critical insight: Furl's routing logic adds zero round trips. The decision of "does this request go to WordPress or Wix?" happens in the same step as TLS termination and connection establishment.
Latency Benchmarks
We ran latency tests across 12 global locations comparing Furl subfolder routing against a traditional VPS-based Nginx reverse proxy:
| Location | Nginx proxy (avg) | Furl edge (avg) | Δ |
|---|---|---|---|
| London | 38ms | 4ms | −89% |
| New York | 12ms | 2ms | −83% |
| Singapore | 142ms | 8ms | −94% |
| São Paulo | 189ms | 11ms | −94% |
| Sydney | 228ms | 9ms | −96% |
The Nginx numbers are from a reasonably well-configured $40/month VPS with global CDN in front. The difference isn't about hardware — it's about where the routing decision is made relative to the user.
How Furl Handles Link Rewriting
This is the part that most DIY routing setups get wrong.
When your WordPress blog at yourblog.wordpress.com serves a page, it generates HTML with internal links pointing to yourblog.wordpress.com/blog/.... If Furl just forwarded that response unchanged, your user would see yourblog.wordpress.com in the HTML — and clicking any internal link would take them off your domain.
Furl rewrites the response body at the edge, replacing all internal origin references with your domain:
Before: <a href="https://yourblog.wordpress.com/blog/my-post">Read more</a>
After: <a href="https://yourdomain.com/blog/my-post">Read more</a>
This happens to:
<a href>elements<link rel="canonical">— important for SEO<meta property="og:url">— important for social sharing- CSS
background-image: url(...)references - Redirect
Location:headers
::callout[warning] Platform-specific quirks exist. WordPress and Wix handle canonicals and asset URLs differently. Furl has platform-specific handling for Webflow, WordPress, and Wix to account for this automatically. ::end
The SEO Outcome
When you route /blog through Furl to WordPress, and Furl rewrites the canonical URL:
<link rel="canonical" href="https://yourdomain.com/blog/my-post" />Google indexes the page under yourdomain.com. Every backlink to yourdomain.com/blog/my-post accrues authority to your main domain. Your blog content and your product/marketing site share a single authority pool.
Teams who have migrated from blog.yourdomain.com to yourdomain.com/blog via Furl typically see a 15–35% improvement in organic search clicks within 90 days, accounting for the time Google needs to re-index the canonical URLs.
What We're Building Next
The routing engine is the foundation. What we're building on top of it:
- Request-level A/B testing — not just origin-level split testing, but per-request variant assignment with full observability
- Edge middleware — run custom logic (auth headers, bot detection, geo-gating) on every request before it reaches the origin
- Analytics at the edge — cookieless, JS-free traffic data derived from edge telemetry rather than client-side scripts
We're early. If you're curious about any of this or want to discuss specific use cases, reach out at hello@usefurl.com.