ozine's book library

主题

第 6 章 搜索意图、关键词聚类与页面规划 ​

6.1 一张词表为什么还不能指导建站 ​

上一章得到的是候选需求。真正开始建设页面时，你还要回答三个问题：哪些查询可以用同一个页面解决，哪些必须拆开，以及有限时间先投入哪里。本章将把词表转成可执行的页面地图，重点解释容易出错的边界，而不要求你相信某个软件一键给出的分类。

继续使用假设中的轻舟开发工具。它收集了“JSON 转 Go”“Go struct generator”“Go JSON 教程”“Go JSON 解析失败”“JSON 转 Go 不上传数据”。如果按词频归类，它们都带有 Go 或 JSON；如果按用户下一步动作归类，却会分出转换、学习、排错和隐私确认。页面规划必须关注后者，否则你可能写出一篇什么都谈一点、却没有让用户完成任何任务的长文章。

第三章已解释搜索意图，本章要把意图判断落到页面职责上。一个人刚开始了解问题，随后可能比较方案；使用工具遇到错误，又会转向说明页。页面之间需要承接这些变化，每个入口仍应有清楚的主要用途。

本章的学习目标是独立完成一份页面映射表，为聚类与拆分写出理由，给机会排序，并能够判断同站多个页面同时出现时究竟是健康覆盖还是资源冲突。文中的阈值、分数及经营数字属于教学设计，不能当作 Google 公布的规则。

6.2 意图标签只负责初筛 ​

沿用第三章的信息型、导航型、商业调查型和交易型分类，先给候选词做粗分，再补主要任务、次要任务与置信度。标签的作用是减少初筛工作，不能代替页面规划。

“最好的 JSON 转 Go 工具”偏向比较，但用户也可能想马上使用其中一个；“某工具价格”有明确品牌目标，也处于购买评估阶段；“成都空调维修”可能既要报价，也要确认今天能否上门。强迫每个词只能有一个标签，会隐藏需要在页面中解决的次要问题。

可以给每个查询保存主要任务、次要任务和置信度。例如“JSON 转 Go 在线”的主要任务是完成转换，次要任务是判断结果是否可靠，置信度高；“Go JSON”只标为混合任务，置信度低，需要查看结果与用户行为。置信度应说明依据，不能由研究者凭感觉填一个精确百分比。

商业工具自动标注意图也只是辅助。Semrush 的官方说明提到，它的模型会考虑结果页特征、表达中的意图词及品牌因素。[B09] 因而当你发现机器把一个词标为信息型，仍应检查该地区当前结果和用户场景。自动标签能够减少重复劳动，但没有替你确认页面是否解决问题。

6.3 从 Google 搜索结果判断页面应该长什么样 ​

沿用第三章的 SERP 观察方法，为同一主题选择几个代表查询，记录主要结果是工具页、产品页、分类页、教程、论坛、视频还是本地商家。此处的目标是决定自己的页面形式；完整的竞对抽样与证据记录方法见第七章。

除了形式，还要观察信息粒度。一个结果直接给出可复制命令，一个结果从基本概念讲起，两者满足的起点不同。检查用户是否需要实时数据、地区信息、价格、图片或可交互功能。若主要任务是即时转换，把可用工具放在页面前部通常更合理；若任务涉及有风险的操作，则应先解释必要限制和准备事项，不能只为了让按钮靠前而删去安全条件。

搜索结果提供的是当前系统选择的答案样本，不能证明所有结果都正确，也不能证明只要模仿形式就能排名。样本还受地点、语言、设备、时间和个性化等环境影响。无痕模式不能消除所有差异。对高投入页面，至少跨时间复查关键查询；对本地服务，还应在合法且准确的目标地区环境中观察。

要把“当前占多数的形式”和“你打算采用的形式”分别记录。如果你选择不同形式，写明理由。例如，当前结果多为长教程，但目标用户反复需要执行计算，而你能做一个准确的计算器。这可以是值得试验的产品机会，却仍属于待验证判断，不是已被结果页确认的获胜策略。

6.4 聚类先按任务，再用算法扩大规模 ​

关键词聚类（Keyword Clustering）就是把可能由同一页面满足的查询放到一组。最简单的方式是词面规则，适合先按产品、格式、城市、型号分桶；它的弱点是无法可靠区分方向、否定、语义和任务。“删除账户”和“删除账户后恢复”共享许多词，却不能当成完全相同的操作。

语义聚类使用向量或语言模型估计表达接近程度，能处理同义词和跨语言说法。问题在于语义相关并不等于一个页面可以满足。“JSON 转 CSV”和“CSV 转 JSON”语义很近，操作方向却不同；“露营装备清单”和“露营装备购买”主题相同，用户要的页面也可能不同。算法应帮你提出候选分组，由人检查边界。

结果重合聚类进一步比较两个查询的自然结果网址。若同一批页面经常同时满足两个查询，可以认为它们可能由同一页面承接。这仍只是观察推断，不是 Google 提供的聚类接口。结果变化、样本深度、网址规范化以及混合意图都会影响判断。

一个稳妥流程是先按业务主题分桶，再选代表词观察结果，随后批量计算相似度，最后复核离群词和高价值词。这样既避免完全手工逐词处理的高成本，也不会把整个网站结构交给黑箱。每个最终分组至少写一句“这些用户都想完成什么”，写不出来就继续拆分或调查。

6.5 一个可以手算的结果重合例子 ​

以下集合完全是假设，用于解释计算。查询甲的前五个自然结果网址为 A、B、C、D、E，查询乙为 A、B、C、F、G。两者共同网址有三个。若采用固定深度重合率，结果为三除以五，即百分之六十；若采用杰卡德相似度（Jaccard Similarity），分母是两集合去重后的七个网址，结果为三除以七，约百分之四十三。

这两个值不矛盾，因为分母不同。把它们都叫“重合率”而不写定义，会让团队得到不同结论。研究记录应明确采集前几个结果、是否剔除广告、是否把同域不同页面合并、怎样处理视频与图片模块、网址参数如何规范化。小样本下一个结果变化就可能显著改变分数。

再假设查询丙的集合为 H、I、J、K、L，均为教程；甲与乙主要为在线工具。那么甲乙可以进入同页候选，丙应先分开。这里的 A、B、C 必须是完全相同的具体页面，不能只是相同域名。假设另一次采集只记录域名，甲出现的是某站的转换器，乙出现的是该站的教程，这只能算域名重合，不能算前述网址集合的交集。即使具体 URL 确实重合，也要阅读页面：一个综合页面可能同时承接不同任务，重合本身仍不足以决定合并。

不要制定“重合三条就一定合并”的普遍规则。实际可以先人工标注一小批明确应合并和明确应拆分的样本，观察所用相似度是否能区分它们，再为该项目选择工作阈值。把低置信度组留给人工，比把阈值调到能让表格看起来整齐更有价值。

还要防止链式误合并。甲与乙接近，乙与丙接近，不意味着甲与丙同任务。许多聚类方法会把这种关系串成一个大组，最终把不同意图压进同页。复核时检查每组的代表词与最远成员，并确认最远成员在页面中仍能自然完成自己的任务。

6.6 为每个分组指定页面职责 ​

页面映射（Keyword Mapping）把需求组分配给现有或计划中的网址。最少保留七个字段：需求组名称、主要任务、代表查询、页面类型、目标网址、现有状态、下一步动作。进一步可以加入负责人、证据日期、成功指标和相邻页面，便于之后维护。

轻舟的转换组可以分配到一个稳定的工具地址；“结构体标签解释”分配到指南；“团队批量生成与协作”若产品真实支持，则对应功能页；“价格与版本比较”对应定价页。主页负责介绍站点和主要入口，不必承载每个长尾问题。一个页面可以覆盖多个相关查询，但应有一个能向用户解释清楚的主要承诺。

一条可执行的假设记录可以写成：需求组为“从 JSON 样本生成 Go 类型”；主要任务为“得到可复核的结构体”；代表查询为“JSON 转 Go”和“JSON 生成 Go struct”；页面类型为交互工具；目标网址为 /tools/json-to-go/；状态为已有基础版本；下一步为补空数组示例与生成结果检查，并从工具目录链接到它。这样，开发者拿到的就不只是两个词，而是一项可以交付和验收的工作。

所谓主关键词只是编辑与测量时的简称，不是要求全文围绕某个词机械重复。正文需要覆盖完成任务必须知道的条件，例如输入支持范围、错误示例、输出限制和下一步动作。次要查询若只需要两三句话解释，可以放在相关段落；若需要独立工具、完整流程或不同责任声明，才更可能需要新页面。

对电商站，宽泛品类通常需要能浏览、比较和筛选的分类页，具体型号需要产品页，选购疑问可以由指南承接。对本地服务，城市服务页需要真实覆盖范围、联系方式与服务细节，不能仅替换地名；对个人内容站，系列文章需要让读者知道从哪篇开始、哪篇解决哪个问题。页面地图由用户行动关系支撑，不是仅靠网址目录看起来整齐。

Google 的电商结构说明强调页面间链接关系帮助系统理解站点，且重要产品应通过可抓取导航到达。[B16] 因此映射表还应写明入口：来自哪个分类、哪篇指南、哪个相关工具。一个精心写好的页面若在站内没有合理连接，发布之后仍可能难以被读者和抓取系统发现。

6.7 什么时候合并，什么时候拆开 ​

合并的常见条件是任务相同、用户起点相似、答案高度重合、需要的功能相同，而且一个页面的组织方式能让不同表达的人快速找到答案。例如，“JSON 转 Go”和“JSON 生成 Go struct”很可能可以共享功能页，但最终仍应核对目标市场的结果和产品实现。

拆分通常发生在输出不同、操作方向不同、目标人群差异明显、步骤无法共用、法律或服务范围不同，或者主要结果形式稳定不同的时候。“个人免费版”和“企业私有部署”可能共享部分背景，但采购者的安全、部署、权限与合同问题需要足够空间，不能把它们藏在面向个人的短 FAQ 中。

还有一种中间状态是先在已有页面补充章节，再观察需求是否值得独立。比如工具页上的“空数组怎样判断类型”先用一个示例回答，若后续发现用户需要完整的跨样本推断教程，再建立独立指南并从工具页连接过去。这能避免凭一条候选词就增加长期维护负担。

拆分并不是越细越好。假设一个维修商确实只在一个城市提供同样服务，如果为每条街道写几乎相同的页面并全部导向同一联系方式，用户并没有得到更具体的帮助。类似的入口页滥用属于 Google 垃圾内容政策关注的范围。[B12] 地理粒度应由真实服务差异支撑，而不是由可以替换多少地名决定。

6.8 优先级：把预期收益和不确定性同时写进计划 ​

排序前先设必要条件：业务相关、可以真实履约、有能力提供可靠答案、页面不会违反政策或侵犯权利。不能满足这些条件的机会，不应靠高搜索量在总分中重新赢回来。满足条件后，再比较收益、可行性、证据强度、建设成本和维护成本。

初期可以采用简单等级而非复杂公式。业务价值分为直接帮助购买、间接支持选择、主要提供学习；证据分为已见真实需求、多源线索、单纯猜想；实施成本按实际所需工时估计。给每个判断写一句理由。公式可以辅助汇总，但不能代替理由，否则团队会把主观估计包装成数学客观性。

如果需要预算决策，可使用预期贡献模型。把“估计搜索需求”“可获得的自然点击比例”“完成关键动作的比例”“每次关键动作的预期贡献”相乘，再减去建设和维护成本。每项都应注明依据和范围。“预期贡献”应使用扣除相应变动交付成本后的价值，并与收入区分；若关键动作只是试用，还要折入之后付费的概率。这里的自然点击比例直接以需求次数为分母时，已经包含没有点击到你站点的各种情况，不要再重复乘一次结果页可点击率。

例如，假设某需求组每月有二千次可覆盖搜索，稳态时你预计获得其中百分之四的点击，即八十次；其中百分之五成为合格试用，即四次；每次合格试用的预期贡献为一百二十元，则月贡献四百八十元。若建设成本一千二百元、每月维护一百元，六个月稳态贡献减成本为六乘四百八十，再减一千二百，再减六乘一百，结果一千零八十元。其中一百二十元可以来自“假设百分之二十的合格试用会付费，每位付费客户在约定观察期内贡献六百元”的估计，并非每次试用实际收款一百二十元。这里还假设六个月内各批客户采用同一贡献观察期，所以结果不等于六个月现金到账额。全部数字为假设，且尚未考虑上线后的爬坡时间。

假设前三个月仅达到稳态的百分之二十五、百分之五十和百分之七十五，后三个月达到稳态，那么六个月的流量系数合计为四点五，贡献只有二千一百六十元，减去同样的一千八百元成本，余三百六十元。加入一个合理的时间条件，结论就明显变化。这正是为什么预算预测必须展示假设，而不能只给漂亮的单点回报率。

6.9 用敏感性分析选最值得验证的问题 ​

继续上例，如果关键动作比例由百分之五降为百分之二点五，预期贡献减半，六个月结果转为亏损；若建设成本能降低三分之一，结果则相对改善。通过这种逐项改变假设的方式，可以发现哪项不确定性最影响决策。接下来优先验证转化路径，而不是继续花时间争论搜索量是一千八还是二千二。

比较两个页面时，也要检查它们是否抢占同一批需求。假设两篇计划覆盖的查询高度重叠，把各自的预测点击直接相加会重复计算。主题组合的预测应去重，并给无法拆清的重叠部分保守处理。多个近义词的工具搜索量也未必彼此独立，尤其当数据提供者将近似变体合并时。

新站应在短期可交付页面和长期核心页面之间分配资源。只做容易的边缘词，可能一直无法解释产品的主要价值；只做极宽泛的头部词，又可能很久没有可读的反馈。一个可执行的计划可以包含少量基础产品页、若干具体任务页和一个探索性试验，比例由团队能力决定，没有适用于所有网站的标准配方。

还要给更新留出时间。某些页面上线很快，却需要每月核验价格、版本或库存；某些深度指南建设成本高，但能长期维护。优先级中忽略维护，相当于低估了未来承诺。对于一个人的站点，能持续保持正确的二十页，通常比无法复核的数百页更可管理。

6.10 关键词蚕食：先证明伤害，再考虑合并 ​

关键词蚕食（Keyword Cannibalization）是行业中对同站页面围绕相似需求发生不利竞争的描述。它不是一个看到两个网址有相同词就成立的官方处罚名目。同一站点的工具、教程和产品页可以各自满足不同任务，也可能在不同时间、设备和地区出现。首先要问的是：用户是否进入了不合适的页面，资源是否被无意义地分散，以及整体结果是否受损。

调查可以从查询与页面交叉数据开始。固定搜索类型、国家、设备和日期范围，按第五章的方法逐个筛选代表查询，再查看“网页”表，记录哪些 URL 获得展现及点击。需要按需求组汇总时，先检查纳入的查询是否确实同任务，再按相同范围逐周比较。不要把单日网址轮换直接当作蚕食；小样本、结果测试、内容更新和统计归属都可能造成波动。Search Console 的多数表现数据归于规范网址，也会影响你对实际被访问版本的理解。[B03]

一个教学假设是：工具页和旧教程争取同一个即时转换词。旧教程获得更多展现，却没有可用功能，进入后很少到达工具；同时两个页面的正文和标题高度近似。在排除技术问题后，这才形成值得处理的冲突线索。另一个情形是教程承接“如何解析”，工具承接“在线生成”，即便共享 Go 和 JSON，也没有充分理由合并。

处理方式取决于诊断。内容真正重复且旧页不再需要时，可以合并有价值的信息并按技术规范做永久重定向；页面任务不同但表达模糊时，应重写标题、开头和内部链接，让职责清楚；页面必须保留且内容高度相似时，再评估规范化。不要把所有较弱页面都指向首页，也不要对不同任务页面随意添加 canonical 来“传权重”。

Google 的规范化说明把重定向与 canonical 标记作为选择代表网址的信号，并说明它们用于重复或非常相似页面。[B14] 这不意味着 canonical 是强制命令，更不意味着它能替代内容职责设计。修复之后仍要检查目标页是否正常访问、内部链接是否更新、重要信息是否保留，以及需求组整体表现是否改善。

6.11 让页面地图成为持续维护的工作文件 ​

映射表需要记录变化原因。某个页面从“计划创建”改成“扩充已有页”，应写明合并依据；某组从“信息型”改成“操作型”，应附上新的结果观察或用户反馈。这样半年后回看时，能知道之前的决定为什么成立，以及什么证据足以推翻它。

建议把页面状态分成待研究、已确定职责、制作中、已发布、观察中、需更新、合并或退役。状态名可以调整，但应清楚区分“尚未完成”与“发布后效果未知”。某个页面没有流量时，先看它是否有被发现与进入索引的机会，再看需求、匹配和竞争；不能把所有问题都解释为关键词选错。

团队协作中，一个需求组应有负责决策的人，而非每位作者自行建立近似页面。作者拿到的简报要有主要任务、必要事实、用户限制、页面形式、相关已有内容和验证方法，不宜只给关键词密度及字数目标。字数取决于解释任务所需的篇幅；Google 的内容指导并没有要求某个固定字数。[B13]

6.12 练习与可执行检查 ​

练习一：甲乙两个查询前五个网址共有四个，是否立刻合并？参考答案：先确认比较的是具体网址还是域名，查看共同页面是否真的满足同一任务，再检查用户限制和页面形式。高重合支持合并候选，但不能省略内容判断。

练习二：一个页面月搜索量估计小，却直接回答客户采购前必问的问题，优先级应低吗？参考答案：不一定。它可能有很高的业务适配和支持价值，应与转化、销售说明及维护成本一起评估。搜索量是需求线索的一部分，不是唯一目标。

练习三：一个站点有两篇“Go JSON”文章，其中一篇解释基础解析，另一篇处理生产系统错误，如何处理？参考答案：先检查它们的具体查询、页面任务、内容差异和内部链接。如果职责清楚且用户都需要，可以保留；若后者只是重写前者，应考虑合并。不能从标题共享两个词直接得出结论。

发布前逐项确认：每页有一句可读的任务承诺；每组关键词有合并或拆分理由；混合意图和低置信度已标记；重要页面有合理入口；预测没有重复计算重叠需求；成本包含更新与维护；没有把厂商分数当作排名承诺；任何重定向或规范化都有明确对象与验证计划。完成这些工作后，内容制作才有稳定的方向。

本章参考来源 ​

保留各书来源与许可 · 示例运行条件以正文为准