Google Documents Regional Search Features for the EEA, Türkiye and South Africa

Two Dates Define the Current Documentation

September 8 established the regional hub. Google said it added the documentation to help publishers, businesses and aggregators understand which regional Search features are available, who is eligible and how participation works.

On September 18, Google updated the aggregator and supplier documentation to support local business queries. The regional hub was also last updated on September 18. That later change matters because a September 8 snapshot no longer describes the full scope of those two EEA units.

As of September 27, 2026, the hub documents the following feature groups:

This is a feature map, not a universal country-by-country availability checker for everything in Google Search. The scope is limited to the experiences Google has grouped in this regional documentation.

Eligibility Follows the Business Role, Not One SEO Checklist

The easiest mistake is to see several Search features on one page and turn them into one implementation checklist. The requirements do not work that way.

EEA aggregators and direct suppliers take different routes

Google’s aggregator unit is a multi-provider feature for eligible Vertical Search Services (VSSs), including Online Travel Agencies, Comparison Shopping Services, metasearch engines and directories. Participation requires VSS approval, relevant content, the necessary data and compliance with Google’s Search content policies. The data route depends on the vertical: lodging and local business integrations use direct data feeds, while flight and long-distance transport experiences can use real-time APIs. Clicks within the unit lead directly to the selected aggregator’s website.

The supplier unit is for direct providers such as individual hotels or airlines, physical businesses and service providers. It appears alongside the aggregator unit and only appears when the aggregator unit appears. Google says a supplier does not need to provide additional data beyond information accessible through web crawling to be eligible, although supported feeds can enhance supplier results.

I would resolve that classification before assigning schema, feed or API work. An aggregator and a direct supplier can target a similar query, but the participation path is materially different.

Structured data is required for one regional experience, not all of them

Google’s beta structured data carousel does require markup. A summary or category page must use ItemList with at least one supported type such as LocalBusiness, Product or Event. Availability differs by region, and correct markup creates eligibility rather than a guarantee that the carousel will appear.

The supported carousel categories are not identical across markets. The EEA documentation covers hotels, local businesses, things to do, products, ground transportation, flights and vacation rentals. Türkiye covers hotels, local businesses and vacation rentals. South Africa covers hotels, things to do, flights, products, food delivery, car hire, vacation rentals and ground transportation.

Other features follow different rules. The EEA ecosystem carousel is available for weather, sports, finance and translation-related queries. Google requires an eligible site to serve EEA users and to be an authoritative source or specialist provider in the relevant area, but it does not require new structured data or a special feed for this feature. Google’s Job sites feature in the EEA and Places sites feature in Türkiye do not require publishers to add markup for their aggregator carousels or refinement chips. In South Africa, Google says the badge does not change ranking and eligible platforms do not need markup simply to appear through the refinement chip.

Where This Fits in an International SEO Strategy

The regional hub answers a narrower question than international SEO as a whole. MOCOBIN’s International SEO guide covers the durable work of matching language and regional content to the right audience through site structure, localisation and targeting signals. This news analysis covers a current Search appearance layer that sits on top of those foundations.

A site can have sound regional architecture and still be ineligible for a specialised feature because its market, query category or business role does not qualify. The reverse is also true: eligibility for a regional feature does not fix weak international site architecture.

That separation is important for the Pillar and Supporting Content relationship. The BASIC page should remain the evergreen destination for international SEO planning. This NEWS_ANALYSIS page should answer what Google documented in September 2026, which businesses may be affected and which implementation route, if any, deserves review.

Four Questions to Answer Before Development Work

1. Which market is relevant? Confirm whether the business and intended users match the geography described in the feature documentation.
2. Which query category applies? Hotels, jobs, weather, products and local businesses do not share one participation model simply because they appear in the same hub.
3. What role does the site play? Classify it as an aggregator, direct supplier, specialist content provider or another publisher type before selecting an implementation route.
4. What does the feature-specific page require? Check whether participation needs approval, an interest form, a feed, an API, structured data or no additional technical implementation.

Only after those checks should a team allocate development time. Copying an EEA implementation into Türkiye or South Africa can solve the wrong problem, and adding markup cannot create eligibility for a feature whose participation criteria the site does not meet.

What the September Documentation Does Not Prove

The regional documentation gives SEO teams a better map of specialised Search experiences, but it does not support several broader conclusions:

• It does not establish September 8 as the launch date of every listed feature. That is the date Google recorded the new regional documentation hub.
• It does not show that structured data is required across the hub. Requirements differ by feature.
• It does not provide a general traffic or CTR forecast. Eligibility and visibility do not establish a predictable traffic outcome.
• It is not the September 2026 ranking update. Google’s Search Status Dashboard shows a separate spam update that began on September 24. That ranking update is distinct from the September 8 documentation addition and September 18 regional feature update.
• It does not replace international SEO fundamentals. Language targeting, localisation, regional URLs and site architecture remain separate decisions.

That distinction matters when analytics move. A traffic change after September 8 is something to investigate, not evidence that the regional documentation caused it. Changes after September 24 also need to be assessed against Google’s separate spam update and other site-specific factors rather than attributed automatically to these regional Search features.

What Affected Teams Should Monitor Next

The first check is the regional hub itself because feature scope, eligibility rules and beta requirements can change. For businesses that match one of the documented markets and query categories, monitor the relevant feature-specific page before changing feeds, markup or integrations.

Then compare Search Console and analytics data only when an actual Search appearance changes in the market you serve. The useful signal is not that Google has another feature. It is whether that feature changes the route through which your specific business can appear for a specific class of queries. If it does not, the implementation can wait.