Make sure
PubliveBot/1.0 (+https://axp.thepublive.com/bot) is unblocked on your CDN.Make sure LLM user agents (GPTBot, ClaudeBot, Google-Extended, and similar) are unblocked on your CDN, in
robots.txt, and in any firewall/WAF rules. If one of these layers blocks a bot’s request before it reaches CloudFront’s function associations, that traffic never gets a chance to route to AXP Edge.Prerequisites
- An existing CloudFront distribution serving your website.
- AWS IAM permissions to create CloudFront functions, Lambda functions, IAM roles, cache policies, and to edit distribution behaviors.
- Your Publive Edge CDS API key and backend URL (issued per client, contact support@thepublive.com if you don’t have these).
How routing works
CloudFront splits this integration across two function types, run at two different points in the request lifecycle:- A CloudFront Function (
pl-edge-routing), running on viewer request — a lightweight JS function that decides, per request, whether this looks like agent traffic. It doesn’t call out to Publive; it only tags the request so the right origin gets picked. - A Lambda@Edge function (
pl-edge-origin), running on origin request and origin response — this is what actually fetches from the Publive CDS backend, applies failover if CDS errors, and shapes the response.
- The request hostname matches your configured client host.
- The request hasn’t already been routed once (a loop guard header prevents re-routing looped or failed-over requests).
- The method is
GETorHEAD, and the path isn’t a static asset (.js,.css, images, fonts, and similar are always skipped). - The user-agent matches a known AI agent, or the request carries a preview flag.
Set up the integration
1
Create the Publive CDS origin
Navigation: AWS Console > CloudFront > Distributions > [Your Distribution] > Origins tab
- Click Create origin.
-
Configure the origin:
- Origin domain: your Publive Edge CDS backend URL (for example,
cds.thepublive.com) - Name:
Publive_CDS_Origin
- Origin domain: your Publive Edge CDS backend URL (for example,
- Leave all other fields at their default values.
-
Add custom headers:
- Click Create origin.
[SCREENSHOT: CloudFront → Distributions → Origins → Create origin, showing the Publive_CDS_Origin domain and custom headers]2
Create the viewer request function
Navigation: AWS Console > CloudFront > Functions
- Click Create function.
-
Configure:
- Name:
pl-edge-routing - Runtime:
cloudfront-js-2.0
- Name:
-
Replace the default code with the routing code below.
Before publishing, customize:
YOUR_DEFAULT_ORIGIN— the name of your existing default origin (found in CloudFront > Distributions > [Your Distribution] > Origins tab).TARGETED_PATHS— set tonullto target all HTML pages, or an array of specific paths, for example['/', '/products', '/about'].
viewer-request.js
- Click Save changes > Publish function.
[SCREENSHOT: CloudFront → Functions → pl-edge-routing, showing the published function code]3
Configure the cache policy
Navigation: AWS Console > CloudFront > Distributions > [Your Distribution] > BehaviorsCheck the cache policy currently attached to your behavior. Click Edit on your behavior and look at the Cache key and origin requests section to identify your scenario:
- Scenario A (Legacy): Legacy cache settings is selected — no policy-name dropdown, just inline TTL and header settings.
- Scenario B (Custom policy): Cache policy is selected, with a policy name your team created (not an AWS-provided policy).
- Scenario C (Managed policy): Cache policy is selected with an AWS-provided name like
CachingOptimized,CachingDisabled, orCachingOptimizedForUncompressedObjects— these cannot be edited directly.
- Under Cache key and origin requests, confirm Legacy cache settings is selected.
-
Add
x-pl-urlandx-pl-origin-choiceto the Headers allow list:- Select Include the following headers from the dropdown.
- Add
x-pl-urlandx-pl-origin-choice.
[SCREENSHOT: Legacy cache settings — Headers allow list with x-pl-url and x-pl-origin-choice added]If you already have All selected in the Headers dropdown, skip this step — all headers are automatically forwarded to the origin.
-
Check Object caching:
- If set to Customize, set Minimum TTL to
0— recommended. If your current Minimum TTL is already very short, you may not need to change it. - If set to Use origin cache headers, no change needed.
- If set to Customize, set Minimum TTL to
- Click Save changes.
- Click your existing policy, then Edit.
-
Set Minimum TTL to
0— recommended. If your current Minimum TTL is already very short, you may not need to change it.[SCREENSHOT: Cache policy TTL settings — generic AWS view, reusable as a layout reference] -
Under Cache key settings > Headers, along with your existing inclusions, add
x-pl-urlandx-pl-origin-choice.[SCREENSHOT: Cache policy headers — generic AWS view, reusable as a layout reference] - Click Save changes.
CachingOptimized), you can’t edit it directly — you need a new custom policy that replicates it and adds Publive’s headers.Part 1 — note your current managed cache policy settingsNavigation: AWS Console > CloudFront > Policies > Cache- Find and open the managed cache policy attached to your behavior.
- Note: Minimum TTL, Maximum TTL, Default TTL; headers, cookies, and query strings included in the cache key; compression support (Gzip, Brotli).
- Click Create cache policy.
-
Name:
pl-edge-cache[SCREENSHOT: Cache policy name field — generic AWS view, reusable as a layout reference] -
Replicate all settings noted in Part 1, with these modifications:
- Set Minimum TTL to
0— recommended, unless your current Minimum TTL is already very short. - Under Cache key settings > Headers, include everything the managed policy had, plus
x-pl-urlandx-pl-origin-choice.
- Set Minimum TTL to
- Click Create.
-
Go back to your behavior and associate the new policy:
Navigation: AWS Console > CloudFront > Distributions > [Your Distribution] > Behaviors
- Edit your behavior.
- Under Cache key and origin requests, select Cache policy.
- Choose
pl-edge-cachefrom the dropdown. - Click Save changes.
4
Create the Lambda@Edge function (origin request and response)
Create the functionNavigation: AWS Console > LambdaUpdate the execution role’s trust policyThe auto-created role only trusts Replace
- Click Create function.
- Select Author from scratch.
- Configure:
- Function name:
pl-edge-origin - Leave all other fields at their default values.
- Function name:
- Click Create function.
- In the code editor, replace the default code with the origin-request/origin-response code below.
- Click Deploy to save the code.
- Note the execution role name shown under Configuration > Permissions (for example,
pl-edge-origin-role-xxxxx) — you need this in the next two steps.
origin-request-response.js
The sample above shows the routing and header-injection contract explicitly, but production failover on CloudFront typically uses a CloudFront origin group (primary: Publive CDS, secondary: your origin) configured on the distribution, rather than a second fetch performed inline in Lambda@Edge — Lambda@Edge cannot make outbound network calls of its own in the origin-response phase in all runtimes. Confirm the failover mechanism with your Publive representative before going live; the origin-group approach is what the Verify steps below assume.
lambda.amazonaws.com. For Lambda@Edge, you must also add edgelambda.amazonaws.com.Navigation: AWS Console > IAM > Roles > [your role from the previous step] > Trust relationships tab- Click Edit trust policy.
- Replace the policy with:
trust-policy.json
- Click Update policy.
AWSLambdaBasicExecutionRole policy configured for regular Lambda, which has the wrong region and log-group name for Lambda@Edge.Navigation: AWS Console > IAM > Roles > [your role] > Permissions tab > click the attached policy name (for example, AWSLambdaBasicExecutionRole-xxxx)- Click Edit.
- Replace the policy with:
cloudwatch-policy.json
ACCOUNT_ID with your AWS account ID (top-right corner of the AWS Console) and FUNCTION_NAME with your Lambda function’s name (for example, pl-edge-origin).- Click Save changes.
- On the function page, click Actions (top right) > Publish new version.
- Add a description.
- Click Publish.
- Copy the Function ARN — you need it in the next step.
[SCREENSHOT: Lambda — publish new version dialog]
[SCREENSHOT: Lambda — versioned Function ARN shown on the function page]5
Associate the functions and cache policy with the behavior
Navigation: AWS Console > CloudFront > Distributions > [Your Distribution] > Behaviors
- Edit your behavior.
-
If you created a new cache policy in the previous step (Scenario C), set Cache policy to
pl-edge-cache. -
Under Function associations, configure:
- Click Save changes.
[SCREENSHOT: Cache policy dropdown on the behavior, set to pl-edge-cache]
[SCREENSHOT: Function associations — Viewer request / Origin request / Origin response set to Publive's functions]Allow AXP Edge through firewall rules (optional)
If your CDN uses a WAF or Bot Manager:- Allowlist the
PubliveBot/1.0 (+https://axp.thepublive.com/bot)user agent so the AXP Edge service can fetch your origin content during failover and cache-warming. - If your firewall requires additional verification beyond user agent, generate a secret (for example,
openssl rand -hex 32) and:- Add
x-pl-fetcher-keywith the secret to the Publive CDS origin’s custom headers (Step 1). - Add a WAF or Bot Manager rule allowing requests where
x-pl-fetcher-keymatches the same secret.
- Add
- AXP Edge forwards this header as-is — you own the full key lifecycle.
Verify
1. Test bot traffic (should be optimized) Simulate an AI bot request using an agentic user-agent:x-pl-request-id header, confirming the request was routed through AXP Edge:
x-pl-request-id header. Page content and response time should be identical to before enabling AXP Edge.
3. How to differentiate between the two scenarios
You can also check routing status in the AXP dashboard: Brand Configuration > Integrations > CDN.
[SCREENSHOT: AXP dashboard — CDN integration status showing "verified" for the CloudFront connection]
4. Verify logs are flowing correctly
CloudFront Function logs (pl-edge-routing)
Navigation: AWS Console > CloudWatch > Log groups (in us-east-1, or the region where your CloudFront distribution is configured)
- Look for a log group named
/aws/cloudfront/function/pl-edge-routing. - Open the latest log stream.
- For agentic requests, expect entries such as:
Routing to Publive CDS origin for userAgent: ChatGPT-User
- For non-agentic requests, expect:
Routing to Default origin for userAgent: ...
pl-edge-origin)
Navigation: AWS Console > CloudWatch > Log groups (confirm you’re in the correct region)
- Look for a log group named
/aws/lambda/us-east-1.pl-edge-origin. - Open the latest log stream.
- For agentic requests, expect entries such as:
Calling Publive CDS Origin for agentic requests— primary pathFailover Triggered for agentic requests— origin-response failover detection
Troubleshooting
Rollback
The Lambda@Edge function (pl-edge-origin) is associated with the origin request and origin response events of your CloudFront behavior. Because it runs inline on every request passing through that behavior — both human and agentic — a Lambda@Edge outage will impact all live traffic, not just agentic requests. If you detect a Lambda@Edge outage, remove the function associations immediately to restore normal traffic flow to your default origin.
How to detect a Lambda@Edge outage
- AWS Service Health Dashboard — check for active incidents affecting Amazon CloudFront or AWS Lambda.
- Lambda@Edge errors — AWS Console > CloudFront > Monitoring > [Your Distribution] > Lambda@Edge errors tab; check the Execution errors graph.
- Click Edit on your behavior.
-
Under Function associations, set the following to No association:
- Click Save changes.
- Wait for the distribution to finish deploying (status changes from Deploying to the last-modified date, typically within a few minutes).
- Click Edit on your behavior.
-
Under Function associations, restore:
- Click Save changes.
-
Wait for the distribution to finish deploying, then verify agentic requests return the
x-pl-request-idheader as described in Verify.
Next steps
AXP Edge dashboard
Monitor agent traffic and manage optimization rules.
Deploy on Cloudflare
Site behind Cloudflare instead of CloudFront? Use the Worker-based guide.