eCDN Cache Rules and Cache Purge

Where Cache Rules and Cache Purge Are Available

To configure cache rules and purge the cache, in Business Manager, go to Administration | Sites | Embedded CDN Settings, and then select Configure Zone for the zone that you want. Cache rules and the Purge Cache button are available at zone scope for these zone types.

How SCAPI Zones Differ

For SCAPI zones, only cache purge is available, and cache rules aren't exposed. This behavior is intentional.

• SCAPI caching is a platform-managed capability. To prevent changes to SCAPI caching behavior, cache-rule self-service is disabled for these zones.
• SCAPI workers set cache tags automatically when they cache a response. You don't define tags for SCAPI zones yourself.
• The ecom-side (JWA) invalidation flow synchronizes SCAPI cache invalidation.
• You can purge SCAPI zone content by tag or by path.

How eCDN Decides What to Cache

Understanding the caching decision helps you write effective rules.

By default, when no cache rules are configured, eCDN caches by file extension only. Common static extensions (images, JS, CSS, fonts, video, documents, and archives) are cached. eCDN doesn't cache HTML, JSON, XML, or TXT responses by default (except robots.txt). The maximum cacheable object size is 5 GB.

A response is cached only when all of these conditions are true.

• The request method is GET.
• The response has no Set-Cookie header.
• The response has Cache-Control: public with max-age > 0, or a future Expires date. When multiple values are present, the precedence is s-maxage, then max-age, then Expires.

A response isn't cached if any of these conditions are true.

• Cache-Control is private, no-store, no-cache, or max-age=0.
• No Cache-Control header is present.
• A Set-Cookie header is present.
• The request method isn't GET.

Note A cache rule only makes an otherwise-uncacheable content type (HTML or JSON) eligible. The origin header rules still apply.

Best Practices

• Cache HTML and JSON deliberately. Make dynamic content eligible only where the response is genuinely shared across shoppers and safe to cache. Never cache personalized or authenticated responses. Make sure that those responses carry Set-Cookie or Cache-Control: private.
• Use cache tags for coordinated invalidation. Stamp related content with shared tags (for example, by product, category, or content asset) so that you can purge a logical group in one request instead of listing paths.
• Exclude tracking parameters from the cache key (for example, gclid and utm_campaign) to maximize the cache hit ratio.
• Verify caching with the Cf-Cache-Status response header. A value of HIT confirms edge caching. A value of MISS or DYNAMIC indicates that the content wasn't served from cache.
• Test in a sandbox first. ODS Default zones support cache rules and purge, so you can validate rule behavior on a sandbox before you apply it to production.

Troubleshooting

Content isn't caching as expected? Check, in order:

1. Origin headers — is the response sending Cache-Control: public, max-age>0 (or a future Expires)?
2. Set-Cookie — a Set-Cookie header suppresses caching. Remove it for cacheable responses.
3. Request method — only GET is cached.
4. Expression accuracy — does the rule expression actually match the request path/extension?
5. Rule enabled? — confirm the rule's Enabled flag is on.
6. Cf-Cache-Status header — HIT vs MISS/DYNAMIC tells you whether the edge served from cache.