Serve Webflow landing pages + blog, and route all other paths to WordPress, all under the same domain

For teams using AWS heavily, CloudFront + Lambda@Edge is one of the most scalable architectures for mixing Webflow and WordPress under a single domain. You can selectively route traffic to Webflow for marketing pages (e.g., landing + blog) while keeping your WordPress backend running on EC2, Lightsail, WP Engine, or any hosting provider.

This guide covers path routing, origin config, cache behavior, SSL, and a production Lambda@Edge function.

---

Architecture Overview

            User
             ↓
         CloudFront
             ↓
   Lambda@Edge Viewer Request
             ↓
        Origin Decision
      ├── Webflow origin (marketing)
      └── WordPress origin (app/dynamic)
             ↓
      CloudFront Response → User

CloudFront acts as your CDN + SSL endpoint. Lambda@Edge injects routing logic before CloudFront decides which origin to fetch.

---

Why Use CloudFront + Lambda@Edge?

• Global CDN + edge compute in one layer

• AWS native (IAM, monitoring, logs in CloudWatch)

• Very low latency routing

• Powerful origin selection via origin-request phase

• No servers to maintain

• Handles SSL automatically on your domain

Perfect for enterprise setups.

---

Prerequisites

• A registered domain in Route53 (or any DNS provider)

• CloudFront distribution created

• Two origins configured:

  Origin 1 — Webflow

    your-site.webflow.io
  

  Origin 2 — WordPress

    wordpress.example.com
  

  Or an EC2 load balancer:

    my-wp-alb-123456.us-east-1.elb.amazonaws.com
  

• Lambda@Edge function deployed in us-east-1 (mandatory)

---

Routing Rules

Webflow:

• /

• /blog

• /blog/*

WordPress:

• Everything else:

  • /shop

  • /account

  • /wp-admin

  • /products/*

  • /custom-pages/*

  • etc.

---

Create the Lambda@Edge Function (Viewer Request)

You must deploy this Lambda in us-east-1.

Go to Lambda → Create Function → Author from scratch
Runtime: Node.js 18

Use this code:

'use strict';

exports.handler = async (event) => {
  const request = event.Records[0].cf.request;
  const uri = request.uri;

  // Define the paths that should route to Webflow
  const isWebflow =
      uri === "/" ||
      uri === "/blog" ||
      uri === "/blog/" ||
      uri.startsWith("/blog/");

  // Choose origin depending on path
  if (isWebflow) {
    request.origin = {
      custom: {
        domainName: "your-site.webflow.io",
        port: 443,
        protocol: "https",
        readTimeout: 30,
        keepaliveTimeout: 5,
        sslProtocols: ["TLSv1.2"],
        customHeaders: {}
      }
    };

    request.headers['host'] = [{
      key: 'host',
      value: 'your-site.webflow.io'
    }];
  } else {
    request.origin = {
      custom: {
        domainName: "your-wordpress-origin.com",
        port: 443,
        protocol: "https",
        readTimeout: 30,
        keepaliveTimeout: 5,
        sslProtocols: ["TLSv1.2"],
        customHeaders: {}
      }
    };

    request.headers['host'] = [{
      key: 'host',
      value: 'your-wordpress-origin.com'
    }];
  }

  return request;
};

---

Attach the Lambda to CloudFront

Go to your CloudFront distribution:

1. Behaviors → Default Behavior

2. Add Lambda function to:
   Viewer Request

3. Set version (Lambda@Edge requires a published version)

4. Save and deploy

Propagation will take 5–10 minutes globally.

---

CloudFront Behavior Settings

Keep one behavior (no need for multiple paths).
Lambda@Edge handles routing.

Recommended settings:

This ensures WordPress logins and sessions work correctly.

---

Handling SSL

CloudFront handles SSL termination at the edge.

Steps:

1. Open ACM (us-east-1)

2. Request a certificate for:

    example.com
    www.example.com
   

3. Attach the certificate in CloudFront → Distribution Settings

No SSL changes are needed on Webflow or WordPress origins.

---

Fixing Webflow Absolute URLs

Webflow sometimes returns absolute URLs:

https://your-site.webflow.io/images/logo.png

You can rewrite these using CloudFront Function (lightweight) or by enabling proxy mode in Webflow.
Example CloudFront Function (optional):

function handler(event) {
  var response = event.response;
  var body = response.body;

  if (body) {
    response.body = body.replace(/https:\/\/your-site\.webflow\.io/g, "https://example.com");
  }

  return response;
}

Attach this to the Origin Response event.

---

Caching Strategy

Webflow

Safe to aggressively cache:

• TTL: 1 day+

• Compression: on

WordPress

Dynamic:

• Bypass cache for:

  • /wp-admin

  • /account

  • /cart

  • logged-in cookies

CloudFront handles this automatically when you forward cookies.

---

Testing the Proxy

Webflow landing page

curl -I https://example.com/

Webflow blog

curl -I https://example.com/blog/my-post

WordPress page

curl -I https://example.com/products/widget

Look at via, server, or custom headers from each origin.

---

Common Pitfalls & Fixes

1. WordPress infinite login redirects

Fix: forward cookies + headers in default behavior.

2. CloudFront caching issues

Fix: set "Cache Policy → CachingDisabled" for dynamic content if needed.

3. Lambda@Edge deploy errors

Lambda must be in us-east-1.
Publish a version before attaching.

4. Redirect loops

Disable forced HTTPS plugins on WordPress, CloudFront already enforces SSL.

---

Conclusion

CloudFront + Lambda@Edge gives you:

• A globally distributed CDN

• Fully controlled origin routing logic

• Automatic SSL

• High-speed hybrid Webflow + WordPress hosting

• Serverless, zero-maintenance architecture

This is the cleanest AWS-native approach to serving Webflow marketing pages and WordPress application logic under a single domain, at enterprise traffic scale.