An edge layer that makes multilingual Webflow routing reliable
The challenge behind multilingual routing
A multilingual site needs every localized route to behave consistently — the right canonical URL, correct sitemap inclusion, and a sensible fallback for pages that exist in one language but aren't ready in another. Left to individual page settings, that consistency erodes fast as the site grows.
The implementation goal
Migrate the multilingual Worker into the broader platform's service structure while preserving everything it already handled: Webflow origin proxying, localized routes, canonical routing, route manifests, protected diagnostics, and sitemap behavior.
An edge proxy that owns multilingual SEO logic
A Cloudflare Worker sits in front of Webflow, reading a KV-backed route manifest to decide canonical URLs, sitemap inclusion, and redirects for pages that aren't ready — all before a request ever reaches Webflow's origin.
Our other projects
The brief was to control multilingual routing and SEO behavior for a Webflow site without turning every localized path into a brittle, manually maintained setting.
Localized websites need every route to handle canonical URLs, sitemap coverage, and not-ready fallback behavior the same way, every time. Managed manually inside Webflow, that consistency depends entirely on someone remembering to configure it correctly page by page.
The service includes production diagnostics, route manifests, and platform-specific routing decisions. Public content needs to focus on the architecture and the outcome, not expose protected diagnostics endpoints or internal route identifiers.
SoFlow migrated the multilingual Worker into the platform's service structure, preserving Webflow origin proxying, localized route handling, canonical routing, route manifests, protected diagnostics, and sitemap behavior — all in one maintained edge layer.
A Cloudflare Worker sits in front of Webflow and reads route manifest state from KV to apply multilingual routing and canonical decisions, protect diagnostic endpoints, exclude not-ready CMS routes from the sitemap, and redirect incomplete public paths to stable alternatives.
- Webflow origin proxying at the edge
- Localized route handling across languages
- Canonical and SEO routing controls
- Language-switcher route manifest backed by Cloudflare KV
- Sitemap exclusions for pages that aren't ready yet
- Protected diagnostics and route parity snapshots
Multilingual routing became a maintainable, testable layer at the edge instead of a set of manual Webflow settings — the kind of infrastructure that scales as more languages and routes are added.
- Migration status and deployed Worker version documented
- Local route parity confirmed after seeding local KV from the live route manifest
- Blog, FAQ, and discipline detail routes intentionally excluded from the sitemap while not yet ready
Why not just use Webflow's built-in localization settings?
Webflow's page-level settings work for simple cases, but they don't give programmatic control over canonical URLs, sitemap exclusions for pages that aren't ready yet, or redirect logic that has to be consistent across every localized route. Once a site needs those decisions made systematically rather than page-by-page, that logic belongs in a Worker sitting in front of Webflow, not scattered across individual page settings.
Why put this in Webflow if external code is involved?
Webflow remains the content and public storytelling layer — every localized page still lives and gets edited there. The Worker only intercepts requests at the edge to apply routing, canonical, and sitemap decisions before Webflow ever serves the page.
What is needed before publishing?
Confirmation of which live routes are safe to reference publicly, and a proof screenshot of the route manifest or sitemap output that doesn't expose protected diagnostics.
This work shows SoFlow can make multilingual Webflow routing more reliable by moving the SEO-sensitive decisions to Cloudflare, where they can be versioned, tested, and audited.
Why not just use Webflow's built-in localization settings?
Webflow's page-level settings work for simple cases, but they don't give programmatic control over canonical URLs, sitemap exclusions for pages that aren't ready yet, or redirect logic that has to be consistent across every localized route. Once a site needs those decisions made systematically rather than page-by-page, that logic belongs in a Worker sitting in front of Webflow, not scattered across individual page settings.
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
Localized route behavior was at risk of being spread across Webflow settings, manual links, and untracked redirects, with no single source of truth for how routing should behave.
The site gained a Worker-owned route layer with documented parity checks and safer, consistent handling of localized routes that aren't ready for public traffic yet.
Webflow's page-level settings can't enforce canonical rules, sitemap exclusions, and not-ready redirects consistently across every localized route, or run parity audits against a source of truth. Controlling SEO-sensitive routing at that level of consistency requires logic running at the domain edge, ahead of Webflow.
