Webflow + Custom Domain: The Subfolder Setup That SEO Experts Recommend

Webflow is the dominant no-code website builder for marketing teams. The editor is powerful, the hosting is reliable, and the CMS handles content well enough for most marketing use cases.

But there's a persistent SEO problem with Webflow's default setup that affects thousands of sites: Webflow's native custom domain feature connects your youraccount.webflow.io to a root domain (yourdomain.com) or a subdomain (marketing.yourdomain.com). It doesn't support subfolder routing natively.

This matters because the highest-traffic content on many marketing sites lives in the Webflow CMS — blog posts, case studies, resource pages, landing pages. If that content is on a subdomain (blog.yourdomain.com or pages.yourdomain.com), it's not building authority on yourdomain.com.

The fix is Furl routing. Here's how it works, specifically for Webflow.

Why Webflow doesn't support subfolders natively

Webflow's infrastructure serves all site content from the root of whatever domain you configure. When you set yourdomain.com as your Webflow custom domain, Webflow assumes it owns the entire domain. There's no built-in mechanism to say "serve only this path from Webflow."

This is a deliberate architectural decision — it simplifies Webflow's infrastructure significantly. But it creates a problem when you want Webflow to serve /blog while a different service handles /app or your main homepage.

Furl solves this by sitting in front of everything: users hit yourdomain.com, Furl routes each path to the appropriate origin, whether that's Webflow, WordPress, Wix, or your SaaS app.

Common Webflow + Furl configurations

Scenario A: Webflow handles your entire marketing site

Your main site is on Webflow. You want to route /blog to WordPress (for the writing experience) or keep it in Webflow CMS but ensure authority consolidation.

In this case, you route your root domain to Webflow (@ and www) and keep everything on Webflow. No subfolder routing needed — the domain is already unified.

Scenario B: Webflow handles your marketing site, SaaS app is separate

Route: yourdomain.com and yourdomain.com/marketing → Webflow Route: yourdomain.com/app → your SaaS application

Scenario C: Your main domain is your SaaS app, Webflow handles marketing

This is the most common scenario we see. Your Next.js or Rails app lives at yourdomain.com. You want Webflow to handle yourdomain.com/blog or yourdomain.com/resources without touching your main app.

Route: yourdomain.com/blog → Webflow CMS blog Route: yourdomain.com/resources → Webflow resources

This is what we'll focus on.

Step 1: Set up Webflow with a staging URL

For the subfolder routing approach, you need Webflow to serve content from a URL that Furl can proxy. The simplest approach: use your free youraccount.webflow.io subdomain as the origin.

In Webflow's hosting settings, ensure your webflow.io subdomain is active and publicly accessible. Don't set up Webflow's custom domain feature — Furl will handle the custom domain routing.

Step 2: Configure Webflow CMS collection URLs

This is the most important Webflow-specific step. Webflow CMS collections have a "slug" configuration — the URL prefix used for collection items.

By default, your blog posts might be at youraccount.webflow.io/blog/post-title. The /blog prefix in Webflow's URL structure needs to match the route prefix you set up in Furl.

In Webflow's Designer → Pages → CMS Collections, set your blog collection slug to /blog. This ensures:

• Posts appear at youraccount.webflow.io/blog/post-title (Webflow origin)
• After Furl routing: yourdomain.com/blog/post-title (production URL)

Step 3: Add your DNS records

Same as any Furl setup. In your DNS provider:

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

If Cloudflare: orange cloud proxy off on the CNAME.

Step 4: Create the Furl route

In your Furl dashboard, create a new route:

• Path: /blog
• Destination: youraccount.webflow.io (your Webflow origin)
• Platform: Webflow
• Link rewriting: enabled

The Webflow platform setting enables Furl's Webflow-specific link rewriter. This is important — Webflow generates some links differently from WordPress or plain HTML, and the rewriter has Webflow-specific handling.

Webflow-specific link rewriting considerations

Webflow generates several types of URLs that need rewriting:

CMS collection links Internal links between CMS collection items use relative paths, which typically don't need rewriting. But if Webflow generates any absolute internal links (it does for canonical tags and OG meta), Furl's rewriter catches these.

Webflow's asset CDN Webflow serves images and other assets from its own CDN (uploads-ssl.webflow.com). Furl does not rewrite these — and it shouldn't. They're served from Webflow's CDN correctly regardless of what domain your site is on. Rewriting them would break asset loading.

JavaScript includes Webflow's webflow.js includes absolute references to Webflow infrastructure. These don't need rewriting for the site to function, and Furl leaves them alone.

Canonical tags Webflow generates <link rel="canonical"> tags based on the site's configured URL. Since we're not setting a custom domain in Webflow (we're using Furl instead), Webflow's canonical will reference youraccount.webflow.io. Furl's link rewriter replaces these with yourdomain.com/blog URLs.

Webflow interactions and forms

Webflow's form submissions go through Webflow's own backend, regardless of what domain the form is on. When using Furl routing, forms continue to work — Webflow handles the submission, stores the data, and sends notification emails.

One consideration: if you've set up custom form redirects in Webflow (e.g., "redirect to /thank-you after submission"), ensure the redirect URL uses your production domain path, not the Webflow origin.

Webflow interactions (animations) work normally. These are JavaScript-driven and don't depend on the domain.

Setting canonical URLs in Webflow

While Furl's rewriter handles canonical tags automatically, you can also set canonical URLs manually per-page in Webflow:

1. Open the page in Webflow Designer
2. Click the page settings (gear icon)
3. Under "SEO Settings → Canonical Tag", enter the production URL: https://yourdomain.com/blog/post-slug

For CMS collections, Webflow allows you to set canonical tags dynamically using collection fields. Add a field (formula or text) that generates the correct production URL, then bind it to the canonical tag setting.

This belt-and-suspenders approach ensures canonical correctness even if Furl's rewriter has any edge cases.

Webflow's sitemap

Webflow auto-generates a sitemap at youraccount.webflow.io/sitemap.xml. Like WordPress sitemaps, this references the origin URL.

To fix this:

1. In Search Console, manually submit https://yourdomain.com/blog/sitemap.xml — Furl will proxy this from Webflow, and you can accept the origin URLs OR generate a custom sitemap
2. Alternatively, disable Webflow's sitemap (Hosting → SEO → Sitemap: Off) and generate your own

For most marketing sites, manually submitting the proxied sitemap URL in Search Console is sufficient. Google is good at following canonical tags even when sitemaps have mismatched URLs.

Performance: Webflow's CDN + Furl's edge

Webflow uses AWS CloudFront for asset delivery. Furl uses Cloudflare's network. The combination means:

• HTML and dynamic content: cached at Cloudflare edge nodes nearest to users
• Images and assets: served from Webflow's CDN (unaffected by Furl routing)
• Core Web Vitals impact: minimal — Furl adds ~1–3ms of processing overhead at the edge, which is imperceptible

Webflow sites already score well on Core Web Vitals for most use cases. The addition of Furl routing doesn't measurably impact these scores.

Multi-section Webflow sites

If you're using Webflow for multiple sections of your site (not just /blog), create separate routes for each:

You can route different Furl paths to different Webflow accounts/projects — useful for agencies managing multiple client Webflow sites under a single main domain.

What happens when Webflow publishes

When you publish changes in Webflow Designer, the update goes live at youraccount.webflow.io first. Furl picks this up on the next request (or within the cache TTL if you've configured edge caching). For most changes, this is instantaneous. For very high-traffic pages with long cache TTLs, you can manually purge the Furl cache from your dashboard.

The SEO payoff

Moving Webflow CMS content from a subdomain to a subfolder produces the same authority consolidation effect as any other subfolder migration. The specifics depend on how much content you have and how strong your backlink profile is.

For marketing-heavy companies using Webflow for their blog, resources, and case studies — which typically accumulate strong inbound links — the consolidation effect can be significant.

The results are most pronounced for companies where Webflow hosts their highest-trafficked content. A company whose Webflow blog drives 60% of their organic traffic sees the most from consolidation — that link equity has the most room to compound.