过时HTML标签实测：换个平台只是换一批老代码

摘要：把128个海外品牌站的首页源码逐行过一遍，找那些早已失效、却还留在页面上的老写法。一件都没有的只有18个站，每个站的中位数是3件，最多的一个站9件。给IE准备的兼容声明还留在48.4%的页面里，而IE已经退役四年。更有意思的是分组之后：Shopify站和非Shopify站的化石总量几乎一样（均值3.44对3.33），种类却几乎不重叠——前者多的是主题模板里的样板行，后者多的是自己历年攒下的meta标签。

打开任意一个大牌电商站，右键看源代码，往head里翻。你大概率会看到这么一行：

<meta http-equiv="X-UA-Compatible" content="IE=edge">

这行的意思是：如果你是IE浏览器，请用最新的引擎模式渲染，别退回兼容视图。

IE已经在2022年6月15日正式退役了。四年过去，这行还在48.4%的电商首页里躺着。

它不报错，不影响渲染，不拖慢速度，浏览器看一眼就跳过。它唯一的作用是提醒你：这个模板是哪一年写的，以及从那年之后没有人删过东西。

这一轮想量的就是这件事——把页面当成一个地层剖面，看看每个站的最底下那层是哪一年的。

怎么把一个页面当地层来测？

方法很朴素。先列一张表，把那些有明确退场时点的写法挑出来，每一条都能说清“它是什么时候不再需要的”。表现类标签这一批直接照着HTML规范里那份过时特性清单抄，不是我自己定的。

挑选标准有两条：一是它今天确实没用了，二是它当年确实是标准做法。第二条很重要——一个东西如果从来没被广泛采用过，它出现在页面上就不是化石，是意外。

然后抓131个海外品牌与电商独立站的首页，用真实浏览器，同时存两份：服务器直接返回的HTML，和脚本执行完之后的DOM。主口径用前者，因为化石是模板的产物，模板输出的就是服务端那份。128个站拿到了可解析的首页。

这里得先跟一件旧事划清界限。站内之前写过meta keywords对Google SEO到底还有没有用，那篇是讲一个标签该不该留、要不要清——结论来自Google在2009年9月那篇公开声明。这一轮不谈该不该，只谈还剩多少、分布长什么样、以及它们是谁留下的。

另一个可以对照的参照系是Web Almanac每年对全网标记用法的统计。那份统计的分母是几百万个各类网页，本文的分母是128个电商站首页，量级和构成都不一样，只能比方向不能比数值。

128个站的head里，都躺着些什么？

按站数排序：

document.write那条只剩2个站，值得一提——浏览器从2016年起会在慢网络下直接阻断它，也就是说留着它是要出功能故障的。有代价的东西，大家清得就快。

还有几条查了但一个都没查到：Flash资源、HTML 4文档类型、XHTML文档类型、AMP版本链接。这几样是真的清干净了，说明清理这件事不是做不到——只要有个明确的时点逼你动手（Flash停服、AMP在搜索结果里失去特权），大家还是会动的。

站一级的分布更直观：

• 一件化石都没有的，18个站，14.1%；
• 中位数是3件；
• 最多的那个站9件，是swarovski；
• 5件以上的，44个站。

顺带一提，这些站不是小作坊。样本里有奢侈品牌、有国际家电、有市值几十亿美元的DTC公司，页面本身做得相当精致。上一轮量正文可读性时那批空壳页还能说是技术选型的锅，这一轮的东西纯粹是没人回头看过。

为什么这些行能活这么久？

先排除一个最容易想到的答案：不是因为它们贵。

把每个站的化石按字节数算一遍，中位数是172字节。最夸张的parachutehome也就2281字节，而那个页面本身有2361KB。占比零点几个千分点。

所以这不是性能问题。正因为不贵，它才活了下来。任何一个需要排期的清理任务，都得先说清收益，而“删掉这行能省172字节”这种收益，永远排不进这个季度。

真正的原因有三层。

第一层，它们不报错。浏览器遇到不认识的meta标签，规范要求的行为就是忽略。没有告警，没有控制台红字，Lighthouse也不管。一个不报错的东西，等于不存在于任何人的待办清单里。

第二层，没人再打开那个文件。head这块地方本来就容易失控，连head到哪一行结束这种事都会有分歧，何况里面某一行该不该留。head区的模板通常在项目最早期就写完了，之后所有的迭代都在组件里。三年五年过去，团队换了两轮，那个文件谁都不敢碰——你不知道那行是不是有什么你不知道的作用。

第三层，也是最要命的一层：这些行大部分不是当年的开发者写的，是从别处抄来的。样板、脚手架、主题模板、某篇教程里的代码块。抄的时候就没搞清每一行的作用，后来更不会有人去搞清。

化石不是一堆，是两堆

把128个站按建站平台分开之后，事情变得有意思了。

平台判定单独跑了一轮，抓首页源码找cdn.shopify.com、myshopify.com、Shopify.theme、shopify-section、window.Shopify这几个确凿特征，命中才算Shopify。得到Shopify站59个，非Shopify站57个，另有12个站因为限流没判出来。

先看总量：

几乎一模一样。换个平台，页面上的老代码总量没变。

但拆开看种类，两边几乎不重叠：

上面那三行，全都出自Shopify主题的theme.liquid样板。你没写过它们，你甚至没见过它们，它们是你选主题那一刻附赠的。

下面那五行，全都是自己攒的：meta keywords是当年SEO教程教的，CDATA是XHTML时代的写法，禁用缩放是十年前为了防止移动端布局乱掉，磁贴配置是Windows 8那阵子的产物。那个http-equiv声明编码的写法也在这一堆里，编码声明写在哪一段字节里其实是有讲究的，只是今天已经没必要用那个长写法了。

换平台不会让你的页面变干净，只是把你自己攒的化石，换成了别人发给你的化石。

这跟“平台默认值”那件事是同一条线

之前量过一轮平台默认值：机器能不能从HTML推出该发什么请求，四个动作83个站只有1个全通，通得最多的两项恰好是平台自己实现的搜索和加购。那一轮说的是默认值替你做了什么。

这一轮说的是同一件事的另一面：默认值也是有出厂年份的，你继承它的时候，连同它的历史包袱一起继承了。

而且这份包袱你还不太好扔。meta keywords是自己写的，删一行就完事；X-UA-Compatible长在主题模板里，动它意味着改theme.liquid，意味着以后主题更新可能覆盖掉你的改动——换主题时该防的那几件事里，这类被覆盖的自定义改动排在很前面。

那24个还留着meta keywords的站，里面写的是什么？

这是本轮最有画面感的一组。24个站的keywords内容，逐个看：

• 3个站的content是空字符串——标签在，值没了；
• 3个站连content属性都没有，只剩一个光秃秃的<meta name="keywords">；
• 8个站里写的就是品牌名本身：bellroy写Bellroy，notino写notino，suitsupply写suitsupply，theordinary写它的母公司名DECIEM；
• 写得最长的是temu，441个字符；rapha写了348个字符，读起来像2008年的SEO作业。

那三个只剩空壳的最值得琢磨。它意味着某一次改版里，有人把填值的那段逻辑删了，却没删标签本身。标签活了下来，内容先死了。

这跟之前在三种页面上量到的一个现象是同构的：类目页有一行完整的描述标签，content却是空字符串——框架发下去了，填值那步没跟上。区别在于，那个是新东西没做完，这个是老东西没删干净。同一种病的两个方向。

一个head里，能同时住着相差十年的两代人吗？

能，而且很常见。

第一行是我最喜欢的一条。同一个head里，上面一行在跟一个2022年就退休的浏览器打招呼，下面一行在用只有现代浏览器才认的模块化脚本。中间隔着整整一个时代，谁也不知道谁的存在。

懒加载那三行也值得说。原生懒加载在2019年落地之后，data-src这套方案就没必要了。实测下来：只用原生的67个站（52.3%），两样都有的24个，只用data-src的10个，两样都没有的27个。浏览器给资源排优先级这件事已经有更细的手段，还在靠脚本控制图片加载的，多半是老组件没换。

还有22个站，图片格式已经上了webp甚至avif，加载方式却还是data-src。新格式换了，旧机制留着——这就是典型的往上堆，不往下挖。

留着这些老写法，到底有没有代价？

大部分没有。少数有，而且有的那几条挺要命。这一节的判断标准跟支付页那轮量CSP是一样的：不看它像不像问题，看它有没有真实后果。

先说没代价的。type="text/javascript"、type="text/css"、rel="shortcut icon"、http-equiv声明编码，这几样浏览器全都能正确处理，删不删都行。它们唯一的成本是让你的head看起来像2012年的。

再说有代价的，三条。

第一条，viewport里禁用缩放。16个站还这么写。这不是无害的历史遗留，它直接影响视力不好的用户能不能放大页面看清楚。现代移动浏览器出于无障碍考虑大多会忽略这个限制，但你不该指望浏览器替你纠错。

第二条，jQuery的版本。运行时检出jQuery的有33个站，占25.8%。把版本号排一排：从1.7.1到3.7.1都有。其中17个站（51.5%）跑的版本低于3.5.0，落在两个已公开的跨站脚本公告的影响范围里；11个站低于3.0.0。这不是“看起来老”的问题，是实打实的已知风险。锁死第三方脚本版本这件事本身有它的代价，但锁死在一个有公开公告的版本上，代价就换了性质。

第三条，microdata和JSON-LD并存。只有5个站，比例不高，但这一类最麻烦：两套结构化数据描述同一个东西，字段还不完全一致，机器读到的是两个互相打架的版本。主题一套、插件一套在head里撞成一团是同一类问题的另一个形态。

清完之后记得验一遍语法，一个尾逗号就能让整页结构化数据失效，删标签时手一滑很容易碰到旁边那段JSON。

另外有10个站只有microdata、没有JSON-LD。这不算错，microdata至今仍是有效写法，但主流工具链和文档这些年都倒向了JSON-LD，继续用microdata意味着你能找到的排查资料越来越少。

还有人在给你造新化石

把服务端那份HTML和渲染完的DOM对比一下，会发现一件事：老写法不只是存量，还在增量。

以type="text/javascript"为例：服务端就有的93个站；另有18个站服务端一处都没有，脚本跑完之后出现了；还有89个站数量比服务端更多，加起来多出1568处。

这些多出来的script标签，是第三方脚本在运行时注入的。分析工具、客服插件、评价组件、广告代码——它们的加载器很多写于好几年前，注入时还带着当年的写法。这些第三方本身还会自己悄悄变，两天半里四分之一的站变过一次，你连它哪天换了写法都不会知道。

装得越多这件事越明显。应用栈臃肿会同时拖慢店铺和烧钱，顺带还替你的页面添了一批不归你管的老写法。

microdata也有类似情况，渲染后多出111处标注。

换句话说，就算你把自己模板里的老写法全清了，页面上还是会长出新的来，而且长出来的那部分不归你管。第三方脚本会往页面里拉进多少东西，只看HTML完全看不出来，这一条又添了一个新的观察角度。

化石是全站的还是单页的？

顺手验了一下。在三种页面都抓齐的那批站里：

• X-UA-Compatible：41个站三种页面都有，只有2个站是部分页面有；
• type="text/javascript"：56个站三页都有，2个站部分有；
• meta keywords：5个站三页都有，2个站部分有。

结论很清楚：化石长在模板层，不长在页面层。这其实是好消息——要清就是改一处模板，不是逐页处理。跟审计按模板抽样而不是按网址逐条查是同一个道理：几万个页面上的同一个问题，落到代码里往往只有一行。

哪些该删，哪些别乱动？

按优先级分成三档。

第一档，尽快处理，因为有实际代价：

• viewport里的user-scalable=no和maximum-scale=1，直接删掉，这是无障碍问题；
• 低于3.5.0的jQuery，升级或者移除，先确认没有别的组件依赖它。顺带把服务器那边的版本暴露也一起收了，版本号写在响应头里等于给人递名片；
• microdata与JSON-LD并存的，二选一，通常留JSON-LD。

第二档，顺手清掉，成本几乎为零：

• meta keywords、revisit-after、rating、distribution这些从没被采纳过的标签；
• X-UA-Compatible，IE已经退役；
• apple-touch-icon-precomposed，iOS 7之后就不区分了；
• 脚本里的CDATA包裹，HTML5解析器不需要它。

第三档，别乱动：

• type="text/javascript"和type="text/css"，删掉当然更干净，但如果它们由主题模板统一输出，改动的风险大于收益，等下次主题升级顺带处理；
• rel="shortcut icon"，所有浏览器都能正确解析，动它没意义；
• 新闻站的news_keywords，长得像meta keywords，但它是另一回事，别误删；
• data-src，如果你的懒加载逻辑还依赖它，别为了追求新写法把功能改坏。先改成原生loading属性，验证没问题再拆旧代码。

保哥给客户清这类东西时的顺序是：先删完全无用的（第二档），再处理有风险的（第一档），第三档写进技术债清单，等有别的理由动那个文件时一起改。分开三次做，比一次全改安全得多。

怎么给自己的站测一次年？

不需要工具，五分钟能跑完。

打开首页源代码，依次搜这几个字符串，搜到就记一笔：

X-UA-Compatible
name="keywords"
text/javascript
shortcut icon
data-src=
user-scalable
itemprop=
<![CDATA[
precomposed
msapplication

记完之后做两件事。

一是数一下总数，跟本文的中位数3件对一下位置。超过5件说明这个模板确实很久没人动过了。

二是对每一条问一句：这行是我写的，还是主题带的？判断方法很简单——去主题的原始文件里搜同一个字符串，搜得到就是主题带的，搜不到就是自己加的。这两类的处理方式完全不同：自己加的直接删，主题带的要考虑升级覆盖的问题。

如果连着几个站都测下来发现同一批东西，那多半不是巧合，是你们团队一直在复用同一份head模板。找到那个文件，从源头改一次，比在各个站上分别改高效得多。

页面只会往上堆

顺便回答一个常被问到的问题：换CMS能不能顺手解决这些。Google并不偏爱某个建站平台，换平台带来的是另一套默认值，不是一次清零。本轮那两组几乎相等的中位数，就是这句话最直接的证据。

软件这行有个不太被承认的事实：加东西有人推动，删东西没人推动。加一行有需求方，有排期，有验收；删一行只有风险，没有收益，谁都不想签这个字。

于是页面就变成了一份地层剖面。最上面是今年新加的模块，往下是去年的埋点，再往下是三年前的组件，最底下压着一行给IE的兼容声明，静静躺了十年。

好消息是它基本无害。坏消息是，当你想搞清楚“我的页面到底给机器看的是什么”的时候，你得先把这十年的沉积物挖开。

常见问题解答

删掉这些老标签，会影响现有排名吗

不会。这些标签要么早就被忽略，要么本来就是浏览器的默认值，删掉不改变页面对搜索引擎呈现的任何有效信息。唯一需要留神的是别误删——比如news_keywords长得像meta keywords但仍在被Google News使用，viewport整行不能删只能删里面的缩放限制。稳妥的做法是先在测试环境删完对比一遍渲染结果，确认没有视觉差异再上线。

X-UA-Compatible这行删了，老用户会不会打不开网站

不会。IE11已于2022年6月15日结束支持，Windows上的IE入口大多已被重定向到Edge。而Edge即使在IE模式下也不依赖页面里的这行声明，它由组策略和站点列表控制。真正还在用IE访问电商站的用户比例，现在基本可以忽略。如果你的后台系统仍需IE兼容，那是另一套内网页面的事，跟对外站点没有关系。

我的站是Shopify主题带的这些老写法，能改吗

能改，但要考虑升级覆盖。改动theme.liquid这类文件后，主题官方更新时你的改动可能被覆盖掉。可行的做法有两种：一是改完之后把改动记录在版本管理里，每次升级后重新比对一遍；二是判断这些老写法值不值得改——像type="text/css"这类完全无害的，等主题自己更新掉更省事。有实际代价的那几条（禁用缩放、老版本jQuery）才值得承担升级维护的成本。

怎么判断一行老代码是我自己写的还是平台默认的

去主题或框架的原始文件里搜同一个字符串。搜得到说明是平台带的，搜不到就是自己或某个插件加的。实测里这两类的分布很不一样：Shopify站的X-UA-Compatible出现率是66.1%，非Shopify站只有28.1%；反过来meta keywords在Shopify站只有1.7%，非Shopify站高达38.6%。分清来源之后，处理方式和风险评估都不一样。

页面上有microdata又有JSON-LD，一定要删一个吗

如果两者描述的是同一个实体，建议只保留一套，通常留JSON-LD。两套并存本身不违规，Google也说过会尝试合并理解，但当两边字段不一致时，结果是不可预测的——你不知道它最终采信哪一边。实测里只有5个站是这种状态，占比不高，但排查起来最费时间，因为报错工具往往只提示冲突，不告诉你冲突来自哪一套。

第三方脚本注入的老写法，我该管吗

管不了，也基本不用管。这类注入出来的script标签带着老写法，对渲染和抓取都没有影响。真正需要管的是这些脚本本身：它们拉进来多少域名、有没有拖慢首屏、有没有引入已知漏洞的库。老写法只是个信号，提醒你这个第三方组件的加载器可能很多年没更新了，顺着这条线去查它的版本，比纠结那个type属性有意义得多。

为什么Flash和AMP这类东西反而清得很干净

因为它们有明确的终止时点，而且不清会立刻出问题。Flash停服之后，留着的资源会直接显示成空白框；AMP在搜索结果里失去特权之后，维护两套页面的成本立刻显得不划算。相比之下，X-UA-Compatible这类东西留着不会出任何问题，也就没有任何人有动力去删。实测里前者是零，后者接近一半，这个对比本身就说明了清理的驱动力从哪来。

权威参考资料