Google now documents two records for every location, and only one of them can be compared.

A competitor's merchant view is closed to you. Your own is closed to everyone else. That settles which record a fair comparison scores.

November 8, 2026 · 10 minute read

The obvious reading of Google's Edit Status release is operational: agencies will catch rejected edits sooner. The reading that matters is about measurement. Google now documents that a location's submitted record and its public record can differ. Every comparison of a brand's locations, or of a brand against its peers, has to choose which one to score, and only one of them can be checked by someone outside the brand.

Google's Edit Status gives every location a documented second record

On November 2, 2026, Google added Edit Status to the v1alpha Business Information API. Two methods carry it: locations.getExtended for core location data and locations.attributes.getExtended for attributes. Google's update notes say the methods return the merchant-provided view, the consumer-facing view, the edit lifecycle stage of each field, the edit source, and the reasons a policy violation led to a rejection.

The reference page for locations.getExtended says the response includes both the merchant-provided data and the consumer-facing view, "which may differ." The field locationProvidedByMerchant holds the data the merchant manages. The field locationSeenByConsumers holds the location data currently visible to consumers on Google Maps and Search. The attributes method follows the same pattern with attributeProvidedByMerchant and attributeSeenByConsumers.

Every top-level field also carries a last edit lifecycle stage, an update time, and a source (an API client or a Business Profile interface). A rejected edit carries a reason from a policy violation list that Google marks as not frozen. The stages are pending, accepted, rejected, updated by Google, and draft, which applies when a location is not yet verified.

"Updated by Google" means the public sees a value the owner did not submit

The lifecycle stage EDIT_LIFECYCLE_STAGE_UPDATED_BY_GOOGLE means the public sees a different value for that field than the one the owner submitted. Google's enum reference describes it as an edit that "was superseded by a value from another source which is now live." Google's edit status guide describes the same stage as a consumer-facing value that Google updated, for example from user reports or external sources, and that differs from the merchant-provided value.

The two descriptions agree on the point that matters. The owner's edit may have been perfectly valid, and the public record still says something else. The guide tells the manager to review the consumer-facing value and then accept it or override it.

Nobody can read a competitor's merchant view, so only the public record can be compared

A comparison of a brand's locations, or of a brand against its peers, is only trustworthy if someone else running the same inputs on the same day reaches the same result. The merchant-provided view fails that test by construction. Google returns it only to someone authorized to manage the profile. A score built on it can be checked by one party: the brand being scored.

Peers make the failure concrete. Nobody can read a competitor's merchant view. A side-by-side that scores the brand on its submissions and its peers on their public listings measures two different things and prints them in one table. The only record that exists for every location in the comparison, the brand's and the peers', is the one Google shows the public.

The consumer-facing record is also the one that matters downstream. It is what a searcher sees, and what any crawler or assistant reading Google's public surfaces meets. The merchant view records what the brand intended. A comparison exists to show where the brand's story holds, changes or loses ground in public, and a record of intent cannot show that.

An outsider does not read that record through locationSeenByConsumers, which Google returns only to authorized managers, like the merchant view. The outsider reads the listing itself, with four stated inputs: the surface (the Google Maps listing or the business profile shown in Search), the query that resolved it (the business name and street address), the timestamp, and the method (a signed-out browser, a stated viewer location, a saved copy of the page). The score reads the fields printed on one resolved listing, not its rank, so the ordering that device and viewer location change never enters it. The brand's own location page, the other side of each match, is public too. Two captures of the same listing at different times are two inputs, not a failed replication.

Identical submissions can hide an inconsistent public identity

Scoring submissions across a brand's locations erases the variation a regional comparison exists to find. Two branches that submitted identical data look identical in the merchant view. One of them may still show the public a superseded category, an old phone number because the new one was rejected, or hours that Google replaced based on user reports. A brand can submit perfectly consistent data for every location and still present an inconsistent public identity.

The gaps carry patterns a submission score cannot see. Rejections under the same policy reason at several locations point to how the brand submits data. Fields updated by Google that cluster in one region are a lead, not an answer: the API reports the stage and the update time, not where the winning value came from. The guide's examples, user reports and external sources, are where a manager starts looking.

A hypothetical twelve-location brand scores 12 of 12 on its submissions and 6 of 11 in public

Consider a hypothetical brand with twelve locations, used here only to show the method; none of these figures describe a real business. Every location submitted hours, a phone number and a primary category that match the brand's own location page for that branch.

On a stated date, the brand's manager reads Edit Status for all twelve. Three locations in one metro area show hours at EDIT_LIFECYCLE_STAGE_UPDATED_BY_GOOGLE: the submissions are right, and another source now controls what the public sees. One shows a phone number rejected with a policy reason: the owner's version was refused, and the old number stays live. One shows a category change still pending: the public record is behind the owner and may catch up, so next week's capture is a new input, not a correction of this one.

An outsider's capture on the same date resolves eleven of the twelve public listings. The twelfth returns no listing for its name and address. That location is not a hole in the sample. A searcher typing the same name and address meets the same absence, so the report lists it as a finding and states its coverage as 11 of 12.

Scored on the merchant view, the brand is consistent at 12 of 12. Scored on the public record, 6 of the 11 readable listings match their location pages on all three fields, and the five that diverge are listed with their stage and update time. The merchant view's perfect score describes a brand no customer has met.

Anyone can rerun the public half. A peer, an auditor or the brand itself can capture the same eleven listings on the same day, with the same surface and query, and count the same six matches. Only the brand can rerun the merchant half, which is why it explains the five gaps and never sets the score.

The strongest objection: a public score can blame an owner for Google's edit

The strongest objection to scoring the consumer-facing record is that it can hold a location responsible for something the owner did not do. Google's documentation says a public value can come from user reports or external sources. A public score could rank a well-run branch below a careless one because of a stranger's suggested edit.

The answer is attribution, not a switch of records. Where the brand manages the location, the report attaches the stage and update time behind each gap. The well-run branch appears as exactly that: correct in its submission, different in public, updated by Google on a stated date. Scoring the merchant view would hide the gap the owner most needs to act on.

The harder case is the one where Google is right. A branch changed its hours, users reported it, Google updated the listing, and the brand's location page still shows the old hours. The score marks that branch divergent, and the divergence is real: a searcher who reads the brand's page gets the wrong hours. The score measures whether a brand's two public records agree, not which one is true. AIOStory does not measure accuracy, and a report says so.

The same limit governs the incentive. Accepting Google's value in the merchant view moves nothing public. Editing the location page to match whatever Google shows does raise the score, whether Google's value is right or wrong. A brand that copies a wrong value into its own page has made its public story consistent and false, and a consistency score rises anyway. The dated captures preserve the sequence, so a reader can see that the brand's page moved to the listing and not the other way around.

Edit Status covers Google's surfaces, in an alpha schema that can change

Edit Status documents a gap between submitted and public data on Google Maps and Search only. Assistants and crawlers also read a brand's own location pages and other directories, and the API says nothing about those. The claim that holds on every surface is narrower: score what an outsider can read on a stated date.

Edit Status also ships in v1alpha. Google marks the policy violation list as not frozen, and field names and enum values in an alpha release can change too. The comparison does not depend on them. The outsider's capture reads the listing, not the schema, so a renamed stage changes the explanation of a gap and never the score.

The submitted record explains the story. The public record is the story.

Before November 2, a location report scored on submitted data could claim it used the best record available. That claim is gone. The same getExtended response that returns locationProvidedByMerchant returns locationSeenByConsumers beside it, with the stage that explains every difference. A report that scores the first field now holds the divergence in its own payload and leaves it out. Scoring submissions is no longer a limit of the data. It is a choice about which story to tell.