Add a blog to a Webflow, Framer, or static site by routing /blog at the edge to a separate blog system while every other path passes through to your existing host. The host CMS stays untouched, the blog lives on the same domain for SEO, and you avoid a full CMS migration.
Webflow CMS works for simple sites, but its 10,000 item limit, limited blog features, and design constraints make it a poor fit for serious content operations. Here are three better approaches to add a blog to your Webflow site.
Edge routing lets you serve /blog from a different origin while keeping your main site untouched. Learn how it works and when it's the right choice for your team.
Most marketing teams who want a blog already have a website. The site lives on Webflow, Framer, a static site generator, or a hand-built Next.js project, and it works. Replacing it to add a content surface is months of work and a coordination tax across design, dev, and marketing. The right move is usually to leave the marketing site alone and add a blog at the edge so /blog resolves to a different system while everything else passes through. This guide is the design pattern. For a primer on the underlying technique, see Edge Routing Explained: What It Is and When to Use It.
A CMS migration is rarely about content. It is about the surrounding infrastructure: design tokens, layouts, navigation, analytics, A/B testing, redirects, forms, and the dozens of integrations a marketing site accumulates. Moving the marketing pages to whatever CMS happens to be good at blogs means rebuilding all of that, plus retraining the team that publishes pages today.
The cost is also strategic. Marketing sites are tuned for conversion and brand. Blogs are tuned for publishing throughput, structured content, and SEO. The constraints conflict. A CMS that is great at one is usually mediocre at the other, which is why most companies that try to unify them end up with a marketing site that publishes slowly and a blog that does not match the brand.
Co-existence solves both. The marketing site stays in the system that does it well. The blog runs in a system designed for content velocity. The two are joined at the URL layer, not the CMS layer. The mechanism that makes the URL-layer join cheap is edge routing.
The case for subfolders is consolidation. When yourdomain.com and yourdomain.com/blog share a host, every backlink to either path contributes to the same authority signal that Google uses to rank pages on that host. When you split to blog.yourdomain.com, you create a second host that has to earn its own signals, even though it shares your brand.
Subdomains are not penalized. They are just treated as adjacent properties, which means a backlink to a blog post on a subdomain helps the subdomain rank, not the marketing pages. For most teams that want their blog to lift the marketing pages, the subfolder is the right choice. The historical reason teams chose subdomains, namely that the blog CMS could not share a host with the marketing CMS, is no longer a real technical constraint. Edge routing makes shared hosts trivial.
We have a longer breakdown of the data in Subfolder vs Subdomain: What the SEO Data Shows.
Edge routing is a request-level decision made before your origin sees traffic. A user requests yourdomain.com/blog/post. DNS sends the request to your CDN or edge platform. An edge function or routing rule inspects the path, sees that it starts with /blog, and forwards the request to the blog origin. The blog origin renders the response and returns it. The CDN caches the response and serves it to the user. To the browser, the page came from yourdomain.com.
The same request to yourdomain.com/pricing follows a different rule and is passed through to the marketing origin. Neither origin knows the other exists. Each system is self-contained.
The mechanics are well-trodden. Cloudflare Workers, Vercel proxy/rewrites, Fastly VCL, AWS CloudFront Functions, and Netlify Edge Functions all support this pattern. The concept is the same across all of them: match a path, rewrite the origin, preserve the host header. We covered the implementation details in Edge Routing Explained: What It Is and When to Use It.
The routing rule needs to match /blog and /blog/* exclusively. Common mistakes are matching /blog as a prefix (which would also match /blogger or /blog-old) or matching only /blog/ (which misses the bare /blog landing page). Use anchored patterns: ^/blog$ and ^/blog/.
The blog origin must see the public host (yourdomain.com), not the internal origin host. This matters for canonical URL generation, sitemap output, and any absolute URLs the blog system emits. Most edge platforms preserve the host header by default, but some default to the origin's host. Check before you ship.
CDN caches key on host, path, and a configurable set of headers. If your CDN caches /blog responses on the same key as marketing responses, and you have a path collision (rare but possible during rollouts), the wrong content can ship. Most edge platforms partition cache by origin automatically. Verify, and if you need belt-and-braces, add a cache tag prefix per origin.
Before you add the routing rule, audit:
The pattern is the same across providers, with provider-specific syntax.
https://yourdomain.com/blog/post-slug, not the internal origin.For Webflow specifically, we walk through the exact configuration, including DNS handoff, reverse-proxy setup, and how to keep the Webflow Designer workflow intact, in Add a Blog to Webflow Without Webflow CMS.
CDN cache conflicts. If both origins are behind the same CDN with overlapping cache rules, a stale entry from one can serve to the other during a deploy. Set cache tags per origin so purges are targeted, and confirm purge propagation before relying on it.
Robots.txt fragmentation. Each origin will try to serve its own robots.txt at /robots.txt. Only one can win. Pick one source of truth and route /robots.txt explicitly to that origin. Do not let the blog origin's robots.txt accidentally serve at the public host with rules scoped to the internal origin.
Sitemap host mismatches. If the blog system generates a sitemap with internal-origin URLs, every URL in the sitemap will 404 when crawled at the public host. Configure the blog system to emit absolute URLs using the public host. This is a one-line config in most blog systems and the most common reason indexing breaks.
Hreflang propagation. If the marketing site uses hreflang and the blog does not, Google sees an inconsistent set of language hints on the host. Either extend hreflang to the blog or remove it from the marketing pages until you can. Inconsistent hreflang is worse than no hreflang.
Canonical URL drift. Some blog platforms emit canonicals based on the request host. Some emit based on a configured public URL. The second is correct for this pattern. The first will silently break if any internal traffic hits the blog origin directly.
Trailing slash inconsistency. If the marketing site uses trailing slashes and the blog does not (or vice versa), you will accumulate duplicate URLs in the index and dilute equity. Pick one convention and enforce it on both sides with 301 redirects.
Co-exist when:
Migrate when:
For most teams the right answer is co-exist for at least the first year. Edge routing makes the cost of co-existence low enough that the question becomes "is the marketing site good enough" rather than "what CMS should we standardize on". EdgeBlog is the autonomous case of this pattern, where the blog system both publishes and routes itself, but the underlying technique is provider-agnostic and works with any blog backend that can serve clean HTML at a public host.