把系统时间调到2031年，19%的网站页脚版权年份跟着变

摘要：116个海外品牌站的首页页脚，那行版权小字被逐个读了一遍。85.3%写了版权声明，其中92.9%带了年份，落后于今年的有12.0%，最老的停在2022年。真正的问题不在旧，在这个数字是谁算出来的——把浏览器时钟拨到2031年再访问一遍，84个可比对的站里有16个的年份当场变成2031。它们写的从来不是自己的年份，是访问者电脑上的年份。剩下能确认是有人写完就没再动的，只有10个。

先说一个你大概率没试过的动作：把电脑的系统时间往后调五年，然后打开你常逛的那几个品牌官网，滑到最底下。

有些站的页脚会跟着你一起穿越。

gymshark.com、govee.com、ouraring.com、shein.com，再加上另外十二个站，在系统时间被设成2031年6月的机器上，页脚老老实实写着 © 2031。它们不知道自己在说什么，只是把 new Date().getFullYear() 的结果贴了上去。这个函数取的是浏览器所在设备的时间，不是服务器的时间，更不是这家公司真实的经营状态。

这行字大概是全站被眼睛扫过最多、被真正读到最少的一处。它同时也被爬虫、被大模型、被各种做站点评估的工具读到，这些读者认真得多，但它们读到的东西同样什么都不是。

页脚那行小字，在法律上到底是什么？

先把它的来历说清楚，后面的数据才有落点。

那行 © 加年份加公司名的东西叫版权声明，格式是三段式：版权符号或者Copyright字样、首次发表的年份、版权所有人的名字。美国版权局的版权声明通函把这三样列得清清楚楚。

关键在第二样：年份指的是首次发表的年份，不是今年。

这跟大多数人的直觉正好相反。很多人默认页脚年份要每年更新，不然显得站废了、显得没人打理。可按照这份文件的口径，一个2019年上线的网站，它首页的版权年份写2019才是准确的；改成2026反而丢掉了这个数字唯一的含义。作品有实质性修改时可以补上新年份，写成2019-2026那种范围式，但这是补，不是替换。

还有更釜底抽薪的一条：1989年3月1日之后发表的作品，版权声明本身就不是必需的了。美国加入伯尔尼公约之后，版权自作品完成时自动产生，写不写这行字都不影响权利归属。它今天的作用主要是提示和威慑，告诉别人这东西有主。

所以这是个很特别的字段：法律上不强制，写了的话年份有明确含义，而这个含义跟“我们还在营业”毫无关系。

它在HTML里也没有专属位置。HTML规范里的footer元素只说这里放的是“所属区块的附加信息，比如作者、相关文档链接、版权数据”，没有规定格式，没有规定字段，也没有任何机器可读的标记要求。谁想怎么写就怎么写。

116个站的页脚，有多少连一行版权声明都没有？

样本沿用这一系列一直在跑的那批海外品牌与电商独立站，服饰、家居、户外、3C、美妆、食品饮料都有，绝大多数是有独立品牌的中大型站。保哥把这131个站又跑了一遍，116个正常打开并拿到了完整页面，剩下的被反爬挡住或者超时，单独剔出去了。这批站在JS渲染那一轮里也是同一份名单，站点构成没变过。

每个站用真实浏览器打开首页，滚到底触发懒加载的页脚，然后把渲染后的正文文本全抓下来，在里面找版权标记：版权符号、Copyright字样、All Rights Reserved、保留所有权利，中英日韩几种写法都算。

结果是这样：

• 99个站写了版权声明，占85.3%
• 17个站一行都没有，占14.7%

17个不写的站里，有warbyparker.com、weber.com、shopify.com、nespresso.com、iittala.com这类量级不小的牌子。这不是疏忽，更像是主动放弃。页脚被塞满了政策链接、社媒图标、支付方式图标、订阅框，那行小字挤不进去，或者设计的时候就没打算留位置。页脚从来不是杂物抽屉，可它确实是全站最容易变成杂物抽屉的那块地方。

这一格里还藏着一个挺好玩的意外。stokke.com的页脚上找不到任何版权声明，但它的结构化数据里有：那段JSON-LD的description字段末尾跟着一句“版权所有 © 2025”。人在页面上看不到，机器读结构化数据的时候会读到。这句话大概率是文案在后台某个描述框里顺手写进去的，然后被整段塞进了机器读的通道。结构化数据是给机器看的那一层，往里塞人话不会报错，但也不会有人替你检查。

写了年份的站里，有多少还停在往年？

99个有版权声明的站，92个在声明里写了年份，占92.9%。剩下7个只有名字没有年份。avocadogreenmattress.com写的是 © Avocado Mattress, LLC.，harrys.com写的是Harry's, Inc. All Rights Reserved.，stanley1913.com写的是PMI WW Brands, LLC，都是一个名字加一句套话，年份不写。

92个带年份的站，年份分布是这样：

落后于今年的一共11个，占12.0%。最老的两个停在2022年：joolz.com的页脚写着 © Joolz 2022，theordinary.com写着 © DECIEM 2022。中间隔了三年多，这两个站在抓取时都能正常打开、正常下单。

还有7个站把年份写成范围，比如ikea.com的 © Inter IKEA Systems B.V. 1999 - 2026、bigcommerce.com的 © Copyright 2003 - 2031（后面这个数字待会儿会解释）。范围式其实是最贴近版权局那份文件原意的写法：起点是首次发表，终点是最近一次实质更新。写这种格式的只有7.6%。

如果故事到这里就结束，结论会是一句很平庸的话：大部分站的页脚年份是新的，少数站忘了改。但真正值得问的是下一句——那81个写着2026的站，这个2026是从哪儿来的？

怎么判断一个年份是谁算出来的？

这个数字有三种可能的来源，从外面看长得一模一样：

1. 有人在今年年初手工改过一次，把2025改成了2026
2. 服务端模板里写着取当前年的变量，每次生成页面时填进去
3. 浏览器里跑了一段JavaScript，用 new Date().getFullYear() 现算

光看HTML分不开前两种，但第三种可以单独抓出来，办法是骗浏览器。

具体做法是在页面加载之前注入一段脚本，把全局的Date对象换掉：无参构造和 Date.now() 一律返回2031年6月15日这个固定时刻，带参数的调用照常走原来的逻辑。这样页面里所有依赖“现在几点”的代码都会以为自己活在2031年，而服务端返回的HTML一个字节都没变。MDN上getFullYear的说明里写得很直白，这个方法返回的是“本地时间的年份”，本地指的就是运行这段代码的那台设备。

然后每个站访问两遍：一遍正常时钟，一遍假时钟，其余条件完全相同：同一个浏览器内核、同一个UA、同一个视口、同样滚到底、同样等页面稳定。两遍抓回来的版权片段并排放着比。

判据得先立住，不然会被噪音骗。同一个站两次访问未必拿到同一个页面：可能撞上验证码墙，可能A/B测试给了不同版本，可能促销条换了一批文案。这跟做爬虫与用户的内容差异比对时必须先补一组同条件对照是一个道理：不先扣掉页面自己的抖动，量出来的差异有一大半是假的。所以比对之前先做一件事——把两段文本里的数字全部抹掉，剩下的词做交集比例，低于0.85的直接判定为“两次不是同一个页面”，整站剔出这一格。

这一条真的拦下了东西。aliexpress.com第一遍撞上了滑块验证页，第二遍才拿到真页面，两遍的年份分别是2023和2025，看着像是被时钟影响了，实际上纯属两个页面。buckmason.com、marinelayer.com、peakdesign.com、wusthof.com也因为相似度不够被剔了出去。403和验证码不等于结论，它只等于这个样本不能用。做这类批量实测最容易犯的错，就是把被挡住当成一种测量结果，跟照抄爬虫黑名单是同一类毛病：名单上写着的，未必真来过。

最后能干净比对的是84个站。

把时钟拨到2031年，哪些站跟着走了？

16个。占84个可比对样本的19.0%。

而且这16个全部精确地变成了2031。不是2030，不是2032，就是我注入的那个年份。这排除了巧合的可能：它们读的确实是浏览器的时钟。

最后一行值得单独看一眼。bigcommerce.com写的是范围式 © Copyright 2003 - 2026，拨完表之后变成2003 - 2031：起点纹丝不动，终点跟着走了。同一行字里，一半写死在模板里，一半是访问者的当前时间。这大概是整轮数据里最精确的一个标本。

其中有一个站不用拨表也能看出来。bugaboo.com的页脚HTML里躺着这么一段：

document.getElementById('copyright-footer')
  .appendChild(document.createTextNode(new Date().getFullYear()))

找一个空的容器，把当前年份塞进去。用户在页面上看到的是 © 2026 | Bugaboo International B.V.，看不到这段代码。源码摆在这儿，拨表实验又独立验证了一遍，两条证据指向同一件事。

把84个站按来源分完，是这样三格：

最后一格反而是最诚实的那一格。anker.com的2025、burrow.com的2025、joolz.com的2022、theordinary.com的2022。这些数字是人写下去的，写的时候是对的，之后没人回头改。它至少携带了一条真实信息：这行字上一次被人碰是哪一年。

而变来变去的那16个，什么信息都没有。

拨表不变，就能说明有人在维护吗？

不能，这条得说清楚，不然上面那张表会被读歪。

拨表实验能干净切开的只有一件事：这个年份是不是浏览器算的。切不开的是另一件事——服务端给的那58个当年年份里，哪些是模板里的变量自动填的，哪些是今年真有人手动改的。

从外面看，Shopify主题里那句 {{ 'now' | date: '%Y' }} 渲染出来的2026，和一个人在后台把2025改成2026敲出来的2026，字节完全一致。没有任何外部信号能区分它们。

要真正定案，得看历史快照：翻这个站2025年12月的存档，如果那时写的是2025、今年变成2026，说明它会自己跟着年份走；如果2025年12月就已经写着别的，才说明有人在动它。这一轮没做这件事，所以这58个站我只能说“服务端给的”，不能说“自动的”，也不能说“有人维护”。

把没做的实验说成做过了，是这类量化文章最容易翻车的地方。这一格的边界就摆在这里。

另外还有一层：这一轮量的是首页页脚。同一个站的内页、结账页、帮助中心页，页脚有可能来自不同的模板。这在做按页面模板抽样的电商SEO审计时是个常识：一个站的页脚往往不止一份。

为什么这行字对搜索引擎几乎没有用？

把上面的结论翻译成机器视角，会得到一个很干脆的答案。

Googlebot抓页面时会执行JavaScript。那16个用浏览器时钟算年份的站，在Googlebot眼里，年份永远等于抓取当天的年份。抓一次是2026，明年抓还是当年。一个恒等于“现在”的字段，信息量是零——它没有任何时刻能告诉你这个站上一次被人动过是什么时候。

Google自己在关于页面日期的文档里说得也很明确：日期必须描述页面的发布或更新时间，不能是页面上所描述的那件事的日期；可见日期和结构化数据里的日期要对得上；不要写未来的日期。它推荐的做法是在页面上放一个带明确标签的日期（写清楚是“发布于”还是“最后更新于”），并配上 datePublished 或 dateModified。

这三条要求，页脚版权年份一条都不满足。它没有标签，说不清是发布还是更新；它是站级的，不是页级的；它在结构化数据里没有对应字段。它跟内容新鲜度是两个体系里的东西，中间没有任何管道相通。

这一点上很多人有个模糊的印象，觉得页脚年份旧了会“显得站不新”，进而影响排名或者影响AI引用。就目前公开的资料看，没有任何证据支持这条路径。真正被拿去判断新鲜度的信号在别处。sitemap里的lastmod是一个，页面级的dateModified是一个，条件请求里回的Last-Modified是一个，内容本身有没有变是最根本的一个。这几样都是页级的、有明确语义的，而且都比页脚那行字难糊弄得多。

顺带说一句相反的风险。要是有人真的听信了“年份要新”，跑去把lastmod或者dateModified全站刷成今天，那才是实打实的麻烦——刷日期不改内容，是内容新鲜度机制里最不划算的一种操作，真正该做的是把衰退的老内容分级挑出来重写，而不是给它们换个日期。想让AI答案愿意引用你，新鲜度要落在内容本身，不是落在时间戳上。页脚年份的好处恰恰在于它太不重要了，改错也没什么后果。

那机器到底靠什么判断一个站还在运营？

这才是页脚年份原本想回答、却回答不了的那个问题。

把这一系列跑过的实测数据摆在一起看，能被机器稳定读到的“这个站还活着”的信号，大致是这么几层，按可信度从高到低排：

• 内容层。 有没有新页面进来、老页面有没有实质改动。这是唯一没法伪造的一层，因为它要求你真的产出东西。前提是这些内容机器读得到。首页要是个连正文都没有的空壳，后面几层做得再好也没用。
• 服务端时间戳层。sitemap的lastmod、条件请求回的Last-Modified和ETag。这一层可以造假，但造假有代价。41万条lastmod的实测里，把整站刷成同一个时间戳的站一眼就能认出来。
• 结构化数据层。Article或BlogPosting上的datePublished和dateModified，商品页上的库存与价格。这一层的问题是同一个字段常常有好几份，机器得先决定信哪一份；连sitemap里提交的地址页面自己认不认账都得单独查一遍。
• 运营痕迹层。 促销活动的日期、客服工作时间、招聘页上的岗位、店铺列表。这些东西造假成本很高，因为它们要跟真实业务对得上，也是E-E-A-T那套信号里少数能从外部核验的部分。
• 页脚年份。 排在最后，而且跟前面几层不在一个量级上。

有意思的是，前四层里没有一层是给人看的。它们全在HTML里、在响应头里、在XML里。而页脚年份是唯一一个给人看的“时间证据”，恰好也是唯一一个什么都证明不了的。

这个错位挺常见。一个站在页面上摆出来的东西，和它在代码里交出去的东西，经常是两套互不知情的系统。首页上title、og:title和H1说的常常不是同一件事，canonical指的地方和页面自己认的地方对不上，都是同一类问题的不同切面。再往下还有更细的：工具说canonical在head、浏览器说在body，页面上最大的那行字未必是H1——人和机器读同一个页面，用的根本不是同一套眼睛。

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

说了这么多它没用，那要不要删掉？不用。它成本极低，还有一点提示作用。但可以让它别再说假话。

按优先级排一下：

第一，把它从“现算”改成“写死”。 如果你的页脚正在用 new Date().getFullYear()，把它换成一个固定的数字。这一条几乎不用讨论。现算除了让年份永远等于访问者的电脑时间，没有任何收益。顺便也省掉一次DOM操作。

第二，写范围式，起点用站点上线的年份。 比如站是2019年上线的，就写 © 2019-2026你的公司名。起点有真实含义，终点在你做了实质改版之后手工往前推。这是最贴近版权声明本意的写法，也是这一轮样本里只有7.6%的站在用的写法。

第三，把名字写对。 版权声明的三要素里，名字比年份重要得多。它是这个站唯一一处正式的自我署名，而这一轮里有相当一批站在这里写了一个跟品牌对不上的名字——这是另一篇的题目了。想让机器把你认成一个可信的实体，关于我们那一页和页脚这行署名是配套的两块。

第四，别把新鲜度的活儿指望它干。 想让机器知道你的页面在更新，该做的是这几件：

• 页面上放一个带明确标签的日期，写清楚是发布还是更新，并跟结构化数据里的 dateModified 保持一致
• sitemap的lastmod老老实实反映页面最后一次实质改动，别整站刷同一个值，写之前可以用时间戳转换工具核一遍时区有没有错
• 服务器对条件请求正确返回304，让爬虫能低成本地确认“这页没变”
• 内容本身真的在动

最后一句大白话：页脚那行年份，是全站唯一一个会自己保鲜的字段，也是全站唯一一个保鲜了也没用的字段。它每年自动变新的那点体面，恰好是它什么都不说的原因。

常见问题解答

页脚版权年份旧了，会影响搜索排名吗

没有公开证据支持这条路径。Google用来判断页面新旧的信号是页级的，主要看sitemap的lastmod、结构化数据里的日期、页面上带明确标签的可见日期，以及内容本身有没有变。页脚那行字既没有标签也没有页级语义，落不进这套体系。真要担心，先去检查lastmod和dateModified有没有说谎，那两个才是真会被读的。

用JavaScript现算年份，Googlebot会读到哪一年

抓取当天的年份。Googlebot执行JavaScript，new Date().getFullYear() 取的是执行时刻的时间，所以对爬虫来说这个字段永远等于当年。这也是它信息量为零的原因。它在任何时刻都只是“现在”的复述。

这一轮为什么把浏览器时钟拨到2031年，而不是往回拨

往后拨的信号更干净。往回拨的话，页面上原本就写着的固定年份也可能大于当时的时间，容易和现算的结果混在一起。拨到2031这个足够远又不至于让日期库溢出的年份，只要页面上出现2031，来源就只能是运行时的时钟。这16个站全部精确变成2031，没有一个变成邻近年份，说明这条判据是干净的。

拨表之后年份不变，是不是就说明这个站在正常维护

不能这么推。拨表只能证明这个年份不是浏览器算的，证明不了它是自动填的还是有人手动改的。这一轮里服务端给出当年年份的有58个站，这两种情况混在一起，从外部分不开。要区分得去翻历史存档，看跨年前后这行字变没变。

页脚干脆不写版权声明，有问题吗

法律上没问题。1989年3月1日之后发表的作品，版权自动产生，声明不是取得权利的前提。这一轮116个站里有17个就是这么做的，包括几个量级不小的牌子。真正会有麻烦的是另一件事：欧盟对在线服务商有强制的信息披露要求，名称、地址、登记号这些要让人随时找得到——版权声明可以不写，公司身份不能不给。

这一轮的数据能代表全网吗

不能。样本是131个有品牌的中大型电商独立站，实际用上116个，本身就是相对规范的一批。中小站和自建站的页脚只会更随意。另外这一轮只量了首页页脚，同一个站的内页、帮助中心、结账流程可能用的是另一份模板，结果未必一致。

权威参考资料