popnetmedia/ai-search-readiness

AI 搜索就绪度

三个关键步骤。它们不涉及内容质量——那由 non-commodity-content 管理。它们决定一个网站是否能被代表客户的机器发现、报价并进行交易。

一个网站即使通过了所有内容规则，也可能对代理不可见，因为它从未发布过数字，也从未暴露过机器可读的预订端点。

---

步骤 1：发布价格范围

规则。 每个商业网站都应发布其服务费用。不是价目表，而是一个范围，包含两端以及决定其中数值变动的因素。

人们经常向 AI 询问各种东西的价格。如果 AI 无法给出报价，就会把用户引向那些发布过价格的竞争对手。“电话询价”对机器来说是个死胡同，对用户来说也越来越如此。

最少需要发布的内容：

• 最低端和最高端，作为实际数字
• 影响价格的因素：决定工作落在范围哪一端的两三个变量
• 范围测量日期，紧挨着数字旁边
• 每项固定费用，完整列出：配送费、安装费、押金、清洁费、最低消费、罚金
• 指向实时来源的链接，以获取精确报价

常见反对意见及回应。 经营者反对是因为价格会变动，他们担心被一个过时数字束缚。这种反对意见针对的是当作唯一价格公布的单个固定价格，而不是价格范围本身。一个注明日期、并说明了驱动因素的价格范围比沉默更准确，而且是经营者自己最能说清楚的事情。

解决问题的规则。 永远不要只发布一个裸费率。请这样发布：

整个船队的每晚费用在 106 美元到 175 美元之间，测量日期为 2026 年 9 月 18 日。选择哪款露营车和哪些日期决定最终价格。查看您的日期以获取确切费率。

而不是：

露营车每晚 106 美元起。

不要重复输入价格。 在构建时，从企业已维护的来源读取价格：预订平台的 feed、POS 系统、已发布的费用表。直接输入到页面上的价格，一个月内就会与结账页面不一致。如果数字是从运营商自己的页面解析出来的，两者就永远不会出现偏差。

如果确实无法发布费率（例如按项目报价，或由第三方设定），页面仍然需要提供所有固定的、与费率相邻的信息：费用表、最低消费、押金、更改预订的罚金。然后清楚地说明费率本身是按报价设定的，并指明获取报价的位置。一个说“我们不发布 X，原因如下，获取方式如下，以及所有不变的信息如下”的页面，胜过什么都不说的页面。

任何定价页面的发布前检查清单：

• 范围的两端都是实际数字，不是“起”
• 影响价格变动的因素已明确命名
• 测量日期紧挨着数字
• 所有固定费用均已完整发布
• 数字在构建时从来源读取，而非手动输入
• 结构化数据携带与正文相同的数字（参见步骤 2）
• 对于无法定价的内容，页面已说明并指向报价来源

---

步骤 2：支持代理的调度

规则。 如果客户的代理看不到如何与日历进行交易，那么该业务对它就是不可见的。代理式预订已经存在：助手会预订餐桌、服务电话、租赁。它首先查找结构化数据，其次才是 DOM。

三个层次，全部必需。

1. 结构化数据中的报价。 每个可预订的项目都携带一个包含实际价格或 priceSpecification 范围、货币、可用性状态和与测量日期匹配的 priceValidUntil 的 Offer。仅在企业级别设置 priceRange 是不够的；机器需要的是被要求预订的那个项目上的报价。

"offers": {
  "@type": "Offer",
  "priceCurrency": "USD",
  "priceSpecification": {
    "@type": "UnitPriceSpecification",
    "priceCurrency": "USD",
    "minPrice": 106,
    "maxPrice": 175,
    "unitCode": "DAY",
    "referenceQuantity": { "@type": "QuantitativeValue", "value": 1, "unitCode": "DAY" }
  },
  "availability": "https://schema.org/InStock",
  "priceValidUntil": "2026-12-31",
  "url": "https://example.com/book"
}

2. 动作。 实体携带一个 potentialAction，指明预订端点、HTTP 目标及其所需的输入参数。这是几乎没有人发布的部分，也是代理实际需要的部分。

"potentialAction": {
  "@type": "ReserveAction",
  "name": "预订此露营车",
  "target": {
    "@type": "EntryPoint",
    "urlTemplate": "https://example.com/book?rental_id={rental_id}&from={checkin}&to={checkout}",
    "actionPlatform": [
      "https://schema.org/DesktopWebPlatform",
      "https://schema.org/MobileWebPlatform"
    ],
    "httpMethod": "GET"
  },
  "result": { "@type": "Reservation", "name": "露营车租赁预订" },
  "object": { "@type": "Product", "name": "2023 Jayco Jay Flight" }
}

选择与动词匹配的动作类型：预订或保留用 ReserveAction，预约用 ScheduleAction，购买用 OrderAction，活动用 RsvpAction。

3. 作为数据而非文本发布的约束条件。 一个预订了企业无法兑现的住宿的代理，浪费了每个人的时间。发布那些会导致预订失败的规定：

• 最小和最大时长
• 提前期和截止时间（availabilityStarts、advanceBookingRequirement）
• 资格要求（最低年龄、驾照、押金）
• 服务区域（areaServed），以及到达每个区域需支付的费用
• 营业或配送时间窗口（当到达时间受他人限制时）

将这些约束条件放入 Schema 中存在对应属性的地方，并在页面上用简单句子描述 Schema 中没有对应属性的内容。两者都必须有：代理读一个，用户读另一个，且它们必须一致。

代理可读的渲染。 关键内容需服务端渲染、使用语义化 HTML、真实的标题、替代文本、使用 <table> 表格。代理读取 DOM 和可访问性树。仅在客户端 fetch 后才出现的内容，是代理看不到的内容。

不要虚假宣传能力。 仅在端点确实接受预订时才发布 ReserveAction。指向联系表单的动作是一个谎言，代理会据此行动，而客户会在最糟糕的时刻发现。如果预订确实需要通过电话进行，请在 Schema 中发布电话号码，并且不要发布保留动作。

协议层次，以及该构建哪一个

存在三个层次。它们不是替代关系，而是堆叠的，顺序很重要，因为较低的层次现在就已经被读取，而较高的层次大多尚未被读取。

第 1 层：结构化数据（始终优先构建）。 如前所述的 Offer 加 potentialAction。这是当今的助手在回答关于企业的问题以及点击链接执行操作时实际消费的内容。它只需要一页 JSON-LD 并且能立即工作。

第 2 层：机器可读的 feed。 一个稳定的 JSON URL，包含目录：可租或可售的物品、每件物品的价格、约束条件、预订 URL 及其测量日期。没有协议承诺，没有需要维护的端点，任何代理、爬虫或兄弟站点都可读。成本低，并且是后续轻松构建第 3 层的基础。

第 3 层：A2A（Agent2Agent）。 用于代理间任务委派的开放协议：一个位于知名 URL 的代理卡片，描述代理的身份、技能和认证；以及一个通过 HTTPS 通信的 JSON-RPC 端点，接受任务并返回结果。当客户助手应该能够提问并获取答案，而不是读取页面时，这是正确的解决方案。

要诚实说明其现状。截至 2026 年底，还没有消费者助手会定期爬取代理卡片的注册表，因此发布代理卡片是对未来发现机制的押注，而非本季度即可获得的预订来源。当企业有代理真正需要询问、而静态 feed 无法回答的信息（通常是实时可用性）时，才构建它。

诚实规则在这里最为严格。 代理卡片声明了技能，其他代理会调用它们。只声明端点真正能做的事情。大多数小型运营商根本无法通过代理间通信完成预订，因为支付、保险和租赁合同都位于第三方平台内部。这没关系，卡片应该如实说明：

{
  "name": "示例租赁预订助手",
  "description": "回答单个车队的价格和可用性问题。无法收款。",
  "skills": [
    { "id": "check-availability", "description": "查询两个日期之间有哪些单元空闲" },
    { "id": "quote-stay", "description": "计算某个单元和日期的总价，包括按城镇配送费用" }
  ],
  "capabilities": { "streaming": false, "pushNotifications": false }
}

一个声称拥有 book-stay 技能但最终导致重定向的卡片，与一个指向联系表单的 ReserveAction 是同样的失败，只不过另一端是机器而不是人。

支付。 代理支付轨道（作为 A2A 扩展的 AP2，以及竞争性代理电商规范）发展很快，但大多数预订平台尚不支持。不要围绕它们设计结账流程。将结账交回给平台自己的系统，并在卡片中说明这一点。

任何可预订页面的发布前检查清单：

• 包含价格或价格范围、货币、可用性、priceValidUntil 的 Offer
• 包含代理可以调用的真实 EntryPoint 的 potentialAction
• 动作的 URL 模板参数与预订系统实际接受的参数一致
• 最低消费、提前期、资格要求和服务区域已作为数据和文本发布
• Schema 中的每个数字与文案中的数字匹配
• 页面在服务端渲染其预订事实
• 没有为不存在的能力发布任何动作

---

步骤 3：来自真实问题的内容

规则。 客户实际问的问题就是内容。每一个电话、每一封邮件、每一个“预订前问题”都是一个页面或一个章节，用客户自己的语言在公开场合回答。

Google 自己的指南说，通用的建议类内容（“夏季的 7 个小贴士”）不会获胜。获胜的是高度具体和真实的内容。客户今天早上问的问题，本身就是一个这样的内容，因为从公开来源写作的竞争者根本不知道这个问题被问过。

操作习惯：

1. 逐字记录问题。 使用客户的原话，而不是行业术语。“你能在我家修屋顶的时候把它送到我家吗？”是查询内容。“住宅放置物流”则不是。这与写搜索者的关键词是同一规则。
2. 在读者所在的位置回答问题。 在问题出现的页面上回答，而不是在没人能到达的博客文章中。
3. 用来源回答问题。 没有来源的回答只是观点；固定费用、已发布的规定、测量得到的数字才是值得引用的依据。
4. 说明哪些答案不是由你给出的。 如果答案属于第三方——委员会、保险公司、公园——请说明情况，并指明应当询问谁。这句话本身就是一项资产。
5. 维护一份只有运营商知道的信息清单。 每个项目都维护一个开放问题文件。这些答案就是别人无法复制的内容，而该文件就是采访议程。

FAQ 区块面向读者，并使用 FAQPage 标记，因为它清楚地表明了页面回答的问题。 它们不是获得引用的杠杆。第一手的具体性是。

---

三者如何配合

读者从一个引用了价格范围的 AI 答案中到达。页面确认了该数字，说明了影响价格的因素，并回答了读者实际有的问题。然后他们的代理进行预订，因为报价和动作已作为数据发布。

任何一个环节缺失都会破坏链条。一个内容优秀但没有公布价格的网站，不会被报价。一个有价格但没有动作的网站，无法被交易。一个既有价格又有动作但内容笼统的网站，首先就不值得被报价。

来源

1. Danny Sullivan 主题演讲，Google Search Central Live 多伦多，2026 年 4 月，关于非商品化内容。
2. AI 优化指南，Google Search Central，关于代理可读性和查询扇出。
3. schema.org 的 Offer、UnitPriceSpecification、ReserveAction、EntryPoint。
4. A2A（Agent2Agent）协议，Linux 基金会，关于代理卡片和 JSON-RPC 任务接口。