Skip to main content

​
Test your setup

Every check below sends a GET request. Profound’s contract covers GET only, so use curl -sD - -o /dev/null rather than curl -I, which sends HEAD. A HEAD response may come from your origin or from a handler that omits the body, and tells you nothing about routing.
1

Assistant traffic should reach Profound

Look for a UUID in x-concierge-request-id and x-concierge-bot-kind: chatgpt-user. Together they prove your CDN routed the request to Profound and Profound recognized the assistant. They do not prove a rendered page was served: a MISS with x-concierge-failopen: 1 means Profound returned your origin’s live content.
2

Your published test page should be served from Profound

On the page you published during setup, also require x-concierge-cache: HIT and the rendered HTML. Save the body for comparison, and let curl decompress it in case Profound served it gzip-encoded:
If this request is a MISS, check the x-concierge-policy headers as described in Reading the result. Repeating the request does not turn a MISS into a HIT; only publishing a render does.
3

Human traffic should be untouched

Expect no x-concierge-* headers and the same page content as before. Compare latency and cache hit rates with your baseline too: a Worker or a shared cache-policy change can affect them even when routing is unchanged.
4

Search crawlers should be untouched

Also expect no x-concierge-* headers. If this request is routed, see Common problems.
5

Excluded traffic should keep its existing behavior

In staging, send non-GET methods, requests to /api/users, /graphql, authentication, admin, framework resources, and assets, including extensionless endpoints. Use harmless fixture endpoints for methods that could modify data, and nonsecret test values for cookies and authorization headers. All of these must stay on your existing route. On Vercel, also test preview and alternate hosts.
6

Test failure behavior safely

Use staging or an isolated configuration, record the original settings, and restore them after each test.
  • Cloudflare: test an unreachable upstream, a response-header timeout, and one of the configured fallback statuses. Expect origin content with x-concierge-cdn-failover: 1. Redirects, 404, and 429 pass through, and a response that has already started streaming cannot be replaced.
  • CloudFront: test primary connection and response timeouts within the configured budget and the selected status criteria. Expect the fallback origin for configured failures, but not for 401. Send uncached requests, and expect cached fallback responses to persist until their TTL expires even after you restore the primary.
  • Vercel: there is no CDN-level failover. During a Profound outage or after a hard rejection, an assistant can receive an error. Do not expect transparent origin fallback.
After restoring the configuration, wait for propagation and repeat the routing and published-page checks.

​
Run setup verification from the dashboard

The Profound dashboard can test your routing for you. It sends a request with each of the nine supported assistant User-Agent values to a URL on your registered host, from outside your network, and reports which ones your CDN routed to Profound. These probes carry no credentials and no loop marker, so they look like real assistant traffic to your CDN. An assistant counts as routed only when its response carries a valid request ID and the matching bot kind. A MISS, a paused domain, a redirect, or a non-200 status can still confirm routing; page health is reported separately. Make sure the URL you test is on your public-page allowlist, or every assistant will correctly show as not routed.
Setup verification is a live observation of one URL at one moment. It confirms that your CDN rule fires for each assistant. It does not verify domain ownership, and it is not a substitute for checking your published test page by hand.

​
Response header reference

​
Reading the result

​
Error responses

Profound only falls back to your origin after a request is authenticated and valid. Configuration errors are rejected rather than proxied. Cloudflare’s Worker masks its configured rejection statuses by serving your origin, and CloudFront masks 400 and 403 but not 401. Vercel has no retry. When an origin page appears where you expected a rejection, inspect your CDN’s diagnostics.

​
Common problems

Your User-Agent pattern matches something outside the supported token list. Compare it with the pattern in your setup guide and the supported assistants. Search crawlers such as Googlebot must keep reaching your origin.
CloudFront replaces the viewer User-Agent with Amazon CloudFront on origin requests unless an origin request policy forwards it. Profound then has nothing to classify. Use the narrow custom origin request policy in the CloudFront guide. Avoid AllViewer, which also forwards the viewer Host and can break the connection to Profound. Add User-Agent to the origin request policy, not the cache key.
The winning rule’s allowed-assistant list excludes it. The response shows x-concierge-policy: off together with the rule ID. Add the assistant to the list, or clear the list so the rule inherits the domain default.
Some cache layer stores HTML without separating assistant and human responses, or without separating hosts, paths, and query strings.On CloudFront, include x-concierge-route in the cache key, keep Minimum TTL at 0, and check host and query variants. On Cloudflare, verify that the Worker’s upstream call bypasses cache; User-Agent keying alone cannot separate page identities because every page uses the same upstream URL. On Vercel, inspect the project’s external-rewrite cache settings. On every provider, also check what happens to cached entries after you publish a replacement, unpublish, or pause: a CDN entry can outlive the change in Profound.
Loop protection is failing. Your rule must let requests carrying x-concierge-request pass straight through to your origin. Profound stamps that header on its own origin fetches, and rejects any inbound request that carries it with 400, so a broken exclusion turns into one failed request rather than a loop.On Vercel, this is a missing condition on x-concierge-request with the value ^1$, the marker Profound stamps. Any other regex silently disables the exclusion, because a missing condition with a value only excludes requests whose header matches it.
Query strings are part of the page identity. If your CDN strips them before the origin request, /product?id=a and /product?id=b collapse to /product, and the wrong variant is rendered and served.On CloudFront, include the query strings your pages vary on, or “All”, in the cache policy. An origin request policy can forward extra query strings without keying them, so verify forwarding and cache identity separately.
Read x-concierge-policy and x-concierge-policy-source on the response. No matching rule means off, and warm serves live origin content even when a publication exists. Set the winning rule to serve.Then confirm that a candidate for this exact path and query was reviewed and published. Approval alone does not publish it, and repeated requests do not publish it either. A candidate held as pending stays pending until someone approves, rejects, or publishes it. If the page is published and policy is serve but you still see a MISS, check your CDN caches and your origin’s reachability.
Check WAF rules, bot challenges, deployment protection, and origin allowlists for both incoming assistant traffic and Profound’s origin fetches. Profound does not forward viewer cookies or authorization headers, so protected or session-sensitive pages belong outside this setup. The loop marker is spoofable and must not be used as a firewall or authentication bypass. If your origin needs a way to identify Profound’s fetches, contact Profound support.

​
Turning it off

To stop serving renders without touching your CDN, pause the domain in the Profound dashboard. Every assistant request goes to your origin while your rules, renders, and publications are preserved, and resuming restores them. A pause takes effect in Profound immediately, but responses your CDN has already cached persist until they expire. A pause is not a substitute for CDN-level failover during an outage, because the request still has to reach Profound. To remove the integration, restore the CDN configuration you recorded before setup:
  • Cloudflare: remove the added Worker route or restore its previous binding without removing other Worker logic.
  • CloudFront: restore the previous viewer-request association and policies. Use No association only when there was none before.
  • Vercel: remove only the added route from vercel.json, preserve other routing, and redeploy.
Routing changes take effect after configuration or deployment propagation. Previously cached fallback responses may persist until expiry or your normal invalidation process. Verify original routing and content after rollback. Registered domains, keys, and publications remain in Profound until you remove them.