AEM GraphQL content stays stale after publish: prove which cache owns it

An editor publishes a Content Fragment, sees the update in AEM, and the headless site still serves yesterday's value. A recent Experience League case describes a persisted query remaining stale at the CDN. The operational mistake is treating “published” as the same event as “every cached response replaced.”

Compare one query along its path

Use the same persisted-query path, variables and headers for each probe. Record response body, status, Age, Cache-Control and surrogate cache headers at the public URL and at an origin route available to your operations team. Avoid comparing a GET persisted query with a POST ad hoc GraphQL query: they can have different cache behavior. Adobe's persisted-query documentation explains why GET results can be cached at Dispatcher and CDN layers.

Set a freshness contract

Write down the acceptable delay between publication and customer visibility. Adobe documents browser max-age, CDN s-maxage, stale-while-revalidate and stale-if-error controls for persisted queries. Measure the actual published response headers, then change the supported cache settings at the level that owns the stale response. A shorter TTL can bound staleness, but it also changes cache hit rate and origin load. Test both.

Verify the publishing runbook

Give editors a check using one known fragment and one public persisted-query URL. Record the publication timestamp and first fresh response at the edge. If the business needs near-immediate freshness, assess the supported invalidation path for the deployed CDN and AEM configuration with the platform owner; do not assume that a Dispatcher flush automatically invalidates every GraphQL edge response.

Adovo’s view

Publishing is an intent; freshness is a measured customer experience. Put a time promise on the content boundary and make the edge response observable. Without that, teams repeatedly “fix” Author or Publish while the stale copy sits somewhere else.