Set-Cookie on 27 homepages: 54 cookies arrive before you click, and Google's renderer drops every one

FIELD TEST · 2026-08-30 · 27 homepages · one request each · Set-Cookie headers on the first response

Sample and method: the 30-site panel this blog has used since 2026-08-15, each homepage requested once on 2026-08-30 with a desktop browser user agent, redirects followed, every Set-Cookie header on the final response recorded. Three sites dropped out — stackoverflow.com and medium.com answered 403, reddit.com returned 8,393 bytes and missed the 10,000-byte floor. That leaves 27.

Fourteen of the 27 homepages send at least one set-cookie header on the very first request, before a visitor clicks anything at all. Together they hand over 54 cookies, 49 of which are written to disk rather than to the session. Google's own rendering documentation says its renderer clears HTTP cookies between page loads, so every one of the 54 is discarded before the next URL is fetched.

How we measured it

One request per homepage, redirects followed, and every Set-Cookie line on the final response collected separately rather than folded into one string. Cookie names, flags and lifetimes below all come from those raw header lines.

Two caveats belong here rather than at the end. We requested as a desktop browser, not as Googlebot, so a site that varies its cookies by user agent would look like a single fact here. And this is the first response only — cookies written later by JavaScript, or after a consent banner is dismissed, are outside what a single header read can see.

Fourteen sites send a set-cookie header before you do anything

Thirteen sites set none. The split is close to even by site count and nowhere near even by cookie count, because the sites that set any tend to set several.

Forty-nine of the 54 carry a Max-Age or an Expires, which makes them persistent rather than session cookies. The longest lifetime on the panel is Max-Age=315619200 on slack.com, a little under ten years, set on a request from someone who has not yet read a sentence of the page.

Five of the 54 have names that refer to consent or privacy law — _v-consent on vercel.com, notion_check_cookie_consent on www.notion.com, _vm_consent_type on www.theverge.com, and both nyt-gdpr and nyt-purr on www.nytimes.com. They arrive in the same response as everything else. What they contain, and whether any of it is a legal question, is not something a header read can answer.

What Google's renderer does with all 54

Google's documentation on fixing search-related JavaScript problems is direct about state. The renderer "does not retain state across page loads", and the page spells out both halves of that: "Local Storage and Session Storage data are cleared across page loads" and "HTTP Cookies are cleared across page loads". The same page gives the instruction that follows from it — "Don't rely on data persistence to serve content."

Read together with the numbers above, that means the ten-year cookie and the session cookie get exactly the same treatment: both are gone by the next URL. A crawler is not a returning visitor building up a profile. It is a first-time visitor, every single time, on every single page.

To a crawler, every page on your site is the first page it has ever seen. Anything you stored on the last one is not there.

The practical version of that is a content question, not a privacy one. A page that renders differently once a cookie exists — a chosen region, a dismissed banner, a logged-in view, an A/B variant sticky across visits — shows an engine the pre-cookie version and only the pre-cookie version. What the raw response actually contains is the same problem approached from the JavaScript side in can AI crawl JavaScript, and you can see it on your own page with the AI crawler reachability check.

The flags: Secure on most, HttpOnly on a third

The attributes on those 54 cookies split unevenly, and the SameSite column is the one with a gap worth naming.

Fifteen cookies carry no SameSite attribute, so the browser picks the behaviour rather than the server. Two cookies out of 54 use Strict, which is a reminder that the strictest option is rarely the chosen one when the cookie has a job to do across sites.

What this means for you

Two checks, and the first one takes a single request.

1. Count your own. curl -sI https://yourdomain/ | grep -i '^set-cookie' lists every cookie your homepage hands to a stranger. If the count surprises you, the surprise is usually a tag manager, not your application.
2. Then fetch the same page twice with no cookie jar and compare the HTML. curl -s https://yourdomain/ | wc -c, twice, with nothing carried between the two. Different byte counts mean part of your page depends on state a crawler will never accumulate.

The second check is the one that matters for search. A crawler that arrives cookieless every time gets whatever your site shows a first-time anonymous visitor, so that version is the version an engine can quote. The other half of this panel's response-header picture, measured on the same request, is in referrer policy on 27 homepages.

What this run cannot tell you

Whether any of these cookies changes what the page shows. We counted headers; we did not fetch each homepage twice with and without a cookie jar and diff the HTML, so for these 27 sites we don't know how much of the page depends on state. We also did not request as Googlebot, did not run JavaScript, and did not accept or reject any consent dialog — cookies set after any of those are invisible here. And this is one request from one exit at one moment, so a server that varies cookies by region looks like a single fact.

Common questions

How did you measure this?

One request per homepage on 2026-08-30 with a desktop browser user agent, reading every Set-Cookie header off the final response as a separate line, then counting names, flags and lifetimes.

Do cookies affect SEO?

Not directly. They matter when content depends on them, because Google's documentation says its renderer clears HTTP cookies across page loads, so a crawler never carries one from page to page.

Does Googlebot accept cookies?

Google's guidance is that its renderer does not retain state across page loads and that you should not rely on data persistence to serve content. Whatever a single request does with a cookie, nothing survives to the next URL.

Is a persistent cookie worse than a session cookie for crawling?

For crawling they are the same, which is the point of the ten-year value found here. Persistence is a promise to a browser that will come back, and the crawler is not that browser.

What does SameSite=None mean?

It allows the cookie to be sent on cross-site requests, which is why 18 of these 54 use it — those are cookies with work to do beyond their own domain. Fifteen more set no SameSite value at all and let the browser decide.