Google Adds Local Business Queries to Aggregator and Supplier Units

Google's September 18, 2026 documentation update brings local business queries into the stated scope of its aggregator and supplier units for users in the European Economic Area. The first decision for a business is its role: an aggregator helping people compare providers, or a direct provider delivering the service.

The current aggregator-unit guide describes an eligible vertical-search feature with provider results and participation requirements. The supplier-unit guide describes a separate direct-provider feature that appears alongside an aggregator unit when that unit is shown. This is a regional feature update, not a global replacement for ordinary local results.

This analysis develops a readiness and measurement plan. Hypothetical examples illustrate data and user-journey decisions; they are not reported business outcomes or a guarantee of acceptance.

Classify the actual business role

An aggregator helps users discover or compare multiple independent providers. A direct supplier provides the underlying product or service. A directory, marketplace, chain, franchise system, and individual location can have different roles.

Do not select the category that seems to offer the most visibility without checking the real business model. A site listing only its own branches is not automatically equivalent to an independent comparison service.

Record who owns the customer relationship, who maintains the listing, and where the visitor completes the intended action. Those facts help define both the feature pathway and the landing-page contract.

A business can operate several products with different roles. Keep them distinguishable rather than assuming one account-level label describes every section of the site.

Confirm the regional and query scope

The international SEO guide helps distinguish market targeting from language and business location.

The documented local-business opportunity is tied to the EEA feature context. A search observation from another market cannot establish whether the feature is available or working for the intended audience.

Record the market, language, query class, device, date, and relevant session conditions when inspecting results. A single screenshot without that context is weak evidence.

Use Google's regional feature overview to identify relevant feature families, then consult the specific guide. Similar-looking units can have different requirements.

Do not infer company eligibility solely from where its office is located. Check the actual service and participation criteria for the market it serves. If an unusual business model is unclear, retain the question for the official participation process rather than inventing an answer.

Separate the aggregator and supplier pathways

For aggregators, the current guide describes approval, relevant content, necessary data, and quality requirements. It links to the applicable interest and integration resources.

For direct suppliers, the guide says additional data beyond accessible crawling is not required for eligibility, while available feeds can enhance results. That is different from saying a feed guarantees appearance or that ordinary website quality is irrelevant.

Map the chosen pathway before building an integration. A team can waste substantial effort preparing an aggregator feed when its actual role is a direct provider.

Keep the public website accurate in either case. A structured integration cannot compensate for a landing page that describes the wrong business, hides the real service, or fails when a visitor tries to contact or book.

Treat the listing as an entity, not a keyword page

Use stable identifiers for businesses and locations. Names can change, addresses can be formatted differently, and several providers can have similar names.

Define which real entity each listing represents. A chain-wide organization, a physical location, and a service-area offering are related but not interchangeable.

Maintain the facts that help a person choose: actual service, location or service area, availability, relevant attributes, authentic images, and a working next action. Do not generate nominal local pages for places where the business does not genuinely operate.

Keep entity facts consistent across the landing page and any integration. A mismatch can produce a confusing journey even when every individual field is syntactically valid.

Build a source-of-truth record

A proposed listing record can contain stable entity ID, public URL, role, location identity, service classification, current operational state, factual attributes, source ownership, and update version.

Assign field owners. A location team may maintain hours while a central system maintains service availability. Without ownership, an integration can distribute stale information that no one considers their responsibility.

Distinguish unknown from unavailable. Missing hours do not prove the business is closed. A missing booking feed does not prove no appointments exist. The representation should not invent certainty.

Record effective dates where relevant. A temporary closure, seasonal schedule, or retired service needs a lifecycle rather than a one-time text edit.

Understand integration dependencies before committing

Google's Local Vertical Search Service integration overview describes eligibility considerations and a staged onboarding process involving sandbox and production review.

Use the current supported integration documentation for actual fields, formats, authentication, validation, and launch requirements. Do not infer a complete contract from a marketing summary.

Build an internal readiness packet first: business role, entity inventory, data ownership, public landing pages, update cadence, and operational support. These remain useful even before acceptance.

Separate application submission from approval and launch. An expressed interest is not a live integration, and a sandbox success is not proof that production results are appearing.

A hypothetical provider comparison

Imagine a local-service marketplace serving several EEA cities. It lists independent plumbers, supports provider profiles, and sends visitors to a maintained contact or booking flow.

Now compare a plumbing company with twelve owned branches. It may have an excellent location directory, but its product is direct service provision rather than comparison among independent providers.

Both can improve entity data and public landing pages. Their feature pathways and integration questions differ. The marketplace needs to substantiate its aggregator role and applicable data relationship; the company needs accurate direct-provider identity and service representation.

These are illustrative classifications, not determinations of eligibility for real businesses. The official criteria and review process control actual participation.

Design the landing-page contract

Review local SEO best practices when validating the selected provider's real service journey.

A click should land on the entity or result the user selected. Avoid sending a specific provider selection to a generic homepage that requires repeating the search.

Preserve useful context such as location, service category, and selected provider where appropriate. The page should explain what the business offers and how to complete the next step.

Test direct visits without stored search state. A URL that works only after using the site's internal filters can fail for a first-time visitor arriving from an external result.

Check mobile behavior, contact controls, booking steps, and error states. A technically eligible listing is incomplete if the actual service journey is unusable.

Reconcile feeds with public pages

If a feed is part of the supported pathway, compare its entity identity, destination, operational state, and consequential facts with the public page.

Keep timestamps and source versions. A discrepancy may result from a source error, transformation bug, delayed export, stale page cache, or intentional channel difference.

Do not automatically overwrite the correct public page to match a bad feed. Trace the authoritative source and repair the producer that diverged.

Use meaningful examples in validation. Two branches with similar names, one temporary closure, and one retired service can expose identity and lifecycle errors that ordinary records miss.

Quantify freshness through the full path

Measure source change, publication, export or API availability, public page update, and later observations. A feed generated every hour does not establish that every underlying fact is current.

Compare producer cadence with the business fact's acceptable age. Appointment availability and a static service description have different freshness requirements.

Inspect queues and shared dependencies. A large backfill should not silently delay an urgent closure update. Separate work or prioritize it according to a documented policy.

Monitor the oldest unprocessed consequential change. A connected integration and a recently successful job can coexist with a backlog of stale records.

A worked mismatch: a closed branch stayed bookable

Consider a fictional location that temporarily closes. The branch system updates immediately, but the public page cache and listing export read different snapshots.

The landing page still offers contact or booking, while the source record says closed. An integration may faithfully distribute one of those inconsistent states.

The proposed repair establishes one versioned operational-state event, updates the page and export coherently, and verifies the selected location at the public URL. It also tests reopening so the restoration path is reliable.

The scenario is hypothetical. It demonstrates why freshness and identity matter independently of whether a particular result unit appears.

Measure discovery and business outcomes separately

Record feature observations with market and query context. Keep appearance, clicks, landing-page sessions, inquiries, bookings, and completed service outcomes distinct.

A click into an aggregator result and a direct-provider inquiry represent different journeys. Do not combine them into one number without explaining the denominator.

Use attribution appropriate to the available evidence. A referral or analytics session can be observed; a claim of incremental revenue needs a stronger design and treatment of other channels.

Compare equivalent periods and log promotions, seasonality, inventory changes, and website releases. A new feature can coincide with demand changes that would have occurred anyway.

Avoid confusing regional features with ordinary local optimization

The update does not make accurate business details, useful location content, public access, or a working website obsolete. Those remain foundational to the visitor experience.

Do not treat every local-ranking fluctuation as a consequence of these units. Diagnose the actual result format, market, affected queries, and landing pages.

Likewise, do not promise a business that joining a program will replace work on its public service information. Participation is one possible distribution pathway, not a complete local acquisition strategy.

Keep entity quality and feature eligibility in separate records. A business can have excellent data while a specific feature does not appear for a given query.

Use a release scorecard with observable evidence

The local SEO checklist adds broader entity and location checks around feature-specific readiness.

A useful scorecard includes role classification, region and query relevance, authentic entity identity, required integration readiness, public landing-page behavior, data agreement, freshness, and operational ownership.

Give each item a clear status: observed pass, failed condition, dependency, or not applicable with a reason. An application in progress should remain a dependency, not a passing live-visibility check.

Test a meaningful set of entity classes and changes. Include new listings, edits, closures, retirements, duplicate names, and direct external entry.

Retain source records and public response evidence for exceptions. That makes a future mismatch diagnosable without repeatedly rebuilding the whole integration.

A bounded evaluation plan

Before investing in a new pathway, define the specific audience and user task. Identify the entity inventory that genuinely serves it and the current quality of the resulting journey.

Estimate implementation and maintenance effort honestly. Include data correction, moderation where applicable, partner support, and ongoing freshness monitoring.

Set a later observation plan with appropriate uncertainty. A small number of favorable result screenshots cannot establish stable coverage, ranking improvement, or business return.

If participation is not appropriate, keep the useful foundation work. Accurate entities, maintained pages, and reliable service actions benefit the site independently of a regional feature.

Audit duplicates at the entity boundary

A local inventory can contain several records for one real location: an old name, a new name, a booking-system identifier, and an imported directory record. A feed that treats all four as independent businesses can misrepresent the inventory.

Build a crosswalk from source identifiers to the stable public entity. Keep the original identifiers as provenance rather than discarding them after a merge.

A fictional marketplace might receive 1,000 source records but resolve them to 920 distinct locations. The difference is not automatically 80 bad records; it may include legitimate multiple services at one place, historical records, or true duplicates. Review the relationship before combining or deleting anything.

Distinguish organization, location, service, and offer. Two services at one address can deserve separate descriptions while still belonging to the same provider location. Conversely, two independent providers sharing a building are not the same business.

Use explicit merge and split events. If two source records are consolidated, update references and destinations coherently. If a record is split into distinct real entities, preserve which service and location each new record represents.

A compact entity reconciliation table

The table is a proposed audit tool. It does not establish program eligibility or replace official integration requirements.

Review the resulting exceptions before expanding distribution. A larger feed can amplify a small identity defect across many queries. Resolving the underlying entity model is often more valuable than adding another optional descriptive field.

Practical answers

Is this update global?

The cited feature documentation describes the relevant EEA context. Verify the current market and query scope rather than applying one observation to every country.

Does every local business need an aggregator feed?

No. Aggregators and direct suppliers have different documented pathways. Classify the actual role and consult the applicable requirements first.

What is the best first step?

Choose a representative entity and trace its identity, service facts, public destination, and update path. Then determine which feature pathway, if any, fits the business. The September change creates a specific evaluation opportunity; a trustworthy entity and landing-page system makes that opportunity usable.