Google's Aggregator Unit: What Directories Can Actually Get
Google documented four aggregator features on 8 September 2026. Region and vertical decide your eligibility, not markup. Here is which door fits.

On 8 September 2026 Google published a documentation page that names directories, by that word, as an intended participant in one of its search features. The aggregator unit page describes the feature as built for "Vertical Search Services (VSSs), including Online Travel Agencies (OTAs), Comparison Shopping Services, metasearch engines, and directories." Then it spends the rest of the page listing requirements that most directories will never satisfy.
Four features were documented that day, under a new section called Regional differences in Search experience. What follows is what each one actually requires, taken from Google's own words, so you can tell in about five minutes which of the four your directory could enter — and why, for a large share of readers, the answer is none of them and that is fine.
Every page quoted below carries the line "Last updated 2026-09-08 UTC" at the foot. All quotes were read off those pages on 9 September 2026.
The documentation is new, the features are not
Google announced this family of units in a Search Central blog post in February 2024. They have been live in the European Economic Area since. What appeared on 8 September is different in kind: the requirements now sit in the documentation tree, with a per-feature availability table and, in three of four cases, a named application path.
That matters because until this week the operational questions — do I need markup, do I need a feed, do I need approval — were answered by SEO news coverage rather than by Google. The Documentation updates log entry for 8 September puts the purpose plainly: to help "publishers, businesses, and aggregators learn about the different regional search features available and understand the eligibility criteria and how to participate."
So there is now a checkable answer. It differs by feature, and the spread is much wider than the shared section heading suggests. Wildly wider, in places.
The aggregator unit wants a pipeline, not a page
This is the door with the directory's name on it. It is also the most expensive one in the set.
Availability first. The unit shows to users in the EEA "for queries related to hotels, flights, long distance trains or buses, and products." Nothing else. If your directory covers dentists, SaaS tools, wineries or coworking spaces, you are out on the vertical alone, before any technical question comes up.
The eligibility sentence is worth reading twice: "Businesses are eligible to appear in the aggregator unit when they are approved as a Vertical Search Service (VSS), they provide the necessary data, and they meet the established quality standards to participate." Three conditions, and only the last one resembles ordinary SEO work.
"Provide the necessary data" is defined, and it is an integration project. Google: "Eligible aggregators that wish to participate must provide data to populate a unit by direct data feed integrations or real-time APIs for queries such as flights or long distance trains and buses." The specifications it points at are not Search documentation at all — they are the Lodging Point of Interest Feed for hotels, the Transport features API for ground transport, the Partner standard Live API for flights, and the CSS product route for products.
One more sentence shapes the economics of trying: "Only one aggregator unit will show at a time." The top-ranked provider's results are expanded by default, and users can switch to another provider from a list "if available." A single slot, contested, in four verticals, in one region. That is the whole prize.
Feeds and live APIs come with freshness obligations. Google's own best-practice line for this unit is to "ensure prices and availability in feeds match the landing page as closely as possible, and refresh feeds regularly to remove expired or out-of-stock listings." That is an ongoing pipeline with a support burden, not a launch task.
The supplier unit has no application form, and it is not yours
Sitting beside the aggregator unit is the supplier unit, the only one of the four with no application step whatsoever. It is also not yours.
Google's requirement: "Your business is a direct provider (for example, individual hotels or airlines, brick-and-mortar business owners, or providers of services like plumbing) that could appear for queries related to hotels, flights, long-distance trains or buses, and products." A directory is the opposite of a direct provider by definition — that is what "aggregator" means in this taxonomy.
Two facts here are still useful to you. First, the entry cost for a direct provider is nearly zero: "You don't need to provide additional data beyond what's accessible through web crawling to appear in this feature." Second, "The supplier unit only appears if the aggregator unit appears." The businesses in your listings can be surfaced by Google in the same result block that surfaces aggregators, without paying anyone, and without asking you.
If your revenue model is selling visibility to those same businesses, read that twice as well. Google now offers a competing shelf.
Job sites and Places sites: no markup, one form
Two of the four features are genuinely light. These are the ones a working directory can realistically pursue.
The job sites features give job aggregators a dedicated carousel and a refinement chip in the EEA. The places sites features do the same in Türkiye for local business and hotel queries. Both pages carry the identical sentence, and it is the single most consequential line across all four documents: "Publishers don't need to add any markup to be eligible for the aggregator carousel or refinement chips."
No feed. No API. No VSS approval language anywhere on either page. What each one does ask is that you tell Google you exist and serve that market: "If your business serves users in the EEA and you want to learn more and express interest in these experiences, you can start by filling out the interest form." The Türkiye page uses the same wording, pointing at the same form.
The mechanics are the same on both: the carousel "lets users easily see the top aggregator results for their query," with a More sites control that expands to additional aggregator sites, and a refinement chip that filters the whole results page down to aggregator text results. Two entry points into a filtered view where your competition is other directories rather than Booking.com. That is a rare framing to be handed.
A caution on the forms themselves. Both application pages link to Google support contact forms that we could not verify from outside a signed-in session — an automated request to either one returned nothing usable on 9 September 2026. Treat the form links as things you open from Google's documentation page while logged in, not as public URLs.
The ecosystem carousel asks for something you cannot ship
The ecosystem carousel covers EEA queries "related to weather, sports, finance, and translate." Its requirements include one that no amount of engineering satisfies: "Your website must be an authoritative source or a specialized provider in your respective domains (for example, major media outlets, or commercial weather services)."
Markup is irrelevant here too: "No new structured data markup or special feeds are required for this specific feature." There is a separate interest form, distinct from the one the job and places pages use. Ordering is described as determined by "Search ranking algorithms based on non-discriminatory ranking principles designed to ensure users see the most relevant results for their location and language."
For almost every directory this is a read-only entry in the table. Editorial standing is the requirement, and it takes years. It is here because its requirement text is the clearest statement in the whole section of what these features reward: standing in a vertical, not technical compliance.
Four doors, side by side
| Feature | Region | Query types | Markup needed | Feed or API | How you apply |
|---|---|---|---|---|---|
| Aggregator unit | EEA | Hotels, flights, long distance trains or buses, products | Not mentioned | Required — feeds or real-time APIs | VSS approval + interest form (travel) or CSS contact (products) |
| Supplier unit | EEA, only when the aggregator unit appears | Same four | Not mentioned | Optional — "can be enhanced with data feeds" | No form; direct providers only |
| Job sites | EEA | Jobs | "Don't need to add any markup" | Not mentioned | Interest form |
| Places sites | Türkiye | Local businesses, hotels | "Don't need to add any markup" | Not mentioned | Interest form |
| Ecosystem carousel | EEA | Weather, sports, finance, translate | "No new structured data markup ... required" | Not required | Separate interest form |
Read the markup column as a group and the pattern is hard to miss. Across the whole section, the thing SEO teams reach for first is either unnecessary or unmentioned. Region and vertical decide eligibility. Everything else is a supply question. Markup buys nothing here.
The one exception is the feature Google filed in the same section but built differently: the structured data carousel, which is earned with ItemList markup and is still beta and still geographically fenced to the same three regions. We covered its requirements and its regional query lists in the schema markup breakdown, and nothing on the new overview page changes them.
If your audience is in the United States, close this tab
Every feature above is fenced to the EEA, Türkiye or South Africa. There is no US, UK-outside-EEA, Canadian, Australian or APAC availability listed for any of them. Hreflang will not help. A European domain will not either. Availability is defined by where the person searching is, not where your company is registered.
For a directory serving those markets, the useful reading of this documentation is diagnostic rather than actionable. It tells you what Google is willing to reward when it is compelled to make room for aggregators — entity completeness, honest titles, fresh prices — which is a decent specification for a listing page regardless of which unit exists in your region. The work that pays in the US is still indexing coverage and page quality, and the failure mode there has a name and a fix path: Discovered — currently not indexed.
There is a second European thread worth knowing if you operate there. The site reputation policy rewrite from 28 August introduced a separate EEA enforcement track for third-party content on your domain. If you run listings or partner pages inside a larger site, the two documents interact.
The field list Google just published for free
The aggregator unit's best-practice section reads like a spec sheet for a listing record, and it applies whether or not you ever fill in a form. Quoted, condensed to what is checkable:
- Rich entity details — images, "detailed descriptions and specifications," and "verified user ratings and review counts."
- Specific categories — Google's own example is "'Boutique hotel' or 'Eco-resort' instead of just a generic 'Hotel'." Taxonomy depth, stated as a ranking-adjacent preference.
- Key amenities, features, and operating hours.
- Accurate titles — "Factual, descriptive titles formatted in title case," while "avoiding all caps, excessive punctuation, emoji, or promotional text (such as 'BEST DEALS' or 'Free shipping') in entity names."
- Imagery without decoration — "clean backgrounds without watermarks or promotional overlay badges."
- Pricing and availability that match the landing page, refreshed to drop expired entries.
Four of those six are decisions about your data model and your import rules, made long before any search feature is on the table. Two of them — titles and imagery — are moderation policy, which means they need a rule your team applies to listings submitted by business owners, not a preference in a style guide.
This is where our own honesty line falls. The DirectoryLaunch codebase gives you the listing schema, category taxonomy, image handling and city page generation that make the field list above achievable, and the local SEO docs cover how the programmatic pages are built. It does not generate a Lodging Point of Interest Feed, and it does not integrate the Transport features API. If your goal is the aggregator unit for hotel queries, the boilerplate saves you the catalogue and none of the pipeline — that part is a bespoke build against Google's travel specs, and anyone telling you a template covers it has not read the feed reference.
What to do tomorrow morning
- Check availability against your traffic, not your registration. Open your analytics and find the share of sessions from EEA countries, Türkiye and South Africa. Below a few per cent, stop here and spend the sprint on indexing coverage instead.
- Match your vertical to the table above. Jobs in the EEA and local business or hotels in Türkiye are the two doors that require no markup and no feed. Everything else needs either a data pipeline or a standing you cannot build.
- If a door fits, open Google's page and use the interest form from there, signed in. Do not chase form URLs found in blog posts, including this one.
- Run the audit prompt above against your listing schema regardless of the answer. The six best practices are the closest thing Google has published to a field-level specification for aggregator content, and they cost nothing to adopt.
- Write the two moderation rules. Title casing and image overlays are owner-submitted problems. Decide today whether your submission form rejects them or a human does, and put the rule where the reviewer can see it.
- Diary a recheck for December. Three of the four pages are new enough that availability lists and query types will move. The Documentation updates log is the only place that shows when.