Cache-Control Headers for Static Websites

Cache-Control decides how long files stay reused

Cache-Control headers tell browsers, CDNs, and other caches how to store and reuse responses. For static websites, good caching can make pages faster, reduce bandwidth, and improve global reliability. Bad caching can keep old content alive, break updates, or make debugging painful. The goal is to cache aggressively where files are versioned and carefully where URLs stay stable.

Static sites usually include two broad response types: assets and HTML. Assets include CSS, JavaScript, fonts, and images. HTML includes pages such as blog posts, category pages, and the homepage. These should not always share the same caching rules.

Versioned assets can be cached for a long time

If asset filenames include a content hash, such as app.8f3a1.css, they can be cached for a long time because a change creates a new filename. A common header is Cache-Control: public, max-age=31536000, immutable. This tells browsers they can reuse the file for a year and do not need to revalidate it during normal use.

This strategy works only when filenames truly change after content changes. If the site serves style.css and overwrites it during deployment, a one-year immutable cache would be dangerous because users may keep the old file. Long caching belongs with versioned URLs.

HTML needs a freshness strategy

HTML pages usually keep the same URL while the content changes. A blog post may be corrected. A homepage may add new articles. A sitemap may update. HTML caching should balance speed and freshness. Many sites use shorter browser TTLs and let the CDN revalidate or purge on deploy.

Headers such as stale-while-revalidate can help caches serve a slightly stale response while checking for a fresh version in the background. This can improve perceived speed, but teams should understand how their CDN implements it. Caching behavior differs across platforms.

• Use long immutable caching only for versioned assets.
• Use more cautious caching for HTML pages that can change.
• Purge CDN caches during deployments that update public content.
• Document caching rules so future changes do not break freshness.

CDN and browser caches are not the same

A CDN cache sits between the origin and users. Browser cache lives on the user’s device. Some platforms allow separate control over edge TTL and browser TTL. This can be useful for static websites because the CDN can serve pages quickly around the world while browsers still check for updates often enough.

When debugging, always identify which cache is involved. A stale page may come from the browser, CDN, service worker, hosting platform, or an intermediate proxy. Clearing one cache may not clear another. Use response headers, cache status headers, and hard refreshes to understand what is happening.

Caching affects SEO through speed and consistency

Search engines need stable access to current canonical pages. If a sitemap lists a new article but the cached blog index does not show it for a long time, discovery may be delayed. If canonical tags or redirects are cached incorrectly, crawlers may receive mixed signals. Caching should support publishing, not fight it.

Strong static website caching is simple in principle: immutable versioned assets, carefully managed HTML, documented CDN behavior, and deployment-aware purging. When done well, users around the world get faster pages and the team can still publish updates confidently.