samesite 实测：27 个首页在你点之前发下 54 个 cookie，15 个没写 samesite

实测 · 2026-08-30 · 27 个首页 · 各请求一次 · 首个响应里的 Set-Cookie

样本 / 口径：2026-08-15 起沿用的同一批 30 个站，2026-08-30 各请求一次，桌面浏览器 UA，跟随跳转，最终响应里的每一条 Set-Cookie 单独成行采集。三个站掉出去了 —— stackoverflow.com 与 medium.com 返回 403，reddit.com 只有 8,393 字节，没过 10,000 字节下限。剩 27 个。

27 个首页里有 14 个在你点任何东西之前就发下了 cookie，一共 54 个，其中 15 个连 samesite 属性都没写，18 个写的是 SameSite=None。54 个里 49 个带过期时间，最长的那个接近十年。而 Google 的文档写着它的渲染器会在页面之间清掉 HTTP cookie，所以这 54 个爬虫一个都带不走。

怎么测的

每个首页一次请求，跟随跳转，最终响应里的每一条 Set-Cookie 各自成行采集，没有拼成一个字符串。下面的名字、属性、寿命全部来自那些原始头行。

两条限制放在这里说，不放文末。请求用的是桌面浏览器 UA，不是 Googlebot，所以一个会按 UA 改 cookie 的站在这里只会呈现为一个固定事实。另外只看首个响应 —— JavaScript 后写的、以及点掉同意弹窗之后才写的，一次读响应头看不到。

15 个 cookie 没写 samesite，18 个写的是 None

54 个 cookie 的属性分布很不均，而 SameSite 这一列是缺口最明显的那一列。没写这个属性时，行为由浏览器决定，不由服务器决定。

54 个里只有 2 个用 Strict。这说明当一个 cookie 本身就有跨站要干的活时，最严的那一档基本不会被选。None 有 18 个，正是那批要跨站带过去的。

14 个站发，13 个站一个都不发

按站数看接近对半，按 cookie 数看差得很远 —— 会发的站往往一次发好几个。

54 个里有 49 个带了 Max-Age 或 Expires，也就是落盘的持久 cookie，不是会话 cookie。整批寿命最长的是 slack.com 的 Max-Age=315619200，略少于十年，而它是发给一个还没读到页面上一句话的访客的。

另有 5 个 cookie 的名字里带着同意或隐私法规的字样 —— vercel.com 的 _v-consent、www.notion.com 的 notion_check_cookie_consent、www.theverge.com 的 _vm_consent_type，以及 www.nytimes.com 的 nyt-gdpr 和 nyt-purr。它们和其它 cookie 在同一个响应里到达。里面装了什么、是不是一个法律问题，读一个响应头回答不了。

Google 的渲染器会把这 54 个全丢掉

Google 那份《修复与搜索相关的 JavaScript 问题》说得很直接：渲染器「does not retain state across page loads」，并且把两半都写了出来 ——「Local Storage and Session Storage data are cleared across page loads」以及「HTTP Cookies are cleared across page loads」。同一页还给了由此推出的那句指令：「Don't rely on data persistence to serve content.」

和上面的数字放在一起看：那个十年的 cookie 和一个会话 cookie 待遇完全一样，到下一个地址就都没了。爬虫不是一个逐渐攒出画像的回头客。它每一次、每一页，都是第一次来。

对爬虫来说，你站上的每个页面都是它见到的第一个页面。你在上一页存的东西，这里没有。

落到实处，这是内容问题不是隐私问题。一个页面只要在「有 cookie 之后」才变样 —— 选过的地区、点掉的弹窗、登录后的视图、跨访问保持的实验分组 —— 引擎看到的永远是没有 cookie 的那一版。同一件事从 JavaScript 那一侧看是 AI 爬虫会执行 JavaScript 吗；自己那一页现在长什么样，可以用 AI 爬虫可达性检查 直接看。

独立站要做的两件事

两步，第一步只要一次请求。

1. 先数自己的。curl -sI https://你的域名/ | grep -i '^set-cookie' 会列出你的首页塞给一个陌生人的每一个 cookie。数字如果超出预期，多半来自埋点管理工具，不是你自己的应用。
2. 再用不带 cookie 罐的方式连抓同一个页面两次，比字节数。curl -s https://你的域名/ | wc -c 跑两遍，两次之间什么都不带。字节数不一样，就说明页面有一部分依赖爬虫永远攒不起来的状态。

第二步才是跟搜索有关的那一步。爬虫每次都是不带 cookie 来的，它拿到的就是你给首次匿名访客看的那一版，而引擎能引用的也只有那一版。同一批面板上响应头的另一半，来自同一次请求，在 27 个首页的 referrer policy 实测。

这次没测出来的几件事

这些 cookie 到底改不改变页面显示的内容，不知道。我们数的是响应头，没有对每个首页做「带 cookie 罐」和「不带」两次抓取再比 HTML，所以这 27 个站里有多少页面依赖状态，这次没测出来。我们也没有用 Googlebot 的 UA 请求、没有执行 JavaScript、没有点过任何同意弹窗 —— 这三种情况之后才写下的 cookie 在这里是看不见的。另外这只是一个时刻、一个出口、每个站一次请求。

常见问题

你们是怎么测的？

2026-08-30 用桌面浏览器 UA 对每个首页发一次请求，把最终响应里的每一条 Set-Cookie 单独读出来，再统计名字、属性和寿命。

samesite 不写会怎样？

行为交给浏览器决定，不再由你的服务器决定。这批 54 个 cookie 里有 15 个是这种情况，占 28%。

cookie 影响 SEO 吗？

不直接影响。它有关系的时候只有一种：内容依赖它。因为 Google 的文档写明渲染器会在页面之间清掉 HTTP cookie，爬虫不会把任何一个从上一页带到下一页。

Googlebot 接受 cookie 吗？

官方的说法是渲染器不跨页面保留状态，并且不要依赖数据持久化来提供内容。单次请求里怎么处理是一回事，反正没有任何东西能活到下一个地址。

持久 cookie 对抓取比会话 cookie 更糟吗？

对抓取来说两者一样，这正是那个十年寿命值得写出来的原因。持久化是给「会再回来的浏览器」的承诺，而爬虫不是那个浏览器。