推荐做法：先补齐 SEO 和 GEO，再评估 WebMCP 是否有真实任务可解决
WebMCP 与 SEO、GEO 有交集，但不是同一件事。把它们放在一起谈，最容易出现两个误判：以为加一个 agent API 就能获得 AI 搜索曝光；或以为只要内容可被 LLM 阅读，agent 就能安全、稳定地完成预约、选品或提交工单。
更实用的划分是：SEO 负责被找到，GEO 负责被理解和引用，agent readiness 负责让机器在网站上完成有边界的任务，而 WebMCP 是最后一层可能采用的浏览器内工具机制之一。
对内容薄弱、产品事实不完整或技术可抓取性有问题的网站，先做 WebMCP 通常不会带来业务价值。对有复杂表单、筛选、配置或重复服务流程的成熟网站，它才值得进入试点清单。
一张表把边界说清楚
| 层级 | 主要对象 | 解决的问题 | 典型工作 | 不应承诺的事 |
|---|---|---|---|---|
| SEO | 搜索引擎与搜索用户 | 页面能否被抓取、索引、匹配查询 | 信息架构、渲染、标题、内部链接、结构化数据 | 让 agent 自动完成交易 |
| GEO | AI answer engine 与用户 | 信息能否被正确理解、复述、引用或推荐 | 直接答案、事实证据、实体清晰度、可提取段落 | 直接提高所有自然排名 |
| Agent readiness | 获授权的 AI agent 与用户 | agent 能否安全地浏览、筛选和完成任务 | 清晰任务流、稳定状态、可恢复错误、权限与确认 | 绕过用户控制 |
| WebMCP | 浏览器中的网站与 agent | 如何把具体页面功能暴露成结构化工具 | 工具 schema、参数、origin 限制、输出边界 | 成为通用 AI 搜索爬虫协议 |
内容可发现、信息可引用、任务可完成、能力可调用是连续关系，但每一层都需要不同的证据。
WebMCP 是什么，不是什么
根据 Chrome 的说明 ，WebMCP 是一项提议中的 Web 标准，允许网站将 JavaScript 功能或 HTML 表单以带有自然语言描述和结构化 schema 的“工具”形式提供给 browser agent。Chrome 提供 imperative API 用于 JavaScript 功能，declarative API 用于标注标准 HTML 表单。
它的价值在于减少 agent 对页面视觉和 DOM 的猜测。例如，旅行站可以提供航班查询和筛选工具，SaaS 可以提供创建支持工单草稿的工具，电商可以提供已授权的商品配置或公开库存查询。
它不是：
- 供搜索引擎抓取和理解网页内容的新 sitemap；
- 让 ChatGPT、Google AI Overviews 或 Perplexity 自动引用页面的保证；
- 后端 MCP server 的替代品；
- 让用户授权、支付验证、服务端权限控制失效的捷径。
截至本文核验，WebMCP 仍在 Chrome 149 起的 origin trial / early preview 中。把它看作需要验证的接口方向，而不是已经稳定的获客渠道。
为什么它会被放进 GEO 讨论里
两者都在回应同一个变化：人不一定亲自阅读全部网页、点击全部按钮。AI 可能先帮助用户比较、总结、筛选，甚至在用户确认后执行操作。
但 GEO 的核心仍是“成为可信的答案来源”。一个产品页应让系统和人都能看懂：产品是什么、适合谁、价格或限制是什么、证据在哪里、与替代方案的差异是什么。即使完全不接入 WebMCP，这些工作仍会提高页面的可用性。
WebMCP 的核心则是“把一个已经存在、已经受权限保护的动作交给 agent”。如果产品说明、价格、库存和退货政策本来就混乱，开放更多工具只会让 agent 更快地传播混乱或在关键步骤失败。
哪些团队应该把 WebMCP 放入路线图
用这个决策表，避免因为“agentic”这个词而启动一个没有任务定义的项目。
| 你的现状 | 当前优先级 | 是否考虑 WebMCP |
|---|---|---|
| 核心页面不能稳定抓取，产品事实分散 | 技术 SEO、内容与实体整理 | 否 |
| 页面可访问，但 AI 回答经常误解品牌或遗漏限制 | GEO、证据与内容结构 | 暂缓 |
| 用户经常在复杂筛选、长表单或配置步骤放弃 | 先做 UX 与事件分析 | 可以寻找一个只读试点 |
| 已有清晰权限模型、可审计服务端 API、可逆操作 | Agent readiness 与安全设计 | 可以进入受控原型 |
| 希望 agent 直接购买、删除或修改敏感资料 | 风险评估与确认体验 | 不作为第一批能力 |
用一个“任务而非协议”的方式开始
不要先问“我们是否应该支持 WebMCP”，而要问“用户正在委托 agent 完成哪一项重复任务？”
一个好的候选任务通常满足四个条件：目标明确；输入少且可验证；结果可预览；失败时能安全退出。例如“筛选符合预算和尺寸的公开商品”比“替用户完成购买”适合作为第一步。
然后按以下顺序判断：
- 页面和服务端已有的用户流程是否本身可靠？
- 需要哪些信息，哪些字段是多余的？
- 工具输出中是否混有评论、第三方内容或敏感数据？
- 这项操作能否先做成只读结果或草稿？
- 用户需要在哪一步确认，确认时应该看到什么？
安全问题不能留到“接入完成后”。详见 WebMCP 安全清单：Agent-Ready 不等于 Agent-Safe ，其中把可信 origin、UGC 标记、读写边界和用户确认转成了发布检查项。
一个 SaaS 例子：支持工单比“全自动客服”更适合起步
假设客户对 agent 说：“把我过去三天的错误信息整理成一个支持请求。”
不成熟的方案是让 agent 读取所有项目、猜测问题、直接提交工单。它可能越权读取资料、把日志中的文本当作指令，或以错误分类创建请求。
较好的方案是：
- 网站先提供用户已经有权查看的、结构化的错误摘要；
- agent 使用只读工具筛选时间范围和项目；
- 网站生成一个工单草稿，而不是提交；
- 用户查看标题、描述、附件和接收团队后确认提交；
- 服务端依旧验证身份、项目权限和字段合法性。
这里 SEO 的作用是让支持文档和产品页面被找到；GEO 的作用是让 agent 和用户理解错误的定义、限制与解决方案；WebMCP 的作用仅是让这段已存在的任务流更少依赖页面猜测。
需要新增的指标，而不是幻想一个“WebMCP 排名”
如果开始原型，衡量方式也应改变。排名、曝光和引用仍要继续看，但不足以说明 agent 工具是否有效。
| 指标 | 要回答的问题 |
|---|---|
| 任务成功率 | agent 是否在不重试或少重试的情况下完成用户授权的目标？ |
| 人工接管率 | 哪一步最常需要用户改写、纠正或接管？ |
| 安全中止率 | 工具是否正确拒绝了越权、未知或风险输入？ |
| 确认后完成率 | 用户在看到影响后是否仍愿意确认？ |
| 内容与答案质量 | 相关页面是否仍被正确理解、引用并导向合格访问？ |
这些指标共同构成 agent readiness 的证据。它们不应取代 SEO 或 GEO 报表，而应与之并列。
结论：把 WebMCP 放在正确的位置
WebMCP 值得持续跟踪，因为它尝试为 browser agent 提供比 DOM 自动化更明确的操作接口。但对增长团队来说，正确顺序比技术名词更重要：先保证页面可发现、可理解、可信；再把高价值任务设计成安全且可验证的流程；最后才决定 WebMCP 是否是实现该流程的合适方式。
如果你需要把这套判断变成站点审计，继续阅读 从 SEO、GEO 到 Agent Readiness：四层网站审计框架 。它将每层的页面证据、风险和 30 天优先级拆开，避免团队一上来就在实验协议上花掉全部精力。
FAQ
WebMCP 与 Model Context Protocol 是同一个东西吗？
不是。两者共享“工具”和 schema 等词汇，但 WebMCP 关注浏览器中当前网页的前端功能与 DOM 交互；MCP 通常面向后端服务、数据源或本地工具。二者可以互补。
做 GEO 是否必须接入 WebMCP？
不必。大多数 GEO 基础工作是内容质量、实体事实、证据、页面结构和技术可访问性。只有当用户确实需要 agent 在站内完成复杂任务时，才需要考虑 WebMCP。
WebMCP 是否只适合电商？
不是。客户支持、旅行搜索、SaaS 配置、预约和数据筛选都可能适用。共同点不是行业，而是存在明确、可限制、可确认的用户任务。
来源与核验范围
作者：Maya Ellison，Auspia 12 年 GEO 策略研究员。Maya 关注 AI 搜索可见性、品牌实体清晰度，以及增长团队可落地的 GEO 运营体系。
