Skip to main content
This guide deploys AXP Edge as a Cloudflare Worker that sits in front of your domain. The worker inspects each request’s user-agent; requests from recognized AI agents (GPTBot, ClaudeBot, Google-Extended, and similar) are routed to the Publive CDS backend instead of your origin. Every other request (human visitors and SEO bots) passes through untouched. Use this approach when your site isn’t on Next.js/Vercel, or when you need agent routing live without an application deploy.
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 this Worker, that traffic never gets a chance to route to AXP Edge.

Prerequisites

  • A Cloudflare account with the target domain’s zone already active (orange-clouded DNS or a Worker route you control).
  • Permission to create or edit Workers on that account.
  • 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

The worker makes one decision per request: serve it from AXP Edge, or fall through to your origin. A request only qualifies for AXP Edge when all of the following are true:
  • The request hostname matches your configured PL_EDGE_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 GET or HEAD, 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.
If the request qualifies, the worker fetches the page from CDS and returns it. If CDS errors or is unreachable, the worker automatically fails over to your real origin and tags the response with a failover header. Visitors never see an error. Unlike the Vercel integration, the agent bot list here is fixed in the Worker code (the AGENT_BOTS array) rather than configurable via an environment variable. To add or remove a bot, edit that array directly and redeploy.

Cloudflare’s AI bot defaults (effective September 15, 2026)

For new domains, Cloudflare will block Agent and Training bots by default on ad-monetized pages (announcement), before requests reach this Worker. Most of AGENT_BOTS falls into those two categories.
Check Security → Bots and allow the Agent and Training categories, or this traffic never reaches the Worker. Applies only to new domains after September 15, 2026 on ad-monetized pages; existing zones are unaffected, and it’s an opt-out default.

Set up the integration

1

Create or reuse a Worker

In the Cloudflare dashboard, go to Workers & Pages → Create application → Create Worker. Name it something identifiable, like <PUBLISHER_NAME>-router, and click Deploy to create it with the default code.If a Worker already exists for this domain, merge the code below into it instead of replacing it. Don’t run two competing routers on the same route.
2

Add the worker code

Open the Worker, click Edit code, and replace the default code with:
worker.js
Click Save and deploy.
If you’re merging into an existing Worker, keep this file’s exported functions distinct (rename on collision) and call isEligibleForOptimization / routeToPublive from your existing fetch handler rather than replacing it outright.
3

Configure environment variables

In the Worker, go to Settings → Variables and add:
4

Add a route linking the Worker to the domain

Go to the Worker’s Domains & Routes → Add route, select your domain, and enter the pattern to match (for example, example.com/* or www.example.com/*), then Save.Alternatively, configure the route at the zone level: open the domain in Cloudflare, go to Workers Routes, and add a route pointing to this Worker.

Verify

  • Bot traffic: a request with an AI agent user-agent returns a response with the x-pl-request-id header present, confirming it was served by CDS.
  • Human traffic: a normal browser request shows no CDS header, and content/response time is unchanged.
  • Failover: temporarily break the backend config (or simulate a CDS outage) and confirm the response carries x-pl-fo: 1 and still serves your real origin content.

Troubleshooting

If step verification doesn’t behave as expected, set PL_EDGE_DEBUG=1 in Settings → Variables, redeploy, then watch Worker → Logs (or wrangler tail) while sending a test request:
A healthy run logs entryeligibility-check (botMatch: true) → fetching-cdscds-responsesuccess:returning-cds-response. Whichever line the chain stops at tells you what to fix: Remove or unset PL_EDGE_DEBUG once verified, to avoid noisy step-by-step logs in production. Note that console.error calls (backend errors, missing config, failed fetches) log regardless of this flag. That’s independent, always-on error logging, not affected by the debug toggle.

Next steps

AXP Edge dashboard

Monitor agent traffic and manage optimization rules.

Deploy on Vercel

Integrating a Next.js app on Vercel instead? Use the middleware-based guide.
Last modified on August 10, 2026