官方更新日期：2026年11月9日
监测日期：2026年11月10日（北京时间）
官方来源：Google Search Central Documentation Updates
更新类型：区域性搜索展示功能及查询支持范围扩展
适用区域：欧洲经济区（EEA）
是否属于排名算法更新：否
2026年11月9日，Google Search Central更新了两份搜索展示功能文档，将“Things to do”（景点、游览及相关体验活动）查询正式纳入Aggregator Unit（聚合服务展示单元）与Supplier Unit（直接供应商展示单元）的支持范围。
这项变化涉及Google在欧洲经济区的搜索结果展示机制。
对于景点信息平台、旅游服务聚合商，以及直接提供符合条件的景点服务的企业，这意味着相关业务可能获得新的搜索展示机会。
但需要明确，此次更新不是Google首次支持Things to do相关搜索内容，也不是一次新的搜索排名算法调整。
真正发生变化的是：Google将Things to do纳入欧洲经济区特定搜索展示单元的支持范围，并明确了聚合平台与直接供应商参与这些单元的不同路径。
值得关注的不只是新增了一个查询类别，而是Google正在通过不同的展示机制，区分信息聚合服务与实际服务提供者。
这对依赖搜索获取客户的企业提出了一个具体问题：
网站究竟是在帮助用户比较服务，还是自己直接提供服务？这两种业务身份，可能对应完全不同的搜索展示与数据接入要求。
一、11月9日更新了什么？不是新增排名规则，而是扩大查询支持范围
Google在官方文档更新日志中公布：
Added “things to do” query support to the aggregator and supplier units
对应的两份文档分别是：
此前，这两类展示单元已经支持酒店、航班、长途交通、商品及本地商家等相关查询。
11月9日的更新将Things to do加入支持范围。
从搜索结果的组织方式看，这种变化意味着：当欧洲经济区用户查询符合条件的景点或活动信息时，Google可以通过聚合服务单元展示相关平台的信息，并在相应条件下同时展示直接服务提供商。
例如，用户搜索某座城市的博物馆、观景台或其他景点时，相关搜索结果可能出现来自不同聚合平台的信息入口，以及符合条件的直接服务提供者入口。
这里的“可能”十分重要。
Google并没有宣布所有Things to do查询都会触发这些展示单元，也没有承诺所有相关企业都能自动获得展示资格。
查询类型获得支持、企业符合参与条件、具体结果获得展示，是三个不同的判断层次。
企业不能仅凭自己的网站包含景点或旅游活动内容，就认定已经具备参与资格。
二、Aggregator Unit与Supplier Unit：两种业务身份，两条展示路径
理解此次更新，需要首先区分两类展示单元的作用。
Aggregator Unit：帮助用户比较多个服务来源
Aggregator Unit主要面向Vertical Search Services（VSS，垂直搜索服务）。
典型参与者包括在线旅游代理商、比价平台、元搜索服务，以及提供相关信息检索和比较的目录平台。
这类企业通常不直接经营页面列出的全部服务，而是汇集多个服务提供者的信息，帮助用户进行比较和选择。
Google官方文档描述了一种展示机制：
符合条件的聚合平台可以在对应单元中提供与用户查询相关的结果。默认情况下，排名靠前的平台结果会展开显示；如果有其他参与平台，用户也可以切换查看其内容。
同一时间，搜索结果中只展示一个处于当前选择状态的Aggregator Unit。
用户点击其中的结果，可以进入对应聚合平台提供的网页。
这使Aggregator Unit不同于普通自然搜索结果。
它不仅展示一个网页链接，还可能通过结构化的信息组织形式，帮助用户比较不同地点或服务。
对于经营景点目录、门票信息聚合或旅游资源比较服务的平台，参与这类展示可能具有商业价值。
但这不是通过优化Title、Description或增加相关关键词就能获得的功能。
Aggregator Unit属于具有专门参与资格与数据接入要求的搜索展示机制。
Supplier Unit：让直接服务提供者获得相应展示入口
Supplier Unit的参与角色不同。
Google将其定义为面向直接供应商的专用展示功能。官方举例包括酒店、航空公司、实体商家及直接提供相关服务的企业。
在Things to do场景下，符合条件的景点经营者等直接服务提供商，可以属于这一类角色。
例如，同样围绕一座观景台：
一家汇总多个观景台、景区及票务信息的平台，可能属于聚合服务提供者。
而实际经营观景台并向用户提供入场服务的企业，则可能属于直接供应商。
两者可以围绕同一搜索需求提供不同的信息入口，但不应混为同一种业务身份。
Google还明确规定：
Supplier Unit只有在Aggregator Unit出现时才会出现。
这意味着Supplier Unit不是任何符合条件的供应商都能独立触发的搜索展示模块。
它的出现首先取决于相应查询是否展示Aggregator Unit，然后才涉及直接供应商的展示机会。
这一机制也决定了，企业不能把Supplier Unit理解为类似普通自然排名的固定展示位置。
三、参与资格并不相同：聚合平台需要数据接入，直接供应商主要依赖网页可访问性
此次更新最有实际价值的部分，是Google明确了两类参与者不同的数据要求。
对于Aggregator Unit，Google要求企业符合相应资格、具备相关内容、提供必要数据，并遵守搜索内容政策。
有意参与Things to do相关聚合展示的企业，可以通过官方的Google Search Aggregator Features表单表达参与意向。
官方表单已列出Things to do相关查询选项。
但提交意向不代表Google已经批准参与，也不意味着提交后就能获得展示。
更重要的是数据接入。
Google在Aggregator Unit文档中说明，酒店、本地商家及Things to do相关单元主要通过直接数据Feed集成获取展示信息。
对于本地商家和Things to do查询，文档指向了Local and things to do Point of Interest Feed。
这意味着企业需要考虑的不只是网页是否能够被抓取，还包括能否持续向Google提供符合规范的数据。
例如，景点名称、地点、类别、相关图片、服务信息及落地页地址等，都可能涉及数据质量要求。
相较之下，Supplier Unit的要求明显不同。
Google明确表示，直接供应商不需要为了出现在该功能中，额外提供超出网页抓取可获取范围的数据。
如果存在合适的数据Feed，相关结果可以得到进一步增强。
这一区别直接影响企业的实施成本。
聚合平台需要评估合作资格、Feed建设及持续的数据维护能力。
直接供应商则可以优先确保自身网页能够被Google正常访问，并准确表达企业及服务信息。
网页可抓取性是Supplier Unit的重要基础，但不是获得展示的充分保证。
四、一个容易忽视的限制：“Things to do”不代表所有旅游活动都符合接入条件
这是此次更新中最需要细分的地方。
Things to do在一般旅游语境中可以涵盖景点、导览、演出、观光、短途体验和各种活动。
但Google在具体产品和数据接入政策中，对不同项目有更细的分类和资格要求。
根据Google Actions Center的Local Aggregator Unit平台政策，当前支持的Things to Do（Attractions）兴趣点类别包括：
博物馆、历史地标、纪念性建筑、美术馆、观景台、植物园、动物园、水族馆及主题公园等。
与此同时，该政策明确列出了一些不属于这一接入类别的项目，例如现场音乐会、体育赛事、临时节庆活动，以及单日或多日导览和游船行程。
这里必须注意适用边界：
这些限制针对的是Local Aggregator Unit的特定POI数据接入机制，不能直接推导为Google所有Things to do产品都不支持相关活动。
Google本身还有其他与Things to do相关的搜索及合作伙伴机制。
因此，运营企业在评估参与资格时，需要进一步判断具体业务属于景点、活动、导览还是其他产品类别，而不是直接将所有旅游项目归入同一数据Feed。
这也说明，Google Search Central文档中的查询类别，与Google Actions Center具体集成规范中的商品或服务类别，并不总是一一对应。
对于提供多个旅游产品类型的平台，先完成业务分类与接入资格核对，再开发数据接口，比直接建设一个统一Feed更加合理。
五、不要混淆三种Google搜索机制：展示单元、结构化数据轮播与Things to do合作项目
此次文档更新还容易引发另一种误解：
既然Google新增支持Things to do，是否意味着企业可以通过添加新的Schema直接获得展示？
答案是否定的。
但这并不代表Google没有与Things to do相关的结构化数据功能。
需要区分三类机制。
第一类是本次更新的Aggregator Unit和Supplier Unit。
它们属于欧洲经济区的特定搜索展示机制。聚合平台涉及资格审核与数据Feed集成，而直接供应商可以依赖网页抓取获得相应的参与机会。
第二类是Structured data carousels（beta），即结构化数据轮播结果测试功能。
这是一项独立的搜索功能。
Google现有文档已经说明，在符合条件的地区和查询场景下，网站可以通过ItemList配合受支持的LocalBusiness、Product或Event等结构化数据，申请符合相关轮播结果的技术资格。
该功能也支持部分Things to do相关查询，但它有自己的页面结构、标记与功能可用性要求。
因此，不能把本次Aggregator Unit与Supplier Unit扩展，错误理解为Google在11月9日新增了一个通用的Things to do Schema。
第三类是Google Actions Center已有的Things to do合作伙伴项目。
该项目允许符合条件的合作伙伴通过Feed集成，向Google相关服务提供旅游活动数据，也涉及特定的广告应用。
它有独立的参与资格、技术规范和合作流程。
这三个机制可能涉及相近的业务内容，但并不是同一个产品，也不意味着使用其中一种数据接入方式就能自动参与其他功能。
对于企业而言，正确的技术顺序应该是：
先确定目标搜索功能，再核对参与资格，最后选择对应的数据接入与页面优化方案。
而不是看到Things to do这个名称，就开始全站添加结构化数据或开发接口。
六、对中国出口企业和欧洲市场网站意味着什么？
此次更新的直接影响主要集中在服务欧洲经济区用户的相关网站。
判断适用性时，不能只看企业注册地或网站语言。
Google文档强调的是相关功能面向欧洲经济区用户，以及企业是否提供与对应查询类型相关的服务。
一家位于中国、但实际服务欧洲经济区用户的合格聚合平台，可以依据官方要求评估参与机会。
一家在欧洲经营景点的直接服务提供者，也可以关注Supplier Unit的相关条件。
但仅仅使用英语、法语、德语建立网站，并不自动产生参与资格。
更重要的是业务模式、服务范围和数据质量。
对旅游景点及相关平台
这项更新增加了一个值得评估的搜索分发渠道。
对于聚合平台，需要研究现有业务能否满足VSS资格要求，以及相关数据是否能够持续更新。
对于符合条件的景点经营者，需要提高重要落地页的信息完整性和可访问性。
例如，页面是否能够清楚说明景点名称、地址、开放时间、价格或预订方式，用户是否能够直接找到真实有效的服务入口。
这些内容不仅关系到机器读取，也影响用户从搜索结果进入网站后的实际决策。
对一般B2B外贸独立站
此次更新没有直接新增工业设备、工程机械或制造业产品网站的搜索功能资格。
没有必要因为Google新增Things to do查询支持，就修改产品页模板、robots.txt、canonical标签或现有结构化数据配置。
对于普通B2B网站，更重要的工作仍然是保证产品和解决方案页面可抓取、可索引，技术参数准确，国际化页面关系合理，并且能够有效支持客户采购决策。
搜索功能更新的重要性，应当依据业务相关性判断，而不是依据更新名称或行业讨论热度判断。
企业应避免把无关的搜索展示变化转化为不必要的网站开发成本。
七、符合条件的企业，应该怎样落实此次更新？
对于准备参与欧洲Things to do相关搜索展示的企业，建议将工作分成资格评估、数据治理和效果验证三个阶段。
先确认参与身份与资格
第一步不是修改网站，而是判断企业究竟属于聚合平台还是直接供应商。
聚合平台应阅读Aggregator Unit的资格要求，并通过官方申请入口核对相关查询类别。
如果经营的是景点聚合服务，还需要仔细核对Local Aggregator Unit的POI政策，确认哪些实体符合要求。
直接供应商则需要确定实际提供的服务是否落在当前功能范围内，以及对应网页能否被Google访问。
对于包含景点、导览、演出、体验等多类业务的平台，最好先按服务类型完成分类，再分别核对政策。
再解决数据准确性与落地页质量
Google在Aggregator Unit最佳实践中强调，企业应尽可能提供完整的实体信息、清晰的图片、准确的标题，以及与实际服务一致的价格和可用性信息。
对聚合平台而言，尤其需要关注Feed中的数据与目标网页是否一致。
例如，一个景点已经更改开放时间，平台Feed却仍保留旧信息；或者活动已下架，但搜索展示仍然指向对应页面。
这类问题会造成用户预期与实际服务不一致。
企业应建立定期更新、数据去重、异常检测和失效内容清理机制。
对于POI类数据，Google还要求使用稳定的实体标识，并维护准确的类别信息。
这意味着真正的技术投入不仅是生成一次Feed，还包括长期维护数据质量。
直接服务提供商则应优先检查核心落地页的可抓取性、内容完整性及内部链接，避免重要服务信息只存在于无法稳定访问的脚本界面、图片或登录后页面中。
最后观察真实展示与业务效果
即使完成相关资格申请或数据接入，也不应立即将项目视为成功。
企业还需要核对相关查询是否实际触发展示、网站是否获得有效访问，以及这些访问能否转化为真实的业务行为。
可以结合Google Search Console、网站分析工具和内部订单系统进行观察。
不过，需要注意：
现有官方文档并未承诺为Aggregator Unit或Supplier Unit提供独立、完整的效果归因报告。
因此，不应预先假定Search Console能够单独识别这两种展示单元的全部曝光与点击数据。
更合理的评估方式，是结合可获取的搜索数据、落地页访问、预订转化和业务记录，同时保留对归因限制的说明。
也不应将自然搜索流量的整体增长或下降，直接归因于此次文档更新。
八、进一步判断：Google正在将搜索展示资格与业务身份、数据能力结合起来
此次更新虽然范围有限，但从搜索产品设计角度看，具有值得关注的意义。
传统SEO主要围绕网页展开。
企业创建页面，搜索引擎进行抓取、索引和排序，用户通过搜索结果访问网站。
Aggregator Unit和Supplier Unit并没有取代这套机制，但它们提供了另外一种展示路径。
在这种路径下，Google不仅需要理解网页内容，还需要识别企业在服务生态中的角色。
同样展示景点信息，聚合平台与直接服务提供者承担的商业责任不同。
聚合平台需要提供跨供应商的信息组织与比较能力，并维护相关数据。
直接供应商则需要准确说明自己实际提供什么服务，以及用户如何获取该服务。
由此可以形成一个判断：
未来部分垂直搜索功能的参与能力，可能越来越依赖业务身份、实体信息质量和数据交换能力，而不只是传统网页优化。
但这属于对现有机制的分析，不代表Google已经宣布将其作为普遍排名规则。
对于企业而言，这一变化提示了搜索优化工作中的三个不同层次。
首先是网页层面，解决内容可访问性、索引、页面结构和用户体验。
其次是实体层面，保证企业、地点、产品或服务具有准确、一致、可核验的信息。
最后是接入层面，只有在相关搜索功能确实提供参与机制时，才进一步评估资格申请、Feed或API集成。
这三个层次可以相互补充，却不能相互替代。
一个网页即使完成所有常见SEO优化，也未必符合特定垂直搜索服务的参与条件。
同样，企业即使完成数据接入，也不能因此保证在搜索结果中获得固定展示位置。
搜索可见性与搜索功能参与资格，需要分别管理。
九、结论：此次更新的重点是搜索展示机会，而不是新的SEO技巧
2026年11月9日，Google将Things to do查询加入欧洲经济区Aggregator Unit和Supplier Unit的支持范围。
这是一项明确的区域性搜索展示功能扩展。
它为符合条件的景点信息聚合平台及直接服务提供商，提供了值得评估的搜索展示路径。
但此次更新没有改变所有网站的通用SEO要求，也没有新增一个可以通过简单配置Schema获得展示资格的通用机制。
对相关企业而言，真正需要解决的问题是：
业务身份是否符合要求，服务项目是否处于支持范围，网站与数据能否满足对应功能的接入条件，以及最终能否获得可验证的业务价值。
对普通外贸B2B企业而言，则没有必要为不适用的功能投入额外开发成本。
这次更新提供的实际启示是：搜索优化不应只研究“Google新增了什么”，还应判断“新增功能服务于谁、需要什么数据、能否产生实际业务价值”。
只有完成这些判断，Google文档更新才真正能够转化为合理的网站运营决策。
官方参考资料
- Google Search Central Documentation Updates：2026年11月9日更新日志，确认Aggregator Unit与Supplier Unit新增Things to do查询支持。https://developers.google.com/search/updates
- Aggregator unit in Google Search：介绍聚合服务展示机制、支持范围、参与资格、数据Feed与质量要求。https://developers.google.com/search/docs/appearance/aggregator-unit
- Supplier unit in Google Search：介绍直接供应商的参与条件、与Aggregator Unit的关系及网页抓取要求。https://developers.google.com/search/docs/appearance/supplier-unit
- Regional differences in Search experience：Google不同区域搜索展示功能的官方总览。https://developers.google.com/search/docs/appearance/aggregator-features
- Google Actions Center — Local Platform Policies：说明Local Aggregator Unit的POI接入条件、支持的景点类型及排除范围。https://developers.google.com/actions-center/verticals/local_vss/policies/platform-policies
- Structured data carousels (beta)：用于区分结构化数据轮播功能与此次更新的聚合服务、直接供应商展示单元。https://developers.google.com/search/docs/appearance/structured-data/carousels-beta
- Google Actions Center — Things to do：Google既有Things to do合作伙伴机制及接入说明。https://developers.google.com/actions-center/verticals/things-to-do/overview
资料核验日期：2026年11月10日。
本文依据Google Search Central及Google Actions Center公开技术文档编写。文中对搜索生态变化和企业运营策略的分析属于基于官方机制形成的判断，不等同于Google对排名、流量或转化效果的承诺。