The Wikidata SOP: How We Tune Entities for Google Knowledge Panels and LLM Citations (With Real Before-and-After Data)

Most people think claiming a Knowledge Panel is the finish line. It’s not — it’s barely the starting line.

I learned this the hard way when Trenton Sandler reached out to me. He’s a D1 distance runner at LSU with 43,800 YouTube subscribers, 34,400 Instagram followers, and 37,800 TikTok followers. He claimed his Knowledge Panel. His confidence score in our Knowledge Graph Explorer is 497 — which is actually quite high. But when you Google “Trenton Sandler”… nothing. No Knowledge Panel appears on the right side. Just ten blue links.

Yet when you go directly to his Knowledge Graph entity via his KGMID (/g/11trgmfjns), the panel renders beautifully — photos, social profiles, recent TikTok and YouTube content. Google knows who he is. It just doesn’t trust that knowledge enough to show it.

This is the entity gap — and it’s the same gap that’s holding back most personal brands, businesses, and creators from showing up properly in both Google and in LLM results (ChatGPT, Claude, Gemini, Perplexity). The fix isn’t magic. It’s structured data hygiene — and it starts with Wikidata.

Why Wikidata Matters More Than You Think

Here’s what most SEOs miss: Wikidata isn’t just a Wikipedia side project. It’s one of the primary structured data sources that feeds directly into Google’s Knowledge Graph. It’s also increasingly used by large language models for entity grounding — when ChatGPT or Perplexity tries to answer questions about a person, a well-structured Wikidata entry with properly referenced claims makes that person far more likely to be accurately represented in AI outputs.

Think of Wikidata as the structured backbone that helps machines understand who someone is, not just that they exist. Every claim on Wikidata — your occupation, your employer, your social profiles, your date of birth — is a node in a giant knowledge web that Google, Bing, Apple, and every AI system reads.

When I talk about entities and trust in Google’s system, this is exactly what I mean. Your entity is the sum of how many authoritative sources corroborate the same facts about you. Wikidata is where you wire those facts together in a format machines can read.

The Real Data: Where Our People Stand Right Now

I audited the Wikidata and Knowledge Graph status for a group of people we work with. Some are apprentices, some are clients, some are friends. This is the baseline — we’re publishing it now so we can come back in a few months and measure the before-and-after impact of following this SOP.

Here’s where everyone stands as of February 21, 2026:

Trenton Sandler — Has a Knowledge Graph entity (confidence score: 497, KGMID: /g/11trgmfjns). Has a Wikidata entry (Q136384612). But the Wikidata entry is thin — nearly every claim references a single source (lsusports.net), two key claims (“instance of: human” and “sex or gender: male”) have zero references, and he’s missing his World Athletics ID (15141450), country of citizenship, the “educated at” property, X/Twitter identifier, and TikTok numeric user ID. Zero Wikipedia sitelinks. No Wikipedia article exists. No personal website with Schema.org markup. His Knowledge Panel exists but does not display on a standard name search.

Dennis Yu (me) — I have a Knowledge Graph entity, but my situation illustrates a different problem: entity disambiguation. When you search “Dennis Yu” in our Knowledge Graph Explorer, 13 different entities come back — all with a confidence score of just 24. There’s a Hong Kong film director named Dennis Yu (Q5259089) who has the stronger Wikidata entry. My Wikidata entry (Q12246156) lists my occupation as “television presenter” — imported from Cantonese Wikipedia — which isn’t exactly how I’d describe what I do. My entry has my KGMID (/g/11pv0w_d02), my partnership with Ben Fife, “educated at: UC Berkeley,” and my Instagram handle. But it’s missing YouTube, TikTok, LinkedIn identifiers, proper occupation descriptions, and references from diverse sources. I have Wikipedia articles but only in Cantonese and Chinese — not English. Even I have work to do.

Brennan Agranoff — Has a Knowledge Graph entity (confidence score: 129, KGMID: /g/11f10l8pht). But no Wikidata entry exists at all. That means all of his entity signals are coming purely from web mentions — there’s no structured data backbone connecting his identity across sources. Creating a Wikidata entry for him would be the single highest-impact action.

Dan Leibrandt — Zero Knowledge Graph results. No Wikidata entry. Google doesn’t even recognize him as a distinct entity yet. He’s starting from true zero, which is actually the most common situation. Everything needs to be built from scratch.

George Paladichuk — Same as Dan. Zero Knowledge Graph results, no Wikidata entry. Invisible to Google’s entity system.

Dylan Haugen — Zero Knowledge Graph results, no Wikidata entry.

Marko Sipila — Zero Knowledge Graph results, no Wikidata entry. There is a Finnish writer named Marko Sipilä (Q61104458) with a Finnish Wikipedia article, which creates a potential disambiguation issue — but for now, Google’s Knowledge Graph doesn’t have our Marko at all.

The Wikidata Tuning SOP: Step by Step

This is the exact process we follow — first manually with our agents, then as an AI-assisted workflow, and eventually as part of our automated dashboard. The goal is to make every entity on Wikidata as rich, referenced, and connected as possible so that Google and LLMs can’t ignore it.

Phase 1: Audit the Current State

Before you touch anything, you need to know what you’re working with. Open three tabs.

First, go to our Knowledge Graph Explorer and search the person’s full name. Write down the confidence score, KGMID, and how many entity results come back. If multiple results appear (like my 13 Dennis Yu entries), note which one is the correct entity. If zero results come back, the person doesn’t exist in Google’s Knowledge Graph yet.

Second, search for the person on Wikidata. If they have an entry, open it and inventory every claim — what properties exist, how many references each claim has, and what identifiers are present. If no entry exists, that’s your first action item.

Third, Google the person’s name and screenshot the results. Does a Knowledge Panel appear? What shows up in the organic results? This is your visual baseline.

Record all of this. We want to come back in 60–90 days and measure what changed.

Phase 2: Create or Enrich the Wikidata Entry

If no Wikidata entry exists, create one. If one exists, we’re going to make it substantially better. Here’s what a strong Wikidata entry for a person needs:

Core identity claims — “instance of: human” (with a reference), “sex or gender” (with a reference), given name, family name, and a clear English description. These seem obvious, but I audited Trenton Sandler’s entry and found “instance of: human” had zero references. Google’s algorithms notice this kind of thing.

Biographical facts — Date of birth, place of birth, country of citizenship, languages spoken. Each one should have at least one reference, and ideally two from different sources. For Trenton, his LSU sports profile corroborates his DOB — but a second reference from World Athletics or a media article strengthens it.

Professional claims — Occupation (be specific — not just “athlete” but the specific sport discipline), employer or affiliation, “educated at” linked to the university’s Wikidata item, “member of sports team” for athletes, field of work for professionals. Each of these creates connections to other well-established entities in the Knowledge Graph.

Identifiers — This is where most people leave massive value on the table. Wikidata has properties for nearly every platform: Instagram username and numeric ID, TikTok username and numeric user ID, YouTube handle and channel ID, X/Twitter username, LinkedIn personal profile ID, Facebook profile ID. For athletes specifically: World Athletics ID, TFRRS athlete ID. For business people: Bloomberg person ID, Crunchbase organization ID. For anyone with media presence: Spotify show ID, Apple Podcasts show ID, IMDb ID. Every identifier you add creates another machine-readable link between the Wikidata entity and a verified profile elsewhere on the internet.

The Google Knowledge Graph ID itself — Yes, you can add the person’s KGMID as an identifier on Wikidata (property P2671). This explicitly connects the Wikidata entity to the Google Knowledge Graph entity, which tightens reconciliation.

Phase 3: Diversify Your References

This is the single most overlooked step. Trenton Sandler’s entire Wikidata entry cites one source: his LSU sports profile. That’s like building your resume with only one reference. Google wants corroboration from multiple independent authoritative sources.

For each claim on Wikidata, try to add references from at least two different domains. For an athlete like Trenton: his World Athletics profile can corroborate his sport, nationality, and birth year. His TFRRS profile can corroborate his university and performance stats. Athletic.net can corroborate his high school career. His verified social media profiles corroborate his identity. Media articles from RaceRaves, the Hey Fightin’ Podcast Network, or the Runner’s Life Newsletter can corroborate specific achievements.

For a business person: company website about pages, conference speaker bios, LinkedIn profiles, published articles or books, podcast appearances, press mentions, industry directory listings. The more independent sources that say the same thing about someone, the stronger the entity.

This is the same principle behind how Knowledge Panels get triggered — Google needs to see consensus from authoritative sources before it’s willing to display a panel.

Phase 4: Connect the Schema Markup

Wikidata is one side of the equation. The other side is having a personal website or entity home with proper Schema.org Person markup that points back to Wikidata and all the same profiles.

The JSON-LD on the person’s website should include @type: Person, their name, description, jobTitle, worksFor, alumniOf, birthDate, and critically — a sameAs array that lists every verified profile URL including: their Wikidata URI (https://www.wikidata.org/wiki/QXXXXXXX), YouTube channel URL, Instagram profile, TikTok profile, LinkedIn URL, Twitter/X URL, and any other authoritative profiles. This creates a closed loop: Wikidata points to the website via “described at URL,” and the website points back to Wikidata via sameAs. Google loves closed loops.

If someone doesn’t have a personal website — like several of our apprentices — a Linktree or about.me page with proper meta tags is a stopgap, but it’s not a replacement. You want a domain you control with proper structured data. We cover this more in our Knowledge Graph API guide.

Phase 5: Monitor and Iterate

After making Wikidata edits and deploying Schema markup, check the Knowledge Graph Explorer confidence score weekly. It won’t change overnight — Google re-crawls and reconciles entities on its own schedule, typically every few weeks to a few months.

What you’re watching for: confidence score increases, new information appearing in the Knowledge Panel (when accessed via KGMID), and eventually — the panel starting to trigger on standard name searches. When that happens, you’ve crossed the trust threshold.

We also recommend periodically checking what LLMs say about the person. Ask ChatGPT, Claude, and Perplexity questions like “Who is [Name]?” and “What does [Name] do?” The accuracy and detail of those answers will improve as entity signals strengthen — because these models pull from many of the same structured sources.

Why This Matters for LLM Citations

We’re in a moment where search is fragmenting. People still Google, but they’re also asking ChatGPT, using Perplexity, and getting answers from Gemini. The common thread is entities. All these systems need to resolve “who is this person?” before they can answer questions about them. Wikidata is one of the few structured sources that all of them reference.

If you’re not in Wikidata with proper claims and references, you’re invisible to a growing percentage of how people find information. If you are in Wikidata but your entry is thin (like Trenton’s single-source problem), the information AI systems have about you will be thin too — or worse, wrong.

As I’ve discussed with Darby Rollins, AI tools pull from search engine signals and Google organizes content using structured data. Both rely on the Knowledge Graph. Strengthening your Wikidata entry is strengthening your presence everywhere at once.

Making This a Repeatable Process

This SOP breaks into three levels of execution, which maps perfectly to how we scale everything at BlitzMetrics — start with agents doing it manually, then layer in AI assistance, then automate into the platform.

Level 1: Manual agent execution. A trained agent can follow the five phases above step by step. The audit takes about 20 minutes per person. Creating or enriching a Wikidata entry takes 30–60 minutes depending on how much research is needed to find proper references. Schema markup deployment depends on whether the person has a website. A agent can process 4–6 people per day through the full SOP.

Level 2: AI agent assisted. An AI agent can handle Phase 1 (audit) almost entirely — searching the Knowledge Graph Explorer, pulling Wikidata entries, generating a gap analysis. It can draft Wikidata claims with proper reference formatting. It can generate the JSON-LD Schema markup. The human reviews and submits. This cuts the time per person roughly in half.

Level 3: Integrated dashboard automation. The end state is a tool in our dashboard that takes a person’s name and website URL, automatically audits their Knowledge Graph status, scans their Wikidata entry for gaps, checks their website for Schema markup, and generates a prioritized action list. The automation handles the audit and generates the edits — a human clicks “approve” to submit them. This is where we’re headed.

The Trenton Sandler Action Plan

Since Trenton’s case is what sparked this whole investigation, here’s the specific action plan for getting his Knowledge Panel to display on a standard name search:

First — add his World Athletics ID (15141450) to Wikidata immediately. Add country of citizenship (United States). Add “educated at: Louisiana State University.” Add his X/Twitter identifier. Add TikTok numeric user ID. Add Google Knowledge Graph ID (/g/11trgmfjns). These are quick wins that can be done in 15 minutes.

Second — add references from at least two additional sources. His World Athletics profile and TFRRS profile can corroborate many of the claims that currently only cite LSU. Add references to “instance of: human” and “sex or gender: male” so they’re not sitting at zero.

Third — he needs a personal website. A simple site at trentonsandler.com with an about page, his bio, and JSON-LD Person schema that includes sameAs links to all his profiles. This gives Google a canonical entity home.

Fourth — pursue editorial coverage. He has a Guinness World Record (3-legged mile with his roommate Hugh Carlson), he’s an NIL athlete doing brand deals, and he’s a D1 runner creating content about the athlete experience. These are all pitchable stories to running publications, sports media, and NIL-focused outlets. As I’ve explained in our Knowledge Panel claiming walkthrough, independent editorial coverage is what ultimately pushes an entity over the display threshold.

Timeline expectation: if he does the Wikidata and Schema work now and continues building editorial mentions, the panel could start triggering on name searches within 2–4 months.

We’ll Be Back With the Results

Here’s what makes this article different from the usual SEO advice — we’re putting real names, real data, and real numbers on the record. In a few months, we’ll come back and update this post with the new confidence scores, new Wikidata entry status, and whether Knowledge Panels are showing for each person.

That’s the test. If structured data hygiene on Wikidata actually moves the needle — and I believe it will — the numbers will show it. And if there are things that don’t work as expected, we’ll share that too. That’s how we operate — show the real data, explain what happened, and adjust.

If you want to check your own entity status, start with our Knowledge Graph Explorer. Search your name. If you see a confidence score, you’re on the map. If you don’t, Wikidata is where you begin.

And if you want help building this out — whether you’re an athlete like Trenton, a business owner, or a creator building your personal brand — this is exactly the kind of structured entity work we do at BlitzMetrics. We’ve done it for hundreds of Knowledge Panels, and now we’re systematizing it so AI agents and dashboards can do the heavy lifting.

The future of SEO isn’t keywords. It’s entities. And entities start with Wikidata.