Google's Aggregator Units Are Not an SEO Play
Quick answer: Aggregator units are multi-provider blocks that show directory and comparison-site results inside Google Search, and Google extended their documentation to local business queries on 18 September 2026. You cannot earn your way into one with structured data. Entry requires approval as a Vertical Search Service plus a direct data feed or real-time API integration, and the feature only runs for users in the European Economic Area. For everyone else it is a curiosity, not a channel.
Every few weeks someone running a directory site sees a screenshot of a Google results page with a tabbed block of competing comparison sites in it and asks the obvious question: how do I get in there?
The honest answer is that this is not a search feature in the sense you are used to. It is a regulatory accommodation with an access programme attached, and the qualifying step is a commercial approval, not a markup change.
What the unit actually is
Google's documentation on aggregator units describes a block that surfaces results from multiple providers at once: online travel agencies, comparison shopping services, metasearch engines and directories. The top-ranked provider's results are expanded by default. The user can switch to another aggregator from within the same block.
Next to it sits a second block. Google's phrasing is that, "to provide visibility to direct providers, Google Search shows another unit alongside the aggregator unit" — the supplier unit, which carries results from the businesses themselves rather than from the intermediaries listing them.
Two blocks, two populations. Aggregators in one, the underlying suppliers in the other. That architecture is the giveaway: this is a structural answer to a complaint about intermediaries being squeezed out of results, not a reward for good pages.
Five verticals, one region
The units appear for queries about hotels, flights, long-distance trains and buses, products, and — as of the September 2026 documentation update — local businesses. Google's documentation changelog records the local business extension on 18 September 2026.
Notice what is not on that list. Software. Developer tools. SaaS. B2B services of any kind. If you run a product directory for technical tooling, there is currently no vertical for you to be an aggregator in, and adding one is not a thing you can request.
The second constraint is geographic. These features are available only to users in the European Economic Area. That ceiling is not a rollout phase you can wait out. The whole apparatus exists because of European competition regulation, which is also why the same period produced an EEA-specific carve-out in Google's site reputation enforcement and a refreshed European Search Dataset Licensing Program page. A US or Indian audience never sees any of it.
The four conditions, and the one that gates everything
Google lists four requirements to appear in an aggregator unit. Paraphrased tightly: be approved as a Vertical Search Service; have content relevant to the query type; supply the data through direct feed integrations or real-time APIs; and comply with Search's content policies.
Three of those are ordinary. The first is the entire story. Vertical Search Service approval is a status Google confers, and there is no public application page, no published threshold, and no documented appeal. The documentation names it as a precondition and then moves on. If you are trying to plan around this, plan around the fact that the gate is opaque by design.
The third requirement is the second-hardest. Each vertical has its own integration path:
| Query type | Data path Google names |
|---|---|
| Hotels | Lodging Point of Interest Feed |
| Flights | Partner standard Live API |
| Trains and buses | Transport features API |
| Products | Product pages across Google |
| Local businesses | Local Point of Interest Feed |
Feeds and live APIs are integration work with an operational tail: schema conformance, freshness obligations, error budgets, someone on call when the feed breaks at 3am. That is a partner-engineering commitment, not a content project. Budget for it the way you would budget for any API and backend integration you have to keep alive indefinitely.
Structured data does not get you in
This is where a lot of directory operators waste a quarter. The instinct is reasonable — Google publishes structured data requirements for most result types, so surely there is markup that qualifies you here too. There is not. Nothing in the eligibility list mentions schema.org at all. The data arrives through a feed, out of band, and the markup on your pages is not the channel.
What structured data still does is earn the ordinary result: the breadcrumb trail, the correct entity resolution, the eligibility for whatever rich treatments survive in your category. That is a real return and it is the one available to you everywhere in the world rather than in thirty countries. We have written before about what schema is actually worth now that FAQ rich results are gone, and the conclusion holds here: markup is for machine comprehension, not for admission to walled features.
If you want that part tightened this week rather than next quarter, the breadcrumb schema generator and the canonical tag generator cover the two things directories most often get wrong at scale: ambiguous hierarchy and duplicated facet URLs.
What a directory can actually control
Strip out the parts you cannot influence and a short list remains.
Be the best answer to the comparison query, not the listing query. Aggregator units compete for the transactional head term. They do not compete for "X vs Y for teams under 20 people". That is where a directory's structural advantage lives, and it is why we argue for comparisons built on real attribute data rather than forty near-identical landing pages.
Make your taxonomy survive the data you actually have. A feed-grade directory and a search-grade directory need the same thing underneath: categories that do not collapse when a product fits three of them. That is a design decision made once and regretted for years, which is why it gets its own treatment.
Keep the generated surface above the thin-page line. Directories live and die by programmatic pages. The gate matters more than the generator, and the publish gate is the piece most teams skip.
Build the feed anyway, for a different reason. If you already maintain clean, typed, fresh product data with an API in front of it, you are positioned for whatever integration programme does open — and in the meantime that same data is what makes curated collections and category browsing worth using. The feed is not wasted work. Waiting on Google to approve it would be.
FAQ
Can I add markup to qualify for an aggregator unit?
No. Google's stated conditions are Vertical Search Service approval, relevant content, data supplied through direct feed integrations or real-time APIs, and content policy compliance. Structured data on your pages is not one of them.
Which queries show aggregator units?
Queries about hotels, flights, long-distance trains and buses, products, and local businesses. Local businesses were added to the documentation on 18 September 2026. Software and SaaS queries are not covered.
Do these units appear outside Europe?
Google documents them as available only to users in the European Economic Area. If your traffic is predominantly outside the EEA, this feature does not affect your search results at all.
What is the supplier unit for?
It is a second block shown alongside the aggregator unit that gives visibility to direct providers — the hotels, airlines or businesses themselves — rather than to the intermediaries that list them.
How do I apply to become a Vertical Search Service?
Google names VSS approval as a requirement but does not publish an application route or eligibility threshold in the aggregator unit documentation. Treat it as a commercial partner conversation rather than a self-serve process, and verify current status with Google directly before committing engineering time.
Is building a product data feed worth it if I cannot get into a unit?
Usually yes, but justify it on your own product rather than on Google. Typed, fresh, queryable product data powers comparison pages, filters, collections and your own API. Feature eligibility, if it ever arrives, is a bonus on top of work that already paid for itself.
See how the structured approach looks in practice across the SEO and content tooling category, or submit a product if you want yours in the dataset.