# Wikidata Entry for a Person: Check, Fix, or Skip It

A Wikidata entry for a person is a structured fact record, not a profile. How to check yours, what belongs in it, how to fix a wrong one, and when to skip.

---


A Wikidata entry for a person is an item: a numbered record in a public database that holds short, structured facts about you, such as your occupation, employer and links to other databases, each of which can carry a source. It is not a biography and not a profile you control. Anyone can edit it within community rules, and an item only stays if the person meets Wikidata's notability policy.

Most pages on this topic treat Wikidata as a ranking trick: create an item, add a few links, wait for a knowledge panel. That framing skips the questions that decide whether it helps you. Do you already have an item, and is it correct? Is it you, or someone with your name? Do the facts in it have sources? And are you the right person to be editing it? This guide is organized around those questions, in the order you would ask them.

It sits next to the guides on Wikipedia and knowledge panels, so I will not repeat how those work. The one overlap that matters: Wikipedia is a separate project with its own notability and conflict-of-interest rules, and a Wikipedia article usually has a linked Wikidata item, but the reverse is not true. A person can have an item without an article. This guide is information, not advice. Wikidata's policies are community pages that change, and the policy pages could not be reopened for this verification pass, so I describe them in general terms and point you to the live page each time. Read it before you act.

<div class="box"><b>The short version</b>
<ul><li>Wikidata is a free structured database. Each person is an item with a Q-number, and facts are statements that can carry references.</li><li>First check whether an item exists and describes the right person. For many people the real work is fixing, sourcing or merging an item, not creating one.</li><li>Wikidata has a policy for living people that centers on privacy and on sourcing anything likely to be challenged. Read it before you raise or edit anything.</li><li>No source read for this guide says that an item produces a knowledge panel, so treat the link as plausible, not promised.</li><li>If you are the subject or are paid to help, do not rewrite your own item. Raise corrections on the project's discussion pages, disclose your role and keep every change sourced.</li></ul></div>

## What a Wikidata item for a person actually is

An item is a record with a unique identifier, a Q followed by digits, a label, a short description and any number of statements. Wikidata is a multilingual knowledge graph run by the Wikimedia Foundation, and its data is released under CC0, a public domain dedication that lets anyone reuse it, which is why so many other services can read it.

Each statement is a property and a value: "occupation" and "photographer", for example. A statement can have qualifiers that add context, such as the start and end of a position, and it can carry references, the sources that support it.

That structure is the whole point. A Wikipedia article is prose that a person reads. A Wikidata item is data that a program reads. When a search engine, an AI assistant, a library catalog or a mapping tool needs to know which "Alex Morgan" a name refers to, a short list of unambiguous facts is easier to use than a paragraph. The identifier does the disambiguating: two people with the same name have two different Q-numbers.

Three things follow for you:

- **The label is a name, not a headline.** The label is the name the person is commonly known by, and other names go in aliases. Titles, taglines and credentials do not belong there.
- **Descriptions disambiguate, they do not promote.** A description such as "American photographer" does a job. "Award-winning visionary photographer" does not belong.
- **Everything is public and reusable.** There is no private view and no approval step for facts about you. Anyone who can edit can add a statement, and anyone downstream can copy it.

## How to check whether you already have an entry

Search before you do anything else. Use the search box on wikidata.org with your name as it is most commonly written, then repeat with variants: with and without a middle name, with a maiden name, in the spelling used in another language. An existing item shows its label, its description and its Q-number in the results.

When you open an item, read it the way a stranger would. These are the checks worth making, in order:

1. **Is it the right person?** Check the description, the birth year if present, the occupation and any link to a known employer. Same-name confusion starts here. If the item describes someone else, that is a different problem from an incomplete item.
2. **Is each statement correct and current?** Employment, residence and titles go stale quickly. A statement can be true historically and still mislead if nothing shows it has ended.
3. **Does each statement have a reference?** Look for the reference line under a statement. Unsourced statements are the easiest to challenge and the easiest to get wrong.
4. **Are there sensitive statements?** Health, family members, home location and similar details about a living person deserve a close look against the living people policy, covered below.
5. **Is there a second item?** Two items for one person is a common fault, and a merge is the usual fix.

You can also read an item as raw data. Wikidata publishes each item in machine-readable formats such as JSON, which lets you see exactly what a machine sees. If you script that, follow the project's rules for automated access, including identifying your tool and backing off when the server asks you to slow down.

If you find nothing, that is information. It may mean you have no item, or that the search did not match your name. Do not conclude anything from absence alone, and do not create an item yet. The next two sections decide whether you should.

## Does Wikidata feed a knowledge panel or an AI answer

Possibly, but no source I could read says how much. Google's [help page on knowledge panels](https://support.google.com/knowledgepanel/answer/9163198) is the primary source for how panels are fed and for how a verified person can suggest changes. Read it for its current list of sources. I make no claim that it does or does not name Wikidata, because I could not reopen it in this pass.

There is history behind the belief that Wikidata matters to search. Google has publicly tied itself to the project in the past, and many services read Wikidata because it is open. Some practitioners have reported panels appearing after an item was created, but those accounts are single cases told by the people who did the work. They are a reason to take Wikidata seriously, not evidence of cause, and I do not rely on one here.

What I can say from experience, as observation and not a statistic, is that a correct, sourced item is cheap insurance against a particular failure: an assistant or a data service confusing you with a namesake because no structured record separates you. A wrong item is the opposite, since errors in public structured data tend to be copied. I cannot point to a measurement of how often search engines or AI assistants read a given person's item, and nobody should sell you one.

<aside class="callout">
<span class="callout-label">Limit</span>
<h4>An item is evidence, not a switch</h4>
<p>No source read for this guide describes Wikidata as a way to request a knowledge panel. Any provider promising a panel in return for an item is promising something the sources do not support.</p>
</aside>

## Whether you qualify: Wikidata's notability test

Wikidata does not accept an item for everyone. The notability policy sits at [Wikidata:Notability](https://www.wikidata.org/wiki/Wikidata:Notability). That page could not be read for this guide, so I will not quote its criteria or say which routes into the database it lists. Read it before you create, or ask anyone else to create, an item.

What I can offer is a practical way to sort cases, built on ordinary reasoning rather than the policy text. An item about a person is easier to defend when the person is identifiable, meaning someone could tell them from anyone else, and when serious public references exist about them: sources you did not write and a reader can open. Whether a given item passes is for the policy and the community to decide, not for me.

In practice, people tend to fall into three groups:

- **Clearly covered.** The person has independent coverage, a Wikipedia article, or entries in established databases such as an academic, sports or film record. An item probably exists already. Your job is to check it.
- **Borderline.** The person has some independent mentions but not much. An item might survive, or might be nominated for deletion. Creating one is a risk with little upside.
- **Not covered.** The person has only self-published pages and social profiles. An item would likely be challenged, and a deleted item can leave a record of the attempt.

Notice what this means for a founder or an executive with a thin press footprint. The thing to fix is the footprint, which means independent coverage and consistent facts on pages you own, not the database. The Wikidata decision follows from it.

## Decision table: what to do by situation

The right move depends on whether an item exists, whether it is accurate, and whether you are likely to qualify. This table sorts the common situations. The "your role" column matters because of the conflict-of-interest points later in the guide.

<div class="tablewrap"><table><thead><tr><th>Situation</th><th>Best move</th><th>Your role</th><th>Main risk</th></tr></thead><tbody>
<tr><td><strong>Item exists, correct and sourced</strong></td><td>Leave it. Note the Q-number and link it from your own site</td><td>Observer</td><td>Letting it go stale</td></tr>
<tr><td><strong>Item exists, a fact is wrong</strong></td><td>Propose a sourced correction, or ask on the project chat</td><td>Requester, not editor of record</td><td>Reverted edit, looks like self-promotion</td></tr>
<tr><td><strong>Item describes a namesake</strong></td><td>Do not edit it toward you. Make sure your own facts are clear on your site</td><td>Observer</td><td>Mixing two people</td></tr>
<tr><td><strong>Two items for you</strong></td><td>Ask for a merge, following the merge help page</td><td>Requester</td><td>Merging the wrong pair</td></tr>
<tr><td><strong>Item holds a private detail</strong></td><td>Report it under the living people policy</td><td>Subject</td><td>Repeating the detail in public</td></tr>
<tr><td><strong>No item, strong independent coverage</strong></td><td>Wait for an independent editor, or ask on the project chat</td><td>Subject or agent with disclosure</td><td>Conflict of interest</td></tr>
<tr><td><strong>No item, thin coverage</strong></td><td>Skip Wikidata. Build coverage and an owned page first</td><td>Not applicable</td><td>Deletion request</td></tr>
</tbody></table></div>

## What a sound item contains, and what to leave out

For a person who qualifies, a sound item is short. It has a label, a description, a few aliases, and statements that are specific and sourced: occupation, employer or affiliation with dates where known, a link to the person's official website, and identifier statements that point to other databases that already describe them. Identifier statements are the quiet workhorses, because they tie the item to records elsewhere and help a data service decide that two records are the same person.

Dates need their qualifiers. Use start and end times where a position has ended, so that a former job does not read as a current one. The statement carries the position, and the qualifiers carry the period.

Sources matter more than count. A reference should be a page a stranger can open and that you did not write: a news article, a registry, an institutional page. A statement whose only support is your own site is weak, and one supported by nothing is exposed.

### What to leave out

Wikidata has a policy page for living people at [Wikidata:Living people](https://www.wikidata.org/wiki/Wikidata:Living_people). I could not reopen it for this pass, so I do not quote it. The general shape of such policies is well known: privacy matters more for private individuals than for public figures, contentious claims need a reliable source, and unsourced material about a living person can be removed. Check the live page for its exact wording.

For you, that gives a useful default: if a fact would be awkward to see copied into an AI answer, ask whether it needs to be in a public database at all. Home city, family members, health and exact birth dates are the usual candidates. If an item holds one and you did not publish it, raise it through the channels the policy names, and do so without repeating the detail in the discussion.

<aside class="callout">
<span class="callout-label">Rule</span>
<h4>Source the fact or do not state it</h4>
<p>A statement about a living person with no reliable reference is the one most likely to be removed, and the one most likely to be wrong. Add the source in the same edit, or leave the statement out.</p>
</aside>

## How to fix a wrong, duplicate or mixed-up item

Fixing an item is more common than creating one, and it follows a sequence. Work from the cheapest route to the heaviest.

### A wrong or stale fact

Start with a sourced correction. If you are the subject, the most reliable approach is to put the correct fact, with a source, in front of an independent editor rather than change your own record. Wikidata has a project chat page where items, policy and technical issues are discussed, and requests for help belong there. State the item's Q-number, the statement, what is wrong, and the source. Keep it factual and short.

### A duplicate

Two items for one person is usually fixed by merging. Wikidata's [merge help page](https://www.wikidata.org/wiki/Help:Merge) describes the process and its tools. Check carefully before you ask, because two similar items can be subtly different people. Which item survives, how the data moves and how the leftover item is handled are all set out on that page, which I could not reopen in this pass, so follow it step by step rather than relying on my summary. If you are unsure, ask on the project chat before anything is merged.

### A mixed-up item

When one item blends two people, a merge is the wrong tool. The remedy is to separate the statements so each person has their own item, with sources for each. That is delicate editing, and the right place to ask is the project chat, not a unilateral rewrite. If you are one of the two people, be especially careful, because you have a stake in the outcome.

### An item that should not exist

Wikidata has a public process for requesting the deletion of an item, and administrators decide the outcome. For a non-notable person who wants no item, a request is the mechanism, and a privacy argument belongs in it. There is no guarantee of the result, and the discussion is public. Do not blank the item or strip its links in anticipation: follow the process as the live page describes it.

Vandalism and spam go elsewhere. Wikidata has an administrators' noticeboard and a request route for page protection. Report with a clear title, the account or page, and examples.

<figure class="fig">
<figcaption><b>Order of work on a faulty item</b></figcaption>
<ol class="fig-steps">
<li><b>Record what is there</b>Save the Q-number, take a dated screenshot, and list each statement that is wrong, missing a source or private.</li>
<li><b>Gather one source per fix</b>Find an independent page for each correction. Your own site is a supporting reference at best.</li>
<li><b>Choose the route</b>A sourced fact goes to the project chat or a careful edit. A duplicate goes through the merge process. A private detail goes under the living people policy.</li>
<li><b>Write the request once, plainly</b>Q-number, statement, what is wrong, source. No adjectives, no history of the dispute.</li>
<li><b>Check after the change</b>Reopen the item, and look at the history to confirm the edit stayed and nothing else was altered.</li>
</ol>
</figure>

## Conflict of interest: what this means for subjects and paid help

Wikidata is a Wikimedia project, and the Wikimedia community cares about editing by people with a stake. Wikidata has its own pages on conflict of interest and on disclosure of paid editing, and the Wikimedia Terms of Use contain a rule on paid contributions. None of those could be read for this guide, so I will not state what they require. The sibling guides on Wikipedia cover the Wikipedia guideline, which is a separate document.

What I can say is based on ordinary good practice, which holds whatever the exact wording elsewhere:

- **Do not use fake accounts.** Never create extra accounts to add or support your own statements. That is deception, it is easily spotted in an edit history, and it can lead to blocks.
- **Disclose a relationship before you edit.** If you are the subject, or a paid agent for the subject, say so openly where you make a request. Check the live rules on disclosure before the first edit and follow them.
- **Prefer requests to edits for anything contested.** A correction proposed with a source can be accepted by someone with no stake, and it will carry more weight.
- **Never pay for edits through a seller who hides the arrangement.** Undisclosed paid editing is the pattern that tends to get items deleted and accounts blocked. Any provider who describes how they avoid detection is selling a risk.

An adviser worth hiring tells you which routes are open to you under the rules, which are not, and when to do nothing. For the routes that are open, the work is research and documentation: finding the independent sources, preparing the correction, and tracking the result.

## A worked scenario and a six-week timeline

This is an invented scenario with generic parties. Assume an independent consultant, whom I will call the consultant, with a common name. Searching the name on Wikidata returns two items: one for a sports coach and one with a bare label and no description. Neither is the consultant. The consultant has a personal site, a few conference listings and one trade-press interview.

The assessment is straightforward. The consultant has some independent coverage but not much, so an item is borderline. The risk is not absence. It is that the bare-label item gets edited by someone who guesses it is the consultant, or that an AI assistant mixes the consultant with the coach. The plan is therefore to strengthen the evidence outside Wikidata and keep a watching brief inside it.

The timeline below is a typical order of work. Durations are experience, written as "usually", and depend on how fast others respond.

<div class="tablewrap"><table><thead><tr><th>Week</th><th>Work</th><th>Output</th></tr></thead><tbody>
<tr><td><strong>1</strong></td><td>Search name variants, list all items, note Q-numbers and screenshots</td><td>Audit sheet</td></tr>
<tr><td><strong>2</strong></td><td>Read each item for the right person, source quality and private details</td><td>Fault list</td></tr>
<tr><td><strong>3</strong></td><td>Strengthen owned and independent sources: official page, consistent bio, press mentions</td><td>Source set</td></tr>
<tr><td><strong>4</strong></td><td>File any correction or merge request with sources, or decide to skip</td><td>Requests posted</td></tr>
<tr><td><strong>5 to 6</strong></td><td>Check outcomes, re-read items, record what changed</td><td>Result note</td></tr>
</tbody></table></div>

Because the consultant is borderline, no item is created in this plan. If independent coverage grows later, the decision is revisited, and the consultant asks on the project chat or lets an unconnected editor decide, with disclosure. Making your own name consistent across your site and profiles is the part you fully control, and it is what makes any later structured record easy to build correctly.

## Next step: check first, edit second

Start with the audit in week one of the plan above. It takes an hour, changes nothing, and tells you which of the situations in the decision table you are in. Most people discover they need a correction or a decision to skip, not a new entry.

<div class="box hot"><b>If this is happening to you now</b>
<p>If an item about you is wrong, mixed with a namesake or holds a private detail, collect the Q-number and the sources before you touch anything, then talk to us. Reputation Partners can review what search engines and AI assistants find under your name and tell you which route fits. <a href="/audit">Request a private audit</a>.</p></div>

## Questions people ask

### Can I create a Wikidata entry for myself?

You can technically create an item, but whether you should depends on notability and conflict of interest. Items that fail the notability policy can be nominated for deletion. If you have little independent coverage, expect trouble. If you are covered, an unconnected editor is a safer author. Read the live policies and disclose your relationship if you edit.

### Does a Wikidata entry give me a Google knowledge panel?

No source I read says so. Google's help page is where panel sourcing is described, and nobody can promise a panel because you have an item. An item is one piece of public evidence about who you are. It may help a system tell you from a namesake, but it is not a request mechanism.

### Is a Wikidata entry the same as a Wikipedia page?

No. Wikipedia is an encyclopedia of articles written in prose under its own rules. Wikidata is a separate database of structured facts released under CC0. A Wikipedia article normally links to an item, but an item can exist without an article. Their notability and sourcing rules differ, so meeting one test does not settle the other.

### What if my Wikidata entry contains something private?

Use the living people policy and read its live wording. Raise the problem on the project chat or the administrators' noticeboard, name the item and the statement, and do not repeat the private detail in the request. If the detail has no reliable source, say so. Whether it is removed is decided by Wikidata's editors and administrators, not by you or by us.

### How do I get a duplicate item merged?

Check that both items describe the same person, then follow the merge help page step by step. It sets out which item should receive the data and how the other is handled. If you are unsure whether the two are the same person, or which should survive, ask on the project chat before anything is merged, and keep your request short with both Q-numbers.

### Can I have my Wikidata entry deleted?

You can ask. Wikidata has a public deletion request process for items that fail its notability policy, and administrators decide in an open discussion. A privacy argument belongs in the request. The outcome is not guaranteed, and a person who is clearly notable is unlikely to be removed on preference alone. Read the live process page first.

### Should I pay someone to add me to Wikidata?

Only if the arrangement is open and the work is research, sourcing and requests, not hidden editing. I could not read Wikidata's paid-editing rules for this guide, so check the live pages. Avoid any seller who promises placement, uses multiple accounts or hides who is paying. Those methods are the ones that tend to get items deleted and accounts blocked.