Google新增地区搜索体验文档：聚合平台与直接供应商怎样判断参与资格

截至2026年9月21日复核，Google又在9月18日更新了聚合商与供应商说明，加入本地商家查询。下面按当前说明整理；9月8日新增文档、9月18日补充支持范围是两个不同时间点。

对跨境网站而言，这份文档最有用的地方，是把不同搜索功能的入口分开了。经营自有产品的商家、替用户比较多个供应商的平台，以及发布行业文章的网站，接下来要检查的材料并不一样。

先看目标市场，再看自己提供什么

Google的地区体验总览按地区和查询类型列出功能。欧洲经济区的聚合商模块与供应商模块，覆盖酒店、航班、地面交通、本地商家和产品等查询；其他功能还涉及招聘、天气等主题。土耳其和南非也有各自的功能范围，不能把其中一项的条件套到另一项上。地区搜索体验总览

这里至少有三个需要分别记录的条件：企业在哪里经营、用户在哪里搜索，以及网站能否实际服务这些用户。页面使用什么语言，解决的是用户能否读懂内容；它不能代替目标地区和业务资格。

例如，一家中国企业用英文向德国客户销售自有产品，应该核对直接供应商对应的条件。另一家网站只写德国旅行攻略，即使有很多酒店文章，也不能仅凭文章数量认定自己属于酒店聚合服务。这个例子用于说明筛选方式，不代表两类网站已经获得资格。

建议先从一个真实业务开始判断：你希望哪类用户，通过哪类查询，进入哪张可购买或可比较的页面。答不清这一句时，暂时不用安排开发接入。

聚合平台和直接供应商，走的是不同入口

聚合商模块面向垂直搜索服务，例如在线旅行代理、比价服务和目录等。官方条件涉及批准资格、相关内容、所需数据和质量要求，并按交通、酒店与产品等类型提供不同联系入口。提交兴趣表只是开始，不等于已经获准展示。聚合商模块说明

直接供应商模块面向相应业务的直接提供者。官方说明，这个模块在聚合商模块出现时才出现；网站需要服务欧洲经济区用户，并属于适用查询的直接提供者。参与不要求额外提供网页抓取以外的数据，但可用的数据源可能增强结果。供应商模块说明

你的网站实际角色	优先核对什么	不能直接推导什么
帮用户比较多个提供者的垂直服务	聚合商资格、业务类型、数据接口与联系入口	有一个产品集合页，就等于获批聚合商
直接销售产品或提供适用服务	服务地区、查询范围、网页信息	做了英文站，就一定展示供应商模块
主要发布教程、资讯和经验文章	内容对应的搜索需求及适用功能	写到某行业，就能参加该行业交易入口

表格是按官方条件整理的判断方法。角色应该由真实服务决定，而不是为了一个搜索功能，临时把网站介绍改成“平台”。如果同一企业同时经营直销业务和比较服务，也需要分别梳理页面与数据职责。

从功能说明走到接入，要准备哪些材料

如果角色与市场初步相符，下一步应打开那一项功能自己的参与说明。不要只停在地区总览，也不要把一家服务商给出的“支持Google”当成已经接入指定模块。

聚合业务可以按下面的顺序准备。这是把参与条件落实到项目中的建议，不是Google的审批承诺。

1. 确定业务类别。 写明比较的是酒店、航班、地面交通、本地商家还是产品。保存一张能体现实际比较服务的页面，说明有哪些可比较对象、用户点击后去哪里。
2. 找到对应联系入口。 酒店、交通和本地商家类与产品类的入口不同。先从官方聚合商页面进入相应表单或联系流程，不要向不匹配的入口重复提交。
3. 盘点数据从哪里来。 记录价格、可用状态、图片、名称由谁维护，更新失败时谁处理。只有静态文章，没有可维护的实体与数据，并不能靠填写表单补出这项能力。
4. 核对所需集成。 官方按业务列出数据源或API文档。先由技术负责人判断现有数据能否对应，再估算开发与长期维护成本；不要先开发一套通用接口再寻找适用功能。
5. 分别记录准备、反馈与展示。 材料备齐、已表达兴趣、获得反馈、实际观察到模块，是不同状态。用具体日期和反馈记录更新进度，避免团队内部提前宣告上线。

把对应资料发给技术负责人时，保留业务类别，避免进错接入路线：

• 酒店：Lodging Point of Interest Feed。
• 地面交通：Transport features API。
• 航班：Partner standard Live API。
• 产品：官方产品类说明与CSS联系入口。
• 本地商家：Local Point of Interest Feed。

这几项来自聚合商页的技术资料入口，不是让直接供应商也逐项提交全部数据。

9月18日新增的本地商家，怎样套用这个判断

以两种假设业务为例：柏林一家实际提供维修服务的商家，和帮助用户比较柏林多家维修商的目录站。前者先按直接供应商核对真实服务地区及公开服务页；后者先按垂直搜索服务核对资格，并走本地商家对应的兴趣表和数据路线。两者都谈维修，不意味着使用同一个申请流程。

商家服务页应让客户确认服务范围、可联系或预约的入口；目录页则要说明比较的是哪些提供者，以及点击会进入哪家服务商或目录里的哪张详情。这里是按真实服务整理页面的建议，不是官方额外规定的一组排名字段。经营者确认材料后，记录“已完成页面准备”即可；能否在某次查询展示仍需另外观察。

直接销售自有产品的网站也按同样的角色判断，先核对供应商说明与自己的公开落地页，不必抓取其他商家的信息凑比较列表。

遇到没有写清的边界，问题应带着具体事实去问。例如：“我们只销售自有品牌，向哪些地区配送，这张页面是产品分类页，是否属于该入口的适用对象？”这比“我的网站能不能做Google聚合”更容易得到有用答复。

产品聚合页可以优化，但不能与聚合商资格画等号

很多独立站会有“所有产品”“按用途选产品”这样的页面。它们能帮助用户浏览，也能把相关详情页组织起来。这是站内信息架构的作用，与Google这里所说的聚合商准入不是同一件事。

假设你只有自己的十几款产品，可以先把产品分类、用途差异、可购买状态和详情页入口做好。不要为了名称相似，就把分类页改成一个并不存在的多商家比价平台。这样增加了维护工作，还可能让买家误解你实际提供的服务。

如果你确实帮助用户比较不同商家的产品，页面则需要让人看清比较范围、数据更新时间、跳转目的地，以及谁负责交易。可见内容、外部数据和实际服务不一致时，先修正这些差异，再评估接入。

需要重新整理页面职责时，可以先看关键词与页面映射。同一个词对应哪种页面，仍然要根据用户要完成的任务判断。

不要把聚合商模块与结构化数据轮播混在一起

地区总览还列出了结构化数据轮播。它可以把同一网站里的多个条目以横向列表展示，相关文档要求使用ItemList搭配支持的内容类型；地区与查询范围另有规定，并仍属于测试中的功能。它不能仅凭名称相似，就与聚合商模块视作同一个接入项目。结构化数据轮播说明

这一区别会直接影响开发报价。有人提出“给分类页加ItemList，就能参加聚合商模块”，应请他指出具体对应哪份功能文档。数据标记描述页面内容，业务资格涉及服务角色与参与条件，代码有效不能替代后者。

轮播自己的当前说明同样列出了按业务类别区分的参与路线。例如产品查询指向CSS项目国家及Comparison Shopping Services项目；其他类别也有相应表单。因此，“我的页面有产品列表”和“加了有效ItemList”仍不足以宣布该特定轮播已符合全部条件。地区、内容类型、页面实现和适用的参与要求，要在同一份文档里一起核对，不能从不同搜索功能中各取一条有利条件拼成结论。

如果研究的是轮播本身，还要检查汇总页是否真的列出相应条目、条目是否有可访问的详情，以及标记中的名称、图片等是否与页面一致。先选定功能再准备实现，避免一份页面同时堆入多个用途不明的标记。

用一张页面做准备，别立即改全站

前面的角色判断确定后，选一张实际落地页完成准备：记录目标地区、业务身份、查询类型、网页地址和数据负责人。后面的资格记录表继续使用这一页，避免团队分别拿着不同业务样本讨论。

页面内容需要回答买家真正关心的问题。例如产品是否向该地区销售、价格适用什么条件、库存何时更新、点击后到哪里完成交易。若这些信息尚未确认，就把它们记为待补材料，不要让AI代填一个看起来合理的答案。

对需要数据接入的平台，还要提前确认更新责任。假设落地页已经停售，而接口仍返回可购买，搜索入口即使带来访问，也会把用户送进错误的交易预期。这里的检查优先级来自实际经营风险，并非Google公布的排名加分表。

完成一张页面后，再判断是否值得扩展到同类页面。面向中文读者的知识站，也可以只是继续提供准确的教程，不必因为新的地区文档出现，就转向不熟悉的平台业务。

把资格判断写成一份有结论的记录

下面用两家假设的咖啡设备网站填写记录：一家销售自有设备，另一家比较多家商家的设备。与其把所有项目都打勾，可以留下下面这样一份记录，区分已经有证据、尚未确定和不适用的事项。表中状态只是演示，不代表这些虚构业务获得Google资格。

核对项	自有设备直销站	多商家设备比较站
网站实际上做什么	用户向本站购买自有设备，先按直接供应商路线核对	比较不同商家的设备与报价，先核对产品聚合商路线
地区证据	德国配送是否真实可用，必须由实际销售政策确认	所列商家是否能向目标地区成交，不能只看平台界面语言
页面样本	一款产品的规格、可售状态、交易或咨询入口	同一需求下可比较的条目、来源商家、跳转目标及更新情况
还缺什么	假设配送尚未确认：先向运营核实，再写公开说明	假设暂无VSS相关批准反馈：记录尚未确认，不写已经接入
当前应该做什么	完善已确认的公开商品与地区信息	从官方产品类联系入口核对资格和数据路线，评估维护能力
当前不能宣布什么	供应商模块已展示，或一定获得额外流量	提交表单已经获批，或加ItemList就完成聚合商接入

如果销售部门最后确认德国不在配送范围，直销站这一轮就应得到“不按服务德国用户的前提继续准备”的结论。不要为了让表格通过，在页面上先写“支持欧洲配送”。比较站若发现报价来自不可持续更新的手工截图，先决定能否维护真实比较服务；缺少这项能力时暂停接入，继续正常的产品内容工作，也是完整的判断。

同一企业也可能既卖自有设备，又经营比较服务。这时要分别列出对应页面和负责人。比较页中有一个链接指向自家商品，并不会让所有页面都变成直接供应商页；反过来，直销站增加“推荐品牌”文章，也没有自动建立一个垂直搜索服务。审核材料应准确描述用户在那张页面完成什么、最终向谁交易。

数据与页面不一致时，先修哪一边

假设比较页展示设备A仍然可购买，但商家落地页已经停售。先确定真实状态来自哪位商家及哪份数据，再更新比较展示和适用的数据源；不能只在文章末尾补一句“以商家为准”，却继续突出旧报价。Google聚合商说明明确要求维护价格与可用状态的一致性，这也是用户能否继续完成任务的基础。

复查可以围绕一个具体条目：来源记录何时更新、平台页面现在显示什么、点击后到达哪家商家的哪件商品。若页面已经修改而数据源仍旧，任务尚未结束；若数据源已更新、前台还显示旧值，再查平台自己的缓存或发布流程。外部搜索界面的变化还需继续观察，不能把本站前台更新直接写成Google模块已经同步。

这些动作是维护真实服务的项目建议。不同数据路线有各自的字段与更新规则，应按实际接入文档实现，不自行编造一个所有聚合商都适用的更新时间或必填字段清单。

后续观察时，把地区变化与页面变化分开

记录开始检查的日期，并保留目标地区的查询、设备与结果截图。随后对照网站自己的访问和询盘数据。来自不同国家、不同时间的两张结果截图，不能直接证明某项优化有效。

如果只是补齐资料，还没有获准参与，也没有看到对应模块，应把状态写成“准备中”或“尚未观察到”。不要将整体自然流量的上涨都归到新功能，也不要因为一次没看到结果就认定网站有故障。

这类更新适合加入AI搜索与谷歌更新的观察范围；长期工作仍然可以沿着谷歌SEO学习路径推进，先把网站能提供什么、服务谁和页面如何承接需求讲清楚。