A local marketplace completes its schema implementation and expects a new Google feature to appear. The markup validates, but several listings have stale hours, the feed uses duplicate provider IDs, and the team has not confirmed whether the company qualifies as an aggregator or a direct supplier.
Local business aggregator data is not a single schema block. Google’s regional units use different participation models for multi-provider aggregators and direct suppliers in the European Economic Area. Readiness begins with business-model and regional eligibility, then moves through stable landing pages, normalized identity, feed architecture, current availability, and a monitoring plan that does not treat validation as guaranteed inclusion.
Local Business Aggregator Data Starts With the Right Program and Market
Google’s regional Search documentation says aggregator and supplier units are available in the EEA for several query classes, including local businesses. The units are part of a broader set of regional Search experiences that vary by market.
An aggregator unit is for eligible Vertical Search Services such as directories, comparison services, metasearch engines, and online travel agencies. A supplier unit is for direct providers such as an individual hotel, airline, brick-and-mortar business, or service provider.
Confirm five items before implementation:
- The company serves users in the EEA.
- Local-business queries fit the actual inventory.
- The company is an aggregator, direct supplier, or both through separate properties.
- The relevant site and content are public and current.
- The team can meet the participation or feed requirements for its role.
Do not use a supplier implementation to represent a marketplace’s aggregated inventory. Do not submit an aggregator interest form for a single direct business simply because it lists several locations.
Separate Aggregator and Supplier Responsibilities
Google’s aggregator unit documentation describes a multi-provider feature in which eligible aggregators populate results relevant to a query. Users can select among participating aggregators, and clicks lead to the aggregator’s site.
For local business queries, approved aggregators provide data through a Local Point of Interest feed. The public documentation also requires relevant content and compliance with Search content policies.
Google’s supplier unit documentation describes a feature for direct providers that appears alongside the aggregator unit. A direct supplier does not need to provide additional data beyond what Google can access through web crawling, though feeds may enhance the result.
| Responsibility | Aggregator | Direct supplier |
|---|---|---|
| Represents | Multiple providers or listings | Its own locations, products, or services |
| Primary participation path | Approval as an eligible VSS and applicable interest process | Crawlable public website serving EEA users |
| Local-business data path | Local Point of Interest feed | Web crawling, with optional enhancement feeds |
| Landing-page role | Compare or route users to relevant providers | Present the direct provider’s offer and location |
| Data ownership challenge | Normalize facts from many suppliers | Keep owned business facts current |
| Common failure | Duplicate, stale, or unsupported provider inventory | Weak crawlable detail or inconsistent profiles |
The supplier unit appears only when the aggregator unit appears. That dependency should shape testing expectations.
Build Stable Landing Pages for Local Inventory
Every submitted or discoverable entity needs a useful destination. A landing page should represent the same business, location, service, and availability shown in the feed or search result.
Use stable URLs and clear canonicalization. Avoid rotating session parameters, temporary search pages, or JavaScript states that cannot be linked directly.
The page should make the important facts visible in text:
- business name and category;
- address, service area, and location details;
- current hours and temporary closures;
- services, products, or appointment options;
- price or price range where relevant;
- availability and eligibility constraints;
- provider relationship and booking or contact path;
- date or process for maintaining current information.
An aggregator page should explain why a listing appears and what the aggregator can verify. A supplier page should make clear that the business provides the service directly.
Normalize Identity, Category, Location, Price, and Availability
Feed quality depends on stable identifiers and explicit ownership. Names and addresses alone are not reliable keys because spelling, language, and formatting vary.
Create a canonical record for each provider and location. Maintain source-of-truth fields for:
- provider ID and location ID;
- legal or official business name and public display name;
- category and supported subcategory;
- geocoded address, service area, and contact details;
- hours, exceptions, temporary closures, and status;
- offer, price, currency, taxes, and applicable terms;
- booking, purchase, or contact URL;
- source system, verification time, and next refresh;
- relationship between aggregator and supplier.
Use controlled vocabularies and document how supplier categories map to the required feed. Do not let a model infer categories from marketing copy without review, especially when eligibility depends on query type.
Resolve duplicates before export. Two records for one location can split engagement and create conflicting prices. One record that combines several locations can show an offer where it is not available.
Keep Structured Data Consistent With Visible Details
Structured data can help describe a local business page, but it should not become a separate inventory. Google’s general structured data guidelines require the markup to represent visible content and remain current.
Generate the page, markup, and feed from shared canonical fields. When that is not technically possible, run automated reconciliation and block release on material mismatches.
Check:
- business identity and URL;
- address and geographic scope;
- opening hours and temporary exceptions;
- offer price, currency, and availability;
- review or rating data that is genuinely visible and policy-compliant;
- images that belong to the listed entity;
- last verification and update events.
A passed Rich Results Test does not prove that a feed is eligible or that the unit will appear. Syntax is one readiness signal.
Design Freshness and Removal Workflows
Local business data decays through normal operations. Stores close, service areas change, providers leave an aggregator, appointments fill, and prices expire.
Assign refresh cadence by consequence:
- closure, safety, and provider-removal events should propagate urgently;
- hours and temporary exceptions need event-driven or frequent updates;
- prices and availability need the cadence required by the product experience;
- category, description, and imagery can follow a slower verified review;
- ownership and identity changes require manual confirmation.
| Data field | Source of truth | Suggested trigger | Failure impact |
|---|---|---|---|
| Business status | Supplier or verified operations system | Closure, reopening, suspension | Users travel to or contact an unavailable business |
| Hours | Location management system | Holiday, emergency, seasonal schedule | Failed visit or booking |
| Availability | Inventory or scheduling system | Capacity change | Invalid offer or appointment |
| Price | Commerce or provider feed | Price or currency change | Misleading commercial decision |
| Category | Reviewed provider record | Service-line change | Wrong query eligibility and poor matching |
| Landing URL | CMS and routing registry | Migration, merge, removal | Broken destination or duplicate entity |
Keep a removal queue and verify that deleted providers disappear from feeds, sitemaps, internal search, structured data, and public landing pages according to policy. Leaving one stale output active can recreate the listing.
Monitor Regional Visibility After Launch
Build a launch record with the approved business role, target region, query class, participating property, feed version, representative URLs, and date.
Monitor technical acceptance, crawl and index state, feature appearance, clicks, leads, bookings, and data-quality complaints separately. The aggregator unit displays only one aggregator at a time, and supplier units depend on the aggregator unit appearing, so absence from one observation is not a complete diagnosis.
Topify can support market-specific prompt and citation observation as an additional layer. A team might monitor representative local-business prompts by country, compare which aggregators and suppliers appear, and inspect the cited or linked sources. The observation does not expose Google’s eligibility decision or prove that a feed change caused feature selection.
Investigate failures in order:
- Was the feature available for the region and query?
- Did the business role match aggregator or supplier eligibility?
- Was the feed or page accessible and current?
- Did identifiers, landing pages, and visible facts agree?
- Did another provider better satisfy the query?
- Did the user complete a meaningful action?
Conclusion
Local business aggregator data is ready only when the business role, regional feature, landing pages, identifiers, feeds, visible facts, and update workflows agree. Schema validation is helpful, but it cannot resolve an ineligible business model or stale provider inventory.
Confirm whether the property is an aggregator or direct supplier, then follow the participation model for that role. Build stable public destinations, normalize provider and location data, and generate feeds and markup from a shared source of truth. Finally, monitor technical state and user outcomes without treating appearance as guaranteed. Expanding coverage matters only when every additional listing remains trustworthy enough to support a real local decision.
FAQ
What is Google’s aggregator unit?
It is an EEA Search feature for eligible multi-provider services such as directories, comparison services, and other approved Vertical Search Services.
What is the difference between an aggregator and a supplier unit?
The aggregator unit represents multi-provider services. The supplier unit represents direct providers and appears alongside the aggregator unit when that feature is triggered.
Which local business data fields need frequent updates?
Business status, hours, temporary closures, availability, price, currency, booking paths, and provider relationships usually need the fastest refresh.
Does structured data guarantee inclusion in these Search features?
No. Structured data and valid pages can support understanding and eligibility, but Google does not guarantee appearance. Aggregators also need program approval and required data integrations.
