从零搭建GEO问题库，应先沿着用户从产生需求到完成决策、使用产品再到售后反馈的完整链路收集提问，而不是先凭经验列主题。这样做的边界是：问题必须来自搜索记录、销售对话、客服工单或站内行为，页面是否被抓取、索引和引用仍需用自家数据验证。
问题库不是选题表，而是用户决策地图
一张普通选题表只记录“写什么”，问题库还要记录“谁在什么阶段问、为什么问、需要什么证据”。同一个业务可能同时出现“这是什么”“和另一种方案有什么差别”“怎么买”“出了问题怎么办”等提问，它们对应的页面任务并不相同。
判断一条问题是否值得进入库，可以看它能否连接一个明确动作：继续了解、比较方案、提交线索、下单、安装使用或申请服务。无法对应用户动作的空泛问题，可先放入观察区，不急着扩写成文章。
先把一条业务链拆成真实提问
问题采集要从业务链的节点开始，而不是从关键词工具的词根开始。把用户接触业务的过程写成一条线，再把每个节点下的原话保留下来，尤其注意那些带有口语、犹豫和反问的句子，它们往往比整齐的关键词更接近真实需求。
- 收集搜索框、广告词、销售聊天、客服记录和表单备注，去掉姓名、电话等个人信息。
- 按认知、比较、决策、使用、服务几个阶段归类，不要只按词面归类。
- 给每条问题补上用户身份、所在场景、阻碍点和希望得到的证据。
- 为问题绑定页面类型，区分产品页、说明页、对比页、案例页和服务页。
- 记录原始出处、采集日期、处理人和当前版本，后续能看出问题是否发生变化。
这里的关键不是收集数量，而是保留语境。例如“能不能接入现有系统”和“怎么接入现有系统”看起来相近，前者偏可行性判断，后者偏实施说明，页面答案不能混成一段。
同一个问题要写出不同阶段的答案
认知阶段的用户需要定义、边界和适用条件；比较阶段需要差异、成本组成和选择影响；决策阶段更在意交付范围、时间节点、合同内容和服务责任。把这些内容塞进一篇长文，用户未必能快速找到自己关心的部分。
问题库可以给每条问题标注“主答案”和“补充答案”。主答案放在页面开头，用完整句子直接回应；补充答案再解释例外、操作条件和相关页面。这样既方便人阅读，也让搜索系统更容易识别问题与答案的对应关系，但是否带来引用或转化变化，需用自家查询记录与业务数据验证。
页面能不能被抓到，别靠猜
问题写得再好，页面无法访问或不允许抓取，内容就难以进入搜索流程。Google Search Central《搜索抓取与索引概览》说明了抓取、处理和索引之间的基础关系；robots.txt、HTTP状态和站点地图应按文档语义逐项查看，不要把“页面已经发布”当成“页面已经被搜索系统处理”。
排查时可从访客视角打开页面，再用服务器日志观察访问状态，检查重要页面是否被登录墙、脚本错误、错误跳转或重复地址挡住。索引状态属于搜索系统的处理结果，不能仅凭浏览器能打开来判断，也不能把抓取次数直接当成AI引用信号。
让实体、引用和结构化数据互相对得上
同一个企业、产品、服务和功能，在标题、正文、面包屑、页面地址、图片说明及结构化数据中应保持同一称呼。名称一会儿写简称、一会儿写旧名，读者和系统都要额外猜测它们是否指向同一对象，这会削弱内容的可理解性。
结构化数据应只描述页面中确实呈现的内容。Schema.org《Schema.org词汇表》可用于查看类型与属性的定义，但使用某个类型不等于获得收录、展示或引用结果。引用链路也要贴近结论：标准、政府页面、检测机构材料或企业自身页面分别承担不同事实，不能用一条来源替代所有判断。
问题库上线后怎么知道该改哪一页
把问题库和页面、查询、访问及业务结果连起来，才知道问题是否真的被解决。建议把观察对象分开记录：爬虫访问、答案中出现、用户点击、自然搜索进入和后续成交不是同一件事，AI引荐点击也不等于订单。
可以建立一张版本表，记录问题原文、页面地址、更新时间、查询场景、引荐来源、落地页、有效表单和成交状态。主转化事件只选一个，归因窗口按销售周期设置；无法通用判断成本、周期、单量或效果，需用自家数据验证。若页面能访问但问题仍反复出现，下一次修改应先看答案缺口与实体表达，而不是盲目增加文章数量。