电商SEO审计逐条查网址要跑100天，改成按页面模板抽样半天就查完了

摘要：一份电商站的技术审计报告动辄导出几万行，每行一个网址。但这些网址不是一个一个写出来的，它们出自几十个模板；同一个错误在报表上占了8000行，落到代码里只是一处判断写反了。Baymard今年发的电子与办公品类基准里，9个大站一共只被评了565个页面设计，平均每站62.8个——这就是那几十万个网址真正的形状。报表按网址计数、施工按模板计数，两个单位差三到四个数量级，于是一个能一次性改掉的问题，在优先级列表里被拆成几千件小事，永远排不进这周。

做技术SEO久了会有个熟悉的画面：从Search Console里导出一份问题清单，几千上万行，每行一个网址。你把它发给研发，研发看一眼说，这得排期。然后这件事就搁下了。

下个季度再导一次，行数只多不少。

保哥今年翻Baymard一份电子与办公品类的体验基准时，注意到一个不起眼的计量口径。那份研究评了9个电子与办公类的大站，公布的数字里有一项是页面设计数：B&H Photo 80个，Best Buy 85个，Newegg 62个，最少的HP 52个，9个站加起来565个。

这几个站，随便哪一个的商品数量都在几十万量级。但真正被打开、被逐条打分的界面，一个站只有五六十个。

这个数字一开始看着像是研究方法的限制——毕竟人工评测做不了几十万页。但换个方向想，它其实是那几十万个页面的真实形状：几十万个网址是几十个模板渲染出来的，逐条看几十万遍，看到的东西也就那么多。

问题在于，我们平时用的所有报表、所有工单、所有优先级列表，用的都不是这个单位。

一份电商SEO审计报告有几万行，落到代码上真正要改的有几处？

先把两个数并排放一次

拿一个中等规模的跨境电商站举例，商品4000款，每款平均4个变体，加上分类页、筛选页、内容页、账户页，被搜索引擎发现的网址大概在18000到25000之间。这是第一个数。

同一个站，主题目录下的模板文件有多少个？一个Shopify主题大概40到60个liquid模板，一个WooCommerce主题加上插件覆写大概50到80个php模板。这是第二个数。

两个数放在一起，比值是300到500。也就是说，平均每一个模板负责渲染三四百个页面。这个比值在越大的站上越夸张，百万级SKU的站能到五位数。

那几万行是怎么产生的

报表之所以按网址计数，原因很实在：搜索引擎抓的是网址，索引的是网址，排名的是网址。Google的整条流水线从头到尾都以网址为单位，这一点在搜索引擎抓取、索引与排名的三段式流程里是明确的。

所以Search Console给你的东西必然是网址列表。页面索引报告里，每一个未被收录的网址占一行，附上一个原因；例子表最多给1000行，而且官方文档明说了，即使不足1000行也不保证列全。

这个上限本身就值得琢磨——Search Console的数据阈值与1000行取样上限是很多人踩过的坑，但大多数人的应对是想办法绕开上限拿更多行，很少有人反过来问：为什么要拿更多行。

那几十处是怎么数出来的

把报表里那几千行按产生原因归类，你会发现它们不是几千个独立事件。分类页的分页参数生成了重复内容，这是一处逻辑；商品变体各自生成了独立网址却没写规范标签，这是第二处；筛选组合被爬虫展开，这是第三处。

三处逻辑，几千行报表。这个映射关系不是特例，它是模板化站点的常态。程序化SEO靠模板加数据源批量生成页面的时候，大家都很清楚一个模板能生出几千页；但反过来做诊断的时候，这个常识就用不上了。

为什么用不上？因为生成的时候你站在模板这一侧，看到的是一份模板加一份数据；诊断的时候你站在报表这一侧，看到的是一份网址列表，模板信息在那份列表里根本不存在。

两个数一相除，得到的是什么

报表行数除以真正要改的地方数，这个比值保哥习惯叫它错位比。它衡量的不是问题有多严重，而是你手上这份材料被打散到了什么程度。

比值等于1的时候最舒服：报表上一行，代码里改一处，这是内容站或者小型企业站的常态。比值到了几百上千，你面对的就不再是一个待办列表，而是一堆碎片。

碎片有个特别不好的性质：它没法被估工时。研发看到8000行会说排期，看到商品页模板里的送达日期分支写反了会说下午改。同一件事，换了个说法，从一个季度变成一个下午。

这不是在说报表没用

得把话说清楚，按网址组织的报表没有任何问题，它甚至是唯一诚实的组织方式——搜索引擎确实是那样看你的站的，Search Console只是如实转述。Search Console各报告的定位与诊断路径该怎么用还是怎么用。

要改的是接收端。报表按网址交付，你按模板接收，中间那一次换算得有人做。现在的情况是这次换算没有归属：SEO拿到报表直接转发，研发拿到几千行直接排期，两边都没有做那次归并。

更麻烦的是，谁都没觉得少了一步。报表是官方的，转发是标准动作，排期是正常流程，链条上每一环都合规，只有结果不对。

三句判据，第三句不用问任何人

判断自己是不是正踩在这个坑里，三句话就够。

第一句：这个问题在你的报表上占了几行。第二句：修好它需要改几个地方。第三句：前两个数相除等于几。

前两句都需要动手查，第三句是纯除法。而且这三个数里没有一个需要向别人索取——报表在你自己的Search Console里，模板在你自己的代码库里，除法在你自己的脑子里。这跟很多需要供应商配合才能查清的问题完全不同。

跟分母被划小不是一回事

前阵子写过一类相邻的毛病：一个百分数只公布分子的性质，不公布分母的边界，读者会自动把分母补成全部。那种情况下问题出在数据发布方，他们主动把统计范围缩小了，而你从数字表面看不出来。

本文这一类不一样。没有人缩小任何范围，报表给的是全量，一行都没藏。问题出在这份全量数据的计量单位跟你要做的事对不上。

区别在哪儿最要紧？那一类的解法是追问纳入标准，问清楚了就能还原；这一类追问没有意义，因为对方给的就是全部，你追问的结果还是那几千行。要解决只能自己换单位。

跟观测者进不去也不是一回事

还有一类相邻情况值得先排除掉：有些界面之所以没有数据，是因为要看到它得先付出很大代价——真下一单、真付一笔钱、真等上十几天，评测机构进不去，你自己的团队通常也进不去。那种情况下缺的是观测行为本身，报表上那一格是空的。

本文说的这件事恰恰相反：数据全都在，一行不缺，覆盖率百分之百。你能看到每一个网址，能看到每一个网址上的每一个问题，什么都没少。少的只是一次归并。

所以两者的难度也完全不同。观测不到的那一类需要额外投入才能补上，本文这一类不需要任何新投入，只需要把已经拿到的东西按另一个维度重新数一遍。从投入产出上看，它可能是技术SEO里最便宜的一次改进。

为什么这件事很少被当成问题提出来

保哥想过一阵这个问题。最合理的解释是，错位比这个东西在小站上根本不存在——一个80页的企业官网，模板12个，网址80个，比值不到7，你按哪个单位数结果都差不多，两种口径给出的优先级排序几乎一致。

大多数人的SEO经验是从这种规模的站上长出来的，习惯也是。等到手里的站长到几万页，习惯不会自动切换，因为中间没有任何一个时刻会跳出来提醒你该换单位了。它是连续变化的，从7到70到700，每一步都不明显。

再加上一点：按网址读报表这件事永远不会出错。你按网址读，读到的每一条都是真的，改掉的每一条也确实改掉了。它只是慢，而慢这件事在没有对照组的时候感觉不出来。

这跟技术SEO债务越积越多拖累流量那一类问题的手感很像——单看每一笔都不致命，坏就坏在它们会持续挂在账上，而清账的速度取决于你用哪个单位记账。

换了单位之后，待办数会突然变得很小

这里得提前打个预防针，不然下个月要挨骂。把同一份报表从网址口径换成模板口径，待办条目数会从几千掉到几十，掉两个数量级。这个数字变化跟工作量没有关系，纯粹是换了个单位。

如果这个数被当成成绩汇报上去，麻烦在后头。按模板修完一轮之后，剩下的确实是页面级的个案——某个SKU的图挂了、某条内容被误删了——这些没法归到任何模板上，条目数会重新往上爬。

到那时候再解释单位换过了，听起来全像找补。所以动手之前先用一句话说清楚：这个数会先掉一大截再回升一点，掉的那部分是被合并的，不是被修掉的。

这套换算对多大的站才划算

保哥的经验是错位比过50就值得做一次，过200就必须做。低于50的站直接按网址推进反而更快，多加一层归并纯属仪式感。

还有一个更简单的判据不用算比值：如果你最近三次把问题清单发给研发，三次都听到了排期两个字，那就是该换单位了。研发说排期通常不是在推诿，是他们从那份材料里读不出工作量，读不出工作量就只能给一个最保守的答复。

换成模板口径之后，同一份材料读起来是这样的：三个模板，每个模板一处判断，其中两处在同一个文件里。这种描述是可以估工时的，而可估工时的事情才排得进这周。

先别急着数模板，先确认你数的是不是模板

说到数模板，很多人第一反应是打开主题目录数文件个数。这个做法能得到一个数，但那个数经常是错的，因为文件数跟渲染形态数不是一回事：一个商品页模板里可能有五六个分支，缺货走一条、预售走一条、礼品卡走一条、带电池的走一条，每条分支渲染出来的页面在用户眼里、在爬虫眼里都是不同的东西，可它们共用同一个文件。

反过来也有：三个不同的文件可能渲染出几乎一样的页面，比如某次改版留下的旧模板还挂在两个老分类上，代码不一样但输出没差别。按文件数你会数出3，按形态数只有1。

所以正确的问法不是有几个模板文件，而是改动一处会同时影响哪一批页面。这个问法直接对应你要做的事——排期、验收、回归测试，全都是围绕改动一处展开的，而不是围绕文件展开的。

组件化之后模板边界确实模糊了，还能这么数吗

能，但要换个层次数。前端全面组件化之后，一个页面是几十个组件拼出来的，模板这个词在代码里可能已经找不到对应物了。这时候该数的是页面级的组装配置，也就是路由到组件树的那一层映射，通常还是几十个量级，跟传统模板数在同一个数量级上。

组件化带来的真正变化不是模板变多了，而是一个问题可能同时落在两层：既可能出在某个组件里，也可能出在某个页面把这个组件配错了参数。前者影响所有用到它的页面，后者只影响一类页面。诊断的时候得先分清是哪一层，不然改错地方。

这跟前端工程师和SEO协作的那几个动作里说的是同一件事的两面：前端很清楚自己改的是组件还是页面，SEO拿到的报表里这个信息完全不存在，两边各说各的，很多沟通成本就是这么来的。

建站平台不同，数出来的东西也不同

Shopify这类平台上模板边界最清楚，template加section加snippet三层结构摆在那儿，数起来几乎不会数错，代价是你只能在平台给的槽位里改。WooCommerce和Magento灵活得多，代价是覆写层数多，同一个输出可能被三个地方改过，得顺着覆写链往下找。

自研的站两个极端都有。工程规范好的站模板清单本来就是现成的，甚至写在文档里；规范差的站可能连一份完整清单都拿不出来，这种情况下第一次数模板本身就是有价值的产出，比后面任何一条优化建议都值钱。

9个电子与办公大站被评了565个页面设计，它们各自有多少个网址？

先把这份基准的数字原样摆出来

数据来自Baymard在2026年3月底发布的电子与办公品类体验基准。这家机构做电商可用性研究十几年，公开程度在同行里算高的，测了哪些站、评了多少条、按什么加权都写得出来。本文后面所有的推算用的都是它自己公布的数字，没有一个是往外找的。

这份基准里有9个站做了完整案例研究，每个站被记录的页面设计数分别是：Best Buy 85、B&H Photo 80、Dell 63、Newegg 62、Office Depot 58、Microsoft 56、Apple 55、Crutchfield 54、HP 52。相加正好565。

另外三个数：这9个站被跨500多条研究准则人工评估，产生了5000多个加权体验分数和3900多个最佳实践示例。9个站里只有1个拿到了良好或更好的总体评价，其余全部落在及格线附近或以下。

平均每站62.8个，这个数为什么这么稳

最高的85和最低的52之间只差1.63倍。放在一批规模差异极大的公司里，这个离散度低得反常——Apple和Crutchfield的营收差着好几个数量级，商品数量、技术团队、年度预算全都不在一个量级上，可它们的界面形态数一个55一个54，几乎一样。

这说明页面设计数不是跟着公司规模走的，它跟着电商这件事本身有多少种界面形态走。首页一种、分类页一种、列表页一种、商品页一种、购物车一种、结账几步各一种、账户区若干种，加起来就是五六十种，谁做都差不多。

把带App的两个站单独拿出来看更清楚：Best Buy和B&H Photo多评了一个终端，页面设计数就顶到了85和80，比其余7个站高出一截。多出来的部分不是因为它们业务更复杂，纯粹是因为多了一套界面。

用它去除另外两个数，会得到什么

5000多个体验分数除以565个页面设计，约等于每个页面设计承载8.85个分数。3900多个最佳实践示例除以565，约等于6.9个。两个数都在个位数，看着不太像人工评测的工作量。

换个除法就通了：500多条准则乘以9个站等于4500多，跟5000这个数基本对得上。也就是说评分的真正单位是准则乘以站，一条准则在一个站上给一个分，跟页面设计数没有直接关系。

那565是什么？它是证据的单位。评分要落地成一句结论加一张截图，截图取自某一个具体界面，那个界面就是一个页面设计。平均每8.85个分数配一张截图，一张截图上能同时说明八九条准则，这个比例是合理的。

两个单位在同一份报告里并存

这件事本身就很说明问题。一份研究报告，评分按一个单位算，证据按另一个单位算，两个单位之间没有换算关系，读者也不会觉得有什么不对。

因为它们回答的是两个不同的问题。分数回答这个站做得怎么样，页面设计数回答我们究竟看了些什么。前者是结论，后者是覆盖范围，混在一起说才会出问题。

回到自己的站上，你的报表回答的是哪一个问题？Search Console给的是覆盖范围——哪些网址有问题；你需要的是结论——哪几处该改。两者之间同样缺一次换算，而且没人替你做。

博客里写9个站，研究页写的是17个

顺着这份基准往回翻，Baymard的电子与办公品类研究概览页给的数字跟博客文章不一样：那里写的是17个美国与欧洲的电子与办公站，9000多个体验分数，8000多个最佳实践示例。博客里那9个只是其中做了完整案例研究的那一批。

把17个站名逐个数一遍：Apple、B&H Photo、Best Buy、Bang & Olufsen、Crutchfield、Dell、Staples、Netonnet、MediaMarkt、Newegg、Fitbit、RTV Euro AGD、Fnac、Office Depot、GoPro、HP、Microsoft。正好17个，页面上写的数跟数出来的数对得上。

对照博客那9个，缺席的8个是：Bang & Olufsen、Staples、Netonnet、MediaMarkt、Fitbit、RTV Euro AGD、Fnac、GoPro。其中5个欧洲站——丹麦、瑞典、德国、波兰、法国各一个——一个都没进案例研究，进案例的9个全是美国站。

那8个站只有分数，没有页面设计数

这个差别正好落在本文的主线上。17个站都参与了评分，所以都有分数；只有9个站被做成了案例研究，所以只有它们有页面设计数。分数这个单位覆盖了全部17个站，页面设计这个单位只覆盖了9个。

用数字看更直观：9000多个分数除以17个站，约529个每站；5000多除以9，约556个每站。两个数几乎相等，说明分数确实是按站均匀产生的，谁都逃不掉。而页面设计那一栏，另外8个站是空的。

为什么欧洲站集体缺了案例这一层

最省事的解释是排期或者授权，案例研究要放大量截图，涉及的沟通比单纯打分多。这个解释大概率是对的，也没什么可指摘的。

值得留意的是它造成的后果：如果你是欧洲市场的从业者，想看看同区域的站长什么样，翻开这份研究能看到5个欧洲站的分数，但看不到它们的任何一个界面。你能知道它们考了多少分，看不到它们的卷子。

这个不对称跟本文说的错位是同一件事的另一面：分数是可以批量产生的，形态不行。前者的边际成本随站数线性增长且很低，后者要一页一页打开截图，边际成本高得多，于是它自然会覆盖得更少。

9个站里只有1个拿到良好

这一项容易被读成行业整体不行，但配上前面的数字之后，它其实在说另一件事：既然9个站的界面形态数都是五六十个，那么它们的差距不可能来自形态数量，只能来自每一种形态做得怎么样。

基准里给的失分描述也支持这个读法：这些站在定位、比较和给用户吃定心丸这三类时刻上普遍掉链子——早期发现被促销噪音干扰、分类体系割裂、缺少看全部的入口，列表和商品页支撑不了同类商品并排比较，结账流程能走通但讲不清送达时间和总价构成。

每一条都不是某个页面的毛病，全是某一类界面的毛病。电商类目页与集合页的机制那套东西之所以能一篇讲完几万个页面，靠的也是这个前提：那几万个页面本来就是同一件东西。

界面形态数几乎不随商品数增长

这是从那9个站身上能拿到的最有用的一条经验。Apple的在售型号按SKU算是几百，Newegg是几百万，两者的页面设计数分别是55和62。商品数差了四个数量级，界面形态数差13%。

换句话说，商品数增长带来的是同一批模板被复用更多次，不是模板变多。上架第10万个商品跟上架第100个商品，用的是同一个商品页模板，走的是同一批判断分支，出问题也出在同一个地方。

这条经验反过来用最值钱：当有人说我们站太大了、审计做不完的时候，那句话通常是错的。站大意味着每个模板背后的页面更多，不意味着要看的东西更多。要看的东西一直是那五六十个。

那商品数增长真正带来的是什么

带来的是数据的多样性。10万个商品意味着10万套属性组合，其中总有一些会撞上模板里没考虑到的情况——标题特别长的、没有主图的、只有一个尺码的、价格是0的、名称里带引号的。

这些问题确实是页面级的，按模板抽样查不出来，只能靠全量扫描。但它们跟模板级问题有个明显区别：页面级问题的表现是零散的，模板级问题的表现是成片的。报表上突然多出8000行同一类问题，那几乎不可能是数据多样性造成的。

所以两条路都得走，只是分工不同：全量扫描交给爬虫，桌面爬虫做全站审计擅长的就是这个，跑一遍几万页成本很低；模板抽样交给人，人擅长的是判断这一类界面该不该是这样。

把这个比例套到自己站上

拿页面设计数当参照有个直接用途：估自己站的模板清单该有多长。一个正经做的跨境独立站，界面形态数落在35到70之间是正常的，低于25通常说明有东西没数进来，高于90通常说明历史包袱不少，有一批老模板还挂着没退役。

保哥数过几个不同规模的客户站，结果比预期整齐：一个800 SKU的家居站数出41个，一个6万SKU的工业品站数出58个，一个刚上线三个月的站数出33个。SKU差了75倍，形态数差不到1.5倍。

数完之后最常见的反应是那句：原来就这么点东西。这个反应本身就有价值——在此之前，那个站在所有人心里的形状是6万个页面，一个谁也不想碰的庞然大物。

页面设计这个词，到底把终端算进去没有

这个细节值得抠一下，因为它决定了62.8这个数该怎么套到自己身上。从数据本身能反推出答案：带App的两个站页面设计数明显更高，说明同一个界面在不同终端上是分开计数的。

顺着这个思路算：9个站里7个被评了桌面和移动两个终端，2个多评了App，一共20个站点终端组合。565除以20等于28.25，也就是每个终端上大约28种界面形态。

28这个数比62.8更接近做站的人的直觉。一个电商站在桌面端确实差不多就是二三十种页面，移动端再来一套。至于这两套算一套还是两套，取决于你的实现方式——响应式布局的站算一套，独立移动站或者独立App就得算两套。

响应式的站省的不只是开发量

顺着上一段往下推一步：同一个业务，做成响应式的站要维护28种形态，做成桌面加独立移动端的要维护56种，加个App就是84种。

这个倍数关系落到审计上就是工作量的倍数。移动优先索引落地之后的那套机制通常被讨论成收录和抓取层面的事，但从检查面这个角度看，它的价值可能更直接：形态数少一半，每一次验收、每一次走查、每一次回归的成本就少一半。

反过来，正在纠结要不要单独做一个移动站或者App的团队，可以把这一项摆进决策表里——它不是一次性的开发投入，是往后每一次改动都要多付一遍的持续成本。

500条准则摊在8个主题上，为什么模板最少的那两块吃掉了44%？

准则是怎么分布的

Baymard那个研究概览页把500多条准则按主题拆开列了出来，这份拆分表比总数有用得多。8个主题，46个子话题，准则数分别是：首页与类目体系与主导航42条、站内搜索31条、商品列表与筛选76条、商品页111条、购物车与结账111条、账户与自助服务66条、全站功能与导航51条、忠诚度与奖励12条。

把这8个数加起来是500整。所谓500多条里的那个多，指的是同一条准则在不同终端上的变体，主干正好500条。

光看这一列已经能读出一点东西：商品页和结账各111条并列第一，两者相加222条，占了全部准则的44.4%。这两块的重要性是共识，倒不意外。

再补上一列，事情就变了

意外的地方在第二列。给每个主题标上它在一个普通电商站上大致对应几个模板，表就变成了另一副样子。

最上面一行和倒数第二行差15.2倍。商品页那一个模板要同时满足111条准则，账户区9个模板分摊66条，平均每个只需要顾好7条多一点。

这个差距意味着什么

意味着改动的杠杆完全不一样。花一天时间过一遍账户区里的某个页面，你能覆盖7条准则；花一天时间过一遍商品页模板，理论上能碰到111条。同样是一天，能触及的判断点差15倍。

而且这还没算网址。商品页模板背后是全站80%到90%的网址，账户区那9个模板背后是固定的9个页面（每个用户看到的内容不同，但页面就那么几个）。一个模板同时占着22.2%的准则和大约85%的网址，这是全站唯一一个两头都顶格的位置。

所以排期上的结论很直白：如果只有一段完整的时间可以投入，投给商品页模板；如果有两段，第二段给列表与筛选。这个顺序跟大多数团队的实际排期顺序不太一样——实际排期里排在前面的往往是那些被投诉得最多、最容易被感知到的地方。

为什么感知顺序跟杠杆顺序对不上

因为被投诉的强度跟单个页面的糟糕程度成正比，跟这个页面有多少个副本没关系。账户区某个功能坏了，用到的人会集中反馈，声音很响；商品页上少了一句送达说明，几十万个页面同时少，但没有一个人会为这件事专门写工单。

这跟索引膨胀那类全站性毛病的性质是一样的：单看任何一个页面都说不上错在哪，坏就坏在它是成片的。影响面越大，单点反馈反而越弱，因为用户遇到的是常态而不是异常，常态不值得写工单。

反过来说，凡是靠工单量排优先级的团队，都会系统性地低估模板级问题。工单量测的是愤怒的密度，不是损失的总量。

全站功能那51条为什么标了不适用

这一栏值得单说。页眉、页脚、面包屑、全局提示、加载状态这些东西不属于任何一个页面，它们横跨所有模板。改一处，全站所有页面同时变。

从杠杆看这是最高的一档，比商品页还高；从风险看也是最高的一档，因为改错了全站一起错，没有任何一个页面能幸免。这个组合让它成了最容易被拖延的一块——收益大，但没人愿意第一个动。

实践里的办法是把它拆细：面包屑归面包屑，全局提示归全局提示，每次只动一个横切关注点，别打包成一次页眉页脚大改。面包屑的几种类型与结构化数据实现可以单独走一次上线，跟其他横切改动互不影响。

再看一遍那46个子话题怎么分的

准则数之外还有一列是子话题数：商品页12个、商品列表与筛选8个、购物车与结账7个、账户与自助服务7个、首页与类目体系4个、站内搜索4个、全站功能3个、忠诚度1个，合计46个。

拿准则数除以子话题数能看出每个子话题的颗粒度：商品页9.25条一个，结账15.9条一个，账户区9.4条一个，忠诚度12条一个。结账那个数明显偏高，说明它的每个子话题都被拆得很细——一个填地址的步骤就能挂十几条准则。

这跟做过结账优化的人的直觉一致。结账弃单的那几类真实成因里，每一类往下都能再分出好几个判断点，不是一句优化结账流程能盖住的。

把准则密度换算成体检时间

有个更接地气的用法：拿每模板承载的准则数去估一次人工走查该花多久。按一条准则平均3分钟看一眼算，商品页模板一次完整走查要333分钟，五个半小时；账户区某个页面22分钟。

这个估算不精确，但量级是对的，而且它解决了排期里最难的一件事——把一个模糊的动作换成一个能写进日历的时长。说走查一遍商品页没人知道要多久，说这件事要占掉一整天，排期会议上就有得谈了。

为什么结账那111条仍然要排在前面

看完上面这张表，可能会得出一个偏激的结论：结账只影响5个页面，杠杆比商品页低多了，往后排。这个结论是错的，因为它漏了一个维度。

网址数量衡量的是曝光面，不是价值密度。结账那5个页面上走过的是已经决定要买的人，每一个都比商品页上那些还在闲逛的人贵得多。模板口径解决的是怎么把工作量算准，不解决怎么把价值算准，后面这件事还得靠业务判断。

保哥的做法是两个维度都写出来再排：一列是这个模板覆盖多少网址，一列是这个模板上每千次访问值多少钱。前者从爬虫结果里数，后者从分析工具里拉，两列相乘再排序，跟只看其中一列排出来的顺序经常差很多。

这张表怎么套到自己站上

Baymard那500条准则要付费才能看全，但这张表的用法不依赖具体条目。你需要的只是每一类界面上大概有多少个判断点，而这个数你自己也能估——把上次做验收时列的检查项按界面归一次类就有了。

估出来的数不用准，因为它的用途是排序不是核算。只要商品页那一栏明显高于账户区那一栏，结论就已经成立了，多几条少几条不影响。

忠诚度只有12条，这算不算说它不重要

不算，它说的是这块的判断点少，不是这块的收益少。12条准则对应2个模板，每模板6条，是全表里最低的一档；但会员体系对复购的影响谁都知道不小。

这里能看出准则数这个指标的边界：它衡量的是一类界面上有多少件事可能做错，不衡量做对了能赚多少。界面越复杂、状态越多、要展示的信息越杂，可能做错的地方就越多，跟这块业务值多少钱是两回事。

所以准则密度只能用来估工作量和排查顺序，不能直接当优先级用。把它当优先级用会得出会员体系不用管这种荒唐结论，而实际情况往往是这12条里有几条一直错着，因为压根没人系统看过。

如果你的站没有某一类界面呢

这个情况比想象中常见。很多跨境独立站没有站内搜索（或者只有一个几乎没人用的搜索框），没有会员体系，账户区只有登录和订单列表两页。按上面那张表，这些站直接少掉31加12加一部分账户准则，将近100条。

少掉的这些不是省下来了，是转移了。没有站内搜索意味着用户找不到东西的时候只能靠分类导航，于是首页与类目体系那42条的权重上升；账户区功能少意味着售后问题会全部涌向客服，那部分体验的载体从界面变成了人。

换句话说，界面形态数少的站，每一个形态上的压力更大。这解释了一个常见现象：小站的商品页往往塞得比大站还满，因为它得一个页面干完人家三个页面的活。

主题划分本身就是一次模板划分

最后说一句可能有点绕但很要紧的话。Baymard把电商体验切成8个主题，这个切法看起来是按用户旅程切的——发现、比较、决策、支付、售后。但你把它跟模板清单摆在一起会发现，两者几乎是一一对应的。

这不是巧合。用户旅程之所以能被切成这几段，正是因为每一段都发生在一类特定的界面上；而界面之所以被做成那几类，也正是因为用户在那几个阶段需要的东西不同。模板结构是用户旅程在代码里的投影，两边说的是同一件事。

这一点在做电商用户旅程与关键词布局的对应时特别有用：旅程图上的每一段，落到站上就是一到两个模板，落到关键词上就是一批意图相近的词。三者能对齐，排期才不会各说各话。

这张表还有个用法：给外部报价挑毛病

找外部做审计或者做体验优化的时候，报价单上常见的写法是全站体验诊断多少钱。拿准则密度这张表去对一遍，很快能问出几个关键问题。

比如：这次诊断覆盖哪几类界面？商品页那111个判断点里打算过多少？账户区要不要做？会不会只看首页和几个大类目页？把范围问题落到界面类型上，报价里那个模糊的全站两个字就撑不住了。

反过来，如果你是提供服务的一方，主动把这张表放进方案里是很占便宜的做法——它把工作量说清楚了，也把不做什么说清楚了，后面扯皮的空间小很多。优化服务合同里那些容易含糊的条款大多数都栽在范围没界定清楚上，而界面类型是所有界定方式里最难被曲解的一种。

Search Console的两份报告，为什么一份按网址数、另一份按页面组数？

同一个后台，两套计量口径

这件事保哥自己也是最近才认真对照过一遍。打开Search Console，页面索引报告和网页体验核心指标报告摆在同一个菜单里，看起来是一套东西的两个视角，实际上它们数的根本不是同一种东西。

页面索引报告的单位是网址。每一个未被收录的网址占一行，配一个原因；点进某个原因，能看到受影响的网址列表，最多1000行，官方文档还专门补了一句：即使不足1000行也不保证列全。

核心指标报告的单位是网址组。这份报告的官方说明写得很清楚，数据按状态、指标类型和网址组三层组织，表格里每一行是一个组，展示的那个网址只是这个组的代表，整张表限200行。

那句藏在说明里的提醒

核心指标报告的文档里有一句话特别容易被略过：图表上方那几个状态标签显示的是网址总数而不是网址组数。原文特意加了个括号强调这一点。

也就是说同一屏界面上，上半部分的数字按网址算，下半部分的表格按组算。上面写着4万3千个网址表现不佳，下面列出12行。两个数之间差着三个数量级，而它们描述的是同一件事。

看惯了不觉得有什么，第一次注意到会愣一下：为什么要这么设计。答案其实很实在——上面那个数是给你判断严重程度的，下面那张表是给你去修的。判断严重程度要看影响面，去修要看改哪儿，两件事天然需要两个单位。

Google已经替你做了那次换算

这是本文最值得留意的一处。前面说报表按网址交付、施工按模板进行、中间缺一次换算，而在核心指标这一块，Google把换算做完了才交给你。

它把4万3千个网址归并成12个组，每组给一个代表网址、一组数值、一个状态。你拿到的东西已经是模板口径的了，不需要自己再归并一次。

这也解释了为什么核心指标那块的优化通常推进得比较顺：材料一到手就是可执行的形状——12行，每行一个问题，每个问题对应一类页面。研发看到12行不会说排期。

页面索引报告为什么不这么干

技术上不是做不到，Google显然有能力把索引问题也按相似页面归组。但两份报告的性质不同：性能指标是连续量，同一类页面的数值天然接近，归组之后组内方差小，代表值有意义。

索引状态是离散量，而且高度依赖单个网址的具体情况。同一个商品页模板下，一个网址被判重复、另一个被判软404、第三个被判抓取异常，三种状态没法归成一个组给一个代表。索引覆盖里那几种状态各自的判定机制拆开看就明白，它们的成因链条完全不同。

所以这不是Google偷懒，是这一类数据本身难归组。但难归组不等于不用归——只是这次得你自己动手。

自己动手归组，第一步是给网址打标

做法比想象的简单。把页面索引报告导出来，拿网址路径里的特征做匹配，给每一行贴一个模板标签：路径里带 /products/ 的归商品页，带 /collections/ 的归列表页，以此类推。

这一步靠正则就能完成，几十行脚本。做完之后原来那几千行会坍缩成十几到几十行，每行是一个模板加一个问题类型，后面跟着数量。这份归并后的表才是能拿去开会的东西。

要注意的是路径规则不总是干净的，历史遗留的网址结构经常对不上。网址结构与短链设计的那套机制做得规整的站，这一步几乎零成本；结构混乱的站得先花点时间理规则，而理规则这件事本身也是有价值的产出。

两份报告的上限，含义完全不同

页面索引报告1000行，核心指标报告200行，后者的上限只有前者的五分之一。听起来后者更抠门，实际情况正好相反。

一个4万网址的站，1000行占全部网址的2.5%，剩下97.5%你看不到；同一个站的模板数假设是55，200行是模板数的3.6倍，绰绰有余，多出来的空间还够容纳同一个模板在不同终端、不同状态下的多行记录。

同一个量级的行数上限，换个单位之后，从远远不够变成绰绰有余。这不是巧合——行数上限是按人眼一次能读多少条设计的，几百行就是人的极限，而模板数恰好也在几十这个量级。两者天然匹配，网址数天然不匹配。

组员按曝光倒序，尾部你看不见

还有一条细节值得记：文档里写了，组内成员是按曝光量倒序列出的。你点开一个组，看到的是这个组里流量最大的那几个网址。

这个排序在多数时候是对的——先看重要的。但它会掩盖一类情况：同一个模板下，头部网址和长尾网址的表现可能差很远。头部商品图片被CDN缓存得好好的，长尾商品的图第一次访问要现回源，这两批页面的最大内容绘制根本不在一个水平上。

组给出的那个数是整组的分位值，头部拉得动它，但你从组员名单里翻不到反面样本。真想确认，得自己找几个长尾网址单独测。多层缓存对首字节时间的影响那套排查里，冷热路径的差异经常就是这么被漏掉的。

数据不够的时候，两份报告的退路不一样

核心指标报告的文档写了一条兜底规则：某个网址组的数据量不够展示时，Search Console会往上创建一个整站层级的组，把该协议、主机和端口下的所有网址数据聚在一起。

这条规则有个副作用值得警惕。当你看到的是整站层级的数字时，界面上并不会有一个显眼的提示告诉你口径已经跳变了。你以为在看某一类页面，实际在看全站均值，而全站均值被首页和头部页面拉得相当好看。

页面索引报告没有这种退化，数据不够就是不显示。两种处理各有道理，但对读报表的人来说，退化成整站是更危险的一种——它不留空白，留了一个看起来正常的数。这跟几家工具的数据对不上时怎么核账是同一类麻烦：数字都在，口径悄悄换了。

归组结果拿到之后，先做哪一件

假设你已经把几千行坍缩成了20行，每行是一个模板加一个问题类型。这时候最容易犯的错是从数量最大的那一行开始改，因为它看起来影响面最大。

先看的应该是数量大且集中在单一模板上的那几行。数量大但横跨十几个模板的行，说明这是个横切问题，成因可能在服务器配置、在全局脚本、在某个被所有页面引用的组件里，排查路径完全不同，往往也更长。

判断方法很省事：同一个问题类型下，如果90%以上的行落在一个模板标签上，那就是模板级问题，直奔那个模板的代码；如果分散在五个以上标签上，先别碰模板，去查响应头里那几个会影响收录的字段和全局配置，那里藏着的东西影响面更大也更隐蔽。

这次归组该谁做

保哥见过三种分工，效果差别挺大。第一种是SEO自己做，好处是他最清楚问题该怎么分类，坏处是他往往不知道代码里的模板边界在哪，标签会打得跟实际结构对不上。

第二种是研发做，好处是模板边界一清二楚，坏处是研发拿到的是一份他看不懂的报表，不知道哪些问题是真问题——收录被规范标签指向别处这件事在SEO眼里是正常，在研发眼里可能是个bug。

第三种是两个人坐在一起做一次，之后固化成脚本。这一种最费当天的时间，但只用做一次；把SEO动作接进持续集成之后，每次导出自动带上模板标签，后面所有人拿到的都是归好组的版本。头一次两小时，往后每次零成本。

有没有不该归组的时候

有，而且值得说清楚，免得走到另一个极端。归组的前提是组内页面确实同质，一旦这个前提不成立，归组会把真问题藏起来。

最典型的是多店铺、多语言、多区域的站。同一个商品页模板，在德国站和日本站上渲染出来的东西可能差很远——字体不同、地址格式不同、税费展示逻辑不同、合规提示不同。按模板归成一组，德国站那一批的问题会被日本站的正常数据稀释掉。

这种站的正确做法是模板乘以区域当作归组单位，行数会翻几倍，但每一行仍然是可执行的。同一套模板铺十种语言时的重复内容风险说的也是这件事：模板相同不代表输出相同，中间还隔着一层数据和一层配置。

问题类型和模板是两个维度，别压成一维

归组的时候有个常见做法是直接按问题类型汇总：重复内容3200条、软404有800条、被规范标签排除1400条。这样确实比原始报表清楚，但它只压掉了一个维度。

正确的做法是做成一张两维表，行是模板，列是问题类型，格子里填数量。同样的数据，这张表能读出按问题类型汇总读不出的东西：某个模板在三种问题类型上都有量，说明这个模板本身有结构性毛病；某种问题类型横跨十几个模板，说明它的成因在全局配置而不在模板。

表做出来通常是十几行乘五六列，一屏放得下。而这张表可以直接当排期表用——先做那些整行数值高的模板，再做那些整列数值高的全局项。

导出之后第一件事是清干净

实操上有个容易吃亏的地方：报表导出的网址里会混着一批不该参与统计的东西——带跟踪参数的重复网址、分页序列里的深层页、已经下架但还没清理的旧地址。

这些不清掉，归组结果会失真。最典型的是分页：一个分类页带出五十页分页地址，全部归进列表页模板，这个模板的数量一下子被推高十倍，看起来像是重灾区，实际上只是分页多。

清理规则不用复杂，把跟踪参数剥掉、把分页序列合并成首页、把已知的下架路径排除，三条规则能解决八成噪声。分类页分页的处理方式本身就该有一套明确规则，做归组正好顺手把它捋一遍。

Google给页面分组时假设了什么，这个假设跟模板是什么关系？

官方文档里那一句

核心指标报告的说明里，讲网址组的那一段末尾有这么一句：这些组被假定共用同一套框架，组内出现的任何表现不佳，其原因很可能来自同一个底层成因。

这句话很容易滑过去，它读起来像一句技术说明。但它其实是整份报告成立的前提，而且是一个可以被证伪的前提——它明确说了假定两个字。

把它翻译成做站的人的话：同一个模板出来的页面，快慢是一回事，坏也坏在同一处。Google敢把4万个网址压成12行给你看，靠的就是这个判断。

共用同一套框架，说的就是模板

Google不用模板这个词，因为它看不到你的代码。它只能从外部观察：这一批页面的结构相似、资源相似、渲染路径相似，于是推断它们出自同一处。

这个推断的准确度取决于你的站有多规整。结构干净的站，Google分出来的组跟你的模板清单会高度吻合；历史包袱重的站，同一个模板下的页面可能因为某些老数据走了完全不同的渲染分支，Google会把它们拆成两个组。

这里就出现了一个免费的好东西：Google的分组结果可以当作你模板清单的外部校验。你自己数出来55个模板，Google有数据的那部分分出12个组，把两边对一遍，对不上的地方全是线索。

对不上的两种情况，各说明什么

第一种：你认为是一个模板，Google拆成了两个组。这说明这个模板里有一条分支的表现跟其余部分明显不同——可能是某类商品多加载了一个第三方脚本，可能是某个分类下的图片没走同一套处理管线。

这种情况几乎总是有价值的发现，因为你自己是数不出来的。你看代码只看到一个文件，看不到运行时那条岔路把页面变成了另一副样子。

第二种：你认为是两个不同模板，Google归成了一个组。这说明这两个模板的产出实质上没有差别，那么它们为什么是两个文件就值得问一句。多半是历史遗留，两套代码维护着同一件事，改一处忘一处的坑就藏在这儿。

怎么把这次对照做出来

操作上没什么门槛。核心指标报告里点开每一个问题，能看到代表网址；把这些代表网址收集起来，用你自己的路径规则打上模板标签，然后看每个组的代表网址落进了哪个标签。

一个组的代表网址落进两个标签，说明Google认为它们是一类而你认为不是；两个组的代表网址落进同一个标签，说明你认为是一类而Google认为不是。两种情况都记下来，形成一份差异清单。

这份清单通常不长，十几条顶天，但它是全站唯一一份由外部视角产生的模板结构评估。核心指标的行业基准与投入产出测算那类判断做完之后，接着做这一步成本几乎为零，因为数据本来就在同一屏上。

这个假设什么时候会失效

失效条件挺明确：当页面的表现主要由数据决定而不是由代码决定的时候。

最常见的场景是图片。同一个商品页模板，有的商品配了12张4 MB的原图，有的只有1张压好的图，最大内容绘制能差出好几倍。这时候组内方差很大，Google给出的那个分位值对谁都不准。

另一个场景是评论。评论区在有300条评论的页面和有0条评论的页面上完全是两种负载。从六个层次拆最大内容绘制的实际路径里，这类由内容量驱动的差异经常比代码差异更大，也更难在模板层解决——你没法要求运营少写点评论。

成因相同这个判断，比分组本身更值钱

回到那句原文。它说的其实是两件事：这批页面共用一套框架，以及它们的问题出自同一个底层成因。第一件是观察，第二件是推论，而第二件才是它敢把4万行压成12行的底气。

把这个推论借过来用在索引问题上同样成立。同一个模板下的8000个网址被判成重复内容，你不需要逐个去看这8000个——看两三个就够，因为它们重复的方式必然一样。

这就是模板口径最实用的一层价值：它把逐条核查变成了抽样核查，而抽样的合理性不是靠统计学保证的，是靠代码结构保证的。统计抽样要考虑分布和置信区间，模板抽样不用——同一段代码的输出，看一遍和看一万遍是一回事。

跟随机抽样的区别在哪

这个区别值得讲清楚，因为很多人做审计时的抽样是随机的，抓一把网址看看。随机抽样在页面同质度高的时候有效，问题是你事先不知道同质度高不高。

举个具体的数：一个站有55个模板，其中3个模板出了问题，涉及网址占全站4%。随机抽20个网址，一个都不落在这4%上的概率超过四成。也就是说随机抽20条，有四成的机会得出一切正常的结论。

按模板抽，每个模板取1条，20条能覆盖20个模板，55个模板取满也只要55条。同样的成本，前者可能什么都查不到，后者一定能覆盖你抽到的每一类页面。

抽样这件事，别的领域早就想明白了

做搜索排名监控的人对这套逻辑不陌生。排名追踪的样本量、频率与设备该怎么设计里最核心的一条就是：样本不是越多越好，关键在于样本能不能覆盖所有需要区分的类别。追1000个词但全是同一类意图，不如追200个词覆盖五类意图。

页面审计是同样的道理，只是大家一直没有把类别这个概念显式地建立起来。关键词有意图分类，页面的分类就是模板，只不过前者是SEO自己划的，后者写在别人的代码里，得去问一句才知道。

说到底，抽样设计的第一步永远是先定义总体的结构，第二步才是决定抽多少。跳过第一步直接抓一把，抓多少都是碰运气。

那些没有数据的模板怎么办

核心指标报告只显示有足够数据的组，你的站上大概率有一批模板从来没在报告里出现过——冷门分类页、老活动页、只有几十次访问的帮助文档。

它们不出现不是因为没问题，是因为访问量不够门槛。而访问量低这件事跟质量差没有任何关系，甚至可能是因为质量差才访问量低。这个因果方向报告本身分辨不了。

处理办法很朴素：把模板清单跟报告里出现过的组对一遍，没出现过的那些单独列一张表，用人工或者页面速度测试逐个跑一次。这批模板通常占清单的三到五成，一次跑完能花掉大半天，但一年跑一次就够了。

组的代表网址，能不能直接拿来当模板代表

能，而且这是个被严重低估的便利。你需要一份模板代表网址清单——每个模板配一条典型网址，以后所有验收、所有速度测试、所有改版回归都用它。这份清单自己整理要花时间，而核心指标报告已经替你选好了一批。

它选的依据是曝光量，选出来的通常是这个模板下最热的那个页面。这个选法有利有弊：好处是这条网址的数据最充分，测什么都测得出来；坏处是它经常是个特例，热门商品往往图更多、评论更多、加了额外的推广模块。

保哥的做法是每个模板存两条：一条热门代表，一条冷门代表。两条一起测，差值本身就是一个诊断信号——差得很小说明这个模板的表现由代码决定，差得很大说明由数据决定，后者的优化路径完全不同。

组给的那个数是分位值，不是均值

这一点文档里写得很直白：报告里的组指标，说的是这个组内75%的访问达到了这个水平或更好。它不是平均数，也不是中位数。

分位值的性质决定了它对尾部不敏感。一个组里有20%的页面表现极差，只要不到25%，分位值可以完全不动。报告上那根绿条不会因为五分之一的页面很糟就变黄，它只在超过四分之一变糟时才动。

这不是设计缺陷，选75分位本来就是为了排除偶发的极端值。但读的人得知道自己在读什么：绿色说明大多数访问是好的，不说明没有一批访问是坏的。要看尾部，得换个工具单独测。

没有这份外部校验的时候怎么办

不是所有站都能拿到足够的现场数据。新站、小语种站、流量集中在少数几个页面上的站，核心指标报告里可能只有一个整站层级的组，分不出任何结构。

这种情况下的替代方案是拿日志代替。服务器日志分析抓取预算与验证爬虫那套流程里，日志本来就带着完整的路径信息，按路径规则归类之后能得到一份完全属于你自己的分组表，而且它覆盖全部网址，不受访问量门槛限制。

日志给不了体验指标，但它能告诉你每一类页面被抓了多少次、返回了什么状态码、响应耗时多少。做模板级诊断，这三样已经够用了；至于用户那一侧的感受，等有了流量再补。

组的数量本身就是一个信号

还有一个不用打开任何一行数据就能读的信息：核心指标报告分出了几个组。这个数跟你自己数出来的模板数一比，能看出站的结构状态。

组数明显少于模板数是常态，因为一多半模板没有足够数据。但如果组数只有个位数，而你的站有几万个网址、流量也不小，那多半说明大部分页面的表现太接近了——接近到Google分不出结构，或者说明数据主要来自少数几个页面。

反过来，组数比模板数还多也值得看一眼。这说明同一批页面在真实用户那里的表现分化得厉害，而分化的原因不在代码里，多半是缓存命中率、图片大小、第三方脚本加载时机这几件事在不同页面上差别太大。这类问题按模板改是改不动的，得往基础设施那一层去查。

现场数据只有整站和单页两级，中间那一层去哪了？

Chrome用户体验报告只聚合两个层次

核心指标那些数字最终都来自Chrome用户体验报告，也就是常说的现场数据。它的方法学文档把口径写得很清楚：符合条件的用户体验被聚合成页面级和源级两种分布。

页面级就是单个网址，源级就是整个站点。中间没有别的层次——没有目录级，没有页面类型级，也没有模板级。你要么看一个网址，要么看一整个站。

这个设计本身没毛病，采集端只知道用户访问了哪个网址，不知道这个网址出自哪个模板。模板这个概念只存在于你的代码库里，浏览器看不见。

那句最容易被忽略的门槛说明

要进入这个数据集，页面和站点都得同时满足两个条件：能被公开发现，以及足够热门。第一个条件好理解，第二个条件的具体数字官方不公开，只说选这个数是为了保证统计分布可信。

关键在紧接着的那一句：页面和源用的是同一个最低访问人数门槛。不是页面用一个低一点的门槛、站点用一个高一点的，是同一个数。

把这句话展开就有意思了。一个网址要拥有自己的现场数据，它自己的访问人数得达到一整个网站被收录的标准。一个商品页得混成一家网站那么大，才配拥有一行属于自己的数据。

这道门槛在电商站上意味着什么

电商站的流量分布是典型的长尾形状。头部几十个页面吃掉大部分流量，剩下几万个商品页各自分到很少的访问。真正能过门槛的，通常是首页、几个大类目页、少数几个爆款商品页。

算一笔粗账：一个月访问量30万的站，假设头部50个页面占60%的流量，平均每个3600次；剩下12万次分给2万个长尾页面，平均每个6次。前者可能过得了门槛，后者差着三个数量级。

结果就是你能拿到的现场数据只有两种：整站一个数，加上几十个头部页面各一个数。而你最想知道的那件事——商品页模板整体表现如何——恰好落在这两者中间，没有任何官方数据源直接回答它。

整站那个数为什么不能替代

因为它被头部页面主导了。源级数据聚合的是这个站所有符合条件的用户体验，而流量是加权的，头部页面贡献的样本量压倒性地多。

首页通常是全站优化得最好的一个页面——图片压过、脚本裁过、缓存命中率最高、上线前测过三遍。它的表现进入整站均值之后，会把长尾页面的问题稀释掉。

更麻烦的是方向：你越用心优化首页，整站那个数就越好看，也就越掩盖商品页模板上的问题。投入和数据表现之间存在一个正反馈，但它反馈的不是真实体验的改善。

头部页面那几个数为什么也不能替代

因为能过门槛的页面按定义就是不典型的。它们流量大，往往意味着缓存一直是热的，图片一直在边缘节点上，数据库查询命中率高。

一个长尾商品页的第一次访问要走完全不同的路径：缓存未命中、回源、可能还要触发一次图片实时处理。页面速度影响SEO的那几条路径里，冷启动和热路径的差距在电商站上经常是两三倍，而现场数据里只有热路径那一侧有样本。

这就是那个尴尬的处境：有数据的页面不需要你操心，需要你操心的页面没有数据。两者之间的分界线不是质量，是流量。

门槛这件事还有个反直觉的后果

访问量门槛带来的偏差不只是覆盖不全，它还会让优化动作的反馈变形。你花两周把长尾商品页的图片处理管线改好了，现场数据里看不到任何变化，因为那些页面本来就不在数据集里。

整站那个数倒是可能微微动一下，但幅度小到分不清是不是噪声。于是一次真实有效的改进，在唯一被拿来汇报的那个指标上几乎没有痕迹。做过几次之后，团队自然会把精力转向那些能在报表上看出效果的页面——也就是头部页面，而它们本来就已经是全站最好的部分了。

这条反馈回路挺阴险，它不需要任何人做错决定，光靠指标的可见性就能持续地把资源往已经不缺资源的地方推。要打断它，只能在头部页面之外另立一套衡量方式，而这套方式目前只能自己搭。

参数被剥离，两个商品可能被算成一个页面

方法学文档里还有一条处理规则值得单独拎出来：网址上的查询参数和锚点会被剥掉，同一个页面的所有访问因此被合并到一起。这条规则的用意是好的，避免同一个页面因为带了各种跟踪参数而被拆成一堆各自过不了门槛的碎片。

但文档自己加了一句提醒：在少数情况下这会把不同的页面意外地合并在一起，比如两个参数代表的是两个不同商品的时候。官方给的例子就是商品编号参数。

老一点的电商系统里，商品页网址用参数区分商品的做法并不罕见，Magento的部分配置、一些自研系统、还有相当多的B2B站都是这样。这类站在现场数据里会呈现出一个奇怪的形态：网址结构与命名的那几个设计维度没做好的代价，在这里以一种很隐蔽的方式体现出来——几万个商品被算成了一个页面，这个页面数据充足、指标漂亮，代表的却是几万个页面的混合体。

还有一条20%的剔除规则

文档里另一条筛选规则是：某个网址或站点，如果超过20%的流量因为维度组合不合格而被排除，那么它会被整个剔出数据集。

这条规则的存在提醒了一件事：现场数据不只是有没有的问题，还有全不全的问题。一个站可能因为访客集中在某些小众设备、小众地区、小众浏览器版本上，导致相当一部分体验根本没被计入。

做小语种市场、做新兴市场的站尤其要留意这一条。跨源资源上那批被抹成零的性能字段是同一类麻烦的另一个版本：报表上那个数是真的，但它代表的范围比你以为的窄。

页面速度工具给的又是另一种口径

核心指标报告的文档里顺带说了一句差异：核心指标报告把数据和状态合并进网址组，而页面速度工具通常显示单个网址的数据，除非这个网址自己的数据不够。所以同一个网址在两个地方看到的数字对不上是正常的，因为一个是组的分位值，一个是这个网址自己的。

把这张表读成一条建议

看完这五行，模板级诊断的路线其实已经清楚了：现场数据用来定位哪一类页面值得查，实验室工具用来查具体查什么，日志用来兜住那些前两者都覆盖不到的模板。三样东西各干各的，谁也替代不了谁。

常见的错误是只用其中一样。只看现场数据的人会以为没数据的地方就没问题；只跑实验室测试的人会对着一个自己挑的网址反复优化，而那个网址可能不代表任何东西；只看日志的人拿不到用户侧的感受。

把三样串起来的成本并不高，难的是想清楚每一样负责回答哪个问题。这跟收录、排名、流量分三层做诊断的思路是一致的：先分层，再选工具，别拿一个工具去回答它答不了的问题。

能不能自己采一份，把中间那层补上

能，而且这是唯一一条真正能拿到模板级现场数据的路。浏览器有现成的接口可以在真实用户那边采集这几个指标，采到之后跟着一起上报的可以是任意维度——包括模板名。

关键就在这个附带维度上。官方数据集里没有模板这一层，是因为采集端不知道；换成你自己采，模板名是你渲染页面时就知道的东西，往上报里塞一个字段的事。同一份指标，多带一个字段，中间那一层就补上了。

实现上不复杂，主流分析工具都支持自定义维度，愿意自己攒的话把数据落到数据仓库里更灵活。把分析数据接进数据仓库做用户旅程分析那套管线搭起来之后，加这一个字段几乎是顺手的事，成本主要在头一次搭。

自采数据也有它的门槛，只是换了个形式

别以为自采就没有样本量问题。一个模板下如果一个月只有几十次访问，你自己采到的分位值同样不可信，跟官方数据集面临的是同一个统计学难题。

区别在于你可以自己决定门槛，也可以自己决定聚合到哪一层。官方给你两个固定层次，自采的话想按模板聚合就按模板聚合，想按模板加国家聚合也行，样本不够就往上合并一层，这个决定权在你手里。

另一个区别是时间窗。官方数据用的是滚动28天窗口，你自己采的可以看昨天，也可以看上线前后各两小时。做改版验收的时候，这个差别是决定性的——等28天窗口更新完，出问题的版本早就跑了一个月了。

新站和小站怎么办

流量还没起来的站，官方数据集里可能连整站那一行都没有。这时候纠结现场数据没有意义，直接走实验室路线：按模板清单逐条跑页面速度测试，一次跑完全部模板，得到一份纯实验室口径的基线。

实验室数据的毛病是它测的是一台模拟设备在一条模拟网络上的表现，跟真实用户的分布对不上。但在没有现场数据的阶段，它至少能回答模板之间的相对好坏——商品页比列表页慢一倍这件事，实验室数据也测得出来。

等流量起来之后，前面那份实验室基线还有一个额外用处：拿它跟新拿到的现场数据对一遍，差异大的模板说明真实用户的处境跟模拟环境差很多，多半是网络条件或者设备性能的问题，而不是代码的问题。

桌面和移动要不要分开数模板

这个问题的答案取决于实现方式，判据还是那一句：改一处会影响哪一批页面。响应式的站改一个模板文件，桌面和移动一起变，那就是一个模板；独立移动站改的是另一套代码，那就是两个。

现场数据这边倒是永远分开的——核心指标报告按终端拆成移动和桌面两份，同一个网址组在两边可能是完全不同的状态。这一点跟模板数怎么数无关，是数据本身的组织方式。

所以对响应式的站会出现一个有点绕的局面：一个模板，两份数据。处理办法是把终端当成分支看待，跟缺货、预售那些分支同等对待——同一个模板在移动端上的表现差，那就是移动端这条分支上的问题，改的时候多半只需要动样式而不用动结构。

国际方法学怎么定样本量，页面数多和模板数多哪个说了算？

有一份标准专门规定了这件事怎么做

这个问题不用自己拍脑袋，W3C有一份网站无障碍一致性评估方法，专门规定评估一个网站时该怎么选样本、选多少、怎么验证选得对不对。它面向的是无障碍评估，但抽样这一节的逻辑跟技术SEO审计几乎完全通用。

这份文件的价值在于它把很多人凭经验做的事写成了明文步骤，而且写得相当细：先定评估范围，再探索产品结构，再选样本，再评估，最后出报告。抽样这一步排在第三，前面两步全是为它做准备的。

做过审计的人看到这个顺序会有点意外——大多数人的实际流程是打开工具就开始爬，爬完再想怎么归类。标准把探索结构放在抽样之前，等于说你得先知道这个站有几种页面，才谈得上抽多少条。

标准怎么定义要区分的那几类

探索这一步里有一小节叫识别样本类型的多样性，正文第一句是这么说的：样式、布局、结构和功能各不相同的样本，往往在无障碍支持上表现不同；它们通常由不同的模板和脚本生成，或者由不同的人撰写。

这句话把模板两个字明明白白写进了国际标准。标准不认为页面类型是个玄学概念，它直接指出了物理成因——不同的模板，不同的脚本，不同的作者。

这跟本文一路在说的是同一件事，只不过标准是从评估方的角度说的：你要抽样，就得先按生成方式把页面分类，因为同一个生成方式产出的东西，看一个和看一百个没区别。这句话2014年就写在那儿了，现在读起来一点不过时。

标准列了一串影响样本量的因素

决定抽多少条的时候，这份文件列了一长串要考虑的因素，其中有两条摆在一起特别有意思。

第一条是产品规模：页面或视图更多的产品，通常需要更大的样本集。第二条藏在一致性那一组里：编码风格的多样性——文件里特意加了个括号解释，这些差异通常来自生成代码的不同脚本、模板和页面作者——多样性越大，需要的样本集越大。

两条因素打架的时候听谁的

问题来了：一个有20万个页面但只有50个模板的站，按第一条要大样本，按后面几条要小样本，标准没有给出这两条谁优先。

但它在下一步里其实回答了。选结构化样本那一节的注记写着：精心挑选这些有代表性的实例，能显著减少所需的样本集规模，同时仍然保持对整个产品的适当代表性。

这句话等于承认了页面数这个因素在模板化产品上基本失效。20万个页面里，只要你选得准，几十条就够代表全部；选不准，抽两千条也照样漏。决定样本量的从来不是总量，是类型数。

这也解释了为什么产品规模那一条要排在最前面——它是最容易观察的因素，适合排在前面提醒评估者别掉以轻心。但真正干活的是后面那几条。

标准还配了一个防自欺的装置

光按类型选样本有个隐患：万一你对类型的划分本身就是错的呢？标准考虑到了这一点，在结构化样本之外要求再抽一组随机样本，数量是结构化样本的10%。结构化样本80条，就再随机抽8条，加起来88条。

这8条不承担评估任务，它们的作用是当指示器：把随机组的评估结果跟结构化组比一遍，如果随机组里出现了结构化组没有的内容类型，或者冒出了结构化组没有的问题，说明你的类型划分不够全，得回去补，然后重来一遍。

这个设计的性价比高得惊人。多花10%的成本，换一个能告诉你前面90%白做了没有的检验。而且它检验的不是被测对象，是你自己的判断——你以为站上有50种页面，随机抽8条撞上一种你没列过的，那50这个数就有问题。

把这条搬到技术SEO审计上

搬过来几乎不用改。按模板清单每类抽1到2条，得到结构化样本；再从全站网址里完全随机抽10%数量的网址，看看这批随机网址能不能都归进你已有的模板标签里。

归不进去的那几条最值钱。它可能是一个你完全不知道存在的页面类型——某次活动留下的落地页、某个插件自动生成的归档页、某个测试环境泄漏出来的地址。预发布环境被收录之后的排查与回收里那种情况，靠模板清单是永远发现不了的，因为它压根不在你的清单里。

保哥做过几次这个检验，随机组撞出新类型的概率大概三分之一。三次里有一次会发现自己漏了一整类页面，这个命中率足够高，高到值得每次都做。

逐条查网址要花多久，算一下就知道该不该做

说了半天抽样，还是得回答那个最朴素的问题：不抽样、逐条查全部网址，行不行。

Google官方文档里写着网址检查接口的配额：每个站点每天2000次，每分钟600次。这是硬上限，加钱也没用。

一个20万网址的站，全量跑一遍要100天。一个5万网址的站要25天。就算是2万网址的小站，也要10天。而这三个数字都超过了大多数电商站的发版间隔。

跑完那天的结果，还算数吗

不算数了，这才是这笔账真正的结论。

100天里，站上会上新几批商品、下架几批商品、改一到两次模板、上线几个插件、调一次导航。等你扫到第19万条的时候，第1条的状态早就变了。你拿到的不是一张快照，是一段横跨三个月的曝光——就像用一台快门开了三个月的相机拍一个每天都在装修的房子，成片上什么都有，就是没有任何一个时刻是真的。

这条推论可以写成一句通用的话：当一次全量扫描的周期长于被扫描对象的变化周期，你永远得不到一份内部一致的快照，扫描的完整性反而变成了不一致性的来源。这跟工具好不好、预算够不够都没关系，是两个周期的比值决定的。

按模板抽样为什么能绕开这个问题？因为它需要的调用次数少两三个数量级。50个模板，每个取3条代表，150次调用，配额允许的情况下几分钟跑完，加上人工判读半天收工。半天之内站不会变，快照是一致的。

那全量扫描是不是就没用了

有用，但它该由爬虫来做，不该由逐条调接口来做。爬虫的速率取决于你自己的服务器和目标站的承受力，跑几万页通常是几小时的事，跟接口配额完全是两个量级。

分工可以定得很清楚：爬虫负责全量、负责发现你不知道的东西；接口和人工负责抽样、负责判断这一类页面该不该是这样。前者回答有没有，后者回答对不对。

把两者混着用最浪费。拿接口去做全量是拿最贵的工具干最粗的活；拿爬虫去做判断则是另一个极端，爬虫能告诉你这个页面缺了描述标签，告诉不了你这个页面的描述该写什么。

那到底该抽多少条

标准没给死数，因为它取决于前面那一堆因素。但按它的框架推一遍，能得到一个挺实用的区间。

先数模板，假设50个。每个模板至少1条，这是底线；有明显分支的模板（缺货、预售、多变体、无图）每条分支再加1条，实践中大约三分之一的模板有分支，加起来大概70条。再按标准要求补10%的随机样本，7条。总计77条。

77条这个量级，一个人一天能过完，接口配额零压力，爬虫抓取更是眨眼的事。跟20万条要跑100天相比，成本差了两千多倍，而覆盖的判断点几乎一样多。

这跟统计意义上的样本量是两码事

得防一个误解。看到抽样两个字，做过实验的人容易往统计功效那边想——要多少样本才能检出多大的效应，置信度多少。对比实验的样本量该怎么算那一套公式在这里完全用不上。

原因在于两种抽样回答的问题不同。实验抽样要估计一个总体参数，样本越大估计越准，误差随样本量的平方根缩小。模板抽样不估计任何参数，它做的是穷举而不是估计——把50种情况一种看一遍，看完就是看完了，没有误差这一说。

说得再直白点：同一段代码渲染出来的两个页面，其结构性的对错是完全一致的。看第二个页面得到的信息量是零，不是很小，是零。这跟做用户调研完全不同，多问一个人总能多知道一点，多看一个同模板页面什么都不会多知道。

唯一需要注意的例外

上面那句话有个前提：结构性的对错。数据驱动的差异不在此列，同模板不同数据的页面，该看还得看。

怎么区分？有个简单判据——这个问题的答案取决于代码还是取决于数据库里的某一行。缺规范标签是代码问题，看一条就够；标题超长是数据问题，得全量扫。前者按模板抽样，后者交给爬虫做全量规则校验。

大多数技术SEO问题落在代码这一侧，这也是为什么模板抽样对技术SEO特别有效。到了内容质量那一侧比例就反过来了，重复内容那类毛病既可能出在模板（同一段描述被所有页面复用），也可能出在数据（供应商给的文案本来就重复），两边都得查。

标准对报告的要求，也值得抄一段

这份文件最后一步是出报告，要求把前面每一步的结论都记录下来——评估范围怎么定的、探索出了哪些页面类型、样本怎么选的、各选了哪几条。理由写得很实在：为了透明、为了结果可复现、也为了给报告里的每一句话找到依据。

技术SEO审计报告里最缺的恰好就是这几项。大部分报告直接从发现问题开始写，不交代查了哪些页面、为什么是这些页面、有没有漏掉哪一类。读的人没法判断这份报告的覆盖范围，也就没法判断没提到的东西是没问题还是没查。

补上这一段的成本极低——一张表，左边模板名，右边代表网址，加一句本次未覆盖哪几类及原因。写这一段花不了十分钟，但它把一份报告从结论清单变成了可追溯的材料，下一次审计还能拿来对照。

上线前抽查的8个网址全是绿的，为什么用户看到的日期还是错的？

先交代这个站

去年接触过一个做跨境户外电源和便携储能的独立站，卖露营电源、太阳能折叠板、扩展电池包这些东西，主打北美和欧洲，客单价300到1500美元，团队二十来人，有自己的前端和后端。这个品类的特点是单价高、决策周期长、参数党多，用户会把三四个型号的参数表并排开着比。

它的商品结构比一般站复杂：一个型号会按插头制式分出美标、欧标、英标、澳标四个版本，再按容量分两三档，一个型号能生出十来个可售组合。全站算上分类页、内容页和参数页，被收录的网址一万八千多个。

模板数保哥后来陪他们数过，41个。一万八千多除以41，平均每个模板背后450个页面。

那次改版改了什么

问题出在一次商品页改版上。这次改版的主要目的是把送达日期从原来的一句模糊说法改成具体日期区间，用户在商品页上就能看到大概哪天到，这是这个品类里挺关键的一个信息——买露营装备的人经常是冲着某个具体的出行日期下单的。

新逻辑要根据仓库位置、承运商时效和商品属性算出一个区间。其中带锂电池的商品要走特殊渠道，处理时间比普通货多5到7天，这一条在需求文档里写了，代码里也确实写了一个分支。

问题是那个分支的判断条件写反了：本该给带电池的商品加处理时间，实际加到了不带电池的商品上。于是所有带电池的商品页——占全站商品页九成——都显示了一个偏早5到7天的日期。

上线前的验收是怎么过的

这家的流程算规范的，改版有回归测试，测试规范写着每次改动抽查不少于5个网址。这次抽了8个，比规范要求的还多3个。

8个网址逐个打开，日期都显示出来了，格式对、区间合理、跟后台配置的时效对得上。全绿，通过，上线。

问题出在这8个网址是怎么选出来的。测试同学从后台导出商品列表，按商品编号排序，取了前8个。而这个站的商品编号是按上架顺序生成的，最早上架的一批是配件——线材、支架、收纳包、车充转接头，全部不带电池。

8个网址，全落在同一条分支上

这就是那次事故的全部技术原因。8个样本，覆盖了1个模板的1条分支。而这次改动动的是这个模板的分支判断，恰好是这8个样本一条都没走到的那一半。

更准确地说：这次改动引入的两条路径里，被验证的那条是正确的（不带电池，不加时间，显示正常），出错的那条一次都没被打开过。

验收报告上写的是：本次回归抽样8条，覆盖率8/18000，符合抽样规范要求。这句话每一个字都是真的，规范也确实是这么写的。

如果规范换个写法，要抽几条

这是保哥后来跟他们复盘时算的一笔账，也是这个案子里最扎心的地方。

把规范从每次改动抽查不少于5个网址，改成每条被改动的模板分支至少覆盖1条网址，这次要抽几条？2条。带电池的一条，不带电池的一条。

2条比8条少了四分之三，在任何一份按条数算的规范里都更不合规。但2条能发现问题，8条发现不了。

这张表能读出一句挺重的话：当抽样规范用错了单位，合规性和有效性会指向相反的方向。抽得越多越显得认真，也越容易在同一条分支上打转；而真正有效的那个做法，在按条数计的规范里看起来像是在偷懒。

这个错误在报表上是什么形态

上线之后三个月，没有任何一个数字报警。这才是这个案子真正值得写下来的部分。

页面索引报告全绿，一万八千个网址收录正常——模板没坏，页面返回200，结构化数据校验通过，日期字段有值而且格式合法，只是算错了。核心指标报告也全绿，改版没影响性能。结构化数据的抽取与校验那类检查同样过不了这一关，因为它校验的是格式而不是数值对不对。

客服工单里有反馈，但被归进了物流类。用户说的是东西比说好的晚到了几天，客服查履约系统，发现清关和运输节点都正常，就按物流延迟处理，该道歉道歉，该补偿补偿。三个月里这类工单一共两百多条，分散在每天两三条，没有任何一天出现过尖峰。

为什么没有人把它们连起来

因为物流慢是一个本来就存在、而且一直有量的工单类目。跨境电商的物流永远有一部分订单会晚，这是常态。这次多出来的两百多条混进去，只是让这个类目的基数比往常大了一点。

保哥后来把这一层写成了一句通用的话：当一个错误的表现形式恰好落进一个本来就存在的正常类目里，它不产生任何异常值，只是让那个类目的基数变大一点；而基数变大一点这件事，在任何一份月度报表上都读作正常波动。

这跟那种会报错、会跳红的问题完全是两种难度。会报错的问题只要有人看报表就会被发现；这种问题你把报表看穿了也发现不了，因为它在报表上的形态是正常的。

最后是怎么发现的

一个德国客户投诉的时候截了图。他买的是一台带电池的电源，商品页上写的日期是8月12日到8月16日，实际8月21日才到，他把商品页的截图和物流轨迹的截图一起发了过来，问这个日期是怎么算出来的。

客服转给了产品经理。产品经理把那台机器的履约时效在后台调出来，跟截图上的日期一比，差了6天。再点开一个不带电池的配件页，日期是对的。两分钟之内定位到了那个写反的判断。

触发这次发现的动作，本质上是把用户看到的那一页和内部系统里的数并排放了一次。这个动作在此之前三个月里没有任何一个人做过——不是没人负责，是这件事不在任何一个岗位的日常动作里：客服看履约系统，产品看需求文档，测试看验收用例，研发看代码，运营看订单列表，五个人看的是五份不同的材料，没有一份是用户屏幕上那一页。

改完之后他们做了什么

修那个判断花了十分钟。真正有价值的是后面那件事：他们把回归测试清单从网址列表改成了模板分支清单。

原来的清单是一份60条网址的表格，谁也说不清这60条是怎么来的，大概是历次上线随手加进去的。新清单是一份31行的表，每行一个模板分支，配一条代表网址——41个模板里有分支的那些拆开算，一共31条需要单独覆盖的路径。

行数从60掉到31，少了将近一半，而覆盖的形态从说不清变成了明确的31种。第一次按新清单跑，就在另外两条分支上撞出了两个存量问题：礼品卡商品页显示了一个并不存在的运费估算（礼品卡是虚拟发货，不该有运费模块），预售商品页把预售开始日期渲染成了到货日期。这两个问题都不知道存在了多久。

业务上的账怎么算

直接损失能算的部分不多：两百多条工单的处理成本，几十单的补偿，一些差评。这些加起来对一个二十人团队来说不算伤筋动骨。

算不出来的是另一部分。这个品类的用户是冲着具体出行日期买的，日期错了6天，对一部分人来说就是这次露营用不上了。这些人里有多少退了货、有多少没退货但再也不来了，报表上看不出来——没回来的人在任何数据里都是一个空格，不是一个数字。

更微妙的是复购率。这个站的复购率在那三个月里掉了不到两个百分点，落在正常波动范围内，当时没人在意。事后回看，那个数很可能就是账单，只是它长得跟噪声一模一样。

组织上的教训比技术上的大

技术上的教训一句话就够：抽样规范要按分支写，不要按条数写。组织上的教训要绕一点。

这次事故里，每一个岗位都在正确履职。测试按规范抽了8条还超额了，客服按流程归了类，运营按后台数据回复了用户，研发没收到任何bug报告。整条链上没有一个人做错事，错的是链条的组织方式——所有人的工作单位都是网址、订单、工单，没有一个人的工作单位是模板。

所以解法也不能是要求大家更认真。更认真的测试同学会抽20条而不是8条，仍然可能全落在同一条分支上。履约模式的选择再讲究，也管不到商品页上那个日期是怎么算的。真正管用的只有一件事：把单位换掉，让清单本身逼着人去覆盖每一条分支。

为什么抽更多条不是解法

复盘会上有人提议把规范从5条改成50条，觉得基数大了总能撞上。这个提议听着合理，算一下就知道不行。

这个站商品页里带电池的占九成，不带电池的占一成。按商品编号排序取前50条，因为编号是按上架顺序生成的，前面那一批全是早期上架的配件——排序方式没变，取50条跟取8条落在同一片区域，一条带电池的都碰不到。

就算改成随机取50条，带电池的占九成，随机抽到的绝大多数反而是带电池的，这次能撞上。但下一次改动如果落在某个只占1%的分支上，随机50条漏掉它的概率超过六成。靠概率去覆盖分支，永远是在赌这次改的那条路够不够常见。

这个坑换个场景还会出现

同样的形状保哥在别的地方也见过几次，列出来方便对号入座。

一种是多站点多区域的电商系统。多店铺架构下网站、商店与视图的层级关系把同一套代码铺到几个区域，验收时习惯只在主站上测，某个区域独有的税费展示或者合规提示出问题，要等当地用户投诉才知道。这里的分支单位是模板乘以区域。

另一种是库存状态。有货、缺货、预售、限购、仅剩几件，同一个商品页模板要渲染五六种状态，而验收时打开的商品几乎总是有货状态——因为测试环境里的商品默认都有库存。多仓库存与预留机制越复杂，能走到的状态分支越多，被覆盖到的比例反而越低。

还有一种是登录态。同一个页面对游客、新客、老客、会员等级不同的用户显示不同的价格和不同的模块，而做验收的人永远是登录着的那一个。这一类分支的共同特点是：默认状态最容易到达，于是它被测了一百遍，其余状态一遍都没有。

新清单该由谁维护

换成模板分支清单之后，最现实的问题是这份表会不会半年之后过期。会的，只要没人管它。

那个站后来的做法是把它挂在发布流程上：上线检查清单里加了一行必填——本次改动触碰了哪几个模板分支，填名字，不填网址。不设下拉选项，不做校验，判定规则只有填了和没填两种。

这个设计的用意是让它活得下去。凡是需要执行者具备判断力才能填对的字段，最后都会变成空的或者随便填的；只要求填个名字的字段才可能长期被填。填错了也没关系，下次改动同一处的人会发现名字不对然后改掉。

三个月后那一栏变成了什么

最值钱的东西是这个字段的副产品。三个月之后，把这一栏的值统计一遍，得到的是一张模板改动热力图：哪个模板每个月被碰五次，哪个模板一年没人动过。

被碰得最勤的那几个，说明业务压力集中在那儿，值得单独做一次结构梳理；一年没人动过的那几个，才是真正该警惕的——没人动过不代表没问题，只代表没有人在它上面工作过，也就没有人有机会发现它的问题。那两个撞出来的存量问题（礼品卡运费、预售日期）就落在这一档里。

这张图不用专门去做，它是填字段的副产品，成本为零，而且会持续更新。相比之下，专门组织一次全站盘点得排期、得占人、还只能得到一个时间点上的快照。

不买工具、不加埋点，这周怎么把模板清单数出来？

先说这几件事的共同前提

下面六件事保哥都实际带人做过，共同点是都不需要新增预算、不需要开发排期、不需要在页面上加任何埋点。用的全是你已经有的东西：Search Console里的报表、代码库、上线流程文档。

另一个共同点是它们都不产生一个可以拿去汇报的分数。这一点得提前说明白，因为很多改进动作之所以推得动，靠的是能产出一个数字给领导看。这几件事产出的是清单和比值，不是排名。

最后一个前提：这几件事做完不会让流量涨。它们改变的是发现问题的效率，不是问题本身。把发现成本从一周降到半天，收益体现在后面每一次改动上，不体现在这一次。

第一件：给每个模板分支存一条代表网址

这件事排第一，跟大多数人的直觉不一样。直觉会觉得应该先数模板，数完才谈得上存代表。但实际做下来，数模板和存代表基本是同一个动作，而后者的产出是永久的。

做法：开一张表，两列，左边模板分支名（商品页有货、商品页缺货、商品页预售、列表页有筛选、列表页零结果、结账第二步……），右边一条代表网址。名字随便起，能让团队里另一个人看懂就行。

这张表做完之后，所有需要挑页面的场合都用它：跑速度测试用它，做改版验收用它，请人做人工走查用它，交给外部顾问做审计也是先给这张表。它是这几件事里唯一一个做完之后每周都会被用到的产出。

第二件：数一次模板，判据只有一句

数的时候不要数文件，数渲染形态。判据是那句话：改这一处，会同时影响哪一批页面。凡是答案不同的，就是不同的形态。

三条捷径可以加快这一步。第一，打开导航把每一个链接点一遍，能覆盖大约七成形态；第二，翻网址结构，路径的每一段前缀通常对应一类页面；第三，问一句研发有没有现成的路由表，很多站是有的，只是从来没人问过。

数出来的结果多半在35到70之间。数完之后跟企业站审计框架里那几个模块对一遍，看有没有整块的界面从来没被想起来过——过滤器面板、空状态页、错误页、打印样式这几类是高发区。

第三件：算一次错位比

把页面索引报告导出，数一下行数；再拿第二件事数出来的模板数。两个数相除。

这个比值本身不做任何决策，它的用途是说服。在会议上说我们的报表比施工单位细了400倍，比说我们应该按模板做审计有用得多，因为前者是一个数，后者是一个观点。

顺手还能算第二个比值：报表行数除以问题类型数。这个数告诉你平均一个问题类型被拆成了多少行。两个比值一起放，一份看起来有几千件事要做的报表，会露出它真实的形状——十几个问题，落在几个模板上。

第四件：把核心指标报告的组名单抄下来对一遍

这件事前面详细说过原理，操作上就是点开报告里每一个问题，把代表网址记下来，看它们分别落进你自己模板清单的哪一格。

找两种不一致：一个组的代表网址跨了你的两个模板标签，或者两个组的代表网址落进你的同一个标签。前者说明你分细了或者Google认为它们同质，后者说明你分粗了或者这个模板里有条你不知道的岔路。

整理出来通常是一份十几行的差异清单。这份清单的价值在于它是唯一一份由外部视角产生的、关于你站结构的评估，而且完全免费。

第五件：把回归清单的单位换掉

找到团队现在用的那份上线验收清单，看它是怎么写抽样要求的。如果写的是抽查不少于多少个页面，就把它改成每条被改动的模板分支至少覆盖一条。

改这一行字的成本是零，效果在前面那个案子里已经很清楚了。要注意的是条数往往会变少，得提前跟负责验收的人说清楚这不是放松要求，否则第一次执行就会有人觉得是在偷工减料。

配套要做的是把第一件事产出的那张代表网址表挂在清单旁边，让执行的人不用自己去想该测哪条。清单说要覆盖商品页缺货分支，表里就有一条现成的缺货商品网址，点开就能测。

第六件：数分支，不是数模板

这是六件里唯一需要研发配合的，但只要半小时。让研发在模板文件里搜一遍条件判断，把那些会显著改变页面结构的分支列出来——不是所有if都算，只算那些会让页面上多出或少掉一整个模块的。

数出来的分支数通常是模板数的两到四倍。41个模板对应31条需要单独覆盖的关键分支（不是每个模板都有分支），这个比例在实践里挺典型。

分支清单比模板清单更接近真实的检查面。前端渲染方式带来的差异在这里尤其明显：同一个模板在服务端渲染和客户端渲染两条路径下产出的东西可能完全不同，那其实是两条分支，得分开测。

这六件该按什么顺序做

保哥排优先级一直用两个维度相乘：拿到成本，以及结论能不能直接变成动作。本文这一批的反直觉之处在于，成本最低的那件排在了中间。

数模板成本只有两小时，却排在第二而不是第一，原因是它的结论落不了地。数出41个模板之后，下一句话是然后呢；而存好代表网址表之后，下一句话是这周的速度测试就用它。能直接接上一个具体动作的产出，永远比一个更准确但悬着的数字有用。

四条边界，别把它用过头

第一条，模板数不是一个精确的数。组件化之后边界本来就模糊，两个人数可能差三五个。这不影响使用，因为它的用途是指导抽样而不是核算，差几个不改变任何结论。

第二条，按模板抽样查不出数据驱动的问题。某个商品的图挂了、某条描述被截断了、某个价格是0，这些只能靠全量扫描。两条路都得走，别指望一个替代另一个。

第三条，模板清单会过期。功能上线、旧页面下线、活动页堆积，半年不管它就是一张废纸。所以第五件事里那个必填字段才是关键——它让清单自己更新，而不是靠人定期盘点。

第四条，这套做法降低的是发现问题的成本，不降低修问题的成本。发现从一周变半天，修还是要修那么久。日常那份SEO动作清单该做还是要做，这件事不替代它们。

口径换了，报表上的数会先掉后涨

最后交代一件容易翻车的事。按模板口径重新整理之后，待办条目数会从几千掉到几十，掉两个数量级。这个数如果被当成成绩报上去，后面会很难收场。

因为按模板修完第一轮之后，剩下的确实是页面级的个案，它们归不到任何模板上，条目数会重新往上走。第二个月报表上的数比第一个月多，这是必然的，跟工作有没有做好没关系。

正确的做法是动手之前先说一句：这个数会先掉一大截再回升一点，掉的那部分是被合并的不是被修掉的，回升的那部分是本来就在但之前被埋在几千行里看不见的。这句话在动手前说是预告，等报表出来再说全像找补。

这跟做SEO数据向上汇报时那些口径变更的处理原则是一样的：口径变了必须先声明，因为读报表的人记住的是趋势线的形状，不是脚注里那行小字。

这件事该谁牵头

按经验，牵头的人得同时够得着报表和代码。SEO一个人做不完，他看得懂报表但摸不准模板边界；研发一个人做也不行，他清楚模板但分不出哪些报表条目是真问题。

最省事的组合是两个人坐在一起花一个下午，做完之后固化成脚本。后端工程师和SEO配合的那几个动作里说的分工原则在这里同样适用：一次性的判断由人做，重复性的执行交给脚本，别把两者混在一个人身上。

如果团队里连这两个角色都凑不齐——很多十人以下的跨境团队是这样——那就只做第一件和第三件。存一张代表网址表，改一行验收规范，这两件一个人半天能做完，而它们贡献了这套方法八成的价值。

三个大概率会遇到的反对意见

第一个：我们的站没那么复杂，用不着。这个判断得用数说话，先算错位比。低于50确实用不着，高于200就别争了。中间那一档看团队精力，做了不亏。

第二个：这不就是页面类型分类吗，我们早就分过了。分过和用起来是两回事。追问三句就知道分没分到位——这份分类表现在在哪儿、上一次更新是什么时候、上次做验收的时候用到它了吗。三句里有一句答不上来，那份分类就等于不存在。

第三个：Google是按网址排名的，你按模板做会漏东西。这个担心方向是对的但结论反了。按模板做不是不看网址，是先把网址按模板归好再看；电商站上哪些页面类型该拦在收录之外这类决策本来就是按类型做的，从来没人一条一条网址地决定要不要收录。

三十天里可以这么排

第一周做第一件和第二件：数模板，存代表网址表。这周结束时手上有一张40到70行的表，这是全部工作的地基。

第二周做第三件和第五件：算错位比，改验收规范。错位比拿去开一次会，把为什么要换单位这件事说清楚；验收规范当场改掉，下一次上线就生效。

第三周做第四件：对核心指标报告的组名单，产出差异清单。这周会有惊喜，通常能捞出两三个之前完全不知道的结构问题。

第四周做第六件，顺便把前三周的产出整理成一份能交接的文档。重点是让这些东西不依赖你个人——你休假两周回来它还在被用，这套方法才算真正落地了。

做完之后能看到什么变化

最先出现的变化不在流量上，在会议上。同一份问题清单，从八千行变成十几行之后，讨论的内容会从这个工作量太大了变成这几件先做哪一件。这个转变通常在第一次会上就能感觉到。

第二个变化在验收环节。按分支覆盖的清单跑上线检查，头几次会连续撞出存量问题——那些一直存在、只是从来没有人打开过那类页面的问题。前面那个案子第一次跑就撞出两个，这个命中率在别的站上也差不多。

流量层面的变化来得晚一些，而且不好归因，因为它是通过缩短问题存活时间实现的。一个模板级问题原来平均要三个月才被发现，现在两周内就能被验收流程逮到，省下的是那两个半月里持续发生的损失——而这部分损失，跟前面那个案子里没回来的用户一样，在报表上永远是一个空格。

同一张清单，四个角色各取所需

这张模板清单做出来之后，最省力的推广方式是让每个角色都在上面找到自己要的那一列，而不是开会宣讲一遍方法论。

SEO拿它当抽样依据，验收清单和监控范围都挂在上面；前端拿它当回归范围，改动落在哪个模板就测哪几条；产品拿它当功能地图，新需求要动哪几种界面一目了然；设计拿它当资产盘点，看看有没有几个界面长得该统一而没统一。

设计和SEO配合的那几个动作里最难落地的一条就是让设计稿和线上页面的对应关系保持清晰，而模板清单恰好是两边共用的那把尺子——设计稿按界面组织，代码按模板组织，两者本来就该是一一对应的，只是很少有人把这个对应关系明确写下来过。

写下来之后有个附带好处：新人进来第一周看这张表，比看任何入职文档都快。四十来行，站上有什么、长什么样、归谁管，一次看完。

常见问题解答

模板数和页面类型数，说的是同一件事吗？

基本是同一件事，但侧重不同。页面类型是从用户或者搜索引擎的视角划分的——这是一个商品页、这是一个分类页；模板是从代码视角划分的——这些页面由同一个文件渲染。

大多数时候两者能对上，因为类型不同的页面通常也由不同的模板生成。对不上的情况有两类：一类是同一个模板渲染出了用户眼里不同的东西（比如商品页和礼品卡页共用一个模板），另一类是不同模板渲染出了用户眼里一样的东西（改版留下的旧模板）。做审计的时候按模板划分更实用，因为你最终要改的是代码，而代码只认模板。

用爬虫工具能不能自动数出模板数？

能数出一个近似值，但要人工修正。常见做法是抓完全站之后按页面结构相似度聚类，或者按网址路径规则分组，两种办法都能把几万个网址收敛成几十组。

需要人工修正的地方在于分支。爬虫看到的是渲染结果，缺货商品页和有货商品页在它眼里可能是两类，也可能因为差异不大被归成一类，这取决于聚类的阈值怎么定。而这两种情况恰恰是你最需要分开的。所以自动聚类适合当起点，最后那一遍还得有人对着代码确认一次，通常花不到一小时。

核心指标报告里的网址组，能直接当模板清单用吗？

不能当完整清单用，但可以当校验用。那份报告只包含有足够现场数据的组，你站上访问量低的模板根本不会出现在里面，通常有三到五成的模板是缺席的。

它的正确用法是反过来：先自己数出模板清单，再拿报告里的组去对，看有没有一个组横跨了你的两个标签，或者两个组落进了你的同一个标签。这两种不一致都是线索，前者说明你分细了或者它们确实同质，后者说明这个模板里有条你没数到的岔路。整理出来通常十几行，是全站唯一一份外部视角的结构评估。

站上有几十万个网址，全量爬一遍到底要多久？

爬虫全量抓取跟逐条调接口是两回事，别搞混。爬虫的速度取决于你设的并发和目标服务器的承受力，几万页通常几个小时，几十万页一两天，成本主要是带宽和服务器压力。

真正卡脖子的是网址检查接口，官方配额是每站每天2000次，20万网址要跑100天。100天里站已经变了好几轮，扫完得到的不是一张快照而是一段横跨三个月的曝光。所以合理的分工是：爬虫做全量发现，接口和人工做抽样判断，别拿接口去做全量。

按模板抽样，会不会漏掉个别页面上的问题？

会，而且这是这套方法明确的边界。某个商品的主图挂了、某条描述被截断、某个价格填成了0，这些由数据造成的问题在模板层看不见，只能靠全量扫描发现。

区分的判据很简单：这个问题的答案取决于代码，还是取决于数据库里的某一行。缺规范标签是代码问题，看一条就够；标题超长是数据问题，得全量扫。技术SEO的问题大多落在代码这一侧，所以模板抽样特别有效；内容质量那一侧比例会反过来，两条路都得走。

只有几百个页面的小站，有必要做这套吗？

先算一下报表行数除以模板数。这个比值低于50的时候，按网址推进反而更快，多加一层归并纯属仪式感，没必要做。

不过有一件事小站也值得做，就是存一张模板代表网址表。它的用处跟站的大小无关——每次改版验收挑页面、每次跑速度测试挑页面、每次请外部顾问看站都用得上。小站做这张表可能只要二十分钟，往后每次省的都是实打实的时间。至于错位比、组名单校验那几件，等站长到几千页再说。

这跟团队已有的技术SEO审计清单冲突吗？

不冲突，它管的是另一件事。已有的审计清单回答的是要查哪些项目——收录、重定向、结构化数据、速度、内链，这些项目一条都不会因为换单位而减少。

换单位改变的是每一项该在多少个页面上查。原来是抽一把网址逐项查，现在是按模板清单逐项查，项目还是那些项目，只是抽样的组织方式变了。实际操作上就是在原有清单前面加一列模板名，把原来的一遍拆成按模板各一遍。清单不用重写，加一列就行。

权威参考资料