Direct answer: Google's new regional Search documentation is an eligibility map, not a worldwide ranking update. Before changing a site, identify where users search, whether the business is an aggregator or direct supplier, and which supported query category applies. Some features require approval plus feeds or APIs; some use crawlable website data; structured-data carousels require valid markup for supported content types.
This guide explains participation in the documented regional experiences. It does not claim that these features are available in the Philippines, that markup guarantees display, or that an ordinary service business should apply to an aggregator program.
Start with four fields: user region, business role, query type, and required data path. If one does not match Google's documentation, stop before implementation.
What changed in Google's documentation
On September 8, 2026, Google Search Central added a regional Search experience directory. Google says it was created to help publishers, businesses, and aggregators understand which features are available in specific countries, the eligibility criteria, and how to participate.
The directory brings together features that previously lived across separate announcements and technical pages. The search-result experiences themselves are not all new. The useful change is a clearer, filterable source of truth for region and query eligibility.
Regional Search feature matrix
| Feature | Region | Queries | Participant | Application or approval | New markup required? | Data path |
|---|---|---|---|---|---|---|
| Aggregator unit | EEA | Hotels, flights, ground transportation, products | Approved Vertical Search Service or comparison provider | Yes | No generic schema fix | Feed, API, or program integration |
| Supplier unit | EEA | Hotels, flights, ground transportation, products | Direct supplier in an eligible vertical | Depends on the vertical | No special markup stated | Crawled site data plus optional feeds |
| Ecosystem carousel | EEA | Weather, sports, finance, translate | Authoritative or specialized provider | Interest form | No | Existing site data |
| Job sites features | EEA | Jobs | Job aggregator | Express interest | No | Organic eligibility and existing site data |
| Places sites features | Türkiye | Hotels and local businesses | Aggregator or directory site | Express interest | No | Organic eligibility and existing site data |
| South Africa badge and refinement chip | South Africa | Travel, products, car hire, food delivery, bus booking | Eligible South African platform | Interest form | No for the badge or chip | Eligible organic result or advertisement |
| Regional structured-data carousel beta | EEA, South Africa, Türkiye | Varies by region | Site listing multiple eligible entities | Varies by region and vertical | Yes | ItemList plus a supported item type |
Eligibility may depend on the searcher's region, the market the site serves, or the company's location, depending on the feature. EEA programs often focus on serving EEA users, while South African features require the business to be based in South Africa. A Philippine company serving EEA travellers may therefore have a relevant EEA case, while a local Philippine business serving only domestic users should not treat those units as current local features.
Aggregator unit versus supplier unit
The aggregator unit is a multi-provider feature for approved Vertical Search Services such as online travel agencies, comparison shopping services, metasearch engines, and directories. Eligible aggregators populate their own unit with results relevant to the query. Google documents direct feeds or real-time APIs for the relevant verticals, alongside quality and content requirements.
The supplier unit gives visibility to direct suppliers in eligible EEA verticals, such as hotels, airlines, transport providers, or merchants. It appears only when the aggregator unit appears. Google says direct suppliers do not need to submit extra data beyond what is available through crawling, although feeds can enhance some supplier results.
Do not choose the more impressive label. A hotel directory and an individual hotel have different roles. Misclassifying a direct provider as an aggregator creates the wrong technical project and the wrong expectations.
Structured-data carousels are a separate path
The host carousel is a list-like rich result that lets users scroll through entities from one site. Unlike an aggregator unit, this path depends on structured data placed on the site's own summary and detail pages. Supported types and regions vary.
Google's carousel documentation supports eligible categories such as LocalBusiness and subtypes, Product, Event, and certain travel entities in documented markets. Each item should represent visible page content and link to a valid detail page on the same domain. The markup does not create eligibility where the region or content type is unsupported.
Regional carousel eligibility ≠ ordinary Google carousel structured data. Do not confuse the regional beta carousel with Google's standard ItemList carousel documentation. They have different supported content types and eligibility rules.
Use the same discipline described in the structured data implementation guide: match markup to visible facts, validate syntax, and do not promise a rich result.
A five-step eligibility workflow
- Identify the governing geography. Check whether the feature depends on the searcher's region, the market served, or the company's location.
- Choose the business role. Record whether the site is a direct supplier, aggregator, comparison service, directory, or content provider.
- Match a supported query type. Hotels, products, jobs, finance, or local businesses are not interchangeable programs.
- Open the feature-specific documentation. Record whether the path needs crawling, structured data, a feed, an API, an interest form, or formal approval.
- Define acceptance evidence. Validate the feed or markup, confirm indexable landing pages, and monitor Search Console without claiming guaranteed display.
What to implement by role
| Your site | Likely first action | Do not do |
|---|---|---|
| Direct supplier in an eligible EEA vertical, such as a hotel, airline, transport provider, or merchant | Make entity, availability, price, and landing-page information accurate and crawlable; then review supplier feed options | Apply as a general aggregator without operating a comparison service |
| OTA, metasearch engine, comparison provider, or directory | Use the correct interest or program form and prepare the required feed/API integration | Assume ordinary organic crawling alone populates an aggregator unit |
| Site listing multiple eligible entities in a supported region | Evaluate the regional carousel beta and implement only the documented structured-data type | Add unsupported schema to every listing page |
| Publisher outside the listed regions and verticals | Keep standard technical SEO and monitor the directory for changes | Rewrite templates for a feature users cannot currently receive |
Measurement and limits
Google says it shows Search features based on what is most helpful for the query. Eligibility, valid data, and approval do not guarantee an appearance. Search Console can show overall Search performance, but documentation does not promise a dedicated performance filter for every unit listed in the regional directory.
Create a dated launch record with the eligible region, feature, accepted feed or validation result, indexable landing pages, and the queries you intend to observe. Compare impressions, clicks, landing pages, and business outcomes. Do not label an ordinary ranking change as proof that a regional unit appeared.
Mistakes to avoid
- Calling the September documentation update a new global algorithm.
- Confusing the aggregator unit with the supplier unit.
- Assuming every feature uses the same geographic eligibility test.
- Adding carousel markup for an unsupported type or market.
- Submitting stale prices, availability, ratings, or entity details.
- Expecting structured data to replace approval, a feed, or an API.
- Promising a rich result after a validator passes.
Sources checked
Regions, query types, and participation requirements were checked against Google Search Central on September 14, 2026. These feature lists can change; recheck the directory before implementation.
- Google Search documentation updates
- Google: Regional differences in Search experience
- Google: Aggregator unit in Search
- Google: Supplier unit in Search
- Google: Ecosystem carousel
- Google: Job sites features
- Google: Places sites features
- Google: South Africa badge and refinement chip
- Google: Regional structured-data carousels beta
- Google: Standard carousel structured data
Need to check whether a regional Search feature fits your site?
FloxoLab can map the eligible region, site role, data source, markup, and validation path before development starts.
Explore the SEO audit