官方发布日期：2026 年 9 月 18 日
官方来源：Google Search Central、Google Actions Center
更新类型：Regional Search Experience / Local Business Search Feature Update
适用地区：欧洲经济区（EEA）
事件分类：Product / Documentation Update，不是 Ranking Update
Google Search Central 在 2026 年 9 月 18 日更新官方文档，正式把 Local Business Queries 加入 Aggregator Unit 和 Supplier Unit 的支持范围。
Google 在 Documentation Updates 中写得非常明确：此次更新，是因为 Aggregator Unit 与 Supplier Unit 现在已经支持本地商家查询。
这不是 Core Update，不是 Spam Update，也没有新增一个所谓“Local SEO Ranking Factor”。
真正发生变化的是：
Google 在 EEA 的商业搜索结果中，把 Aggregator 与 Direct Supplier 这套双轨搜索体验进一步扩展到了 Local Business。
对于普通网站，这看起来只是 Search Appearance 多了一种可能性。但对于本地商业目录、垂直搜索平台、服务聚合平台、实体门店、维修服务商、经销商、安装与售后网络，它意味着 Google 本地商业搜索的竞争界面正在进一步从 网页排名竞争 扩展为 商业身份 + 实体数据 + 参与资格 + Search Feature 展示竞争。
一、9 月 18 日究竟发生了什么？
Aggregator Unit 和 Supplier Unit 并不是 9 月 18 日首次出现。
Google 在此前的 EEA 区域 Search Experience 中，已经将它们用于酒店、航班、长途火车或巴士、产品。
9 月 18 日真正新增的是第五类：Local Businesses。
更新后的 Aggregator Unit 官方文档现在明确说明，这项功能可用于 hotels、flights、long-distance trains or buses、products、local businesses。Supplier Unit 的范围也同步增加了 Local Businesses。
因此，这不是单纯的文字整理。Google 在更新日志里明确把原因写成：Aggregator Unit 与 Supplier Unit 现在支持 Local Business Queries。
二、理解这次更新，首先要理解两类商业主体
这次变化最关键的并不是“Local Business”四个字，而是 Google 正在把两类参与者进一步明确区分开。
Aggregator
也就是帮助用户搜索、筛选、比较、发现多个商业实体的平台。例如目录网站、垂直搜索服务、OTA、Comparison Shopping Services、Metasearch Engine。
Supplier
即真正直接向用户提供服务、产品或交易的主体。Google 官方给出的 Supplier 示例包括独立酒店、航空公司、实体企业，以及 plumbing 一类本地服务商。
因此，可以把这套体系简单理解为：
Aggregator = 帮用户找到商家的人
Supplier = 真正给用户提供服务的人
Google 现在正在 EEA SERP 中，为两类主体建立不同的商业搜索入口。
三、Aggregator Unit：聚合平台不再只依赖普通蓝色链接
Aggregator Unit 是一个 Multi-provider Search Feature。
Google 将其设计给 Vertical Search Services（VSS）。符合资格的聚合平台可以在一个独立 Search Unit 中展示与用户查询相关的多个商业实体。
例如用户搜索 hotels in paris，Aggregator Unit 可能直接呈现酒店名称、照片、价格、评分以及其他实体属性。点击其中某个结果后，用户进入提供该数据的聚合平台网站。
而且 Google 允许多个符合资格的 Aggregator Provider 参与。默认情况下，排名最高的 Provider 会被展开，用户可以切换到其他 Provider。
但是：同一时间只展示一个 Aggregator Unit。
因此，Aggregator 的竞争已经不再只是“目录页面能不能自然排名第一”，它同时增加了：
Search Feature Eligibility + Provider Ranking + Entity Inventory Quality
三层竞争。
四、Local Business 加入之后，Google 对“本地搜索”的定义更具体了
Google Actions Center 针对 Local Vertical Search Service 的技术文档进一步解释了这里的 Local Search。
官方举出的示例包括 Dining、Services（例如 Beauty Salons）、Things to do（例如 Attractions）。
Google明确表示：正在更新本地搜索的 Search Results Page，为 Vertical Search Services 和 Direct Suppliers 创造新的参与机会，并通过 Aggregator Unit 和 Supplier Unit 展示这些结果。
这意味着，这次变化不应该只理解成“Google 给酒店之外又加了一种单位”，它真正进入的是：实体型本地商业搜索。
五、Supplier Unit：Google为什么还要给直接商家单独留一个入口？
如果 SERP 只增加 Aggregator Unit，会产生一个明显问题：真正提供产品和服务的企业，可能被聚合平台进一步挤压。
Google 因此同时设计了 Supplier Unit。
Supplier Unit 专门面向 Direct Providers，而且它与 Aggregator Unit 存在明确依赖关系：
Supplier Unit 只有在 Aggregator Unit 出现时才会出现。
因此，二者并不是两个完全独立的 Rich Result。
更准确的结构是：
Aggregator Search Experience → Aggregator Unit + Supplier Unit
一边展示聚合平台，另一边展示直接供应商。Google通过这种结构在同一类商业 Query 中同时保留平台发现机会和直接商家机会。
六、本地企业最应该关注的一句话：Supplier 不要求额外 Feed
这是此次更新对普通企业最重要的事实之一。
Google 在 Supplier Unit 官方文档中明确说明：如果企业属于 Direct Provider，不需要提供超出正常 Web Crawling 可以获取的信息。
也就是说，普通本地企业不需要为了 Supplier Unit 建立专用 API、开发所谓 Supplier Schema、强制上传新的 Feed 或接入一个新的 Indexing Protocol。
只要网站服务 EEA 用户、企业本身属于直接供应商、Google 可以从网站正常抓取相关信息，就可能符合基础参与条件。
当然，如果企业本身拥有额外 Feed，Google 说明 Supplier Result 可以进一步使用这些数据增强。但 Feed 不是基础参与的前提。
七、这进一步强化了一个结论：官网依然是 Direct Supplier 的重要数据源
这次变化并没有削弱企业官网的价值，恰恰相反。
Supplier Unit 明确建立在 Web Crawling 可以理解企业信息 这一前提之上。
因此，一个面向欧洲本地市场的企业网站，至少应该能够清楚回答：
- 企业是谁；
- 提供什么服务；
- 服务哪些地区；
- 实体位置在哪里；
- 如何联系；
- 什么时候营业；
- 有哪些真实产品和服务；
- 用户最终应该联系哪个主体。
如果这些基本信息都无法从网页中稳定识别，那么即使不存在新的 Schema 要求，企业依然会面临 Entity Understanding 不完整 的问题。
八、Aggregator 的参与门槛完全不同
Supplier 可以依赖正常 Web Crawling，但 Aggregator 不一样。
Google 明确要求 Aggregator 首先必须满足 Vertical Search Service（VSS）资格。
同时还需要服务 EEA 用户、拥有与查询匹配的相关内容、提供所需数据，并符合 Google Search 内容政策及相关质量要求。
因此：
Aggregator Unit 不是靠多建几个 SEO 页面就能进入。
这是一套 Business Eligibility + Search Eligibility + Data Integration 共同构成的参与体系。
九、Local Business Aggregator 的核心技术基础是 POI Feed
对于 Local Business Queries，Google 现在明确把数据接入指向 Local Point of Interest Feed。
Google Actions Center 对这套 Feed 的定义更加具体。
POI Feed 是一种标准化实体数据格式，用来向 Google 提供 Business Name、Address、Phone、Category、Photos、Location 以及其他商业元数据。
Google 还明确说明：这个 Feed 中的 Partner 数据用于填充 该 Partner 自己的 Aggregator Unit，不会被用于增强 Google 自己的服务或者填充竞争对手的 Unit。
十、POI Feed 让本地搜索越来越接近“商业实体数据库”
Google 当前的 POI Feed 字段已经可以描述相当完整的本地商业实体，包括：
poi_id
name
telephone
url
location
display_address
images
rating
num_ratings
category
description
business_hours
price_range以及不同语言的 Localized Content。
从 SEO 技术视角看，这非常关键。
因为 Aggregator 参与 Google 本地搜索时，输入的已经不只是 HTML 页面，而是一个高度结构化的 Entity Inventory。
这意味着 Aggregator Search 正在越来越接近 Entity Retrieval，而不是单纯的 Document Ranking。
十一、这也是为什么“Local SEO = 做几个城市页”的模型正在变得越来越落后
传统 Local SEO 常常被简化成城市关键词、Local Landing Page、Google Business Profile、评论、NAP、本地链接。
这些基础仍然重要，Google 此次并没有宣布它们失效。
但是 Aggregator / Supplier 体系增加了一层更加清晰的商业关系：
- 谁是 Aggregator？
- 谁是真正的 Provider？
- 这个 Provider 是什么实体？
- 实体在哪里？
- 属于什么 Category？
- 营业时间是什么？
- 有哪些图片？
- 服务范围是什么？
因此，Local SEO 不能只继续围绕 keyword + city 生产页面。它需要逐渐向 Local Entity Governance 演进。
十二、Google 对实体数据质量已经提出非常具体的建议
Google 在 Aggregator Unit 最佳实践中明确建议提供更加完整的实体属性，包括高质量图片、详细说明、规格、验证后的用户评分和评价数量、具体业务分类、关键设施或服务特征、营业时间。
Google 还特别指出：相比非常宽泛的类别 Hotel，更具体的 Boutique hotel 或 Eco-resort 可以帮助用户更准确判断实体。
这种逻辑同样适用于本地商业。
例如，“Contractor”通常不如“Electrical contractor”“Industrial equipment maintenance service”“Amusement ride installation service”具体。
核心原则是：分类应该表达真实业务，而不是追求关键词覆盖最大化。
十三、Google明确反对把关键词和促销文案塞进 Entity Name
这部分尤其值得 Local SEO 团队注意。
Google明确建议实体 Title 保持 Factual 和 Descriptive，并避免全大写、大量标点、Emoji、促销语言。
Google甚至直接举出 BEST DEALS 和 Free shipping 作为不建议放入名称的例子。
Google Actions Center 的 Local Integration Policy 也要求：Business Name 应该准确对应真实世界中的企业名称，不应额外塞入并非真实名称组成部分的营销信息。
因此，如果看到此次更新后，Local SEO 团队开始批量把 Best、Cheap、Near Me、Top Rated、City Name 塞进公司名，方向实际上与 Google 给出的数据规范相反。
十四、图片已经不只是网页装饰，而是 POI 实体字段
Google 对 Aggregator 数据建议使用清晰、原创、高质量的图片，并建议背景简洁、不要水印、不要加入促销 Badge、尽量提供高分辨率素材。
而 POI Feed 本身已经直接设置 images 字段。Google 还规定了图片 URL、格式、文件大小、抓取权限等具体技术要求。
这说明，对本地商业搜索而言，真实视觉资产正在越来越接近 Entity Data，而不仅是网页装饰。
对于企业而言，真实门店、真实仓库、真实维修中心、真实技术团队、真实安装现场、真实设备的图片，长期价值通常会高于大量通用 Stock Image。
十五、价格与 Availability 开始成为数据治理问题
Google 同时建议 Aggregator 保持 Pricing、Availability 及时更新，并尽量确保 Feed 数据与 Landing Page 一致。
这是商业搜索中一个越来越重要的技术问题。
如果 Google 单元中显示某个价格、某个 Availability、某项服务，用户点击以后 Landing Page 却出现另一套状态，会形成明显的 Search Experience 断层。
因此未来商业 Search 项目不能只审核“网页能不能抓”，还要审核：
Google 接收到的数据，与用户真正进入页面后看到的数据是不是一致。
这就是 Search Data Governance。
十六、这对普通中国外贸 B2B 网站有什么影响？
如果企业只是中国制造商，没有欧洲本地公司、没有实体门店、没有欧洲仓库、没有安装团队、没有维修中心、没有真实经销商或服务网络，此次更新的直接影响 较低。
不需要因为 Local Business Query 进入 Supplier Unit，就批量创建 equipment supplier Berlin、equipment supplier Paris、equipment supplier Madrid 这样的页面。
如果企业在这些城市根本不存在对应业务实体，这种页面并不会因为此次更新突然获得价值。
十七、不要把“服务欧洲客户”误解成“欧洲本地实体”
这是外贸 SEO 特别容易出现的错误。
一家中国制造商可以向德国出口产品，但这不自动意味着它是 Berlin Local Business。
同样，可以为法国客户远程提供售后支持，也不等于它在 Paris 拥有一个本地 Service Center。
Supplier Unit 的核心概念是 Direct Provider。
Google 给出的示例包括真实 Brick-and-mortar Business Owner 和实际服务提供商，例如 Plumbing Provider。
因此，外贸网站应该表达真实服务覆盖能力，而不是人为制造不存在的 Local Entity。
十八、真正值得关注的是拥有欧洲服务网络的 B2B 企业
如果企业在欧洲确实拥有子公司、经销商、代理商、Showroom、仓库、安装团队、维修中心、售后服务点，那么此次更新就非常值得纳入国际 SEO 体系。
因为这些关系不应该只存在于一段 Dealer 文字、一张 PDF 或一个 Contact 页面。
应该进一步清楚表达：
- 谁是 Manufacturer；
- 谁是 Distributor；
- 谁提供 Sales；
- 谁负责 Installation；
- 谁负责 Maintenance；
- 具体 Service Area；
- Location；
- Business Hours；
- Contact；
- 支持哪些产品。
这本质上是 Entity Relationship Modeling。
十九、对工业 B2B 企业，最大的 Local SEO 机会可能不是产品，而是 Service
很多制造企业习惯把 SEO 全部围绕 Product、Supplier、Manufacturer、Factory、Price。
但设备进入海外市场以后，会产生大量具有明显 Local Intent 的查询：
Installation、Repair、Maintenance、Inspection、Spare Parts、Technical Support、Dealer、Service Center。
Google 现在已经明确把服务商，例如 Plumbing Provider，作为 Supplier Unit 的直接供应商示例。
因此，对拥有欧洲本地售后网络的工业企业，一个值得重新构建的模型是：
Product Search 可以是 Global，Service Search 往往是 Local。
这可能比继续增加普通 Blog Article 更值得投入。
二十、这次更新不是新的 Schema Update
需要特别强调：Google 9 月 18 日没有宣布新的 Supplier Schema、新的 Aggregator Schema、新的 LocalBusiness Schema 或新的结构化数据 Ranking Factor。
Supplier Unit 甚至明确说明：基础参与不要求提供 Web Crawling 之外的额外数据。
现有的 LocalBusiness、Organization、Product、Service 等结构化表达，可以继续按照自身正确场景使用。
但不要因为这次更新人为创造 SupplierUnit schema 或 AggregatorUnit schema 这样的不存在规范。
二十一、LocalBusiness Structured Data 依然值得正确使用，但它不是 Supplier Unit 门票
Google 当前的 LocalBusiness 结构化数据文档仍然建议：对每个真实本地营业地点使用 LocalBusiness 类型，并尽量选择更加具体的子类型。
这对于实体理解、搜索展示、数据一致性仍然有价值。
但是：
Structured Data Validity ≠ Supplier Unit Eligibility。
不能把“部署 LocalBusiness Schema”直接等同于“进入 Supplier Unit”。两者不是同一个系统条件。
二十二、Search Console 怎么监测？
Google 在 Aggregator Unit 最佳实践中建议继续通过 Google Search Console 监测整体 Search 表现。
但截至当前官方文档，并没有宣布一个新的 Aggregator Unit 或 Supplier Unit Search Appearance Filter。
因此，企业现在更现实的监测方法应该是：
EEA国家 + Local Intent Query Cluster + Location / Service Page + Impressions + Clicks + CTR + Average Position + Conversions
联合分析。
同时把 2026-09-18 Local Business Aggregator/Supplier Support 记录为 SEO Intelligence Event。
二十三、建议把此次更新纳入 SEO 自动审计系统
对拥有欧洲实体网络的企业，可以增加：
entity_type
entity_role
country
city
address
service_area
business_hours
phone
local_page
dealer_relationship
services
images
schema_type
verified_real_world_entity自动输出：
VALID_LOCAL_ENTITY
MISSING_ADDRESS
MISSING_SERVICE_SCOPE
ENTITY_NAME_INCONSISTENT
POSSIBLE_FAKE_LOCATION_PAGE
DEALER_RELATIONSHIP_UNCLEAR
LOCAL_SCHEMA_MISSING
IMAGE_ASSET_INSUFFICIENT这样的检查结果。
对于 Aggregator/VSS 项目，则需要增加：
vss_eligibility
poi_feed_status
feed_freshness
entity_match_status
landing_page_consistency等字段。
这会比简单建立“城市关键词页面生成器”更符合此次 Google 更新真正透露出的方向。
二十四、风险与机会判断
普通中国 B2B 出口企业
即时 SEO 风险：低。
如果没有 EEA 真实本地业务，这次更新不会突然改变普通全球产品页面的 Ranking 逻辑。
在 EEA 拥有真实本地服务网络的企业
战略影响：中等。
尤其值得重新整理 Dealer、Warehouse、Installation、Maintenance、Repair、Service Center 等实体和服务关系。
Local Directory / VSS / Aggregator
影响：较高。
因为其参与已经涉及 VSS 资格、POI Feed、实体数据、图片、Category、数据准确性、Landing Page 一致性等完整的 Search Infrastructure 要求。
二十五、项目原创判断：Local SEO 正在从“城市页面优化”扩展到“Local Entity Supply Chain”
从长期 SEO Intelligence 角度，这次更新最值得保留的，不只是“Google 增加了 Local Business Query”。
更重要的是 Google 正在更清楚地表达一条商业实体链：
User Query → Aggregator → Entity Inventory → Direct Supplier → Landing Page / Real-world Service
这可以定义为：Local Entity Supply Chain。
需要强调：这是项目方法论，不是 Google 官方术语。
但它比传统 keyword + city + page 更准确地描述了正在形成的商业搜索环境。
未来 Local SEO 要回答的不只是“哪个页面排第一？”，还需要回答：
- 谁是 Aggregator？
- 谁是真正的 Supplier？
- 这个实体是否真实？
- 实体数据来自哪里？
- 业务关系是否准确？
- Google 看到的数据与 Landing Page 是否一致？
结论
Google Search Central 在 2026 年 9 月 18 日把 Local Business Queries 正式加入 Aggregator Unit 和 Supplier Unit 支持范围。
它不是一次 Ranking Update。
但它是 EEA 商业搜索体验持续结构化的一步。
对于 Aggregator，Google 越来越依赖：
VSS资格 + POI Feed / API + Entity Data Quality + Search Feature Eligibility。
对于 Direct Supplier，Google 仍然允许通过正常 Web Crawling 获得基础参与资格，不要求额外 Feed。
因此，这次更新给外贸独立站真正带来的启示，不是“再生成 500 个城市页”，而是：
重新梳理企业在海外真实存在的商业实体和服务网络。
产品可以全球销售，但安装、维修、售后、经销、仓储、现场服务往往发生在具体地区。
如果企业真的拥有这些能力，就应该把它们转化成清楚、真实、可抓取、可验证的实体信息。
Google 正在越来越明确地区分：谁汇总商业实体，谁真正提供服务。
未来 Local SEO 更可靠的竞争力，也会越来越来自：真实实体 + 清晰关系 + 准确数据 + 稳定网站信息，而不是制造更多并不存在的地域关键词页面。