用这套框架的前提：先问“AI 会在哪一步让用户失败”
网站的 AI 准备度不是一个分数，也不是加上 llms.txt、schema 或 WebMCP 后就自动达成。真正的问题是：当搜索引擎、answer engine 或获授权的 agent 接触到你的站点时，它能否找到正确页面、理解事实、在回答中不歪曲品牌，并在用户要求操作时安全地完成任务？
这四个问题对应四层审计：可发现、可理解、可引用、可执行。修复顺序从下到上。底层出问题时，上层的优化通常只是漂亮但不稳定的补丁。
这篇是一个审计与优先级框架，不是“把网站做成全自动 agent”的主张。对于多数企业，做到前三层已经能解决更大的 SEO 和 GEO 问题。第四层只适用于确实有 agent 任务价值、权限边界和确认体验的场景。
从下往上修：可发现是基础，可理解建立事实，可引用赢得答案资格，可执行才进入 agent 任务。
第一层：可发现（Discoverable）
这一层仍是 SEO 的地基。页面需要能被合适的 crawler 访问、渲染、抓取和索引；重要页面还需要通过站内链接和规范化 URL 被找到。对 agent 来说，稳定 URL、可用 HTML、清楚导航和可预测状态同样重要。
检查证据：
- 重要产品、服务、文档、政策和帮助页有稳定且可索引的 URL；
- robots、认证墙、JavaScript 渲染和 canonical 没有无意阻断重要内容；
- 关键事实不只存在于图片、视频或登录后界面；
- 站内链接把核心任务页与支持证据页连接起来；
- 页面加载失败、空状态和地区/语言跳转有可解释的替代路径。
常见误区是只检查博客是否被索引，却忽略价格、限制、退货、集成、库存和支持政策页面。这些往往是 AI 回答和 agent 决策中最需要核对的信息。
第二层：可理解（Understandable）
这层要求系统能准确知道“你是谁、你提供什么、适合谁、有什么条件”。它比关键词覆盖更接近实体与产品事实管理。
每个高意图页面都应有一段能独立成立的答案：定义产品或服务、指定受众、说明关键限制、链接到证据。不要让用户和模型从三段营销文案里猜价格模式、适用地区或兼容性。
| 页面类型 | 必须能被直接理解的事实 | 常见缺口 |
|---|---|---|
| 产品页 | 类别、使用对象、核心能力、限制、价格或询价条件 | 只有口号，没有边界 |
| 服务页 | 服务范围、地点、交付物、资格与预约方式 | 地点和适用场景藏在 FAQ |
| 比较页 | 比较标准、版本日期、相同与不同之处 | 只攻击竞品，不给依据 |
| 帮助页 | 问题、前置条件、步骤、失败原因 | 步骤无法独立执行 |
| 政策页 | 生效日期、地域、例外和联系方式 | 旧版本与新页面互相矛盾 |
第三层：可引用（Citable）
GEO 的目标不只是“出现品牌名”。更好的目标是让系统在回答具体问题时，能复用一段清楚、有来源、有边界的内容，并且不把品牌或规则说错。
可引用不等于堆 FAQ。它通常来自一组更基础的页面特征：直接回答；可核验事实；命名清晰的实体；与声明匹配的证据；可区分的章节；必要时的日期、地域和限制。
检查时挑 20 个真实的买家、支持或比较问题，而不是泛泛地问“推荐一个工具”。记录每次回答中：是否提到你、是否链接或引用正确 URL、是否把核心事实说对、是否遗漏重要限制。两到四周复测一次，并将错误类型映射回页面。
引用不是单一的“有或没有”：品牌被提及、来源正确、事实准确和限制保留应分别记录。
第四层：可执行（Actionable）
这一层才是 agent readiness 的任务面。它要求网站将真实任务拆得足够清楚：输入是什么，权限来自哪里，结果如何预览，哪里必须确认，失败后如何恢复。界面本身仍然必须可用；agent 只是新增的协作者，不是绕过正常安全模型的超级用户。
WebMCP 是可能的实现途径之一。它允许在浏览器中将 JavaScript 功能或 HTML 表单定义为结构化工具，减少 agent 对 DOM 的猜测。但不要因为协议存在就把第四层写进路线图。先证明任务值得自动化，并完成威胁建模。
如果你正在评估这一层，请先阅读 WebMCP、SEO 与 GEO：AI Agent 网站优化到底在优化什么？ 。若准备做原型，则必须使用 WebMCP 安全清单 中的可信 origin、不可信内容标记、读写边界与用户确认要求。
一张优先级矩阵：不要把低层问题包装成高层创新
| 发现的问题 | 所在层级 | 风险 | 下一步 |
|---|---|---|---|
| 产品页只能靠客户端接口显示，抓取到空壳 | 可发现 | 高 | 先解决渲染与可访问内容，再谈 GEO |
| 品牌页面没有受众、价格条件和限制 | 可理解 | 高 | 建立事实卡与产品/服务页面模板 |
| AI 回答会提到品牌，但总漏掉地区限制 | 可引用 | 中高 | 在相关页面前部增加可核验的范围说明，重测 prompt |
| agent 在筛选时经常选错过滤条件 | 可执行 | 中 | 先改善表单状态、标签与错误信息，再评估结构化工具 |
| agent 可读取评论并直接创建退款 | 可执行 | 极高 | 停止自动化，做权限、UGC 和确认流程的威胁建模 |
这张表也解释了为什么“WebMCP 是否影响 SEO”问错了重点。若你在第一层有抓取问题，WebMCP 不会修复。若第三层缺少可信事实，工具不会凭空制造引用资格。它只可能改善第四层一个已被验证的用户任务。
30 天行动计划：从证据开始，而不是从新协议开始
第 1 周：选范围与基线
选一个产品线或一个高价值服务，不要全站同时审。列出 10 个关键 URL、20 个真实问题、3 个高频任务。记录索引与渲染状态、页面事实缺口、AI 回答的错误类型，以及每个任务的人工完成路径。
第 2 周：先修发现与理解
修复阻断抓取、错误 canonical、空壳渲染、过期政策和断裂内链。为最重要的页面加入清楚的定义、受众、限制、证据与下一步。不要在没有事实审核的情况下批量用 AI 重写。
第 3 周：建立引用测试
用同一组问题测试相关 AI answer surfaces，记录来源 URL、回答准确性、限制保留、竞争对手出现情况和用户可能的下一步。根据错误模式更新页面，而非只盯品牌提及次数。
第 4 周：选择一个安全的任务原型
只有前三层没有明显阻塞时，才挑一个公开、只读、低影响任务。定义输入和输出 schema，保留人工确认和失败回退。若返回 UGC 或第三方数据，先完成安全审查。Chrome 的 WebMCP 安全指南 强调：untrustedContentHint、readOnlyHint 和精确的 origin 暴露是工具作者的责任。
评分时看证据，不要迷信总分
你可以使用 Auspia Agent Readiness Score 做首轮盘点，但总分只适合排队，不适合替代判断。一个站点即使有很好的内容结构，只要订单查询错误地暴露给不可信 origin，第四层就不能被判为“就绪”。反过来，一个从未实现 agent 工具的站点，也可能在前三层非常强，已经具备优秀的 SEO 与 GEO 基础。
建议为每层保留三类证据：页面样本、真实测试结果、明确负责人。这样当 AI 平台或 Web 标准改变时，团队更新的是证据和流程，而不是重新追逐一个新标签。
FAQ
四层都必须做到才能做 GEO 吗？
不需要。GEO 重点在可理解与可引用，并依赖可发现这个基础。可执行层适用于 agent 需要实际完成站内任务的业务场景。
llms.txt 属于哪一层？
它最多是发现或指引层的补充信号，不能替代可访问页面、清楚事实、证据或测试。是否被某个平台使用也应以官方支持和实际验证为准。
如何选择 20 个 AI 测试问题？
优先选择已有搜索需求、销售或客服记录支持的问题：产品适用性、比较、价格条件、地域可用性、设置步骤、限制与故障排除。每个问题都应能对应到一个需要负责的页面。
WebMCP 是第四层的唯一选择吗？
不是。许多任务先通过更好的表单、稳定的 API、可访问 HTML 和明确的确认步骤就能改善。WebMCP 是 browser agent 的结构化接口候选方案，且目前仍在早期阶段。
来源与核验范围
作者：Ethan Marlowe，Auspia 500+ Prompt GEO 衡量负责人。Ethan 专注于 prompt 跟踪、引用报告、可见性仪表盘和 AI 回答质量检查。
