Key Takeaway
Google's September 8, 2026 regional-search overview organized eligibility by market, query and business role, including EEA Aggregator and Supplier Units and structured-data carousels in the EEA, Turkey and South Africa. Check the specific supported query types before investing. Direct-provider pages, aggregator integrations and site-level list pages require different work; eligibility guarantees neither display, rankings, clicks nor AI citations.
Facts and background
The September 8 update added regional documentation and participation guidance. It did not establish that every listed feature launched that day or that Google's ranking system changed uniformly. This article preserves the scope reviewed on September 10; later expansions must be checked separately.
Select features according to the markets served and relevant query types. Aggregator Units serve qualifying multi-provider services; Supplier Units serve direct providers; structured-data carousels present lists from one site. One generic schema template cannot substitute for these different roles, data channels and page structures.
Decide by role, market and query
| Feature | Scope in the September 10 source review | Appropriate participant | Participation route | Important limitation |
|---|---|---|---|---|
| Aggregator Unit | EEA: hotels, flights, long-distance trains or buses, and products in the original review | Vertical search, comparison shopping, online travel, metasearch or directory services | Express interest, meet eligibility and quality requirements, and supply the required feed or real-time API | Not the default route for an ordinary brand site; one Aggregator Unit appears at a time |
| Supplier Unit | EEA: the original hotel, flight, long-distance train or bus, and product queries where an Aggregator Unit appears | Businesses directly supplying the relevant products or services | A crawlable site serving EEA users; supplier feeds may enhance results | Appears only alongside an Aggregator Unit; optional extra data does not remove page-governance requirements |
| Structured Data Carousel(beta) | EEA, Turkey and South Africa, with different query support; product queries were listed for the EEA and South Africa | Sites with list pages and separate detail pages for multiple entities | ItemList combined with supported types such as Product, LocalBusiness or Event | Described as beta; market, query, structure and content-policy restrictions apply |
Supplier Units are relevant to direct-selling brands serving EEA users. Google's guidance permits eligibility based on crawlable pages, with optional supplier-feed enhancements. That does not mean Google can infer missing product identities, prices, stock or purchase routes: the underlying pages still need accurate information.
Supplier Units appear only when an Aggregator Unit appears. Crawlability therefore does not create a reserved display position. Region, query type, result context and Google's selection still matter. Validate actual queries in target markets; a schema test is not proof of search display.
Product carousels require genuine list pages
The original review described structured-data carousels as beta, with product support in the EEA and South Africa. Turkey's listed scope covered hotels, vacation rentals and local businesses, not products. Use an actual summary or category page with ItemList and supported entity types, linking each item to its own detail page.
The cited guide requires at least three entities and markup for all visible list items. A collection with only in-page anchors and no separate detail pages does not meet that design. Provide the corresponding ItemList on each paginated page; for infinite scrolling, represent entities loaded initially. Detail pages need not add list markup solely for this beta feature, but every listed detail URL must be accessible and match the visible item.
| Page or data layer | Fields to reconcile before release | Common failure | Validation evidence |
|---|---|---|---|
| Market category page | Visible items, order, ItemList positions, detail URLs, images and names | Markup describes hidden products or items not initially loaded | Rendered-page inspection, JSON-LD parsing and item-by-item URL checks |
| Product detail page | Identity, variant, price, currency, availability, purchase action and market | IP-based redirects select the wrong language or product; discontinued pages redirect to a different item | HTTP, DOM and purchase-flow checks from target regions and stateless sessions |
| Product/Offer Schema | Visible price, currency, availability, brand, GTIN/MPN and variant identity | Markup conflicts with page or feed prices, stock or variants | Rich Results Test, fetched HTML and field-level reconciliation |
| Product feed | Language, currency, target country, URL, variant, price and availability | Feed and landing languages differ, or the intended variant is not preselected | Merchant Center diagnostics, target-URL checks and field snapshots |
Merchant Center landing-page rules provide a useful consistency baseline: language, currency, price, stock and variant must match product data; purchasable products need a working purchase action, and preorder or backorder availability needs appropriate dates. Initial-HTML price and availability markup can reduce reliance on dynamic rendering for fast-changing facts. Use these checks as engineering safeguards without implying that every Supplier Unit participant must use Merchant Center.
Maintain linked market, page and validation records
Record country, language, currency, sales eligibility, delivery coverage, provider role and supported query types together. Link each market to category and detail pages, canonicals, language versions, Product/Offer fields, feed records and owners. Do not apply EEA product eligibility to Turkey or reuse a page that cannot represent actual market-specific prices and stock.
Govern direct retail and multi-merchant platform operations separately. Owned product pages need direct-provider and data consistency checks; comparison platforms need the applicable VSS or CSS eligibility, application, feed/API and content-policy work. Two business models do not automatically give one domain, page or feed both qualifications.
Preserve regional context in measurement. Fix query groups, languages, devices, sign-in state and observation dates, then record ordinary results, Supplier Units, Aggregator Units and carousels separately with landing URLs and displayed fields. Overall Search Console performance alone may not identify a specific regional module. Test AI Mode and AI Overviews citations independently.
Regional release acceptance matrix
| Decision | Conditions | Action |
|---|---|---|
| Pass | Supported market and query, correct role, crawlable pages, consistent visible data and feeds, and compliant list structure | Release a small batch and record feature-level results in target markets |
| Conditional pass | Core pages exist, but delivery, sync, variant selection or initial rendering remains partly unverified | Release only verified markets and products; retain issues and retest |
| Fail | Unsupported market claimed, direct brand misclassified as aggregator, conflicting data or hidden/unavailable products in markup | Pause submissions or expansion and correct roles, pages and facts |
| Cannot establish attribution | Only total traffic changes, without market, query, feature or landing-URL evidence | Do not claim feature-driven growth; complete layered testing |
Impact on enterprises
The overview brings scattered participation requirements into a market-and-role framework. Direct sellers can evaluate crawlable pages and optional supplier feeds; comparison, travel and directory services need qualifying aggregator integrations; list-page owners need consistent ItemList and detail-page relationships. It also cautions against copying templates across markets. EEA product support does not imply equivalent Turkish support, and South African query coverage differs. Translation alone cannot reconcile sales regions, currencies, stock, delivery, variant URLs and feeds.
Zhihe Growth's Assessment
Zhihe Growth recommends treating regional eligibility as a repeatable engineering process: establish the participant role, market, query type, page structure and data channel, then keep each product's identity consistent across content, markup, feeds and checkout. Supplier Units and carousels are possible search surfaces, not AI-citation switches or ranking guarantees. Separate technical eligibility, data consistency, observed local display and business outcomes. Retain region, query, device, date, feature screenshot and URL; use a separate question set for AI mentions and citations. This article describes requirements reviewed as of September 10, 2026. It does not establish approval, guaranteed appearance, ranking gains, citation-rate increases or conversion improvements for any brand.
Recommended action
- Maintain a market register with country, language, currency, delivery, sales eligibility and query types.
- Identify the business role in each market: direct supplier, aggregator, comparison-shopping service or content provider.
- Verify each market and query against official guidance; do not extrapolate between the EEA, Turkey and South Africa.
- Direct providers should expose crawlable category and detail pages with clear product identity, price, stock, currency and purchase actions.
- Reconcile landing pages, Product/Offer JSON-LD, feeds and checkout field by field.
- Use ItemList on genuine eligible list pages with at least three entities, all visible items represented and separate detail-page links.
- Define pagination and infinite-scroll markup rules that reflect the current page or initially loaded content.
- Maintain separate page, feed/API, eligibility and ownership records for direct-retail and aggregator operations.
- Test fixed queries in actual target markets and retain language, device, date, feature, fields, URLs and screenshots.
- Report eligibility, actual display, Search Console performance, AI citations and conversions separately. Schema validation is not display or citation evidence.
Limitations
This article reflects Google Search Central and Merchant Center guidance reviewed as of September 10, 2026. September 8 marked a documentation overview, not a simultaneous launch of all features or a change to every ranking and AI-citation mechanism. Google's later September 18 local-business expansion is addressed separately. Supplier Units serve qualifying direct providers in the EEA and appear only with Aggregator Units. Crawlable pages can suffice, with optional feed enhancements. Carousel beta scope and requirements may evolve; eligibility does not guarantee crawling, indexing, display, position or clicks. Merchant Center rules are used here as a consistency baseline, not a requirement that all organic Supplier Unit participants open Merchant Center accounts. Market-specific tax, pricing, delivery, privacy, consumer-protection and comparison-shopping obligations require review by the appropriate business and compliance owners.