Does Google’s EEA Local Search Change Affect Your Site?

Short answer: Google’s September 18, 2026 documentation update matters to a U.S.-managed site only if it genuinely serves users in the European Economic Area (EEA) and fits Google’s documented supplier or aggregator model. It does not establish a nationwide U.S. local-search rollout, a change to ordinary local rankings, or a replacement for Google Business Profile, Google Maps, organic results, or local-pack visibility.

This guide is for a U.S.-based agency SEO or technical lead deciding whether a client should investigate the change. The practical decision is usually one of three options: follow the supplier path as a direct local provider, follow the aggregator path as a directory or other Vertical Search Service (VSS), or take no feature-specific action because the site is not currently in scope.

What changed on September 18, 2026?

Google’s Documentation Updates page records a September 18 update adding local-business query support to the aggregator and supplier units. Google’s regional Search documentation describes these units for users in the EEA and lists local businesses among the supported query types.

That is a documented feature clarification or expansion, not evidence of a general algorithm update. The update does not, by itself, show that Google changed U.S. local results, standard indexing, Google Business Profile behavior, local-pack eligibility, or ranking systems.

Google also does not promise that every eligible business, query, or page will display in one of these units. Treat the change as a qualification and implementation question—not as a new ranking opportunity with a guaranteed outcome.

Use this three-way decision aid

Classification	EEA audience	Organization role	Relevant next step
Direct local provider	Genuinely serves EEA users	Provides the local service directly, such as a plumbing company or other local provider	Review the supplier path and make accurate business information accessible through crawling
Aggregator or VSS	Relevant to EEA queries	Lists or compares multiple providers, such as a directory, metasearch service, online travel agency, or comparison service	Review eligibility, express interest where appropriate, prepare required data, and use the applicable Local Point of Interest Feed
Not currently in scope	No clear EEA service or user audience	Serves U.S. users only, or does not operate as a direct provider or qualifying VSS	Continue normal technical and local SEO work; do not build a feature-specific feed solely because of this update

Use all four criteria together:

Audience: Does the website genuinely serve EEA users?
Role: Is the organization the direct provider, or does it aggregate multiple providers?
Query relevance: Would the service or directory content answer a supported local-business query?
Data capability: Can the organization keep its website information, entity records, and—where relevant—feed data accurate and aligned?

An EEA-language page, euro pricing, international shipping, or a general statement that a company “serves Europe” is not enough to establish eligibility. Document the actual service area, booking process, delivery model, locations, or other evidence that explains how EEA users can use the service.

The supplier path for direct providers

Google describes the supplier unit as a feature for direct providers, including brick-and-mortar businesses and service providers such as plumbers. The supplier unit appears alongside the aggregator unit, so it is not a standalone replacement for ordinary local search.

For a direct supplier, Google says the website does not need to provide additional data beyond information accessible through web crawling. A feed may enhance supplier data when available, but the supplier documentation does not describe a feed as the required gateway for a direct provider.

Review this baseline:

Document the genuine EEA audience and service availability.
Make representative local or service-area pages accessible to crawlers.
Publish accurate business details, service information, operating hours, and contact or booking paths where applicable.
Check that the content is available without a login and is not blocked by robots.txt or a noindex directive.
Use structured data where it accurately describes the page and business, then validate it as an implementation check.

Do not treat LocalBusiness structured data as a mandatory eligibility gateway. Google’s Local Business structured-data guidance supports validation and crawlability checks, but the cited feature documentation does not state that this markup is required for supplier or aggregator-unit eligibility.

The aggregator path for directories and comparison services

Google defines the aggregator unit as a multi-provider feature for Vertical Search Services. Examples in Google’s documentation include directories, metasearch engines, online travel agencies, and comparison-shopping services.

For local-business aggregator queries, Google directs eligible participants to the Local Point of Interest Feed documentation and states that these units are populated by direct data-feed integrations. This feed requirement concerns aggregator participation; it is not a new requirement for ordinary local SEO indexing.

Google’s documented aggregator eligibility process includes:

Expressing interest in participation.
Having relevant content for the supported query type.
Providing the required data.
Complying with Google Search content policies and quality requirements.

Expressing interest is not approval, and supplying a feed is not a promise that a unit will appear for a particular query. Google’s public documentation does not provide approval thresholds, query-volume requirements, display-frequency commitments, or a guaranteed timeline after interest is submitted.

For aggregator records, Google recommends comprehensive entity details such as images, descriptions, ratings where applicable, categories, amenities or features, and operating hours. Treat these as data-quality and usefulness recommendations, not ranking guarantees.

Website versus feed: what should you trust?

The answer depends on the organization’s role. A direct supplier starts with crawlable website information. An aggregator must plan for the applicable feed and should still maintain consistent, useful landing pages.

Check	Website content	Feed data	Implementation risk
Ownership	Usually controlled by the provider or site content team	Controlled by the directory, platform, data team, or integration owner	Different teams can update the same entity independently
Update frequency	Changes when pages, templates, or CMS records are published	Changes according to the feed generation and delivery schedule	One source can remain stale after the other changes
Entity matching	Uses names, addresses, phone numbers, URLs, and page relationships	Uses the feed’s identifiers and required entity fields	Duplicate, missing, or inconsistent identifiers can make matching harder
Landing-page consistency	Shows the information a user sees after clicking	Supplies structured records to the integration	A feed record that disagrees with the landing page creates an avoidable mismatch
Failure mode	Blocked crawling, rendering problems, noindex, or stale content	Schema errors, failed delivery, stale records, or invalid values	There may be no single source that automatically resolves the conflict

As a practical control, compare important feed fields with the corresponding landing page: business name, address or service area, phone number, URL, category, hours, and availability claims. If the values differ, treat that as an implementation risk. Do not assume Google will resolve the mismatch in the preferred direction.

A diagnostic sequence for agency teams

1. Prove the EEA service connection

Record the evidence that the site serves EEA users. Depending on the business, that might include published locations, service-area rules, booking or delivery terms, support coverage, or a documented process for accepting EEA customers.

Do not use a language selector, currency switcher, or international shipping option as the only evidence. A site can have those features without offering the local service described by the query.

2. Classify the organization before changing the site

Ask whether the organization directly provides the service or helps users discover multiple providers. A directory listing European service providers is structurally different from a U.S. plumbing company that directly accepts EEA customers.

If the answer is unclear, pause the implementation. Building an aggregator feed for a direct provider—or treating a multi-provider directory like a single supplier—can send the project down the wrong path.

3. Inspect representative landing pages

Choose a small sample that reflects the actual site: a business detail page, a location page, a service-area page, and any page linked from the data source. Check the rendered output, not just the CMS editor or raw template assumptions.

Confirm that important information is present in the page users and crawlers can access. Check the business name, location or service area, contact details, hours, category, description, and the canonical page URL used by the site.

4. Test crawl and indexing barriers

Inspect the applicable robots.txt response for each representative URL.
Check the HTML, rendered output, and response headers for noindex.
Confirm that the page does not require a login or an interaction that prevents the relevant content from being retrieved.
Check for rendering failures that hide business details from the rendered page.
Review sitemap inclusion and whether the sitemap points to the preferred, indexable URL.

Google’s Local Business structured-data guidance specifically recommends checking crawlability, noindex and login barriers, validating markup, using URL Inspection, and allowing time for recrawling and reindexing.

5. Validate structured data where it is used

Use structured-data validation to catch syntax problems, missing values, and discrepancies between the markup and visible page content. The markup should describe the actual business or location on that page; do not add fields merely because they might be useful to a feed.

Validation shows that the implementation is technically readable. It does not confirm supplier or aggregator eligibility and does not confirm that a Search unit will appear.

6. Use URL Inspection as an evidence check

Run URL Inspection for representative pages and record the result, including the inspected URL, indexing status, crawl information, and any detected issues. Use this to identify technical barriers, not as proof that a page appeared in an aggregator or supplier unit.

Also record the date of the test. Google notes that recrawling and reindexing can take time, so a clean implementation check is not the same as immediate feature visibility.

7. Add feed checks only when the path requires them

For an aggregator, document the feed owner, generation process, delivery status, identifiers, required fields, and a sample of records. Compare those records with their landing pages before treating the integration as ready.

For a direct supplier, do not create a feed simply because the September 18 documentation update mentions feeds. The supplier documentation says crawl-accessible information is the baseline and that feeds can enhance supplier data when available.

Hypothetical example: directory versus plumbing company

Hypothetical scenario: A U.S.-based directory publishes profiles for European plumbers, electricians, and other service providers. It has multiple providers per category, searchable listings, and landing pages for the entities it lists.

This organization maps to the aggregator/VSS path. The agency should document EEA relevance, review the aggregator eligibility requirements, prepare the required entity data, and investigate the Local Point of Interest Feed. It should also verify that each feed record matches a useful, crawlable landing page.

Now consider a separate U.S. plumbing company that genuinely accepts EEA customers through a documented service model. It provides its own services rather than listing other plumbers.

This company maps to the supplier path, subject to Google’s eligibility assessment. The initial work is to verify the EEA service connection and make accurate provider information accessible through crawling. A feed may be an enhancement where available, but the documented supplier baseline is crawl-accessible website information.

If a third site serves only customers in the United States, the September 18 documentation update does not create a reason to pursue either path. Normal technical SEO and local-search maintenance remain the appropriate work.

What evidence should go in the project record?

Documentation of the actual EEA market, service area, locations, or customer process.
The organization classification: direct provider, aggregator/VSS, or not currently in scope.
Representative URLs and captures of the rendered business information.
The robots.txt response and any relevant robots directives.
Evidence that noindex and login barriers are absent where indexing is intended.
URL Inspection results for representative pages.
Structured-data validation results where markup is used.
Sitemap coverage and the preferred URL for each entity or location.
Feed records, delivery evidence, and field-level comparisons where the aggregator path applies.
Matching values between feed records and landing pages.
Cautious Search Console monitoring of overall Search performance.

Google recommends monitoring overall Search performance with Search Console, but the cited documentation does not identify a dedicated Search Console report or filter for local-business aggregator or supplier units. Use Search Console to monitor the site generally; do not present a normal performance report as proof that a specific unit displayed.

Bottom line for U.S.-managed sites

Start with scope, not implementation. If the site does not genuinely serve EEA users, or if the organization is neither a direct local provider nor an appropriate multi-provider service, the September 18 update does not justify a feature-specific project.

If the site is a direct provider, verify EEA service coverage and crawlable, accurate website information. If it is a directory or other VSS, investigate approval and the Local Point of Interest Feed, then reconcile feed records with landing pages. In both cases, document technical readiness separately from feature appearance because Google’s documentation does not guarantee inclusion or provide a dedicated report proving that a unit appeared.

For agencies reviewing a mixed portfolio, which client type is proving hardest to classify: a direct provider with cross-border service, or a directory whose provider data comes from multiple sources?

Sources

Google Search Central: Documentation Updates

Editorial note: AI assists with research, drafting and automated checks. Sources are linked so you can verify the guidance. Platform requirements can change; confirm the details that apply to your setup.