Local Search Becomes a Feed: What Aggregator and Supplier Units Change

Google's September 18, 2026 documentation update added local-business queries to its aggregator and supplier units in the European Economic Area. The change matters because it gives different source roles their own search surfaces. An aggregator may populate a unit through an approved direct data feed, while a direct provider can appear in a supplier unit using crawlable website information and may enhance its result with feeds. Local GEO therefore depends on more than optimizing a location page. A business must know whether it is acting as the place itself, an intermediary that lists places, or both, and keep names, identifiers, locations, hours, availability, reviews, and landing pages synchronized across those roles.

Two units, two kinds of source

The aggregator unit is designed for vertical search services such as directories, comparison services, metasearch companies, and online travel agencies. It can show results supplied by an eligible aggregator for hotels, flights, transport, products, and now local businesses. One provider's results are expanded by default, and users can select another available aggregator.

The supplier unit appears alongside the aggregator unit and is reserved for direct providers: an individual hotel, airline, shop, plumber, or other business that directly supplies the service. Google says the supplier unit appears only when an aggregator unit appears. Direct providers do not need to submit additional data beyond what Google can crawl from the web, although feeds can enhance supplier results.

The availability is regional. Google's documentation lists both units for EEA users, and its regional-experience page describes different features in other markets. A result seen in France should not be assumed to exist in the United States, Türkiye, or South Africa under the same conditions.

The source role changes the data contract

An aggregator and a direct provider can describe the same restaurant, clinic, store, or tradesperson, but their evidence is not equivalent.

A directory cannot become the official source of a shop's holiday hours merely by repeating them. A shop cannot claim independent review evidence by embedding ratings it controls. The roles should remain visible in both content and measurement.

Local entity matching is the first technical problem

Google's Local Point of Interest feed documentation shows how much entity matching depends on ordinary fields. A POI record can include a partner-generated identifier, name, telephone, URL, coordinates, address, and localized text. Those fields help match partner inventory with entities already known to Google.

The matching problem becomes difficult when:

• a chain uses the same phone number for every branch;
• a mall tenant and the mall share an address with no unit number;
• a professional works at several clinics;
• a business has moved but old directories retain the former coordinates;
• a franchise uses the corporate URL instead of a location URL;
• transliterated names vary by platform;
• a service-area business publishes a virtual office as a storefront;
• an aggregator creates a new ID after every feed rebuild.

Before writing more local content, create a location identity table. Give every real location a stable internal ID, official name, complete address, coordinates, international phone number, canonical URL, business category, and operating status. Record former addresses and aliases rather than deleting their history.

Crawled pages and direct feeds solve different problems

A location page is designed for people and general web retrieval. It can explain services, access, staff, parking, policies, accessibility, and local proof. A feed is a structured exchange designed to move many records and updates reliably. Neither is a substitute for the other.

Google's aggregator documentation says local-business and lodging units can be populated through direct data-feed integrations, while flight and transport use real-time APIs in relevant cases. The supplier documentation says crawlable web data is sufficient for basic eligibility. That creates a reconciliation duty: the feed, markup, page, and actual business operation must agree.

Freshness is a field-level property

"Updated today" is too coarse for local data. A record contains facts that change at different speeds:

• name and coordinates may remain stable for years;
• normal hours may change seasonally;
• holiday hours may be known only weeks ahead;
• availability can change by the minute;
• prices may vary by location and day;
• review counts change continuously;
• service coverage can change after staffing or licensing updates.

Assign each field an owner, source, refresh interval, and expiry rule. A sample contract might look like this:

The point is not to update every field every minute. It is to stop a fast-changing field from inheriting the false confidence of a recently refreshed stable field.

Categories are claims about fit

Google recommends specific categories rather than generic labels in aggregator data. Category choice affects which query set a business can plausibly satisfy. A "health clinic" and a "travel vaccination clinic" overlap, but the second category implies a service that should be verified on the location page. A restaurant marked as "vegan" needs a menu and operating reality that support the label.

Category expansion should follow evidence:

1. Confirm that the service is currently offered at that location.
2. Publish a page section that explains the service, constraints, and booking route.
3. Use the most specific supported category without stacking unrelated types.
4. Reconcile the category across the business profile, site markup, feeds, and directories.
5. Remove the category when the service ends.

Adding popular categories without operational support may increase short-term impressions and create wrong answers, poor leads, and policy risk.

Reviews need provenance and role clarity

Google's LocalBusiness documentation permits review information under defined conditions, while its review-snippet guidance restricts self-serving review markup for businesses and organizations. An aggregator may report user ratings about listed businesses when the ratings are genuinely collected and policy-compliant. A business should not convert testimonials it controls into the appearance of independent aggregate evidence.

For GEO, preserve at least four review facts: who collected the review, which location or provider it concerns, the date or service period, and the moderation or verification method. A model summarizing "customers praise the service" should have a way to distinguish verified post-transaction reviews from selected quotes on the business's own site.

Separate the direct-provider and aggregator playbooks

For a direct local business

1. Claim and maintain the relevant business profile.
2. Publish one canonical page for each real location.
3. Include visible name, address, phone, hours, services, booking path, and accessibility details.
4. Add accurate LocalBusiness markup that matches the page.
5. Resolve old addresses, duplicate profiles, and inconsistent phone numbers.
6. Monitor crawler access and page status.
7. Test regional queries from the markets actually served.

For an aggregator or directory

1. Define the inventory source and the right to display it.
2. Use stable POI identifiers and an explicit entity-matching process.
3. Record when each field was received and last verified.
4. Provide original value beyond copied listings, such as comparison, availability, verified reviews, or specialist coverage.
5. Build correction and provider-claim workflows.
6. Keep feed records aligned with public landing pages.
7. Apply for relevant programs only where eligibility and data quality can be maintained.

An organization that plays both roles should separate the records and disclose the relationship. A hotel group's booking directory is not independent of its hotels, even if it looks like an aggregator.

Regional testing needs a surface map

Do not use one query and one country as a proxy for local visibility. Build a matrix with:

• country and language;
• desktop and mobile surface;
• direct-brand, category, "near me," and comparison intent;
• aggregator unit present or absent;
• supplier unit present or absent;
• selected provider in the aggregator unit;
• direct-provider appearance;
• factual accuracy of name, hours, category, price, and availability;
• landing-page destination;
• timestamp and signed-in state.

The September documentation itself is evidence that feature availability varies by region. A change in unit design can alter click paths even when the underlying business page and rank remain unchanged.

What success looks like

Useful metrics follow the data path:

These measures can reveal whether the limiting factor is entity hygiene, feed operation, web retrieval, surface eligibility, or user conversion.

Frequently asked questions

Is this a global Google Search change?

1. The aggregator and supplier units discussed here are documented for EEA users, with other regional features listed separately.

Does a direct provider need a special feed to appear in the supplier unit?

Google says no additional data beyond crawlable web information is required, although feeds can enhance results where available.

Can a local business appear in both an aggregator and supplier context?

The business can be represented in an aggregator's inventory while its own site may be eligible as a direct supplier. The roles and destinations should remain clear.

Is LocalBusiness structured data enough?

1. It helps describe the page, but the public page, business operation, profiles, and any feeds must also be accurate and accessible.

What should be fixed first?

Start with identity-critical fields: official name, location, phone, URL, operating status, and category. Content expansion built on a duplicate or wrong entity makes the problem larger.

Sources and evidence boundary

• Google Search Central, "Aggregator unit in Google Search," accessed September 28, 2026
• Google Search Central, "Supplier unit in Google Search," accessed September 28, 2026
• Google Search Central, "Regional differences in Search experience," updated September 18, 2026
• Google Actions Center, "Point of Interest feed," accessed September 28, 2026
• Google Search Central, "LocalBusiness structured data," accessed September 28, 2026
• Google Search Central, "Review snippet structured data," accessed September 28, 2026

The feature descriptions above are limited to Google's documented behavior and availability on the access date. Eligibility does not guarantee display. The field-governance, audit, and measurement frameworks are practical recommendations rather than disclosed ranking factors.