先给结论：选题不是把关键词换几个说法，而是把用户问题拆成他想完成什么、需要哪种证据、最后要去哪个页面。一张合格的选题表应记录问题、意图、页面角色、主承接页、证据来源和更新责任。

从用户问题开始

优先收集客服、销售、站内搜索、搜索控制台和访谈中的原句，例如 GEO 项目怎么验收、小预算能不能先试、结构化数据为什么没变化。原句比单个关键词更能表达场景。

给问题标记意图

可用定义、比较、教程、诊断、采购和复盘六类标签，选择主要任务。一个问题可以有多个动词，但标题和正文必须知道主要服务谁。

指定页面角色与证据

定义问题可由专题页承接，操作问题由方法文承接，采购问题由服务页和案例页承接。每个选题写清资料来自官方文档、项目记录、站点日志、访谈还是待研究。

发布后的复核

检查标题是否对应问题、开头是否直接回答、FAQ 是否真实、内链是否指向主承接页、sitemap 是否包含 URL。没有访问不一定是选题错误，也可能是页面尚未被发现。

适用边界

没有付费工具也可以用一手问题建立矩阵，但不能把问题数量当作搜索量，更不能据此保证流量。

Q&A

Q没有关键词工具还能做选题吗？

可以，客服问题、销售异议、站内搜索和现有访问数据都是一手需求信号。

Q标题需要包含所有关键词吗？

不需要，标题应准确表达用户任务，正文自然覆盖相关概念。

下一步怎么做

先把 20 个真实问题录入搜索需求矩阵，再指定页面和证据。 可参考服务方案、案例研究和研究专栏。

<!-- stage23-evidence-v1 -->

长期维护成本怎么拆

维护成本至少分为内容复核、技术构建、数据监测和异常处理四部分。内容复核负责事实、来源、标题和适用边界；技术构建负责模板、sitemap、RSS、canonical 和结构化数据；数据监测负责抓取、展示、点击和转化；异常处理负责失效链接、部署失败、提交失败和错误页面。分开统计后，才能知道是生产量过大，还是系统稳定性不足。

小团队不需要每天全面人工巡检，可以建立分层节奏：每次发布抽查新页面，每周抽查核心模板，每月复盘主题和查询，每季度检查服务页、案例页与证据页。自动化负责发现问题，人负责判断是否修改以及修改边界。

控制成本而不牺牲质量

优先维护承担商业决策和事实定义的页面，再维护长尾文章；优先修复会影响全站的模板问题，再修单页表达；优先合并重复内容，再增加新页面。所有新增任务都要说明预期解决的问题和停止条件，避免内容系统无限扩张。

  • 低质量批量文章的后续维护成本通常高于少量高质量页面。
  • 旧页面更新应保留原 URL，除非确有迁移理由。
  • 定期清理失效来源和无效内链。
  • 任何自动化都要有失败报警和可回滚方案。

<!-- stage23-depth-v2 -->

实施时可以建立一条最小证据链：先保存原始问题和测试日期，再保存页面版本与构建提交，接着记录平台返回的展示或抓取结果，最后把访问和业务动作关联到同一批页面。证据链的价值不是让每个结果都变好，而是让团队知道哪一步发生了变化。比如页面已经进入 sitemap 但没有展示，问题可能在索引或竞争；页面有展示但没有点击，问题可能在标题和摘要；页面有点击但没有咨询，问题可能在答案深度、信任证据或下一步动作。

为每篇内容设置一个复核日期。复核时先读页面，不要先看结论；确认标题仍然对应用户问题，开头仍然直接回答，正文没有过期条件，参考来源能够打开，内链仍然指向主承接页。若事实变化，只修改受影响的段落并更新日期；若搜索意图变化，再重新评估页面角色。不要为了追求“最新”而无理由重写稳定概念，也不要保留已经失效的承诺。

发布后至少保留三类记录：内容记录，包括标题、来源、更新时间和负责人；技术记录，包括构建结果、页面检查和提交响应；结果记录，包括查询、展示、点击、内链和业务动作。每次复盘明确哪些是事实、哪些是观察、哪些是下一步假设。这样持续内容增长才能从“不断发布”变成“不断学习并可回滚的生产系统”。 <!-- stage23-depth-v3 -->

为了让团队能长期执行，还要给每个问题设置停止条件：连续两个复核周期没有新增证据时，暂停扩写；同一意图已经有主页面且新页面没有独立任务时，合并或改为内链；来源失效且无法找到替代来源时，暂缓发布；平台数据样本不足时，只记录观察，不做增长承诺。停止条件可以减少无效内容堆积，也能把时间留给真正影响用户决策的页面。 <!-- stage23-depth-v4 -->

记录还应包括“未做什么”。例如没有外部工具时，不把估算写成真实搜索量；没有客户授权时，不把内部项目写成公开案例；没有足够样本时，不把单次波动写成趋势；没有完成生产核验时，不把本地构建写成已上线。把这些边界写进内容和复盘报告，既能保护读者判断，也能让后续维护人员知道哪些结论不能直接复用。

参考来源