Brand Knowledge Graph: How to Make AI Describe Your Business Correctly

A brand knowledge graph is a structured set of facts about your business (who you are, what you offer, where you operate and which profiles belong to you) connected so machines can read them without guessing. When AI assistants like ChatGPT, Perplexity, Gemini or Google AI Overviews describe your business, they piece together facts from many sources. A clear, consistent knowledge graph on your own site gives them one reliable version to match against.

This guide explains what a knowledge graph is, how your own structured data relates to Google’s Knowledge Graph, which facts to define, and how to check that the web tells the same story about you everywhere.

What is a knowledge graph?

A knowledge graph stores information as entities (things) and relationships (how those things connect). An entity can be a company, a person, a place, a service or a website. A relationship says something like “this clinic is a location of this company” or “this person founded this company”.

The difference from a normal web page is structure. A page says “Founded in 2015 by Dr. Maya Collins, Harbour Lane Dental has served Sydney families for years.” A knowledge graph records the same thing as separate, labelled facts: organization name, founding date, founder, location. Machines don’t have to interpret the sentence; the facts are already sorted.

This matters for AI search because assistants are trying to answer questions such as “Who runs Harbour Lane Dental?” or “Is there a dentist on Harbour Lane in Sydney?”. The more clearly your facts are stated and linked, the easier it is for an engine to match your business to the right entity and avoid confusing you with a look-alike. This is the practical side of knowledge graph SEO, and the core idea behind entity SEO for AI search.

Google’s Knowledge Graph vs your own structured data

People often mix up two different things:

• Google’s Knowledge Graph is Google’s own database of entities. It powers things like knowledge panels. You can’t edit it directly; Google builds it from many sources it trusts.
• Your own brand knowledge graph is the structured data you publish on your website, usually as schema.org JSON-LD. You control it completely.

Your structured data doesn’t force any engine to show particular facts, and no AI company publishes exactly how it weighs sources. What your own graph does is give crawlers a clean, machine-readable statement of the facts, linked to your official profiles. Combined with consistent information elsewhere, that improves the odds that engines resolve your business correctly. Google also states that structured data must match the visible content on the page, so the graph should describe what visitors can actually see.

Which facts should your brand knowledge graph define?

Start with the facts AI assistants are most often asked about. For most businesses, that means:

1. Identity: official name, any alternate names, logo, website URL, founding date, founder.
2. Type: the most specific schema.org type that fits, such as Organization plus a LocalBusiness subtype (Dentist, LegalService, Restaurant and so on).
3. Services: what you actually offer, described in plain language. Service entities and the knowsAbout property can help here.
4. Locations: each physical location with address, telephone, opening hours and areaServed. Service-area businesses should state the areas they cover.
5. People: founders or key staff as Person entities, where they are visible on your site.
6. Profiles (sameAs): links to official profiles you control, such as social accounts, business directories or industry listings. These help engines confirm that those profiles and your website describe the same business.
7. FAQs: short, factual answers to common questions, marked up as FAQPage. Google limited FAQ rich results to well-known government and health sites in 2023, so don’t expect FAQ snippets, but the markup still helps machines read questions and answers.

Write the facts down in one place before touching code. A single source of truth makes it far easier to keep your website, profiles and directories in sync later.

What does a connected JSON-LD graph look like?

Good schema markup for AI is connected, not a pile of separate snippets. Schema.org JSON-LD lets you publish several entities in one @graph and link them with @id values. Each entity gets a stable identifier (usually your URL plus a fragment like #organization), and other entities point to it instead of repeating the details.

Here is a compact example for a fictional Sydney dental practice. It defines the Organization, the WebSite (published by that Organization), and one Dentist location linked back to the Organization as its parent:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.example.com/#organization",
      "name": "Harbour Lane Dental",
      "url": "https://www.example.com/",
      "logo": "https://www.example.com/logo.png",
      "foundingDate": "2015",
      "founder": { "@type": "Person", "name": "Dr. Maya Collins" },
      "sameAs": [
        "https://www.facebook.com/harbourlanedental",
        "https://www.linkedin.com/company/harbourlanedental"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://www.example.com/#website",
      "url": "https://www.example.com/",
      "name": "Harbour Lane Dental",
      "publisher": { "@id": "https://www.example.com/#organization" }
    },
    {
      "@type": "Dentist",
      "@id": "https://www.example.com/locations/sydney/#location",
      "name": "Harbour Lane Dental Sydney",
      "parentOrganization": { "@id": "https://www.example.com/#organization" },
      "url": "https://www.example.com/locations/sydney/",
      "telephone": "+61 2 0000 0000",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "12 Harbour Lane",
        "addressLocality": "Sydney",
        "addressRegion": "NSW",
        "postalCode": "2000",
        "addressCountry": "AU"
      },
      "openingHours": "Mo-Fr 08:00-18:00",
      "areaServed": "Sydney"
    }
  ]
}

A few points worth noting:

• The @id values are identifiers, not pages that must exist. Keep them stable once published.
• The WebSite and the location reference the Organization by @id, so engines can see they all belong to one business.
• Dentist is a LocalBusiness subtype. Use the subtype that matches your business.
• Every fact in the markup should also appear on the visible page. Don’t add details customers can’t see.
• Multi-location businesses add one location entity per branch, each with its own @id, address and phone.

For a deeper walk-through of the individual types and properties, see our guide to Organization and LocalBusiness schema for AI search.

Why does consistency across the web matter so much?

Your structured data is one voice among many. AI engines with web search retrieve pages and cite sources, and those sources include your Google Business Profile, Bing Places, Apple Business Connect, directories, review sites, social profiles and press mentions. If those sources disagree, an assistant may repeat the wrong version or hedge.

Common conflicts include:

• An old phone number still listed on a directory after you switched providers.
• A previous address on one map profile after a move.
• Different business names, such as “Harbour Lane Dental” on the website and “Harbour Lane Dental Clinic Pty Ltd” on a listing.
• A founding year that differs between your About page and a LinkedIn profile.
• Services you stopped offering still described on older pages.

Consistent NAP (name, address, phone) across your website, Google Business Profile, Bing Places, Apple Business Connect and directories helps engines match one business. The same logic applies to every other fact in your graph.

How do you check your knowledge graph for conflicts?

Run a simple audit a few times a year, or whenever something changes:

1. List your canonical facts. Name, type, address, phone, email, website, founding date, founder, services, areas served, official profiles.
2. Check your own site first. Compare the footer, contact page, About page, location pages and existing schema markup. Conflicts on your own domain are the easiest to fix and the most damaging to leave.
3. Validate the markup. Use Google’s Rich Results Test or the Schema Markup Validator to confirm the JSON-LD parses and the @id links resolve as intended.
4. Check each sameAs profile. Make sure each linked profile shows the same name, address, phone and description.
5. Check major directories and maps. Update outdated listings and remove duplicates where the platform allows.
6. Ask the AI engines. Ask ChatGPT, Perplexity, Gemini and Claude questions like “What is [brand]?” and “How can I contact [brand]?”. Note any wrong facts and which sources they cite. If an assistant repeats a wrong fact, our guide on what to do when ChatGPT gets your business wrong covers the next steps.

Answers vary by engine, wording, location and time, so treat a single answer as a sample, not a verdict. Re-check over several weeks to see whether fixes are being picked up.

How Onxeera helps

Onxeera’s Brand Knowledge tool keeps one fact profile for your business: identity, services, locations, profiles and FAQs. It can pre-fill empty fields from your own site, checks your website for missing facts and conflicts, and outputs a connected schema.org JSON-LD graph and a FAQPage block. On Starter and above it also produces llms.txt, key-facts HTML and consistent descriptions you can reuse across profiles. To see whether AI engines are repeating those facts correctly, the AI Reputation tool flags wrong phone numbers, websites, emails or founding years against your Brand Knowledge, with the quote and the sources cited.

Whatever tools you use, the principle is the same: define your facts once, publish them clearly, and make the rest of the web agree with them.

Frequently asked questions

Do I need a Wikipedia page to have a knowledge graph?

No. Your own brand knowledge graph is the structured data on your website, which you fully control. Wikipedia has notability and conflict-of-interest rules, and businesses should not write their own article. Focus on clear schema markup, consistent profiles and accurate directory listings instead.

Will adding JSON-LD guarantee AI assistants describe my business correctly?

No. Structured data gives engines a clean statement of your facts, but no AI company publishes how it weighs sources, and answers vary by engine and time. It improves the odds, especially when your profiles and directories agree with it. Re-check AI answers over several weeks to measure progress.

Where should the JSON-LD graph go on my website?

Most sites place the Organization and WebSite entities in the site-wide template, often on the homepage, and add each location entity on its own location page. Keep the @id values identical everywhere so all pages point to the same entities, and make sure the facts match the visible content.

How often should I update my brand knowledge graph?

Update it whenever a core fact changes, such as a new phone number, address, service or location. Otherwise, a review every few months is sensible. Update your website first, then your profiles and directories, so every source changes in the same direction.