Next-generation Global CDN
Next-generation GCDN with bot protection
Pantheon's next-generation GCDN introduces built-in bot protection. Learn what's included, how to migrate, and what to expect.
Pantheon's next-generation GCDN provides the same caching and content delivery you rely on today, plus new security features built into the CDN layer.
If your site uses Advanced Global CDN (AGCDN), do not upgrade to the next-generation GCDN yet. AGCDN compatibility with the next-generation GCDN is rolling out in waves. Don't start any upgrade work until you hear from Pantheon Support or your Account Team confirming your site is compatible. We'll reach out directly once your site is ready.
What's Included
Bot Protection
Bot protection is enabled by default on all migrated sites. There is no additional configuration or cost required.
- Automated bot detection and scoring — Incoming traffic is automatically evaluated and scored. Requests identified as malicious receive managed challenges.
- Verified bot identification — Legitimate bots (such as Googlebot, Bingbot, and other search engine crawlers) are recognized and allowed through automatically. Unverified malicious bots are challenged.
Bot Bypass Tokens
If your site relies on automation that is not on the verified bot list, such as uptime monitors, CI/CD tools, feed importers, or custom API clients, bot protection may challenge or block it. You can exempt your own automation by generating a bot bypass token and sending it with your requests.
1. Install the plugin and generate your site's token:
Use --format=json if you're wiring this into CI or a monitoring config. The command prints two tokens for your site — a current token and a next token — each with its Valid From date, Expires date, and the header name to use. You must have access to the site in Pantheon to generate its tokens. The site argument accepts a name or UUID; one token pair covers every environment (dev, test, live, and multidevs).
2. Add the current token to your automation as an HTTP request header:
For example, configure your uptime monitor or CI job to send this custom header on every request to your site.
Requests that carry a valid token skip the standard challenge applied to automated traffic. Targeted protections, rate limiting, the managed WAF, and other platform-level security rules still apply to every request, with or without a token.
Keep in mind:
- Tokens are valid for 6 months, and new tokens are issued every month. Each run of the command returns the current token plus a next token that starts 3 months later; both are accepted during that overlap. If you run the command again in a later month, you'll see different values. That is expected: tokens you already deployed keep working until their Expires date and don't need replacing. Switch your automation to the next token on or after its Valid From date, and re-run the command before the token you're using expires.
- Treat the token like a credential. Send it only from servers and services you control. Never expose it in client-side code, public repositories, or logs. If a token is leaked, contact Pantheon support to revoke it; a replacement token becomes available at the start of the following month.
- A missing token gets normal bot evaluation — no penalty. An incorrect token is rejected with a 403 on every request, so if your automation starts failing, check the header value first.
- Verified bots (such as Googlebot and Bingbot) are allowed through automatically and do not need a token.
After migrating to the next-generation GCDN, monitor your automated integrations (CI/CD tools, feed importers, monitoring services, API clients) to ensure they are not being blocked. If a service stops working, generate a bot bypass token and add it to that service's requests as described above. If the bypass token doesn't cover your situation, contact Pantheon support to request an exception.
User-Agent bypass
Some tools can't send a custom request header, so they can't use a bot bypass token. Hosted uptime monitors, SEO scanners, accessibility scanners, and partner integrations often let you see or set their User-Agent but not add a header. You can exempt these tools by their exact User-Agent string, one domain at a time.
Requests whose User-Agent header exactly matches one of a domain's entries skip the standard challenge for automated traffic on that domain. Targeted protections, rate limiting, the managed WAF, and other platform-level security rules still apply to every request.
If your automation can send a request header, use a bot bypass token instead. A token is a secret; a User-Agent is not.
-
Find the exact User-Agent your tool sends. Check the tool's documentation or settings, or ask its vendor. If the tool lets you set its User-Agent, choose a distinctive string that identifies it, for example
ExampleMonitor/2.1 (+https://example.com/monitor). -
Install the plugin and add the entry to the domain the tool requests:
If the plugin is already installed, update it with
terminus gcdn:update. Use the environment the domain is connected to, usuallylive. Quote the User-Agent so your shell passes it as one value. The command prints the domain's entries after the change. Changes take effect within a few minutes. -
List and remove entries:
Without
--hostname,listshows the entries of every custom domain of the environment. Use--format=jsonfor machine-readable output. To remove an entry, pass the stored value exactly aslistshows it.
Keep in mind:
-
Matching is exact and case-sensitive, against the full User-Agent string, including any version number. A partial string doesn't match. If a tool changes its User-Agent, for example after an upgrade, add the new string and remove the old one.
-
A User-Agent is not a secret. Any client that sends the same string also skips the challenge on that domain. Prefer a distinctive string that identifies your tool, and remove entries you no longer need.
-
Entries that look like a web browser's User-Agent are refused by default, because any bot imitating that browser would also skip the challenge. If you are sure, run the command again with
--allow-browser-uaand confirm. -
Entries apply to one domain. If a tool requests both
example.comandwww.example.com, add the entry to each. Wildcard domains are not supported. -
Each domain can have up to 8 entries. An entry is 1 to 256 printable ASCII characters, with no double quote or backslash, and no leading or trailing space.
-
The domain must be a verified custom domain served by the next-generation GCDN, and you must have access to the site to manage its entries.
-
Verified bots (such as Googlebot and Bingbot) are allowed through automatically and do not need an entry.
If a command fails, its message says why. The most common cases:
| Message | What to do |
|---|---|
<domain> is not a domain of <site>.<env> | Check the environment. Run terminus domain:list <site>.<env> to see its domains. |
<domain> has not been verified yet | Verify the domain with terminus gcdn:verify <site>.<env> <domain>, then try again. |
<domain> is not served by GCDN | The domain is not on the next-generation GCDN yet. See Eligibility. |
<domain> already has the maximum of 8 User-Agent bypass entries | Remove an entry you no longer need with terminus gcdn:ua-bypass:remove. |
If a tool is still challenged a few minutes after you add its entry, compare the entry with the User-Agent the tool sends now, including the version number and letter case, and check that the entry is on the exact domain the tool requests.
Custom Certificates
Sites using customer-provided TLS certificates are now supported on GCDN. Migration for these sites is owned by our Professional Services team and coordinated through support — open a support ticket to get started.
Platform vanity domains
Organization-owned vanity hostnames (e.g., live-mysite.example-agency.com) are fully supported. Migration for these sites is owned by our Professional Services team and coordinated through support — open a support ticket to get started.
Client Challenges
When the next-generation GCDN identifies a request as potentially automated or malicious, it may present a challenge to the visitor. This is a non-intrusive verification that confirms the visitor is human before allowing access to your site.
Content Converter
Content Converter (Markdown for Agents) is enabled on all new GCDN zones. When a client sends a request with the Accept: text/markdown header, the CDN automatically converts the HTML response to Markdown in real time. This makes it easier for LLMs, AI agents, and other programmatic consumers to process your site's content without needing to parse raw HTML.
To request Markdown from a next-generation GCDN site:
- This is enabled automatically on all next-generation GCDN zones — no action is required.
- Standard browser requests (without the
Accept: text/markdownheader) are not affected and receive normal HTML responses. - The response includes an
x-markdown-tokensheader indicating the estimated token count of the Markdown document.
Caching
Caching behavior is the same as the legacy GCDN. Your existing caching configuration carries over without changes.
- The Pantheon Advanced Page Cache module (Drupal) and plugin (WordPress) work the same way. Granular, surrogate-key-based cache clearing is fully supported.
Cache-Controlheaders set by your application are respected.- Static assets are cached at the edge automatically.
- Tracking parameters (
utm_*,__*) are stripped from cache keys, consistent with legacy GCDN behavior (PANTHEON_STRIPPEDlogic). - Analytics cookies (Google Analytics, HubSpot, etc.) are excluded from cache key generation so they don't fragment your cache.
Eligibility
Next-gen GCDN is available to all sites on the platform except those currently using Advanced Global CDN (AGCDN). AGCDN sites are being made compatible in waves. Until Pantheon confirms your site is ready, do not start the upgrade on an AGCDN site from the dashboard or with Terminus. We'll contact you as soon as your site is ready to upgrade.
Known Limitations
Azure Front Door is not supported in front of the next-generation GCDN
Azure Front Door always sets the outbound TLS SNI to the configured origin hostname and does not provide a way to override SNI independently of the origin Host header. Because of this, requests from Azure Front Door cannot satisfy the SNI and Host header match requirement and receive 403 responses from the GCDN edge. Disabling certificate subject name validation in Azure Front Door does not change the SNI it sends and does not work around this.
Terminus commands experience syntax errors
Next-generation GCDN sites must use Terminus version 4.1.9 or higher when interacting with sites that have the next-generation GCDN enabled. Using older versions of Terminus may result in errors such as [debug] json_decode exception: Syntax error or [error] Pantheon headers missing, which is not quite right..
CNAMEs to Platform Hostnames Not Supported
Custom domains that use a CNAME in their DNS configuration pointing to a Pantheon platform hostname (for example, live-yoursite.pantheonsite.io) are not supported. Custom domains must resolve via A/AAAA records, or — after migration — via the CNAME values for the GCDN edge provided by the dashboard. Sites with a CNAME to a platform hostname will experience interruptions when migrated. See Custom Domains and contact Pantheon Support before migration if affected.