Cross-reference a 2024 Search Central post with a 2026 developer-doc update while trying to establish whether a carousel applies in the EEA, Türkiye, both, or neither, and the problem becomes obvious. Regional Search eligibility has required detective work. On September 8, 2026, Google published one hub for Search experience differences across the European Economic Area, Türkiye, and South Africa, ending two-plus years of changelog archaeology.
The page lays out each feature, its participation route, and the implementation order that matters for multi-market teams. The practical aim is simpler: do not run a Türkiye checklist against an EEA market, or miss an eligible South African listing feature.
What the Hub Actually Is (and Why It Took This Long)
Google's Regional Search Features Hub is a maintained reference for region-specific SERP features, their eligibility rules, participation path, and status. It is an index, not a launch post. Treat it as a monitored document, because it will change.
Previously, teams had to combine Google's regional differences in Search documentation, developer changelogs, and community threads. That Google needed so long to centralize this information says something about the internal separation of its regional rollouts.
A Map of Google Regional Search Features: What's Listed and Where
The hub names three regions: the EEA, Türkiye, and South Africa. Their feature sets differ substantially. It documents features with formal eligibility or participation routes, not every regional SERP variation worldwide. No listing means no documented route to participate.
EEA: Digital Markets Act Search Features and the Aggregator/Supplier Split
The EEA's DMA search features are the hub's most complex entries because they stem from regulation rather than product choice. EEA's redesigned search results created an aggregator unit for comparison and booking platforms, plus a supplier unit for direct providers. They are separate programs, with different criteria, feeds, and approvals.
EEA refinement chips let users filter by category or attribute. For travel and ecommerce sites, the way Google categorizes content affects the unit where a listing appears and the route users take to reach it.
South Africa and Türkiye: Smaller Footprint, Specific Opportunities
South Africa's badge feature is a trust and verification marker for eligible business listings, covering travel, shopping, food delivery, and more. It does not directly change rankings, but it changes the listing's visual prominence. International teams have paid relatively little attention to it.
Türkiye's Places sites carousel serves location-based results and is listed only for Türkiye. Google's current regional Search documentation lists Places sites features for Türkiye, not the EEA. That gap has led teams to spend implementation cycles on Türkiye-specific requirements for EEA markets where the feature is absent.
How Participation Works: Three Very Different Paths
The costly mistake is treating every regional feature as the same kind of opt-in. Google uses three participation models; confusing them sends teams toward the wrong build.
Path 1: Structured Data Carousels Beta. This beta uses ItemList structured data. Google's official carousels documentation says ItemList groups entities such as LocalBusiness, Product, or Event into a list eligible for carousel rendering. It is available in the EEA, Türkiye, and South Africa. Correct markup is necessary but not sufficient: pages must meet quality thresholds and the feature must be active in the user's region. Validate structured data for SEO, AEO, and LLMs before submission.
Path 2: Feed Submission and Approval. EEA aggregator units can require structured data feeds depending on the vertical. Supplier units do not require additional data beyond what Google can access through web crawling, although feeds can enhance supplier results.
Path 3: The Google Search Interest Form. The South African badge and some EEA units require a Google Search interest form to start eligibility review. Submission does not ensure inclusion. Record the date and follow up in Search Console if Google's stated response window passes.
Feature-by-Feature Regional SERP Eligibility Breakdown
Use this matrix as the regional eligibility reference that teams previously assembled from scattered documentation.
| Feature | Region(s) | Participation Path | Structured Data Required | Status | Key Gotcha |
|---|---|---|---|---|---|
| EEA Aggregator Unit | EEA | Feed + approval | Yes (feed-based) | Live | Markup alone is insufficient; the feed must pass review |
| EEA Supplier Unit | EEA | Web crawling; optional feed enhancements | No | Live | Additional feeds can enhance results but are not required for basic eligibility |
| Refinement Chips | EEA | Automatic (no opt-in) | No | Live | Google assigns chips; content categorization matters |
| Structured Data Carousels Beta | EEA, Türkiye, South Africa | Markup (ItemList) | Yes (ItemList schema) | Beta | Rules can change before the beta ends |
| South African Badge | South Africa | Interest form | No | Live | It does not affect rankings; form required |
| Türkiye Places Sites | Türkiye | Interest form / Google eligibility | No | Live | Available for hotel and local-business queries |
| Regional SERP feature eligibility matrix based on Google's September 2026 hub documentation. |
What Most Teams Get Wrong About Regional SERP Feature Eligibility
The common multi-market account failures:
- Applying EEA requirements outside the EEA, or the reverse. Türkiye's Places sites carousel and EEA units are separate systems.
- Assuming markup is enough when the feature also requires a feed or form. This wastes the most time.
- Reading the hub once instead of monitoring it. Beta rules can move without a major announcement.
- Treating the missing EEA Places sites carousel documentation as permission to proceed. Until clarified, regard it as Türkiye-only.
Warning: The hub does not say whether an EEA Places sites carousel was retired. Google should close that documentation gap. Until it does, do not build EEA implementations from Türkiye-specific guidance.
Prioritisation Framework for Multi-Market SEO Teams
Step 1: Audit Your Markets Against the Hub
Map each client domain to its served regions, then compare that map with the hub. Flag features already built for the wrong market and eligible features not yet pursued. Google's official AI search guide also helps frame which work affects traditional and AI-driven discovery.
Step 2: Validate Markup Before You Submit Anything
Validate ItemList and entity markup before filing feeds or forms. Errors delay approval. Typical ItemList problems include missing properties, bad nesting, and entity types outside a feature's accepted schema.
Step 3: Monitor, Don't Set and Forget
Beta criteria move. Carousel eligibility has changed since the beta launched and may change again. Keep monitoring it through Search Central alerts and hub-page change detection; a diff tool or Vizup's Answer Engine Monitoring is suited to the job. Add a quarterly status review to reporting. Track Google Search profiles for publishers as well for a broader view of changing discovery surfaces.
Vizup extends that monitoring into a broader Organic Autopilot for modern discovery. It helps brands monitor, create, optimize, publish, and learn across Search, Social, Communities, AI Answer Engines, and Local Discovery using AI agents, human experts, and live SEO, pSEO, AEO, and GEO tools. Paid ads can then be used as an optional amplification layer rather than the foundation of the strategy.
Edge Cases the Hub Doesn't Spell Out
For a site serving EEA and non-EEA users, does eligibility follow user location or domain registration? Google's documentation points to user location, but the hub does not say so directly. Sites in both Türkiye and the EEA should also treat Places sites carousels and EEA units as separate systems, not shared-feed infrastructure.
EEA aggregator inclusion does not remove other DMA obligations. The carousel beta remains a beta, so its scope or availability may change before release. Resource accordingly; it is not a guaranteed long-term investment.
FAQ: Google Regional Search Features
Does ItemList structured data guarantee carousel beta visibility?
No. ItemList markup is a prerequisite, not a guarantee. Google also assesses page quality, relevance, and whether the feature is active for the user's region. Beta criteria can change without notice.
For sites serving EEA and non-EEA users, must EEA units cover all traffic?
EEA-specific Search experiences are shown to eligible users in the EEA. Participation requirements vary by feature, so follow the hub's requirements for the relevant aggregator, supplier, carousel, or other experience.
Is Türkiye's Places sites carousel the same as an EEA carousel?
No. The hub lists the Türkiye Places sites carousel only for Türkiye. Google has not confirmed an EEA equivalent or retirement. Do not apply Türkiye implementation guidance in EEA markets.
How do I choose between an interest form, data feed, and markup?
Check the hub's participation route for the feature. The South African badge uses an interest form; EEA aggregator and supplier units need a feed and approval; the carousel beta uses ItemList markup.
Is structured data wasted outside the EEA, Türkiye, and South Africa?
Structured data such as Product and LocalBusiness can still help search engines understand page entities and can support eligible Search experiences outside these regional features
