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, but that documentation update does not mean every feature launched everywhere that day.

This guide turns the official pages into one decision matrix. It covers the European Economic Area (EEA), Türkiye and South Africa, and separates what Google documents from what a publisher still needs to test.

What Google documented on September 8

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. Google says participants express interest, maintain relevant content, provide data through feeds or APIs when requested, and comply with applicable policies. Product titles, images, price and availability should remain current.

The supplier unit is for the direct provider—an airline, hotel or retailer, for example. 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.

Three 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.
• 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, 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.