Skip to main content
New: 190 SEO checks now available. See what's new
highPerformanceSET_COOKIE_ON_CACHEABLE

Cacheable response sets a cookie, so no CDN will cache it — the fix

This response declares itself cacheable (s-maxage or public max-age) and also sends a Set-Cookie header. No shared cache stores a response carrying Set-Cookie, so the caching header has no effect and every visit goes to the origin.

Where this fits: performance in SEO

Performance is both a ranking signal (Core Web Vitals) and a conversion multiplier. Google measures real-user loading (LCP), interactivity (INP), and visual stability (CLS) — and slow sites lose visitors before analytics even registers them. Most performance issues concentrate in a few repeat offenders: unoptimised images, render-blocking resources, and third-party scripts. Fixing the top three usually moves the needle more than fixing the next thirty.

Why cacheable response sets a cookie, so no cdn will cache it hurts your rankings

The two headers contradict each other, and the contradiction is silent: the page looks cached, the CDN is configured, and every request still pays full origin latency. It is a common cause of site-wide slow first-byte readings that no amount of server optimisation will fix, because the server was never the problem.

This is a high-severity issue: it directly suppresses rankings or click-through on the pages it affects. It belongs in your current sprint, prioritised by how many pages carry it.

How to fix it

Decide which half is true. If the cookie is not needed on this route — locale detection, session affinity, analytics — stop setting it there and the CDN starts working. If it is needed, remove s-maxage so the response stops claiming something no cache will honour.

// Set the cookie only where it is actually needed, not on every response
if (isLocaleRoute(request) && !request.cookies.has('NEXT_LOCALE')) {
  response.cookies.set('NEXT_LOCALE', locale);
}
// …or stop claiming the response is cacheable:
// res.headers.set('Cache-Control', 'private, no-store');

Performance best practices

  • Serve images in modern formats (WebP/AVIF), sized to their container, with explicit dimensions.
  • Inline critical CSS and defer everything else; eliminate render-blocking third parties.
  • Set far-future cache headers on static assets and an ETag on everything.
  • Preload the fonts and hero image; font-display: swap to avoid invisible text.
  • Measure with real-user Core Web Vitals, not just lab scores — Google ranks on field data.

The full library: SEO best practices, by category.

Frequently asked questions

What does "Cacheable response sets a cookie, so no CDN will cache it" mean?

This response declares itself cacheable (s-maxage or public max-age) and also sends a Set-Cookie header. No shared cache stores a response carrying Set-Cookie, so the caching header has no effect and every visit goes to the origin.

Why does cacheable response sets a cookie, so no cdn will cache it matter for SEO?

The two headers contradict each other, and the contradiction is silent: the page looks cached, the CDN is configured, and every request still pays full origin latency. It is a common cause of site-wide slow first-byte readings that no amount of server optimisation will fix, because the server was never the problem.

How do I fix cacheable response sets a cookie, so no cdn will cache it?

Decide which half is true. If the cookie is not needed on this route — locale detection, session affinity, analytics — stop setting it there and the CDN starts working. If it is needed, remove s-maxage so the response stops claiming something no cache will honour.

How serious is this issue?

This is a high-severity issue: it directly suppresses rankings or click-through on the pages it affects. It belongs in your current sprint, prioritised by how many pages carry it. It belongs to the performance family of checks.

How do I find every page affected by this on my site?

Run a free Dr Urls audit: it crawls your site, detects cacheable response sets a cookie, so no cdn will cache it on every affected page, shows example URLs, and generates a ready-to-use fix task. Re-scan after fixing to verify the issue is gone.

Does your site have this issue?

A free Dr Urls audit crawls your site, finds every page affected by cacheable response sets a cookie, so no cdn will cache it, and hands you a ready-made fix task.

Check my site free

Related performance guides