Skip to main content
This guide adds a Next.js Middleware that routes AI agent traffic (GPTBot, ClaudeBot, Google-Extended, and similar) to the Publive CDS backend, while human visitors and SEO bots continue to hit your app exactly as before. It ships as part of your normal Next.js build, so there’s no separate infrastructure to stand up.
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 Middleware, that traffic never gets a chance to route to AXP Edge.

Prerequisites

  • A Next.js app deployed on Vercel (App Router or Pages Router; Middleware support in both).
  • Your Publive Edge CDS API key and backend URL (issued per client, contact us if you don’t have these).
  • The Vercel CLI, if you plan to test Middleware locally (see Local development).

How routing works

Middleware runs on every request inside your Next.js app, ahead of routing. It passes _next/ paths through untouched, and delegates every request’s eligibility decision to a shared routeToPublive() module. A request only qualifies for AXP Edge when all of the following are true:
  • The request hostname matches your configured NEXT_PL_EDGE_CLIENT_HOST.
  • The request hasn’t already been routed once (a loop guard header prevents re-routing looped 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, Middleware proxies it to Publive CDS with the required headers. If CDS errors or is unreachable, the request falls through to normal Next.js rendering. Visitors never see an error.

Set up the integration

1

Add the middleware entry point

Create middleware.ts at the app root:
middleware.ts
2

Add the debug logger

Create middleware/debugLog.ts:
middleware/debugLog.ts
3

Add the routing module

Create middleware/routeToPublive.ts with the shared eligibility, header-building, and error-logging logic:
middleware/routeToPublive.ts
4

Configure environment variables

In your Vercel project (Settings → Environment Variables) or .env.local, add:
5

Deploy

Ship the Middleware as part of your normal app build/deploy pipeline, so there’s no separate infrastructure to stand up.

Local development

Skip this section if next dev correctly triggers your Middleware locally. It’s only needed when the app embeds or proxies to another framework (Astro, and similar), where that framework’s local dev server can intercept requests before they reach Next’s own pipeline. In that case, Middleware never runs under plain next dev.
The fix is to develop against the actual Vercel platform locally, using the Vercel CLI, instead of relying on next dev.
1

Add dev/deploy scripts

In package.json:
package.json
  • dev: normal fast local iteration; use for everything that isn’t middleware/routing-specific.
  • dev:edge: runs the real Vercel dev server, which correctly simulates Edge Middleware dispatch, env vars, and routing exactly as production behaves. Use this whenever testing or debugging the Publive routing logic.
  • deploy:preview: pushes a preview deployment without touching production.
  • deploy: ships to production.
2

One-time setup per project, per machine

3

Run the edge dev server

This starts a local server that behaves like the real Vercel edge network. Middleware runs on every matched request, exactly as it will in production.

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: simulate a CDS failure and confirm the request falls back to normal Next.js rendering instead of erroring.
Test with:

Troubleshooting

If verification doesn’t behave as expected, add NEXT_PL_EDGE_DEBUG=1 to .env.local (local) or the platform’s env var settings (deployed), then restart/redeploy. Watch the terminal (next dev / vercel dev) or the platform’s log viewer (Vercel → Logs) while sending a test request. A healthy run logs entryeligibility-check (botMatch: true) → fetching-cdscds-responsesuccess:returning-cds-responsemiddleware:serving-cds-response. Whichever line the chain stops at tells you what to fix: Remove or unset NEXT_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 Cloudflare

Not on Vercel? Use the Cloudflare Worker-based guide instead.
Last modified on August 10, 2026