AI 助手是怎么读价格页和联盟计划页的

AI 助手读价格页和联盟计划页的方式，是抓取 HTML、从里面提取能找到的数字，而其中很多并不执行 JavaScript。Vercel 在 2024 年 12 月对其网络流量的分析发现，它研究的主要 AI 爬虫都不渲染 JavaScript，点名了 OpenAI 的爬虫、Anthropic 的 ClaudeBot 和 PerplexityBot，而 Gemini 和 AppleBot 会渲染 [2]。所以，一个只有在脚本运行后才出现的价格或佣金比例，对买家或创作者正在询问的那个助手来说，可能根本不存在。解决办法很朴素：把每个数字放进首屏 HTML，在所有页面上用一致的方式只写一次，再加上与可见文字一致的 schema.org 标记。本文说明抓取器能看到什么、哪些标记有用，并给出一段条款改写前后的对比。

AI 助手是怎么抓取价格页的？

访问分两种，行为不同。一种是爬虫，提前访问页面、建立索引，助手之后在索引里搜索。另一种是由用户提问触发的抓取：有人问“这个工具多少钱？”，助手当场去取页面。OpenAI 对两种都有说明：OAI-SearchBot 用于在 ChatGPT 搜索中展示网站，GPTBot 收集可能用于训练模型的内容，ChatGPT-User 在用户提问或使用外部操作时访问页面；OpenAI 还说明 ChatGPT-User 不会自动爬取，robots.txt 规则可能不适用于它 [1]。

两种访问有同一个实际限制：它们读的是服务器发来的内容。浏览器下载 HTML、运行脚本、调用你的价格接口，再把结果画出来。不执行脚本的抓取器在第一步就停了。如果你的价格表是一个 React 组件，在页面挂载后才从接口加载套餐数据，抓取器看到的就是空容器，以及你留在里面的占位文字。

Vercel 的分析是这方面最清楚的公开证据。它报告说 ChatGPT 和 Claude 的爬虫会下载 JavaScript 文件但不执行；Gemini 因为使用 Google 的基础设施而能渲染 JavaScript；AppleBot 用基于浏览器的爬虫渲染 [2]。它还指出，首个 HTML 响应里已有的内容，包括 JSON 数据，仍可能被索引。爬虫会变，2024 年的测量不能保证 2026 年的情况，但这足以成为按“做得最少的抓取器”来设计页面的理由。

HTML 与 JavaScript 渲染的价格：抓取器看到什么

你一分钟就能自己测。不用浏览器请求你的价格页，比如用 curl，然后在响应里搜美元符号。如果原始 HTML 里能看到套餐价格和佣金比例，不渲染的抓取器也能看到；如果看到的是加载动画、一个带 id 的空 div，或者一个稍后才“激活”表格的 script 标签，它就看不到。

三种常见做法表现不同。静态页面或服务端渲染页面在第一次响应里就发出完整表格，所有抓取器都能读。在服务端渲染、再在浏览器里激活的框架页面，只要数据是在服务端获取的，也会发出完整表格；在多数现代框架里，用服务端组件或构建时加载数据时这就是默认行为。而页面加载后才向接口请求价格的单页应用，什么有用的都不发，数字只存在于浏览器里。

也要注意部分可见的情况。月付和年付的切换按钮，常常只渲染一套价格，再用 JavaScript 换成另一套，抓取器只看到默认那套。常见问题的折叠面板有时只在点击时加载答案。按访客位置切换的货币，可能给来自数据中心的抓取器显示一种你没想到的货币。对每一种情况，都要确保默认 HTML 里是你最希望被引用的版本，并在旁边用纯文字写出另一版本：“每月 $49，或按年付费每年 $490”。

为什么各页面数字一致比结构化标记更重要

助手很少只读一页。被要求比较联盟计划时，它可能会读你的联盟落地页、条款页、一篇帮助文章和一篇第三方评测，然后把它们对一遍。如果你自己的页面互相矛盾，助手要么挑一个，要么合成一个区间，要么说条款不清楚。这三种结果对你都没有帮助。

矛盾很常见，因为不同的人在不同时间写不同的页面。市场团队做完一次促销后在首页写“伙伴最高可赚 30%”；联盟页面仍写着“持续 12 个月的 20% 佣金”；法律条款写的是“净收入的 20%”，计算基数又不一样；Cookie 有效期在一个页面上是 60 天，在一篇没人更新的旧帮助文章里是 30 天。

在这个话题上，这次核查是你能花得最值的一小时。列出所有提到价格、佣金比例、持续期、Cookie 有效期、冻结期或最低打款的页面，把每个数字和它所在的页面填进表格。每一行和其他行不一致的地方，就是某个助手此刻正在给出的错误答案。修改这些页面；旧页面改不了的，加一句指向当前条款的话。

哪些 schema.org 类型对价格页有用？

结构化数据是你的事实在一种带字段名的格式里的第二份副本。它不取代可见文字，而是印证它。schema.org 词汇表里有你需要的价格类型和问答类型，以 JSON-LD 的形式嵌在 script 标签里。由于 JSON-LD 是首屏 HTML 的一部分，不渲染的抓取器也能读到，这和 Vercel 所说首个响应里的 JSON 可能被索引是一致的 [2]。

价格用 Offer 类型。price 属性放金额，priceCurrency 用 ISO 4217 代码放货币，例如 USD；priceSpecification 链接到更详细的价格描述；eligibleDuration 说明报价的有效期；offeredBy 指向提供报价的组织 [3]。订阅场景下，UnitPriceSpecification 增加了 billingDuration，即一个价格按多长时间计费，可以填一个时长；billingStart，用于一段时间后变化的价格；以及 priceType，用于标价或促销价 [4]。

{"@context":"https://schema.org","@type":"Offer","name":"Pro plan","price":"49","priceCurrency":"USD","priceSpecification":{"@type":"UnitPriceSpecification","price":"49","priceCurrency":"USD","billingDuration":"P1M"},"url":"https://example.com/pricing"}

问答用 FAQPage 类型，它是呈现一个或多个常见问题的网页，每个问题作为页面的 mainEntity [5]。这里有一个变化很重要：Google Search Central 的更新日志在 2026 年 5 月记录了弃用 FAQ 富媒体结果，说它从 2026 年 5 月 7 日起不再出现在 Google 搜索中，并在 2026 年 6 月记录了删除相关文档 [6]。所以 FAQPage 标记在 Google 已经换不来特殊的搜索摘要。但它仍是一种任何解析器都能读的、带名称的清晰结构；如果你的问答已经在可见 HTML 里，加上它的成本很低。

有一个空白值得直说：我们没有找到专为联盟佣金条款设计的 schema.org 类型。你可以把计划描述成一个带 description 的 Offer，但佣金比例、持续期、Cookie 有效期和冻结期都没有专门字段。对这些条款来说，可见文字本身就是机器可读的格式，这也是为什么下一节比任何标记都重要。

怎样的联盟条款才算机器可读？

机器可读不需要什么特殊格式。它的意思是：每条事实都是一句短句，含一个数字、一个单位和一个范围，而且处处写法相同。提取条款的助手是在对文字做模式匹配。“首付款后 12 个月内每张已付发票的 20%”可以被可靠提取；“你推荐来的每位客户都能为你带来丰厚的持续佣金”则不能，因为里面没有数字。

五条规则就能覆盖大部分情况：一条条款一句话；数字放在句首或靠前；写明百分比的基数，是发票金额、净收入还是首次付款；写明时间单位，是天、月还是发票张数；再加一个可见的“最后更新”日期，让读到两个版本的助手能分辨哪个是当前的。

改写前：为快速浏览写的条款

加入我们的伙伴计划，赚取业界领先的持续佣金！我们慷慨的 Cookie 给你充足的转化时间，打款也很快。顶级伙伴还能解锁更高比例。适用相关条款。

这段话里一个数字都没有。被问到“这个计划付多少？”的助手，只能说不知道，或者从一篇可能已经过时几年的第三方评测里猜。“业界领先”“慷慨”这种说法，模型要么忽略，要么无依据地复述，对创作者做决定都没有帮助。

改写后：为提取而写的条款

• 佣金：客户首次付款后 12 个月内，每张已付发票的 20%。
• 阶梯：你的第 10 位付费客户之后，新客户按 25% 计算。
• Cookie 有效期：自最后一次点击起 60 天，按最后点击归因。
• 优惠码：你的专属优惠码无需点击即可归因。
• 冻结期：发票付款 30 天后佣金变为可支付；退款和争议会被扣除。
• 打款：每月一次，通过 PayPal 或 Wise，余额达到 $50 时发放。
• 不计佣金：你本人或你公司的购买，以及在搜索广告中竞价我们的品牌词。
• 最后更新：2026 年 10 月 1 日。

每一行只有一个数字和一个范围，百分比的基数写明了，排除情形也点了名。助手可以单独引用其中任意一行而不出错；比较三个计划的创作者几秒钟就能把它们排成一张表。把这段条款放在联盟页面的服务端渲染 HTML 里，在条款页用完全相同的句子，并互相链接。

怎样测试助手在你页面上看到了什么

1. 不用浏览器抓取页面并保存响应，在里面搜你期望出现的每个价格和佣金数字。缺失的部分，对不渲染的抓取器就是不可见的。
2. 检查每个切换项的默认状态：月付或年付、货币、地区。被引用的是默认状态。
3. 打开响应里的 JSON-LD，把每个值和旁边的可见文字对照。与页面不一致的标记比没有标记更糟。
4. 做跨页面核查：列出每个提到条款的页面，确认它们用相同的措辞写着相同的数字。
5. 直接问两三个助手，比如“这个计划付多少佣金、持续多久？”，把回答和你的条款对照，并记下每个助手引用了哪个页面。
6. 每次改价格或计划后重做一遍，并同时更新“最后更新”日期。

这也是 RelayWonder 用服务端渲染计划页、把条款写成纯文字句子的原因；我们还发布了 llms.txt 文件，为语言模型指出值得读的页面，并提供 MCP 端点和 API 密钥，让代理以类型化数据读取计划条款，而不必抓取网页。不管你用什么工具，上面的测试都能告诉你事实有没有送到读者手里。

这周就能改的页面

• 如果价格和佣金数字现在是脚本加载的，把它们移进服务端渲染的 HTML。
• 把联盟条款改写成一条一句，数字靠前，写明基数和单位。
• 给价格页和条款页加上“最后更新”日期。
• 修改或重定向每一个写着不同比例、持续期或 Cookie 有效期的旧页面。
• 为套餐价格加 Offer 和 UnitPriceSpecification 标记，为已在 HTML 中可见的问答加 FAQPage 标记。
• 记下你测试了哪些助手、它们怎么回答，下个月就能看出改动有没有生效。