一个词值不值得单开一页，87个站的站点地图先替你答了一半

摘要：把87个电商与DTC站的站点地图全量拉下来，21.9万个网址逐个拆词归一，找出那些“用词完全相同、只是拼法不一样”的网址组。76个站里都有，占87.4%，一共2390组、6109个页面。其中六成是同一个名字后面挂着1、2、3的序号，两成是多一个词少一个词，还有130组是把同样几个词换了个顺序重写了一遍。

先说这批数据是怎么来的。有人问过一个很实际的问题：手上有个关键词，跟现有页面挨得很近，到底该不该单独开一页。这个问题的标准答法是做一次页面独立性测试——比对搜索结果、比对内容大纲、确认站点结构里有没有它的位置。

这套方法没问题，但它有个前提：你得先知道自己现在有多少页面已经在干同一件事。而这个前提，多数站是不成立的。

你以为在决定要不要多开一页，实际上你的站上可能已经有三页在讲同一件事了，只是它们的网址长得不一样，所以你没发现。这篇文章要量的就是这个数。

一个关键词该不该有自己的页面，这个判断卡在哪？

先把那套方法说清楚，因为后面的数据是给它补前提的。

三步走的判定流程

第一步查现有覆盖：翻后台数据，看哪些页面已经在这个词上拿到了展示，顺便找出互相打架的网址。第二步跑独立性测试。第三步根据结果选动作：新建、扩写、合并，或者做成可复制的模板。这套三步判定法的原文写得比我这里细，值得对着自己的站读一遍。

一个页面能吃下多少词，次要关键词怎么布局才不堆密度讲过一次。

核心的判断标准是一句话：一个词值得单开一页，当它能带来一组区别得开的查询、能支撑起真正不同的内容、并且在站点结构里有位置。三个条件缺一不可。

三个条件里，第一个最难自己判断，因为它取决于引擎怎么看；第二个最考验诚实，因为写的人总觉得自己能写出不一样的；第三个最容易被跳过，因为它牵涉到导航和内链，动起来麻烦。

这三个条件的顺序有讲究

看起来是并列的三条，实际上有先后。结构位置应该最先确认，因为它是唯一一个不满足就直接否决的条件。一个在站点结构里没有位置的页面，即使查询区分得开、内容也写得出来，它上线之后也是个孤岛。

结构位置这一条最实在，架构搭错爬虫根本找不到产品页。

查询区分度排第二，因为它决定了这一页有没有独立存在的外部理由。内容差异排最后，因为它是你可以通过努力去创造的——前两个不行，后一个再努力也没用。

实操里我见到的顺序常常是反的：先想到一个内容角度，觉得能写，于是决定建页；建完才发现放不进导航，也没有页面愿意链它。这个顺序一反，整套判断就变成了给一个已经做出的决定找理由。

独立性测试具体测什么

比搜索结果：把候选词和最接近的现有页面各查一遍，记下前十条自然结果，看重合度。重合高，说明引擎把这两个查询当成一回事；再看引擎偏爱什么类型的页面，是品类页还是产品页。

意图会漂移，关键词没动排名却掉多半是意图变了。

建内容大纲：在动手写之前先把标题层级列出来，跟现有页面的大纲摆在一起比。这一步的意义在于，它能在还没花成本的时候暴露重合。

确认结构位置：这一页的上级是谁、从哪些页面能链过来、用户在导航里能不能找到它、背后有没有稳定的内容或者库存支撑。

四种动作各自的适用场景

更新、合并还是删除，老文章的4步SOP给了判断路径。

这套方法缺的那一块

它假设你清楚自己现有的页面盘子。实际情况是，一个跑了三五年的电商站，网址数量早就超出任何人的记忆范围，而且大部分增长不是决策带来的，是各种批量操作的副产品。

盘子大了会拖垮流量，索引膨胀的诊断与处置。

所以在做“要不要开新页”这个决定之前，更该先做一次“现在有多少页在重复”的盘点。后者的成本比前者低得多，而且它经常直接把前一个问题回答掉了。

为什么这个盘点没人做

因为它看起来不产生价值。合并两个重复页面，短期内不会带来流量增长，还要花时间做跳转和内链调整。而开一个新页面，至少看起来像是在扩张。

按性价比排一排，11个速赢清单里也有这一类活。

这个偏好非常顽固，我在不少团队里见过：页面数量是个能写进汇报的数字，页面重复度不是。于是站越做越大，重复越攒越多，直到某天流量掉了才开始查。

更根本的原因是，重复这件事没有一个天然的责任人。建页面的人只对自己那一页负责，运营只对商品负责，技术只对系统能不能跑负责。没有人的职责范围里写着“确保整站不重复”，于是这件事就悬着。

反过来看那些做得好的站，通常不是因为有人特别负责，而是因为流程里恰好有一道自动的检查。把责任落到流程上，比落到人身上可靠得多——人会离职，流程不会。

而且清理这件事有个尴尬的性质：做得好的时候，什么都不会发生。流量不涨，排名不动，只是抓取分布干净了一点，报表准确了一点。一个成功的清理，看起来跟没做过一模一样。

所以它需要一个别的理由来支撑。我通常给的理由是数据可读性：合并之前，同一件商品的数据被拆在五个网址上，任何一份报表都是错的；合并之后，你才第一次看到这件商品真实的表现。这个理由比“对SEO好”管用得多，因为它指向一个所有人都能验证的具体后果。

Google那边怎么说这件事

官方文档的措辞一向克制：一组被判定为重复的网址会被合并成一个规范网址，其余的成为这一组里的成员。关于合并重复网址的那份说明没有说重复会被惩罚，它只是说重复会被合并。

它自己怎么挑规范页，9大决策逻辑与排查实操列得很细。

这个区别很重要。重复的代价不是罚分，是选择权的转移——你不合并，引擎替你合并，而它选中哪一个作为规范页，未必是你希望的那一个。本次样本里那些一件商品五个网址的情况，就是把这个选择权完全交了出去。

我从87个站的站点地图里找同一件事的两个网址

下面是这次的做法和结果。

样本和抓取

从一批公开可访问的DTC品牌站、电商站和几个平台型站点里，取到182份站点地图，其中72份是索引文件，展开一层拿到398份子地图。合并去重之后，91个站有可用网址，其中87个站的网址数在40以上，进入分析。

批量拿地址，6种格式解析与URL提取更省事。

总网址数21.9万。最大的一个站单站1.6万，最小的四十几个。这个规模差异后面会影响结论的读法，我会单独说。

为什么用站点地图而不是自己爬？两个原因。一是快，一份文件几秒钟就下来了，爬一个万级站点要几小时。二是站点地图代表的是站长自己认为值得被收录的那批网址，这个口径比爬虫爬到的更有意义——爬虫会爬到一堆站长自己都不想要的地址。

代价是漏掉了那些没进站点地图的重复页面。所以我这次量的是“连站长自己都承认应该收录的网址里有多少重复”，这个口径比全站爬取严格得多，数字自然也小得多。

索引文件那一层的处理

72份站点地图是索引文件，也就是里面装的是别的地图文件的地址。我对每份只展开一层，且每份最多取前6个子文件。

站点地图怎么写才不出错，2400站踩过的坑都在。

这个限制会漏掉大站的一部分网址——一个有30个子地图的站，我只看了6个。这是个刻意的取舍：宁可每个站少看一点，也要多看几个站，因为本文要回答的是“这个问题有多普遍”，不是“某个站有多严重”。

按 站点地图协议的定义，索引文件本身可以嵌套，但实践中很少有人做两层以上。所以展开一层基本够用，漏掉的主要是横向的宽度，不是纵向的深度。

怎么定义“同一件事的两个网址”

判据是这样：取网址路径的最后一段，转小写，按非字母数字切成词，去掉停用词和平台通用词，做一次粗糙的单复数还原，然后把剩下的词排序拼成一个指纹。指纹相同但原始拼法不同的网址，就是一组。

slug里的门道，影响抓取与排名的9个细节。

举个例子：baby-blankets-heathered-oatmeal-ribbed-knit 和 ribbed-knit-baby-blanket-heathered-oatmeal，切完排序之后完全一样，是一组。

为什么用词集而不用别的

因为它便宜、可复现，而且不需要抓取正文。抓21.9万个页面的正文来算相似度，成本高到没法做；而词集只需要站点地图，一份文件就够。

重复的六类成因，同域跨域参数变体全排查有对照表。

代价是它只能发现“用词层面的重复”，发现不了“说的是一件事但用词完全不同”的那类。所以这次量出来的所有数字都是下限，真实的重复只会更多。

这个取舍值得多说一句。一个粗糙但便宜的判据，最大的价值不在于它有多准，在于它能被真正跑起来。一个需要抓全站正文、跑相似度模型的方案，在方案阶段就会死掉；一个只要一份站点地图和二十行脚本的方案，今天下午就能出结果。

我的经验是：先用便宜的判据把最明显的一批捞出来处理掉，处理完之后再看剩下的问题值不值得上更贵的手段。多数时候，便宜那一轮就把八成的量解决了。

单复数还原为什么只做粗糙版

我用的还原规则很土：结尾ies变y，结尾es且前面不是特定辅音的去掉s，结尾单个s且不是ss的去掉。这套规则会犯错，比如把glass之外的一些词处理错。

停用词清洗那一套，URL slug优化器怎么用。

没上正经的词形还原库，一是环境限制，二是更精确的还原会带来一个副作用：它会把更多本来不同的词合并到一起，制造新的假阳性。在这个场景里，宁可漏掉一些也不要多抓一些。

这个取向贯穿了整套判据的设计：所有拿不准的地方，一律选择更保守的那一边。这也是为什么最终的数字比第一版小了一半。

停用词表里放了什么

除了常规的英语虚词，还放了一批平台通用路径词：collections、products、product、page、category这些。它们出现在几乎每一个电商网址里，留着的话所有网址都会互相“相似”。

路径结构本身也有讲究，10000个站的实测结论。

这一步是必须的，但它也带来一个副作用：路径结构的差异被抹掉了。一个在collections下、一个在blogs下的同名页面，在我的判据里算同一组。这个选择是有意的，后面有一节专门讲它。

先看结论

电商重复怎么治，8类成因加canonical全清单。

87.4% 这个数是本文最该记住的一个。它的意思是：如果你随机挑一个电商站，它的站点地图里几乎肯定存在至少一组“同一件事的两个网址”。这不是个别站的毛病，是这个业态的常态。

而2.78% 这个数是另一回事：它说明就总量而言，这个问题并不大。绝大多数网址是干净的。普遍但不严重，是这批数据最准确的一句概括。

这两个数放在一起，正好解释了为什么这件事长期没人管：因为按比例算它显得微不足道，2.78% 听起来完全可以忽略。但按站算，它几乎无处不在，而且那6109个页面是实打实在消耗抓取和分散信号的。

那11个没有重复的站是什么样的

87个里有11个一组都没找到。翻了一下，共同点是网址数都不大——多数在两三百以内，最大的也就八百。它们要么是品类少、上新慢的品牌，要么是主要靠一个大目录页承载所有商品的站。

扁平还是层级，SEO上到底差在哪。

这印证了前面的判断：重复不是能力问题，是规模和节奏的必然产物。页面越多、上新越频繁、参与建页的人越多，重复就越难避免。指望靠“大家仔细一点”来解决，基本没戏——这件事我在三个不同规模的团队里都验证过，结论一致。

不过这11个站也不能简单当成“做得好”。它们中有几个的问题其实在另一头：网址少到品类都铺不开，用户想找一类东西只能在一个大列表里翻。没有重复，有时候只是因为还没长到会重复的规模。

所以这个指标要配着规模一起看。三百个网址零重复，正常；一万个网址零重复，那说明这个站的建页流程里一定有某种约束在起作用，值得去问问是什么。

规模差异怎么影响这批数字的读法

最大的站单站1.6万个网址，最小的四十几个。如果按网址数加权，那几个大站几乎决定了2.78% 这个总占比；如果按站平均，得到的又是另一个数。

我报的2.78% 是全样本的总占比，也就是被大站主导的那个版本。按站取中位数的话，这个数会低不少——因为多数站的重复量很小。两个算法都对，只是回答的问题不同：一个是“这批网址里有多少是重复的”，一个是“典型的站有多严重”。

写结论的时候我选了前者，因为本文关心的是抓取和信号的浪费总量。但如果你是拿它来评估自己的站，该对标的是后者。这类差别不说清楚，读者很容易把一个总量指标当成个体基准去比。

这个数字会不会被建站平台影响

会，而且影响很大。用同一类平台的站，重复的形态高度一致，因为它们的网址冲突处理逻辑是同一套。本次样本里用某一类平台的站占了大头，所以序号型才会占到六成。

平台自带的分页逻辑，索引判断与canonical设置是个参照。

换一批用别的系统的站，形态分布肯定不一样，但“重复普遍存在”这个结论应该是稳的，因为它的成因是流程性的，跟具体用什么系统关系不大。

第一次算出来的数字，为什么有一半是假的？

这一节讲我自己的错误，它比上面那个百分比更值得记。

第一版跑出来4532组

我第一次做归一化的时候，做了一件看起来很合理的事：把所有纯数字的词删掉。理由是网址里的数字大多是商品ID、页码、序号，属于噪声。

自己划的及格线不算数，那个95%是怎么来的。

结果是4532组、12541个页面，占全部网址的5.7%。数字很漂亮，比最后的结论大了将近一倍。

然后我去看具体案例

翻到第三页就不对劲了。一组是 classic-5-inch-chefs-knife 和 classic-7-inch-chefs-knife，5寸和7寸的厨刀。另一组是2人帐篷和3人帐篷。还有一组是14盎司、30盎司、40盎司的三个保温杯。

口径一变结论就变，前1%是4家还是51家。

这些根本不是重复，它们是不同规格的商品。而我的归一化把区分它们的唯一信息——那个数字——当成噪声删掉了。

数字在网址里其实分两类

变体该合该拆，几十个URL的取舍正是这个问题。

四类里只有后两类该删，而我一刀切全删了。一个词该不该删，取决于它在这个位置承担什么功能，不取决于它长什么样。

修完之后掉到2390组

新的规则是：数字一律保留，只处理结尾那个孤立的纯数字——五位以上当商品编号，整条排除；1900到2100之间当年份，删掉并标记；12以内当变体序号，删掉并标记；其余的模棱两可，整条排除。

分母没说清就会出这种事，92%只覆盖了7.4%的买家。

改完之后组数从4532掉到2390，虚高了1.9倍。页面数从12541掉到6109，占比从5.7% 掉到2.78%。

这次失误和上次是同一类

它和把常用词误当特征词是一个毛病：用一个形式上的规则去近似一个语义上的判断。“纯数字是噪声”这个规则在很多场景下成立，恰好在商品网址这个场景下不成立，因为商品的核心区分点经常就是数字。

一条趋势线上三处口径变更，跨年数据能不能直接比。

而这类错误的共同后果，还是让问题看起来更严重。两次测量，两次虚高，方向完全一致。这已经不像巧合了，更像是这类粗糙判据的固有偏向。

怎么在下次提前发现

办法只有一个，而且很笨：把结果随机抽二十组，逐组用眼睛看一遍。我两次都是靠这一步发现问题的，没有任何统计指标提醒过我。

对不上账的时候，三家数据的对账方法。

抽样看的时候有个诀窍：不要只看那些明显对的，要专门去找“看起来最不像重复的那几组”。错误总是藏在边界上，而边界上的样本一眼就能看出不对。

为什么第一版的结果读起来那么合理

这才是最值得警惕的地方。4532组、5.7%、87个站里79个有问题——这组数字放在一起完全说得通，甚至比修正后的版本更符合“电商站重复很严重”这个预期。

合理的东西也可能是错的，换一个主语答案差16个点。

一个符合预期的错误结论，比一个反直觉的正确结论更难被发现。因为前者不会触发任何怀疑，你会直接开始想怎么把它写出来。

我这次能发现，纯粹是因为写作时需要举例子，于是去翻具体案例。如果这批数据只是用来出个报表、画个图，那个虚高一倍的数字会一路走到最后。

这个经验后来变成了我的一条固定动作：任何一个准备用出去的统计结论，先给它配三个具体例子。配不出来说明你还不理解这个数；配出来了，多半也就顺便发现问题了。

两个数字的差别有多大

虚高之后怎么修，对接一年的口径修正。

最后一行有意思：站数几乎没变。因为那些被误判进来的规格差异，绝大多数发生在本来就有真重复的站上。所以“87.4% 的站有这个问题”这个结论，在错误的版本里也是对的。

这提醒了另一件事：同一批脏数据，对不同的结论污染程度完全不同。算比例的结论全毁了，算覆盖面的结论基本没事。所以发现数据有问题的时候，别急着把所有结论都推翻，先分清哪些依赖被污染的那一部分。

修好之后，2390组是什么形态？

把这2390组按产生方式分了个类。

四种形态的成因完全不同

序号型是系统自动生成的：建站平台在检测到网址冲突时自动往后加数字。增减词型和词序型是人写的：不同的人、不同的时间，给同一个东西起了不同的名字。年份型是有意的：做了一个新版本，保留了旧的。

筛选器最容易爆网址，不爆炸的系统方案。

成因不同，处理方式也完全不同，这是把它们分开数的全部意义。系统生成的可以批量清理，人写的必须一个个看，有意保留的可能根本不用动。

集中度也很不一样

76个有重复的站里，前5个站贡献了1300多组，超过总数的一半。最多的一个服装品牌550组，1771个页面，占它自己网址总数的47%。

聚合口径怎么看，3类站点的实测。

换句话说，这不是一个均匀分布的问题，而是少数几个站问题极其严重，多数站有一点点。所以“87.4% 的站有这个问题”这句话，要配上“但多数站的量很小”一起读才准确。

占比高的站有什么共同点

翻了一下前十名，共同点挺明显：都是上新频繁的服装或者快消品牌，而且都在用同一类建站平台。上新频繁意味着不断有新商品要建页，用同一类平台意味着遇到网址冲突时的处理方式一样——自动加序号。

平台侧的治理，EAV与参数白名单是另一套解法。

这两个条件凑在一起，重复就会稳定地按周积累。它不是某一次操作失误，是一个每周都在运转的生产流程的固有产出。

把它换算成时间会更直观

那个550组的服装品牌，假设它做了五年，平均下来每周新增两组。两组听起来完全不值得管，也确实没人会为一周两组去开会。但五年之后就是1771个页面。

日志里能看出累积效应，爬虫到底抓了什么。

所有的技术债都是这个形状：单次增量小到不值得处理，累计总量大到不敢处理。而中间那个从“不值得”变成“不敢”的转折点，从来没有人注意到它什么时候发生的。

这也是为什么我更愿意推事前的那道闸而不是事后的审计。一道闸拦住的是每周那两组，成本几乎为零；审计要处理的是累计的1771个，成本高到要立项。

小站现在做，比大站将来做便宜一百倍

本次那11个一组重复都没有的站，网址数都在八百以内。它们现在加一道重名检查，等于用零成本锁定了一个干净的起点。

怎么讲这笔账，用商业语言把钱说清楚。

而那几个已经积累到几百组的站，现在要做的是一个跨越好几个季度的清理项目，还要协调投放、内容、开发三方。同一件事，早做是加两行代码，晚做是立一个项目。

如果你现在管的站还不大，这一篇里最值钱的一句话就是这个：趁现在。等到你觉得有必要认真处理的时候，成本已经翻了两个数量级。

序号型占了六成，这意味着什么？

这一档值得单独说，因为它数量最大，也最容易处理。

它是怎么产生的

典型场景：一个商品下架了，过一阵又上回来，或者换了个款号重新录入。系统检测到网址已被占用，就在后面加个1。再来一次，加个2。

下架再上架的处理，301、410与库存信号决策。

本次样本里见过最夸张的一组，同一件女式卫衣有五个网址，后缀分别是空、2、3、4、5。五个网址，五个页面，一件衣服。

这五个页面上都有什么

我抽查了几组，情况分三种：有的旧网址已经跳转到新的，那问题不大；有的旧网址还能正常打开，卖的是同一件商品；还有的旧网址打开是缺货状态，页面还在，但买不了。

404被抓不全是坏事，软404修复指南说得更细。

第二种和第三种都会进站点地图，也都会被抓取。第三种最伤：它既占抓取预算，又给用户一个买不到东西的落地页。

更麻烦的是，缺货页往往还保留着完整的商品信息和结构化数据，所以它在搜索结果里看起来跟正常商品页没有区别。用户点进来才发现买不了，而这个体验的损失不会记在任何一份SEO报表上。

站点地图里该不该放这些页面

不该。Google关于站点地图的建议里说得很清楚，放进去的应该是你希望被收录的、有价值的网址。一个跳转的、缺货的、或者已经被别的页面取代的网址，三条都不占。

导出逻辑要加条件，怎么只输出该收录的。

但实际情况是，很多站的站点地图是从数据库里全量导出来的，只要商品记录还在就会被写进去。这等于每天都在向引擎重申一批你自己都不想要的网址。

修法很简单：导出逻辑里加一个条件，只输出当前在售且状态码为200的商品页。这一行改动的效果，比清理一百个历史网址还明显，因为它一次性停止了信号的持续发送。

缺货商品页本身怎么处理

这是另一个大话题，简单说三种情况：短期缺货，页面留着，明确标注补货时间；永久下架但有替代品，跳转到替代品或者所属品类；永久下架且无替代，返回410让引擎尽快移除。

301、404和410怎么选，状态码怎么影响SEO。

最差的做法是留着页面什么都不说。用户不知道能不能等，引擎不知道该不该继续抓，而这个页面还在你的站点地图里占着一行。

为什么没人清理

因为清理它需要判断，而判断需要知道哪个是当前有效的。系统不知道，只有运营知道。而运营的日常工作里没有“清理历史网址”这一项。

改版后的死链，一次揪出来。

更现实的原因是：这些页面在后台是看不见的。商品列表里显示的是商品，不是网址；只有导出站点地图或者跑一次爬虫，它们才会浮出来。

怎么批量处理

这一档是四类里唯一适合批量处理的。做法：把所有结尾带序号的网址挑出来，按去掉序号后的名字分组，组内比较状态码和上架状态，保留一个，其余的做跳转。

这类活挂cron上，备份与sitemap一条龙。

有个前置检查别忘了：确认这些序号确实是系统加的，不是商品名字的一部分。办法是看这一组里有没有一个不带序号的版本。有，那序号八成是自动加的；只有 -1和 -2没有裸版本，那可能是别的意思，得人工看。

本次样本里我遇到过一组，三个网址分别以 -1、-2、-3结尾，没有裸版本。点开看是同一个产品的三种包装规格，序号是内部编号。差一点就把三个不同的商品页合成了一个。

整个过程可以脚本化，只在“保留哪一个”这一步需要人确认，而这一步通常有个简单规则：保留当前在售的那个，都不在售就保留最新的那个。一个500组的站，半天能清完。

清完之后能看到什么

最直接的是抓取分布的变化：原本分散在五个网址上的抓取，会集中到一个上。其次是内部报表变干净——同一件商品的数据不再被拆成五份。

抓取预算怎么分，2026年的12项实操。

顺带说一句，抓取这一侧还有别的省法。Google建议用304状态码节省抓取预算这条最近被重提过：内容没变的页面返回304，爬虫就不用再下载一遍正文。清理重复是减少要抓的地址数，304是减少每次抓取的字节数，两件事可以一起做。

至于排名，别期待立刻变化。这类清理的价值是止损和让数据可读，不是提升。把它当成打扫房间，不是当成装修。

跳转该怎么写才不出事

清理序号型的时候，跳转的写法有讲究。最稳的是一对一映射，每个旧网址明确指向一个新网址，写在配置文件或者数据库里。最危险的是用正则批量匹配——比如把所有结尾带 -1到 -9的都跳到去掉后缀的那个。

双向跳转很容易绕圈，Apache与Nginx双向实战。

为什么危险？因为有些商品的正式名字里就带数字后缀。一个叫 tumbler-30 的商品，被规则匹配成 tumbler-3 的变体，就跳到了一个完全不同的商品页上。这类错误上线之后很难被发现，因为跳转本身是成功的。

Google关于永久跳转的说明里也提到，跳转链要尽量短、映射要尽量明确。一条规则少写一分钟，出错之后排查要花一天。

清理之前先备份一份清单

把要处理的网址、它们当时的状态码、以及跳转的目标，全部存成一份表。这份表在两个时刻会救你：跳转配错要回滚的时候，以及三个月后有人问“那个页面去哪了”的时候。

跟开发怎么配合，后端协作的7个动作点。

这件事听起来是常识，但实际操作里经常被省掉，因为脚本跑完了、结果对了，谁还愿意再导一份表。而恰恰是那些一次跑成的操作，最后最没人说得清当时到底改了什么。

词序颠倒的那130组，是怎么产生的？

这一档数量最少，但它最能说明问题。

先看几个真实例子

一个服装品牌有两个网址，一个叫 womens-hammered-satin-popover-shirt-bone-black，另一个叫 womens-hammered-satin-popover-shirt-black-bone。同一件衬衫，两个颜色词换了个顺序。

命名这件事，7维设计与上线后铁律。

一个家居品牌，一个叫 baby-blankets-heathered-oatmeal-ribbed-knit，另一个叫 ribbed-knit-baby-blanket-heathered-oatmeal。同样几个词，重新排了一遍。

一个个护品牌，两顶联名帽子，一个叫 dad-hat-tushy-x-narragansett，另一个叫 dad-hat-narragansett-x-tushy。连联名双方的顺序都换了一次。

这说明了什么

说明这个站上没有一份“东西该怎么命名”的约定。两个人、或者同一个人在两个时间点，面对同一件商品，写出了两个名字。

一份能交接的规范，内容简报怎么写。

而且这两个名字都不算错。“骨白黑”和“黑骨白”，谁也说不出哪个更对；“婴儿毯 罗纹针织”和“罗纹针织 婴儿毯”，两种说法在中文和英文里都成立。没有对错的地方，就是最容易分叉的地方。

这也是为什么这一档虽然只有130组，但它最值得引起注意：它证明了这个站的内容生产没有任何一致性约束。今天能在颜色顺序上分叉，明天就能在别的地方分叉。

那两顶帽子的例子最能说明问题

一个联名系列的两顶帽子，网址一个是“甲乘乙”，一个是“乙乘甲”。这不是两个人写的——同一批上架的商品，多半是同一个人在同一个下午录进去的。

商品侧的结构化，Schema结构加GEO联动。

连同一个人在同一段时间里，都没有保持一致的顺序。这说明这件事根本没进入过意识层面：录商品的时候，他想的是把信息填全，不是想网址会长什么样。

指望通过培训解决这个是不现实的。人在做重复性录入工作的时候，注意力不在这些细节上，这是人的正常状态，不是失职。所以答案还是那个：把约束放进流程，别放进人的自觉。

这类重复不可能靠系统避免，因为系统看不出这两个名字说的是一件事。它只能靠一份命名规范，或者一次发布前的重名检查。

词序为什么会影响这么大

对搜索引擎来说，网址里的词序影响很小，两个网址的语义几乎一样。问题不在引擎那边，在你自己这边：两个名字意味着两条数据线、两份统计、两个可能被分别优化的对象。

内链上的参数也伤信号，流量分析与抓取的取舍。

更麻烦的是内链。有人链了第一个，有人链了第二个，本该集中的信号被劈成两半。这一点在站内搜索和推荐位上也一样。

怎么防

最有效的一条是发布前的重名检查：新建页面时，把标题拆成词、排序、跟已有页面比一遍，命中就提示。这个检查的实现成本非常低，就是我这次用的那套逻辑。

蚕食怎么修，5维度信号区隔实战。

把一次事后审计变成一次事前提示，是这批数据里性价比最高的一个改法。它每次只拦一个页面，但一年下来能省掉几百组。

提示该说什么

不要只说“检测到重复”，那样的提示三次之后就会被无视。要说清楚三件事：撞上的是哪一个页面、它现在是什么状态、以及给一个可以直接点的链接过去看。

告警怎么分级，三平台诊断与90天闭环。

让人一秒钟就能判断“哦这个我知道，确实不一样”或者“咦这个页面还在？”。一个能被一秒钟处理掉的提示，才有可能被长期保留；一个需要花五分钟去查的提示，很快就会被关掉。

这道提示还能顺便解决另一个问题

它其实是一个轻量的站内检索：建页的人在写标题的时候，就能看到站上已有的相关页面。这个信息对他有直接价值——他可以顺手加个内链，或者调整角度让两页更互补。

顺手能看到相关页，两套标注怎么归一也是靠同一份索引。

换句话说，这道闸对建页的人不是阻碍，是帮助。这一点很重要，因为任何一个被当成阻碍的检查，最终都会被绕过去。让它同时提供价值，是让它活下来的唯一办法。

如果暂时加不了这道闸

退一步的做法是每月跑一次审计，只看新增的部分。把这个月新建的页面拿出来，跟历史指纹比一遍。量小，几分钟就能看完。

批量监控可以用接口，2000条配额下的管线。

这比季度全量审计好得多，因为新建一个月内的页面最容易处理——还没积累外链，还没被大量内链指向，改名字或者删掉的成本都很低。等到半年后再发现，处理成本就完全不一样了。

命名规范该写多细

不用很细，三条就够：属性的固定顺序（比如先品类后颜色再材质）、单复数的统一约定、以及联名或者组合类商品的书写顺序。剩下的交给重名检查兜底。

写法上的规矩，8大实战技巧也是越少越好记。

写太细的规范没人看，也执行不了。三条能记住的规则，加一道自动检查，比一份二十页的文档管用。

已经存在的词序型怎么处理

这一档没法批量，只能一组一组看，因为你得判断哪个名字更好。判断标准建议只用一条：哪个更接近用户会怎么说。不是哪个更符合内部命名习惯，也不是哪个更早创建。

合并与权重回收，完整打法。

比如那件衬衫的两个网址，一个是“骨白黑”，一个是“黑骨白”。用户在描述这件衣服的时候会先说哪个颜色？通常是主色。那就保留主色在前的那个。

这类判断做起来其实很快，一组十几秒。130组也就半小时。真正花时间的不是判断，是判断完之后改内链和跳转。所以这一档我建议攒够一批一起做，别零散处理。

还有一种更省事的处理：如果这两个网址的流量和外链都可以忽略不计，那不用做跳转，直接把其中一个改成不索引，然后从站点地图和内链里拿掉就行。跳转是为了迁移价值，没有价值可迁的时候，跳转纯属增加复杂度。

怎么判断有没有价值可迁？看两件事：过去半年有没有自然流量，有没有外部站点链接过来。两个都是零，直接下线；任意一个不是零，老老实实做跳转。

增减词型那459组更值得先看

它数量是词序型的三倍多，而且成因更多样：有的是加了个修饰词做了个新页面，有的是漏了个词，有的是一个带品牌名一个不带。这一档里混着真重复和真差异，不能一刀切。

哪些词值得单独打，9大挖掘策略。

快速分辨的办法：看多出来的那个词是不是实质性的。多出来的是best、guide、how这类，多半是同一件事的不同表达；多出来的是尺寸、材质、人群这类，那可能真是两个不同的东西。

本次样本里两种都有。一个3C品牌的 100w-gan-charger 和 100w-gan-chargers 只差一个复数，肯定是重复；而另一个站的两个网址一个带人群词一个不带，那是真的分了两页在做。

同一个话题横跨博客和品类页，算不算重复？

这是这批数据里最有意思的一类，也是最接近原始问题的一类。

先看这一组

一个3C品牌，同一个话题下有四个网址：一个是英国站的博客文章，一个是德国站的博客文章，一个是波兰站的品类页，还有一个是英国站的品类页。四个网址，讲的都是“给某类电脑用的某种扩展坞”。

内容型页面的索引控制，工程化怎么做。

另一个音频品牌，一个是西班牙站的品类页，一个是博客里的选购文章，两者的词集完全相同。还有一个护肤品牌，一个是标签聚合页，一个是文章页，同样的词。

标签聚合页那一组特别典型。很多内容管理系统会自动为每个标签生成一个聚合页，而标签名往往就是文章标题里的关键词。于是一篇文章上线，同时诞生了一个跟它同名的聚合页。这个聚合页里可能就只有这一篇文章。

标签聚合页该不该被收录

看它里面有几篇。一篇的时候它就是这篇文章的一个影子，应该不索引；累积到五篇以上、且这几篇确实构成一个话题的时候，它才开始有独立价值。

分类和标签怎么分工，索引治理与着陆页打法。

这个判断可以自动化：聚合页里的条目数低于阈值就加不索引标记，超过阈值自动放开。这一条规则能一次性解决掉很多站的一大批重复，而且几乎没有副作用。

阈值定几合适？我的习惯是五，跟品类页的八不一样，因为聚合页的价值来自话题密度而不是选择余地。五篇文章已经能构成一个像样的话题入口，而五件商品撑不起一个品类页。

还有一个细节：放开索引之后，聚合页最好加一段导语，说清楚这个话题是什么、这几篇文章分别解决什么问题。光是一串标题列表的聚合页，即使条目够多，也很难有独立价值。这段导语通常一百来字，写一次管很久。

标签和分类别同时开放

很多内容管理系统同时生成分类页和标签页，而运营给文章打标签的时候，标签名经常跟分类名重合。于是同一批文章在两个地方各聚合了一次。

这一类重复比单个标签页更麻烦，因为两边的条目数可能都不少，看起来都够格独立。解法是选一边开放：内容以分类为主的站关掉标签页索引，以标签为主的站反过来。两边都开，就是主动制造一批同词集的页面。

本次样本里我没有专门统计标签页的比例，因为很多站的标签路径被我当成通用路径词过滤掉了。但从抽查的印象看，这一类在内容型电商站上占的比重不小。

这也是这套判据的一个局限：我为了让不同站之间可比，把平台特有的路径段抹掉了，代价是丢掉了页面类型这个维度。如果只分析一个站，反而应该保留路径段，因为同一个站内部的路径含义是稳定的。

换句话说，做横向对比和做自查，判据的设计原则是不一样的：前者要抹掉个体差异才能比，后者要保留个体特征才能用。照抄一份为横向对比设计的判据来自查，往往会漏掉最该看的那一类。

跨地区站那几组的正确处理

英国站和德国站各有一篇同话题博客，处理方式不是合并，是让它们互相声明语言地区关系。这一层做对了，两篇内容各自服务各自的市场，互不干扰。

那些语言版本网址的真实身份，多数只是规范页的别名。

做错的话有两种后果：要么引擎在两个市场之间挑一个展示，另一个市场的用户看到不合适的版本；要么两篇被当成重复，其中一篇被合并掉。两种后果都比“什么都不做”更糟，因为你已经付出了做两篇的成本。

这算不算重复

严格说不算，它们的页面类型不同、用户处在的阶段不同、转化路径也不同。品类页给的是商品列表，博客给的是判断依据。这正是“一个词值得单开一页”的合理场景之一。

用户旅程分六段，关键词布局与内容策略。

但它有条件：两个页面得真的在做不同的事。如果那篇博客文章的内容，本质上就是把品类页上的商品又列了一遍加几句评价，那它就没有独立存在的理由。

怎么判断这一对该不该都留

用那个大纲比对法，但简化一下：把两个页面的主要标题各列出来，看有几条是对方没有的。少于三条，合并；三到五条，考虑把博客那篇改成更明确的角度；五条以上，两个都留。

话题入口页怎么做，从内链中转站到被引用。

这个阈值不是什么标准，是个经验值，但它至少给了一个能操作的判断，而不是停留在“看情况”。

跨地区站的那种更麻烦

英国站和德国站各有一篇同话题博客，这在多语言站里太常见了。它们之间不是重复，是不同市场的版本，正确的处理是让它们互相声明语言关系，而不是合并。

同语言多地区怎么不打架，美英澳那一套。

问题出在同一个市场内部：英国站既有博客又有品类页，两个网址盯着同一簇词。这一对才是需要判断的。

我的判据抹掉了路径差异

前面提过，我把collections、blogs这类路径词放进了停用词表，所以一个在博客下、一个在品类下的同名页面，在我这里算同一组。

目录层级的影响，6招优化实战。

这是个有意的选择：我想找的是“讲同一件事的网址”，不是“路径相同的网址”。但它带来的后果是，这2390组里混着一部分本来就该分开的合理组合。

混进来的比例大概是多少

我抽了40组人工看，其中6组属于这种跨类型的合理组合，占15%。按这个比例外推，2390组里大概有三百多组不该算作问题。

数据信谁，6场景选型与三源校准。

这个误差我没有从最终数字里扣掉，因为抽样只有40组，扣掉反而是假精确。读的时候心里减掉一成半就行。

那六组合理组合长什么样

四组是品类页加同话题博客，一组是标签聚合页加文章页，还有一组是产品页加使用教程页。共同点很清楚：两个页面在用户旅程上处在不同位置，一个负责让人了解，一个负责让人买。

内容页怎么承接，FAQ段落8步实战。

这类组合不但不该合并，做得好的话它们之间还应该互相链接：博客文章链到品类页承接购买意图，品类页链到博客文章承接犹豫的用户。本次抽到的那六组里，只有两组做了这层互链。

剩下四组是各做各的，互相不认识。这其实比重复更可惜——你已经付出了做两个页面的成本，却没拿到两个页面配合的收益。

跨类型的组合怎么判断该不该留

三个问题。第一，这两个页面的用户处在同一个决策阶段吗？同一个阶段，合；不同阶段，留。第二，它们的转化目标一样吗？都是加购，那多半该合。第三，有没有互链？没有的话，先补互链再观察，别急着合。

信息词流量过大有代价，6大危害与破局。

第三个问题最实用，因为补互链的成本远低于合并，而且效果往往立竿见影。很多看起来该合并的页面，补上互链之后各自的表现都变好了，因为它们终于开始互相导流而不是互相竞争。

那套三步判定法，落到电商站上怎么用？

回到最初的问题。有了前面这批数据打底，这套方法可以用得更具体。

第一步不该是查数据，该是查重名

原方法的第一步是去后台看哪些页面已经在这个词上有展示。这一步没错，但它有个盲区：那些一次展示都没拿到的重复页面，在这一步里是隐形的。

先过硬闸，可索引性一键体检。

所以我建议在它前面加一步：把候选词拆成词集，跟站点地图里所有网址的词集比一遍。这一步不需要任何后台权限，一份站点地图加二十行脚本就够。

命中了怎么办

命中说明你要建的这一页，站上可能已经有了。先去看那个页面：它现在是什么状态、有没有内容、是不是序号型的历史遗留。三种情况三种处理，但都轮不到新建。

按症状分诊，不被收录的急救手册。

没命中再走原来的三步

没命中，说明这个词在你站上确实是新的，这时候再去比搜索结果、建大纲、看结构位置。顺序这样排，是因为查重名的成本远低于跑独立性测试。

候选词哪来的，一个主题挖50个问题。

电商站的一个特殊判据

原方法里有一条是“确认有稳定的库存或者足够的支撑内容”，这条在电商站上要加重。因为品类页的价值直接跟商品数挂钩：一个只有三件商品的品类页，无论词多好，都撑不起来。

商品侧的排序因素，6大因素与流量提升。

我的经验阈值是八件。低于八件，这个词就先做成筛选条件或者塞进更大的品类页里，等商品数上去了再独立。提前建好的空品类页，最后都会变成需要清理的对象。

八这个数不神圣，你完全可以按自己的品类调。定它的逻辑是：一屏能看到的商品数，加上一点余量。用户点进一个品类页，第一屏只看到三四件东西，他会立刻退回去——这个页面在他眼里就不是一个品类，是一个凑数的集合。

客单价高的品类可以往下调。卖大型家具或者定制类产品的，五件甚至三件都能撑得住，因为用户本来就预期选择不多，而且每一件都会看得很仔细。反过来，服饰配件这类品类，八件都嫌少。

真正该问的不是“几件够”，是“用户看到这一屏会不会觉得来错地方了”。八只是一个方便记住的起点。

那些低于阈值但词很好的怎么办

做成一个带筛选的入口：让这个词指向大品类页并预置筛选条件，网址上带一个可读的参数或者路径段。这样既接住了这个词，又不用维护一个空页面。

等这个筛选条件下的商品数长起来了，再把它升级成独立页面，把原来那个带参数的地址跳过去。先做轻的，够格了再做重的，比一上来就建页然后等它慢慢空掉要稳。

商品数会掉下去怎么办

这是空品类页的主要来源：建的时候有二十件，两年后季节过了、款式下架了，只剩三件。而没有人会回头去检查一个两年前建的品类页现在还剩几件商品。

空品类怎么处理，分类树清理那一套也是同一个思路。

解法是给品类页也加一个定期检查：商品数低于阈值的页面，自动列出来给人看一眼。处理方式有三种，合进上级品类、改成筛选条件、或者暂时下线等补货。三种都行，最差的是放着不管。

本次数据里那些重复率高的站，我抽查过几个品类页，确实有商品数只剩个位数的。它们还在站点地图里，还在被抓取，还在参与内链，唯独没有内容。

另一个电商特有的判据：季节性

有些词的搜索量高度集中在一年里的两三个月。为这类词单独建页，一年里有九个月它是空的或者过时的。更合理的做法是做成一个长期存在的页面，内容随季节更新，而不是每季建一个新的。

季节曲线怎么量，提前布局的做法。

本次数据里的年份型那98组，有相当一部分就是这么来的：每年做一个新版本，旧的留着。五年之后同一个主题有五个页面，其中四个是历史文物。

模板化那一条要格外小心

原方法建议对可复制的结构做模板，先上试点页再全量。这条在电商站上尤其重要，因为电商的模板化能力太强了——一个品类乘一个颜色乘一个尺码，轻松生成几千页。

筛选页要不要Disallow，三类判别法。

本次数据里那几个重复率接近一半的站，多半就是模板化没收住。模板化是把双刃剑：它让你能低成本铺开，也让你能低成本地铺错。

试点页该怎么设计才算数

原方法说先上几个试点页，看索引情况、查询覆盖和用户互动，再决定要不要全量。这条很对，但实操里试点经常做成了走过场：上三个页面，两周后看一眼，觉得还行就全量了。

试点最怕外部冲击，上线掉5%出在那26天。

试点要算数，得满足三个条件。第一，试点页要覆盖最好和最差的情况——不能只挑商品最多、词最热的那几个组合，那样结论必然是乐观的。至少要有一个商品数刚够线的、一个词很冷的。

第二，观察期不能少于六周。索引本身要两三周，有了索引之后还要几周才能积累出可读的查询数据。两周就下结论，你看到的只是抓取速度，不是效果。

第三，要提前说好什么算通过。比如：三分之二以上的试点页被索引、每页至少覆盖三个不同查询、平均停留时间不低于同类页面的七成。不提前定标准，事后一定会找到理由说通过。

全量之后还要留一道闸

模板化最麻烦的地方是它会持续生产。今天铺了两千页，明天新增一个品类，自动又多出两百页。所以全量之后必须留一个持续的检查：每个新生成的页面，商品数够不够线、有没有和已有页面撞词集。

哪些页该屏蔽，这7类加实操。

这道闸的实现很简单，就是在生成逻辑里加两个条件判断，不通过就不生成、或者生成为筛选参数而不是独立网址。加这两行的成本，比事后清理两千个页面低两个数量级。

什么样的组合最不该独立成页

按本次样本的观察，有三类基本不该独立：颜色单独成页、尺码单独成页、以及价格区间单独成页。这三类的共同点是它们描述的是筛选条件，不是一类东西。

站内搜索页那一类，4种方案对比。

用户搜“蓝色连衣裙”确实存在，但他要的是一个能筛蓝色的连衣裙列表，不是一个只有蓝色的孤立页面。前者可以用筛选参数配合可索引的筛选页解决，后者会在换季之后变成一个空页面。

反过来，材质、场景、人群这三类通常值得独立，因为它们背后有真实不同的选购逻辑。判据不是搜索量，是“这一页能不能写出别的页写不出的内容”。颜色写不出，材质能写出。

搜索结果重合度这一步，没有工具怎么办？

三步里最难落地的就是这一步，因为它需要看搜索结果。

手工做一次要多久

两个词各查一次，记下前十条结果的域名和网址，算重合数。熟练的话一对五分钟。听着不多，但如果你有三十个候选词，就是两个半小时。

要省时间就上工具，三条路的横评。

可以省掉的部分

其实不需要完整记十条。只看前五条，而且只记域名不记完整网址，重合度的判断结果在绝大多数情况下不变。这样一对能压到两分钟。

粗一点的口径够用，3平台300站实测。

另外一个省事的做法：先看两个词的结果页里，有没有对方的页面。你自己的页面同时出现在两个查询的结果里，这本身就是一个很强的“引擎认为它们是一回事”的信号，比数重合度直接得多。

重合度多少算高

常见的经验线是前十条里重合六条以上算高、三条以下算低。中间那一档最难判，得靠下一步的大纲比对来定。

结果每天都在变，波动还是真掉了。

这个阈值不必太较真，因为搜索结果本身每天都在变。它的作用是把候选词粗分成三堆，不是给出一个精确判断。

结果页类型比重合度更有信息量

如果一个词的结果页里全是品类页，另一个词的结果页里全是长文指南，那即使重合度不低，这两个词也大概率该分开做——因为引擎对它们的期待不一样。

意图有五种，对应的内容策略。

看类型不看重合，这是我从这一步里学到的最实用的一条。类型的差别一眼能看出来，重合度还得数。

类型有哪几种要认

电商相关的查询，结果页大致就四种形态：商品列表页占主导、单品页占主导、长文指南占主导、以及混合型。前两种是交易意图，第三种是了解意图，第四种通常意味着这个词的意图还没稳定下来。

结果页形态在变，引用与排名脱钩之后。

混合型的词是最值得做的，因为它还没被谁占死；也是最容易做砸的，因为你可能选错形态。遇到混合型，看排在最前面那两三条是什么形态，跟着它们走。

形态不匹配的代价

如果一个词的结果页全是长文指南，你却建了个品类页去打，那这一页大概率进不了前列——不是因为它质量差，是因为它给的东西不是这个查询要的。

写之前先定形态，7步GEO实战流程。

反过来也一样。这类错配在电商站里特别常见，因为电商的默认反应是“建个品类页”。而有相当一部分品类词，用户要的其实是先弄明白怎么选。

这一步和词集检查的分工

词集检查回答的是“我站上是不是已经有了”，结果页类型回答的是“外面期待的是什么形态”。两个问题都过了，才轮到大纲比对回答“我能不能写出不一样的”。

技术审计分几层，42步实战列过。

三步的成本递增，所以顺序不能变。词集检查几秒钟，结果页看一眼两分钟，大纲比对要半小时。把最便宜的放在最前面，是任何一套筛选流程的基本原则。

三步的淘汰率也不一样。词集检查大概能淘汰掉两成的候选——那些你站上已经有了的。结果页类型再淘汰一成左右——形态完全不对的。剩下的七成才进大纲比对，而大纲比对通常还会再刷掉一半。

算下来，一百个候选词最后真正值得建页的大概三十几个。如果你的团队现在是候选词有多少就建多少页，那这套流程能立刻把工作量砍掉三分之二，而产出的页面质量还更高。

被刷掉的那些词去哪了

不是丢掉，是分流。词集命中的，去合并或者扩写已有页面；形态不对的，换一种内容形态重新考虑；大纲撑不起来的，作为一个小节并进相关页面。

一个词被判定为不值得单开一页，不等于这个词没价值。它只是不值得为它做一个独立的容器。这个区别很重要，否则这套流程会被理解成砍掉七成的机会，而实际上它是把七成的机会用更省的方式接住。

实际操作里，我会给每个被刷掉的词标一个去向：并入哪一页、以什么形式。这份记录本身就是下一轮内容排期的素材，比一份光有词没有去向的清单有用得多。

本地做不了怎么办

用国内网络查国外搜索结果，结果本身就不准，还会被地域和个性化影响。可行的替代是用后台的查询报表反推：把这两个词各自带来展示的页面列出来，看是不是同一批。

看后台数据前，网域还是网址前缀资源要先选对。

是同一批，说明引擎在用同一批页面回应这两个词，等价于高重合度。这个信号来自你自己的数据，比抓搜索结果稳定得多。

还有一个更强的信号：互相替换

如果你发现某个查询在不同时间由不同的页面来承接——这周是A页出现，下周换成了B页，再下周又换回A——那基本可以确定引擎认为这两页在做同一件事，只是拿不准该给谁。

后台数据有黑洞，1000行与阈值过滤怎么补。

这种反复替换是最明确的合并信号，比任何重合度计算都直接。因为它不是你在猜引擎怎么想，是引擎自己在反复表态。

怎么看到这个现象？在后台按查询筛选，把时间范围拉长到半年，看这个查询下的页面列表。稳定只有一个页面，说明分工清楚；两个页面轮流出现，说明它们在互相顶替。

这个信号的另一面

反复替换还有一个后果，很多人没意识到：每次替换，这个查询的排名都会重新洗一次。因为换了个页面就等于换了一组信号，之前积累的表现数据没法完全继承。

收录排名流量是三件事，先分清卡在哪。

所以两个页面互相顶替的时候，它们的排名通常都不如合并之后的那一个。这不是玄学，是很直接的道理——你把本来能集中的东西分成了两半，还让它们轮流上场。

如果实在拿不准

有个折中做法：先不合并，而是把其中一个明确降级——把它从主导航里拿掉、减少指向它的内链、在内容上把它改成更窄的角度。观察四到六周，看另一个页面的表现有没有变好。

可逆的动作先做，按性价比排的清单。

变好了，说明确实在互相抢，可以放心合并；没变化，说明它们各自有各自的用户，留着。这个做法比直接合并可逆，代价只是多花一个月。对拿不准又不敢动的情况，值得。

大纲重合度才是真正的判据吗？

我认为是，而且它比搜索结果那一步更值得花时间。

为什么它更可靠

因为它测的是你能不能写出不同的东西，而这件事完全由你决定，不受引擎、地域、时间影响。搜索结果告诉你引擎现在怎么看，大纲告诉你你有没有本事让它改看法。

一稿多发怎么不被反超，归属机制。

怎么快速比

把两个页面的二级标题各列一行，摆在一起。然后问两个问题：新页面有几条标题是老页面完全没有的；这几条能不能各自撑起三百字以上的实质内容。

提纲阶段能省很多事，写作流程7步。

两个问题都过关，才值得新建。只有第一个问题过关，说明你想到了不同的角度，但没有对应的材料，写出来还是水。

一个更狠的检验

把新页面的大纲拿给一个不了解这个业务的人看，问他：这两页读起来是不是同一篇文章的两个版本。如果他说是，那基本就不用建了。

让机器读得懂，5维度写作法。

这个检验之所以有效，是因为写的人总能看出区别，读的人往往看不出。而搜索引擎在这件事上更像读的人。

大纲比对什么时候会误判

两个页面的大纲差别很大，但内容实际重合——这种情况常见于把同一批信息用不同的标题重新组织了一遍。防它的办法是看证据：两个页面里引用的数据、案例、来源，是不是同一批。是同一批，那大纲再不同也是一件事。

看证据不看结构，事实密度7招。

反过来的情况也有

大纲高度相似，但内容完全不同——比如两个市场的同类内容，结构一样但数据和案例都是本地的。这种该留，而且该用语言地区关系把它们串起来，而不是合并。

本地化不是翻译，原生再创作的生产线。

把大纲比对做成一张表

实操上我习惯做成两列的表：左边是老页面的二级标题，右边是新页面的。能对上的放在同一行，对不上的单独占一行。做完之后一眼就能看出有多少行是单边的。

往上讲的时候，6步翻译成业务语言。

这张表还有个额外用处：它直接就是合并时的施工图。如果最后决定合并，那些单边的行就是要搬过去的内容，能对上的行则要挑一个更好的版本保留。判断和执行用的是同一份材料，省掉一次重新梳理。

三百字这个阈值怎么来的

不是什么行业标准，是个经验数。三百字大约是把一个具体问题说清楚所需要的最小篇幅：给出结论、说明适用条件、举一个例子。少于这个数，通常意味着这一节只有观点没有支撑。

篇幅和深度的关系，怎么量才算数。

用它做判据的好处是可操作：你不用去评价内容“有没有深度”，只需要问自己“这一节我能不能写满三百字而不注水”。能不能写满，比够不够深刻，是一个诚实得多的自问。

大纲之外还该比一样东西

比这两页各自打算引用什么材料。数据来源、案例、图表、工具，这些是内容的骨头。两个页面如果计划引用同一批材料，那它们大概率就是同一篇文章的两种排法。

实体这条线，AEEBM五阶段。

这一条尤其能挡住一种常见的自欺：把同一份调研数据换个角度再写一遍，标题全不一样，读起来却处处眼熟。搜索引擎在这件事上比人敏感得多，因为它比对的正是那些具体的实体和数字。

一个反向的检查

做完前面所有比对，还可以反过来问一句：如果这两页只能留一个，留哪个？如果这个问题很好回答，说明它们本来就分了主次，那就该合并，把次的并进主的。

留一个还是留两个，更新合并删除的SOP。

如果这个问题很难回答，两个都觉得该留，那才是真正值得分成两页的情况。这个问法的好处是它绕开了所有技术判据，直接逼你做一次价值判断。

为什么大纲这一步经常被跳过

因为它发生在动手之前，而动手之前的所有工作在感觉上都像是拖延。写大纲不产生页面，比对大纲更不产生页面，两件事加起来要花半小时，而这半小时里什么都没做出来。

把它做成必填项，可交接的生产规范。

但这半小时挡住的，是几天的写作外加之后一直存在的一个多余页面。投入产出比高到离谱，唯一的问题是它的收益是隐形的——你永远看不到那个没被创造出来的重复页面。

这跟前面说的清理是同一类问题：做对了什么都不会发生。所以我更倾向把它做成流程里的一个必填项，而不是一个靠自觉的好习惯。提纲不填不给排期，是最简单有效的一条规矩。

大纲比对还能顺便定内链

比对完之后，那些“两边都有但角度不同”的部分，天然就是互链点。老页面在这一节提一句“更详细的做法见新页”，新页在对应位置回指老页。

互链点怎么找，内链网络的织法。

这一步在比对的当下做，成本几乎为零；等到两个页面都上线之后再回头补，就要重新读一遍两篇文章。顺手能做的事一旦拖到以后，多半就不会做了。

该合的时候怎么合，才不丢转化？

判断完是一回事，动手是另一回事。合并做砸的成本比不合并高得多。

先定保留哪一个

三个判据按优先级排：哪个有更多的自然流量、哪个有更多的外部链接、哪个的网址结构更符合你现在的规范。前两个看数据，第三个看规范。

信任怎么继承，6信号实战。

不要按“哪个内容写得好”来选。内容可以搬过去，流量和链接搬不过去——或者说搬过去要付跳转的损耗。

这一条经常被推翻，因为写内容的人会强烈主张保留自己那一版的网址。可以理解，但账不是这么算的：一个有三年历史、攒了几十条外链的网址，它的价值不在于上面写了什么，在于外面有多少地方指着它。

折中的办法是：保留旧网址，把新版内容整个换上去。这样既拿到了更好的内容，又保住了地址的历史。唯一要注意的是内容换掉之后，原来那些外链指向的说法可能已经不在页面上了，最好在文中保留一小节承接。

三个判据打架的时候

流量多的和外链多的不是同一个，怎么办？优先外链。因为流量是可以通过内链和曝光重新导过去的，外链不行——你没法让别人改他们的链接。

权重怎么传，子域还是子目录算过账。

如果两者都指向同一个，但那个网址的结构很难看（比如带着一串序号），要不要为了规范去换？不要。网址好不好看的收益，远低于换地址的成本。规范是给新页面用的，不是用来改造历史的。

合并之后旧网址还要留多久

跳转至少留一年，有条件的话永久留着。有人觉得跳转规则积累多了会影响性能，实际上除非规模到几万条，否则完全不用担心。

移除要多久，6大场景实测给了参照。

过早撤掉跳转，是我见过最可惜的一类操作。辛辛苦苦合并完，攒了半年的信号迁移，一撤跳转全断。撤跳转唯一合理的场景是这个地址已经很久没有任何请求了，而这件事需要查日志确认，不能靠感觉。

内容怎么并

不是简单地把两篇拼起来。正确的做法是先列出两边的大纲，去掉重复的部分，把保留页缺的那几节补进去，然后重新调整一遍顺序。

旧内容怎么翻新，12步实战。

拼起来的页面会很长而且逻辑断裂，用户读得出来。合并的目标是一个更好的页面，不是一个更长的页面。

判断有没有并好，有个简单办法：把合并后的页面通读一遍，看有没有哪两段在说同一件事。有，就说明只是拼在了一起。真正并好的页面读起来应该像一开始就是这么写的。

还有一个容易忽略的：标题也要重新想。两个页面各有一个标题，合并后不能简单选一个，因为新页面覆盖的范围比原来任何一个都大。标题不改，等于用一个更窄的说法去承接一个更宽的内容。

合并之后页面变得很长怎么办

这是常见结果，两篇各三千字，并完六千字。太长会影响读完率，但直接删内容又可惜。

长内容怎么排，7种结构化格式。

可行的做法是把合并后的页面重新分层：主线保留在页面上，那些只有少数人需要的细节部分抽出来做成折叠区块，或者干脆拆成一个更专门的子页面——注意这里的拆和之前的重复不是一回事，这次拆出去的是明确更窄的一个话题，有自己的独立角度。

拆的时候记得从主页面链过去，并且在子页面回链。合并加拆分听起来矛盾，其实是同一件事的两步：先把散的收拢，再按合理的边界重新切开。

区别在于切的依据。原来那种重复是按“谁建的、什么时候建的”这类偶然因素切开的；重新拆是按话题的实际边界切。同样是两个页面，一个是历史遗留，一个是设计结果，它们在数据上的表现会完全不同。

怎么确认拆得对不对？拆完之后看两个页面各自能不能拿到自己那一簇查询。能，说明边界找对了；如果子页面拿不到任何独立查询，那它其实不该被拆出来，应该作为主页面里的一节存在。观察周期同样是四到八周，跟合并一样。

跳转怎么做

被合并的网址做永久跳转指向保留页。别用软跳转，别直接删掉返回错误码，也别只在页面上放个链接说“已搬家”。

跳转配置抄这份，多域名跳主域实战。

跳转做完之后还有两件事经常被忘：把站内所有指向旧网址的内链改掉，把站点地图里的旧网址去掉。不改内链，你就在持续地给一个跳转喂流量；不改站点地图，你就在持续地告诉引擎这个已经作废的网址还很重要。

转化路径要单独检查

这一条是电商站特有的。两个页面可能挂着不同的营销活动、不同的推荐位、不同的加购按钮配置。合并之后，被去掉的那个页面上的这些东西，得有地方接。

落地页那一侧，30个A/B测试方案。

最常见的翻车是：某个广告投放的落地页正好是被合并掉的那个，跳转虽然没断，但落地页的内容跟广告文案对不上了，转化直接掉。合并之前先查一遍有没有付费流量指向它，是个五分钟能做完但经常被跳过的动作。

合并之后多久看效果

四到八周。前两周通常会有一段波动，甚至短暂下降，这是正常的。在两周内因为数据难看而把合并回滚，是最糟糕的操作，因为你会同时承担合并和回滚两次的成本。

抓取报告怎么读，五类问题URL的排查顺序。

为什么前两周一定会掉

因为跳转生效需要时间：引擎要重新抓取旧网址、发现跳转、更新映射、把信号迁过去。这个过程中，旧网址已经不返回内容了，新网址还没继承到信号，中间有一段真空。

分层索引那套，Base还是Landfill也影响恢复速度。

这段真空的长度取决于旧网址被抓取的频率。被抓得勤的页面恢复得快，冷门页面可能要一两个月。所以合并的时候，先合那些流量大的、被抓得勤的，恢复周期短，也更容易看出效果。

合并做完要通知谁

至少三方。投放那边，确认没有广告落地页指向被合并的网址。内容那边，让他们知道以后写这个话题该链哪一页。数据那边，在报表里标一个断点，否则下个月做同比的时候没人说得清为什么某个页面的数据翻倍了。

跨部门怎么打招呼，协作7动作。

第三条最容易漏，后果也最长久。一次没标记的合并，会在之后一年里持续制造无法解释的数据跳变，而每一次跳变都要有人花时间去查。

一次合并多少组合适

建议一批不超过二十组，而且同一批里最好是相似的类型。分批做的好处是出了问题好定位——一批二十组，如果数据不对，排查范围是二十个；一次性合了两百组，你根本不知道该从哪查起。

点了不等于复核，验证修复在验什么。

批次之间隔两周，等上一批的数据稳定了再动下一批。一个五百组的站，这样做要半年。听起来慢，但它是唯一一种每一步都可回滚的做法。

什么情况下不该合并

三种。一是被合并的那个页面上有活跃的付费流量，且落地页内容和广告文案强绑定；二是两个页面服务的是不同市场或者不同语言；三是其中一个页面正在被大量外部站点引用，而它的内容跟保留页并不完全等同。

有付费流量要先对齐，联盟客那一课。

第三种最容易被忽略。一个被很多人引用的页面，它的价值不只在于内容，还在于它是一个稳定的地址。合并它意味着所有那些引用都要多走一跳，而且引用它的人当初引的是那个具体说法，未必是保留页上的版本。

还有第四种，比前三种更常见但更少被提起：两个页面的转化率差别很大，而你不知道为什么。这时候合并等于用一个未经验证的假设去覆盖一个已经在跑的结果。

正确的做法是先搞清楚差别从哪来——是流量来源不同、页面结构不同、还是商品陈列不同。搞清楚之后再决定：如果差别来自可复制的东西，把它复制到保留页上再合并；如果来自流量结构，那这两个页面服务的可能本来就是不同的人。

合并之前的最后一道自问

动手之前问一句：如果三个月后有人问我为什么合并了这两个页面，我能不能用一句话说清楚。说不清楚的，先别动。

这个自问能挡住相当一部分“看着重复所以合了”的操作。重复是一个观察，不是一个理由；理由必须是合并之后会变好，而且能说出好在哪。观察和理由之间隔着一次判断，而这次判断经常被省略掉，因为观察本身看起来已经足够有说服力了。

反过来，那些能一句话说清楚的合并，做起来也顺——因为理由本身就指明了该保留哪一个、该搬走哪些内容、以及合完之后该看什么数据。说不清理由的时候，通常是判断还没做完，不是执行还没开始。

本次数据里那2390组，如果真要一组组问这句话，能一句话说清楚的可能只有序号型那六成。剩下的四成，多数需要先弄明白它们各自在做什么。这也是为什么我一直建议从序号型开始。

一套可以直接跑的自查动作

最后把这一整篇压成能执行的东西。

三十分钟版本

下载你的站点地图，把所有网址导进表格。用公式把每个网址的最后一段取出来，替换掉连字符，转小写。然后排序，肉眼扫一遍相邻的行。

网址处理的小工具，编解码与乱码还原。

相邻的行长得几乎一样的，就是重复组。这个土办法能找出序号型和增减词型，也就是本次数据里的八成。词序型找不出来，那得靠脚本。

三十分钟版本能查出多少

按本次数据的形态分布，排序扫一遍能覆盖序号型的61.9% 和增减词型的19.2%，合计八成。剩下的词序型和其他类型，排序之后不会相邻，肉眼扫不出来。

批量查这类问题，检测分类到提交一条龙。

八成对第一次做的人来说完全够了。先把这八成看见，比一次做到位重要得多——因为这八成里就已经包含了那些一件商品五个网址的极端情况，处理完之后你对自己站的状况会有一个完全不同的认识。

而且这个土办法有个额外的好处：因为要用眼睛扫，你会顺带看到很多别的东西——命名不一致的地方、路径结构混乱的段落、以及一些你完全不记得建过的页面。自动化脚本只会报它被要求报的东西，人扫一遍能看见的比那多得多。

两小时版本

写个脚本做词集指纹，就是我这次用的逻辑：取末段、切词、去停用词、单复数还原、排序、拼指纹。注意保留数字，只处理结尾的孤立序号。

脚本自己写也不难，用Claude Code做报表。

跑完之后按组数排序，先看最大的那几组。一个站的重复问题通常高度集中，处理掉最大的十组，能解决一半的量。

常态化版本

把词集指纹这套逻辑接进内容发布流程，新建页面时自动比一次，命中就提示。这是一次性投入，之后不需要再做审计。

接进流程里，自动化运维一条龙。

盘点表该有哪几列

表怎么设计，从指标体系到异常诊断。

处理顺序建议

先处理序号型，因为它量最大且能批量做；再处理年份型，因为它判断简单；然后是增减词型，需要逐组看；最后才是词序型和其他，它们量小但每一组都要判断。

先做便宜的，按性价比排序的清单。

做完之后该盯什么

盯两个数：站点地图里的网址总数，和重复组的数量。前者应该在清理后下降然后平稳增长，后者应该降到低位并且不再涨。如果重复组数量在清理之后又开始涨，说明生产流程里的那个源头没堵上，审计做多少次都是白做。

监控要多源，5步SOP与替代方案。

源头通常在哪几个地方

按本次数据反推，源头集中在三处。第一处是商品重新上架的流程：下架再上架时系统自动加序号。堵法是在上架逻辑里加一步，检查这个名字的历史网址，能复用就复用。

换基建要重搭，sitemap与重定向自己来。

第二处是多人协作建页：没有命名约定，也没有重名检查。堵法是发布前的词集比对提示。第三处是模板批量生成：没有商品数下限，也没有撞词检查。堵法是在生成条件里加两个判断。

三处堵法的共同点是它们都在生产环节，不在治理环节。这也是我做完这批数据最强的一个体会：重复不是清理不够勤，是生产没设闸。清理是把水舀出去，设闸才是把龙头关小。

一份可以照抄的检查清单

1. 下载全量站点地图，索引文件展开一层
2. 取每个网址的末段，切词、去停用词、单复数还原、排序，生成指纹
3. 数字一律保留，只删结尾孤立的短序号和年份，五位以上整条排除
4. 指纹相同但原串不同的，归为一组
5. 随机抽二十组人工确认，重点看最不像重复的那几组
6. 按形态分类，序号型走批量，其余逐组判断
7. 合并前查一遍有没有付费流量指向
8. 跳转、改内链、清站点地图，三件一起做
9. 把这套逻辑接进发布流程，做成事前提示
10. 每季度重跑一次，只看重复组数量的变化

做完第一轮之后的常见反应

多数人的第一反应是“怎么这么多”，第二反应是“这些页面原来还在”。这两个反应本身就说明了这件事的价值——它让一批你以为不存在的东西重新出现在视野里。

顺手也查一下体积，2MB抓取上限。

更全的一份，42步审计清单。

至于处理，不用一次做完。把清单跑出来，先处理序号型那六成，剩下的按季度慢慢消化。重要的不是一次清干净，是从此以后你知道这个数是多少，以及它是在涨还是在降。

回到最初那个问题

一个关键词值不值得单开一页？这批数据没有直接回答它，但它把这个问题往前推了一步：在问“要不要多开一页”之前，先问“我现在有几页在做这件事”。

选题从哪开始，先挖词再定题。

87.4% 的站里，这个问题的答案不是零。而只要它不是零，前一个问题的答案就大概率是“不用开，先去把已有的那几页理清楚”。

这两个问题的成本差得很远。开一页要写内容、配图、排期、上线、进导航；查一次已有的重复，一份站点地图加二十行脚本，半小时出结果。用半小时的动作，去挡住一次几天的投入，这笔账在任何时候都划算。

最后留一句

做完这批数据我最大的感受不是“重复真多”，而是这些重复几乎全部是流程的自然产出，没有一个是因为谁不认真。系统在网址冲突时自动加序号，是为了不让上架失败；两个人给同一件商品起了不同的名字，是因为没人告诉他们该叫什么；模板铺了两千页，是因为它本来就该铺。

少生成一页也是收益，从页面碳足迹到抓取经济。

每一步都合理，合起来产生了一个没人想要的结果。这类问题不能靠更努力来解决，只能靠在某个环节加一道便宜的检查。本文里所有的方法，说到底都是在找那道检查该加在哪。

常见问题解答

词集完全相同的两个网址，一定是重复吗？

不一定。本次抽样里大约有一成半属于合理组合，最常见的是一个品类页加一篇同话题的博客文章，两者面向的用户阶段不同。判断方法是比大纲：新页面有三条以上老页面没有的实质内容，就该留。

两个标记能不能同用，9种场景怎么判断。

结尾带 -1、-2的网址可以直接批量跳转吗？

基本可以，但要先查两件事：这些网址各自的当前状态码和商品在售状态，以及有没有付费流量正指向它们。前者决定保留哪一个，后者决定动手之前要不要先跟投放的人打个招呼。

规则写在哪一层，6层综合治理。

合并之后排名没涨，是不是白做了？

合并的主要价值是止损和让数据可读，不是提升排名。它解决的是抓取被分散、内链信号被劈开、报表数据被拆成几份这些问题。如果原来的重复页面本来就没什么流量，合并之后自然也不会凭空多出来。

数字不好看怎么讲，8维度的说法。

一个词值得单开一页的最低标准是什么？

三条同时满足：它能带来一组和现有页面区别得开的查询；你能写出至少三条现有页面没有的实质内容，每条撑得起三百字；站点结构里有它的位置，有上级页面和内链能指过去。电商品类页还要再加一条：至少八件商品。

一页吃一簇词，怎么布局。

没有工具能看搜索结果重合度，怎么办？

用后台的查询报表反推：把这两个词各自带来展示的页面列出来，看是不是同一批。是同一批，说明引擎在用同一批页面回应这两个词，等价于高重合度。这个信号来自你自己的数据，比抓取搜索结果稳定。

后台数据怎么读，从配置到诊断。

跨地区站的同话题页面要不要合并？

不要。它们是不同市场的版本，正确的处理是让它们互相声明语言地区关系。需要判断的是同一个市场内部的重复，比如英国站既有博客又有品类页盯着同一簇词。

关系怎么声明，return tags与x-default。

模板化生成的页面算不算重复？

取决于每一页有没有独立的内容和足够的支撑。品类乘颜色乘尺码这类组合页，多数情况下只有前几层值得独立成页，越往下越应该做成筛选条件。判断的锚点是商品数和内容差异，不是词的搜索量。

变体的三层治理，Schema、canonical与URL。

发布前的重名检查具体怎么实现？

逻辑就是本文用的那套：把新页面的标题或者拟定网址拆成词、去停用词、单复数还原、排序拼成指纹，跟已有页面的指纹表比一次。命中就提示，不强制拦截。

不同页面类型怎么配，5类页面的差异。

指纹表可以在每晚从站点地图重建一次，几秒钟的事。提示而不拦截，是因为确实存在合理的同词集组合，强制拦截会挡住正常业务，几次之后就会有人来要求关掉这个功能。

清理之后网址总数下降，会不会影响收录量？

收录量会降，这是预期内的，因为被合并的那些网址本来就不该单独占一条记录。要看的不是收录总数，而是有流量的页面数——这个数在清理之后应该持平或者上升。用收录总数考核SEO，本身就会激励制造重复。

用什么当考核指标，实测数据参照。

词集判据会不会漏掉最重要的那类重复？

会。它只认用词层面的重复，说的是一件事但用词完全不同的那类完全看不见，而那类往往是最值得处理的——比如一篇叫“怎么挑登山包”的文章和一篇叫“背包选购指南”的文章。要抓这一类，得比内容或者比查询覆盖，成本高得多。所以这套方法的定位是低成本的第一道筛，不是全部。

语义层面的判断，从关键词到意图理解。

这批数据能代表所有电商站吗？

不能，它有三个明确的偏差。样本偏向欧美中大型DTC与电商品牌，用同一类建站平台的占比很高；只看了站点地图里的网址，没进站点地图的重复页面完全没被统计；判据只认用词层面的重复，说的是一件事但用词不同的那类全部漏掉了。这三条都让数字偏保守。

同一批数据的另一面，品牌词那条线怎么画的。

权威参考资料