隐藏内容机器算不算？16种藏法的实测裁决表

摘要：118个海外独立站的首页各取两个数——文档树里的全部文字，和用户实际看得见的文字。比值中位数0.461，也就是说过半的站，页面上一半以上的字用户根本看不到。更意外的是那些字的构成：全部隐藏文字里占比最大的一块既不是商品也不是导航，是cookie同意条款，占32.2%，在最极端的一个站上占到整页文字的88.0%。另在本机造了16种藏法各一个页面，让8个读取器逐一去读，答案互不相同：人眼完全看不见的三种，机器全部照读；另有两种人眼同样看不见的，浏览器自己就不算。

做上一篇实测的时候顺手多取了一个数，本来只是备用。跑完发现这个数比原本要量的那个有意思得多。

那个数很简单：一个页面的文档树里一共有多少文字，和用户睁眼能看到多少文字。两者的差，就是“在页面上、但你看不到”的那部分。

直觉上这个差应该不大——毕竟页面是给人看的。实测下来中位数是一半。

这个话题跟前一篇是同一批数据的两个侧面：那边问的是“不执行脚本的一方拿到多少”，这边问的是“执行了脚本、内容也都在了，用户又能看到多少”。两个问题的答案指向的处理动作完全不同。

页面上有多少字是用户看不见的？

先把两个数的取法说清楚，因为这两个数长得像，含义完全不同。

两个数怎么取的

一个是文档树里的全部文字：把页面主体复制一份，删掉脚本、样式、待用模板、矢量图、内嵌框架这几类不属于正文的节点，剩下的文字全算，包括那些被CSS藏起来的。

另一个是用户看得见的文字：浏览器渲染完之后，渲染树里真正呈现出来的那部分。被 display:none 或 visibility:hidden 干掉的节点不在里面。

顺带说清一个容易混的概念：hidden 这个属性的语义并不是“这段内容不存在”，HTML规范里对hidden属性的定义写的是“当前不相关”。内容还在文档里，只是这一刻不该呈现给用户。这个区别是本文所有结论的起点——藏起来和不存在，从来不是一回事。

两个数在同一次访问、同一个浏览器实例里取，只差一个取法。这一点很关键——如果一个数用浏览器取、另一个用命令行工具抓HTML再解析，量出来的差里会混进“抓取身份不同”的成分，那就没法归因了。

还得说清一件事，“看得见”在这里指的是不用滚动也在渲染树里，不等于“打开就在首屏”。一个在页面最底部的段落照样算看得见。这个口径比“首屏可见”松，所以下面这些数字是保守的。

可见率的中位数是0.461

118个可比站（文档树文字超过200字符的），可见率分布如下：

可见率不到一半的站有63个，占53.4%。10% 分位是0.106，也就是说十分之一的站，用户看到的字不足页面总字数的九分之一。

最极端的几个：allbirds 91336个字符里只显示2377个（2.6%），bolia 3.7%，jackery 4.8%，menuspace 5.5%，bugaboo 6.1%。

对照组：16个站写什么就显示什么

另一头有16个站可见率超过95%：anker、article、babybjorn、bonprix、buckmason、ecoflow、gymshark、ikea、mejuri、peakdesign等等。

这批站的存在很重要，它们证明两件事。第一，测量本身没问题——如果取法有系统性偏差，这16个站也该出现落差。给每一次对比配一组本该没有差异的样本，是这类实测最省事也最容易被跳过的一步，之前吃过亏，教训记在页面抖动基线与差异误报那篇里。第二，也是更实际的一点：一个正经的电商首页，完全可以做到把绝大部分文字直接显示出来。这不是行业限制，是选择。

看不见和读不到，是同一件事吗？

上面那个数只说明“用户看不到”。至于机器读不读得到，得单独测。

在本机造一批只差一处的页面

观测别人的站有个天然的局限：你只能看到它已经做成什么样，不能问“如果换一种做法会怎样”。所以这次另搭了一个台子。

这种自建对照的思路在效果验证类的实验里更要紧，因为那边连“什么算没有效果”都得自己造出来，做法写在给GEO建议配一个注定无效的对照组里。

做法是在本机起一个小服务，按参数生成16个页面。每个页面结构完全相同，唯一的区别是那段被测文字用哪种方式藏起来：行内 display:none、外部样式表的隐藏类、hidden 属性、aria-hidden、未展开的 details、手写折叠面板、visibility:hidden、高度压到0、待用模板、noscript、挪到屏幕外、content-visibility:hidden、透明度0、脚本注入、inert，外加一个完全正常显示的对照。

每段被测文字里埋一个唯一标记词，然后让8个读取器去读，看谁能搜到那个标记词。

那个锚点是整套设计里最要紧的一步

每个页面上还另放了一段永远正常显示的文字，也带唯一标记，充当锚点。

它的作用是分辨两种失败：如果连锚点都没读到，说明这次抓取压根没成功，跟被测的藏法无关。没有锚点，“读不到”和“没抓到”会混成一团，而这两件事的结论正好相反。

这个设计当场就救了一次。第一版用某个接口去读无障碍树，结果连完全正常显示的对照都读不到——按那版数据写出来的结论会是“无障碍树里什么都没有”，纯属胡说。换了取法之后，锚点在16个页面、两种脚本状态下全部命中，前面的数据才敢用。

还有一条：台子必须搭在本机。线上的运行环境会自动补一些响应头，网页服务器还会再补一次，想造出“什么都不声明”的干净场景根本做不到。

8个读取器，16种藏法，答案互不相同

下面这张表是实测结果。“读到”记Y，“读不到”记横杠。

先说怎么看这张表。绝大多数行的形态是一样的：前三列全Y、中间三列全横杠、后两列全Y。真正值得停下来看的是五行——aria-hidden、高度压到0、待用模板、content-visibility、inert，以及最后的脚本注入。它们各自打破了一种直觉。

第一条结论：决定机器读不读的，不是你能不能看见

把上表按“人眼能不能看见”重排一下，会看到一件很反直觉的事。

高度压到0、透明度0、挪到屏幕外这三种，人眼完全看不见，但六个机器口径全部照读——包括本该只统计“可见文字”的渲染树取法。而 visibility:hidden 和 content-visibility:hidden 人眼同样看不见，渲染树却不算它们。

分界线在于节点还在不在渲染树上。display:none 和 visibility:hidden 会把节点从渲染树里摘掉或标记为不呈现；而透明、零高度、屏幕外这三种，节点老老实实待在渲染树里，只是位置或颜色让你看不见。MDN对innerText的定义说的就是这层区别：它取的是渲染树里的文本，不是文档树里的。

实务上的意思是：那些为了无障碍而放的屏幕外文本，在所有机器口径下都是算数的。写太多、写得跟正文不一致，是会被读进去的。

第二条结论：两个无障碍量法自己会打架

这一条跑之前完全没想到。

同一个页面，用浏览器的无障碍快照和用底层协议取的完整无障碍树，对三种藏法给出了不同答案：content-visibility:hidden 快照读得到、完整树读不到；inert 快照读得到、完整树读不到；aria-hidden 两个都读不到，但渲染树读得到。

换句话说，同一段字在无障碍这一层是不是“存在”，取决于你用哪个工具去问。做审计的时候这件事很要命——换个工具，报告结论就翻个面，而两份报告都会显得很确定。工具自报的准确率往往解决不了这个问题，因为那个分母常常是它自己划的，这一点在审计工具准确率的分母问题里拆过。

分歧集中在 content-visibility 和 inert 这两个较新的属性上，这并不奇怪：前者的设计初衷是让浏览器跳过屏幕外内容的渲染工作以提速，web.dev关于content-visibility的说明讲的是性能，不是内容可见性，各家工具怎么在无障碍层面对待它并没有一致答案。站内之前专门写过这个属性的机制与用法，见content-visibility与渲染跳过。

aria-hidden 那一行值得单独记：它是唯一一个“眼睛看得见、无障碍层看不见”的组合。MDN关于aria-hidden的说明里明确写着它只影响无障碍树、不影响视觉呈现。所以拿它来藏内容是无效的，它藏的是给读屏软件用的那一份。

第三条结论：真实采集管线基本什么都不挑

最右边那两列是真实内容管线里常用的两个工具：一个正文提取器，一个文档转换器。

16种藏法里，它们只有两处读不到：待用模板里的内容（提取器读不到，转换器读得到），以及脚本注入的内容（两个都读不到，因为它们不执行脚本）。剩下14种，全部照单全收。

这件事跟很多人的预期正好相反：你把内容折叠起来是为了让页面清爽，但在这一层读取方那里，页面一点都没变清爽。它拿到的是全部文字，而且没有任何线索告诉它哪些是主要内容、哪些是备用面板。抓取、渲染、提取这三段各自会在哪里卡住，站内有一篇GEO技术端的抓取渲染提取做过整体拆解。这类正文提取库的文档里说明了它工作在HTML层，本来也不具备判断可见性的能力。

被藏起来的那些字，到底是些什么？

知道藏了一半之后，下一个问题自然是藏的都是什么。这次把每个隐藏块按它的类名和标签特征归了类。

归类靠的是类名和标签名里的关键词，所以有12.8% 落进了“未能归类”。这一档必须如实标出来，因为它可能同时包含几种用途，也可能是我这套关键词没覆盖到的写法。把它当成误差上界看就行。想直观比一比爬虫和用户各自拿到什么，站内有一款渲染对比器可以直接跑，比手工翻源码快。

隐藏块里装的不只是文字

还有三个数：72.0% 的站在隐藏块里放了标题标签（最多的一个站藏了1126个），91.5% 的站在隐藏块里放了链接，49.2% 的站藏了带价格的内容，64.4% 藏了表单或输入框。

链接这一项最值得注意：隐藏链接占全站链接总数的比例，中位数是55.0%，90% 分位是82.6%。parachutehome的8493个链接里有7736个在隐藏块里，占91.1%。

这条跟上一篇的结论正好接得上：那边测出来关掉脚本之后链接基本不丢，说明链接本来就在HTML里；这边测出来一半以上的链接在隐藏容器里，说明它们虽然在，但用户得先点开菜单才看得到。两个结论合起来才完整：链接在页面上，只是不在页面表面。不同渲染方式对内容能不能被读到的影响，在关掉脚本之后还剩多少字的实测里量过一遍。

为什么字数最多的一块是cookie同意书？

上面那张表最反常的一行是第一行。

32.2% 这个数是怎么来的

把118个站的全部隐藏文字加起来，其中三分之一出自同意与隐私条款这一类块。而这类块只出现在41个站上——也就是说，34.7% 的站贡献了32.2% 的隐藏文字量。

单站看更夸张。这41个站里，同意条款文本占整页文字的比例中位数是17.8%，最极端的几个：

jackery首页文档树里一共13.6万个字符，其中9万个是cookie说明；joolz更彻底，整页文字的88% 是同意条款。

这些字是从哪来的

看一眼具体内容就明白了。这些块里装的是同意管理平台生成的完整分类说明：每一类cookie的定义、用途、存续期，以及逐条列出的第三方供应商清单。有的还带着行业框架的模板占位符，那种一看就是没被填充的字段名。

这些说明默认是折叠的，用户要点“管理偏好”再点“详情”才展开。也就是说，这几万个字符从头到尾没有一个用户读过，但它们完整地待在每一次响应里。

同意弹层这一层还有个连带影响：在用户点同意之前，很多站的翻译脚本和个性化脚本都不许跑，首屏能显示什么就被这个顺序锁死了，这个连锁反应在同意弹层与首屏语言里单独讲过。

这件事的三重代价

第一重是字节。这几万字符每次请求都发一遍，对用户是流量，对抓取方是带宽。页面体积撑大之后还会撞上另一条线——抓取器对单个页面有取回上限，超了就截断，这个维度在页面字节预算与抓取截断的实测里量过。

第二重是内容信号被稀释。一个不执行脚本、也不判断可见性的提取器拿到这个页面，看到的是一篇大半篇幅在讲cookie分类的文档——上表里最狠的几个站，这一块占到整页文字的七成到九成。它不知道这部分该忽略。你以为自己的首页在讲产品，机器读到的可能是一份隐私政策。

第三重更微妙：这些文本高度同质。同一个同意管理平台生成的说明文字，在几十个站上几乎一字不差。也就是说，几十个电商首页共享着一大段完全相同的内容，而这段内容还占了各自篇幅的一大块。

该怎么处理

不是把同意弹层删掉——合规要求摆在那儿。可做的是三件事，成本递增：

• 把详情文本改成按需加载：用户点“详情”的时候再去取那几万个字符。多数同意管理平台支持这个配置，只是默认不开。这一步性价比最高。
• 把它挪出主文档：放进独立的内嵌框架或独立页面，这样它就不算在本页文字里了。
• 如果不能挪，至少量一下：把“同意条款占整页文字的比例”加进例行检查，超过某个阈值就报出来。别等到有人问“为什么首页摘要里全是cookie”才发现。

导航菜单藏了多少链接？

第二大的那一块是导航菜单，83.1% 的站有这类隐藏块，占全部隐藏文字的28.9%。

文字不多，链接极多

导航菜单这一类的特点跟同意条款正好相反：它文字量排第二，链接数排第一——12842个，是同意条款那一类的23倍。单站看，导航菜单隐藏块里的链接数中位是62个，最多的一个站放了1692个。

这些就是俗称的大菜单：鼠标悬停或点击才展开的多列面板，一列一个品类，一行一个子类。默认状态下整块 display:none，用户不动它就一直藏着。

顺带一提，同一批站里首页对外的自我描述本身就常常各说各话，标题、社交卡片标题和主标题三者对不上的比例相当高，那一层量在首页六份自我描述的实测里。

这算不算问题

大部分情况下不算。这一点得先说清楚，免得看完就去动菜单。

理由是这类链接在文档里是实实在在的 <a href>，抓取器沿着它们爬得到下一层。链接能不能被发现，取决于它是不是标准的锚元素、带不带href，跟它当下显示不显示没有关系。上一篇实测里关掉脚本之后链接基本不丢，也是同一件事的另一个侧面。

真正值得关注的是另一件事：这些链接的锚文本，多数只有一两个词。“新品”“全部”“男士”“配饰”——它们放在菜单里靠上下文表意，单独拎出来给机器看就没什么信息量。而一个站上过半的链接都是这种形态时，整个站的链接语义就被稀释了。

可做的动作很轻：给最重要的那批分类入口，在页面正文里另放一处带完整锚文本的链接。不是替换菜单，是补一处。

藏在暗处的那些标题标签，会打乱大纲吗？

前面提过一个数：72.0% 的站在隐藏块里放了标题标签。这个数值得单独拆一拆，因为它牵扯的是页面结构，不只是文字量。

数量大到不像话

隐藏块里的标题标签数量中位是12个，最多的一个站藏了1126个。一个正常首页可见的二级标题通常也就六到十个，这意味着不少站在暗处放着比明处多一个数量级的标题。

这些标题从哪来的？拆开看主要是三类：大菜单里每一列的列头被写成了标题标签；商品卡片模板里每张卡的商品名是标题标签，而未展开的推荐位里躺着几十上百张卡；同意弹层里每一类cookie的名称也常被写成标题。

为什么这件事不像看上去那么严重

直觉上，一个页面有一百个标题标签听着很糟。但把它放回实际场景，影响比想象的小，原因有两层。

第一层是标题标签的作用主要在于表达内容组织，而不是当计数用的信号。一个模板批量生成、结构规整的标题群，不太会让内容组织被读错。

第二层更实际：这些标题绝大多数是模板批量产出的短词组，形态高度一致。它跟“一篇文章里胡乱嵌套标题层级”是两回事，后者才是真正会让大纲混乱的做法。页面上标题层级本身该怎么排，站内另有一篇前端与SEO协作的动作清单讲过。

真正该管的是另一件事

比数量更值得管的是重复。多语言站把几套语言的标题都塞进同一个文档、响应式设计放两套菜单，都会让同一批标题在页面上出现两遍甚至三遍。

这个可以直接量：把所有标题标签的文本取出来，看去重之后还剩多少。如果去重率低于一半，说明页面上装着整块副本，那才是要处理的。而这一类问题跟“藏没藏起来”无关，展开的时候一样存在。

那这些藏起来的内容，会不会被当成作弊？

这个话题绕不开这一问，而且两头都有人说错。

先划清界限

Google的垃圾内容政策里确实有“隐藏文本和链接”这一条，但它针对的是特定意图：为了操纵排名而放置用户看不到的文字，比如白底白字、字号设成0、把文字挪到屏幕外堆关键词。

判据在意图和形态，不在“有没有用CSS藏东西”。折叠菜单、选项卡、手风琴式的常见问题，这些都是正常的界面模式，页面上有个控件能把它展开，用户能看到。它们跟“藏一段关键词让用户永远看不到”是两回事。

但有一类确实踩线

需要小心的是屏幕外文本那一类。前面的实测已经说明，挪到屏幕外的文字在所有机器口径下都算数，包括无障碍树。这原本是给读屏软件用的正当技术，但如果往里塞的是关键词列表、或者跟可见内容完全不同的另一套描述，那形态就跟政策里点名的做法一模一样了。

一条实用的自查：把屏幕外文本全部提取出来读一遍，问一句“如果一个人用读屏软件听到这段，他会觉得合理吗”。答案是否，就该改。

还有一类是无心的

更常见的其实是没人注意的那种：多语言站把所有语言版本的文案都塞在同一个页面里、靠CSS切换；或者响应式设计做了桌面版和移动版两套菜单，两套都在文档里、按屏幕宽度显示其中一套。

这些都不是作弊，但后果是同一段内容在页面上出现两三遍。检查方法是把隐藏文字提取出来，跟可见文字做一次重复度比对，重复率高就说明有整块副本。

同一件事在页面上被说了不止一次，还有更隐蔽的形态：同一个字段被声明两遍、两遍还不一样，那时候赢的是位置靠前的那条，实测记在重复声明的裁决实测里。

这套检查该怎么做？

落到自己站上，这件事比上一篇那个更容易查，因为不需要跑两轮。

三行代码就能量出那个比值

在浏览器控制台里取两个数：一个是页面主体剔掉脚本样式之后的全部文字长度，一个是渲染出来的文字长度。两者相除就是可见率。

如果一个页面的正文本身就少得可怜，那量可见率之前得先确认它到底有没有正文，判据与实测在空壳首页与可读正文的实测里。

拿到数之后先别急着下结论，先看它落在哪一档。这次实测的中位数是0.461，四分之一的站在0.279以下。如果你的站在0.5上下，属于正常范围；掉到0.2以下，就该看看藏的是什么了。

接着看构成，这一步比比值重要

光有一个比值没法行动，得知道那一半字是什么。做法是把所有被隐藏的顶层容器捞出来，按文字量排序，看前十个。

按这次的分布，前十个里大概率会有：同意管理弹层的详情文本、大菜单、订阅弹层、地区选择器。看到同意条款排第一不用惊讶，34.7% 的站都是这样。

三类处理方式

什么不该做

有两个常见的过度反应值得拦一下。

一个是把折叠内容全部改成默认展开。这会牺牲真实的用户体验，而换来的机器侧收益接近于零——前面的裁决表已经说明，除了待用模板和脚本注入这两种，机器本来就全都读得到。

另一个是给隐藏块加各种标记，试图告诉机器“这块不重要”。目前没有任何一个被广泛支持的标记能表达这个意思。真想让某块内容不参与，唯一可靠的办法是把它挪出这个文档。

这类“写了一条指令但没有任何一方会读它”的情况在别处也反复出现过，抓取指令那一层的统计见写了没人读的抓取指令实测。

把它接进例行检查

这个比值适合做成常态监控，因为它的变化几乎总是有原因的：换了同意管理平台、加了新的弹层、菜单改版。

做法是每次构建后对几个关键模板各算一次可见率，写进日志。阈值用自己上一次的数当基线，跌了就去看隐藏块排行的前十个变了什么。比起绝对值，这个数的变化更有诊断价值。

常见问题解答

折叠起来的常见问题，搜索引擎算不算数？

算。折叠内容在文档里是完整存在的，实测里除了待用模板和脚本注入两种形式，其余全部藏法在各类读取器下都能被读到。折叠是界面选择，不影响内容被发现。真正需要注意的不是算不算，而是别把大段无关文本一起折进去。

我的站可见率只有0.3，要紧吗？

看构成，不看数字本身。这次实测有32.2% 的站落在0.25到0.5之间，这是最常见的一档。如果那70% 藏起来的字是大菜单和同意条款，属于正常形态；如果是整块商品描述的重复副本，或者是屏幕外的关键词，那才要处理。

用aria-hidden能不能把内容对机器藏起来？

不能。实测显示aria-hidden只让内容从无障碍树里消失，渲染树、文档树、正文提取器全都照读，用户眼睛也照样看得见。它藏的恰恰是给读屏软件用的那一份，用来当内容开关是用反了。

屏幕外文本会不会被判作弊？

取决于里面写了什么。屏幕外文本本身是无障碍领域的正当技术，实测中它在所有机器口径下都算数。判据是内容合不合理：如果是给读屏软件用的说明文字，没问题；如果是关键词列表或者跟可见内容不一致的另一套描述，那形态就跟垃圾政策点名的做法一样了。

同意条款的文字真的会影响内容判断吗？

这次实测能确认的是它确实占据了大量篇幅——41个站里中位数占整页文字的17.8%，最高88.0%。至于这对排名或引用有多大影响，这次没有测，不能下结论。可以确定的是它增加了字节、稀释了主题集中度，而且这几万字符从来没有用户读过，改掉的成本又很低。

为什么两个无障碍工具会给出不同答案？

因为它们取的是无障碍树的不同快照层级，对content-visibility和inert这类较新的属性处理不一致。实务上的意思是：做无障碍或可读性审计时，先用一个完全可见的对照页确认工具本身没问题，再看结论；换工具的时候要重新对一遍基线，不能直接比两份报告的数字。

把菜单改成默认展开会不会更好？

不会。机器本来就读得到菜单里的链接，改成展开对它们没有增益，反而会破坏用户体验。真要优化，方向是给重要分类补几处带完整锚文本的正文链接，而不是动菜单本身。

这次的数字能不能直接套到我的站上？

不能。样本全是海外电商与品牌独立站，首页的模块化程度天然偏高，隐藏比例会比内容型站点高一截。可以借用的是方法和分类框架，数字要自己量。

权威参考资料