Knowledge Graph Engineering – Entity SEO & Semantic Brand Authority

Entity audit – what I check first

An entity audit answers one question: what do Google and AI models “know” about your brand today, and where did they learn it? Before changing anything I collect the picture from several places at once, because each one shows a different layer of the same problem.

I treat the Knowledge Graph Search API with care. Google's documentation describes it as a read-only API that returns individual entities without the connections between them, and says it is not suitable as a production-critical service. So I use it as an indicator (does the entity exist, how is it described, does that change over time), not as an oracle.

Questions I ask AI assistants

1. What does [brand] do? (checks category and description)
2. Who founded [brand] and who runs it? (checks people)
3. Where does [brand] operate and since when? (location, date)
4. Which companies offer [service] in [city or country]? (does the brand appear in recommendations)
5. [brand] or [competitor] – what's the difference? (what the model associates the brand with)

I ask each question several times, because a single model answer is random. The method is described in the AI visibility audit, which I often run alongside this service.

The brand fact sheet – one source of truth

The fact sheet is a table in which every fact about the brand has one approved value, a source that confirms it and a list of places where it appears. It is the most important output of the audit, because every later step (About page, JSON-LD, Wikidata, profiles) copies values from this sheet rather than from memory.

Every fact gets a status: confirmed, conflicting (with a list of places showing a different value) or missing. The list of conflicts is a ready-made correction plan, ranked by how much each source matters to Google and to AI answers.

Entity home – the page that defines the brand

The entity home is one page on your site, usually About, that presents every fact from the sheet in a form readable by people and machines. Other sources should confirm it, and it should link to them.

I design it as a fact page, not a brand-image page. A typical layout:

• The first paragraph is the description from the fact sheet: name, what you do, for whom, where and since when.
• People by name, with their role and a link to their profiles or author pages.
• Company details in the footer or a separate block: legal name, registration and tax numbers, address.
• Specialisms named plainly, in the same words you use in your offer and profiles.
• External confirmation: publications, talks, awards, linked to their sources.
• Links to official profiles that users can see, not just hidden in the code.

Google's Organization structured data documentation recommends placing the markup on your home page or on a single page that describes your organisation. I pick one of those as the entity definition and only reference it from every other page.

The JSON-LD graph – Organization, Person and WebSite linked by @id

A JSON-LD graph is a set of structured data in which every entity (company, person, website) has a stable @id, is defined once, and other pages and entities refer to it. The whole site then describes one consistent company rather than dozens of unconnected things.

Properties I fill in

Google's Organization documentation (updated September 2026) has no required properties but recommends, among others, name, alternateName, legalName, url, logo, description, address, contactPoint, sameAs, foundingDate, numberOfEmployees and the identifiers vatID, taxID, iso6523Code and naics. It says the last two help distinguish your organisation from others, and that logo helps Google pick the logo shown in results and knowledge panels.

This site is built that way: one Person entity with the ID https://wiszniewsky.pl/#person and a business entity that point to each other (founder and worksFor), with a Wikidata item among the person's sameAs links. Blog posts don't redefine the author; they reference that @id. Google's author guidance for Article is simple: list each author separately, put only the name in author.name, and use author.url or sameAs to point to a page that identifies the person.

An important limit: Google's documentation on AI features in Search says no special markup is needed to appear in AI Overviews or AI Mode. The JSON-LD graph is not a ticket in, just a machine-readable version of facts that are already on the page. I implement it directly in code, as in my Schema.org implementation service, and cover types and syntax in the structured data guide.

sameAs – which profiles to add and which to leave out

I only add URLs to sameAs that unambiguously identify the same brand or person and that the brand controls or that are recognised knowledge bases. schema.org defines sameAs as the URL of a page that unambiguously indicates the item's identity, so every wrong link weakens the entity instead of strengthening it.

Wikidata in practice – criteria and risks

A Wikidata item makes sense when the brand meets the inclusion rules and serious public sources describe it. Without that the item gets nominated for deletion, and attempts to force it through stay visible in the edit history.

Wikidata's notability policy lists three criteria, and meeting one is enough: the item has a sitelink to a page in a Wikimedia project (such as Wikipedia), it refers to a clearly identifiable entity that can be described using serious and publicly available references, or it fulfils a structural need by making statements in other items more useful. Companies without a Wikipedia article usually rely on the second criterion, which is why I prepare the sources before creating the item.

• Sources that work as references: a registry entry, articles in trade or local media, publications, award announcements.
• Weak sources: your own site as the only confirmation, press releases reprinted without editing, social profiles.
• The item description should distinguish the entity from others with the same name (e.g. “Polish software company, Białystok”), not advertise it.
• Closing the loop: the item points to the official website, and the site adds the item URL to sameAs.

Step-by-step instructions, with properties and order, are in Wikipedia, Wikidata and the Knowledge Panel. I don't edit Wikipedia on clients' behalf: it's conflict-of-interest territory, and the only honest thing I can do is help earn the independent sources an article could one day be based on.

The knowledge panel – how to claim and correct it

You can't order a knowledge panel or “submit” one through Search Console. It appears when Google has enough confirmed information about an entity, and only then can you claim it and suggest changes.

According to Google's help pages, the process looks like this:

1. Search for the brand or person and find the knowledge panel.
2. At the bottom of the panel (sometimes in the About section) click “Claim this knowledge panel”.
3. Sign in to one of the official accounts Google lists, such as YouTube or the site's Search Console. If Google can't link any account, it asks for more information to verify your identity.
4. Once verified, suggest changes through Feedback: flag the specific fact, describe what should change and add links that support it.
5. A verified owner can add other people to manage the panel.

Search Console is only one of the verification routes here. That's why, during implementation, I make sure the site is verified in Search Console on an account the company controls and the official YouTube channel is listed in sameAs. It shortens the path once a panel appears.

Person entities – founders, experts and authors

In many companies, especially service and expert businesses, the founder is the most recognisable entity. A model asked “who is an expert in [topic]” looks for people, not just companies, so I treat Person entities as part of the same job.

• An author or expert page on the site with a bio, specialism, photo and profile links.
• Person in JSON-LD with one @id, linked to the company via worksFor and founder.
• A consistent byline across articles, interviews and talks: the same name, the same role.
• External profiles (LinkedIn, author pages in the media) with the same description and a link to the company site.

How to build an expert's recognition in AI answers is covered in Expert Personal Brand in the AI Era. The service includes key people if we agree on that at the start, because the number of people drives part of the cost.

Hard cases – rebrands, mergers and names shared with another company

The most work goes into situations where brand data is not just incomplete but contradictory by definition: a name change, a merger, or a name someone else also uses.

When the domain changes, the entity is only one piece. If a rebrand includes a new site address, I combine this work with an SEO migration so you don't lose rankings while tidying the data. If a model keeps repeating false information, see what to do when ChatGPT says something untrue about your company.

Linking the brand to topics – mentions that build the entity

An entity that is recognised but not associated with any topic won't make it into recommendations. The second goal of this service is to connect the brand name with the categories you want to be recommended for.

I do it in three ways: consistently tying the name to topics on your own site (description, specialisms, knowsAbout in structured data), making sure external profiles describe the same specialisms, and planning mentions in places that write about your category. The mention plan is part of the deliverables, but actually earning coverage is separate work, described in LLM citation strategy and in the article on digital PR and brand mentions.

A full path from entity architecture through content to coverage in trade media is shown in the fashion brand case study, where searches for the brand name grew from 840 to 2,350 a month.

How I measure progress in building the entity

I measure progress with a fixed set of indicators, checked before implementation and then monthly, rather than with a single screenshot of the knowledge panel.

For testing AI answers I use my own tool described in the AnswerLyzer case study, which scores model answers with an LLM-as-a-judge method. A manual version of this measurement is in the article on the AI visibility audit.

Timeline – what depends on me and what depends on Google and AI models

Part of the work has a predictable timeline because I do it myself. The rest depends on when Google reprocesses the pages and when external sources and models pick up the changes, and nobody can honestly guarantee that date.

This service is part of broader GEO, or AI search optimisation. If you're not sure where to start, I usually suggest the visibility audit first, because it shows whether the problem is the entity, the content or a lack of mentions.