Wikidata Deleted My Business Item
For Not Being Notable
By Lesli Rose · July 22, 2026 · 7 min read
On 25 May 2026 I created a Wikidata item for my own consulting brand. On 8 June 2026 an administrator deleted it with the reason "RfD: Not notable." Fourteen days, start to finish. I am writing this up because I recommend entity work for a living, and the most useful thing I can show you is the version where it did not work.
You can still read the record. Wikidata keeps deletion logs public even when the item itself is gone:
19:09, 8 June 2026 ZI Jony deleted page Q139919427 (RfD: Not notable.)
Why I Created It in the First Place
My brand name is contested. Search "Lesli" and you compete with a pool supply chain and an appliance manufacturer. When a machine cannot tell which entity you are, it does the safe thing and recommends one of the larger ones. A Wikidata item is the standard answer to that problem, and it is a good answer. Wikidata feeds Google's Knowledge Graph and is read directly by several AI systems. One unambiguous identifier, and everything else on the web can point at it.
So I built it properly. Instance of, official website, founder, location, field of work, and sameAs links out to every profile I controlled. It sat there for two weeks, patrolled by bots, looking exactly like a healthy entity record.
The Policy I Did Not Weigh Properly
Wikidata's notability policy accepts an item if it meets at least one of three criteria. Paraphrasing closely:
1. It contains at least one valid sitelink to a page on Wikipedia, Wikivoyage, Wikisource, Wikiquote, Wikinews, Wikibooks, Wikidata, Wikispecies, Wikiversity or Wikimedia Commons.
2. It refers to an instance of a clearly identifiable conceptual or material entity that can be described using serious and publicly available references.
3. It fulfills a structural need, for example being needed to make statements in other items more useful.
Criterion one was out. No Wikipedia article. Criterion three was out. Nothing else on Wikidata needed my item to make sense. That left criterion two, and criterion two turns on the phrase "serious and publicly available references."
Every reference I could offer described me because I had written it. My website. My profiles. My own published work. None of that is independent, and an editor reading the item saw that immediately. The policy was not applied unfairly. It was applied correctly, to a business that had not yet earned the thing the policy asks for.
The Damage Is Not the Deletion
Losing the item cost me nothing on its own. The real cost was everything that had been wired to point at it.
Structured data on my site listed the identifier under sameAs. Case study copy cited it as proof of work. Two drafted articles referenced it as an example. The moment the item was deleted, all of it silently became a set of claims pointing at a URL that returns 404. Nothing broke visibly. No error appeared. The site simply carried on telling machines to go look at something that was no longer there, and it did so for six weeks before I caught it.
That is the failure mode worth internalising. A deleted identifier does not announce itself. It degrades quietly, in the exact layer of your site that only machines read.
A Detail That Cost Me Three Passes to Notice
When I first found the dead identifier, I assumed it had been invented. It had not, but nothing in the obvious checks could tell me that. A deleted item and an item that never existed return byte-identical responses. The page 404s for both. Special:EntityData reports no entity for both. Searching the brand name returns zero results for both.
The distinction only surfaced in the public log. If you ever find a dead identifier in your own structured data, check Special:Log?page= with the item ID before you conclude anything, because the two cases call for opposite responses. An invented identifier is an integrity problem: find the source and purge every copy. A deleted one means the claim was true when it was written and the world moved, and the reason it was deleted is usually the more valuable finding. In my case that reason was "not notable," which told me something real about the state of my own brand that "someone made this up" would have hidden completely.
What to Build Instead, and In What Order
The entity logic was never wrong. Machines do need one unambiguous node for your business. I had the sequence backwards, reaching for the record that requires independent coverage before I had any.
The order that actually holds:
First, the records you fully control and nobody can delete for notability: Google Business Profile, LinkedIn company page, industry directories that accept your category, and identical name, address and phone details across every one of them.
Second, the crosswire. Use sameAs in your structured data so each record points at the others, and every profile that allows a website field points back at your domain. This is the step most businesses skip, and it does most of the disambiguation work people hope Wikidata will do.
Third, the independent coverage: being named in roundups, quoted, reviewed, listed by someone who is not you.
Then Wikidata, if it is still worth it. By that point you have the serious and publicly available references criterion two asks for, and the item survives.
This maps onto something I have written about before: roughly 85% of AI citations come from third-party sources, not from your own website. A self-created Wikidata item is an attempt to shortcut that number. It is you, writing about you, on a platform that happens to be well trusted. The platform's editors exist specifically to catch that, and in my case one did, in fourteen days.
Would I Do It Again
Not yet, and not in that position. A second self-created item for the same brand would be deleted on the same grounds, and repeatedly recreating deleted items is a good way to attract the wrong kind of editor attention. The item becomes worth revisiting when there is independent coverage to cite, and at that point it often appears without being asked for.
If you are being told that a Wikidata item is the highest-leverage move for your visibility, the honest question to ask first is what independent sources currently describe your business. If the answer is none, the item is not the next move. The coverage is.
Common Questions
Can I create a Wikidata item for my business?
Anyone can create one in about twenty minutes. Creating one and keeping one are different things. Any editor can nominate an item for deletion, and administrators routinely delete items for businesses with no independent published coverage.
What makes a Wikidata item notable?
Meeting at least one of three criteria: a valid sitelink to a Wikimedia project page, being a clearly identifiable entity describable using serious and publicly available references, or fulfilling a structural need for other items. Most small businesses fail all three, because the references describing them are their own website and their own profiles.
Does a Wikidata item improve AI visibility?
It can act as a canonical identifier that helps machines tell your brand apart from others sharing the name. But it is a consequence of independent coverage rather than a substitute for it, and an item that gets deleted leaves you worse off than never creating one, because your structured data now points at a URL that returns 404.
What should I do instead?
Build the records that cannot be deleted for notability, then cross-reference them with sameAs so each one points at the others, then earn the third-party coverage. Wikidata comes after that, not before it.
How do I tell a deleted item from one that never existed?
You cannot, from the item URL or the API; both return identical empty responses. Check the public log at Special:Log with the item ID as the page parameter. It shows the deletion, the administrator and the stated reason.
Find Out What Machines Think You Are
I'll map every record that describes your business, show you where they contradict each other, and tell you which ones to fix first.
Run Your Visibility Report