Google搜索新增本地业务模块支持：服务商和目录站分别要准备什么？

Google于2026年9月18日在搜索文档中增加了本地业务查询对聚合商模块和直接供应商模块的支持。相关体验面向欧洲经济区（EEA）用户。这里讨论的是搜索展示功能扩展，没有把它解释为一次新的核心排名更新。Google更新记录

本文按2026年9月21日可读的官方文档整理，先解释两类入口，再给出服务商与目录站各自能着手完成的工作。

用户点击两种模块后，去的地方不同

聚合商模块面向垂直搜索服务，包括符合条件的目录、比较和聚合平台。用户在模块中看到某个平台提供的相关结果，点击后进入该平台继续查看。直接供应商模块则通向真正提供相关服务或商品的网站，而且官方明确它只在对应聚合商模块出现时展示。聚合商说明；供应商说明

用“某城市的水管维修”理解这一区别比较直观：一家平台整理多家维修商并让用户比较，承担聚合作用；一家自己派人维修的公司，则是直接服务提供者。页面上都可能出现同一个服务词，但业务关系不同。

经营者在中国、页面用中文或英文，都不能单独决定是否与这次更新有关。应先看实际面向的用户和服务地点。中文团队替欧洲本地公司维护网站，值得核对；只有面向中国国内读者的资讯内容，则不需要为了这项展示变化改造成商家目录。

这次范围也不能与所有地区的其他搜索样式混在一起。需要查看不同地区的功能背景时，可以接着阅读Google地区搜索体验与参与资格。

先给自己的网站做一次角色判断

角色判断可以从用户完成交易或联系服务的路径出发。谁实际提供服务？用户是在比较多家公司，还是向某一家预约？页面讲述的主体与负责履约的主体是否一致？

网站实际工作	应先看哪条路线	不应直接作出的推断
自己派技术人员到客户现场	直接供应商相关条件	只要上传Feed就能取得展示
整理多家维修商并提供比较或查找	聚合商/VSS资格与数据要求	有商家列表就已经获准参加
品牌列出自己门店	结合实际提供者和各门店页面核对	门店列表一定就是独立VSS
品牌列出独立经销商或合作服务点	先讲清品牌、经销商与履约关系	所有合作方都由品牌直接履约
文章推荐几家商店	先保证内容与推荐信息准确	推荐文章自动成为合格聚合平台

混合业务尤其需要说明关系。例如网站既有自营服务，又收录第三方服务商，就不应让所有页面使用模糊的“我们提供”。用户需要知道自己联系谁，数据也需要分清每家实体，而不是在页面中随意切换品牌身份。

直接服务商：先让客户知道能否预约

供应商文档列出的基本条件是服务EEA用户，并属于相关查询的直接提供者。它同时说明，不要求在网页抓取能够获取的信息之外额外提交数据；已有数据Feed可能增强展示。不能因此理解为任何可抓取网站都会获得位置，但也没有理由先替每家本地公司开发一套聚合商Feed。供应商参与说明

对于一家上门维修公司，最有价值的页面修改通常是把真实业务写清楚。下面以一个假设项目说明，不代表某家公司已获得模块展示。

旧页面只写“专业维修，覆盖全城”，页尾放了办公室地址。客户仍然不知道自己的邮编能否预约、哪些设备能修、需要提供什么资料。可以改成三个连续的答案：

1. 地点：分开办公地址、可到访门店和上门范围。
2. 服务：说明接什么设备、需先提供什么资料、哪些情况检查后才能报价。
3. 预约：提供可用入口，并说清提交后如何确认时间。

从一句宣传改成可预约的页面

延续上面的假设维修公司，可以把一句宽泛介绍改成如下工作稿。方括号是等待商家确认的内容，不应原样发布；页面也不能因为采用这份写法就获得Google模块展示。

我们在［实际服务城市］为［确认接受的设备类型］提供上门检查。请先提交设备型号、故障现象和邮编，我们会确认该地址是否在服务范围，并说明可预约时间。办公室［是否接待来访］；需要更换零件的项目，检查后再确认费用和交期。

这段话解决四个连续问题：在哪里、修什么、如何判断能否承接、何时才能报价。实际发布前，商家要逐个填写并确认事实；不要把“待确认”偷偷改成“全国”“所有品牌”或“当天解决”。

对应表单也要接住正文承诺：正文说先核对邮编，表单却没有地点字段，客服仍要追问；写明需故障照片，移动端却不能上传，就要提供可用的替代提交方式。完成后用一条虚拟需求从手机提交，查看工作人员收到的字段是否足够安排下一步。测试只验证预约路径，不把一次表单成功写成搜索展示验证。

目录平台复用这种资料时，应保留实际履约商家名称与联系入口。如果联系方式统一转到目录客服，也要让用户知道是在平台询问，再由平台匹配服务商，避免把平台接单与商家直接履约混为一谈。

目录平台：先建立可靠实体资料，再准备数据接入

聚合商文档要求获准作为VSS参与、具备相关内容、提供所需数据，并满足相应质量与内容要求。本地业务采用直接数据Feed集成，官方给出了兴趣登记与Local Point of Interest Feed的入口。聚合商资格与数据要求

Actions Center的概览进一步说明，POI数据围绕有实体地点的商家，涉及名称、地址、电话、类别和照片等信息。它服务于合作方自己的模块展示。本地VSS概览

准备数据时，不宜先从编一个JSON示例开始。先检查商家库是否足够可靠：同一商家有没有重复记录，分店是否被合成一个地址，联系方式是否属于对应门店，详情页是否真实存在。数据结构正确但实体关系错误，仍然会让用户联系到错误对象。

可以先选几家资料完整的商家做端到端核对：列表展示、商家详情、联系方式和维护记录是否对应同一家。下面是一份内部资料检查表，不是Google Feed字段规范。

内部记录	核对方式	常见修正
商家及分店身份	对照详情页与实际联系信息	合并重复商家，分开真实分店
地址与服务区域	区分可到访地点和上门范围	避免办公室被误当营业门店
类别和服务说明	与商家实际业务核对	删除宽泛或失实的分类
图片与名称	确认对应当前实体和地点	更换错店照片与促销式名称
联系落点	实际打开详情页、电话或预约入口	修复混合推荐页、死链或错误号码
更新时间与负责人	看谁确认、何时复核	给停业、迁址和投诉建立修改入口

上表用于内部资料核对，不能直接作为Feed上传文件。确定参与路线后，再按当前官方规范核对字段、枚举、提交方式与更新要求。商家清单可以先整理，技术接入则需要这些要求明确后再实施。

门店页面、服务区域页和城市列表，各自承担什么

门店详情应回答“这是哪一家，在哪里，怎么联系”；服务页回答“能处理什么，需要什么条件”；区域页则说明该范围内是否确实能提供服务，以及覆盖边界。它们是否需要分开，取决于实际业务差异，不能只根据有多少城市关键词决定。

一家只在一座城市服务的公司，可能一张内容完整的服务页面就足够。拥有多家门店、不同电话和营业安排的企业，则更需要分别对应的详情。若多个区域除了城市名之外没有任何差异，批量复制页面不会帮助客户作出更准确的预约判断。

目录平台还需要检查筛选后的落点。用户筛选了某个地区和服务，再点击具体商家，最好能直接到对应详情，而不是回到一个重新开始搜索的总列表。这个改动即使暂时没有带来新模块流量，也能改善已有访客的比较过程。

当一家商家停业或移出目录时，页面、内部列表和供给数据应同步处理。只改页面文案、仍向外提供旧数据，会留下不一致；只删除Feed记录、详情页仍显示可预约，也会让站内用户遇到错误信息。

上线以后，分别观察展示、访问与有效咨询

观察可以分成三层。第一层是搜索中是否看到相关模块；第二层是用户点击后去了哪里；第三层是页面是否带来符合业务范围的咨询。三层不能只用一个“排名涨了”概括。

保留一组与你实际业务匹配的查询，记录地区、语言、设备、日期和结果样式。看到模块时，点击核对落地页；没看到时，记录为本次未观察到，不立即推断网站被排除或没有资格。功能出现还受到查询与展示条件影响。

Search Console可以辅助观察对应国家、页面与查询的搜索变化；网站分析与表单记录则帮助看访客是否完成联系。若咨询量增加，还要区分服务区域内的有效需求和无法承接的咨询。没有能够对应的证据时，不把全部增长归因于9月18日这项变化。

如果页面流量不错但咨询大多不匹配，优先查看服务范围、设备类型和预约条件是否写得清楚。若目录点击以后大量返回列表，则检查详情资料和联系入口。这样修改的是用户实际遇到的问题，也更容易知道下一轮该投入内容、数据维护还是技术接入。