Google Search Is Now More Regional in the EEA: What Businesses Should Change in SEO

Google Search no longer has one identical opportunity set everywhere. On September 8, 2026, Google published a new regional differences in Search experience guide that maps features available only in specific markets. In the European Economic Area (EEA), those features now include aggregator units, supplier units, ecosystem carousels, job-site features and structured-data carousels for selected query categories.

For businesses, the important lesson is not "add more schema". Different website types have different paths. A hotel that sells its own rooms, an online travel marketplace, a comparison-shopping service and a local-directory site should not use the same SEO playbook.

The practical framework is:

Where is the searcher?
        ↓
What type of business/site are you?
        ↓
Which regional Search feature applies?
        ↓
Crawling, feed/API, or structured data?
        ↓
Validate eligibility
        ↓
Measure regional Search performance

This guide explains what EEA businesses should change, what they should not change, and where technical SEO now intersects with product feeds and platform integrations.

What did Google change in September 2026?

Google added a dedicated documentation hub for regional differences in Search experience on September 8, 2026. Google says it is evolving the search results page for certain query types to provide opportunities for Vertical Search Services (VSS), Comparison Shopping Services (CSS), direct suppliers and content providers.

The documented EEA experiences include:

Source: Google Search Central regional differences documentation.

This is a useful change in documentation because "does Google support this Search feature?" is no longer enough. The better question is:

Does Google support this feature for my business model, query type and target region?

Is this a ranking algorithm update?

Not in the ordinary sense. Google is documenting Search-result experiences and participation/eligibility paths that vary by region.

That distinction matters.

If an EEA search results page contains a supplier unit, aggregator unit or host carousel, your organic opportunity may change even when the underlying page-ranking system has not been announced as a ranking update.

Think of Search visibility as two layers:

Layer 1: Can your page rank/index normally?
Layer 2: Is your site eligible for additional regional Search surfaces?

A technically healthy page can pass Layer 1 and still miss Layer 2 because the business has not supplied the required feed, is not an approved VSS, or has not implemented eligible structured data.

Why is the EEA Search experience different?

Google's current documentation focuses on how to participate rather than asking site owners to interpret the regulatory background. But the regionalisation is happening in a broader European regulatory environment.

On July 23, 2026, the European Commission announced decisions finding Google non-compliant with parts of the Digital Markets Act, including a finding relating to preferential treatment of Google's own services in areas such as shopping, hotels, transport and sports results. The Commission imposed a €460 million fine for the Search self-preferencing finding. See the European Commission announcement.

For SEO teams, the practical takeaway is simpler than the legal debate:

Search appearance in Europe can now differ materially from the experience your team sees in another country.

Do not approve an EEA SEO strategy by taking screenshots from the UK, US or another non-EEA market and assuming the same modules are available.

First classify your website: supplier, aggregator, or both?

This is the most important step.

Direct supplier

A direct supplier sells or provides the thing being searched for.

Examples:

• an individual hotel;
• an airline;
• a retailer selling its own or stocked products;
• a transport provider.

Google's supplier unit documentation says the feature is for direct providers and can appear alongside the aggregator unit for eligible EEA queries.

Aggregator

An aggregator helps users compare or discover offerings from multiple providers.

Google's aggregator unit documentation explicitly includes:

• Vertical Search Services;
• online travel agencies;
• Comparison Shopping Services;
• metasearch engines;
• directories.

Hybrid business

Some businesses operate both direct-supplier and marketplace models.

For example:

Travel company
├── sells its own tours
└── lists tours from external operators

or:

Retail group
├── sells inventory directly
└── runs a marketplace for third-party sellers

Do not force the whole domain into one mental category. Different sections or commercial models may have different eligibility and data requirements.

What is the Google aggregator unit?

The aggregator unit is a multi-provider Search feature for eligible aggregators serving EEA users.

Google says the unit may appear for:

• hotels;
• flights;
• long-distance trains or buses;
• products.

Inside the unit, one eligible aggregator's results are expanded by default, while users can select another available provider. Clicks lead to the aggregator's website.

For a hotel query, for example:

User searches "hotels in paris"
        ↓
Aggregator unit appears
        ↓
One aggregator is expanded
        ↓
Hotel results/prices/ratings are shown
        ↓
Click goes to aggregator website

This creates a different SEO opportunity from ranking a normal blue-link landing page.

How does an aggregator become eligible?

Google's current aggregator documentation lists several requirements.

An eligible business needs to:

1. Express interest through the applicable Google process.
2. Have content relevant to supported query categories.
3. Provide data in the required form.
4. Follow Google Search content policies.

The technical route depends on vertical.

Google currently points to:

• a lodging Point of Interest feed for hotel queries;
• a transport features API for ground transportation;
• a partner live API for flights;
• product-data participation routes for product queries.

This is a major architectural point:

For some EEA Search surfaces, classic on-page SEO is not enough. Your Search visibility can depend on a reliable product/data integration.

If your inventory, price or availability data is inaccurate or stale, adding another paragraph of SEO copy will not solve that problem.

What data quality matters for aggregator units?

Google's best-practice guidance is unusually concrete.

It recommends rich entity details such as:

• images;
• accurate descriptions/specifications;
• verified ratings and review counts;
• specific categories;
• amenities/features;
• operating hours.

It also tells participants to keep pricing and availability up to date and to ensure feed values match landing pages as closely as possible.

That turns part of SEO into a data-engineering problem.

A useful internal checklist becomes:

CMS / inventory system
        ↓
Is entity data complete?
        ↓
Is price/availability current?
        ↓
Does feed/API match landing page?
        ↓
Are images usable and high quality?
        ↓
Does Search receive updates quickly?

For ecommerce, travel and transport businesses, feed freshness belongs in the SEO reliability dashboard.

What is the supplier unit?

The supplier unit is Google's Search feature for direct providers.

According to Google's supplier unit guide, it can appear alongside the aggregator unit in the EEA for eligible hotel, flight, long-distance transport and product queries.

Crucially, Google says direct suppliers do not need to provide additional data beyond what Google can access by crawling in order to be eligible, although supplier feeds can enhance results where available.

That makes the supplier path different from the aggregator path.

A direct supplier should prioritise:

Crawlable website
+ clear entity/product pages
+ accurate visible data
+ strong technical SEO
+ optional/enhancing feeds

An aggregator may need:

Approval / participation
+ direct feed or API integration
+ strong data quality
+ Search-compliant content

Do not pay to build an aggregator feed if your business is actually a direct supplier and Google's documented supplier route applies.

Does every local business qualify for the supplier unit?

No. This is where reading the region/query matrix carefully matters.

Google describes direct providers broadly with examples such as individual hotels, airlines, brick-and-mortar businesses and service providers. However, the EEA supplier-unit availability currently documented on Search Central is tied to queries involving:

• hotels;
• flights;
• long-distance trains/buses;
• products.

Meanwhile, EEA structured-data carousels cover a broader set including local businesses and things to do.

So a plumber, restaurant or local service business should not conclude:

"Google has a supplier unit, therefore I need to register for it."

First map your query category to Google's actual feature table.

What are EEA structured-data carousels?

Google also documents a structured-data carousel that is currently in beta.

It is a horizontal list-like rich result that can show multiple entities from the same site. Google says each tile may include information such as:

• image;
• price;
• rating;
• entity details.

In the EEA, Google currently lists the carousel for queries related to:

• hotels;
• vacation rentals;
• ground transportation;
• flights;
• local businesses;
• things to do;
• products.

The implementation is based on __INLINE_CODE_0__ structured data combined with supported item types such as __INLINE_CODE_1__, __INLINE_CODE_2__ or __INLINE_CODE_3__. See Google's structured-data carousel documentation.

The carousel is built for list pages plus detail pages

This is where many rushed schema implementations will go wrong.

Google's current requirements say the site should have:

Summary/category page
        ↓
at least 3 entities
        ↓
each entity links to a distinct detail page
        ↓
ItemList markup describes those entities

The feature is not designed for a single all-in-one page where each "detail" is merely an anchor section.

Google also says:

• mark up all items visible on the summary/category page;
• URLs in the list must point to different pages on the same domain;
• include at least three items;
• each item needs core properties such as __INLINE_CODE_0__, __INLINE_CODE_1__ and __INLINE_CODE_2__;
• use the required/recommended properties for the actual entity type.

That means schema strategy should follow information architecture.

You should not create fake detail pages merely to satisfy markup. But if your site already has genuine category/list pages and useful entity detail pages, the carousel gives that architecture an additional EEA-specific opportunity.

Example architecture for a hotel directory

A good content model might look like:

/hotels/paris
├── /hotels/paris/hotel-a
├── /hotels/paris/hotel-b
├── /hotels/paris/hotel-c
└── /hotels/paris/hotel-d

The summary page can contain an __INLINE_CODE_0__ describing the hotels.

Each detail page should still exist because it is useful to the user, not because schema demands decorative URLs.

A poor implementation would be:

/hotels/paris
#hotel-a
#hotel-b
#hotel-c

with three anchor sections and no useful detail pages, because Google's current carousel guidelines say anchor links within the category page are not supported for this feature.

Does adding ItemList guarantee the carousel?

No.

Google's general structured data guidelines explicitly say correctly implemented structured data does not guarantee that a rich result will appear.

Structured data creates eligibility, not entitlement.

Search appearance can still depend on factors including:

• query;
• location;
• device;
• page quality;
• feature availability;
• Google's result-selection systems.

This is why the correct KPI is not:

Schema deployed = project complete

It is:

Schema valid
→ pages indexed
→ eligible region/query monitored
→ impressions/clicks observed
→ commercial effect measured

How should ecommerce sites react?

EEA ecommerce sites have multiple possible Search surfaces.

Depending on business model, you may need to review:

• product structured data;
• Merchant Center/product feeds;
• Comparison Shopping Service participation;
• aggregator-unit eligibility;
• supplier-unit eligibility;
• beta host carousels;
• canonical/indexing architecture.

The right priority order is:

1. Fix product truth

Make sure:

price
availability
currency
shipping/offer data
product identity

agree across the page, structured data and feeds.

2. Preserve crawlable product/category pages

Feeds complement the website. They do not excuse poor crawlability.

3. Validate structured data

Use Google's Rich Results Test and Search Console URL Inspection.

4. Decide whether you are a supplier or aggregator

A retailer and a comparison-shopping service have different participation paths.

5. Segment performance by market

Do not average EEA and non-EEA results into one dashboard and then wonder why SERP behaviour looks inconsistent.

How should hotels and travel businesses react?

Travel is one of the clearest verticals affected by regional Search experiences.

A direct hotel should focus on:

• crawlable room/property information;
• correct hotel identity;
• accurate pricing/availability where supplied;
• high-quality images;
• entity detail;
• technical SEO;
• appropriate structured data.

An OTA or travel marketplace needs to think beyond pages and schema:

• VSS participation;
• lodging feeds;
• inventory freshness;
• price consistency;
• review/attribute quality;
• feed monitoring.

A travel operator that is both a supplier and an aggregator should map each commercial flow separately.

For example:

Own hotel inventory
→ supplier path

Third-party hotel marketplace
→ aggregator path

The site may need one shared technical platform but two Search participation strategies.

How should local-business directories react?

Directories are explicitly included in Google's aggregator examples.

For an EEA directory, the opportunity may involve:

entity database
+ category/location landing pages
+ strong detail pages
+ direct data feed participation where applicable
+ structured-data carousel eligibility

The challenge is data quality.

A directory with:

• duplicate entities;
• stale opening hours;
• copied images;
• incorrect categories;
• thin location pages;

has a product/data problem before it has a schema problem.

Use structured data to describe a trustworthy entity graph, not to disguise a weak directory.

Why this matters for marketplace architecture

Marketplace SEO is increasingly coupled to product architecture.

Imagine an aggregator where price changes in the operational database but:

• landing page cache updates in 20 minutes;
• feed updates every six hours;
• structured data updates on the next deploy;
• API returns real-time inventory.

Google could receive several versions of "truth".

A better architecture is:

Canonical inventory source
        ↓
normalised entity/product model
        ├── website
        ├── structured data
        ├── Google feed
        └── real-time API

All channels derive from the same data model.

This reduces mismatches and makes SEO debugging much easier.

For complex marketplaces, Softotic's web application development service can support the data/application layer while SEO and growth optimisation covers crawlability, structured data and measurement.

Create a regional Search feature matrix

For international businesses, maintain an explicit matrix.

Example:

This stops teams from deploying "global SEO" changes for features that are only available in particular markets.

Test SERPs from the target region

A regional Search strategy needs regional observation.

Do not rely exclusively on:

• one employee's laptop;
• one corporate VPN exit;
• screenshots from US-based rank trackers;
• manually changing __INLINE_CODE_0__ and assuming that perfectly reproduces user context.

Use multiple signals:

1. Search Console performance data.
2. Reputable rank/SERP monitoring configured for target markets.
3. Manual checks from representative target locations when practical.
4. Analytics/landing-page trends.
5. Feed/API diagnostics where a regional unit depends on supplied data.

The goal is not to "scrape every SERP". It is to understand whether the Search surface your implementation targets actually appears for relevant users and queries.

Search Console should be read with geography in mind

When Search appearance differs by region, aggregate performance can hide useful changes.

Suppose:

EEA impressions rise
CTR changes
Non-EEA traffic stays flat

A global average may barely move.

Segment:

• country;
• query;
• page;
• device;
• date before/after implementation.

Then annotate rollout dates for:

• structured data;
• feed integration;
• major template changes;
• Google regional feature changes.

This turns a vague "SEO dropped" conversation into a diagnosable regional event.

Regional Search also affects manual-action interpretation

The regionalisation goes beyond new display modules.

On August 28, 2026, Google announced a change to its site reputation policy enforcement following discussions with the European Commission. Beginning August 30:

• outside the EEA, an applicable manual action can directly affect the affected site's Search results;
• inside the EEA, Google says that manual-action impact does not apply, although the affected section may be separated so it ranks independently over time.

Google still notifies site owners in Search Console. See Google's August 28 site reputation policy update.

This does not make reputation abuse safe or advisable in Europe.

It does prove a larger operational point:

A Search Console issue, ranking change or SERP feature may now have different user-facing consequences inside and outside the EEA.

International SEO incident response should always ask, "Which market is affected?"

What should not change?

Do not turn this documentation update into an excuse for SEO theatre.

You still need:

• crawlable pages;
• useful content;
• sensible internal linking;
• canonical consistency;
• performant rendering;
• truthful structured data;
• high-quality entity/product information;
• Search Essentials compliance.

Regional features are an additional opportunity layer.

They do not replace ordinary Search quality.

Do not build city-swapped pages for regional features

A new carousel is not a reason to manufacture hundreds of pages such as:

Best hotels in Paris
Best hotels in Lyon
Best hotels in Nice

if the only difference is the city name and a templated list.

Google's structured-data guidelines still require markup to represent the actual visible content, and normal Search quality/spam policies still apply.

Build a location or category page when it is useful because it has:

• genuinely relevant entities;
• useful filters/context;
• unique commercial or informational value;
• maintainable data;
• clear detail-page relationships.

Schema should expose useful structure, not justify thin pages.

A technical implementation checklist for host carousels

For an eligible EEA site:

Information architecture

• □We have a genuine category/summary page.
• □The page contains at least three relevant entities.
• □Each entity links to a unique detail page.
• □Detail URLs are crawlable and canonical.

Structured data

• □__INLINE_CODE_0__ is present on the summary page.
• □Each __INLINE_CODE_0__ has a valid position.
• □Each item uses the correct supported type.
• □Required __INLINE_CODE_0__, __INLINE_CODE_1__ and __INLINE_CODE_2__ data is present.
• □Type-specific required fields are correct.
• □Markup matches visible content.

Validation

• □Rich Results Test passes.
• □URL Inspection shows Google can crawl the page.
• □Pages are not blocked by __INLINE_CODE_0__, login or __INLINE_CODE_1__.
• □Sitemap includes relevant pages.
• □Search Console is monitored after rollout.

Quality

• □Images are representative and crawlable.
• □Prices/availability are current where applicable.
• □Ratings are genuine and correctly represented.
• □The page is useful even if Google never displays a carousel.

That last item is the anti-spam sanity check.

A technical checklist for aggregators

• □We have confirmed we are an aggregator/VSS rather than direct supplier.
• □Our query category is currently supported in the EEA.
• □We have completed the applicable Google interest/participation process.
• □Required feeds/APIs are identified.
• □Entity IDs are stable.
• □Price and availability data are refreshed at an appropriate cadence.
• □Feed/API values match landing-page values closely.
• □Images and entity metadata are complete.
• □Feed/API failures trigger monitoring.
• □Search Console and commercial landing-page performance are tracked.

A technical checklist for direct suppliers

• □We serve users in the EEA.
• □Our supported query category matches the supplier-unit documentation.
• □Key product/property/service pages are crawlable.
• □Entity information is clear and consistent.
• □Pricing/availability is accurate where published.
• □Relevant structured data is valid.
• □Optional supplier feeds are evaluated only where they add value.
• □We monitor Search performance in the actual target EEA markets.

Should UK businesses care?

Yes, if they sell to or operate in the EEA, but they should not assume the UK itself is part of the EEA experience.

The EEA consists of EU countries plus Iceland, Liechtenstein and Norway. The United Kingdom is not an EEA member.

A UK-based hotel marketplace, retailer, travel operator or SaaS platform can still care greatly if it serves customers searching from France, Germany, Spain, Italy, Ireland, the Netherlands or other EEA markets.

So segment by user market, not merely company registration country.

For a UK business:

UK organic strategy
≠ automatically identical to
France/Germany/Spain organic strategy

An international SEO dashboard should reflect that.

What should a small business actually do this month?

If you are not a marketplace, OTA, product aggregator or eligible list-based site, the answer may be: nothing special yet.

Do not implement a feature merely because it is new.

Use this triage:

Do we serve EEA searchers?
    no → monitor only
    yes
        ↓
Are our query categories listed?
    no → normal SEO continues
    yes
        ↓
Are we direct supplier, aggregator, or content provider?
        ↓
Follow only the relevant eligibility path

For an individual hotel or retailer, basic crawlability and data quality may matter more than a new integration.

For a large marketplace, the feed/API opportunity may justify immediate product and engineering work.

How to prioritise the work

Score each regional opportunity on four dimensions:

Then prioritise:

High demand + eligible + near-ready
→ implement now

High demand + eligible + poor data quality
→ fix data architecture first

Low demand + eligible
→ test selectively

Not eligible
→ do not manufacture a workaround

This is more useful than chasing every new Search feature.

Common mistakes

Mistake 1: treating all EEA features as schema features

Aggregator units can require feeds or real-time APIs. Supplier units can rely on normal crawling. Host carousels use structured data.

Different surface, different technical path.

Mistake 2: assuming "valid schema" means "will display"

Google says structured data creates eligibility, not a guarantee.

Mistake 3: viewing Search only from headquarters

The searcher region matters.

Mistake 4: confusing supplier and aggregator

A direct hotel and an OTA should not follow the same playbook.

Mistake 5: letting feed data disagree with landing pages

Google explicitly recommends keeping price and availability aligned as closely as possible.

Mistake 6: creating thin location/category pages only to unlock markup

The page should deserve to exist without the rich result.

Mistake 7: making SEO own the entire integration

Feed/API reliability may require product, backend, data and DevOps ownership.

SEO should define Search requirements, not become the only team responsible for an operational data pipeline.

A 30-day implementation plan

Week 1: market and feature audit

• identify EEA markets that generate revenue/impressions;
• map query categories;
• classify the site as supplier, aggregator or hybrid;
• identify applicable Search features;
• document current visibility.

Week 2: technical gap analysis

For structured-data candidates:

• inspect category/detail architecture;
• validate current schema;
• identify missing entity fields.

For aggregator candidates:

• assess feed/API requirements;
• identify canonical inventory source;
• review update frequency.

Week 3: pilot

Deploy to a limited set:

one vertical
one category/template
representative EEA markets

Validate crawlability, markup or feed correctness.

Week 4: monitor and decide

Review:

• indexing;
• Search Console;
• regional impressions/clicks;
• feed/API errors;
• landing-page engagement;
• commercial impact.

Scale only after the pipeline is reliable.

FAQs

What are Google's regional Search differences in the EEA?

Google now documents several Search experiences that are available specifically in the EEA for certain query categories, including aggregator units, supplier units, ecosystem carousels, job-site features and structured-data carousels. Availability depends on the feature and vertical.

What is the difference between an aggregator unit and a supplier unit?

An aggregator unit is designed for businesses such as OTAs, comparison-shopping services, metasearch engines and directories. A supplier unit is for direct providers such as individual hotels, airlines or eligible retailers/providers. Their participation and data requirements differ.

Do direct suppliers need a special Google feed?

Not necessarily. Google's current supplier-unit documentation says no additional data beyond what is accessible through web crawling is required for eligibility, although feeds can enhance supplier results where available.

What structured data is required for the EEA carousel?

Google's beta carousel uses __INLINE_CODE_0__ together with supported entity types such as __INLINE_CODE_1__, __INLINE_CODE_2__ or __INLINE_CODE_3__. The summary/category page must contain at least three entities that link to distinct detail pages, and required fields such as __INLINE_CODE_4__, __INLINE_CODE_5__ and __INLINE_CODE_6__ must be present.

Does correct schema guarantee a Google carousel?

No. Google explicitly says valid structured data does not guarantee that a rich result will appear. It makes the page eligible; Search systems decide what experience to show based on factors including query, location and device.

Does this apply to the United Kingdom?

The EEA-specific features apply to users in EEA countries. The UK is not an EEA member. However, a UK business serving customers in EEA markets should still evaluate these features for those markets.

Conclusion

The most important change is not a new schema property. It is a change in how international SEO teams should think.

Instead of:

One website
→ one global Google Search playbook

use:

Market
+ query vertical
+ business model
+ eligibility path
= Search opportunity

For EEA businesses and international companies serving EEA users, Search visibility can now involve three distinct technical disciplines:

1. traditional crawl/index SEO for direct pages;
2. structured data and information architecture for host carousels;
3. feeds and APIs for aggregator participation.

That makes SEO increasingly connected to the underlying software and data model.

Before adding markup or building a feed, identify which Google surface actually applies to your business. Then make the smallest technically correct change that creates eligibility, validate it, and measure the result by region.

If your site has the commercial opportunity but the technical foundation is fragmented, Softotic's SEO and growth optimisation service can map the regional Search requirements, while web application development can implement the structured-data, entity and feed/API layer. For a focused assessment, contact Softotic with your target EEA markets and site type.

Sources and references

• Google Search Central: Regional differences in Search experience
• Google Search Central: Aggregator unit in Google Search
• Google Search Central: Supplier unit in Google Search
• Google Search Central: Structured data carousels (beta)
• Google Search Central: General structured data guidelines
• Google Search Central: Update to the Site Reputation Policy, August 28, 2026
• European Commission: Google DMA non-compliance decisions, July 23, 2026