你的官网能被 AI 读到，但它能被 AI 用吗

直接回答：企业做 GEO 一直只解决了「AI 能不能看到你、引用你」——这是语料取用权。2026 年 10 月，第二件事发生了：AI 开始在你的官网上直接办事——这是工具调用权。这两套准入不是并列的两道门，是入口与深水区的关系：调用权必须站在取用权里面才生效，没有「只做第二套」这条路。而大多数企业现在把全部预算、人力和认知都押在第一套上，第二套连门都没开。

先把证据摆出来，再说门怎么开。

两件同期发生的事，指向同一个方向

第一件：WebMCP 从规范草案走进了采用期。 截至 2026 年 10 月 06 日，注册 WebMCP 工具站点的目录 webmcp.com 已列出 2,959 个站点（本日实测该注册表首页计数）。同一天可查证的支持面包括：Shopify 已把 WebMCP 工具自动加到全部 Liquid 店面，并为结算（checkout）补充了工具（来源：Shopify 开发者更新日志）；Chrome 与 Edge 通过 Origin Trial 开放开发者报名接入，Brave 已原生支持（来源：PromptArmor 威胁情报解读《What is WebMCP and what are the risks?》，2026年10月06日）；智能体浏览侧，ChatGPT 的内置浏览器以「Site tools」名义支持，Cloudflare 在 Browser Run（智能体浏览）链路中支持（来源同上）。

2,959 这个数字要说明性质：它是注册表自报口径，未经独立审计，且未区分试验站与商用站。

第二件：Google 用结构化接口取代网页抓取。 据 AI HOT 精选（2026年10月07日）转述，Google 发布 Developer Knowledge API 生态，以结构化 API 与 Markdown 形式的官方文档取代网页抓取，支持语义与关键词检索、文档分块和有依据的问答，并提供 CLI、agent skill、客户端库等多个入口。该条原始发布页本日未能取到（网络层失败），描述以二手摘要为准，本文标注未核实。

这两件事放一起看，方向就不再含糊。

WebMCP 是让网站把「能做的事」交出去。 它的机制是网页在自己的代码里注册一组工具。每个工具三样东西：名字、描述、输入结构（JSON Schema）。电商站会注册 search_products 和 update_cart，SaaS 站会注册 create_ticket、update_record。智能体访问该页面时，看到的不再是一堆待猜的按钮，而是一份写明白的清单。过去它得截图、猜哪个是按钮、点错了退回来重试；现在它按名字调用函数（来源同上）。

Google 的做法是让知识本身变成接口。 官方文档不再只等被抓，而是主动以机器可读的形式供给。

一头是企业把动作交出去，一头是平台把知识交出去。同一条链上的两端。

有人会说，这算什么新东西

官网早就有在线下单、预约、询价表单，机器通过接口也能调。这个反问必须回答，否则整篇文章的戏剧性是虚的。

差别在两处，都不在「能不能做」，而在谁承担约定成本。

第一处是约定方式。 以前每一个智能体想对接你，都得单独谈一次接口、单独过一遍权限；谈不成就算了。WebMCP 把约定写进页面，智能体自带一套读法。接入的边际成本，从「一对一谈判」降到「一次声明」。

第二处是谁来维护。 以前那套接口是另一条要单独维护的通道，很容易和页面本身走岔。现在声明写在页面里，和按钮走同一段代码。

所以这不是能力从无到有，是接入成本从高到低。 商业史上，成本降一个量级的接口，通常比能力新增一个档位的接口扩散得快——因为前者不需要谁改主意，只需要谁算一次账。

这里有一个必须说准确的边界

这段很重要，因为它决定你该花多少钱。

WebMCP 不解决「被找到」。 官方文档明确写着：客户端和浏览器必须实际访问一个站点，才能知道它有没有可调用的工具。工具注册在页面里，跑在打开的那个浏览器标签页里，没有可供爬虫抓取的工具文件，也没有可提交索引的入口；ChatGPT、Perplexity、Google 目前都没有公开文档说明会在「决定引用哪些页面」时读取工具声明（来源：Chrome for Developers WebMCP 文档「限制」一节；分析见 jpldigital.ca《WebMCP Is Not AI SEO》）。

这句话的含义是：在智能体看到你的工具之前，它已经先选中了你的站。 找到发生在更早的一环。

所以这件事的门槛顺序是清楚的：

四行里只有最后一行是 WebMCP 的战场。 前三行还是 GEO 的老战场，一行没变。

这也是为什么开头那句话要说「入口与深水区」，而不是「两扇门」。 两扇门可以分头推；入口和深水区不能。你的站抓不到、不被引用，工具声明得再齐，智能体根本来不了。

这意味着企业要维护两套东西

把上面的门槛顺序翻译成工程语言，企业面对的是两张清单，各自独立。

第一张：语料清单（你对 AI 说什么）。

• 官网是否允许主流 AI 爬虫抓取，robots 有没有把该放行的拦掉；
• 核心问题有没有答案前置的页面承接，比如「XX 服务多少钱」「XX 和 YY 的区别」；
• 结构化数据是否与正文一致，FAQPage、Article、BreadcrumbList 是否齐全；
• 事实口径是否唯一，同一件事在公司官网上和在第三方资料里是否是同一个数。

第二张：工具清单（你在自己的页面上，允许 AI 做什么）。

• 有哪些任务本来就在你页面上完成。查询、预约、询价、下单都属于这一类；
• 这些动作有没有被声明成工具。声明的字段就三样：名字、描述、输入结构；
• 哪些标成只读、哪些能写数据，标注是否与实际行为一致；
• 出错了返回什么，是一句能读懂的话，还是一串异常码。

两张清单不共享答案。 语料做得好，工具一个没声明，智能体到了你的页面照样只能猜按钮；工具声明得再齐，页面抓不到、不被索引，智能体根本来不了。

通问AI 的判据：一张清单不够，得有两张

上面这段讲的是通用逻辑，任何讲 GEO 的人都可能讲得出来。这里给一个更硬的判据，也是通问AI 在做知识库时反复强调的那件事。

判断一家公司的 GEO 做到第几层，看它维护几张清单。

• 第一层：维护一张——语料清单。做完发出去，写完就结束。绝大多数公司停在这里，包括很多对外卖 GEO 服务的公司。
• 第二层：维护两张——语料清单加工具清单。第二张是活的。产品改了它要改，权限改了它要改，页面上新开一项业务，它也要改。

这两张清单在工作方法上是同一件事，所以第二张才做得出来。 通问AI 在做自己的品牌知识库时，把这件事拆成两层：一层是基础信息表，收公司名、产品、价格、资质、案例这些对外事实，作为全公司唯一权威口径，所有内容都从这里读；另一层是事实白名单，把可引用的数字和名称单独抽出来，用来卡内容的 0 幻觉。

通问AI 早就在用这套办法管自己的对外表达：一张管事实怎么说，一张管数字哪里来。今天要加的是第三张——动作清单，管机器能在你页面上做什么。

这个顺序本身就是答案。 先有事实的单一权威，才谈得上动作的单一权威。一家连「我们公司到底叫什么、价格是多少」在三个平台上说法都不一致的公司，不可能把「哪个动作可以被机器执行」管理清楚。

许教授的拆解方法在这里可以直接用：「只有怎么做的问题，没有要不要做的问题。」（许教授金句库 L718，7-04，GEO 结论句）这句话他讲的是当年要不要做 GEO，本文把它借过来看今天这件事，属于作者的引申。他当时讲的不是 WebMCP。但换成今天这道题，逻辑一样——问「要不要」的时候，答案通常已经由同行的进度替你写好了。

数据还没验完，这件事要诚实说

不能只讲好的一面。

第一，收益数字目前是厂商口径。 官方表述是这能提升智能体执行的速度、可靠性和精度，但没有给出数字；二手渠道流传过两个数字：约 67.6% 的 token 削减，97.9% 的任务成功率。这两个数字尚未在独立基准中被复现，本文只作标注、不作依据（来源：Chrome for Developers 与第三方分析文的差异，见 agentpatterns.ai 与 jpldigital.ca 的对照）。

第二，它的适用面比多数人想的窄。 工具活在页面的执行环境里，需要一个打开的标签页。后台任务、CI 跑批、服务端定时任务这类无头场景用不上，那些场景仍应走服务端 MCP 或既有 API。对没有前端交互投入预算的长尾站点，浏览器自行解析现有的表单标签和无障碍语义，比一个永远发不出去的 registerTool 调用更现实。

第三，它引入了新的风险面。 供应链侧，工具是页面 JavaScript，第三方脚本被污染、扩展被劫持，都能在用户会话里注册或改写工具；治理侧，改动工具可能不需要 OAuth 应用、MCP 服务器或集成申请，安全团队没有既有的评审节点；披露侧，工具描述与返回值可以被用来影响智能体判断，而页面外观不变；配置侧，标为「只读」的工具可能实际写数据，而很多 AI 客户端正是靠这个标注来决定要不要在调用前加人工确认；还有一类是操作漂移——用户看着页面说一件事，智能体通过工具做了另一件事（来源：PromptArmor 同一篇解读）。

第四，工具被调用不等于成交。 最需要防的场景是：智能体调完你的 search_products，拿着你的价格去别家下单。这时候你的工具清单等于一份帮对手比价的免费接口。 你以为在做「让 AI 更好办事」，实际做的是「让比价更容易」。

哪些企业适合现在就评估 WebMCP？ 手里有已登录、有前端交互场景的站点，比如电商、SaaS、预约与票务——页面里本来就有大量任务值得被机器执行。哪些先别急？ 内容型官网、电话与表单就能完成转化的服务型企业，眼下把语料清单做扎实的回报更高。

这一条要说得更直白些：门开着不亏，只对上面第一类企业成立。内容型官网不一样——它门上挂的工具没人来用，反而多出一份要维护的声明和一组要被审计的权限标注；这种情况下「开门」是负收益。

还有一个前提，比前面所有分析都重要

到这里讲的都是「第二套怎么建」。但有一个更前置的问题必须先答：你现在的客户里，有几个是通过 AI 进来的？

如果这个比例接近零，那么对多数读者来说，今天最该做的事可能不是研究 WebMCP，而是把第一套做透——它便宜、成熟，而且客户已经在那儿了。第二套是新增项，不是替代项。

这个数字不用猜，可以自己测，成本是零：去你的服务器日志或访问分析里，筛一遍 referrer 里带 AI 来源的流量——chatgpt.com、perplexity.ai、doubao.com、claude.ai 这些域。这个数字是多少，就是你现在该往第二套上投多少的答案。 如果一周下来接近零，先做第一套；如果已经能看见，第二套的门就该研究了。

本文无法给出这个比例的行业均值，也不打算给。标注未核实，且它本来就因行业而异——自己测出来的那个数，比任何行业报告都有用。

现在就能做的四件事

第一步，先定义「调用位次」。 给自己定一个可观测的目标：当客户用 AI 问「谁做 XX、怎么收费、能不能约」，你的核心动作是第几个被智能体执行的。参照 GEO 里「问答位次」的做法，把它当作月度指标，而不是感觉。

许教授讲 GEO 时给过一条操作层面的硬约束：「AI 不喜欢中文铺垫。要答案前置，先把答案放在最前面 80-200 字。」（许教授金句库 L535，2026-06-27 实战营1）他讲的是语料怎么写。工具说明写的是同一种东西——工具的描述字段就是给机器看的「前置答案」，它决定智能体敢不敢调你这个工具。这是本文的类比，不是他本人对 WebMCP 的表态。

第二步，盘出你的动作清单。 把官网上「本就需要完成的事」列出来。列的不是页面，是动作。查询、试算、预约、下单、提交、退款、改期各算一条，每一行对应一个候选工具。判断标准只有一条：这件事是人登录后在页面上做的吗？ 是，它就有资格成为工具。

第三步，先确认你能不能看见调用。 WebMCP 的工具跑在用户浏览器标签页里，调用日志落在哪一端，目前没有公开文档给出明确答案（本文标注未核实）。可以探的两条路径：页面内埋点，或把工具调用转到你自己的服务端接口再记账。在为「调用位次」定月度指标之前，先确认你能不能拿到这个数——拿不到，指标就是空的。

第四步，把人工确认点标出来。 哪些动作一旦执行就产生金钱、法律或隐私后果——下单、退款、删除、对外发送。这类动作应当设定人工确认，并且标注要与实际行为一致——标了只读却写数据，是最容易在半年后变成事故的配置。

常见问题

这两张清单，谁来跟你一起过

一个判断

本文由通问AI内容团队整理，最后更新于 2026年10月08日。文中采用数据为 2026年10月06日 快照，注册表数字会随登记情况变动。新闻事实均标注来源与日期，二手来源与未核实项已逐处标注；人物观点引用逐字取自对应金句库并标注行号，凡晚于素材截止日的引申均已显式标注为作者引申。

通问AI®（杭州造数引擎智能科技有限公司）· 帮有商业基础的人用AI赚钱。