Google Search Regional Features: Eligibility by Country, Query and Provider

Google’s regional search features are not one program with one eligibility rule. A site has to match the documented region, query family and provider type; the implementation can then require an interest form, a feed or API, ordinary crawlable content, or structured data. Google added a central documentation hub on September 8, 2026, then expanded the EEA aggregator and supplier documentation to local-business queries on September 18.

This guide turns the official pages into one decision matrix. It covers the European Economic Area (EEA), Türkiye and South Africa, and separates an eligible query from the aggregator or direct supplier that can participate. That distinction matters for local searches because the business named in a query is not automatically the same entity as the comparison service or supplier unit shown around it.

What Google documented on September 8 and 18

Google’s Search documentation updates log says it added documentation about regional differences in Search features, including eligibility and participation. The new regional features overview points to seven feature families:

• aggregator units and supplier units in the EEA;
• ecosystem carousels and job-site features in the EEA;
• places-site features in Türkiye;
• badges and refinement chips for eligible South African sites; and
• host carousels supported through structured data in the EEA, Türkiye and South Africa.

The practical change for publishers is clarity. You can now inspect a documented route instead of treating “regional Search features” as a vague rich-result opportunity.

The 30-second eligibility answer

A technically perfect implementation outside the documented region or provider class is not evidence of eligibility. Conversely, several features explicitly say no new markup is required.

Regional search-feature decision matrix

Download the full regional-feature decision matrix (CSV). It includes each regional query family, provider type, markup/feed requirement, participation path, measurement suggestion, caveat, source URL and verification date. No email address is required.

Choose the route that matches your business

Aggregator or direct supplier in the EEA

The aggregator unit is for providers such as comparison services, online travel agencies, metasearch sites and vertical directories. Its documented EEA query families now include hotels, flights, long-distance trains or buses, products and local businesses. Google says participants express interest, maintain relevant content, provide requested data through feeds or APIs, and comply with applicable policies.

The supplier unit is for the direct provider, such as an airline, hotel, retailer, brick-and-mortar business or local service provider. Google says no additional data is required beyond crawlable content, although feeds can enhance what is shown. It is not independent: the supplier unit appears only when an aggregator unit is present.

Specialized sites, jobs and places

The EEA ecosystem carousel covers weather, sports, finance and translation providers. The EEA job-sites feature can show a carousel or refinement chip. Türkiye’s places-sites feature covers hotels and local businesses. Each documentation page provides an interest route and says no new markup is required.

That does not make the normal Search requirements disappear. Pages still need to be accessible, useful and eligible for indexing. Participation is not a substitute for clear entity information, accurate inventory, helpful landing pages or ordinary ranking systems.

South Africa’s badge and refinement chip

Google’s South Africa features page describes a badge for eligible sites and a refinement chip for certain travel, product, car-hire, food-delivery and ground-transport searches. The badge can appear with web results and ads, but Google explicitly says it does not affect ranking. Treat it as an identification feature, not a ranking lever.

Where markup is and is not required

The host carousel is the clear structured-data route. Google’s beta carousel documentation requires a summary page with an ItemList and supported LocalBusiness, Product or Event items. The summary page must link to at least three detail pages on the same domain. Detail pages do not need to repeat the list markup.

All list items need to be represented on the page. Google documents pagination and says an infinite-scroll implementation should expose the items loaded in the initial viewport. Because this is beta documentation, validate the markup and watch the supported regions and verticals for changes; valid markup does not guarantee a carousel.

By contrast, the supplier, ecosystem, job-sites, places-sites and South Africa refinement-chip pages do not ask for a new schema type. The aggregator path is data-led through feeds or APIs. Adding unrelated markup “just in case” creates maintenance risk without satisfying a documented requirement. Our structured-data library applies the same evidence-first principle to other implementations.

Four worked eligibility scenarios

These scenarios are illustrations, not reported results.

• An EEA hotel-comparison service: aggregator unit is the relevant first route. The team should confirm eligible hotel queries, maintain price and availability data, and prepare for a feed/API discussion. Supplier-unit requirements do not fit unless the company sells its own hotel inventory directly.
• An EEA home-services marketplace: local-business support makes the aggregator route relevant when the marketplace compares eligible service providers and can supply accurate point-of-interest data. Each listed plumber or salon is not the aggregator. A provider that sells the service directly belongs on the supplier side and can be considered only when the aggregator unit appears.
• A Türkiye local-business directory: the places-sites interest route may fit. Adding an EEA-only job or ecosystem implementation would not. A host carousel may be a separate option only if the page and vertical meet the Türkiye beta documentation.
• A South African product marketplace: the badge/chip documentation and the product host-carousel documentation are different routes. The former does not require special markup and does not change ranking; the latter requires supported structured data.

Measure eligibility and appearance without guessing

Build a small observation ledger before implementation. Record the query, country, language, device, account state, date, feature seen, provider shown and destination URL. Then repeat the same query set after the technical or participation change. Separate three questions:

• Eligibility: does the documented region, query and provider type match?
• Appearance: did the feature show for the controlled observation?
• Outcome: did the feature send useful visits or conversions to the intended landing page?

Do not assume Search Console will expose a dedicated appearance filter for every feature. Preserve screenshots and landing-page evidence, but avoid turning a single personalized result into a general visibility claim.

What the documentation does not prove

• It does not guarantee that an eligible or interested provider will be shown.
• It does not make a South Africa badge a ranking factor.
• It does not make every regional feature available in every country or query family.
• It does not show that September 8 was the launch date of every listed feature; it is the date Google added the documentation hub and linked guidance.
• It does not turn beta structured-data support into a display promise.

Sources and methodology

SearchEngineAnswer checked Google’s documentation updates log, regional overview and each linked feature page on September 8, then rechecked the aggregator and supplier pages after Google added local-business query support on September 18, 2026. The CSV records the documented region, query family, provider type, technical requirement and caveat for every row. We did not submit participation forms, receive Google eligibility decisions or measure live appearance rates. Product behavior and documentation can change, so use the source links in the matrix before implementation.

Practical next step: filter the CSV to your region and provider type. If no row matches, do not force a markup project. If one does, capture a pre-change observation set and follow that feature’s official participation or implementation path.