How to Audit Your Brand Entity Consistency for AI Search (8-Layer Guide).

By Ridho Putradi S'GaraSep 2, 202613 min read
// share
► Listen to this post

ent cover hero

Ask ChatGPT who your company is, then put the same question to Gemini and Perplexity. If the three answers disagree about what you do, where you are, or who runs the place, you have an entity consistency problem, and it is costing you visibility in the exact channel your buyers now use to shortlist vendors.

This guide covers what a brand entity is, why AI search rewards consistency, and how to run the audit yourself across eight layers. We ran it on our own site while writing this, and we published what it found.

What a brand entity actually is

Search engines and language models do not store your brand as a string of characters. They store it as a node with properties attached, including name, category, location, founder, services, and a set of links to other nodes.

Your website is one source feeding that node. Your LinkedIn page is another, along with your Google Business Profile, your Crunchbase entry, a directory listing you forgot about in 2019, a podcast bio someone wrote for you, and the schema markup your developer shipped last year.

When those sources agree, the engine holds one confident node. When they disagree, the engine holds a node with low confidence, or two nodes it cannot tell apart, or one node carrying facts from a company that is not yours. Getting this right is the foundation of entity SEO, and it is where most brands quietly lose ground in AI answers.

Classic search could tolerate a fuzzy entity. A page ranked on its own merits, and a user who landed on it worked out the rest.

An AI answer removes that step. The model states who you are in a sentence or two, and the user never visits your site to check. A wrong fact in that sentence goes straight to the buyer with no correction layer in between.

Researchers have measured how often this goes wrong. Columbia's Tow Center tested 1,600 queries across eight AI search engines and found that more than 60 percent of responses contained factual errors (Columbia Journalism Review). ChatGPT Search got 67 percent of test queries wrong in that study, and Perplexity got 37 percent wrong. The models were not inventing facts at random. They repeated what their sources said, and they did it with confidence.

If your sources contradict each other, you are supplying the raw material for that error rate.

Google raised the bar again in June 2025, when it removed more than three billion entities from the Knowledge Graph across two updates in a single week (Search Engine Land). The entities that survived were the unambiguous ones, each resolving to a single clear classification rather than several competing identities. Clarity is now the price of admission.

The two ways brand entities break

Serious findings in an entity audit tend to take one of two shapes.

The merge

Two different companies collapse into one node. Your brand shares a name with another organisation, and your own markup helps the engine confuse the two.

The trigger is often an alternateName property declaring the exact string a bigger, older, or better-documented company already owns. Sometimes it is a single link. A Crunchbase URL pointing into a name-collision cluster tells every engine that reads your schema that you and the other company are the same legal entity.

The same merge happens between a founder and their company. Put the company Instagram handle inside the founder's Person schema, or the founder's personal LinkedIn inside the Organization schema, and you have written an instruction that says these two are one identity. Knowledge panels stay broken once that happens.

The split

One thing becomes two, which happens most often to founders. A founder who runs a personal site alongside the company site ends up with two Person nodes, two different @id values, two job titles, and two sets of profile links that never overlap, with nothing bridging them. To a graph, that reads as two people who happen to share a name.

Sister brands split the same way. Five ventures with no parentOrganization or subOrganization edges are five unconnected islands, and none of them inherits any authority from the others. Connecting them is one of the moves in our Total Graph Authority framework.

The eight layers of an entity audit

Work them in order. Layer A is the source every other layer copies from, so a fix anywhere else is wasted while A is wrong.

Layer What it covers Why the order matters
A. Canonical facts The one true version of your name, description, and core facts Everything downstream copies from it
B. Structured data Organization and Person schema, @id architecture, sameAs Machine-readable, so errors propagate fast
C. On-site consistency Redirects, canonicals, NAP, competing About pages Cheap to fix, easy to verify
D. Off-site profiles GBP, LinkedIn, Crunchbase, directories, registries Slow and manual, so start early
E. Knowledge graph Branded SERP, knowledge panel, Wikidata, collisions Where merges show up
F. People entities Founder and author nodes, cross-domain identity Where splits show up
G. AI answers What the models actually say about you Your measurement layer
H. Outside sources Press, podcasts, guest posts, unlinked mentions Slowest to compound, highest ceiling

Layer A. Lock the canonical facts

Pick one page as your entity home. Your About page suits this better than your homepage, because it describes one subject and nothing else, while a homepage tries to communicate several things at once. Google resolves conflicting information about you against a primary source, and you want to choose which page that is.

Then write down the answers and stop improvising them. Record your trading name as one exact string. Record your registered legal name, kept distinct from the trading name. List the variants you will accept, and no others. Write one sentence describing the company and one paragraph, both reused word for word everywhere. Fix the founding date, founder, headquarters, category, and service list.

Much of the inconsistency we find in client audits traces back to this document not existing. Six people wrote six descriptions across six platforms, and each one was reasonable on its own.

Layer B. Audit your structured data

Start with the @id, which carries more weight than the rest of your markup combined, because it gives every other block on your site a single entity to point at. Declare https://yourdomain.com/#organization once, then have every blog post reference it as publisher, every staff member reference it as worksFor, and every page reference it from its WebPage node. Our structured data process starts here for exactly this reason.

Sites without a stable @id end up redeclaring the organisation on every template. The values drift, and the engine sees a scattering of unconnected pages rather than one company.

Check that name and legalName both appear when they differ. Google's documentation asks for this, and most sites ship the legal name alone or the trading name alone.

Then check what your markup is missing. Google names no required properties for Organization schema and recommends adding as many relevant ones as you can (Google Search Central). Some work behind the scenes to separate your organisation from others, while others control what shows in the knowledge panel. The recommended set now runs to name, alternate name, legal name, description, logo, URL, sameAs, address, contact point, telephone, email, number of employees, founding date, DUNS, NAICS, LEI code, global location number, VAT ID, and tax ID. The full property vocabulary lives on schema.org.

Registry identifiers earn their place here too. A tax ID is not a user-facing field, and that is the point. It anchors your entity to a government record no other company can claim.

Last, audit sameAs as an identity claim rather than a link list. Every URL in that array says this profile is me. Your web developer's site does not belong there. Neither does a partner, a client, or a tool you use.

Layer C. Clean up the on-site basics

Confirm one host and one protocol resolve, with permanent redirects rather than temporary ones. A 302 on your www subdomain tells crawlers the arrangement might change, and clearing that up is a technical SEO basic that still trips up established sites.

Match your footer address to your schema address character for character, then match both to your Google Business Profile. Suite numbers and phone formats drift between these three more than any other field.

Find the competing About pages. Companies accumulate About, Company, Our Story, and Team pages that each do a third of the job, and none of them reads as authoritative. Consolidate them, and use internal links to point the weaker pages at the one you chose in Layer A.

Check that your case studies and work pages carry the Organization node. These pages get cited as proof, and they often ship with breadcrumb markup and nothing else, which detaches your strongest evidence from your entity.

Layer D. Fix the off-site profiles

This layer is slow, manual, and worth doing before anything clever.

Your Google Business Profile name should match your canonical name with no keywords bolted on. Your LinkedIn company page needs the same name, website, industry, and founding year as your schema. Crunchbase, industry directories, and local Indonesian listings all need the same address and the same description.

Check for one-way links as well. A profile listed in your sameAs that does not link back to your canonical domain makes a claim your own site cannot confirm.

Then hunt for legacy names. An old domain, a previous company name, or an entity you rebranded away from will keep getting cited as current until you redirect it or label it as former.

Layer E. Check the knowledge graph and hunt for collisions

Search your exact brand name and read the whole first page. Your own properties should occupy it. Another company outranking you on your own name is the clearest possible signal of a collision.

Check whether a knowledge panel exists and whether its facts are right (Google's knowledge panel help). A wrong founder and a wrong location are the two failures we see most.

Then check Wikidata, where no item for your brand means nothing feeds the Knowledge Graph from the structured side. Getting listed on Wikidata is more achievable than getting a Wikipedia page, though it carries its own notability policy, and every statement needs a real source behind it (Wikidata notability). Guides that tell you Wikidata has no notability bar are wrong, and brands get their entries deleted on that assumption.

Finally, run the collision test by searching your name plus every alternateName you declare. If another organisation holds that string, above all one with an acquisition history and a well-populated Crunchbase profile, stop declaring the string.

Layer F. Separate the people from the company

Your founder needs a Person node with worksFor pointing at the organisation @id, one job title, one name form, and one set of profile links.

The two checks that catch the most damage run in opposite directions. Look for company profiles sitting inside the Person sameAs. Then look for personal profiles sitting inside the Organization sameAs. Either one reads as a claim that the human and the company are the same entity.

If your founder runs a second site, bridge the two Person nodes with a sameAs link between the @id values. Without that bridge you have two people.

Match your profile URLs as exact strings across every site. A trailing slash on one LinkedIn URL and none on another breaks the match.

Layer G. Measure what AI actually says

Build a fixed set of twelve to twenty prompts and never change them inside a measurement cycle. Ad hoc spot checks prove nothing, because a second run has nothing to compare against. This is the core of any real AI search visibility audit.

Cover four kinds of question across the set. The first is direct identity, meaning who you are, what you do, where you are, and who founded you. The second is category questions where you are not named, such as best agencies in your market. The third is comparisons against named competitors. The fourth is founder questions, which test your Layer F work.

Run them across ChatGPT, Gemini, Claude, Perplexity, AI Overviews, and Copilot. Run ChatGPT with browsing on and off as two separate tests, because the answers often disagree, and the gap tells you whether your problem sits in the model's training or in what it retrieves today. If you want the mechanics behind that retrieval step, our guide to how RAG works for SEO covers it.

Score facts rather than impressions, marking each attribute correct, wrong, or missing across category, location, founder, services, and whether the answer confused you with someone else.

Then trace every wrong fact to the page or listing feeding it. Teams skip this step, and the audit turns into a list of complaints. An error with no traceable source means the model is filling a gap, which points at Layer H rather than your schema.

Report three numbers and keep them separate. How often you get named at all, how many facts land correct, and how often you get confused with another company. They move for different reasons, and a blended score hides which layer to work on.

Layer H. Build the outside sources

Everything above happens on properties you control. Layer H covers everything else, and it carries weight the other layers cannot replicate, because an engine treats agreement between independent sources differently from a claim you make about yourself.

Press mentions, podcast appearances, guest posts, speaker bios, awards, association memberships, client pages that list you, and unlinked brand mentions all sit here. Each one needs the same name and the same description. This is where digital PR stops being a vanity exercise and starts feeding your entity.

This layer costs the most and compounds the slowest, which is why it belongs in week one rather than week twelve.

What we found when we audited ourselves

We ran this framework on search.agency while building the tooling for it, and the results were uneven in an instructive way.

The on-site markup held up better than the rest. We had one @id declared once and referenced by every WebPage, every blog post publisher, and every staff worksFor, with both name and legalName present on every page and a founding date matching the About copy. Robots allowed GPTBot, OAI-SearchBot, ClaudeBot, and PerplexityBot by name.

Three problems mattered, and none of them were schema quality.

First, our alternateName declared "The Search Agency". That string belongs to a US search marketing company acquired by ForwardPMX in December 2019, which also holds the primary Crunchbase slug for the name. We were volunteering the one variant most likely to merge us into an American agency that no longer trades under that name, so we removed it.

Second, our Crunchbase link pointed at a slug carrying a numeric suffix, which is how Crunchbase separates profiles inside a name cluster. That link was still unverified, and until we confirm it belongs to us, it may be telling every engine we are the acquired company.

Third, our founder existed as two people. One Person node on search.agency with the title Founder and CEO, another on his personal site with the title AI Search Consultant, different Instagram handles, different profile sets, and nothing bridging the two @id values. The sameAs array also included our web developer's site, which claims their domain as one of our identities.

The pattern underneath all of it repeats across most audits we run. Strong schema, near-zero existence outside our own domain. We have no Wikidata item, and brand searches on the trading name, the legal name, and the founder name return nothing about us. Meanwhile a competitor runs syndicated PR claiming the category position we want.

That diagnosis changes the work, because more schema would not have helped us. The gap sits in layers D, E, and H.

The order to fix things in

  1. Verify or remove any external link you cannot confirm belongs to you, starting with Crunchbase.
  2. Remove alternateName values that match another organisation.
  3. Separate person and company identities in both directions.
  4. Bridge fractured Person nodes across domains with sameAs.
  5. Create the Wikidata item, then add its URL to sameAs everywhere.
  6. Add parentOrganization and subOrganization edges across your venture set.
  7. Baseline your AI answers before the fixes propagate, so you can prove movement later.
  8. Start the outside-source work, because it takes longest to pay back.

How long the fixes take to show

Entity clarity fixes take two to six weeks before AI descriptions improve, and six to twelve weeks for correction across every platform, depending on how many wrong sources exist. Treat those windows as directional, and set your re-test at four to six weeks and again at twelve.

The number of wrong sources drives the timeline more than anything you do to your own site. A brand with one stale directory listing corrects fast. A brand with a decade of inconsistent bios does not.


Search Agency runs entity consistency audits for enterprise brands across Indonesia and Singapore. If your knowledge panel is wrong, or AI assistants describe you as a company you are not, get in touch.

// want_this_for_your_brand

See where your brand stands in AI answers today, benchmarked against your competitors, no pitch required.

[ request_an_audit → ]