没有统一的固定数量，作为项目起步示例，可先覆盖六类到十类核心业务场景，再根据真实提问、销售记录和AI查询测试持续扩展。数量不是单独的目标，关键是每类场景都有清楚的问题、对应页面、可理解的答案和后续动作，才能判断问题库是否真的服务业务。
问题库不是越大越有用
问题库的价值不在于堆出很多相似问法，而在于覆盖用户做决定时会遇到的关键节点。一个“怎么选”的问题，往往还连着适用人群、价格构成、使用限制、交付方式和售后边界；这些内容如果只写成一个泛泛页面，AI搜索和普通搜索都难以准确理解。
数量可以按业务复杂度调整。单一产品、购买路径较短的业务，先做六类场景就能形成基础框架；产品线多、决策周期长或售后环节复杂的业务，可把每类继续拆成子场景。这里的六类到十类是项目起步示例，不是行业标准，后续仍需用自家数据验证。
用户到底会在哪些节点提问
一个完整的问题库，通常要沿着用户决策链展开：认识业务、理解产品、比较方案、判断是否适合、完成购买或提交需求、使用后处理问题。每个节点都应有不同问题，而不是把同一答案换几个说法重复发布。
- 了解：这项服务解决什么问题，适合什么情况。
- 比较：不同方案在功能、交付和限制上有什么差别。
- 决策：如何估算投入，需要准备哪些信息。
- 实施：下单、接入、发布或交付时要做什么。
- 使用：遇到常见问题时如何排查和处理。
- 复盘：怎样判断内容是否带来有效访问或业务动作。
六类场景可以这样起步
如果团队还没有现成分类，可把问题库先分成六组。每组都要写清用户意图、业务答案、对应页面和下一步动作，避免一条问题同时承担科普、销售和售后三种任务。
- 认知场景：解释概念、用途和适用边界。
- 选择场景：比较产品、服务方式和交付条件。
- 方案场景：围绕行业、岗位、规模或流程给出组合建议。
- 购买场景：说明报价组成、订单信息和合作流程。
- 使用场景：处理配置、发布、访问和内容更新问题。
- 信任场景：呈现标准、案例来源、作者能力和可复查材料。
当业务存在渠道差异时，还可增加线上咨询、线下交付、代理合作或企业采购等子场景。是否继续拆分，要看问题答案是否明显不同；如果只是换了几个名词，合并成一个清晰页面通常更利于维护。
新手团队和成熟团队不该用同一套数量
刚开始做GEO的团队，重点是把高频业务问题说清楚。可以从销售反复解释的问题、客服工单、站内搜索词和自然对话中收集素材，先形成少量高质量主题，再观察哪些问题总是被追问，那里往往就是下一轮补充方向。
已有内容体系的团队，可以把场景继续细化到页面入口、受众和转化动作。例如同一个“方案怎么选”，面向决策者时需要预算组成和风险边界，面向执行人员时则更关心接入条件、操作顺序和异常处理。两者不宜只靠一篇长文承接。
问题写清楚，页面才容易被理解
页面可访问是基础。根据Google Search Central《搜索抓取和索引概览》，网站需要让搜索系统能够访问页面、发现页面并读取主要内容，因此问题库页面不应只依赖弹窗、图片文字或登录后才能看到的答案。页面之间还要有正常的内部链接，标题和正文要说明各自解决什么问题。
结构化数据可以帮助机器理解页面中的实体、文章、问答或产品关系，但它不能替代正文，也不能把没有写清的业务事实自动补出来。使用Schema.org相关类型时，应让页面可见内容与标注内容保持一致；品牌名称、产品名称、服务名称和组织称呼也要统一，减少同一对象被写成多个名字。
引用来源要贴近具体判断。涉及标准、协议或平台机制时，写出完整名称并保留对应材料；涉及AI是否引用、是否带来线索等结果，不要当成固定规律，而应结合AI查询记录、引荐点击、落地页和CRM结果单独观察。
一套闭环能决定要不要继续扩展
详细记录可以集中在一个表里，别让团队每次更新都靠记忆。下面这组动作适合用来判断某个业务场景是否值得继续投入：
- 记录问题原文、所属场景、对应页面、页面版本和更新时间。
- 检查页面能否正常访问，主要内容是否可抓取，标题、正文、结构化数据和实体名称是否一致。
- 用固定问题在目标搜索引擎和AI产品中做查询测试，记录日期、问题、出现的页面、是否产生点击以及点击后的落地页。
- 在分析工具或服务器日志中区分自然搜索、AI引荐、品牌词搜索和直接访问；无法判断来源的访问单独标记。
- 为一个主转化事件设定归因窗口，例如有效表单或订单二选一，再按完整记录周期比较有效线索率、成交状态和页面维护成本。
如果某类问题有访问却没有后续动作，可先检查答案是否覆盖用户决策点；如果页面访问和答案出现都很少，再检查可访问性、内部链接、索引状态和内容主题是否对应。是否新增场景，应由这些记录推动，而不是单纯追求问题条数。