Step 1 of 6

The problem: two domains, one brand.

Before writing code, get clear on what a reverse proxy actually does — and why the obvious alternatives don't quite work.

The scenario

You own two web properties:

Primary: a marketing site on Webflow (e.g. brand.webflow.io).
Secondary: a legacy app or blog on its own host (e.g. legacy.example.com).

You want both to live under one canonical host: www.example.com.

Why not just 301 redirect?

A 301 from legacy.example.com/blog/x to www.example.com/blog/x only works if the canonical host can actually serve that page. If Webflow doesn't host your blog, you'd be redirecting users to a 404. You need the blog content to keep coming from the legacy origin — but appear under the canonical host.

Why not just DNS / CNAME?

DNS routes a hostname to one origin. You can't say "use Webflow for /, and the legacy box for /blog". A reverse proxy can.

What a reverse proxy does

// pseudo-code
async function handle(request) {
  const url = new URL(request.url);

  // 1. pick an origin based on path
  const origin = url.pathname.startsWith('/blog')
    ? 'https://legacy.example.com'
    : 'https://brand.webflow.io';

  // 2. fetch the upstream response
  const upstream = await fetch(origin + url.pathname + url.search, request);

  // 3. rewrite anything that leaks the upstream host
  return rewriteCanonicalLinks(upstream, url.host);
}

The Worker sits between the user and the two origins. From the user's perspective, there's only one site. From the origins' perspective, they're answering normal requests.

What we'll build next

The next step picks a canonical host, defines the two origins, and writes the first routing rules. You'll be able to play with them in a live simulator.