No cache-control policy on the HTML

Audit check cache · worth 5 of 100 points · all checks

What the audit saw

The response has no Cache-Control header, or one that forbids reuse.

Why it costs you

Without a policy the browser guesses, and CDNs refuse to hold the response, so every visit goes back to origin. A correct policy is what makes a repeat visit feel instant.

How to find it on your site

  1. Read what is being sent 
    curl -sSI https://your-site.com/ | grep -iE 'cache-control|etag|last-modified|age'
  2. Short cache for HTML, immutable for hashed assets 
    # nginx
location = /index.html { add_header Cache-Control "public, max-age=300, must-revalidate"; }
location ~* \.[0-9a-f]{8,}\.(js|css|woff2)$ { add_header Cache-Control "public, max-age=31536000, immutable"; }
  3. Verify a hit after a second request 
    curl -sSI https://your-site.com/ | grep -i '^age'; sleep 2; curl -sSI https://your-site.com/ | grep -i '^age'

How to know it is fixed

cache-control present, and Age climbing on the second request if a CDN is in front.

The part people get wrong

Caching HTML for a year is how sites serve stale prices. Keep HTML short and make the filenames of assets carry a content hash.

Check it against your own site

Open an issue with your URL and a bot runs this check plus 14 others, posts the failures with the measured values, and publishes a report page: free audit. If you want the fixes applied and re-verified instead: fixed-price tiers.

Other checks

The site does not answer on the URL you gave · The page is served over plain HTTP · The TLS certificate is expired or about to exp · No mobile viewport tag · The page title is missing or the wrong length · The meta description is missing or the wrong l · The page has no H1, or more than one · Images have no alt text

All published audits · Check reference