站内搜索页实测40个电商站：查无结果和查得到长得一模一样

摘要：给40个电商站的站内搜索页各发两次请求，一次搜一个它肯定有的词，一次搜一串随手敲出来的乱码。26个能正常返回的站里，有12个两次拿回的页面几乎一模一样，字节数差不到百分之一；还有8个把所有查询都指向同一个规范地址，2个直接指向首页。

先讲这次实测怎么做的，因为方法比结论更值得抄。

每个站发两次请求。第一次搜sale这个词，几乎所有电商站都有促销相关的东西，这一次代表查得到；第二次搜qzxjvwmk，一串随手敲的字母，任何站都不可能有，这一次代表查不到。然后把两次拿回来的东西并排比：状态码、字节数、标题、规范地址、有没有禁止收录的标记。

这个设计的全部意义在于第二次请求。只看第一次，你会觉得每个站的搜索功能都挺正常；加上第二次，才能看出这一页对结果有没有反应。而AI引荐把人送过来的时候，送到的往往就是第二次那种状态。

这次实测是怎么设计的，你要复现该注意什么？

方法先交代清楚，后面的数字才有意义。

为什么必须用两个词而不是一个

只搜一个真实的词，你能验证的只有搜索功能通不通。加上一个必然无结果的词，才能看出这一页对结果有没有反应。这个设计的原理跟做实验时加一个已知无效的对照组是一回事：没有对照，任何结果看起来都正常。

对照这件事在转化测试里是标配，三十个可直接抄的测试方案里几乎每一个都配着对照组，思路完全一致。

假词该怎么选

真实的查询词是另一座金矿，站内搜索数据怎么挖关键词那篇讲的是怎么把它变成选词依据。

还有一条：假词最好每次实测都换一串新的。用同一串太久，它可能已经被别人搜过、被记进了热门查询、甚至生成了缓存页。

真词该怎么选

选一个几乎所有同类站都有的通用词，别选品类词。品类词在不同站的覆盖差别太大，比如你搜袜子，做鞋的站有、做床垫的站没有，那这次对比就变成了在比商品结构，不是在比页面行为。

选词按意图分层比按热度排序有用，洋葱式分层的实战方法可以直接套到站内搜索上。

要记录哪几项

禁止收录标记和规范地址能不能同时用，九种场景的判断方法那篇给了一张对照表。

六项里最容易漏的是最后一行。有八个站的禁止收录标记不在页面上，而在响应头里，只看页面源码会以为它们什么都没做。

复现时会遇到的三个障碍

第一是防护系统，陌生请求容易被拦，这次40个站里有9个是这么丢掉的。第二是地区差异，很多站会按访问来源跳到不同的区域版本，这次有两个站被跳到了非英文站点。第三是搜索路径不统一，各家写法差别很大，得先确认路径再批量跑。

被拦和打不开有时是同一类问题，从域名解析到内容分发的排障顺序可以借来排查。

这三个障碍本身也是数据。一个连正常请求都要拦的站，模型的取回器同样会被拦；一个会按地区跳转的站，模型看到的可能是另一个国家的版本。

一个查不到东西的搜索页，跟查得到的到底差在哪？

先看总账。

40个站里能拿到真实页面的有26个

这类批量检查最容易撞上共性问题，十二类高频坑的诊断清单可以当一份对照表用。

被挡下的那9个本身也是个信息：这些站对来路不明的请求相当敏感，而AI客户端在取回页面的时候，用的恰恰是这类来路不明的请求。这一点后面还会提到。

26个站里，12个的两次响应几乎一模一样

抓取和渲染分几步走，直接决定这一页对机器可不可见，这条链路的完整拆解值得先读。

字节数一样意味着什么

意味着服务器在这两次请求里做的事完全相同：它返回了一个页面框架，至于框架里该填什么，交给浏览器里的脚本去问接口。对于任何不执行脚本、或者只看服务端返回内容的东西来说，这两个页面就是同一个页面。

脚本接管页面之后的抓取影响有一整类，八类影响的实战分析里能找到对应场景。

那几个字节的差别是哪来的？多半是页面里嵌了一份查询词的副本，或者某个时间戳。差107个字节的那个站，我核对过，就是查询词本身的长度差异带来的。

还有14个站是服务端就分开的

类目页的渲染方式同样影响收录，集合页机制与冷启动那篇讲过两种实现的差别。

这一类的搜索页在服务端就把结果渲染好了，所以查得到的时候页面明显更大。它们的搜索结果页是有内容的，任何取回它的东西都能看到那些商品。这是两种截然不同的实现方式，而它们在浏览器里看起来完全一样。

把26个站按这两个维度分成四类

分层看问题比逐条列问题清楚，技术体检该覆盖哪五层给了一个可复用的分层法。

第三类为空这件事本身有意思：如果结果是脚本填进去的，那么标题通常也是脚本改的，服务端返回的初始标题里自然写不出结果数量。两个特征是绑在一起的，不是两件独立的事。

第四类那12个站的实际后果

它们的搜索页对任何不执行脚本的东西来说，都是同一个页面。这意味着：搜索引擎抓到的是空壳（多数站已经用禁止收录规避了这个问题）、社交平台的预览抓到的是通用信息、模型的取回器拿到的可能也是一样的东西。

语义化标签到底影响不影响提取，拿样本页跑一遍的实测给出了可验证的答案。

而这一切都不影响真人打开它，因为真人的浏览器会执行脚本。于是这个问题在内部完全暴露不出来——所有人打开都是好的，只有机器看到的是空的。

怎么在三十秒内确认自己属于哪一类

在浏览器里打开自己的搜索结果页，右键查看网页源代码（注意不是检查元素，那是渲染后的结果），在源码里搜一下页面上显示的某个商品名。搜得到，你是前两类；搜不到，你是第四类。

想一次查清页面被什么挡在索引外，可索引性一键体检怎么用那篇给了具体工具与读法。

查看源代码和检查元素这两个功能看起来差不多，但它们展示的是两个完全不同的东西：一个是服务器给你的，一个是浏览器加工完的。机器多数时候只看得到前者。

顺便记一个反直觉的数据

有两个站的情况是反的：查不到东西的时候页面反而更大。原因是它们在没有结果的时候会推荐一大堆热门商品，而有结果的时候只显示匹配到的那几个。这个做法本身没错，但它让页面大小这个指标失去了判断力——所以这次实测才必须同时看标题和规范地址，不能只看字节数。

停留和跳出这两个指标同样反直觉，它们到底影不影响排名那篇做过一次拆解。

为什么会有将近三成的AI引荐落在这一页？

把镜头拉回来，说说这件事为什么值得花时间。

先看几组被反复引用的数字

今年有几份行业分析给出了同一个方向的结构：模型引用的网址里六成以上位于站点深处，而实际点进来的人接近六成落在首页。那份基于六百多万次AI引荐会话的分析还给出了一个更具体的数字：将近三成的引荐落在了站内搜索结果页上，作者把它称为整批数据里最容易被忽略的一条。

用户行为在AI结果页上确实变了，八百多万次会话的实测给了停留与滚动的具体变化。

顺带一提，同一时期关于AI可见度该测什么的讨论提醒了另一件事：这类数据在多数后台里本来就是残缺的，能看到落地页已经算幸运。所以下面的建议都不依赖精确的量，只依赖有没有量这个判断。

三成这个数字之所以刺眼，是因为这一页在多数公司里没有主人。它不属于内容团队，不属于设计团队，也很少出现在任何一份优化清单里，因为在过去它根本不是一个入口。

为什么模型会给出这样的链接

几种情况都可能：它引用的原始网址本身就是一个带查询参数的搜索页；它在回答里给的是一个它自己拼出来的地址；或者站点的某个中间层把用户的问题转成了一次站内搜索。不管哪一种，结果是一样的——人带着一个具体问题过来，落在了一个连自己有没有答案都不确定的页面上。

地址怎么写才容易被正确引用，四家模型对照实测出的五条原则有直接结论。

还有一种情况：地址是模型自己拼的

这一点值得单独说，因为它决定了你能不能防。模型在回答里给链接，来源有两种：一种是它检索到的真实网址，另一种是它根据站点结构规律自己拼出来的。后一种拼错的概率不低，而拼错的结果往往落在搜索页或者404页上。

你没法阻止它拼，但你可以让拼错的结果不那么难看。这也是为什么本文一直在强调无结果页和404页的呈现——它们是所有猜错地址的共同终点。

怎么判断自己遇到的是哪一种

第四行是最容易发现的一种：一个格式完全正确、只是内容不存在的地址，人是编不出来的，只有按规律生成才会长这样。把404日志按这个特征筛一遍，通常能捞出一批。

这批人有多少，值得为他们改吗

先泼盆冷水：目前AI引荐在多数站的流量里占比很小。有研究给出的点击率是百分之一量级——人在对话里拿到答案，多数不会点开来源。所以如果你指望这是一条新的大流量渠道，短期内会失望。

代理替用户逛店下单之后，可见与被选是两件事，这个盲区怎么补单独写过。

但有两组数字让这件事没法被简单忽略。一是增速，有平台在一次链接展示方式调整后的一周内，引荐量涨了一倍多；二是质量，有工具站披露过，AI来的访客只占其流量的半个百分点，却贡献了超过一成的注册。量小、密度高、增速不稳定，这三个特征凑在一起，对应的正确策略不是重仓，是低成本占位。

还有一个判断是否值得做的角度

看这件事的失败成本。改标题、改无结果页，就算AI引荐一直没起来，这些改动对站内搜索的老用户同样有效，失败成本接近零。反过来，为这条路径重做一套页面、买一套监测，如果路径没起来，这笔投入就打了水漂。在不确定性高的方向上，优先做那些失败了也不亏的动作。

低成本占位具体指什么

同时照顾人和机器的转化设计，四个策略的实战拆解给了可以立刻用的动作。

左边三件事的共同点是：就算AI引荐这条路径明天消失了，它们对别的渠道依然有效。这是判断该不该做的最好标准——一个动作只在某个新渠道成立时才有价值，那它的风险就跟那个渠道绑死了。

这跟从搜索引擎过来完全不同

意图和落地页对不上是老问题，看结果页决定落地页怎么改的七步可以直接照做。

前两类的落地页都是有人负责的，第三类不是。这就是这件事的全部麻烦：意图最明确的那批人，落在了控制力最弱的那个页面上。

这批站的搜索路径写法有多不统一

参数怎么处理决定了地址会不会爆炸，五类参数的处理对比是这类问题的入门底子。

不统一本身没问题，但它带来一个实际后果：如果模型试图自己拼一个搜索地址给用户，它拼错的概率相当高。拼错的结果通常是一个空结果页或者404，而用户不会知道是地址错了，他只会觉得这个站没有他要的东西。

把查询词写进路径的那四个站

这种写法有个额外的好处：地址看起来像一个正经页面，被引用和被分享时更体面。代价是加筛选条件的时候要么再拼参数、要么继续往路径里塞，长了会很难看。

地址结构该扁平还是层级，一万个站的实测结论给了一个反直觉的答案。

如果你的站内搜索承担了相当一部分入口作用，这种写法值得考虑，因为它让每个查询都有一个像样的身份。反过来，如果搜索只是站内工具，那用标准参数最省事。

这批站的响应速度差得也很远

弱网和低端机上的差距会被放大好几倍，移动端性能优化的实战顺序值得对照一遍。

有个现象值得记：查得到的时候普遍比查不到的时候慢，个别站慢出好几倍。这符合直觉——有结果就要渲染更多东西。但它也意味着，一个真正带着需求来的人，等待时间反而更长。

那个16秒的站，页面有370万字节，是这批样本里最大的一个。一个搜索结果页做到3.7兆字节，多数内容其实是脚本和样式，跟用户搜的东西没关系。

顺手把这批站的其他细节也记一下

做这类批量检查，附带收获通常比主目标还多。这次顺手看到的几件事：有三个站的搜索页在非英文地区被自动跳到了另一个语种版本，而查询词在跳转过程中丢了；有两个站的搜索页缺少移动端适配的声明标签；还有一个站的搜索结果里，每个商品链接都带着一串追踪参数，等于给自己制造了一批重复地址。

这三件事都跟本文主题无关，但它们的共同点是：只有在从外部、以陌生访客身份访问时才会暴露。团队内部的人永远看不到，因为他们的地区、设备和登录状态都不一样。

还有一件事值得先说清楚

这次实测只发了两次请求，没有登录、没有带任何用户状态。这意味着测到的是一个陌生访客第一次到达时看到的东西——而这恰好就是从AI回答里点进来的人所处的状态。你自己在后台看到的搜索页，和一个陌生人第一次看到的，可能是两个页面。

陌生访客第一次到达时看的是信任，七层信任怎么落地那篇拆得比较细。

那12个站的两次响应为什么会一模一样？

回到实测。这一节讲机制。

页面在哪一层被组装，决定了它对谁可见

如果搜索结果是服务端拼好的，那么任何发起请求的东西都能拿到内容；如果结果是浏览器里的脚本请求接口再填进去的，那么只有会执行脚本的客户端才看得到。而爬虫、模型的取回器、各种预览工具，执行脚本的能力参差不齐，很多干脆不执行。

三种渲染模式下的引用率差多少，这份实测直接给了对照数据。

这带来三个具体后果

单页应用被跳过是常见现象，四种渲染模式与段落级诊断能帮你定位卡在哪一层。

为什么这么多站选择了脚本渲染

不是偷懒，是有实际理由的。搜索结果需要实时查库、需要支持筛选和排序、需要在用户改条件时立刻更新，这些都是脚本渲染擅长的场景。服务端每次都渲染一遍完整结果，成本更高，缓存也更难做。

前后端分离之后有一整套基建要自己重搭，这份清单列了容易漏掉的几项。

所以这不是一道对错题，是一道取舍题。取舍的关键在于：这一页有没有外部访客直接落地。只有站内工具属性时，脚本渲染完全合理；一旦它开始承接外部流量，服务端至少要能说清楚这一页是什么、有没有结果。

折中方案长什么样

模板层的改动通常最划算，十二步把产品页分类页配齐里有不少可直接套用的改法。

第一行的成本通常只是在模板里多输出一行，却能让这一页从一片空白变成一句明确的话。如果只能做一件事，就做第一行。

顺带说说缓存这件事

搜索页因为查询词无穷多，通常不做缓存。但高频查询词其实很集中，前二十个词往往覆盖一半以上的搜索量。把这批词的结果页缓存起来，既省服务端开销，又让这几页有条件做成服务端渲染。用二八分布去解决全量渲染的成本问题，是这类页面最实际的一条路。

缓存策略该怎么定，八维决策树与规则迁移实战给了一套能落地的判断顺序。

那个只有10个字节的404

26个站里有一个的搜索路径直接返回404，而且响应体只有10个字节。这大概是全站最诚实的一个页面：它明确告诉你这里没有东西，而且不浪费任何一个字节。

死链该怎么批量查、怎么分类，从检测到提交的一条龙可以直接用起来。

从纯技术角度这没问题，但从访客角度这是最糟的一种——一个从AI回答里点进来的人，看到的是浏览器的默认错误页，连品牌名都看不到。诚实和有用是两回事。

还有一个1.16兆字节的404

另一个站的搜索路径同样返回404，但响应体有1166117个字节。这一页做得很漂亮：有导航、有推荐、有品牌视觉，唯一的问题是它的状态码在告诉所有机器这一页不存在。

状态码怎么选影响的是机器的判断，三百零一与四百一十的选择依据那篇讲得很清楚。

状态码和页面内容说着两句不一样的话，这是这次实测里最常见的一种自相矛盾。机器信状态码，人信页面内容，于是同一页在两边得到完全相反的评价。

规范地址那一栏，为什么八个站把所有查询指向了同一个网址？

这一节是本次实测最值得记的一个发现。

先说这个标签是干什么的

规范地址的作用是告诉搜索引擎：这一页的正式地址是哪个。当同一份内容有多个网址能访问到时，用它指认唯一的那一个。

这个标签的跨页场景比想象中复杂，八种场景与冲突诊断能避开大部分误用。

八个站的写法是这样的

无论你搜什么词，页面里的规范地址永远写的是不带查询参数的那个搜索路径。也就是说，搜羊毛袜和搜qzxjvwmk这两个页面，对搜索引擎宣称自己是同一个页面。

它是提示不是命令这件事很多人不知道，八种误用里第一条说的就是这个。

这个做法对不对

从避免重复内容的角度，它是标准做法之一，很多平台的默认模板就这么写。但它的副作用是：这一整类页面在搜索引擎眼里坍缩成了一个地址，任何一个具体查询的表现都无法被单独衡量。

筛选生成的地址要不要屏蔽，三类判别法给了一个不必一刀切的处理策略。

如果你想知道哪些站内查询正在带来访问、哪些查询下的页面需要改，这个写法会让你彻底失去这条线索。

还有两个站更彻底

它们的搜索页把规范地址直接指向了网站首页。翻译成人话就是：不管你搜什么，这一页告诉搜索引擎，我其实是首页。

同一页冒出两个规范地址是常见故障，怎么把它们归一那篇有排查顺序。

这个写法在早年是一种偷懒的防重复手段，今天基本没有理由再这么做。它的直接后果是这一整类页面在搜索侧完全消失，同时也把你自己观察它们的可能性一并抹掉了。

坍缩到一个地址之后，你失去了什么

想按类型看表现，先得让页面有各自的身份，内容分组怎么配是配套的一步。

这四条里最可惜的是最后一条。模型给出的那个链接里通常带着查询词，那是它对用户问题的一次翻译——它认为用你站上的这个词去搜，能找到答案。这条信息价值极高，而规范地址一坍缩，它在你的分析工具里就消失了。

但也别急着把它改掉

规范地址的写法牵扯到索引策略，改之前得想清楚整体方案。真正低成本的替代方案是：规范地址先不动，但在日志或者分析工具里按完整地址统计，把查询参数留下来。这样既不影响索引策略，又保住了那条线索。

改索引策略之前要先算清膨胀风险，诊断与处置的决策矩阵可以当前置检查。

剩下那八个是怎么写的

它们把规范地址写成了带查询词的自身地址，同时配上禁止收录的标记。这是目前看起来最合理的一种组合：不进索引，但保留每个查询各自的身份，方便自己在日志和分析工具里区分。

这一页到底该不该被屏蔽，四种方案的对比把各自的代价都列出来了。

把状态写进标题的站，为什么只有四个？

这一节讲一个成本极低、却很少有人做的动作。

四个站的标题长这样

它们的搜索结果页标题里直接写了结果数量：搜到27个结果、搜到8个结果，或者搜到0个结果。查得到和查不到，光看标题就能分辨。

标题怎么写是老话题但一直有人写错，这份写法清单可以对照着改模板。

为什么只有四个站做了这件事

猜测有两层原因。一是历史包袱：搜索页的标题多数是建站平台的默认值，没人想过要改。二是它不在任何一份优化清单里——检查标题的清单通常只覆盖首页、分类页和商品页，搜索页因为不进索引，被自动排除在检查范围之外。

不进索引这个理由在过去成立，现在不成立了。标题的作用早就不只是给搜索引擎看，它还是分享预览的名字、浏览器标签页上的字，以及机器判断这一页是什么的第一条线索。

这件事为什么重要

标题是这一页最先被读到、也最容易被机器提取的部分。把状态写进标题，等于给所有取回这一页的东西发了一份明确声明。对模型来说，一个标题写着0个结果的页面，和一个标题只写着搜索的页面，能给出的判断完全不同。

让人一眼看懂比让人好奇更重要，标题写法那篇举了不少正反例子。

对人也一样。浏览器标签页上直接显示0个结果，用户不用等页面加载完就知道该换个词了。

标题里该写什么，有一个可以直接抄的格式

搜到结果的时候：查询词加结果数量加品牌名。搜不到的时候：明确写出没有找到匹配这个词的结果。两句话都不长，模板里改一次就永久生效。

模板级的改动收益最大，二十个进阶策略里有好几条都是一次改动长期生效。

第三行是个容易漏的边界：有人会访问不带查询词的搜索地址，这时候页面该显示什么，多数站没想过。实测里就有站在这种情况下直接返回了404。

剩下的站标题是什么样

变体页的标题与规范地址同样容易乱，三层治理实战那篇给了完整方案。

最后一行那三个站，服务端返回的页面连标题都是空的。如果有一个模型取回了这一页，它拿到的是一份没有标题、没有内容、只有脚本的文档。

一个不存在的词，怎么会进了标题？

有一个案例值得单独拎出来。

实测里发生的事

某综合电商平台，用那串乱码去搜，页面正常返回200，标题是平台名加上那串乱码，页面里没有任何禁止收录的标记。换句话说，我给它一个胡编的字符串，它就生成了一个以这个字符串命名的、可以被收录的页面。

批量生成的页面被清零是有先例的，那次五百多万页面的教训值得当反面参照。

这类页面为什么危险

因为它可以被批量制造。任何人都能构造无数个查询地址，每一个都会生成一个新的、看起来独立的页面。这就是索引膨胀最经典的成因之一，也是搜索引擎一直建议屏蔽站内搜索结果页的原因。

地址爆炸最典型的成因就是筛选器，系统方案八步能把抓取陷阱堵住。

把乱码写进标题还有一个下游后果

这一页如果被分享出去，社交平台的预览卡片上会显示那串乱码；如果被某个聚合站抓走，标题里也是那串乱码。页面标题不只是给搜索引擎看的，它是这一页在所有外部场景里的名字。

页面上反射出的用户输入是安全问题的入口，七步攻防那篇讲的是同一类风险。

更麻烦的是这类地址可以被恶意构造。有人拿你的搜索地址加上一句难听的话，做成链接发出去，打开就是你的品牌名加那句话。这类玩法在早年很常见，防住它的办法就是别把查询词原样写进标题，或者至少做转义与长度限制。

顺手检查三件事

预发布环境被收录也是这类没人管的问题，八步清除与四层防御可以照着做。

三项都过，说明这一页至少是安全的。这些检查跟SEO没直接关系，但它们跟搜索页一样，都属于没人认领的那一类问题。

这个站为什么还这么做

猜测是历史与体量的问题。这类超大平台有自己的一套处理方式，也承担得起一定程度的冗余。但对中小站来说，照抄大平台的做法是最危险的一类学习——它们能扛住的东西，你未必扛得住。

大平台能扛住的冗余小站扛不住，分层索引那篇解释了页面会被丢进哪一层。

顺带说说防护系统那9个站

被挡下的9个站里，有几个是直接返回429，有几个跳到了人机验证页。这说明它们的防护规则对陌生请求相当严格。

防护规则误伤爬虫是常事，拦不拦得住、会不会误伤那篇给了诊断方法。

这带来一个值得警惕的推论：如果一个模型的取回器被当成异常流量挡在门外，那么它对这一页的了解就停留在被挡下之前。它可能仍然会把这个地址给用户，而用户是浏览器，能正常打开——于是站点自己永远不会发现这件事。

屏蔽了抓取，是不是就等于不用管这一页了？

这是本文想纠正的一个最普遍的误解。

这一节先把两个词分清楚

抓取和索引是两件事，很多讨论之所以吵不出结果，是因为这两个词被混着用。抓取是机器来取这一页的内容；索引是取回之后决定要不要收进库里、能不能被搜到。一个页面可以被抓取但不被索引，也可以在没被抓取的情况下因为外部链接而被索引。

后半句听起来违反直觉，但它确实发生：搜索引擎从别的地方看到有链接指向你这一页，即使不去抓取，也可能把这个地址收进索引，只是没有内容摘要。所以指望用抓取规则来阻止收录，方向从一开始就是错的。

先看实测里的屏蔽情况

电商站到底该屏蔽哪几类页面，七类清单加平台实操可以直接核对。

这两种手段管的是同一件事吗

不是。抓取规则文件的官方说明写得很直白，它管的是要不要来取这一页；而禁止收录标记那份文档管的是取回之后要不要放进索引，里面还专门提醒了一句：如果路径被抓取规则挡住，这个标记就读不到，反而可能因为外部链接被收录。而它们共同的盲区是：都只对遵守规则的机器有效，对点开链接的真人一点约束都没有。

两者的分工经常被搞反，什么时候用哪个那篇一句话就能说清楚。

于是就出现了这样一种局面

站点用两道规则明确表示这一页不算数、不要收录、不要展示，然后有一批意图最明确的真人从AI回答里点进来，落在了这一页上。你用尽办法把它从搜索里排除掉，却没有任何一种办法把它从用户旅程里排除掉。

这套协议的边界比多数人以为的窄，写废了会发生什么是个很好的提醒。

规则能管住机器要不要看，管不住人会不会来。凡是人能点开的地址，都是你的门面，不管你在规则里怎么写。

模型的取回器算哪一类

这是一个模糊地带。各家AI产品的取回行为不完全一样：有的会读抓取规则，有的只在训练用途上读，有的在用户明确要求打开某个网址时不读——理由是这算用户的显式请求，不算自动抓取。

它们到底怎么取、取什么，从代码逆向出的真实偏好给了八步可复现的做法。

这个理由其实站得住：抓取规则约束的是自动化的批量抓取，而一个人在对话里说帮我打开这一页，背后有一个正在等结果的人。规则管不到这种情况，也不该管。

由此得到一条判据

判断一次取回要不要受抓取规则约束，看它背后有没有一个正在等结果的人。有，那它更接近浏览器；没有，那它是爬虫。这条判据比按用户代理名字去分类可靠得多，因为同一家产品的不同功能可能分属两边。

要不要拦、拦到什么程度，三层选型框架给的判据跟这条正好互补。

正确的分工应该是这样

加了标记之后多久生效，六大场景的实测能帮你安排改动节奏。

第一行有个容易踩的坑：如果你在抓取规则里屏蔽了这个路径，搜索引擎就读不到页面上的禁止收录标记，反而可能因为外部链接把它收进去。两种手段叠加使用时，顺序和组合要想清楚。

把查询直接映射到已有页面，是不是更好的答案？

实测里有两个站的做法明显不同，值得单独说。

它们做了什么

用那个真实的词去搜，请求被跳转到了一个已经存在的分类页——一个跳到了清仓专区，一个跳到了促销分类。也就是说，它们把一个高频查询词，映射成了一个自己已经维护好的页面。

把查询导向已有页面本质是内链设计，权重流动与主题集群那篇讲了背后的逻辑。

这个做法的三个好处

第一，访客拿到的是一个有人负责、内容完整的页面，而不是一个临时拼出来的结果列表。第二，这个页面本来就在索引里、有排名、有转化数据。第三，它把一次不确定的查询，变成了一次确定的到达。

把流量导向已经有排名的页面收益最快，第二页冲第一页的方法是同一种思路。

代价是什么

要维护一张映射表，而且映射错了比不映射更糟——用户搜A却被送到B，那是另一种失望。所以这个做法只适合头部那几十个高频词，长尾还是得老老实实回搜索结果。

映射错了比不映射更糟，本地化的五个翻译陷阱里有一堆映射失手的例子。

映射表该怎么维护才不会烂掉

三条规矩就够。第一，只做头部词，二三十条封顶，长尾不碰。第二，每季度回看一次，把已经不再高频的词删掉。第三，映射目标必须是长期存在的页面，别指向促销专题这类会下线的东西。

活动上下线要跟映射一起管，大促排期那份路线图把两边的节奏对齐了。

第三条最容易翻车：促销结束页面下线，映射还在，于是搜这个词的人被送到404。如果非要映射到活动页，那就在活动结束时把映射一起删掉，做成同一个上下线流程。

还有一种更轻的做法

不做跳转，只在搜索结果页顶部加一个推荐位：你搜的这个词，我们有一个专门的页面。用户可以点，也可以继续看结果。这个做法保留了用户的选择权，也避免了映射错误带来的失望，代价是多一次点击。

推荐位放在哪一层跟站点结构有关，架构该怎么搭那篇讲了深度带来的影响。

两种做法的选择标准很实际：查询词与目标页的对应关系有多确定。确定得没有歧义就跳转，稍有含糊就做推荐位。

怎么知道自己的高频词是哪些

站内搜索的查询记录是现成的第一方数据，多数电商平台后台都能导出。取前50个词，看看有多少已经有对应的分类页或者专题页，没有的排进内容计划。这份清单的价值不只是做映射，它本身就是一份用户在用自己的话告诉你他们想要什么的清单。

需求预测同样要从真实查询出发，五步选品实战可以跟站内搜索数据配合着用。

除了搜索页，还有哪些页面也在悄悄接客？

站内搜索只是最典型的一个。同一类问题还发生在另外几种页面上，特征完全一样：能被访问、有人落地、却没人负责。

带筛选参数的分类页

用户选了颜色、尺码、价格区间之后生成的那些地址，数量可以是分类数的几十倍。多数站会把它们排除在索引之外，然后就再也不管了。但这些地址一样可以被分享、被引用、被点开，而它们的标题往往还是分类页的原标题，看不出加了什么筛选。

分页和筛选是一对孪生问题，五种方案的对比与配置能一次把两边理清。

标签页与聚合页

建站系统自动生成的标签归档、按属性聚合的列表，这类页面通常内容稀薄、模板统一。它们的问题跟搜索页一样：不同的标签在页面上长得几乎一模一样，唯一的差别是列表里那几条。

分类和标签怎么分工，索引治理与着陆页打法那篇给了明确的取舍。

登录后才可见的那些页面

订单详情、收藏夹、优惠券列表这类页面，未登录时通常跳到登录页。如果模型给出的地址是其中之一，用户看到的就是一个登录框。这种情况没法完全避免，但可以做得体面一点：跳到登录页时带上原地址，登录完自动回去，而不是把人扔到账户首页。

登录墙是弃购的经典成因之一，九个真实成因与五步诊断里有具体数据。

那个谁都有、谁都不看的404页

404页在这件事里的角色被严重低估。当模型给出的是一个已经下线的地址，用户落地的就是这一页。而多数站的404页只有一句抱歉和一个回首页的链接。

改版之后的死链与跳转链最容易失控，一次揪出全站问题的做法可以定期跑。

分页深处的那些页

第七页、第十五页的商品列表，同样可以被引用和访问。它们和第一页共用一套模板，唯一区别是商品不同，而标题里往往连页码都不写。一个人从AI回答里落在第九页上，他既不知道自己在哪，也不知道前面还有八页。

集合页分页的索引判断有讲究，这份实操把规范地址那一块也说清楚了。

已下架商品的页面，是最贵的一类

模型的知识和引用都有滞后，它可能一直在拿一个你半年前下架的商品当答案。用户点进来，看到的要么是404，要么是一个还能打开却买不到的页面。

删除、合并还是跳转，四档处理的决策框架可以直接拿来判断。

四种里最不该做的是原地不动——页面还在、还能加购、下单时才报错。这类页面每天都在替你把最有购买意愿的人赶走，而它在任何报表上都不会显示为问题。

怎么一次把这几类页面都查一遍

方法跟本文开头那个实测一样：给每一类页面各造一个必然为空或者必然不存在的状态，请求一次，看它说了什么。筛选页选一个不可能有商品的条件组合，标签页用一个不存在的标签，分页直接翻到第九十九页，商品页用一个编造的编号。

四次请求，十分钟。把四次的标题、状态码和首屏内容列成一张表，你会立刻看出哪几类页面在替你说着不该说的话。

这四类页面的共同点

都是自动生成的、数量庞大的、模板统一的。模板统一意味着不管背后的数据是什么，页面说的话都一样，于是不同的意图落在这里就被压成了同一种体验。要改的从来不是某一个页面，是那套模板对状态的表达能力。

模板决定了这一类页面能说什么，六层内容矩阵那篇讲的正是模板层的内容设计。

这一页的数据该怎么看，才不会被跳出率骗了？

改之前得先看清楚，而这类页面的数据特别容易被误读。

跳出率高不一定是坏事

一个人搜到了想要的东西，点进商品页买了，这在很多统计口径里不算跳出；但如果他搜到了、看了一眼就关掉去别处比价，那算跳出。同样是跳出，一种是失败，一种只是没在这一次成交。

哪些指标只是好看，砍掉虚荣指标只盯真信号做过一次彻底的清理。

零结果的比例才是最该盯的指标

站内搜索有一个别的页面都没有的优势：它天然知道自己有没有回答上来。把零结果查询的比例拉出来看，比看跳出率有用得多。

先定框架再上工具，这个顺序反过来就白干那篇讲的就是这件事。

零结果里还要再分两类

一类是你确实没有这个东西，另一类是你有但搜不到。这两类的处理方式完全不同，混在一起看会得出错误结论。

用词对不上是语义问题，余弦相似度在商品数据上的八种用法给了量化办法。

实测里那个皮具客户属于第二类，而且是最典型的一种：商品是有的，只是商品标题里写的是材质和品名，用户搜的是用途和场景。这类问题不解决，你补再多商品也还是搜不到。

怎么快速分清这两类

取零结果词的前三十个，一个人拿着商品清单对一遍，半小时能分完。分完你大概率会发现，第二类占了大多数——因为用户的说法总是比你的商品命名丰富。

缺口分析的思路可以直接搬过来，怎么找竞争小价值高的机会讲的是同一套方法。

零结果查询词是一份免费的选品清单

用户搜了、你没有，这件事本身就是需求信号。把零结果词按频次排序，前面那些要么是你该补的商品，要么是你该补的说法。这份清单比任何关键词工具都准，因为它来自已经站在你店里的人。

选品判断需要真实需求做底，七步决策与十二周落地可以跟这份清单配着用。

搜索页的转化数据要单独看，别混进整站

从搜索框进来的人，转化率通常明显高于整站平均，因为他们已经明确知道自己要什么。如果你的搜索页转化率还低于平均，那基本可以断定这一页出了问题，而不是流量质量问题。

转化改造要分模块推进，八模块九十天的路线给了一个可执行的排期。

第二行那个对比特别值得做一次：把用过站内搜索的会话和没用过的分成两组，比较它们的转化率。多数站会发现前者高出一截，这个差值就是你继续投入改搜索的理由，也是说服别人的最好材料。

从AI来的那部分要再单独拆一次

这批人跟站内自己点搜索框的人不一样：他们是一进门就落在结果页上，没有经过首页、没有看过导航、也没有主动输入过任何东西。对他们来说，这一页既是搜索结果，又是这个站给他们的第一印象。

这批流量的转化特点跟别的不一样，落地页接不住会损失多少那篇算过这笔账。

拆开看的方法很简单：按来源筛出AI引荐，再按落地页筛出搜索路径，两个条件叠加。量通常不大，但正因为不大，你可以把每一条都点开看一眼，看看他们搜的到底是什么词。

还要看一个容易被忽略的数

搜索之后的下一步动作分布：有多少人点了结果、有多少人改了词再搜一次、有多少人直接走了。改词再搜的比例高，说明第一次的匹配没到位；直接走的比例高，说明这一页连让人再试一次的欲望都没给。

行为数据背后的心理动机，一套从数据读懂用户的研究方法比只看热图有用。

这一页到底该怎么改，才接得住从AI来的人？

把前面的发现收成一份可执行的东西。

四个动作，按性价比排

那些看不见的摩擦力最容易被漏掉，购买路径上的摩擦清单可以逐条对照。

先做哪一个，取决于你现在卡在哪

资源怎么分配得看阶段，三档投入产出框架给了一个按站点成熟度排序的方法。

最后一行是认真的。如果你的搜索页一个月只有几十次访问，那这件事的优先级应该排在很多别的事情后面。本文讲的一切都建立在这一页确实有人落地这个前提上，先验证前提，再谈动作。

改动上线前必须验的三件事

第一，用那串乱码再跑一次，看标题和内容有没有按预期变化。第二，查看网页源代码，确认改的东西在服务端返回里就存在，不是脚本后来加的。第三，用手机看一遍，因为无结果页的推荐区块在窄屏上很容易变成一长条。

上线前的防护清单越具体越好，改版不掉流量的完整清单可以直接当验收表。

三件事加起来十分钟，但跳过任何一件，改动都可能只对你自己可见。

无结果时该给什么

不是一句抱歉没有找到。至少要有三样东西：一个能改的搜索框并保留原来的词、一批相关或者热门的商品、一个明确的求助入口。这三样加起来，把一个死胡同变成了三个出口。

出错时给什么提示是同一类设计问题，别只写输入有误那篇给了改写方法。

这一页还该说清楚一件事：你是谁

从AI回答里落地的人，多数没见过你的首页、不知道你卖什么、也不确定这个站靠不靠谱。所以搜索结果页上那种站内工具式的极简设计，对他们是不够用的。至少要让品牌名、主营品类和一个能回到主线的入口出现在首屏。

这不是要把搜索页做成首页，而是承认一件事：任何一个能被外部访问的地址，都可能是某个人认识你的第一页。这句话套在本文提到的每一类页面上都成立，包括那个只有十个字节的404。

三个出口的优先次序不能反

顺序应该是：先让人知道发生了什么，再给他改的机会，最后才是推荐。反过来做——一进来先是一屏推荐商品，说明藏在下面——用户会以为这些就是搜索结果，然后对你的商品质量产生一个错误印象。

搜索框从入口到结果有四层要设计，这份拆解把每一层该做什么写清楚了。

说明必须在推荐之前，这一条没有例外。它的成本只是调整一下区块顺序，效果却是把误会挡在门外。

搜索框里该不该保留原来的词

该保留。用户改词的时候多数只想改一两个字，如果框被清空，他得重新打一遍。这个细节小到几乎没人讨论，但它直接决定了那个改词再搜的比例，而改词再搜的人是这一页唯一还留得住的人。

控件选择会悄悄吃掉转化，下拉框在表单里的代价是一个很好的类比案例。

一个真实的客户案例

保哥有个做手工皮具定制的客户，市场在欧美和日本，团队8个人，产品是钱包、卡包、表带这一类，很多款式支持刻字。他们的站内搜索用的是建站平台自带的功能，从来没人碰过。

用户带着自己的说法来，页面却只有厂商的说法，这个落差在商品页上同样存在。

去年年底他们发现，有一批访问落在搜索结果页上，而且这批访问的跳出率高得离谱。查下来原因很具体：用户搜的是刻字、定制、生日礼物这类词，而他们的商品标题里全是产品名加材质，一个字都没提这些用途。搜索匹配的是标题，于是这些词全部返回零结果。

改动分两步。第一步是给商品加上用途标签并纳入搜索范围，两天；第二步是把零结果页面改掉，加了热销商品和一个可以直接联系客服的入口，一天。三个月后，搜索页的跳出率下来一截，更实在的收益是客服那边多了一批带着明确需求的咨询。

他们是怎么发现这件事的

过程有点偶然。客服同事提了一句，最近老有人问你们有没有能刻名字的钱包，可我们明明有一整个系列。运营去站里搜了一次刻字，返回零结果，当场就明白了。客服那边听到的问法，和商品页上写的说法，是两套完全不同的词汇，而搜索框正好卡在这两套词汇中间。

用户扫完一屏一个没点，这件事在报表里等于没发生，这类沉默拒绝最难被发现。

他们还顺手解决了另一个问题

补用途标签的时候顺带发现，这批词在商品页上同样没有。也就是说不只是搜不到，从搜索引擎过来的人也搜不到。一次为搜索框做的改动，最后在自然流量上拿到了更大的收益——这类改动的性价比通常都是这么来的，因为它修的是数据不是页面。

用户旅程各阶段的用词不一样，六阶段的关键词布局能帮你把词补齐。

一个他们没做对的地方

零结果页的推荐区块一开始放的是全站热销，效果一般。后来改成按用户搜的词做模糊匹配，比如搜刻字没结果就推可定制的那几个系列，咨询量才明显起来。推荐要跟没找到的那个东西有关，否则它只是又一屏商品。

推荐不相关一次，用户就不再信任你的任何推荐位，这条教训在购物车里已经验证过。

这套改动花了他们多少时间

合计四天半，分散在两周里做完。这个成本对多数团队都在可接受范围内，真正的门槛是有没有人意识到这一页需要被管。

这个案例里最值得注意的一点

他们的问题不在搜索功能，在商品数据。站内搜索是一面镜子，它照出来的是你的商品信息里缺了哪些用户会用的词。修搜索功能只是表面动作，真正的收益来自把那些词补进商品数据。

行业标准的说法和用户自己的说法常常对不上，尺码那个例子特别典型。

换个规模看，小站该怎么做

商品数量少于一百的站，其实不需要复杂的搜索，需要的是别让人搜空。做法可以很土：把最常被问到的十几个说法直接做成同义词映射，搜A的时候按B去匹配。一张表，几十行，一小时能做完。越小的站越应该用笨办法，因为笨办法不需要维护。

小团队用笨办法反而更稳，极简原则的八步落地是同一种思路。

常见问题解答

站内搜索结果页到底该不该让搜索引擎收录？

绝大多数情况下不该。这类页面可以被无限构造，容易造成索引膨胀，而且内容质量不稳定。标准做法是在页面上加禁止收录标记，让搜索引擎能取到这一页并读到标记。如果同时在抓取规则里屏蔽了路径，反而可能因为读不到标记而出问题。

那禁止收录之后，从AI来的人怎么办？

这两件事互不影响。禁止收录只约束搜索引擎的索引行为，对真人点开链接没有任何限制。所以该改的还是要改：标题写清状态、无结果时给出路、服务端尽量返回真实内容。

怎么知道有没有人落在我的站内搜索页上？

看访问日志或者分析工具里的落地页报告，按搜索路径筛一下就知道。如果有量，再看它们的来源；如果来源里能看到AI产品的域名，那就是本文说的情况。这个检查十分钟能做完。

我的搜索页是脚本渲染的，非改不可吗？

不是非改不可，但至少要让服务端返回的框架里带上正确的标题和一句说明。全面改成服务端渲染成本可能很高，而把标题和状态放进初始响应通常只是一个模板改动。

把查询词做成映射，会不会被当成作弊？

不会，前提是映射的目标页面确实跟查询词相关。把搜促销的人送到促销页是正常的产品设计。真正有风险的是映射到不相关的高价值页面，那属于欺骗性跳转。

零结果页面加推荐商品，会不会显得答非所问？

关键在措辞。先明确说没有找到匹配这个词的商品，再说下面是一些热销款，用户是能接受的。最糟的做法是不说明情况直接堆一屏商品，那会让人以为这些就是搜索结果。

这次实测的方法能用在自己站上吗？

能，而且更简单，因为你不需要绕过任何防护。用一个必然有结果的词和一串乱码各请求一次，把两次的状态码、字节数、标题、规范地址列出来对比。十分钟能做完，结论直接可用。

搜索页要不要做成服务端渲染？

如果你的搜索页确实有外部访问落地，值得做；如果它只是站内工具，没必要为它改架构。一个折中方案是让服务端至少返回正确的标题、结果数量和一段说明，商品列表仍然交给脚本，成本通常只是模板改动。

零结果的时候返回404合不合适？

不合适。搜索页本身是存在的，只是这次查询没有匹配到内容，这跟地址不存在是两回事。返回404会让机器认为这个地址无效，而它明明可以被访问。正确做法是返回200，同时在标题和页面上明确说明没有结果。

规范地址到底该指向哪里？

如果这类页面不进索引，指向带查询词的自身地址最稳妥，既不影响索引策略，又保留了每个查询的身份。指向不带参数的搜索路径也能用，但你会失去按查询词分析的能力。指向首页是没有理由的，不建议。

如果我用的是建站平台，模板改不了怎么办？

先看平台有没有开放搜索页模板或者标题规则的设置，多数主流平台是有的。实在改不了，退一步的做法是在无结果时用平台自带的推荐位配置，至少让这一页不是空的。能改多少改多少，比因为改不全就一点不改强。

改完之后怎么知道有没有效果？

三个数就够：这一页的零结果比例、从这一页点进商品页的比例、以及改词再搜的比例。改动上线前后各取两周做对比。别只看跳出率，那个数受太多因素影响，波动大到看不出改动的效果。

如果我的站根本没有站内搜索呢？

那这篇文章对你仍然有用，因为同样的问题会出现在筛选页、标签页、分页和404页上。判断方法完全一致：找一个必然为空的状态，请求一次，看这一页说了什么。凡是模板统一、数量庞大、自动生成的页面，都值得跑一遍这个检查。

这件事该由谁负责？

建议挂在做转化那个人身上，因为它本质是落地页问题，不是技术问题。技术同事负责让服务端返回正确内容，做内容的负责补商品数据里的用户用词，但盯着这一页表现的应该是关心转化的那个人。没人负责是这一页所有问题的总根源。

权威参考资料