Cache-Control is an HTTP response header that controls how and for how long web pages are stored by browsers and content delivery networks before a new request is made to the origin server.
Web developers or system administrators reading documentation on caching strategies and HTTP headers.
01What it is and how it works
When a browser or CDN requests a page, the server includes a Cache-Control header in the HTTP response. This header contains directives such as max-age, no-cache, no-store, and public or private. The max-age directive tells the browser how many seconds to use the cached copy before it must ask the server for a fresh version. A directive like no-cache means the browser must revalidate with the server before using the cached copy, even if it is still within the max-age window. The no-store directive prevents any caching at all, which is useful for sensitive pages like checkout confirmations. The public directive allows shared caches like CDNs to store the response, while private restricts caching to the user's browser only. Each directive is evaluated by the browser or CDN independently, so a single header can combine multiple rules. The effective behavior depends on the order and combination of directives, and some directives override others. For example, no-store takes precedence over max-age. Understanding these interactions helps prevent stale content from being served to users or search engines.
Cache-Control is a line of code sent by a web server that tells a browser or CDN whether to save a copy of the page and how long to keep it before asking the server for a new version.
02What to do about it
Audit your most important pages this week using browser developer tools or a command-line tool like curl to inspect the Cache-Control header. For static assets such as images, CSS, and JavaScript, set a long max-age (for example, 31536000 seconds, or one year) and use versioned filenames so updates are picked up immediately. For HTML pages that change frequently, use a shorter max-age (such as 60 to 300 seconds) or add a must-revalidate directive. For pages with sensitive or personalized content, apply no-store to prevent any caching. If you use a CDN, configure its caching rules to match your origin server's Cache-Control header rather than overriding it. Test changes by reloading the page in an incognito window and confirming the header is applied as expected. Document your caching strategy so team members do not accidentally overwrite it during future deployments.
03How it is measured or noticed
Open the Network tab in your browser's developer tools, reload the page, and click on the document request to view the response headers. Look for the Cache-Control field and read its directives. You can also use the command line with curl -I https://example.com to see the full set of response headers. Third-party tools like WebPageTest or Lighthouse will report caching status and flag resources that lack proper Cache-Control headers. Server-side logs can show how often requests are hitting the origin versus being served from cache, which helps you verify whether your directives are working as intended.
04Common mistakes
- Setting max-age too high on HTML pages, causing search engines to see outdated content for weeks or months.
- Using no-cache without must-revalidate, which can lead to inconsistent behavior across different browsers and CDNs.
- Applying no-store to static assets like images or CSS, wasting bandwidth and slowing page load times.
- Forgetting to update Cache-Control headers after deploying new content, so users continue seeing the old version.
- Relying on default server settings instead of explicitly configuring Cache-Control for each content type.
05Limits
Cache-Control only affects HTTP-level caching by browsers and CDNs. It does not control server-side application caching, database query caching, or in-memory caches used by your application framework. Search engine crawlers may choose to ignore Cache-Control directives entirely, especially no-store, and re-crawl pages regardless of the header. Cache-Control also has no effect on pages that are never requested over HTTP, such as content served through a mobile app API. Additionally, some older HTTP proxies and CDNs may not fully support all Cache-Control directives, so behavior can vary across different intermediaries. This header is often confused with the meta robots tag, which controls search engine indexing behavior, not caching. It is also distinct from the Expires header, which sets an absolute expiration time and is largely superseded by Cache-Control.
06Worked example
A news website sets Cache-Control: max-age=300, must-revalidate on its article pages. This means browsers and CDNs will use the cached copy for five minutes before revalidating with the server. When a breaking news story is published, the editor updates the article and republishes it. Within five minutes, all visitors will see the updated content because the cache expires and the server sends the new version with a fresh max-age=300 directive. If the editor had set max-age=86400 instead, visitors would continue seeing the old version for 24 hours, delaying the spread of the breaking news.
The entry above is written by GetLoopLoop. What follows is what independent catalogues hold about the same term — none of it is the source of this page.
- Part of
- HTTP Caching
- Kind of thing
- HTTP header
The same term on Wikipedia
Catalogued in 1 languagesFrequently asked questions
How do I know if my pages are using the right Cache-Control settings?
Yes, you can check the HTTP response headers using browser developer tools or curl to see the Cache-Control value. This tells you how long browsers and CDNs will keep the page cached.
What does a 'no-cache' directive mean for my site's performance?
Yes, it means the browser must revalidate with the origin server on every request, so the page always reflects the latest content. This can improve freshness but may increase server load.
Can I set different Cache-Control values for static assets versus dynamic pages?
Yes, you can apply separate directives per resource type, such as 'max-age=31536000' for images and 'no-cache' for API responses. This balances speed and up‑to‑date data.
Why is my page still showing old content even after I updated it?
Usually the existing cache is being served because the Cache-Control header allows a long max‑age. Clearing the cache or using a shorter max‑age will force a fresh fetch.
Do I need to worry about Cache-Control when using a CDN?
It depends on how the CDN is configured; some CDNs respect the header while others have their own caching rules. Checking the CDN documentation and testing with curl will reveal its behavior.
Asked out loud
spoken, not typedThe same term in the words somebody uses speaking to an assistant rather than typing into a box — written from the situation, which is why each one carries the situation it came from.
Yes, you can view the response headers in the browser dev tools or with curl to see the directive. This tells you how long the page will be cached.
Yes, you should inspect the HTTP response headers using dev tools or curl to locate the Cache-Control setting. That shows how long the content is cached.
Usually you need to set a shorter max‑age or add no‑cache to force a fresh fetch. This will make the updated content appear immediately.