Pantheon Global CDN on Cloudflare Is Now the Default for New Sites. What Existing Sites Should Test

Since September 10, 2026, every new site on Pantheon is created on the next-generation Pantheon Global CDN, which is built on Cloudflare. Existing sites stay on the legacy Pantheon Global CDN until someone starts the migration. Pantheon has not announced a deadline for that move.

The change matters most to agencies that run many client sites on Pantheon. New builds now get bot scoring and challenges by default, plus a feature that serves Markdown to clients that ask for it. Older sites can move through a dashboard banner or the Terminus command line. This piece walks through what changes, what stays the same, what to test on a WordPress or Drupal site before moving it, and how to start the migration.

The short version: caching works the same way, and Pantheon says no application code changes are needed. The work sits in DNS, in any automation that hits the site, and in a few domain setups Pantheon does not support. Check those three things first and most migrations should be routine. Sites on Advanced Global CDN (AGCDN) should wait for Pantheon Support.

What Pantheon announced, and when

Pantheon’s September 10 release note says new sites now provision on the next-generation Pantheon Global CDN "powered by Cloudflare, instead of the legacy Global CDN." The same note says existing sites "are not affected and remain eligible for migration." AGCDN customers are not affected.

The default switch came after a short public rollout. Here is the sequence, from Pantheon’s own pages.

The beta announcement had targeted general availability for Q2 2026. It arrived on July 15, per the GA release note. The beta post also said AGCDN migration was planned for the second half of 2026.

What the legacy CDN runs on is stated in Pantheon’s Terminus plugin. Its README says the upgrade command "migrates the site from Fastly to GCDN." For background on the old provider, see our explainer on Fastly.

What changes on the next-gen Pantheon Global CDN

Pantheon’s next-generation GCDN guide (last reviewed September 28, 2026) lists what is included. The main items, and what each one means for an agency:

The GA note adds two items that were blocked during beta. Sites with Multizone Failover can now migrate and keep regional failover. Organization-owned vanity hostnames are "fully supported."

Bot protection and bypass tokens

Bot protection is the headline change in the new Pantheon Global CDN. The guide says it is enabled by default on all migrated sites at no additional cost. Incoming traffic is scored. Known crawlers such as Googlebot and Bingbot are allowed through. Requests that look automated or malicious get a challenge instead of the page.

That is useful for sites that pay for bot traffic in server load. It is also where most migration surprises will come from. Any automation that is not on the verified bot list can be challenged. Pantheon names four examples: uptime monitors, CI/CD pipelines, feed importers and custom API clients.

The fix is a bypass token. According to the bypass token release note, tokens work like this:

• Header: the token goes in an x-pantheon-bot-bypass request header.
• Scope: one site, all of its environments.
• Lifetime: six months. Terminus returns a current token and a next token, and both are accepted during a three-month overlap.
• Rotation: Pantheon says to re-run the command quarterly to get the next pair.
• Wrong token: the request is rejected with a 403.

A bypass token skips the bot challenge only. The release note says "targeted protections, rate limiting, and the managed WAF still apply to every request." Pantheon also says to treat the token as a credential and send it only from servers you control. If one leaks, support can revoke it. Our piece on Pantheon Secrets for WordPress covers one way to keep tokens like this out of the codebase.

The Content Converter serves Markdown to agents

The guide describes a feature called Content Converter, also labeled "Markdown for Agents." When a client sends a request with an Accept: text/markdown header, the CDN converts the HTML response to Markdown. The response carries an x-markdown-tokens header with an estimated token count. Normal browser requests still get HTML.

The guide says the converter is enabled on all new GCDN zones. It does not say whether it can be switched off per site. For clients who have views on AI access to their content, that is a question to put to Pantheon Support before migrating. Our coverage of Cloudflare’s crawler registry gives more context on how Cloudflare classifies automated traffic.

Caching, headers and purge

Pantheon’s position is that caching on the Pantheon Global CDN does not change. The guide says the Pantheon Advanced Page Cache module for Drupal and plugin for WordPress "work the same way." Surrogate-key cache clearing is supported. Cache-Control headers set by the application are respected. Static assets are cached automatically.

Two cache-key rules are spelled out. Tracking parameters starting with utm_ or __ are stripped from cache keys. Analytics cookies, such as those from Google Analytics and HubSpot, are excluded from cache key generation. The utm and double-underscore rule matches what Pantheon’s legacy caching documentation already described.

Several things are not documented for the next-gen CDN as of September 29, 2026:

• HTTP/3: the guide, the FAQ and the release notes do not mention HTTP/3 or QUIC.
• Purge timing: no figures are given for how fast a cache clear propagates.
• Header changes: no list of added or removed response headers is published.
• Session cookies: the legacy rules for SESS, NO_CACHE and STYXKEY cookies are not restated on the next-gen page.

Pantheon says caching behavior is identical, so the legacy rules should hold. But none of these points is written down for the new CDN, so treat them as test items rather than assumptions. Our CDN explainer covers how cache keys and purges work in general.

WAF, traffic metrics and Cloudflare in front

The guide mentions a managed WAF and rate limiting as platform-level protections. It does not describe customer-editable WAF rules. For teams that already run their own Cloudflare zone, Pantheon supports Cloudflare’s Orange-to-Orange (O2O) setup. That keeps the existing zone, with its WAF rules and Workers, in front of the Pantheon Global CDN.

O2O requires the Terminus plugin; the dashboard migration does not support it. The steps include a DNS-only DCV delegation CNAME for certificates. The guide says that record must stay in place permanently for certificate renewal.

A different third-party CDN in front of Pantheon is also supported, with one strict rule. The TLS SNI value must match the HTTP Host header on every request. Pantheon says this prevents domain fronting and cannot be disabled. Azure Front Door is listed as not supported, because it sets the outbound SNI to the origin hostname with no override. Requests from it receive HTTP 403 responses.

Sites migrated to the new Pantheon Global CDN also get more detail in site metrics. Pantheon’s traffic documentation says Pages Served filtering and a Total Requests breakdown are available only on next-gen sites. The breakdown shows the split between Pages Served and uncounted requests, such as known bots.

Domains, DNS and certificates

DNS is where a Pantheon Global CDN migration can go wrong. The guide gives three rules.

First, custom domains must use A/AAAA records. A custom domain that uses a CNAME pointing at a Pantheon platform hostname (*.pantheonsite.io) is not supported. Pantheon says sites set up that way "experience interruptions upon migration."

Second, update DNS promptly. Pantheon’s wording: "be prepared to update your DNS records as soon as possible after starting the migration." Waiting risks what the guide calls inconsistent behavior.

Third, starting the upgrade moves the platform hostnames at once. The guide says it "automatically moves your site’s platform hostnames (*.pantheonsite.io) to the next-generation GCDN." Dev and Test URLs change CDNs before the live domain does.

Certificates are issued through DNS TXT record validation by default, per the Global CDN FAQ. That allows certificates to be provisioned before traffic moves. HTTP-01 validation is available through the Terminus plugin. The legacy CDN used Let’s Encrypt certificates, according to Pantheon’s HTTPS guide; the next-gen pages do not name a certificate authority.

What agencies should test on WordPress and Drupal

Pantheon’s FAQ says the migration is "transparent to your Drupal or WordPress application" and designed to avoid downtime. The risk is in what surrounds the application. A pre-migration checklist for the Pantheon Global CDN, built from the documented changes:

1. Inventory custom domains. Confirm every domain uses A/AAAA records, not a CNAME to a platform hostname.
2. List inbound automation. Uptime monitors, CI jobs, feed importers, search indexers and payment or CRM webhooks. Anything not on the verified bot list may be challenged.
3. Issue bypass tokens. Add the header to each trusted service and set a quarterly rotation reminder.
4. Test on Dev first. Platform hostnames move when the upgrade starts, so the Dev URL is the first place to see challenges.
5. Check logged-in paths. Log in, submit forms, run checkout or donation flows, and confirm pages are not served from cache.
6. Compare cache behavior. Check Cache-Control and surrogate-key purges from Advanced Page Cache after a content edit.
7. Record HTTP versions and headers. Capture response headers before and after, since Pantheon has not published a list of changes.

For WordPress, pay attention to WPML language cookies and WooCommerce or donation flows. For Drupal, include Feeds imports, migrations run from outside Pantheon and any decoupled front end that calls the site’s APIs. Our WP Engine vs Pantheon comparison and Pantheon vs Acquia comparison were written before this change. Their CDN sections describe the legacy setup.

How to migrate an existing site to the Pantheon Global CDN

Moving an existing site to the next-gen Pantheon Global CDN has two self-service paths, plus a support path for special cases.

Dashboard. Eligible sites show a next-generation GCDN banner on the site dashboard. The GA note describes the flow: click the banner, complete the guided migration, then update DNS records. Sites that do not see the banner are either on AGCDN or are Front-End Sites, per the FAQ.

Terminus. The guide requires Terminus 4.1.9 or higher. Older versions produce a json_decode exception: Syntax error or missing Pantheon headers. Install the plugin with terminus self:plugin:install pantheon-systems/terminus-gcdn-plugin. The README lists these commands:

terminus gcdn:upgrade <site>                    # move all environments off the legacy CDN
terminus gcdn:dns <site>.live                   # show TXT records for ownership and certificates
terminus gcdn:verify <site>.live example.com    # verify a domain after DNS propagates
terminus gcdn:o2o <site>.live                   # record sets for Cloudflare Orange-to-Orange

Support. Sites with customer-provided TLS certificates or organization vanity hostnames need Professional Services. Open a support ticket to start. AGCDN sites should not be upgraded until Pantheon Support confirms compatibility. The guide says AGCDN support is rolling out in waves. If an AGCDN upgrade was already started, do not change DNS; contact support.

Pantheon has not published a retirement date for the legacy Pantheon Global CDN. Until it does, the timing of each move is the agency’s call.

Frequently Asked Questions