隐私政策的最后更新日期，347个页面里三分之二没写

摘要：把131个海外品牌站的隐私政策、服务条款、退货政策、配送说明、Cookie说明逐页抓下来，能读到正文的一共347页，其中写了更新日期的只有115页，占33.1%。写了的那批里，将近一半停在一年以前，12.4%停在五年以前，最久的一页停在2014年1月——而同一个页面的HTTP响应头说这份文件最近才动过。更尴尬的是，93个页面白纸黑字承诺“我们改了会把日期标在这里”，其中26个页面自己一个日期都没写。

做站的人对政策页有一种奇怪的态度：上线那天认认真真找模板、改公司名、跑法务，然后就再也不看它一眼。它不进转化漏斗，不参与A/B测试，没有人给它排OKR。它安安静静挂在页脚，和网站备案号、版权年份做邻居，直到某天有人问一句：这份东西还算数吗。

这个问题本来有标准答案。政策文件是网页里少数几类会主动写下自己生效时间的东西——法务模板的第一行通常就是那句Last updated。它等于文件自己举手说：我是那天定的稿。

那就来数一数，有多少页举了手，举起来的那些手，又停在哪一年。

一份会写生效时间的文件，为什么多数都不写？

样本是131个海外消费品与零售品牌的官网，覆盖服饰、家居、3C、母婴、户外、美妆几个大类，既有Shopify、Salesforce Commerce这类平台店，也有自研站。从首页出发，先沿页脚链接找政策页，找不到的再按常见路径试一遍，最后逐页取回正文。

能拿到首页的120个站里，最终有100个站给出了至少一个能读到正文的政策页，一共347页。这里已经剔掉了两类：正文不足900字符的JS空壳，以及被限流挡回来的页面。

三分之一。换成站点口径好看一些：100个站里有74个站至少有一页写了日期，但反过来说，26个站的整套政策文档，没有任何一页告诉你它是什么时候定的。awaytravel、baseus、bigcommerce、brooklinen、bugaboo、casetify、gymshark、lookfantastic、peakdesign、rapha都在这一列里，其中不乏合规团队规模不小的牌子。

更值得琢磨的是那条断崖。隐私政策和服务条款接近六成会写，退货政策掉到4.2%，配送说明只剩1.6%——72个退货页里只有3个写，61个配送页里只有1个。

为什么断崖正好出现在退货和配送这两类页上？

一个容易想到的解释是“重要性递减”，但它站不住脚。对独立站来说，退货和配送恰恰是最常改的两页：运费门槛变了要改，承运商换了要改，旺季时效延长要改，某个国家的关税政策一动还得再改一次。按理说，最需要标注版本的正是它们。

真实原因藏在这两页的出身里。隐私政策和服务条款出自法务模板，法务模板的开头天生带一行日期，因为它是一份合同性质的文本，需要能指认“你同意的是哪一版”。退货和配送则出自运营手写，或者干脆是平台自带的富文本编辑器里敲出来的一段话——它在作者心里的定位是“一段说明文字”，不是“一份文件”。

这个分野在数据里留下了一道很干净的痕迹：写日期的页面，81页的日期落在正文前30%的位置，也就是标题正下方。这是模板的位置，不是编辑随手加的位置。

顺带说一句，退货和配送页上并不是没有日期。有27个页面正文里能找到日期串，但判不出是更新日期，其中12个是退货或配送页。翻开看，它们写的是“12月25日前下单可在圣诞节前送达”“1月31日前的订单享受延长退货期”——那是促销截止日，不是文档更新日。这两类日期在同一页上并排放着，读的人得自己分。关于承诺该说给人听还是说给机器听，站内那篇配送和退货承诺的机器可读性实测拆得更细。

写了日期的那些页面，停在哪一年？

115个日期能全部解析成具体年月。分布如下。

中位数落在一年整。也就是说，在那些愿意写日期的页面里，也有整整一半超过一年没有更新过。往后拉：32.7%超过两年，22.1%超过三年，12.4%超过五年。

队尾这一串名字值得念一遍：tuftandneedle的服务条款停在2017年1月，nomadgoods的条款停在2017年2月，decathlon的条款停在2017年11月，materialkitchen的隐私政策停在2017年12月，joolz的隐私政策停在2018年5月25日——那天恰好是GDPR生效日，一份为合规而生的文件，此后八年没有再动过。

最长的那一页是philips的服务条款，写着January 2014。这份文件写下的时候，还没有CCPA，没有Schrems II判决，没有欧盟数字服务法，苹果也还没有推出应用追踪透明度。它一路挺过了这些，页面上那行字一动不动。

同一个站的隐私政策和服务条款，是同一天改的吗？

如果一个站是“定期整体复审”，那它几份文档的日期应该扎堆；如果是“哪份出事改哪份”，日期就会散开。34个站有两页以上写了日期，可以直接看。

结果是：只有8个站所有页面同一天，26个站各不相同。散开的那批，跨度大得离谱。

decathlon那一行最能说明问题。隐私政策改到了上个星期，服务条款还停在八年多以前。这不是懒——恰恰相反，这说明有人在认真维护隐私政策。只是维护它的那个人（或者那个外部律所、那套同意管理平台）只负责隐私这一份，条款不在他的清单里，而全公司也没有第二个人认领它。

不是没人干活，是这些文件被拆给了不同的人，而其中几份没有分到人。这句话适用于绝大多数“年久失修”的页面，不只是政策页。

“我们改了会在这里标出来”，这句话兑现了吗？

政策模板里几乎都有这么一段：我们可能不时修订本政策，修订后会在本页发布并更新顶部的日期，请您定期查阅。这句话本身就是一个承诺，而且是可验证的承诺——承诺这种东西一旦落成文字就有强弱之分，站内那篇退货政策那句承诺译成日语之后的语气变化讲的就是同一类问题。

347个页面里，93个页面（分布在64个站）写了这类话。然后：

• 其中26个页面（20个站）自己一个日期都没写。它承诺会更新一个并不存在的东西。
• bellroy的隐私政策把话说得最具体——“修订日期会标注在本页顶部”——顶部那行写着Last Reviewed: 1 July 2020。
• article、burrow、everlane、glossier、dreametech都属于“承诺了但没有日期”这一类。

这不是钻字眼。这句话在很多司法辖区里是变更通知机制的一部分：既然你不单独通知，那用户唯一能判断“政策变没变”的依据就是这行日期。日期不写或者不更新，这个机制就是空的。

机器记的时间和人写的时间，对得上吗？

页面上那行字是人写的。同一个页面还有另一个时间：HTTP响应头里的Last-Modified，那是机器记的。两个时间放在一起会很有意思。

先说个扫兴的事实：347个政策页里，只有8页带Last-Modified头。剩下的全是动态渲染或者经过CDN，服务器压根不报这个字段，所以这个对照只能在很小的样本上做。但这8页里的对照，比大样本还刺眼。（想查自己站上发没发这个头，别只用一条curl -I去量，那个命令量出来的头比实际少一截。）

philips那一行是整轮实测里最刺眼的一处。机器说这个文件几天前刚动过，人说它是2014年1月的版本。两句话都不算撒谎——CMS重新渲染了一次页面，字节确实变了；条款正文可能一个字没改。它们记的根本不是同一件事：一个记的是“这份字节什么时候生成的”，另一个记的是“这份约定什么时候定的”。

这个坑在别处也出现过。站内那篇sitemap里lastmod到底记的是哪一刻量过41万条地址，结论是同一个字段在不同站上记着完全不同的事件；同一批数据里还有一篇提交的地址页面自己认不认账，量的是另一层不一致；条件请求与304的实测里也有同一个问题的另一个面。凡是“时间”这种看起来不言自明的字段，都要先问它记的是哪件事。

顺带提醒一句，对搜索引擎来说这两个时间的地位并不对等。Google在自家文档里说得很直白：它更信任正文里对用户可见的日期，也会参考结构化数据里的dateModified，但明确表示不会依赖那些用户看不见的信号。也就是说，你把Last-Modified刷得再勤，页面上那行2014年才是被读到的那个。

这一行字，一共有多少种写法？

如果你想写个脚本把全站政策页的更新日期抓出来做个看板，这一节是坏消息。

115个日期，前面的标签词一共17种写法：Last updated占58次，之后是effective as of（11次）、effective（7次）、last modified（7次）、effective date（7次）、last update（6次）、updated（5次）、updated on（3次）、last reviewed（2次）、effective from（2次），还有amended as at、revised on、update on这类只出现一次的。中文站点则写“更新日期”和“生效日期”。

日期本身的格式有五种：August 6, 2026这种最多（87次），其次是1 July 2020（9次）、只写到月份的September 2025（7次）、以及少量斜杠与点号格式。

还有两页干脆什么标签都不写，日期直接跟在文档标题后面：ouraring的隐私政策，标题下一行就是June 15, 2026；harrys的服务条款也是同一种写法。人一眼能懂，机器要靠猜。这种“同一件事在页面上有好几种说法”的毛病并不新鲜，站内那篇首页的title、og:title和H1说的常常不是同一件事量的是同一个病灶的另一处。

这就带出一个很少被提的事实：网页上有canonical、有hreflang、有结构化数据、有sitemap的lastmod，唯独“这份文件什么时候定的稿”没有任何一个标准字段。它只存在于正文里的一句自然语言中。你想让机器可靠地读到它，只有自己动手——把它写进结构化数据的dateModified，或者至少包进一个带datetime属性的time元素。日期格式怎么选、各处该用哪一种写法，站内的日期格式化工具用法那篇有一张对照表可以直接抄。

文件里引用的那部法规，还在生效吗？

日期只是文件的自述。更硬的办法是看它引用了什么——法规有明确的生效和失效日期，文件里提到哪一部，就等于在自己身上盖了个时间戳。

347个页面里，提到Do Not Sell的139页次，CCPA 39次，Global Privacy Control 38次，GDPR 36次，标准合同条款24次，CPRA 17次。这些都还在生效。合规文本里引用哪一部法规、拿不拿得出依据，正在变成一件越来越硬的事——欧盟对环保声明的举证要求就是最近的一例。

然后是那4页：baseus、bellroy、cybex-online、rapha的隐私政策里，还写着Privacy Shield。

欧盟与美国之间的这套数据传输框架，在2020年7月16日被欧洲法院在Schrems II案里直接判为无效。它的替代品——欧盟与美国数据隐私框架——2023年7月才生效，本轮实测里有8个站已经换上了新名字。四个站的隐私政策，把一个已经失效六年多的法律依据继续印在页面上，作为跨境传输个人数据的正当性来源。

bellroy这一页尤其完整地展示了这件事是怎么发生的：页面顶部写着Last Reviewed: 1 July 2020，正文里引用Privacy Shield。判决下来的日子是7月16日，而这份文件的最后一次审阅，比判决早了15天。它不是没跟上，是从来没有第二次。

另外三个站更彻底一些：baseus、cybex-online、rapha的隐私政策连日期都没写，所以你连“它是哪年停下的”都无从判断，只能靠这个失效的法规名反推。引用的法规，有时候是比日期更可靠的时间戳。

那这份文件到底是谁在维护？

看一眼页面上的第三方指纹，答案就浮出来了。

347个页面里，83页次带OneTrust的痕迹，28页次带Osano，11页次TrustArc，10页次Usercentrics，还有Quantcast、Termly、iubenda、Didomi零星几家。这些都是同意管理平台，负责Cookie横幅、偏好中心，有些也顺带托管Cookie清单。

它们能自动更新的是Cookie清单那一块，不是政策正文。于是就出现了这种局面：Cookie说明里的表格是脚本每周扫出来的，永远新鲜；同一页顶部那行更新日期是人手写的，停在两年前。

还有一种更直白的证据。20个页面（分布在8个站）的正文里，留着方括号包起来的模板占位符——bigcommerce、brompton、chubbiesshorts、ice-watch、mackweldon、monos、nativecos、ritual。那是建站平台默认政策模板里等着你替换的地方，比如让你填店铺名、填退货天数。方括号还在，说明它等了好几年也没等到。这些页面从上线那天到现在，正文一个字都没有被人打开过。

把这三件事叠在一起，一个站的政策页大致有三层：平台生成的默认文本、外部工具自动维护的片段、以及理论上归内部法务的正文。没有分到人的，恰恰是中间那一层——它既不在平台的自动更新范围里，也不在任何人的季度清单上。如果你正在选同意管理平台，站内那篇出海独立站怎么选同意管理平台把各家能管到哪一层拆开对比过。

这行日期会被谁读到？

做SEO的人容易先问一句：这东西影响排名吗。直说，几乎不影响。政策页大多不是流量页，多数站也不指望它排名。

但它影响三件更实际的事。

第一件是AI引用。生成式搜索在挑源的时候会评估内容的时效，而政策页是少数几类“机器会当成事实依据去读”的页面——用户问“这个牌子多少天可以退货”“他们会不会把我的数据卖掉”，模型往往直接从政策页取答案。一个引用着已失效框架、又不标日期的页面，很容易被当成过时来源降权，更麻烦的是它可能被原样当成现行事实读出去。站内那篇早就掉没了的旧内容为什么AI还当成当下事实讲的就是这个机制的另一面；关于时效信号本身怎么打，可以看内容新鲜度的实战法则。

第二件是信任评估。政策页是E-E-A-T评估里“这个站是不是一个真实、负责的经营主体”这一层的证据之一，尤其在涉及钱和个人数据的类目里。一份停在2017年的服务条款传达的信息很明确：这里没有人在看。YMYL类目怎么靠E-E-A-T稳住排名那篇把这类证据链拆得更细，E-E-A-T信号怎么强化那篇给的是可执行的一侧。顺带说一句，这类信号在小语种市场的权重更高，落地页上最像装饰的那几个信任元素那篇里能看到量级。

第三件最贵，是纠纷发生时。用户说“我下单的时候你们写的是30天退货”，你说“我们改成14天了”。这时候唯一能证明变更时点的，就是页面上那行日期加上你的版本记录。没有日期，你在事实层面就没有变更记录——一句比较级要你拿出整套证据那篇里说的举证责任分配，在这里同样成立。

保哥去年帮一个做母婴用品的独立站梳理页脚，就撞上过这一幕：客服后台有用户拿着截图说政策里写的是免费退换，运营坚持三个月前就改成了退货运费自理。翻CMS的修订历史，那一版被后来的批量导入覆盖掉了；页面上的日期从上线起就没动过。最后按用户的截图赔付，然后才回头把日期和版本记录补上。这件事的成本不在赔的那笔钱，而在于那之后每一次改政策都要额外走一遍留痕流程。

这一轮实测，我的尺子错了六次

“只有33.1%的页面写了更新日期”这种句子，最怕的不是数据不好看，是尺子本身没量准。任何“只有多少”“一个都没有”的结论，发表前都得先证明这把尺子能量出反例。这一轮的尺子前后错了六次，其中三次直接改变结论。

第四条值得单独说一句。stanley1913的页脚里，第一个叫Terms的链接指向的是短信营销条款；thirdlove指向的是促销条款；mackweldon的Terms链接落到了FAQ页。这些页面各自都有日期，看着挺新——如果不核对标题，得到的就是一份“服务条款更新得挺勤”的假象。

还有一条没算进上表，但同样重要：那27个“有日期串却判不出更新日期”的页面，我一开始怀疑是漏判，回捞之后只补回4页，剩下的绝大多数写的是促销截止日。尺子谨慎的时候不能只怪它保守，得逐个看过才知道它是不是对的。

自己站上该怎么查，这行字该怎么写？

先花十分钟做一次盘点，顺序是固定的。

1. 列出你的政策页清单：隐私政策、服务条款、退货政策、配送说明、Cookie说明，加上任何独立的促销条款、短信条款、联盟条款。别只看页脚，页脚里可能有两个都叫Terms的链接。
2. 逐页找那行日期。找不到就记零。
3. 把每页的日期和它上一次真正改动的时间对一遍。对不上的，说明这行字已经和内容脱钩了。
4. 搜一遍页面里的法规名，重点看Privacy Shield、Safe Harbor这类已经失效的名字，以及你现在实际依赖的传输机制有没有写上去。
5. 搜一遍方括号——模板占位符如果还在，说明这页正文从来没被打开过。

然后是写法。四条，都不难。

统一标签词。全站只用一种，推荐“最后更新”或者Last updated。别一页写Effective、一页写Last modified，那是不同的意思：一个是这版什么时候开始生效，一个是文本什么时候被改动，两者可以差好几周。要是想两个都表达，就两个都写上，别混着用。

日期写全，别只写到月。本轮有7页只写了月份，byredo三页都是September 2025。真到纠纷的时候，“9月”这个精度不够用。也别用纯数字的斜杠格式，那个格式在美式和英式读法下差着一整个月。

让机器也能读到。把日期同时写进带datetime属性的time元素，格式用ISO 8601；如果这页有结构化数据，dateModified也同步一份。这一步的成本是五分钟，收益是从此以后你可以脚本化地盘点它。

把它挂到人身上。这是最关键的一条，也是前面所有数据真正指向的地方。decathlon的隐私政策改到上个星期而条款停在八年前，不是因为有人偷懒，是因为条款那份没有分到人。做法很朴素：每份政策文档在内部文档里写清楚谁是责任人、多久复审一次，写法可以参考披露声明那种“不做什么的清单”，可核查的条目比笼统的原则好用；平台自动维护的片段和人工维护的正文分开记，别默认“装了工具就等于有人管”。

最后补一句适用范围。这行日期不会给你带来流量，改完第二天也不会有任何指标动。它属于那类“平时看不出价值、出事时才知道贵”的东西——和站内那些早就没人读的响应头字段、悄悄自己变了的第三方脚本、生成器一次都没报错的坏sitemap是同一类问题：不是做错了，是做完之后没有人再回头看第二眼。

常见问题解答

政策页不写更新日期，会被搜索引擎降权吗？

不会直接降权。政策页通常不是排名目标，Google也没有把“页面上有没有更新日期”当成排序信号。真正的影响在别处：一是生成式搜索挑源时会评估时效，一份引用着失效法规又不标日期的页面容易被判为过时来源；二是它属于站点可信度的证据之一，尤其在涉及钱和个人数据的类目里。别为了SEO加这行字，要为了能说清楚版本而加。

写Last updated和写Effective date，有区别吗？

有，而且是实质区别。Last updated说的是文本什么时候被改动过，Effective date说的是这一版什么时候开始对用户生效。政策改完通常会给一段过渡期，两个日期能差好几周。本轮实测里两种写法都很常见，last updated类占多数，effective类合计27页次。稳妥的做法是两个都写，并且明确标出哪个是哪个。

Last-Modified响应头能代替页面上的日期吗？

不能。这两个字段记的不是同一件事。本轮实测里philips的服务条款，响应头说昨天动过，页面上写着2014年1月——前者记的是这份字节什么时候生成，后者记的是这份约定什么时候定稿。而且政策页里只有8页带这个响应头，绝大多数动态站和CDN根本不发它。它可以作为辅助线索，不能当依据。

用同意管理平台之后，政策页是不是就自动保持最新了？

只有一部分是。这类平台能自动维护的是Cookie清单、横幅文案和偏好中心，政策正文仍然是人工维护。本轮347个页面里有130多页次带这类平台的指纹，其中不少页面的Cookie表格很新，顶部那行更新日期却停在两年前。装了工具不等于有人管，两层要分开记责任人。

政策页历史版本要不要保留？

要，而且比那行日期更重要。日期只告诉别人“现在这版是哪天的”，历史版本才能回答“用户下单那天看到的是哪一版”。最省事的做法是在CMS之外单独留档：每次改动导出一份带时间戳的静态快照，或者把政策文本纳入版本控制。真到纠纷时，能拿出当日版本和拿不出，结果完全不同。

退货政策和配送说明也需要写更新日期吗？

需要，而且优先级不比隐私政策低。本轮数据里这两类页的日期覆盖率只有4.2%和1.6%，但它们恰恰是改动最频繁、最容易引发纠纷的两页——运费门槛、时效承诺、可退天数，每一项改动都直接对应真金白银。这两页不写日期，多半不是决定不写，而是它们出自运营手写而非法务模板，模板里那行字压根没跟过来。

权威参考资料