UME

标签： GeneralSearch

  • GEO 优化核心密码：GeneralSearch「边想边搜」× Fetch「边读边取」智能交互链路全拆解

    结论先行

    在生成式搜索里，你的内容要“出现在答案中”，往往要先走完两步：GeneralSearch 找到你，再由 Fetch 读到你，最后才轮到 GEO 让模型敢引用你。
    因此，GEO 不只是“写得更像答案”，还要把网站做成一个稳定可抓取、可解析、可片段化复用、可归因的知识接口。
    如果把问题拆成工程化三问：搜得到（GeneralSearch）→ 读得到且读得对（Fetch）→ 引用得准且能追溯（GEO），你会更快定位增长杠杆与阻断点。

    Key Takeaways

    • GeneralSearch 决定候选池：你不在 Top 结果/候选源里，模型通常不会“费力去读你”。
    • Fetch 决定可用性：403、挑战页、强登录、纯 CSR（HTML 没正文）会直接让你“被读成空”。
    • GEO 决定引用率：AI 更偏好可抽取的答案块、清晰实体与可核验证据，而不是长段营销叙述。
    • 搜索爬虫 vs 用户触发 Fetch 要分开管：例如 OpenAI 的 OAI-SearchBot（搜索）与 ChatGPT-User（用户触发访问）用途不同；Perplexity 也区分 PerplexityBot 与 Perplexity-User，且用户触发 fetch 往往不按 robots 走。
    • robots 允许不等于服务器放行：真实拦截点常在 WAF/CDN Bot 管理与速率限制。
    • 生成式搜索会“多路搜索”：Google 公开描述 AI Overviews/AI Mode 可能使用 query fan-out（多次相关搜索）来找支持页面；覆盖子问题与同义表达会更重要。
    • 可观测性是 GEO 的核心能力：用日志（Fetch 成功率/状态码/耗时）+ 固定问集（覆盖率/引用率/表述一致性）做闭环，而不是只看点击。
    • 想“别被展示”，不要只靠 robots：noindex/preview 控制有严格前提（页面需可被爬虫访问到，才能读到 noindex）。

    1. 为什么要把 Fetch 与 GeneralSearch 放进 GEO 讨论

    在友觅 UME 的框架里，技术性 GEO 的目标不是“做一个 llms.txt”，而是把站点变成生成式引擎可稳定抓取、可正确解析、可片段化复用且能可靠归因的“知识接口”。
    而 Fetch 与 GeneralSearch，恰好对应生成式检索链路里最容易被忽视的两段“地基工程”：

    • GeneralSearch：负责“找候选来源”（发现与召回）。在不同平台里可能叫 web_search、Search API、query fan-out、或更泛化的“搜索工具”。
    • Fetch：负责“打开并读取某个 URL”（单次请求/抓取/解析）。Google 对“fetchers”的定义就很贴近：像 wget 一样，通常代表用户发起单次请求。

    GEO 的现实约束是：你无法只优化“内容表达”，却忽略“是否被找到、是否读得到”。因为很多生成式系统的默认策略是：先搜索，再挑少量链接 Fetch。

    2. 三个概念一张表看懂

    概念在链路中的角色典型失败信号你能直接优化的杠杆推荐核心指标
    GeneralSearch发现/召回候选页面（进入候选池）“AI 从不提你/永远选竞品来源”SEO 地基、主题覆盖、内链与 Hub、标题摘要工程候选池覆盖率、Top-N 进入率、主题可见性
    Fetch打开 URL 并获取可解析内容403/429、挑战页、抓到空壳 HTML、超时、重定向链过长robots + WAF/CDN 放行、SSR/预渲染、性能与稳定性、规范化Fetch 成功率、200 比例、TTFB/耗时、解析可见正文比例
    GEO让内容以“证据/答案块”形态被选中并引用抓到但不引用；引用不准；去品牌化严重答案工程、实体工程、证据工程、Schema、锚点可引用块引用率、Share of Answer、表述一致性、纠错闭环周期

    这张表可以当作站内“问题归因”框架：没被引用 ≠ 内容不行，可能只是卡在了 GeneralSearch 或 Fetch。

    3. 生成式搜索的默认路径：GeneralSearch → Fetch → 生成 → 引用

    把生成式系统的典型行为抽象成伪代码，更容易理解你要优化什么：

    用户问题 Q
  ↓
GeneralSearch(Q) → 返回候选URL列表（可能是多轮 query fan-out）
  ↓
挑选 Top-K URL
  ↓
Fetch(URL) → 获取HTML/正文 → 解析/分块/重排
  ↓
生成答案 → 选择证据片段 → 引用/归因

    关键点有两个：

    1. 搜索会变成“多次搜索”
      Google 明确提到 AI Overviews/AI Mode 可能用 query fan-out：围绕子主题多路搜索、再汇总支持页面。对于内容方，这意味着：只押一个主关键词不够，必须覆盖子问题、同义问法、比较型问题。
    2. Fetch 往往是“少量且挑剔”的
      生成式系统通常不会像传统搜索引擎那样“深爬你全站”，而是围绕当前问题，挑少量页面读取。这也是为什么 UME 一直强调 P0：不要让 AI 爬虫吃 403；robots 放行不等于服务器放行。

    4. 让 GeneralSearch 选中你：候选池工程

    4.1 你真正要赢的是“被选为来源”的资格

    在 UME 的表达里，GEO 的“收录”更像是进入生成式检索链路的候选池，并在答案里被可靠引用。
    这意味着：SEO 仍是地基。Google 也明确：AI features 的最佳实践仍是既有 SEO 基础，不需要额外“神秘优化”；但前提是页面能被索引、能出 snippet，并满足技术要求。

    4.2 GeneralSearch 侧的内容与结构策略

    以“让系统更容易搜到你”为目标，UME 建议的可执行动作是：

    • 做主题 Hub（聚合页）而不是散点文章：用 Hub 把概念、教程、对比、案例、FAQ 串成可遍历的知识网络。
    • 把关键词表改成“问题图谱”：What/Why/How/Compare/Metrics/Pitfalls，把用户真实问法写进 H2/H3。
    • 标题与摘要要可被直接摘取：生成式引擎前置会先看少量信号（URL、标题、描述/摘要），质量会影响“是否值得被 Fetch”。
    • 覆盖同义词与别名：尤其是实体名称、术语、英文缩写、行业俗称，避免“搜得到但不命中你”。

    5. 让 Fetch 读得到且读得对：技术性 GEO 的 P0 清单

    5.1 把 Fetch 当作“更脆弱的爬虫/浏览器”

    Google 将 fetchers 描述为：像 wget 一样通常只做单次请求；这类工具对重试与容错的预期往往更低。
    而在 AI 生态里，这类“用户触发访问”的 agent/fetcher 甚至可能不受 robots 约束：

    • OpenAI 说明 ChatGPT-User 是用户触发访问，不用于自动爬取，且 robots 规则可能不适用。
    • Perplexity 文档也明确：Perplexity-User 支持用户动作，且“由于是用户请求的 fetch，一般会忽略 robots.txt”。

    对内容方的启示：你不能只做“allowlist 某个 bot”，还要让页面对“类浏览器访问”也能稳定可读。

    5.2 P0：别让 AI bot 吃 403

    UME 在技术性 GEO 清单里把它列为第一条：robots.txt 放行不等于服务器放行；WAF/CDN Bot 规则才是常见拦截点。

    落地动作（按优先级）：

    1. 日志按 UA 分桶：统计 200/301/403/429/5xx。
    2. 定位拦截层级：应用（Nginx）→ CDN → WAF → Bot 管理/挑战页。
    3. 放行策略用“IP 段 + UA”组合：对公开 IP 段放行，对异常频率仍限流（尤其是 Perplexity 文档给了 WAF 配置思路）。

    5.3 P0：核心内容必须“在 HTML 里可见”

    技术性 GEO 明确要求：正文、定义、关键表格、FAQ 必须在 HTML 中可见；纯 CSR 至少要有 SSR/预渲染兜底。

    工程验收方法（不依赖复杂工具）：

    • view-source: 是否能看到关键段落
    • curl 拉取 HTML 是否是正文，而不是空壳/挑战页

    5.4 把重定向链压到 1–2 次以内

    UME 指出：不同抓取代理的重试/容错能力不一样，不能假设都像 Googlebot；关键页面要做到最多 1–2 次跳转就到最终 200。

    5.5 用 HTTP 头让“可更新性”更像工程而不是口号

    Google 在 crawling 基础设施文档里提到对缓存与 ETag、Last-Modified 等机制的支持与建议，这会影响抓取效率与更新识别。
    在 GEO 语境下，这属于“新鲜度工程”的一部分：让系统更容易确认你是最新版本，而不是反复抓取旧内容。

    6. 让模型敢引用你：答案工程 × 实体工程 × 证据工程

    UME 的收录逻辑强调：生成式系统通常经历发现→抓取→解析→分块→索引→检索→重排→生成→引用；每一环都有可控杠杆。
    要把“读到了”变成“引用了”，最有效的不是再写一篇，而是把内容工程化成可复用组件：SSOT → 实体页 → 证据卡 → 答案块 → 分发与评测闭环。

    6.1 答案块是 GEO 的最小交付单元

    答案块推荐结构（可直接当 UME 站内写作规范）：

    • 问题句（H3）：用用户问题写标题
    • 短答案（1–2 句）：可被直接摘走
    • 要点（3–5 条）：为什么/怎么做/注意什么
    • 边界条件：适用与不适用
    • 证据位：数据、案例、来源（指向证据卡）

    6.2 实体一致性决定 AI 是否“认得你”

    内容工程里强调：组织/产品/作者/术语命名与关系要稳定、可机读；实体口径漂移是 GEO 常见失败原因。

    最小实体资产建议：

    • Organization（组织页）
    • Product/Service（产品/服务页）
    • Glossary（术语表）
    • Author/Team（作者/团队页）

    6.3 证据卡决定 AI 是否“信你”

    证据卡模板（可复用组件）：

    • 结论句
    • 数据/截图/对比
    • 口径：时间范围、指标定义、样本
    • 方法：如何得到、限制条件
    • 来源：可追溯引用
    • 更新：最后更新时间与负责人

    7. 故障树：到底卡在 GeneralSearch、Fetch 还是 GEO

    现象更可能的根因快速验证解决动作
    AI 总选竞品来源GeneralSearch 候选池进不去用固定问题集看来源分布；检查索引与 Hub 覆盖做 Hub+子页矩阵；补同义问法；提升可见性
    有时提到你，有时不提候选池波动 + 证据不足看是否有稳定实体页/证据位实体页统一命名；关键结论加证据卡
    AI 访问你站点但抓到空内容Fetch 失败或解析失败日志看 403/挑战页/JS；curl/view-source 验证WAF/CDN 放行；SSR/预渲染；去挑战页
    引用了但链接定位不到段落缺少可引用锚点检查是否有段落 id/目录关键段落加锚点 id；“引用此段”策略
    引用你但表述出错实体/边界不清或版本漂移用回归问集对比表述一致性防御性 GEO：边界条件、版本日志、纠错闭环

    8. 监测与指标：把 GEO 做成可审计系统

    8.1 你需要两类“观测面板”

    1. Fetch 面板（站点可用性）
    • Fetch 成功率（200 占比）
    • 403/429/5xx 占比
    • 平均耗时/TTFB
    • 重定向链长度分布
    1. 引用面板（答案份额）
    • 覆盖问题数（question coverage）
    • 引用率（citation rate）
    • Share of Answer（答案份额：答案中出现你/引用你的比例）
    • 表述一致性（同一问题跨时间/跨模型一致性）

    8.2 用可追踪参数识别“AI 搜索带来的回访”

    OpenAI 的发布者 FAQ 提到：ChatGPT 搜索的引流 URL 会自动带 utm_source=chatgpt.com，便于在分析工具中追踪。
    建议你把它纳入 UTM 规则与渠道看板，并对“答案引用→回访→转化”的漏斗单独建报表。

    9. 权限、控制与边界：robots、noindex 与“用户触发 Fetch”

    这一段在 GEO 实操里非常关键，因为很多团队会误把 robots 当成“最终控制开关”。

    9.1 分用途管理爬虫是新常态

    以 OpenAI 为例：

    • OAI-SearchBot 用于搜索结果呈现；
    • GPTBot 用于抓取可能进入训练的数据；
    • ChatGPT-User 用于用户触发访问，且 robots 规则可能不适用；robots 更新生效可能需要约 24 小时。

    Perplexity 也类似：

    • PerplexityBot 用于搜索结果；
    • Perplexity-User 支持用户动作，且“由于是用户请求的 fetch，一般忽略 robots.txt”。

    结论：你要把“搜索呈现”“训练使用”“用户触发访问”拆开做策略决策，再落到 robots/WAF/页面控制上。

    9.2 不想被展示，别只靠 robots

    OpenAI FAQ 提到：即使你禁止 OAI-SearchBot，如果系统从第三方搜索或其它页面拿到了 URL，仍可能只展示“链接与标题”；如果不希望发生，需要用 noindex，但前提是爬虫能访问到页面读取该标签。
    Google 的 noindex 文档也明确：要让 noindex 生效，页面不能被 robots.txt 阻挡，否则爬虫看不到 noindex，页面仍可能出现。

    证据与边界

    证据来源

    • UME 对技术性 GEO 的定义与 P0/P1 工程化清单（可抓取、可解析、可引用、可观测）。
    • UME 对 GEO 收录链路与“被抓取→被引用→被转化”的框架拆解。
    • OpenAI 官方关于 OAI-SearchBot、GPTBot、ChatGPT-User 的用途区分与 robots 生效延迟。
    • OpenAI 发布者 FAQ 对“如何出现在 ChatGPT 搜索”“noindex 与展示控制”“utm_source=chatgpt.com”以及 Atlas 可访问性建议（ARIA）的说明。
    • Google 对 crawlers 与 fetchers 的定义、user-triggered fetchers 的解释，以及缓存/协议等技术属性。
    • Google 对 AI features 的解释（query fan-out、多轮搜索、SEO 基础仍适用）。
    • Perplexity 对 PerplexityBot 与 Perplexity-User 的用途说明，以及用户触发 fetch 往往忽略 robots 的提示。

    适用与不适用边界

    • 适用：内容型网站、B2B 官网、工具/知识库、文档中心、希望提升“被引用/被代表”的品牌与产品团队。
    • 不适用或需谨慎：强登录、强个性化、内容高度动态且不愿做 SSR/预渲染的页面；以及出于版权/合规明确不希望被抓取/展示的资产（应先做授权边界与 noindex 策略）。

      术语定义

      • GEO（Generative Engine Optimization）：面向生成式 AI/对话式搜索的优化体系，目标是让模型在回答相关问题时更倾向引用你并正确归因。
      • GeneralSearch：生成式系统用于“找候选网页/数据源”的搜索工具能力（不同平台名称不同）。
      • Fetch：生成式系统用于“打开 URL 并读取内容”的抓取/读取工具能力；与 Google 所说的 fetchers（代表用户单次请求）在行为上相近。
      • 候选池：生成式检索链路中可被检索与重排的来源集合；进不去候选池就谈不上引用。
      • 答案块（Answer Block）：可被独立摘取复用的最小语义单元（短答案+要点+边界+证据位）。
      • 证据卡（Evidence Card）：把可信度组件化（口径、方法、来源、时间戳、负责人），让 AI 更敢引用。

      关键实体清单

      • 品牌与站点：友觅 UME、growume.com
      • 核心方法论：GEO、技术性 GEO、内容工程、SSOT、实体页、证据卡、答案块、Share of Answer、可观测性
      • 关键技术对象：robots.txt、WAF/CDN、SSR/预渲染、Schema.org、ETag/Last-Modified、UTM
      • 关键生态实体：OpenAI（OAI-SearchBot、GPTBot、ChatGPT-User）、Perplexity（PerplexityBot、Perplexity-User）、Google（AI Overviews、AI Mode、fetchers、Google-Extended）