Guide

How to Get a Knowledge Panel

Last updated 26 July 2026

A knowledge panel is not something you apply for. Google states that panels “are created automatically by Google Search Algorithm when there is enough information available on the open web”.¹ That single sentence determines the whole strategy: the work is producing information about you on the open web, not marking up the information you already publish about yourself.

This guide sets out the order to do that in. Order matters more than the individual tactics, because several of the steps people reach for first are gated on steps they have not done yet.

For what the Knowledge Graph is and how panels behave once you have one, see Knowledge Graph and knowledge panels. This guide is the procedure.

Step 1: Diagnose what Google currently recognises

Before doing any work, establish which of three states you are in, because they need different responses.

Search your name or brand while signed out. Then check:

A panel already exists. Skip to claiming it. Go to the panel, select Claim this knowledge panel, and verify through an official property. Everything below is then about strengthening what it contains rather than creating it.
No panel, but Google clearly resolves the entity (a rich set of correct results, correct autocomplete, your official site ranking first for your name). You are close. Step 2 is the gap.
No panel and ambiguous results (your name returns other people, or nothing coherent). This is the common case for individuals and small brands, and it is a longer project.

Which route applies also depends on what kind of entity you are, so check the fork below before working through the steps.

If you are a local business, start with Google Business Profile

A business with a physical location or defined service area has a shorter and more reliable route than anything else in this guide. A verified, complete Google Business Profile produces a business panel directly, and organisations with one tend to be represented far more consistently than those relying on web signals alone.

That route is verification-based rather than corroboration-based, so it does not depend on the coverage described in step 2. Complete the profile fully, keep the name, address and phone number identical everywhere they appear, and treat the rest of this guide as secondary. The steps below are written for entities with no verification route available: creators, publishers, consultants, and organisations without premises.

The Knowledge Graph Search API trap

A widespread diagnostic mistake is querying the Knowledge Graph Search API (directly or through a third-party tool), finding a machine ID such as /g/11xy2z3abc for your name, and treating it as evidence that Google recognises you.

It is not. The API and knowledge panels are different systems, and Google’s own developer documentation warns that the API “is not suitable for use as a production-critical service”.² It is legacy, superseded by Cloud Enterprise Knowledge Graph, which issues its own identifiers.³

Querying a shared or common name tends to return several Person entities for it, often with no description, URL or detailed description on any of them. Those are not duplicate entities waiting to be merged. They are a string that resolves to nothing, recorded more than once. Empty records cannot be consolidated, because there is nothing in them to consolidate. The objective is attributes attached to one entity, not the selection of an identifier.

The same reasoning applies to pointing sameAs at a google.com/search?kgmid= URL. It is a practitioner convention rather than documented behaviour, it is harmless, and it is not the constraint.

Step 2: Build third-party corroboration

This is the step that actually moves the outcome, and the one most often skipped in favour of markup.

Google builds the Knowledge Graph from “a variety of sources that compile factual information”, in addition to licensed data.¹ The operative requirement is independence. Anything on a domain you control is you asserting an identity, not a source corroborating one. If you run two sites, neither counts as a third party for this purpose, regardless of how good the structured data is.

Publishing more of your own content does not fix this. Two hundred articles on your own site prove you write about a subject. Not one of them is a source stating that you are an expert in it. The distinction between publishing and being written about is the entire step.

What produces genuine corroboration, roughly in order of value:

Author bio pages on publications you do not own. A byline on an established industry publication creates a page about you, on an authoritative domain, with a consistent name and bio. This is the highest-value asset available to most practitioners.
Podcast and interview appearances. Each episode page is another independent description of who you are.
Conference and webinar speaker pages. Event sites are well-crawled and describe speakers in a consistent, structured way.
Being quoted in industry coverage. Expert quote requests and journalist sourcing produce named mentions in editorial contexts.
Structured databases. Muck Rack for people who write, Crunchbase for organisations. These are compiled reference sources of exactly the type Google draws on.

Keep the name format, bio, and linked site identical everywhere. Corroboration works by consistency: three sources describing the same name, role and canonical URL do more than six describing variants of them.

Step 3: Add structured reference entries

Only once step 2 has produced references does this become possible, which is why it is third rather than first.

Wikidata has a materially lower bar than Wikipedia. An item qualifies if it “refers to an instance of a clearly identifiable conceptual or material entity that can be described using serious and publicly available references”.⁴ The phrase doing the work is serious and publicly available references. Without step 2 you have none, and items that fail notability are removed following a community deletion request.⁴

Two cautions. Wikidata maintains a separate autobiography guideline, so creating your own item is the wrong approach: an item should follow from coverage existing, ideally created by someone else. And do not attempt a Wikipedia article unless you genuinely meet its notability criteria. Failed attempts are deleted, and the attempt is publicly visible.

Step 4: Make your own signals consistent

Your structured data is the last step, not the first. It cannot manufacture recognition, but it does help Google reconcile evidence it has already gathered.

One canonical entity home. A single page that is unambiguously about the entity, with a stable @id, referenced from everywhere else.
sameAs pointing only at profiles that genuinely identify the same entity: LinkedIn, GitHub, and authoritative profiles. See the modelling warning below.
Consistent authorship across everything you publish, in the same name format.
Organisation schema with name, logo, founding date, and founder for a publication or business.

Do not put your own publication in a Person’s `sameAs`

A common and self-defeating error. sameAs asserts identity: it says the subject and the target are the same thing. If you run a named publication that is a distinct entity in its own right, listing its URL in your personal sameAs tells Google the person and the publication are one entity, which is the exact ambiguity you are trying to remove.

Model the relationship structurally instead. Organization.founder pointing at the Person, and Person.worksFor pointing at the Organization, states that two entities exist and how they relate. That is a stronger and more accurate claim than collapsing them.

Which entity should you target?

Worth deciding deliberately rather than defaulting to a Person panel.

Target the entity that independent sources actually describe. For a consultancy whose founder does the speaking and writing, that is the person. For a company whose coverage names the business rather than its staff, it is the organisation. Corroboration accrues to whichever name appears in those sources, so pick the one already being written about rather than the one you would prefer.

Name distinctiveness is a secondary factor worth weighing. Disambiguation is part of the problem Google is solving, so a widely shared personal name competes against everyone else who has it, while a distinctive company name does not. Where a founder’s name is common and the business name is not, the organisation is usually the shorter path.

The two are not in competition. An Organization panel that names its founder builds the Person entity as a side effect.

What not to bother with

Repeatedly tuning schema. If your markup is already valid and consistent, more of it will not trigger a panel. Markup is not the constraint.
Paid directory listings bought for entity signals. Compiled reference sources help; low-quality directories do not.
Selecting or aligning to a machine ID. See step 1.
Requesting a panel. There is no submission route. Google is explicit that when and whether a panel appears “happens automatically and isn’t something we can or would influence”.¹

Realistic expectations

This is a programme measured in months, driven by genuine industry presence rather than technical work. For an individual practitioner without editorial coverage, a panel may not arrive at all, and a shared name makes it harder still.

That is worth knowing before you start, because it changes what you should optimise for. The corroboration built in step 2 improves author credibility, E-E-A-T signals, and citation likelihood in AI-generated answers whether or not a panel ever appears. Those returns are reliable. The panel is a visible confirmation of entity recognition, not the reason to do the work.