Edge routing and sitemap control for a Webflow site, built as a Cloudflare Worker
A Cloudflare Worker that owns host routing and sitemap generation in front of Webflow
What Webflow's page settings can't do at the edge
A Webflow site can need canonical host control, a generated sitemap that spans both static and CMS-driven routes, and proxy-level behavior that Webflow's own settings don't reach — all of which is easier to own at the edge than to patch together inside the CMS.
What the Worker needed to own
Build a Cloudflare Worker that redirects www traffic to the apex host, proxies every other request through to the Webflow origin untouched, and generates XML and HTML sitemaps by combining a configured list of static routes with live Webflow collection items.
One Worker: canonical host, proxy, and sitemap in one place
The deployed Worker intercepts requests before they reach Webflow, enforces the apex host as canonical, proxies normal traffic straight through, and serves sitemap requests by combining static route configuration with a live pull of Webflow CMS collection slugs.
Our other projects
The brief was to put a Cloudflare Worker in front of a Webflow-hosted site so host normalization, proxying, and sitemap generation could be controlled at the edge instead of relying on Webflow's settings alone.
A Webflow site may need canonical host normalization, a sitemap that reflects both static pages and CMS content, and route discovery logic that Webflow's own page settings simply don't expose.
This Worker belongs to a specific client domain and cannot be published, screenshotted, or named until that client approves. Keep private until that approval is in hand.
A Cloudflare Worker redirects www traffic to the apex host, proxies all other requests through to the Webflow origin, generates XML and HTML sitemap responses on request, and fetches Webflow collection items through the Webflow API to include their routes in the sitemap.
Every request to the domain hits Cloudflare first. The Worker normalizes the host, intercepts sitemap requests and builds them from static route configuration plus a live Webflow CMS API pull, and proxies everything else straight through to the Webflow origin unchanged.
- Canonical www-to-apex redirect
- Transparent Webflow origin proxying
- XML and HTML sitemap generation
- Combined static and Webflow-collection route sources
- Public-host URL normalization at the edge
This is a solid, working proof of Cloudflare-plus-Webflow routing — currently held private while SoFlow confirms permission to name the client and project publicly.
- Wrangler configuration names the production host directly
- Worker source includes working sitemap XML/HTML generation
- Worker fetches live Webflow collection routes through the Webflow API
Why can't SoFlow name the client publicly yet?
Because this Worker is tied to a specific domain and project, and naming it requires the client's sign-off first. The technique — edge proxying and Worker-generated sitemaps in front of Webflow — is exactly the kind of thing SoFlow can build for another site; it's the name attached to this particular one that needs clearing.
Why put this in Webflow if external code is involved?
Webflow is the public storytelling and CMS layer. External code should stay in the app, Worker, or integration layer where it can be versioned, secured, and tested.
What's needed before publishing?
Written permission to name the project, plus route and sitemap screenshots that don't expose anything the client considers private.
It proves SoFlow can extend a Webflow site's routing and discoverability at the edge with Cloudflare Workers — control that Webflow's own settings can't provide on their own.
Why can't SoFlow name the client publicly yet?
Because this Worker is tied to a specific domain and project, and naming it requires the client's sign-off first. The technique — edge proxying and Worker-generated sitemaps in front of Webflow — is exactly the kind of thing SoFlow can build for another site; it's the name attached to this particular one that needs clearing.
Why put this in Webflow if external code is involved?
Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
- Item 1
- Item 2
- Item 3
Unordered list
- Item A
- Item B
- Item C
Bold text
Emphasis
Superscript
Subscript
Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
- Item 1
- Item 2
- Item 3
Unordered list
- Item A
- Item B
- Item C
Bold text
Emphasis
Superscript
Subscript
The Webflow origin alone didn't control canonical hosting, proxy behavior, or a sitemap that reflected both static and CMS content.
A single Worker now owns host normalization, request proxying, and sitemap generation in front of the Webflow site.
Webflow's page settings don't give you edge-level redirects, transparent origin proxying, or a sitemap assembled dynamically from multiple route sources — that logic has to live in front of Webflow, not inside it.
