Bulk Cache Headers Checker (Cache-Control)

It depends on the content, which is why the threshold is a form setting. Practical anchors: immutable build assets (hashed filenames) — a year (max-age=31536000, immutable); images and media — days to months; regularly updated HTML — minutes (or no-cache with validators, so browsers revalidate cheaply); personalized or paid pages — no-store. The checker highlights anything below the threshold you set (300 seconds by default).

Correct — one of the most misleading names in HTTP. no-cache allows storing but requires revalidation with the origin (ETag/Last-Modified make that a 304, nearly free). no-store is the one that forbids storing anywhere. The checker reports which of the two the server actually sends, and the verdict treats them differently: no-cache with validators is a solid pattern for fresh HTML.

When a response has no freshness directives (no Cache-Control max-age, no Expires) but does have Last-Modified, browsers and proxies estimate freshness as roughly 10% of the time since the document was modified — a cache of a page changed a year ago "lives" about a month and a half. It works, but nobody controls it: set an explicit Cache-Control instead, and the report marks the heuristic-only state for exactly that reason.

Caching headers live in the response headers, so a HEAD request is enough — no page body is downloaded, which keeps bulk checks light. A few servers answer HEAD with 405; their headers are still read from that response, and the status itself is shown in the report so you can interpret it.