AI search

The entity consistency audit for ecommerce brands

Your brand and product facts live in four places at once. Here is how to audit them, rank the mismatches and fix them in dependency order.

By CartKernel · Published September 6, 2026

An entity consistency audit checks whether every system that describes your brand and your products says the same thing. It matters because search and answer systems assemble a picture of a business from several sources at once, and disagreement between those sources is a reason to use somebody else’s page instead. Nothing about the fix is exotic. It is bookkeeping, applied to facts.

The audit produces one artifact: a sheet of every fact, where it is published, what each source currently says, and which version is correct.

The four places your facts live

Every ecommerce brand publishes the same facts in at least four systems, usually maintained by different people who never compare notes.

The visible site. What a shopper reads on the about page, the product page, the shipping policy and the footer.
Structured data. The markup embedded in those pages describing the organization, the products, the offers and the reviews.
The product feed and merchant account. Titles, prices, availability, identifiers, shipping and returns as submitted to shopping surfaces.
Third-party profiles. Business listings, social profiles, marketplace storefronts, retailer pages, supplier directories and reference sites.

A disagreement between any two of them is a defect, whether or not anything visibly breaks. Price mismatches produce concrete failures such as Merchant Center price mismatch. Softer mismatches, such as three spellings of a brand name, produce nothing visible and quietly weaken every system that tries to recognize you.

Start with a fact sheet, not with an audit

You cannot audit against a standard that does not exist. Write the canonical version first, in one document, owned by one person:

Fact	Canonical value
Legal entity name	The registered name, exactly
Trading brand name	The name used publicly, including capitalization and any spacing
Alternate names	Former names, common misspellings, abbreviations
Primary domain	With or without www, one canonical form
Logo	One file, one aspect ratio, one URL
Registered address and any physical locations	Full postal format
Support contact	Email and phone as published
Social and marketplace profiles	Full URLs, current ones only
Founding year and origin	If you publish it anywhere, publish it identically everywhere
Shipping regions and lead times	The current policy, in the words used on the policy page
Returns window and conditions	The current policy

The alternate names row is the one most stores skip and the one that resolves the most confusion, because it is how you tell systems that the old name and the new name are the same business.

Audit the organization layer

Compare the fact sheet against each source, one column per source, one row per fact. Look for:

A brand name written differently across the site header, the schema, the feed and the social profiles.
An address or phone number that changed once and was updated in three of five places.
A logo that exists in several crops with no single canonical URL.
Social profiles listed in markup that no longer exist, or active profiles that appear nowhere in markup.
Policy pages whose text disagrees with the shipping and returns values submitted to shopping surfaces.
Organization markup missing entirely, or present on one page and absent from the rest of the site.

Organization markup is the machine-readable version of the fact sheet, so build it from the sheet rather than from memory. The requirements Google documents for it are worth reading before you write any of it.

Audit the product layer

Product facts are higher volume and higher stakes, because they feed shopping surfaces directly. Check these fields for agreement between the page, the markup and the feed:

Identifiers. GTIN and MPN present, correct and matching across sources. A wrong identifier is worse than a missing one, because it associates your listing with a different item.
Brand. The manufacturer’s brand, spelled as the manufacturer spells it, not your store name, unless you made the product.
Title. Consistent enough that the page and the feed are recognizably the same item, even where the feed title is optimized differently.
Price and currency. Identical to what a shopper sees at the point the surface checks, including how tax is displayed in your market.
Availability. The feed value matches what the page shows and what the cart will accept.
Variant grouping. All variants of one product share the same grouping identifier, and each variant has its own identifier.
Condition. New, refurbished or used, stated the same way in both places.
Review data. Aggregate ratings in markup reflect reviews actually visible on the page.

The product schema generator produces markup that matches the fields above, and product structured data explains what each one is for.

Rank mismatches by what they block

Not every disagreement deserves the same urgency. Sort them into three tiers:

Blocking. The mismatch causes a disapproval, a suspension risk or an incorrect price shown to a shopper. Fix this week. The website-side requirements behind many of these are set out in Merchant Center website requirements.
Degrading. The mismatch does not stop anything but weakens recognition: inconsistent naming, missing identifiers on part of the catalog, stale profiles. Fix this quarter.
Cosmetic. Formatting differences with no consequence, such as an address written with and without a suite abbreviation. Standardize when convenient.

Rank within each tier by the revenue behind the affected products, not by the number of rows.

Fix in dependency order

The order matters, because fixing downstream first means doing it twice.

Settle the fact sheet and get it signed off by whoever owns the brand.
Correct the visible site, since every other source should be derived from what shoppers actually read.
Regenerate structured data from the site’s own data, so markup cannot drift from the page.
Update the feed and merchant account, including shipping and returns settings.
Correct third-party profiles last, working through the highest-visibility ones first.

Generate markup from the same data that renders the page wherever the platform allows it. Hand-maintained markup on a template that pulls its visible content from a database will disagree eventually, and nobody will notice until something is disapproved.

Assign an owner per source and set a recheck trigger

Consistency decays whenever a fact changes and only one system hears about it. Two habits hold it:

An owner per source. One name against the site, one against the feed, one against the merchant account, one against third-party profiles.
A change checklist. Any change to a name, address, policy, price structure or product identifier triggers a pass through all four sources before the change is considered done.

Recheck fully twice a year, and immediately after a rebrand, a domain change, a replatform, a policy update or a catalog import from a new supplier.

What the audit buys you

Clean entity data does not guarantee a mention anywhere, and nobody should claim it does. What it removes is the class of reasons a system has to skip you: contradictory facts, unmatched identifiers, missing grouping, a brand that looks like three brands. It also makes the monitoring described in a repeatable method for monitoring AI search visibility interpretable, because when the data agrees everywhere, a wrong answer points at something else.

Whether markup itself moves visibility is discussed in does schema markup help AI search visibility, the shopping-data side is in does Merchant Center data power AI shopping, and the ongoing work runs inside AI search visibility alongside Merchant Center.