GEO问题库按业务场景分类还是按意图分

GEO问题库更适合采用“意图做主轴、业务场景做标签”的混合结构：先判断用户是在了解、比较、排查、决策还是使用，再补充行业、产品、页面和客户阶段。若团队只按业务场景堆问题，内容容易看起来齐全却难以指导页面；若只按意图归档，又可能失去业务落点，后续写作和数据记录都会变散。

别只按业务场景分，主轴要放在用户想做什么

业务场景回答的是“这条问题属于哪个业务”，搜索意图回答的是“用户此刻想得到什么结果”。在GEO内容里，后一个变量更能决定页面该写解释、对比、流程还是行动建议，所以问题库的一级目录宜围绕认知、比较、选择、使用和排查等任务建立。

这不等于放弃业务场景。把行业、产品线、客户阶段和页面类型作为标签，团队就能从同一个问题切换到不同业务视角，例如同是“怎么选”，可以分别落到产品比较页、服务方案页或售后说明页。

意图分得太粗，写出来还是会跑偏

“了解型”和“购买型”之间还隔着不少差异。用户问定义，通常需要简洁解释；用户问区别，需要并列维度；用户问是否适合自己，需要条件边界；用户问出了问题怎么办，则需要排查顺序和处理入口。问题库至少要把“想知道”和“想行动”分开。

一个好用的意图标签，应当能直接改变页面写法。若删掉标签后，编辑仍不知道该用问答、清单、对比表还是决策流程，说明分类还停留在行业名词层面，需要继续细分任务和用户阶段。

业务场景这一层，放在标签位更灵活

业务场景适合记录问题发生在哪里，比如产品介绍、价格说明、服务流程、售后处理、技术支持或品牌认知。它的价值在于帮助团队发现某一业务是否缺内容，但不宜单独承担页面排序，因为同一场景里可能同时存在科普、比较和决策问题。

场景标签还可以加入“面向谁”和“在哪个页面解决”两项。前者区分新用户、老客户、采购人员或技术人员，后者标记文章页、产品页、帮助中心和落地页。标签不要追求数量多，能帮助分配任务、定位页面和解释数据就够了。

一条问题怎么判断该进哪个格子

假设团队收到“某类服务是否适合小团队使用”这句话，主意图应记录为条件判断，业务场景可标为服务方案，用户阶段可标为评估期，页面类型则可能是方案页或问答页。这样一条记录既能指导写作，也能保留后续改写空间。

判断时别只看疑问词。把问题改写成“用户读完后要做什么”，往往更清楚：得到概念、缩小范围、完成选择、解决故障，还是找到下一步入口。若一句话同时包含两个任务，保留一个主意图，另一个放入次级标签。

建库时用这套小流程，后面少返工

问题库真正有用，不在于收集了多少句，而在于每条记录都能连接到页面、内容和结果。团队可以把下面的流程放进表格，边整理边修订，不必一次把所有分类定死。

1. 记录原始问题，并标出用户要完成的任务，不急着改写成文章标题。
2. 选择一个主意图，再添加业务、产品、用户阶段和页面类型标签。
3. 为问题绑定现有页面，记录页面是否能访问、是否允许抓取、是否进入索引，以及结构化数据和实体名称是否一致。
4. 发布后记录查询日期、出现位置、AI引荐点击、落地页、有效表单和成交状态，爬虫访问与答案出现只作中间信号。
5. 按一个完整记录周期复盘，主转化事件只选一个，无法确认的来源单独标为未识别，再决定改标题、补答案还是调整页面关系。

效果不能靠分类名称直接推断，成本、周期、单量和转化也无法通用判断，需用自家数据验证。对小团队来说，先把主意图和页面连接起来；对内容量较大的团队，再增加业务负责人、版本号和变更原因，方便回看每次调整带来的差异。