页面体积实测46个电商站，4个的商品链接谷歌根本没读到

摘要：一个页面超出抓取上限50%却一样东西都没丢，另一个只超27%就丢光了全部结构化数据——这两件事同时出现在保哥这次的实测里。46个真实电商与建站平台的页面逐字节量完，中位数吃掉46.4%的额度，4个越线，7个用掉八成以上，最紧的那个组合装页余量只剩23字节。真正吃掉额度的既不是商品也不是文案，是前端框架为了在浏览器端接管页面而内联的那份数据副本；实测里最大的一个这样的标签，比整条上限还长287272字节。而从头到尾，没有任何一个环节会报错。

Googlebot为什么会读到一半就停下来？

2026年3月31日，谷歌搜索团队的Gary在搜索中心博客上写了一篇罕见的内部机制文，题目是《Googlebot内幕：把抓取、取回和我们处理的那些字节讲清楚》。这篇文章里最值得反复读的不是任何一条优化建议，是它对一个动作的描述方式。

它不拒绝，它只是停下

原文的句子是这样的：如果你的HTML文件大于2MB，Googlebot不会拒绝这个页面，它会在正好2MB的位置停止取回。这句话里有两个动词，一个是不会拒绝，一个是停止。它们描述的是同一次抓取，但落到你这边是两种完全不同的处置。

这套流程完整走一遍是几个独立的阶段，搜索引擎抓取和渲染DOM分几步那篇把每一步会在哪里丢内容拆开讲过，本文说的截断发生在第一步。

拒绝会留下痕迹。抓取失败会在Search Console的抓取统计里变成一条曲线，会在服务器日志里对应一个非200的状态码，会在你的监控面板上触发一次告警。停下不会。停下之后，前面那部分字节被原样交给索引系统和网页渲染服务，而且是当作完整文件交上去的。

会报错的系统是在替你干活。停在半路而不报错的系统，只是安静地把你的一部分内容从这个世界上取消掉了。

被取消的那部分到底怎么样了

Gary把这件事写得很干脆：2MB阈值之后的任何字节都会被完全忽略，它们不会被取回、不会被渲染、也不会被索引。三个动词全否，没有留任何余地。

这条上限本身的成因和常规优化步骤，Googlebot抓取2MB限制的8步实战那篇已经讲过，本文不再重复，只补它没覆盖的落点问题。

抓到了不等于进索引，进索引不等于能被搜到，提交了为什么还不收录那篇把抓取与索引之间的几道关系理了一遍，可以对照着看。

注意这里的措辞不是“不会被排名”或者“权重较低”。是不存在。你的第481个商品链接，你的评价结构化数据，你的面包屑，如果它们排在第2097153个字节上，那么在谷歌的世界模型里，你这个页面从来没有过它们。

2MB不是一条通用的线

同一篇文章里还给了另外几个数字，它们合在一起才构成完整的图景。

要看清楚到底是哪个客户端在抓你、各抓了多少次，唯一可靠的地方是服务器日志，读懂Googlebot抓取与预算浪费那篇给了完整的读法。

这张表里藏着一个很少被讲的事实：同一个网址，不同的抓取客户端看到的长度不一样。你那个2.4MB的分类页，对谷歌搜索是被切掉一截的，对某个走15MB默认值的客户端却是完整的。你没法用一次测试覆盖所有情况，因为它们本来就在读不同长度的同一份文件。

它是一个平台，不是一个机器人

这篇文章顺手纠正了一个流传二十多年的误解。Gary写道，21世纪初谷歌只有一个产品，所以只有一个爬虫，Googlebot这个名字就这么留了下来；而今天的Googlebot只是一个类似集中式抓取平台的东西的使用者之一。

日志里那个自称Googlebot的请求也不一定真的是它，每5次Googlebot抓取就有1次IP不属于谷歌那篇实测过反向验证该怎么做。

你在日志里看见Googlebot，你看到的只是谷歌搜索。谷歌购物、AdSense还有几十个别的客户端，全都走同一套底层基础设施，只是用着不同的爬虫名字。字节上限就是每个客户端各自设置的一项参数，和用户代理字符串、和它在robots.txt里认哪个令牌，摆在同一个配置块里。

HTTP响应头也算在这2MB里

这是原文里一句很容易被跳过的补充：这个限额包含HTTP请求头。也就是说预算表的第一行不是你的HTML，是你自己平时根本不会去看的那几KB。

响应头这一层还有别的账要算，服务器把没改过的页面对爬虫重发了几百遍那篇讲的是条件请求没配好会怎样浪费掉抓取资源。

保哥顺手量了一下手上这批站点的响应头。22个站的头部字节均值是2938字节，最大的一个是webflow.com的13975字节。放在2MB这个尺度上，最大的那个也只占0.67%，看起来无关紧要。但如果你的余量本来就只剩两位数，这几KB就是那个把你推过去的东西。

渲染只能执行爬虫真的取到的那部分代码

抓取拿到字节之后交给网页渲染服务，也就是常说的WRS。原文提醒了两件事，第二件比第一件重要得多。

渲染这一层对不同的抓取方有不同的结果，CSR、SSR与ISR的引用率实测那篇量过几种渲染模式在被引用上的真实差距。

第一件：HTML里引用的每一个资源，除了媒体、字体和少数特殊文件，都会由WRS用Googlebot单独抓一次，它们各有自己的字节计数器，不计入父页面的额度。所以把重的东西挪成外链文件是真的有用，不是心理安慰。

第二件：WRS只能执行爬虫实际取到的那部分代码，而且它是无状态运行的，请求之间会清掉本地存储和会话数据。这两条叠在一起会产生一个很难排查的后果——你的页面在浏览器里跑得好好的，是因为浏览器拿到了完整的文件，而WRS拿到的是被切过一刀的版本。

一个容易被误读的地方

有人会把“外部资源各有自己的额度”读成“把东西挪到外部文件就等于免费”。不是这样的。挪出去只是让它不占父页面的份，它自己那份仍然有上限，而且WRS要不要去取它、什么时候取，是另一套逻辑。

正确的理解是：挪出去解决的是父页面被截断的问题，不是解决那份内容一定会被读到的问题。如果你把结构化数据挪进一个外部脚本再动态注入，你等于把一个确定的问题换成了一个不确定的问题。

所以本文全程建议的是“往前排”而不是“挪出去”。往前排是把重要的东西放进那段一定会被读到的字节里，这是所有做法里唯一一个不引入新变量的。

这条线还会变

原文结尾留了一句：这个限制并非一成不变，随着网页不断变大（或者变小，希望是变小）它可能会随时间改变。这句括号里的自嘲值得记一下，因为它说明谷歌自己也知道趋势在往哪个方向走。

谷歌抓取侧的规则历史上改过好几次口径，移动优先索引与Googlebot渲染机制的演变那篇复盘过一次改动落到站点上是什么体感。

一条会变的线，你不能踩着它做优化。你只能给它留余量，而余量的大小取决于你多久才会发现自己越了线——按本文后面的实测，答案通常是永远不会。

那15MB的默认值意味着什么

官方给出的“未指定上限的爬虫默认15MB”这一条，实际上是在说抓取平台的配置结构：字节上限是每个客户端自己填的一个字段，不填就走默认。

顺着这个结构往下想会得到一个有点冷的结论：谷歌搜索这个客户端，把这个字段填成了全平台默认值的七分之一。这不是疏忽，是搜索侧对网页文档长度的一个判断——他们认为2MB足够容纳任何一个合理页面的全部内容。

这个判断在2026年是不是还成立，本文的实测给了一个不太好看的答案：8.7%的头部电商页面已经不在这个假设里了。

为什么这件事该由做转化的人来管

把抓取上限放进转化率优化的话题里，第一反应会觉得串台了。但这两件事在同一个文件里争同一份预算，而且争抢的原因恰恰是转化侧的诉求。

搜索侧和体验侧本来就该并成一条链来看，搜索体验优化SXO把SEO、UX和CRO拧成一条链那篇讲的是这种跨界协作的组织方法。

首屏要快，所以关键CSS被内联进HTML；交互要跟手，所以服务端渲染完还要把数据再内联一份供浏览器接管；个性化推荐要即时，所以一整套商品数据被提前塞进页面。这三件事全是为了转化，也全是在往同一个2MB的桶里倒东西。

更麻烦的是它们的收益你看得见——首屏时间、交互延迟、加购率，都在报表上；它们的代价你看不见，因为代价发生在一个不产生任何错误信号的地方。

这类失败为什么特别难被抓到

常见的技术故障都有一个共同点：它们会让某件事变得不成立。接口挂了会返回500，证书过期会让浏览器拦截，脚本报错会在控制台留下红字。这些都是断言失败，断言失败会喊。

同样是不报错的故障，人机验证屏被谷歌当正文索引那次事故里页面照样返回200，只是搜索引擎读到的是另一份内容。

截断不是断言失败，它是一次成功的部分完成。系统按设计工作，返回了它承诺的东西，只是那个东西比你以为的短。没有任何一层会为“比预期短”这件事负责，因为没有任何一层知道预期是多少。

先说清楚它不是什么

它不是抓取预算问题。抓取预算讲的是Googlebot愿意在你的站上花多少次请求，是站级别的资源分配；字节上限是单次请求内部的截断，是页面级别的。两者可以同时存在，也可以互不相关。

抓取预算是站级别的另一件事，分面导航产生的海量URL怎么治理那篇讲的才是预算被稀释的典型场景，跟本文的页面级截断不是一回事。

它也不是渲染超时。渲染超时是WRS等不到你的脚本执行完，那件事发生在拿到字节之后；截断发生在拿字节的时候，等于渲染那一步收到的原料就是残缺的。

它更不是robots.txt或者noindex。那两者是你主动做出的排除决定，有明确的语义、有专门的报告位置、也有人为它们负责。截断没有决定者。

46个真实电商站的字节结构实测

官方文档给了一条线，但没有告诉你线在哪个位置、你离它有多远。保哥决定自己量一遍。

为什么必须自己量

因为这条线的所有已知信息都是定性的。官方说了上限是多少，没说行业实际分布在哪；说了超出会被忽略，没说超出的比例有多高；说了要把关键元素放在前面，没说现在有多少站没这么做。

行业基准这种东西最怕拿来直接套，转化率、排名周期、流量占比该对标多少那篇整理过一批公开基准以及它们各自的适用边界。

这些空白不能靠推测填。一个只在文档里存在的风险，和一个八分之一的头部站点已经踩上去的风险，值得投入的资源完全不同，而两者的区别只有量一遍才知道。

样本怎么选的

选站的标准只有一条：跟看这篇文章的人在同一个赛道上。最后落到四类。

第一类是头部DTC品牌的独立站，包括Allbirds、Gymshark、Glossier、Bombas、Away、Brooklinen、Ruggable、Chubbies、Mejuri、Oura、Lovevery、Article和Purple。这批站的共同点是设计精良、技术栈新、有专职团队维护。

第二类是面向出海卖家的大型电商与品牌站，包括SHEIN、Anker、Jackery、EcoFlow、Uniqlo、IKEA、Target和Walmart。第三类是建站与营销工具自己的官网，包括Shopify、BigCommerce、Squarespace、Wix、WooCommerce、Webflow、Mailchimp和HubSpot。

第四类是几个做SEO的人天天访问的站，包括Semrush、Ahrefs、Cloudflare、Stripe和PayPal。把这一类放进来是想看看，天天讲技术优化的人自己做得怎么样。

挑样本这件事本身有方法，以消费级3D打印机为例做细分品类数据洞察那篇把选样、取数和交叉验证的完整流程走了一遍。

页面类型上首页和分类页各抓一份。分类页是重点，因为商品列表页天生就长，而且它在站内链接结构里承担着往商品页分发权重的职责——它被截掉一截，后果是可以直接算出来的。

怎么量的

抓取用的是普通桌面浏览器的用户代理，不伪装成Googlebot。这一点要说明白：伪装成爬虫会拿到某些站专门为爬虫准备的版本，量出来的是另一件事。本文量的是普通访客拿到的那份HTML，也就是绝大多数站点交给Googlebot的同一份。

伪装成爬虫去抓会拿到另一份内容，这件事在5000站爬虫伪造与抓取预算实战那篇里有更完整的说明和验证办法。

每个页面记两个数：一个是加了压缩协商之后服务器实际传输的字节，另一个是解压之后落到磁盘上的字节。后面会看到，这两个数的差别足以改变结论。

剔除规则也写在这里：返回403、429、302且没有跟到最终页面的，以及解压后不足20000字节的（基本是防护页或者跳转壳），全部丢掉。两轮抓取一共75个网址，最后留下46个有效样本。

总体分布长什么样

电商站的高频坑里有好几个都和页面结构有关，电商SEO最常见错误清单的12类高频坑那篇可以当一份对照表用。

中位数和均值分开看是有讲究的，砍掉虚荣指标、定准北极星指标那篇讲过一个分布右偏的指标被平均值掩盖会造成什么误判。

中位数46.4%这个数字第一眼看着挺安全，一半的额度都还没用。但请注意它是中位数——意味着有一半的站点比它更重，而且这个分布是明显右偏的：均值比中位数高了7.6个百分点，尾巴全在右边。

已经越过线的有几个

4个，占46个样本的8.7%。

分类页出问题会顺着结构往下传，独立站架构搭错了谷歌爬虫根本找不到你的产品页那篇讲的就是这种自上而下的连带损失。

八分之一强。这个比例比保哥开工前的估计高了不少——动手之前保哥心里的数字大概是二十分之一，而且以为超标的会集中在那些明显做得糙的站上。结果全是行业里被当作范本的品牌。

踩在线上的那一批

比超标更值得看的是紧贴着线的那些。用掉八成到十成预算的一共7个页面。

贴着阈值的数最怕被当成稳定值来用，一条五年趋势线上有三处口径变更那篇讲的是同一个指标在不同时段其实量的不是同一件事。

第一行那个数值得盯一会儿：2097129对2097152，余量23个字节。往这一页上再加一个商品的alt文本，它就过线了。而做这件事的人不会收到任何提示。

23个字节大概是什么概念？一个稍微写得完整点的HTML属性名加上等号和引号就到了。一次A/B测试往页面里塞一个实验标识，一次埋点升级多加一个data属性，一次翻译更新把某个短语从三个词改成五个词，都够。

为什么首页反而不是最危险的

直觉上首页最重，因为它模块最多。实测结果不支持这个直觉：46个样本里，超标的4个中有2个是分类页，紧贴上限的7个里有4个是分类页或者商品列表页。

原因是首页的内容量由设计稿决定，一个轮播加六个模块就是六个模块，不会自己变多；分类页的内容量由在售商品数决定，而在售商品数会随着生意变好一直涨。首页的长度有人负责，分类页的长度没人负责。

关键内容排在第几个字节

页面总长只是一半的故事。另一半是：你最要紧的那几个标签，落在这条时间线上的什么位置。

开发期就把这些位置定死是最省事的，自建站谷歌SEO开发期10大优化要点那篇讲的正是这一批只在开工时改起来便宜的事。

要把一页里所有结构化数据的位置和字段一次扒清楚，结构化数据审计工具一次扒清五种格式的字段缺漏那篇给了现成的做法。

保哥把每个页面里的标题标签、规范链接、页面描述、Open Graph标签、多语言标注和最后一段结构化数据的收尾位置全部取出来，取其中最靠后的那一个，作为“关键内容落点”。

好消息是压倒性多数的站都把这些东西放在了文档最前面，57.8%的页面在头1%的字节里就把关键标签写完了。这说明行业整体的习惯是对的。

坏消息在最后三行。有6个页面的关键内容落在了预算的20%之后，其中3个越过了60%，1个直接掉到线外。

落点最靠后的那批是谁

结构化数据的失效方式不止落在线外一种，一个尾逗号就能让整页结构化数据失效那篇列了几种同样不报错的写法错误。

这几个站的共同点是把结构化数据放在了文档尾部。这个做法本身完全合法，规范里从来没说结构化数据必须写在head里。它只是把一件本来零风险的事，变成了一件跟页面长度绑在一起的事。

Brooklinen那个69.22%尤其值得说：它今天是安全的，因为页面停在1571567字节。可它的安全不来自任何一次决策，来自“页面暂时还没长到那么长”。而页面只会越长越长。

安全和暂时安全的区别

这批数据里最该被记住的分类，不是超标和不超标，是“结构上安全”和“当前数值安全”。

这种当前数值安全的隐性欠账在建站第一年攒得最多，独立站CMS第一年SEO隐性失分排查那篇列了12项跨平台的共有坑。

结构上安全的站，把关键标签写在文档头部，页面再长十倍也不会丢；当前数值安全的站，靠的是页面还没长到那个长度。两者今天的体检报告完全一样，明天的走向截然不同。

26个站的关键标签落在头1%以内，它们属于第一类，这件事对它们永远不会成为问题。剩下那20个站里，每一个都在跟自己的增长赛跑。

一个容易看错的地方

有人会拿总大小的中位数46.4%来安慰自己：一半额度都还没用，慌什么。这个读法漏掉了一件事——中位数描述的是这一批站，不是你那一个站。

拿别人的分布往自己身上套是个通病，把DTC流量打法搬到B2B工业品为什么不灵那篇讲的就是这种迁移失败。

而且分布本身有很强的品类特征。首页普遍比分类页轻，纯内容站普遍比商品站轻，用传统模板渲染的普遍比用现代前端框架的轻。你要对比的不是这46个的中位数，是跟你技术栈和SKU结构最像的那两三个。

顺带量到的一件小事

抓取过程中有9个网址返回了403，全部来自那些启用了严格机器人防护的品牌站。这一点跟本文主题无关，但值得提一句：这些站对普通爬虫的防护做得很紧，而Googlebot走的是另一套通道，两者的体验完全不同。

那些403来自机器人防护，要不要拦、拦到什么程度是个单独的题，robots加UA加WAF三层选型框架那篇给了取舍方法。

这也是本文样本量止步46的原因。原计划的75个网址里，扣掉403、跳转未跟到底和防护壳，最后能拿到真实HTML的就这么多。把这个数字如实写出来，比补几个不相干的站凑整要诚实。

超过2MB的页面，到底丢了什么？

知道谁超标了没有用，得知道超标之后具体损失了什么。保哥把4个超标页面按截断点切成两段，数了数落在线外的东西。

Allbirds男款分类页：丢掉三分之一的商品入口

这一页总长2673710字节，截断点落在预算用尽的位置，也就是文件的78.4%处。

商品列表页该挂哪几种结构化数据是有定论的，Shopify怎么给页面加结构化数据以及128种类型怎么选那篇给了选型清单。

97个链接。这一页是男款商品的分类页，被切掉的那97个链接里绝大部分是商品卡片上的入口。对Googlebot来说，那些商品在这一页上没有入口——它们可能还能从站点地图或者别的分类页进去，但从这个理应最相关的页面进不去。

更要命的是那唯一一段结构化数据。它的起点在2670014字节，也就是预算的127.3%处，比截断点还要靠后57万字节。这一页的结构化数据在谷歌那边等于没写。

保哥把截断点那128个字节的原文取出来看了看，正好卡在一个商品卡片的链接标签中间，属性还没写完。Googlebot拿到的是一个从中间被剪断的HTML片段，连闭合标签都没有。

Wix首页：链接丢了三分之二，结构化数据反而安全

这一页是本次样本里最长的，3148564字节，超出上限50.14%。

面包屑既是链接又是结构化数据，两头都受截断影响，面包屑导航的四种类型与结构化数据实操那篇讲了它该怎么放。

它的4段结构化数据全部落在预算的15.3%到15.4%之间，安安稳稳地在线内。但它的链接丢了将近三分之二，图片丢了86.5%。截断点落在一段内联SVG的路径数据中间——那是一个图标的矢量描述。

这里出现了一个很有意思的对照：Wix超得比Allbirds更多，结构化数据却是安全的；Allbirds超得少一些，结构化数据却全丢了。

Anker两个页面：超标了，却什么都没丢

Anker的分类页2654871字节（超26.59%），首页2105560字节（超0.40%）。按理说前者的处境应该和Allbirds差不多。实际结果是：

同一件事在两套口径下给出相反结论并不罕见，两套报表算出相反的结论而且两套都没算错那篇拆过一个结构非常像的案例。

一个都没丢。两个页面的结构化数据分别落在预算的0.1%和0.2%处，链接和图片标签全部排在文档前部。它们超出的那五十多万字节里，装的是别的东西。

四个页面都越了线，超出幅度分别是0.40%、26.59%、27.49%和50.14%。受伤程度却完全不按这个顺序排：超得最少的什么都没丢，超得最多的结构化数据完好，中间那个丢光了全部结构化数据。

那条决定命运的规则

把这四个案例并排看，规则其实非常朴素：决定你丢什么的不是你超了多少，是你把重要的东西排在了第几个字节。

要查单页的抓取体积有现成的工具，抓取体积检查器与Googlebot上限实测那篇讲的是怎么用，本文补的是行业分布和落点这两件它不回答的事。

分类页的分页处理本来就有一套讲究，Shopify集合页分页的索引判断和canonical设置那篇把常见的几种做法和后果对照过。

这句话听起来像常识，但它推翻的是一个非常普遍的做法——用页面总大小当作健康指标。总大小是一个必要条件，不是充分条件；它能告诉你有没有风险，不能告诉你风险落在谁头上。

Anker那个分类页的总大小比Allbirds还大，但它是安全的。如果你的巡检脚本只看总大小，你会给Anker报警而放过Allbirds——两次都错。

一个可以自己复现的验证

如果想亲手确认这件事，最直接的办法是把一个超标页面的前2097152个字节单独存成一个文件，然后用浏览器打开它。

你会看到一个突然中断的页面：某个商品卡片显示到一半，后面全空。这就是Googlebot拿到的那份文档，不是一个近似，是字节级别完全一致的同一份东西。把它截图发给团队，比任何一段解释都管用。

再进一步的话，把这个截断版本丢进富媒体结果测试，看它还认不认得出你的结构化数据。这一步会把“可能有影响”变成“确实没有”，而这两句话在推动排期时的分量完全不同。

不报错不等于没后果

有个问题保哥被问过很多次：既然截断不产生错误，那我怎么知道自己中招了？

不会喊的问题都得自己去找，接口和feed这类地址拿什么说自己不想被收录那篇讲的是另一类同样没有报错位置的疏漏。

答案是：从现有的监控里你确实不知道。Search Console的覆盖率报告不会因为截断而变红，因为页面确实被成功抓取并索引了；抓取统计里那次请求是200；页面速度报告更不会提这件事，它量的是用户侧体验。

能看出来的地方只有三个，而且都不直接。第一是富媒体结果测试——如果它报“未检测到结构化数据”而你的源码里明明有，八成就是这个原因。第二是Search Console的网址检查工具里“已抓取的页面”那一栏，把它复制出来数字节数。第三就是自己量，也就是本文这套做法。

为什么四个案例值得逐个拆

因为把它们归成一句话会丢掉最有用的那部分信息。如果只说“有4个站超标了”，读者拿到的是一个比例；逐个拆开之后，读者拿到的是一张自己站点的对照表。

Allbirds对应的是结构化数据放尾部的站，Wix对应的是首屏内联做得很重的站，Anker对应的是用了现代框架但把语义标签写在前面的站。这三种形态覆盖了绝大多数电商技术栈，你大概率能在里面找到自己那一类。

另外还有一层意思：Anker那两个页面证明了超标本身不是罪。如果本文只讲“别超过2MB”，读者会得出一个过度简化的结论，然后在一个不需要动的地方投入排期。

渲染那一层还有第二重后果

前面提到WRS只能执行爬虫真的取到的那部分代码。当截断点落在一段脚本或者一段JSON数据的中间时，交给WRS的就是一份语法上根本不成立的东西。

框架站的渲染模式选择直接决定这类风险有多大，React和Next.js框架站渲染模式选错就抓成空壳那篇把几种模式的取舍列全了。

Anker那两个页面的截断点恰好都落在同一类标签内部——后面一节会讲清楚那是什么。这意味着虽然它们的链接和结构化数据全都安全，但依赖客户端接管才能出现的内容仍然有风险。索引层安全和渲染层安全是两件事，不能互相担保。

而且WRS是无状态的，请求之间会清掉本地存储和会话数据。任何依赖“上一次访问留下的东西”才能正确渲染的逻辑，在它那里都不成立。这一条和截断没有直接关系，但它们经常一起出现在同一个技术栈里。

被切开的那个标签会怎么样

浏览器的HTML解析器有很强的容错能力，遇到没闭合的标签会自动补齐，遇到写到一半的属性会尽力猜。所以一个被截断的HTML文档，多半还是能解析成一棵勉强能用的DOM树。

要确认一段JSON到底是不是完整的，最省事的办法是丢进格式化工具跑一次，JSON格式化与JSON-LD调试那篇讲得很细。

但脚本和JSON不吃这一套。一段被从中间切开的JSON就是语法错误，解析它的代码会直接抛异常。如果那段JSON是页面接管所依赖的数据源，接管这一步就不会发生，客户端负责渲染的那部分内容一个字都不会出现。

三种不同的受伤方式

把前面几个案例归一下类，截断造成的损失一共有三种形态，严重程度递增。

结构化数据该做哪些不该做哪些是有依据的，Schema官方第一次公开全网使用数据那篇拿实际使用率排了优先级。

第一种是内容缺失：链接、图片、文字段落被切掉。它的特点是损失可以数出来，也可以按比例估算影响。

第二种是元数据缺失：结构化数据、多语言标注、规范链接落在线外。它的特点是损失不成比例——一段结构化数据丢了就是全丢，没有丢一半这回事。

第三种是解析中断：截断点落在脚本或JSON中间，导致后续逻辑整个不执行。它的特点是损失可能远大于被切掉的那部分本身，因为断掉的是一个开关，不是一段内容。

先查哪一种

按发现成本从低到高：先查元数据，因为富媒体结果测试几分钟就能给答案；再查内容缺失，需要自己数链接；最后查解析中断，它需要把截断后的文档喂给解析器才能确认。

要快速生成或者比对一段标准的结构化数据，结构化数据生成器与13种Schema类型那篇的工具可以直接拿来做对照基准。

好在这三种的修复方式高度重合——把关键的东西往前排，同时把体积压下来。你不需要先分清是哪一种才能动手，分类的价值在于估算损失的大小，不在于决定做什么。

是什么把HTML撑到2MB的？

量到这里，最自然的猜测是内容太多——商品太多、文案太长、导航太深。保哥抓着这个猜测去拆了一遍，结果是猜错了。

先看一个夸张的数字

Anker那个充电器分类页里，有一个标签单独占了2384424字节。

要看清一段内联代码到底占了多少字节，格式化工具比肉眼靠谱，CSS格式化、压缩与前端性能的真实账那篇算过这笔账。

不是一段代码块，不是一整个区域，是一个标签。它的开头长这样：一个id叫做NEXT_DATA的脚本标签，类型标着application/json。它从文件的269963字节处开始，一直写到2654387字节处才结束，中间没有换行也没有别的标签。

这一个标签的长度是2384424字节，而整条抓取上限是2097152字节。也就是说，光是它自己，就比Googlebot愿意读的全部内容还长287272字节。

截断点2097152落在这段JSON的正中间，保哥把那个位置前后的原文取出来，是一张商品图的地址和它的替代文本，写到一半被切断了。

那坨JSON里装的是什么

是这一页已经渲染出来的那些商品，再写一遍。

同一份内容在系统里存在两次这件事不只发生在前端，把内容当产品来设计那篇讲的是内容生产侧的另一种重复。

现代前端框架的通行做法是服务端先把HTML渲染好发给浏览器，让用户尽快看到内容；然后浏览器端的框架要接管这个页面，让它变得可交互。接管的前提是框架得知道这一页当初是用什么数据渲染出来的。最省事的传递方式，就是把那份数据原样序列化成JSON，内联进同一个HTML文件。

于是同一份商品列表在同一个文件里存在两次：一次是给人看的标签，一次是给框架用的数据。而抓取上限量的是两份之和。

不是一家的问题

换了几个技术栈之后发现这是普遍现象，只是名字不一样。

这些机制全在前端手里，前端工程师SEO协作的7个动作点那篇整理过哪些事必须由前端来做、SEO只能提要求。

Lovevery那个尤其能说明问题。它没有用一个大标签，而是拆成394个小脚本依次往一个数组里推数据。从工程角度这是更先进的做法，可以边下边渲染；从字节角度它和一坨没有任何区别，只是分成了394份。那个离上限只剩23个字节的页面，95.0%的体积是这些分片。

内联样式是另一路

数据的影子之外，还有一路是样式。

在线工具生成的样式往往带着一堆用不上的默认值，CSS在线编辑器生成的是一份相对默认值的差异清单那篇讲过这个坑。

内联首屏样式的完整逻辑和适用边界，关键渲染路径怎么优化那篇讲得比本文细，包括什么情况下不该内联。

Wix那一页把180万字节的样式写进了HTML。这不是疏忽，这是刻意的：把首屏需要的样式内联进文档可以省掉一次网络往返，让内容更早出现在屏幕上。它是各家性能指南里都写着的正经做法。

还有第三路：内联的矢量图

Cloudflare首页给了一个意外的样本。它总长1304713字节，其中930927字节是内联SVG，占71.4%。

图标到底该用内联矢量图还是位图是有账可算的，135字节的图标被压成560字节那篇量过几种格式在小尺寸上的真实开销。

把图标做成内联SVG的理由同样很正当：不用发额外请求、可以用CSS直接改颜色、不会有闪烁。代价是每一个图标的每一条路径数据都变成了HTML文档的一部分，要和你的商品链接抢同一份预算。

把三路加起来看

保哥把内联样式、内联脚本和内联矢量图三项加总，除以页面总长，得到一个“影子占比”。

这几项瘦身对用户侧指标也有好处，WooCommerce性能优化6层架构把LCP从4秒压到1.5秒那篇的分层办法可以照抄。

字节这件事还有另一个算法，从页面碳足迹到爬虫抓取的同一套规范那篇把传输字节换算成了能耗，结论方向和本文一致。

把页面推到抓取上限的从来不是内容，是内容的影子。实测里最重的七个页面，86%到97%的体积都不是给人读的那部分。

一个黑色幽默

拆Brooklinen和Jackery的内联脚本时，保哥在里面看到了一段正则表达式，内容是Googlebot、Storebot-Google、bingbot、Baiduspider、YandexBot、DuckDuckBot这一串爬虫名字。那是电商平台的埋点管理器在识别爬虫，好让爬虫不要污染统计数据。

识别爬虫这件事今天比过去复杂得多，AI爬虫抓取量已超Googlebot 3.6倍那篇给了当前的爬虫构成和应对思路。

这段代码本身有几万字节，它是把这个页面推向截断线的那份重量的一部分。一段专门用来识别Googlebot的代码，在替Googlebot把这一页缩短。

影子占比比总大小更有诊断价值

如果只能记一个指标，保哥会选影子占比而不是总大小。理由是它直接告诉你该往哪儿使劲。

影子占比低而总大小高，说明你的内容是真的多，那就该考虑分页或者调整信息架构；影子占比高而总大小还行，说明你现在安全但增长空间被提前吃掉了；两个都高，说明你正在用一个会不断膨胀的机制承载一个会不断增长的内容量，这是最需要立刻处理的组合。

算这个指标不需要工具：把源代码里最长的那几个脚本标签的长度加起来，除以文件总大小。三分钟能算完，而它给出的信息比总大小多一整个维度。

为什么这件事这么难被发现

三路影子有一个共同特征：它们在浏览器里完全不可见。你打开开发者工具看元素面板，看到的是渲染后的DOM树，那些内联JSON已经被框架消化掉了；你看网络面板，看到的是压缩后的传输大小；你跑性能评分工具，它关心的是渲染时间不是文档长度。

想看清源码的真实结构，一个能实时预览又能看原始文本的编辑器很省事，HTML编辑器三栏实时预览那篇介绍了用法。

唯一能看见它的地方是查看网页源代码然后往下滚，或者像本文这样直接量字节。而这两件事都不在任何一条常规工作流里。

为什么框架不替你解决

因为对框架来说这不是问题。把数据内联进文档是它能想到的最可靠的传递方式：不需要额外请求、不会有时序问题、不依赖任何外部状态。从框架的角度这是一个优雅的设计。

两个都没做错的组件在同一个地方打架是常态，装了SEO插件却冒出两个canonical那篇是另一个同构的例子。

框架的作者没有理由知道谷歌的字节上限是多少，就像你没有理由知道框架内部用什么格式序列化数据。这个后果掉在两个都没做错的设计中间那条缝里，而缝里没人。

能不能不要那份数据

大多数情况下不能，但大多数情况下可以让它小很多。

把内容当结构化数据来生产会顺带解决字段冗余的问题，内容工程与AI搜索时代的内容生产那篇讲了这套思路。

那份数据之所以大，通常是因为它是后端接口返回的原样。一个商品对象里可能有40个字段，而页面上真正用到的只有八个：标题、价格、主图、库存、评分、链接、颜色、尺码。剩下32个字段——供应商编号、入库时间、内部分类码、多个尺寸的图片地址——一个都不会出现在屏幕上。

裁字段是本文提到的所有动作里最费劲的一件，但也是收益最大的。前面那个耗材站砍掉了108万字节，占它总瘦身量的三分之二。

另一条更省事的路

如果框架支持，把接管数据从内联脚本改成一次独立的网络请求，这份数据就有了自己的字节额度，不再占用父页面的份。

多一次往返值不值得，取决于你的缓存层怎么搭，TTFB怎么优化才不白费那篇把多层缓存对抓取和体验的双向影响算清了。

代价是多一次往返，首次交互时间会变差一点。这是个真实的取舍，不是免费的午餐。但对于那些商品数很多的分类页，这个取舍往往是划算的——因为分类页上的用户本来就要浏览一阵子才会点进商品，那一次往返藏得住。

顺便说一句内联的边界

内联本身没有错，错的是把“内联能省一次请求”当成一条无条件成立的规则。省一次请求的收益是固定的，大概几十毫秒；内联的成本却是随内容线性增长的。

很多当年正确的决定今天已经翻过去了却没人复核，被低估的9个反直觉UI设计杠杆那篇里有几个例子是同一个道理。

当被内联的东西小到几KB，这笔账怎么算都赚；当它涨到几十万字节，这笔账早就翻过去了，只是没有人回头重算过。本文实测里没有一个站是故意把180万字节的样式写进文档的，它们只是在很久以前做了一个当时正确的决定，然后再也没有复核。

为什么优化性能反而会把页面推过线？

这一节是全文最别扭的部分。因为把页面撑到抓取上限的那三件事，每一件单独拿出来都是被官方推荐过的正经做法。

三条建议，同一个文件

改版是这类问题最集中的时点，改版不掉SEO的完整防护清单那篇里的检查项建议加上文档字节数这一条。

性能这条线本身的收益是真实的，海外客户用低端机弱网打开你的独立站有多卡那篇量过这些优化在真实设备上的差别。

没有一条是错的。第一条来自Chrome团队关于消除渲染阻塞资源的长期建议，配套的做法在web.dev那篇提取关键CSS里写得更细。它们的问题在于三者共用一个容器，而这个容器有一条谁都没提的边界。

性能优化和抓取完整性在同一个HTML文件里争同一份预算，而且争抢的方式是单向的：性能这边每省一次网络往返，抓取那边就少一截余量。

为什么这场冲突几乎从不被提起

因为两边的度量单位不一样。性能这边的单位是毫秒，抓取这边的单位是字节；性能这边的报表是实验室数据加真实用户数据，抓取这边压根没有报表。

跨部门的口径缝隙需要一份对账清单来兜，数据分析师与SEO对账清单的7个动作点那篇给了一套可以照抄的协作机制。

更根本的原因是两边的负责人通常不是同一个人，甚至不在同一条汇报线上。前端负责渲染指标，技术SEO负责收录与结构化数据。而这条冲突恰好横跨两者，落在中间那条缝里。

这跟保哥之前写过的很多口径问题是同一个形状：不是有人做错了，是两个都做对的人在同一个地方留下了一个谁都不负责的后果。

一个真实的取舍现场

去年保哥接手过一个做3D打印耗材与配件的跨境独立站，欧美加澳洲三个市场，耗材22到45美元一卷，另外卖喷嘴、料盘、加热床这些配件，团队14个人。这个品类的SKU结构非常特殊：同一款耗材要按材质、直径、颜色三个维度铺开，光是一种PLA就能拆出60多个变体。

变体多的品类在分类页上的处理是个老问题，WooCommerce独立站SEO优化12步那篇里产品页和分类页那两节可以直接对照。

他们的耗材总览页要列出全部在售变体，因为客户就是按颜色挑的，你把颜色收进筛选器，跳出率立刻涨。这一页在改版前有412个商品卡片。

改版做了两件事：把首屏样式内联进文档，首次内容绘制从2.4秒降到1.3秒；同时换了新的前端框架做服务端渲染，交互延迟明显改善。这两件事上线之后的三个月里，团队看到的所有指标都在变好。

问题是怎么冒出来的

不是通过监控。是通过一次很偶然的对话。

筛选和变体的展示方式会同时影响体验和字节，连点五个筛选之后用户已经忘了自己选过什么那篇讲的是它的体验代价。

运营同事在做站内搜索优化时，想确认一下某个颜色的耗材有没有被正确收录，随手在搜索引擎里用site指令查了一下这个分类页下面的商品。她注意到有一批深色系的变体怎么都查不到，而那批变体在页面上排得比较靠后。

她第一反应是那些商品可能没上架，去后台查了一下，全部在售。第二反应是可能被canonical指到别处了，查了一下也没有。她卡在这里两天，因为她能想到的所有排查方向都指向“页面本身有问题”，而页面本身怎么看都是好的。

转机是她把这一页的源代码另存为本地文件，想用编辑器搜一下那几个颜色的名字。文件属性显示2.6MB。她当时的原话是：一个没有图片的HTML文件为什么会有2.6MB。

这个破局点的成本几乎为零：她不是在怀疑什么，只是需要一个能被搜索的文本。文件大小是操作系统顺手告诉她的。

拆开之后的账

量完的结果是：那一页2712880字节，超出上限615728字节，也就是文件的77.3%处被切断。

全站爬一遍能顺手把链接结构的断点找出来，Screaming Frog全站审计的12类问题排查清单那篇给了完整流程。

图片标签被切掉之后连带影响的是图片搜索那条流量，Shopify图片SEO从命名到压缩的完整清单那篇讲了这条线怎么保。

111个商品卡片对不上她查不到的那批深色变体吗？对得上，而且比她发现的更多——她只注意到深色系，因为那是她自己负责的那条产品线。

分页导航那一行最疼。8个分页链接全在页脚，全部落在截断点之外。也就是说从这一页出发，Googlebot根本走不到第2页往后的任何商品。那些商品还能通过站点地图被发现，但站点地图只负责告诉搜索引擎这个网址存在，它不传递任何关于重要性的信号。

改了什么，代价是什么

处理顺序按“改动成本从低到高”排，实际效果却几乎相反。

首屏时间涨0.3秒值不值得，最好用实验来回答，30个A/B测试方案那篇里有几个跟加载速度直接相关的测试设计。

第一项减掉的字节是零，但它是全部四项里唯一一个能保证“以后再长也不会丢关键内容”的。把重要的东西往前排不解决体积问题，它解决的是排序问题，而排序才是决定你丢什么的那个变量。

四项做完之后这一页落到1201000字节左右，占预算57.3%。首次内容绘制从1.3秒回到1.6秒，涨了0.3秒。这个代价是真实的，得写出来。

三个月后的数

被截掉的那111个商品，其中87个在六周内进入了索引；分类页在长尾颜色词上的展示量涨了不少，但保哥不打算把这个数字写成一个精确的百分比，因为同期他们还做了别的事，归因分不干净。

同期做了别的事就没法干净归因，哪条外链真撬动排名与6步实验设计那篇讲的正是怎么在多个变量里隔出一个。

能干净归因的只有一件：商品列表的富媒体结果回来了。这件事只跟结构化数据在不在线内有关，没有第二个变量。

另一件说不上是收益还是教训的事：他们后来给这一页做了自动分页，每页96个商品。做完之后页面长度降到60多万字节，余量充足。但客户投诉挑颜色变麻烦了，加购率掉了。最后回滚成一页全展示加上前面那四项瘦身——绕了一圈才明白，问题从来不是商品太多，是每个商品在文件里占的位置太贵。

这次复盘里最该记住的一句

发现它的人不是在排查，是在找一个能被搜索的文本。所有真正难被发现的问题，最后都是被一个跟它无关的动作顺手撞出来的。

最难发现的问题往往是被一个不相干的动作撞出来的，揪出购买路径上那些看不见的摩擦力那篇里的几个案例也是这么被发现的。

这一点值得展开一句。团队里没有人失职：前端做了性能优化并且拿到了结果，SEO在做站内链接结构并且做得不错，运营在盯商品收录。三条线各自的检查项里都没有“文档字节数”这一项，因为它不属于任何一条线。

如果当时有一份预算表会怎样

会在改版上线的那一次构建里就被拦下来。那次改版把内联样式加进去，文档一次涨了39万字节，从原来的200多万涨到270万——一个只要有人看一眼数字就会警觉的跳变。

把定期检查交给定时任务是最省心的做法，用cron把独立站运维自动化那篇给了备份、sitemap和日志的完整脚本。

问题不是没人愿意看，是那个数字从来没有被显示在任何地方。它不在构建日志里，不在部署摘要里，不在任何一张周报上。

这件事在哪一类团队最容易发生

技术能力强、迭代快、性能意识好的团队。这不是反话。

技术能力弱的团队用的是成熟模板，模板输出的HTML结构固定、体积可控，反而不会出事；技术能力强的团队才会自己上框架、自己做首屏优化、自己写渲染逻辑，而这三件事全是这个问题的诱因。

能踩到这个坑，某种意义上是团队水平的证明。但这句安慰改变不了那111个商品三个月没被抓到的事实，所以它只能当一句玩笑说，不能当一个理由。

成本对照

整件事从发现到修完花了大约四周人力，跨了三个人。如果在改版那次就有一条构建断言，成本是半天。

预防和发现的成本差十几倍这件事在实验上同样成立，A/B测试样本量怎么算才能避免假胜利那篇算过提前算样本量能省多少返工。

两个数字之间差了十几倍，而且这还没算上那三个月里被切掉的111个商品少收的流量。这类问题的成本结构是固定的：预防很便宜，发现很贵，而中间那段时间是免费送给对手的。

这条线到底该用哪把尺子量？

前面所有的数都是按解压后的字节算的。这个选择需要交代清楚，因为换一把尺子，结论会翻过来。

官方原文里的两种说法

Gary那篇文章在同一段里用了两种表述。一处是“Googlebot目前对任意单个网址取回最多2MB”，另一处是“这对你的服务器通过线路发出的那些字节意味着什么”。

压缩协商这一层的坑不止一处，nginx出厂只压HTML这一种类型那篇发现其余类型的字节是全额计入抓取成本的。

前一种听起来像是在说文件本身的大小，后一种听起来像是在说传输量。这两者在HTTP协议里本来就是分开定义的，Content-Encoding响应头标注的正是“实体内容被编码过，你收到的字节数不等于原始字节数”。而现代网站几乎全部开启了压缩传输，这两个数差得非常远。

差多远

保哥对46个样本逐个记了传输字节和解压字节。

把HTML本身压一遍也有讲究，WordPress免插件压缩HTML加速那篇讲了保留代码块和与GZIP叠加时该注意什么。

七倍半的中位数意味着什么？意味着一个解压后1.5MB的页面，在网络上只跑了两百KB。你在浏览器网络面板里看到的那个“200 kB”，和抓取上限量的那个数，相差一个数量级。

换尺子之后的结论

46个样本里，传输字节超过2MB的页面：0个。解压后超过2MB的页面：4个。同一批页面，同一条线，换一把尺子量，超标数从0变成4。

同一件事换个口径结论就翻过去，这类事在行业清单里非常普遍，9条查得到出处、8条数字对不上那篇追过一批来源。

这就是为什么本文全程用解压字节。不是因为确定官方就是这么算的，而是因为在两种可能的口径里，一个会漏报，一个会误报，而漏报的代价是你永远不知道自己丢了东西。

顺带一提，压缩倍数本身也是个不稳定的量。它取决于内容重复度——那些内联JSON因为字段名反复出现，压缩率特别高。Allbirds那个分类页压缩了13.00倍，正是因为它里面有大量结构相同的商品数据。越是把你推向上限的那类内容，越是在传输字节上看不出来。

那响应头呢

官方明说限额包含HTTP请求头。这一项保哥也量了，22个站的头部平均2938字节，最大的是webflow.com的13975字节。

Set-Cookie这一堆多半来自同意管理和统计脚本，GDPR和CCPA同意横幅怎么不毁SEO数据那篇讲了它们的取舍。

拿最大值算，它占2MB预算的0.67%。绝大多数情况下可以忽略。但有两种情况不能：一是你的余量本来就只剩几万字节；二是你的站点用了大量Set-Cookie，实测里chubbies.com的分类页一次响应带了14个Set-Cookie，头部接近4KB。

一份可以直接抄的余量标准

综合以上不确定性，保哥给自己定的规矩是这样的。

阈值定得太紧没人执行、太松失去意义，页面速度到底怎么影响SEO排名那篇里给优化项排优先级的思路可以直接搬过来定这个值。

1800000这个警戒值留了约14%的余量。这个余量不是拍脑袋来的，它对应三件很容易发生的事：一次营销活动往页面上加两个模块、一次多语言上线让每个文案变长、一次埋点升级给每个商品卡加两个属性。

这张表怎么用才不会变成摆设

把阈值写进文档没有用，写进流程才有用。这张表的正确用法是把那个1800000填进一条构建断言里，让它在每次发布前自己跑一遍。

如果暂时做不到，退而求其次的做法是把它挂在改版和大促这两个时点上——这两件事是页面长度跳变最集中的场合，也是最容易被忽略的场合，因为那时候所有人都在盯别的指标。

为什么不建议踩着2MB做优化

三个理由，按重要性排。

规则会变这件事这两年体现得特别明显，Core Web Vitals在AI搜索时代还值不值得投那篇追过一轮指标口径的调整。

第一，官方明说这条线会随时间改变，而且暗示了它有可能往下走——原文那句“或者变小，希望是变小”是在说网页大小的趋势，但一条为了适应网页而设的线，跟着网页走是很自然的。

第二，你不知道自己什么时候会越线。页面长度不是由一次决策决定的，是由几十次小改动累加出来的，而每一次小改动的作者都不知道当时的余量是多少。

第三，也是最实际的：越线之后没有任何信号。你的所有其他阈值——图片大小、脚本执行时间、接口响应——都有工具会告诉你超了。只有这一条不会。

一句给排期用的话

如果要向不熟悉这件事的人解释为什么按解压字节算，最短的说法是：压缩是给网络省钱的，不是给内容减肥的。压缩不会让你的文档变短，只会让它在路上占的地方变小，到了对面还得原样展开。

顺便说一下压缩本身

虽然抓取上限大概率不看压缩后的字节，但压缩仍然值得认真做，理由跟本文无关：它直接影响用户侧的加载时间，也影响抓取的效率。服务器上没打开的压缩类型，会让相应的资源以原始体积传输。

压缩之外还有一批同样影响抓取效率的小事，从sitemap的lastmod到结构化数据的日期那篇讲的时间戳口径是其中之一。

这里要区分开的是两件事：压缩优化的是传输，前移和瘦身优化的是文档结构。前者让页面更快，后者决定页面完不完整。两件事都要做，但不能互相替代，也不能用其中一件的达标去证明另一件没问题。

一个反直觉的推论

压缩率越高的页面，越容易出问题。

工具给出的页面体积口径各家不一样，Semrush完整使用指南那篇里提过怎么确认一个工具报的数到底是哪一种字节。

因为压缩率高说明内容重复度高，而内容重复度高的最大来源恰恰是那些结构化的内联数据——同样的字段名在几百个商品对象里出现几百遍。所以压缩率是一个反向指标：它越好看，说明你的文档里那份“内容的影子”越大。

实测里压缩倍数最高的两个页面，bigcommerce的定价页14.95倍、ahrefs首页14.82倍，解压后都在120万字节以上，而它们的传输字节只有九万多和八万多。光看网络面板，这两个页面轻得像一篇博客。

这条推论怎么用

它给了一个几乎零成本的粗筛办法：把传输字节乘以8。

这类粗筛动作基本都能用免费工具完成，预算为零也能做好SEO的免费工具清单那篇整理过一批。

8是本文实测均值8.47向下取的整。如果乘完之后超过180万，就该认真量一次；如果乘完还不到100万，基本可以放心。这个粗筛不精确，但它只需要看一眼浏览器网络面板里的数字，做一次乘法。

做乘法这件事本身值得提醒一句：人脑对乘法的直觉很差。看到“传输220KB”的时候，没有人会自动想到“这一页可能有1.8MB”，因为220和1800之间那个跳跃不在直觉的射程里。

浏览器工具为什么帮不上忙

开发者工具的网络面板确实会同时显示传输大小和资源大小两列，后者就是解压后的字节。但默认视图里资源大小那一列常常被折叠掉，而且它显示的是“1.9 MB”这种带单位的近似值，你没法用它去跟2097152做比较。

查看源代码和开发者工具看到的经常不是同一份东西，渲染对比器揪出爬虫和用户看到的页面不一样那篇讲了怎么把两份摆在一起比。

更麻烦的是，网络面板显示的是浏览器最终拿到的那份文档，如果页面上有脚本在加载后修改了DOM，你查看源代码看到的和面板里量到的可能不是一回事。唯一没有歧义的量法是把原始响应存成文件，看文件大小。

被截掉一截，对转化到底有多大影响？

写到这里必须回答一个更硬的问题：这件事值不值得占用你本来就不够用的排期。保哥的答案是分情况，而且分得很清楚。

先把不影响的那部分划掉

截断影响的是搜索引擎看到的版本，不影响用户看到的版本。你的访客拿到的永远是完整文件，页面在浏览器里怎么好用还是怎么好用。

搜索侧和转化侧该各管各的指标，高转化电商网站的SEO加CRO双轴8模块那篇把两条线的分工画得比较清楚。

所以下面这些指标不会因为截断而变差：加购率、结账完成率、站内搜索使用率、退货率、客单价。如果有人告诉你修好截断能提升转化率，那句话是错的。

真正受影响的是三样东西

商品结构化数据的字段这两年还在加，Google给商品结构化数据加了个category那篇讲的就是最近这一次变化。

评分和价格能不能出现在搜索结果里，全看那段结构化数据在不在，怎么给评论加上星级结构化数据那篇讲了具体做法。

三样里只有第二样能干净归因。前面那个3D打印耗材站的复盘之所以只敢说富媒体结果这一件，就是因为另外两件的效果和同期别的动作缠在一起。

富媒体结果和转化的关系

这是唯一一条能连到转化的链路，而且它连的是点击率不是转化率。搜索结果里带着价格、库存状态和评分的那一条，和只有标题描述的那一条，被点开的概率不一样。

要测富媒体结果对点击率的影响得先隔离变量，SEO实验设计与统计功效那篇讲了最小可检测效应该怎么定。

但这里必须节制。行业里流传的那些“富媒体结果提升点击率百分之多少”的数字，绝大多数经不起追问——分母是什么、对照组怎么选的、同期有没有别的变化，往往一条都答不上来。保哥不打算再往里加一个。

能说的只有一句：结构化数据落在截断点之外，等于你写了但没生效。这句话不需要任何效果数据来支撑，它本身就是个事实判断。

分页链接为什么最疼

因为它的损失是成倍的。一个分类页丢掉8个分页链接，丢的不是8个网址，是这8个网址背后可能几百个商品的内部发现路径。顺带一提，商品列表本身该用ItemList类型来描述，它的position字段正是用来告诉搜索引擎“这一项在列表里排第几”的——而排第几这件事，在字节层面还有另一重含义。

内部发现路径塌掉之后补救成本很高，多级面包屑导航的3种方案加结构化数据那篇是另一条常被忽略的发现路径。

而且这类损失在报表上表现为“什么都没发生”。那些商品还在，还能被搜到（如果它们在站点地图里），只是它们在站内链接结构中的位置塌了一块。你不会看到一条曲线掉下去，你只会看到一条曲线一直没涨起来，而这两件事在图上长得一模一样。

什么样的站需要现在就查

不是所有站都值得花这个时间。按保哥的经验，下面这几个特征命中两条以上就该查。

多语言站还有一整套自己的坑，国际化SEO和hreflang的多语言站避坑清单那篇是这方面比较全的一份。

多语言站的模板共用是这类问题的高发区，WooCommerce多语言多货币SEO的三层避坑那篇把语种差异的坑列了一遍。

最后那条是最阴的。保哥见过一个站英文版1.7MB安全、德文版2.1MB超标，因为德语复合词长。你在英文版上做的全部测试，一次都覆盖不到那个真正出问题的版本。

还有一类站几乎不用查

纯内容站、博客、单页产品站、目录页数很少的品牌站，基本可以跳过。它们的页面长度由文案决定，而文案再长也很难写到100万字节——那大概是30多万个汉字。

判断的标准可以简化成一句：你这一页的长度是由人写出来的，还是由数据库条数决定的。前者天然有上限，后者没有。所有出事的页面都属于后者。

这条判据也解释了为什么分类页比商品详情页危险。商品详情页的内容量是固定的，加一个商品不会让它变长；分类页的内容量跟在售商品数成正比，而在售商品数只会增加。

先量哪一页

按这个顺序：变体最多的那个分类页、商品数最多的那个筛选结果页、首页、语言版本里文案最长的那一版。前两个基本能覆盖九成风险。

筛选结果页同时还是重复内容的高发地，电商重复内容的8类成因地图那篇讲了它该怎么被治理。

筛选结果页往往是全站最长的页面，独立站搜索框怎么设计才不浪费这个高转化入口那篇讲的结果页设计会直接影响它的长度。

不需要全站扫。全站扫的成本会让这件事排不上，而排不上的检查等于不存在。先量四个页面，四个都安全就先收工，这是本节最实际的一条建议。

一个反向的提醒

量完发现远低于上限的话，请到此为止，不要顺手做“页面瘦身优化”。

优化到什么程度该停手是个通用问题，AI时代CRO优化的4个策略那篇讲了怎么给每一项优化定一个明确的完成条件。

页面长度本身不是排名因素，把一个800KB的页面减到400KB不会带来任何搜索侧收益。这件事的全部价值在于避免一个二元的、灾难性的、不报错的失败，而不在于把一个数字变小。

这个区分很重要，因为它决定了你该在什么时候停手。很多技术优化项目跑偏，就是因为把一个“及格线”当成了“越高越好的分数”。

及格线和分数的区别

及格线是二元的：过了就没事，差一点就全丢。分数是连续的：多一分有多一分的好处。把及格线当分数追，会在一个收益早已归零的方向上持续投入。

把及格线当分数追这件事在归因模型上也常见，多触点归因模型怎么选才不被最后一次点击骗走预算那篇讲了停手的判据。

这个行业里被当成分数追的及格线不少。页面体积是一个，请求数是另一个，HTML标签的语义化程度也常被这么对待。判断一件事属于哪一类，只要问一句：从60分提到90分，有没有任何一个具体的后果会改变？答不上来就是及格线。

那什么时候它会变成分数

只有一种情况：当页面体积大到影响用户侧加载时间时。但那已经是另一个话题了，它的判据是真实用户的加载指标，不是2MB这条线。

用户侧的加载指标该看哪几个、看到什么程度算够，从响应式到Core Web Vitals的3类站点改造对比那篇给了对照。

两个话题共用同一个动作（把文档变小），但它们的停手条件完全不同。为抓取完整性做的瘦身，做到安全线以下就该停；为加载速度做的瘦身，只要用户侧指标还在改善就可以继续。混在一起做会导致两件事都说不清楚做完没有。

这份字节预算表怎么落到构建流程里？

前面全是诊断，这一节是处方。按“做完能不能一劳永逸”排序，不按工程量排序。

六件自查动作

第一件带早停：取四个页面另存为本地文件，看文件大小。变体最多的分类页、商品最多的筛选页、首页、文案最长的语言版本。五分钟，零成本，不需要任何工具。四个都在100万字节以下就可以收工——后面五件解决的是同一个病，而这一件已经证明你没得这个病。

这六件里有五件不需要任何付费工具，11个按性价比排序的速赢清单那篇的排序逻辑和这里一样，都是先做能早停的那件。

第二件：查看源代码，用浏览器的查找功能定位你的结构化数据，看它在文档的什么位置。十分钟。如果它在文档下半部分，不管当前页面多大，都把它移到head里去。这一件是全部六件里唯一一个能永久免疫的。

第三件：把分页导航和面包屑挪到主内容之前。半天。它们在视觉上仍然可以显示在页脚，用样式控制位置就行；要挪的是它们在文档里的顺序。

第四件：翻一遍那个最大的内联脚本，看看里面有多少字段是渲染用不到的。一到两周，最费劲的一件。通常能砍掉一半以上，因为那份数据往往是把后端接口的返回原样塞进去的。

第五件：把内联的关键样式限制在真正的首屏范围内。三天左右。很多站的“关键样式”是整套设计系统，不是首屏那几个组件。

第六件：给多语言站点逐个语种量一遍。半天。这一件不产生任何改动，只产生一张表，但它是唯一能发现“只有德文版超标”这类问题的动作。

卡点挂在哪里

前面六件都是一次性的。要让这件事不复发，得有一个东西挡在改动路径上。

把一个数字放进例行流程比记在脑子里可靠，新网站SEO目标管理的3里程碑加量化任务清单那篇讲的是同一种思路。

如果暂时改不动构建流程，退一步用定时任务每天量一次也行，把sitemap、排名和清缓存交给定时任务那篇给了写法。

保哥试过的做法里效果最好的是这个：在构建产物里输出一个数字。构建流程跑完之后，对几个代表性页面各生成一次HTML，量它的字节数和关键标签落点，把这两个数写进构建日志，超过警戒值就让构建失败。

为什么是刻度而不是别的形式？因为这个数字必须在有人做出改动的那一刻出现，而不是在季度巡检时出现。一个季度检查一次的指标，只能告诉你已经错了多久；一个跟着每次构建走的指标，能告诉你是哪次改动干的。

提示语里那个“与上次构建的差额”是关键设计。总量超标只能说明积累到头了，差额才能指出是谁加进来的。实践下来，看到“本次构建增加了217KB”的人，会去看自己改了什么；看到“当前1.83MB超标”的人，会去问这个阈值是谁定的。

怎么跟人说这件事

说“我们的页面太大了”效果是零。页面大不大是个见仁见智的判断，而且负责性能的同事手上有一整套数据证明这个页面很快，你说不过他，因为他是对的。

跨职能沟通有一套通用的说法，网页设计师SEO协作的7个动作点那篇里那几句开场白可以直接照搬到本文这个场景。

保哥用的说法是这样的：这一页的HTML是2.6MB，Googlebot只读前2MB。我数了一下，第2MB之后有111个商品链接和全部8个分页链接。我想把分页链接和结构化数据挪到文档前面，挪完再看一次。

三个事实一个提议，没有一个字说这个页面做得不好。快和完整是两个独立的属性，一个页面完全可以又快又缺一截。

护住所有人的第二句：这个页面的性能优化是对的，问题不在它身上，在于我们没有一个地方记录过这份预算还剩多少。这句话把焦点从人挪到了“缺少一个仪表”上，而添一个仪表是没人需要反对的事。

四条边界

第一条：这套方法只对HTML文档有效。图片、脚本文件、样式文件各有自己的额度，不占父页面的份。有人量完HTML就去优化图片体积，那是另一件事，跟这条线无关。

PDF走的是另一条64MB的线，PDF怎么做SEO与6个优化清单那篇讲的规则和HTML这条完全不同，别混着用。

规范链接是另一个经常被当成命令来用的提示，canonical标签是提示不是命令那篇列了8种误用，逻辑和本文的边界那节很像。

第二条：没超标不等于没问题，超标也不等于一定受伤。这一点前面用Anker和Allbirds的对照说过了。总大小是筛查指标，落点才是诊断指标，不能只看前者。

第三条：本文的全部数字来自2026年8月上旬对46个页面的一次快照。这些站随时会改版，你今天去量可能得到完全不同的结果。可以迁移的是方法和那条2MB的线，不能迁移的是任何一个具体百分比。

第四条，也是最容易被忽略的：如果一个页面从设计上就该分页，那么它超标只是这个设计问题的一个症状。先想清楚一页展示412个变体是不是必要，再决定要不要为了保住这个设计去做字节层面的腾挪。前面那个站绕了一圈才想明白，一页全展示确实是对的，但那是因为客户按颜色挑；如果换成一个用户根本不会翻到底的页面，那就该分页。

三种常见的返工做法

见过团队在这件事上走过三条弯路，都不算错但都更贵。

第一条是先做整体瘦身再谈排序。瘦身要动很多人，排期一拖就是一个季度，而排序调整半天就能做完并且立刻消除风险。正确顺序是先排序后瘦身，因为排序解决的是丢什么，瘦身解决的是丢多少。

第二条是把这件事做成一个专项。一旦立项就要有目标、有里程碑、有复盘会，而它本质上只是一条构建断言。做成专项的结果通常是做完一轮之后没人维护，半年后原样复发。

第三条是把阈值定得太紧。有人量完之后把警戒线定在100万字节，理由是要留足余量。定得越紧越容易被绕过——第一次构建失败的时候大家还会认真看，第三次失败之后那条断言就被人注释掉了。

最后一件不建议做的事

不要给Googlebot单独输出一个精简版HTML。

给不同来访者返回不同内容这条路历史上翻过车，JS判断移动端并自动跳转的SEO最佳实践那篇复盘过其中一次。

技术上做得到，逻辑上也说得通——反正爬虫不需要那些交互数据。但它引入了一整类新风险：两个版本会随时间漂移，而漂移的方向你无法监控；一旦被判定为向搜索引擎和用户提供不同内容，代价远大于你省下的那点字节。

把重要的东西往前排是零风险的，给爬虫另做一份不是。在同样能解决问题的前提下，选那个不会在别的地方炸开的做法。

什么时候需要重新量一次

跟着改动走，不跟着日历走。下面这几件事发生之后必须重量：换前端框架或者升级大版本、给商品卡片增加新字段、上线新语种、接入新的第三方脚本、把分页改成一页全展示、做一次视觉改版。

改动之后指标异动的排查顺序有讲究，GA4直接流量突然暴增的六类成因排查决策树那篇的决策树写法值得抄。

要让检查跟着改动走而不是跟着日历走，文件变动触发是个思路，inotify怎么用才能文件一变就触发那篇讲了实现。

最容易漏的是接入第三方脚本。因为那不是你写的代码，改动记录里可能只有一行“接入某某工具”，而它往页面里塞了多少字节，通常连接入的人都不知道。

把这件事交给谁

这是个组织问题，而且是这类跨界问题里最典型的一个。它的检测在构建流程里，属于前端；它的后果在收录和结构化数据上，属于SEO；它的诱因是性能优化，属于另一个KPI。

前端和SEO在一个数字上达成一致就够了，服务器配置对SEO影响的20项必看清单那篇里也有好几项是这种需要两边共管的。

保哥的建议是把断言放在前端的构建流程里，把阈值的解释权放在SEO这边。前端负责让这个数字在每次构建时出现，SEO负责说明这个数字为什么是这个值。两边都不需要理解对方的全部逻辑，只需要在一个数字上达成一致。

关于这套方法本身的自反

这篇文章讲的是“被截断的内容不会有人告诉你”，那它自己的证据链有没有被截断的地方？

把自己的证据链摊开写清楚是笨办法但有效，AI搜索的归因数据平台为什么不会给你那篇也用了同样的写法。

有，而且至少有三处。第一，46个样本全部是2026年8月上旬的一次快照，任何一个站在这之后改版，本文对它的描述就失效了。第二，抓取用的是普通浏览器身份，如果某个站对Googlebot返回的是另一份HTML，本文量到的就不是Googlebot看到的那一份。第三，2MB这条线是否按解压字节计算，官方文档并没有说死，本文是按更保守的口径推的。

这三处不确定性里，前两处会让个别数字失准，第三处会让整篇文章的结论方向发生变化。所以它被单独拿出来写了一整节，而不是塞在脚注里——一个可能推翻结论的前提，不该出现在比结论更小的字号上。

最后一句

这件事在优先级列表上的位置其实不高。它不影响用户体验，不影响转化路径，多数站量完之后会发现自己很安全。

五分钟能做完又值得做的事不多，谷歌SEO技术清单的5大核心方向那篇里还有几件成本同样低、同样容易被跳过的。

它值得做的唯一理由是：检查它只要五分钟，而它出问题的时候不会有任何人告诉你。符合这两个条件的事情在这个行业里不多，遇到一件就顺手做掉。

常见问题解答

页面超过2MB会不会导致整页不被收录？

不会。官方原文写得很明确，Googlebot不会拒绝这个页面，它只是在2MB的位置停止取回，然后把已经拿到的那部分当作完整文件交给索引系统。页面照样会被索引，只是索引的是被切过一刀的版本。这也是这个问题特别难被发现的原因——覆盖率报告不会变红，抓取统计里那次请求是200，你的所有监控都显示一切正常，只有排在后面的那些内容在谷歌那边不存在。

这2MB算的是压缩前还是压缩后的字节？

官方文档在同一段里用了两种表述，一处像是在说文件本身，一处像是在说线路传输量，没有把话说死。实测46个页面的压缩倍数中位数是7.55倍，这意味着按传输字节算超标的是0个，按解压字节算超标的是4个。保哥的选择是按解压字节算，理由不是确定官方就这么算，而是在两种可能的口径里，一个会漏报一个会误报，而漏报的代价是你永远不知道自己丢了东西。

怎么快速判断自己的页面有没有风险？

最快的办法不需要任何工具：在浏览器里打开那一页，右键查看网页源代码，全选另存为本地文件，看文件属性里的大小。低于100万字节可以直接收工。这个动作要挑对页面，优先量变体最多的分类页和商品数最多的筛选结果页，这两类基本能覆盖九成风险。首页反而不是最危险的，因为首页的商品数通常是固定的，分类页会跟着SKU一起长。

为什么我的页面没有图片却有2MB？

因为撑起体积的多半不是内容，是内容的影子。用了服务端渲染加客户端接管的框架，会把这一页渲染时用到的数据原样序列化成JSON再内联进同一个文件，于是同一份商品列表在文件里存在两次。实测里最极端的一个这样的标签单独就有2384424字节，比整条抓取上限还长287272字节。另外两路是内联的首屏样式和内联的矢量图标，某些站单这一项就占页面的57%。

把结构化数据放在页面底部有问题吗？

规范上完全没问题，从来没有哪条规则要求结构化数据必须写在head里。它的问题是把一件本来零风险的事，变成了一件跟页面长度绑在一起的事。实测里有个头部品牌的分类页，唯一一段结构化数据的起点在2670014字节，落在截断点之外57万字节，等于写了但没生效。把它移进head是全部检查动作里唯一一个能永久免疫的，成本大约十分钟。

页面瘦身能不能提升排名？

不能，页面长度本身不是排名因素。如果你量完发现远低于上限，请到此为止，不要顺手做一轮“页面瘦身优化”。这件事的全部价值在于避免一个二元的、灾难性的、不报错的失败，不在于把一个数字变小。把800KB减到400KB不会带来任何搜索侧收益，而这个区分很重要，因为它决定了你该在什么时候停手。

能不能给爬虫单独输出一个精简版页面？

技术上做得到，但不建议。它引入了一整类新风险：两个版本会随时间漂移，而漂移的方向你没法监控；一旦被判定为向搜索引擎和用户提供不同的内容，代价远大于省下的那点字节。相比之下，把分页链接和结构化数据往文档前面挪是零风险的，效果也一样。在同样能解决问题的前提下，选那个不会在别的地方炸开的做法。

多语言站点需要每个语种都量吗？

需要，而且这是最容易被漏掉的一环。同一套模板下不同语种的文案长度差别可能很大，保哥见过英文版1.7MB安全、德文版2.1MB超标的情况，原因只是德语复合词更长。你在英文版上做的全部测试，一次都覆盖不到那个真正出问题的版本。这一件不产生任何代码改动，只产生一张表，半天就能做完，但它是唯一能发现这类问题的动作。

权威参考资料