Google documents two EEA-only search units: aggregator and supplier

Google Search Central published documentation on 8 September 2026 for two result units that appear only to people searching in the European Economic Area: the aggregator unit and the supplier unit. The aggregator unit gives approved Vertical Search Services a block on the results page for hotel, flight, long distance train and bus, and product queries, and the supplier unit puts direct businesses such as individual hotels and airlines next to it.

The two pages arrived with a third, titled "Regional differences in Search experience", which maps every region-specific feature Google now runs across the EEA, South Africa and Türkiye. All three carry a last updated date of 8 September 2026. None of this is live on google.co.th, and the documentation says so in its own way: feature availability is stated as the EEA and nothing else.

What Google documented on 8 September 2026

The page, titled "Aggregator unit in Google Search", opens by telling EEA users that a search for something like "hotels near me" may look different than it used to. That framing matters, because it tells you the units are already appearing rather than being previewed. Google then explains the mechanism and, unusually for Search Central, explains how to ask to be included.

That last part is the reason this documentation is worth reading closely even from Bangkok. Search Central normally documents how to earn a result: mark up your page, meet the guidelines, rank. The aggregator unit page documents an application. Google writes that businesses are eligible when they are approved as a Vertical Search Service, when they provide the necessary data, and when they meet the established quality standards to participate. Approval comes first, ranking comes after, and the approval step is a form.

How the aggregator unit works

Google describes the aggregator unit as a multi-provider feature designed for Vertical Search Services, and names Online Travel Agencies, Comparison Shopping Services, metasearch engines and directories as the kinds of business it is for. Inside the unit, eligible aggregators populate their own block with results relevant to the query. Google's own example is a search for "hotels in paris" returning a list of top-ranked hotels with photos, prices or star ratings drawn from one eligible provider. Clicks inside the unit go straight to that aggregator's website.

Users are not stuck with whichever provider Google picked. The documentation says people can select a different provider from a list of alternative aggregators where one is available, and the unit then repopulates with results from the newly chosen aggregator.

Only one aggregator unit shows at a time

Google states plainly that only one aggregator unit will show at a time, and that the top-ranked provider's results are expanded by default. Those two sentences carry most of the commercial weight in the page. The competition inside this feature is not for one of ten blue links. It is for the default expansion, with every other approved provider reachable only by a user who bothers to open a dropdown and switch.

Google does not publish how the top-ranked provider is selected. The best practices section says only that information is shown in the unit based on what is most helpful to users for their queries, and points readers at the Search Quality Rater guidelines. There is no documented signal list, no scoring, and no way to see your position in the switcher other than through your own traffic.

The supplier unit for direct providers

The supplier unit is the counterweight. Google describes it as a dedicated feature for direct providers, giving individual hotels, airlines, brick and mortar business owners and providers of services such as plumbing as its examples. It appears alongside the aggregator unit, and the documentation adds a condition that is easy to skim past: the supplier unit only appears if the aggregator unit appears.

Two requirements are listed for the supplier unit. The website must serve users in the EEA, and the business must be a direct provider that could plausibly appear for hotel, flight, long distance train or bus, or product queries. Google then notes that no additional data is needed beyond what is accessible through web crawling, though supplier results can be enhanced with data feeds where a business has them.

So a hotel does not apply, does not submit a feed and does not sign anything. It becomes visible because Google crawled its site, and it becomes visible only in the moments when an aggregator unit has already been triggered for that query. Visibility for the direct business is contingent on a feature built for the aggregators it competes with.

Who qualifies for the aggregator unit, and how the application works

Google lists four conditions on the aggregator unit page. A business must express interest through a form, must have relevant content for the query types the unit serves, must provide data to populate the unit, and must comply with Google Search's content policies.

The forms are split by vertical. For ground transportation, flight and hotel queries, Google points to the Google Search Aggregator Features form. For product queries, it directs businesses to the comparison shopping services contact form. The documentation gives no processing time, no acceptance criteria beyond approval as a Vertical Search Service, and no appeal route for a business that is turned down.

The data an aggregator has to supply

Participation is a feed and API commitment, not a markup exercise. Google names a different integration for each vertical: the Lodging Point of Interest Feed for hotel queries, the Transport features API for ground transportation, the Partner standard Live API for flights, and its existing product pages guidance for product queries. It also splits the delivery mechanism by vertical, saying flight and transport units are populated by real-time APIs while lodging and local business queries are populated by direct data feed integrations.

That single mention of local business queries is the only place local appears in the mechanics, and it sits at odds with the feature availability section, which limits the unit to hotels, flights, long distance trains or buses, and products. Google does not say whether local queries are coming, or when.

What Google asks participants to send

The best practices are specific enough to act on. Google asks for rich entity details, listing images of the entity, detailed descriptions and specifications, verified user ratings and review counts, specific categories such as "Boutique hotel" or "Eco-resort" instead of a generic "Hotel", plus key amenities, features and operating hours. It asks for factual, descriptive titles in title case and says to avoid all caps, excessive punctuation, emoji and promotional text such as "BEST DEALS" or "Free shipping" in entity names.

On imagery, Google asks for clear original photography, clean backgrounds without watermarks or promotional overlay badges, and high resolution where possible. On data hygiene, it asks that prices and availability in feeds match the landing page as closely as possible and that feeds be refreshed to drop expired or out of stock listings. Finally it points participants at Search Console to monitor performance, without saying whether the units get their own reporting there.

The regional feature map Google published alongside

The "Regional differences in Search experience" page is the most useful of the three, because it shows the aggregator and supplier units are part of a wider set of region-specific result types rather than a one-off. This is what it lists.

The same page also lists structured data carousels for the EEA, South Africa and Türkiye, and a badge and refinement chip specific to businesses based in South Africa. Structured data carousels are the one entry on that page open to any site that implements the markup, with no approval step attached.

What the documentation does not say

The gaps are as informative as the content, and worth stating plainly, because other coverage will fill them in with assumptions.

• The pages never mention the Digital Markets Act, the European Commission, or any regulatory proceeding. The only justification offered is that Google is evolving the results page to provide new opportunities for Vertical Search Services, Comparison Shopping Services, direct suppliers and content providers.
• There is no launch date, no rollout schedule and no statement of when the units started appearing. The wording implies they are already visible to some EEA users.
• Nothing is said about how the units interact with the ordinary organic results underneath them, whether they push listings down, or whether a site can appear in both places for the same query.
• Nothing is said about paid placement, cost, or whether participation carries any commercial terms.
• There is no approval timeline and no stated recourse if a business is not approved as a Vertical Search Service.
• Google does not say whether the units are reported separately in Search Console, only that participants should keep up with what is happening across Search there.

What this means for Thai marketers

Directly, nothing changes on google.co.th. The feature availability sections on both pages restrict the units to users in the EEA, and Thailand is not in any of the three regions Google's feature map covers. Anyone telling you to prepare a Thai site for the aggregator unit is selling something.

The second-order effect is real, though, and it lands on a specific group. Thai hotels and resorts that sell to European travellers, Thai carriers competing for European flight queries, and Thai exporters whose product pages rank for European product searches are all served results by google.de, google.fr and the rest. Their European SERP is the one being rebuilt. A booking aggregator that gets approved now occupies an expanded block on those queries, and the Thai hotel underneath it is reachable through the supplier unit only when that aggregator block fires.

A few checks are worth making if European demand matters to your business. Segment Search Console by country and look at whether impressions and click through rate for EEA countries move over the coming weeks against your Thai and regional baselines. Confirm that the pricing and availability shown on your own pages is crawlable rather than locked behind a booking widget script, because the supplier unit draws on what Google can crawl. And if you sell products into Europe, check that your product data is complete on the same attributes Google asked aggregators for, because those are the fields it says help users evaluate options. Solid ecommerce marketing foundations do the work here, since the feed quality that feeds European surfaces is the same feed quality that feeds Shopping and marketplace listings closer to home.

There is a broader read for anyone doing SEO in Thailand. Google's own best practice list for these units is a description of entity-level data quality: correct categories, real photos, verified ratings, amenities, opening hours, and prices that match the landing page. Those requirements are not EEA-specific, even though this feature is. They are the same inputs that decide how a Thai business renders in local results, product listings and AI-generated answers.

Frequently asked questions

Is the aggregator unit live in Thailand?

No. Google's documentation states that the aggregator unit is available to users in the European Economic Area for queries related to hotels, flights, long distance trains or buses, and products. Thailand is not mentioned on any of the three pages, and the regional feature map published on 8 September 2026 covers only the EEA, South Africa and Türkiye.

Do I have to submit a data feed to appear in the supplier unit?

No. Google writes that you do not need to provide additional data beyond what is accessible through web crawling to appear in the supplier unit, though it adds that supplier results can be enhanced with data feeds where available. The aggregator unit is the opposite case: it requires a direct feed integration or a real-time API depending on the vertical.

Can any comparison or booking site apply for the aggregator unit?

Any business serving EEA users can express interest, but eligibility is decided by Google. The documentation says businesses are eligible when they are approved as a Vertical Search Service, provide the necessary data and meet the established quality standards. It gives two contact forms, one for ground transportation, flight and hotel queries and one for product queries, and it does not publish the criteria used to approve or reject an applicant.

Does the aggregator unit replace normal organic listings?

The documentation does not say. It describes the aggregator unit and the supplier unit as additions to the results page for certain query types, and it explains that only one aggregator unit shows at a time with the top-ranked provider expanded by default. It makes no statement about the placement of these units relative to standard organic results or about any effect on the listings below them.

Does Google say this is about the Digital Markets Act?

No. The Digital Markets Act is not mentioned anywhere on the aggregator unit page, the supplier unit page or the regional differences page. Google frames the change as evolving the search results page to provide new opportunities for Vertical Search Services, Comparison Shopping Services, direct suppliers and content providers in specific regions, and offers no regulatory explanation.

Where this leaves you

Read the primary documentation rather than the summaries, because the operative details here are single sentences: only one aggregator unit at a time, the top-ranked provider expanded by default, and the supplier unit appearing only when the aggregator unit does. The full pages are on Google Search Central.

If your business earns revenue from European travellers or European buyers, the useful work this month is measurement and data hygiene rather than an application form. If you want a second pair of eyes on how your European organic performance is trending and whether your entity data would survive this kind of feed scrutiny, that is a conversation worth having now rather than after a quarter of drift.