Building a Brand Entity: A Knowledge Graph Guide for D2C Brands

Ask ChatGPT what your brand sells. Then ask Gemini who founded it. Then ask Perplexity how your returns policy works.

Most D2C founders who run this test get three answers, and at least one of them is wrong. Sometimes the model confuses the brand with a similarly named company. Sometimes it invents a founding year. Sometimes it simply says it has no reliable information, which in a shopping context is the same as not existing.

That is not a content problem. Your blog is fine. It is an entity problem, and it is fixed in a completely different place.

This guide explains what a brand entity is, why D2C brands face a harder version of the problem than most businesses, and how to build the machine-readable identity that Google’s Knowledge Graph and AI assistants rely on. You will learn the exact schema properties Google recommends, the subtype nearly every D2C site gets wrong, how to handle brand-name collisions, and a 90-day plan to go from invisible to correctly understood.

Key takeaways

• An entity is not your website. It is the set of facts about your brand that machines have collected and cross-checked from many sources
• Google recommends OnlineStore as the schema subtype for ecommerce sites, not the generic Organization most D2C brands use
• There are no required properties in Organization schema — which is why most brands add four and stop
• Identifiers like iso6523Code, vatID and taxID do nothing visible on your site, but they are how machines separate you from every other business with a similar name
• You will probably never get a Wikipedia page, and that is fine. Wikidata, consistent marketplace listings and corroborated mentions do most of the work
• The single biggest D2C entity risk is a brand name that collides with a common word or an existing company

What is a brand entity

An entity is a thing that machines can identify, describe and distinguish from other things. A person, a place, a company, a product, a concept.

Google’s Knowledge Graph is a giant store of entities and the relationships between them. It knows that a particular person founded a particular company, that the company sells a particular category of product, and that it operates in a particular country. When you search for a well-known brand and see a panel on the right of the results, you are looking at an entity Google is confident about.

The distinction that matters most is this one: your website is a source of information about your entity. It is not the entity itself.

That is why brands with excellent websites can still be described wrongly by AI assistants. The website is one input. The entity is built from many inputs, cross-checked against each other. If your site says one thing and your Amazon storefront says another and your LinkedIn page says a third, the machine’s confidence drops and it either picks one at random or declines to answer.

Entity, keyword, and why the difference matters now

For twenty years SEO was organised around strings. You wanted to rank for a phrase, so you put the phrase on the page.

Entity optimisation is organised around things. You want a system to know what your brand is, what it sells, who runs it, where it operates and whether it can be trusted. No amount of keyword placement achieves that, because it is a question of corroborated fact, not word frequency.

This became urgent rather than academic when AI assistants started answering shopping questions directly. A ranking system can afford ambiguity — it just shows ten links and lets the human sort it out. A recommendation system cannot. When an assistant names your brand, it is putting its own credibility behind that answer, so it favours brands it can describe confidently. This is the same logic underneath agentic search optimisation and it applies to every AI surface, not just Google’s.

Why D2C brands have a harder entity problem

Generic entity advice assumes you are a recognisable company with press coverage and a Wikipedia page. Most D2C brands are not, and their obstacles are specific.

You are probably below the notability threshold. Google does not publish criteria for triggering a knowledge panel, but the pattern is clear enough: it happens when a brand is discussed widely enough across independent sources that Google considers it a distinct, notable thing. A three-year-old skincare brand with strong revenue and no press coverage often does not qualify, regardless of how good the business is.

Your brand name may collide. This is the most underrated risk in D2C and I will come back to it in detail. Many D2C names are common words, coined words that resemble other words, or names already used by an unrelated company in another country.

Your data is scattered across marketplaces you do not fully control. A typical Indian D2C brand appears on its own site, Amazon, Flipkart, Nykaa, Myntra and two or three quick-commerce apps. Each of those carries a brand description, a logo, a category and sometimes a founding story. When they disagree, the entity gets blurry.

Your legal name and trade name differ. The company might be registered as “Aureal Consumer Products Private Limited” while every customer knows it as one word. Both facts are true, and if you never declare the relationship, machines have to guess whether they are the same company.

You rebrand more often than established companies. Name changes, category expansions and packaging overhauls are normal in D2C and each one fragments the entity record unless handled deliberately.

Your founder is a separate entity, and often a bigger one. Founder-led D2C brands frequently have a founder with more public presence than the company. That is an asset, but only if the connection between the two entities is explicit.

None of these are content problems. All of them are data problems.

The entity home: pick one page and mean it

Before any implementation, decide on your entity home — the single page that acts as the authoritative description of your brand.

For most D2C brands this should be the homepage or a properly built About page. Google’s guidance is to place organization structured data on your home page, or on a single page describing your organization, and explicitly says you do not need it on every page of your site.

That last part is worth emphasising because it is one of the most common implementation errors. Many Shopify and WordPress themes inject Organization schema into every page by default. That does not strengthen your entity; it just creates noise and makes debugging harder.

Your entity home should carry, in plain readable text as well as in markup: what you sell, who you are, when you started, where you operate, how to contact you, and what your policies are. Everything else on your site can reference it.

Layer 1: Declare yourself properly

This is where most of the practical gain sits, and where most D2C brands do the least.

Use the right subtype

Google’s Organization structured data guidance is to use the most specific schema.org subtype of Organization that matches your business. For an ecommerce site, that means using OnlineStore rather than the more general OnlineBusiness — and certainly rather than the bare Organization that nearly every theme ships with by default.

This single change costs one line and tells Google what kind of thing you are before it reads any other property.

{

  “@context”: “https://schema.org”,

  “@type”: “OnlineStore”,

  “name”: “Your Brand”,

  “url”: “https://yourbrand.com”

}

If you also run physical stores, use the appropriate LocalBusiness subtype for those locations in addition to this.

There are no required properties, which is exactly the problem

Google states plainly that Organization structured data has no required properties, and recommends adding as many as are relevant to your organization.

This sounds generous. In practice it means most implementations include four properties — name, url, logo, sameAs — and stop, because nothing forces them to do more. Here is the fuller set worth working through.

The identifiers most brands skip

The identifier properties deserve their own paragraph because they are counter-intuitive.

iso6523Code, duns, leiCode, naics, vatID, taxID and globalLocationNumber do nothing for the human visiting your page. They are pure disambiguation signals — Google says outright that properties like iso6523 and naics are used behind the scenes to distinguish your organization from other organizations.

That is precisely why they matter for D2C. If your brand name is ambiguous, a registry identifier is the strongest possible statement that you are a specific, registered, real business and not the other company with a similar name.

iso6523Code is the format Google prefers, because it carries a four-digit ICD prefix telling any system which registry issued the identifier. Google lists three common values:

• 0060: for a Dun & Bradstreet DUNS number
• 0088: for a GS1 Global Location Number
• 0199: for a Legal Entity Identifier

So “iso6523Code”: “0060:123456789” says “this is our DUNS number” in a way any consuming system can validate. Google’s documentation encourages iso6523Code with the appropriate prefix over the standalone duns and leiCode properties, though the standalone versions remain valid if you already use them.

For Indian D2C brands, taxID is the natural home for your GST identification number, and it must match the country declared in your address. The full ICD register is published under ISO 6523-2 if you want to check whether a specific Indian registry has a designated code before using iso6523Code for it. Where it does not, taxID and legalName together still do substantial disambiguation work.

Get the logo rules right

Google’s requirements for the logo property are specific and frequently missed:

• Minimum 112 × 112 pixels
• The image URL must be crawlable and indexable
• The format must be one Google Images supports
• The logo must look correct on a pure white background

That last one catches out a lot of D2C brands. If your logo is white or very light — common in premium positioning — it will disappear against the white background of a knowledge panel. You need a version that works on white, even if it is not the version on your site header.

Merchant properties are the D2C-specific opportunity

hasMerchantReturnPolicy, hasShippingService and hasMemberProgram sit at the organization level and feed directly into merchant knowledge panels and Merchant Center brand profiles.

For a D2C brand this is unusually valuable, because return policy and shipping terms are exactly what a shopper — or an assistant acting for a shopper — wants to know before committing to an unfamiliar brand. Declaring a 30-day free return policy in structured data, at brand level, answers that question everywhere the entity is described rather than only on the page a visitor happens to land on.

Then validate it

Run the Rich Results Test on your entity home and fix any critical errors. Then use the URL Inspection tool to confirm Google can actually reach the page and that it is not blocked by robots.txt, a noindex tag or a login wall.

Allow time. Google notes it can take several days after publishing for a page to be found and crawled, and entity consolidation is slower still.

Layer 2: Get corroborated

Declaring facts about yourself is necessary but not sufficient. Machines weight independent confirmation far more heavily than self-description, for obvious reasons.

Build a real sameAs set

sameAs links point to pages elsewhere that describe your organization. Google’s own example uses profile pages on social and review sites.

Prioritise by authority rather than by how many you can list:

High value. Wikidata, LinkedIn company page, Crunchbase, your verified Google Business Profile, official registry listings, industry association pages.

Medium value. Instagram, YouTube, X, Facebook, Pinterest — provided each is genuinely active and consistent.

Low value. Directory listings you paid for, aggregators, anything that would not exist if you had not created it.

The rule is that every sameAs URL should point to a page you can actually be verified on. A dead LinkedIn page with no posts is a weak signal.

Wikidata, yes. Wikipedia, probably not.

These get conflated constantly and they have very different thresholds.

Wikipedia requires notability demonstrated through significant coverage in independent, reliable sources. Most D2C brands do not meet it, and attempting to create a page anyway usually results in deletion and occasionally in reputational embarrassment. Do not build a strategy around it.

Wikidata is a structured database rather than an encyclopaedia, and its inclusion criteria are considerably broader. A brand that can be described with references — a company registration, credible press mentions, an official site — can generally have an item. That item then becomes a strong, machine-readable, third-party anchor for your entity, linkable from sameAs.

Two rules if you go this route. Be transparent about your connection to the brand, because undisclosed self-editing is against community norms. And only add statements you can reference, because unreferenced claims get removed and repeated removals damage the item’s standing.

Fix your marketplace listings

This is where D2C brands lose the most entity clarity and nobody talks about it.

Your Amazon brand store, Flipkart seller page, Nykaa brand page and Myntra listing each carry a brand description, a logo and a category. They are frequently written by different people at different times and never reviewed together.

Do a single audit. Put every place your brand is described into one spreadsheet, and check five fields across all of them: exact brand name spelling, logo file, one-line description, category, and founding year. Make them identical. This is unglamorous work that takes a day and removes more machine confusion than a quarter of blog posts.

The same applies to your legal name. If you are registered as one thing and trade as another, make sure that relationship is stated consistently rather than each platform showing a different variant.

Layer 3: Connect to other entities

An isolated entity is weak. Entities gain definition from their relationships.

Your founder. For founder-led D2C brands this is the strongest available connection. The founder should have their own consistent presence — LinkedIn, author bios, interviews, conference listings — and the connection should be explicit on both sides. Your About page names them; their profiles name the company. If your founder appears on podcasts and in press more than the brand does, that visibility only transfers if the link is unambiguous.

Your products. Product schema on product pages, connected to the brand, tells Google that these specific items belong to this specific organization. For a D2C brand your products may become more recognisable entities than the company itself, which is fine as long as they are clearly attributed.

Your category. Your description, your content and your product taxonomy should place you consistently in one primary category. Brands that describe themselves as three different things across three platforms are harder to recommend, because an assistant answering “best X” needs to know whether you are an X.

Your locations and markets. Where you are based, where you ship, which markets you serve. Concrete and easily stated, frequently omitted.

The name collision problem

I want to spend real time here because it is the most D2C-specific entity risk and almost nothing written on this subject addresses it.

D2C naming conventions actively work against entity clarity. Short, coined, evocative names are excellent for brand recall and terrible for machine disambiguation. Three failure patterns:

Common word collisions. A brand named after an ordinary noun competes with every use of that noun. The machine has to decide whether a mention refers to your company or the everyday meaning, and it will often get it wrong.

Existing company collisions. Your name may already belong to an unrelated business in another country or category. Both entities exist, both are legitimate, and machines must separate them using every other available signal.

Near-miss collisions. Names that differ from an established brand by a letter or a space get merged constantly.

You cannot rename the company because of this, and I would not suggest you should. What you can do is make every other signal so specific that disambiguation becomes easy:

• Use legalName alongside name so the registered entity is stated
• Add registry identifiers, because a tax ID or company number is unique in a way a brand name is not
• Always pair your name with your category in descriptions — “a direct-to-consumer skincare brand” rather than just the name
• Keep alternateName accurate, including the variants customers actually type
• Build the founder connection, because a named person is a strong differentiator
• Use a consistent, distinctive logo everywhere

The test: search your brand name in Google and in three AI assistants. If you see results about something else entirely, or the assistant blends your brand with another, you have a collision to manage rather than a content gap to fill.

What you cannot control

Some honesty is useful here, because a lot of agencies sell entity work as if a knowledge panel can be ordered.

You cannot make Google give you a knowledge panel. Google does not publish the criteria and there is no submission process. What you can do is make the underlying facts unambiguous and let notability accumulate.

You cannot remove a knowledge panel once it exists. You can claim it if you can verify you represent the entity, and then suggest corrections, but the panel is Google’s.

You cannot control what other sites say about you. You can correct factual errors by contacting them, and you can make your own declarations clear enough that contradictory information looks like the outlier.

You cannot force a Wikipedia page, and pursuing one aggressively tends to backfire.

What you fully control is your own declarations, your consistency across owned platforms, and your effort to earn genuine third-party coverage. That is enough. Most D2C entity failures are not caused by the uncontrollable parts.

How to check where your entity stands

Ask the assistants. Ask ChatGPT, Gemini and Perplexity to describe your brand, name your founder, list your main products and summarise your returns policy. Record every error. This is your baseline and it takes fifteen minutes.

Search your brand name. Look for a knowledge panel. Look for the wrong entity appearing. Look at which of your profiles rank.

Run the Rich Results Test on your entity home to confirm your markup parses and to see exactly which properties you have declared.

Do the consistency audit. Every platform, five fields, one spreadsheet.

Check Search Console for structured data errors and for the Generative AI performance report.

Re-run the assistant test monthly. Improvement here is slow and cumulative, and the errors disappearing one by one is the clearest signal you have that the work is landing. Sustained measurement across assistants is what proper AI visibility tracking is for.

Final takeaway

Building a brand entity is not a creative exercise. It is a records exercise.

You are answering a small set of questions — what are you, what do you sell, who runs you, where do you operate, what are your terms — and then making sure every place that answers those questions agrees.

The reason it feels unfamiliar is that no single team owns it. The schema is developer work. The marketplace listings belong to ecommerce. The founder profile is founder-led. The press coverage is PR. Entity work is the thing that falls between those functions, which is exactly why so few brands do it and why the ones that do become noticeably easier for AI systems to recommend.

Start with the test. Ask three assistants about your brand, write down what they get wrong, and work backwards from there. Every error has a source, and every source is fixable.

FAQs

How long before an entity is recognised?

Months, not weeks. Markup gets picked up within days of recrawling, but consolidating a confident entity depends on corroboration accumulating across sources. Expect three to six months for meaningful change, longer for a knowledge panel.

Will Organization schema improve my rankings?

Not directly. It helps Google understand and disambiguate your organization, influences visual elements like which logo appears, and feeds merchant knowledge panels. Those affect visibility and trust rather than ranking position.

What if two companies genuinely share our brand name?

Then disambiguation is your entire job. Legal name, registry identifiers, category-paired descriptions, founder connection and a distinctive logo are the tools. Both entities can coexist clearly if each is specific enough.

Make your brand legible to machines

Most D2C brands discover their entity problem the hard way — an AI assistant describing them as the wrong company, quoting a returns policy they abandoned two years ago, or crediting a founder who was never involved.

Opositive builds brand entities as part of our D2C SEO and AI SEO programmes: Organization and product schema implementation, identifier and registry mapping, cross-platform consistency audits, Wikidata and profile groundwork, and ongoing measurement across Google, ChatGPT and Gemini.

If you want to know how AI systems currently describe your brand, and where the wrong answers are coming from, request an entity audit.

Mansi Jain

Mansi Jain
Senior AI SEO Specialist @ Opositive.io
GEO, AEO & LLM Optimization Specialist · 6.5+ yrs Technical SEO

About Mansi
Mansi Jain is a Senior SEO Specialist with 6.5+ years of experience in technical SEO, content strategy, ecommerce SEO, and AI-powered search optimization. At Opositive.io, she helps businesses improve their visibility across traditional search engines and emerging AI platforms through data-driven SEO strategies.
Her expertise includes technical audits, keyword research, schema implementation, content clustering, and AI SEO (GEO/AEO). Passionate about staying ahead of search trends, Mansi shares practical insights and actionable strategies that help marketers, founders, and businesses achieve sustainable organic growth.

“Practical, data-driven SEO that helps businesses grow sustainably across both traditional search and AI platforms.

Specialization
Technical SEO, Ecommerce SEO & AI SEO (GEO/AEO)

Education
B.Tech, Information Technology
College of Technology and Engineering, Udaipur · 2015 – 2019

Experience
Senior SEO Specialist, Opositive.io
3+ years at Opositive · 6.5+ years in SEO & AI-powered search

Skills
Technical audits, keyword research, schema, content clustering