问题集扩充时，应先保留能对应真实需求、能落到具体页面、能通过查询或业务记录判断的问题，再处理同义改写和低信息量提问。适合持续维护的做法是把问题分成需求意图、页面承接、实体表达和结果记录几层，扩充前去重，发布后用查询记录、AI引荐点击和有效表单复盘，不能只看问题数量增长。
问题多，不等于覆盖广
一个问题值得留下，通常要能回答一个清楚的用户任务，例如比较方案、理解概念、寻找操作路径，或判断某项服务是否适用。只有把句子换成“怎么做”“是否值得”“有什么限制”，却没有新增对象、条件或决策动作，往往只是同一需求换了外衣。
问题集还要和页面承接能力对上。页面没有回答范围、适用条件、限制说明或下一步动作时，继续增加相似问题，只会让内容团队重复生产。更实用的判断是：这个问题能否对应一个独立答案，能否引导用户继续阅读，能否在查询测试中看出回答是否准确。
先分清用户到底想解决什么
同一个主题可能包含认知、比较、操作和验证等不同意图。把“GEO是什么”和“怎样减少无效问题”放进同一组，会让页面主题变宽；把“如何发现重复问题”和“如何记录AI引荐”拆开，则更容易安排页面、表格和负责人。
可以给每个问题保留一行简单说明：用户处于什么阶段、想得到什么动作、需要哪些前提、答案准备放在哪个页面。若两个问题的答案、前提和下一步完全相同，就合并为一个主问题，把自然问法放入正文小标题或问答段落，而不是单独建页。
一道问题要有自己的答案落点
判断问题质量时，不要只看句子是否像用户会搜索，还要看答案能否独立成立。一个合格的问题至少应有明确对象、具体动作或判断条件，例如“页面被抓取后为什么仍未进入索引”，就比“GEO怎么做”更容易形成可读、可测的内容。
页面承接也要写得清楚。涉及抓取时，可围绕robots.txt、sitemap、HTTP状态码和页面可访问性组织内容；Google Search Central《搜索抓取与索引概览》对这些基础机制有相应说明。涉及结构化数据时，应使用Schema.org定义的类型和属性，不要把结构化数据直接写成AI引用或转化结果的承诺。
同义问题别让系统反复劳动
去重不能只靠字面比对。把“如何减少无效GEO问题”“怎样清理低价值问题”“问题集扩充后怎么去重”放在一起，看它们是否共享同一答案、同一页面和同一判断标准；若只是语气不同，可保留一个主问题，其他表达作为自然问法记录。
也别把所有长尾问法都删掉。有些问法虽然相近，却带有不同限制，例如面向技术人员关注抓取与结构化数据，面向内容人员关注题目归类与版本管理。保留差异的关键，不是词语数量，而是答案是否需要改变示例、操作顺序或结果记录方式。
让页面、实体和引用关系说得明白
一页内容更适合围绕一个清晰主题展开，标题、首段、小标题、摘要和结构化数据中的实体名称保持一致。公司、产品、服务、术语若在不同页面使用不同叫法，读者和系统都需要额外猜测它们是否指向同一对象。
引用来源也要贴近具体事实。机制说明可引用搜索引擎文档或标准组织的材料；企业方法则应写成建议，不要伪装成行业规律；AI是否引用、是否带来点击或表单，需要结合自家查询记录、服务器日志和CRM判断，不能用抓取次数或答案中出现过一次来代替结果。
扩充前后，按这套小闭环走
问题集不必一次做大，先选一批与当前页面和业务动作直接相关的问题，完成“新增—去重—发布—观察—调整”的循环。每轮只改变一个主要因素，后面才看得出是问题表达、页面承接还是渠道记录影响了结果。
- 记录问题原文、意图、对象、对应页面和版本日期；如果无法写清答案落点，就先放入待整理区。
- 合并答案相同的问法，保留有不同前提、不同受众或不同下一步动作的版本，并写下保留理由。
- 检查页面是否可访问，查看robots.txt、sitemap和HTTP状态；这些机制的含义可按Google Search Central相关文档逐项比对。
- 检查实体名称、页面标题、摘要、结构化数据类型和引用材料是否一致；Schema.org的类型与属性说明可作为结构参考。
- 记录AI引荐点击、落地页、有效表单和成交状态，先选一个主转化事件，再按实际销售周期设定归因窗口；无法确认的访问单独记为未识别。
判断时不要把“被抓取”“出现在回答里”“有人点击”和“形成订单”混成一个指标。若问题扩充后只有抓取记录增加，却没有更清楚的答案或有效业务动作，就应回头缩小主题、补足页面内容，或暂停继续新增相似问法。
版本记录能防止问题集越改越乱
问题集长期维护时，最容易被忽略的是旧版本为什么被合并、删除或改写。给每条问题保留状态、变更日期、对应页面和变更原因，后续出现查询表现变化时，才有机会判断变化来自内容调整还是外部环境。
对于同一主题，可以保留主问题、用户自然问法和暂不处理的问法，但三者不要混在一个发布列表里。页面更新后重新做几次人工查询，记录回答是否覆盖限定条件、是否引用了正确页面，再决定继续扩充还是先修页面。