Akamai RSS Feed Caching: TTL, Cache Key and Purge Guide

Short answer: To serve an RSS feed through Akamai, let the origin send the correct content type, a validator and a cache lifetime, then set a short edge time to live of about five minutes in your property rules, remove query strings from the cache key, compress the XML, allow the feed to be fetched by automated clients and purge the feed address when you publish. A feed cached this way stays fast under load, never serves a stale item for long and can be read every few minutes by an auto-poster such as PostRSS without causing trouble at the origin.

An RSS feed is one of the most requested files on a busy site. Readers, search engines, podcast apps, aggregators and auto-posting services all fetch the same small XML document again and again, often every minute or two. If every request reaches the application, the feed becomes a steady load that has nothing to do with real visitors. A content delivery network such as Akamai can answer these requests from its edge servers close to the reader, and it can do so safely if the rules are designed for a document that changes whenever you publish. This guide explains the choices that matter for feeds: lifetime, cache key, validators, compression, purges, security rules and testing. The names of behaviors and options in the Akamai control panel change from time to time, so treat the terms below as a map and check the exact labels in your own configuration.

Why a feed needs its own caching rules

Most properties are tuned for images, scripts and pages. A feed is different in three ways. It is small, so the cost is in the number of requests and not in the bandwidth. It changes at unpredictable moments, because it changes when an editor presses publish. And it is read mostly by software, which does not wait politely and does not send cookies. A rule written for static assets, with a lifetime of a day, would hide new articles for a day. A rule written for dynamic pages, with no caching at all, would pass every request to the origin. The right answer is a short lifetime, a clean cache key and a way to refresh the copy early when something is published.

Let the origin describe the feed first

The edge caches what the origin sends, so start at the origin. The feed should be returned with the RSS content type and a UTF-8 charset, a status of 200, and two validators: an entity tag and a last modified date. With validators the edge can ask the origin whether the document has changed and receive a very small answer when it has not. A cache lifetime sent by the origin gives the edge a safe default, even if the property rule is removed by mistake later.

HTTP/1.1 200 OK
Content-Type: application/rss+xml; charset=UTF-8
Cache-Control: public, max-age=300, s-maxage=300
ETag: "feed-2026-11-09-0740"
Last-Modified: Mon, 09 Nov 2026 05:40:00 GMT
Vary: Accept-Encoding

The header for shared caches takes precedence over the general one at a shared cache, so you can give browsers and readers a different lifetime from the edge. For a feed it is usually sensible to keep both short and equal. If you need to understand how the content type affects tools, read the guide to validating a feed before you auto-post from it.

Choose the edge lifetime

In the property configuration you can tell Akamai how long to keep an object, either by honoring the headers from the origin or by setting a fixed value for a path. For a feed the sensible range is one to ten minutes. Five minutes is a good starting point: a reader who checks the feed sees a new article within five minutes at most, and the origin handles at most one refresh request per edge location for each lifetime period. Consider the other side as well. Auto-posters and aggregators decide when a post goes out from what they see in the feed, so a long lifetime delays every post by the same amount. A news site that wants posts within a minute may choose a lifetime of sixty seconds together with an active purge, while a weekly newsletter can use thirty minutes.

Remove noise from the cache key

The cache key decides whether two requests share one copy. By default the full path and the query string are part of the key, so the addresses /feed/ và /feed/?utm_source=reader become two separate objects, and a tool that adds a random value to every request will never hit the cache at all. Most feeds ignore every query string except a small number of real parameters, such as a category or a page number. Configure the cache key to ignore all query parameters by default and to include only the ones that your feed really uses. Also keep cookies out of the key and strip them from requests for the feed, because a stray cookie that varies per visitor can split the cache into thousands of copies. Normalize the case of the path if your server treats it as the same address.

Compress the XML

An XML feed contains repeated tags and shrinks to a fraction of its size when compressed. Enable compression for the RSS and Atom content types in the delivery configuration, and let the origin send the header that tells caches the response depends on the encoding the client accepts. Compressed responses are cached separately from uncompressed ones, which is correct and expected. Do not compress twice, once at the origin and again at the edge, because a few combinations produce errors in older readers. A short test with a command line client that asks for gzip will show whether the response is encoded once.

Purge when you publish

Waiting for a lifetime to expire is simple, but an active purge is faster. Akamai offers a purge service that can invalidate a URL or a group of objects labeled with a tag. The most reliable pattern is to purge the feed address from the publishing workflow: the content system finishes saving the article, then calls the purge service for the main feed and for the category feed that the article belongs to. An invalidate marks the object as stale and lets the edge revalidate it with the origin, which is gentler than a delete and keeps the validators useful. Keep the credentials for the purge service in a secret store and limit them to the actions you need. If you cannot automate the purge, a lifetime of a few minutes is still enough for most sites.

Serve a stale copy when the origin fails

Feeds are fetched around the clock, and the origin may be down for maintenance or overloaded exactly when a flood of requests arrives. Configure the property to keep serving the last good copy for a limited period if the origin returns an error or does not answer. Readers and auto-posters then see slightly old content instead of an error page, and the next successful refresh restores the normal behavior. Set a limit, for example a few hours, so that a broken origin does not hide the problem forever, and make sure your monitoring still alerts you when the origin fails, because the edge will hide the symptom from outside.

Do not block the readers

Security features are often attached to the same property: rules against automated clients, limits per address, challenges for suspicious requests. A feed is meant to be read by software, so these rules can break real tools. Create an exception for the feed path that allows common feed readers and auto-posting services, but keep a rate limit per address that is generous enough for a legitimate client checking every minute. If the feed is fetched from a data center, a rule that challenges all data center traffic will return a challenge page where the tool expects XML, and the tool will report an invalid feed. If you want to understand what an attacker could do with a feed, see the guide on RSS feed security.

Use one canonical address

Keep one address for the feed and use it everywhere: in the link tags of your pages, in your notes and in your auto-poster. If an older address must keep working, redirect it once with a permanent status to the canonical address instead of serving the same content at several URLs, which splits the cache and confuses tools that remember where an item was seen. Test the redirect from the edge, not only from the origin, because a rule at the edge can change its behavior. Avoid redirects that depend on the user agent, since a tool that is sent to a different address may look like a failure.

Test the result

1. Request the feed twice in a row from the command line and compare the headers. The second response should show a cache hit and an age greater than zero.
2. Request it with a random query string. The response should still come from the same cached object.
3. Publish a test article and purge the feed. The new item should appear within a minute.
4. Request the feed with a compression header and check that the body is encoded once.
5. Fetch it from another network, for example a mobile connection, to make sure that no challenge page is shown.
6. Check the feed in the W3C Feed Validation Service.

Add the check to your routine after every change to the property, because a new version can alter caching in ways that nobody notices until readers complain.

Common mistakes to avoid

• A lifetime measured in hours. New articles stay invisible, and every auto-posted share is late by the same amount.
• Query strings in the key. Each random parameter creates a new object and sends the request to the origin.
• Cookies on the feed. They split the cache and are never needed for a public feed.
• Challenges for automated clients. A challenge page is not XML and breaks readers.
• No purge and no monitoring. Without either, you learn about a problem from your audience.
• Several feed addresses. They multiply cache objects and the places where items are tracked.

How PostRSS works with a feed served through Akamai

PostRSS has been publishing RSS and Atom feeds to social networks since 2014. Paste the address of your feed, connect your accounts and choose how each post is built; PostRSS can check the feed as often as every minute and publishes each new item with its real image and link to the networks you select among its 66 supported networks. A well-cached feed suits this model, because the tool receives a fast, valid answer every time. If you add UTM parameters to the posted links, they are applied to the article links and not to the feed address, so the cache key of the feed is unaffected. See the PostRSS features page for the full list of options and the pricing page for plan limits.

Bài đọc liên quan

• Cloudflare Workers RSS feed
• AWS Lambda RSS feed
• RSS feed validation before you auto-post

The bottom line

Akamai can take nearly all of the load of an RSS feed away from your origin, provided the rules fit the nature of the document. Let the origin send the right type and validators, keep the edge lifetime to a few minutes, remove query strings and cookies from the cache key, compress once, purge when you publish, serve a stale copy for a limited time during failures, allow legitimate automated clients and keep a single canonical address. Test every change and let a tool read the feed as often as it needs, so every new article reaches your audience on social networks quickly.

FAQ

How long should an RSS feed be cached at the edge?

Between one and ten minutes suits most sites. Five minutes is a common starting point, and an active purge on publish makes new items appear almost at once.

Should query strings be part of the cache key for a feed?

Usually not. Ignore them by default and include only parameters your feed really uses, such as a category or page number. Otherwise every random value creates a separate cached object.

Can a security rule break feed readers?

Yes. Rules that challenge automated clients return a page instead of XML, and tools then report an invalid feed. Create an exception for the feed path with a generous rate limit.

Do I need to purge the feed after every article?

It is not required if the lifetime is short, but a purge from the publishing workflow makes new items visible within seconds and keeps auto-posted shares on time.

Can PostRSS read a feed that is served through a CDN?

Yes. PostRSS reads any valid RSS or Atom address that is reachable without a login, whether it is served by the origin or through a CDN.