---
title: Configure cache headers
slug: dxp/docs/configure-cache-headers
docTags: 
createdAt: 2026-07-30T20:33:07.587Z
---

:::hint{type="info"}
**Note**

Cache headers are the required method for managing cache rules on your website. Configure caching behavior directly in your application; Optimizely does not manage cache rules in Cloudflare CDN on your behalf.
:::

Using the correct cache headers in your application ensures you get the most out of the CDN service, whether you cache static content, text, or HTML. You can use [Last-Modified](https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html), **cache-control** settings, *ETags*, or a combination of these to determine whether content has changed.

## Cache-control

There are many HTTP header settings, but `cache-control` is one of the most important ones because this setting determines how long a cached object should remain cached.

A CDN monitors the cache headers in the response settings:

- `cache-control: no-cache` – The CDN will not cache the content.
- `cache-control: public` –  The CDN caches the content.

:::hint{type="warning"}
**Important**
You must set the `cache-control` to `public`  (not private where only the browser is allowed to cache the content).
:::

Typical values:

- `max-age=$seconds` – Determines the lifespan of an object.
- `must-revalidate` – Tells the cache to follow maximum lifespan information strictly.
- `public` – Can be cached by intermediaries.
- `private` – Can be cached, but only by the browser.

:::hint{type="warning"}
**Caution**
Do not set `cache` to `public` on page requests if the page has private information, such as a cart page in ecommerce.
:::

**Example:** Caching an object for a maximum of 20 minutes (1200 seconds).

```csharp
Cache-Control: public, max-age=1200, must-revalidate
```

## Cache levels for query strings

The default cache layer setting in DXP for query strings is `Standard`, meaning a different resource is delivered each time the query string changes.

## Cache static content

To minimize the trips to the web server, use as long `max-age` as possible, at least for static content. In `StaticFileOptions`, there are specific sections for setting cache headers for static content. You can see an example here:

```csharp
public void Configure(IApplicationBuilder app, IWebHostEnvironment env) {
  ...

  const string cacheMaxAge = "604800";
  app.UseStaticFiles(new StaticFileOptions {
    OnPrepareResponse = ctx => {
      // using Microsoft.AspNetCore.Http;
      ctx.Context.Response.Headers.Append("Cache-Control", $ "public, max-age={cacheMaxAge}");
    }
  });

  ...
}
```

## Override SetCachePolicy

If you use `MaxAge`, this sets `cache-control` to `public`. The following example sets the `max-age` using a `TimeSpan` of one hour, which is converted automatically to 3600 seconds.

```csharp
public class StartPageController: PageControllerBase {
  public ActionResult Index(StartPage currentPage) {
    Response.GetTypedHeaders().CacheControl.Public = true;
    Response.GetTypedHeaders().CacheControl.MaxAge = TimeSpan.FromHours(1);
    return View(currentPage);
  }
}
```

If you use `Expires`, this sets `cache-control` to `public`,  and `Expires` to your selected date and time.

```csharp
public class StartPageController: PageControllerBase {
  public ActionResult Index(StartPage currentPage) {
    Response.Cache.SetCacheability(HttpCacheability.Public);
    Response.GetTypedHeaders().Expires = DateTime.Now.AddHours(1);
    return View(currentPage);
  }
}
```

## Use ETags

The `ETag` (entity tag) is a part of the HTTP protocol determining cache validation and is best used for *static* content, such as files, uploaded assets, and pages without output caching. You should not use ETags for requests to resources composed from *dynamic* content objects such as a landing page.

You can combine `ETag`s with other settings. You can use `Cache-Control max-age` and `ETag` to refine cache management and optimize performance. You can also use `ETag` only if you have specific caching control requirements.

**Recommendations**

- **Static deployed files such as CSS** – Set the expiration date time interval for as long as possible, then update the URL to include a version number that changes when new static files are uploaded.
- **Uploaded assets such as images** – ETags are good for this. However, do not set expiration times longer than the editors can wait for a file to be updated because editors might get confused if they upload a new image with the same name and the cache still shows the old image.
- **Custom API controllers and "normal" HTML** – Normally, you should not cache dynamic content, but it may be useful in some cases. Only cache if you do not have personalized content. If an API is cached, ensure variables are pulled from the URI rather than headers to avoid displaying incorrectly cached information and test thoroughly before going live. Do *not* cache *administrative* or *confidential* information.

## Non-cached hostnames

DXP implements page rules to avoid Cloudflare caching on the following hostnames:

- `inte.dxcloud.episerver.net`
- `slot`

You can use these to see the latest files, which is often helpful after a deployment. Polish is not used, either.

To make it easier to validate updates to code, CSS, or scripts, Optimizely does not have caching enabled for the default hostnames of integration environments or deployment slots.

If you want to verify your integration environment with standard caching, you can add a custom hostname because the rule is only configured for the default hostname.