Wikidata knowledge entity: how an independent consultant closes their semantic graph

Nomen est omen. On the semantic web, no identifier means no name.

Consultoría Actuarial del Norte, S.L.P. is a single-partner practice in Bilbao, registered as a Spanish professional limited company. Five people, founder included. Stable turnover, a client book of mutual societies and mid-sized insurers, eighteen years of track record. The founder speaks at two conferences a year and has written a technical book on Solvency II with a university press. His website has reasonable domain authority and his LinkedIn has 4,200 followers. All good on paper.

Google doesn't know any of this. Search his exact name and no Knowledge Panel appears on the right. Ask an LLM for actuarial consultants specialising in Solvency II in Spain and the model names two large Madrid boutiques and a Catalan firm, but not him. When he does show up, it's as a stray result: a conference PDF, a post on his firm's blog, an old profile in a professional directory. Every mention is an island.

The problem isn't authority. It's identity.

Google and several LLMs need a unique identifier to hang all those scattered mentions on, so they can recognise them as the same entity. For 90% of the open semantic ecosystem, that identifier is a Wikidata Q-ID. Without it, the system sees five unconnected mentions. With it, the system sees a consultant.

This applies now.

Wikipedia is not Wikidata, and confusing them is the first mistake

Almost everyone assumes you need a Wikipedia article to be in Google's Knowledge Graph. You don't. Wikipedia and Wikidata are sister projects of the Wikimedia Foundation, with different rules and different purposes.

Wikipedia is an encyclopaedia of articles written in natural language. Its hard rule is notability: only subjects with significant coverage in independent secondary sources get in. For an individual consultant, in practice, that means five to ten press articles in general or trade media focused on them personally. Most consultants don't meet that bar and never will. That's fine. Wikipedia isn't for that.

Wikidata is a structured database of items. Each item has an identifier (Q-ID) and a list of properties with values. It isn't an encyclopaedia. It's a knowledge graph. Its admission rule is far looser: any entity that can be identified unambiguously and has at least one external reference to back it up gets in. The usual threshold is two or three links to external sources: an ORCID profile, a VIAF record, a book's ISBN, an entry in an official professional register, a reference in an academic database.

Translation: a consultant with a published book, an ORCID profile and two talks recorded in academic databases can get into Wikidata without trouble. Not into Wikipedia. And for Google's Knowledge Graph, Wikidata is enough in most cases.

The confusion is expensive. The consultant spends months trying to force through a Wikipedia article that will be deleted for self-promotion or lack of notability, when the useful route was always the other door.

Wikipedia checks narrative notability. Wikidata checks structured identity. They are different problems and they are solved differently.

There's a third common confusion: thinking Wikidata only matters for public figures. It doesn't. Wikidata holds items for universities, scientific journals, buildings, songs, beetle subspecies and, yes, technical professionals who have published under a persistent identifier. In December 2025, Wikidata passed 115 million items. For specialist consultants who already have a minimal public footprint, the bar is low.

Which properties to fill in for the person and which for the company

An independent consultant almost always needs two Wikidata items, not one. One for the natural person and another for the practice or professional brand when they invoice through a company. The two items link to each other and each has its own minimum set of properties.

Natural person

These are the minimum properties for Google to treat the item as a person with a stable identity.

• P31 (instance of). Mandatory value: Q5 (human). Without this triple, the item doesn't resolve as a person anywhere.
• P21 (sex or gender). Value Q6581072 (female), Q6581097 (male) or other documented options. Google uses it for disambiguation.
• P106 (occupation). One or more occupations go here. For an actuary, Q1077636 (actuary). For an independent software engineer, Q82594 (software engineer) plus Q131524 (consultant). The more specific occupations the better, as long as they're true.
• P569 (date of birth). Year of birth at minimum. Full date if it's public. Without a date of birth, Wikidata treats the item as incomplete and Google gives it lower priority for a Knowledge Panel.
• P27 (country of citizenship). Value Q29 (Spain) for a consultant based in mainland Spain.
• P19 (place of birth). City or municipality, linked to an existing Q item.
• P108 (employer) or P800 (notable work). At least one. If the consultant invoices through their own company, P108 points to the practice's Q-ID. P800 takes published books (linked by their own Q-ID) or notable projects.
• P1416 (affiliation). Professional body, trade association, university chair. Helps pin down the niche.
• P856 (official website). URL of the personal or professional website.
• P2002 (Twitter/X username), P2035 (LinkedIn), P2013 (Facebook), P4033 (Mastodon), P11947 (Bluesky). Every active public profile as a separate property. Each one is an external source that anchors the identity.
• P496 (ORCID iD). For any consultant with registered academic or technical output. ORCID is the persistent identifier that gives the item the most weight with Google.

Company or practice

When the brand invoices, the company gets its own item.

• P31. Value Q4830453 (business) or something more specific: Q1477538 (professional limited company) for a Spanish S.L.P., Q188907 (limited liability company) for a generic S.L.
• P17 (country). Q29.
• P159 (headquarters location). City of the registered office.
• P571 (inception). Year of incorporation.
• P452 (industry). Sector. There are items for almost all of them: actuarial consulting (Q11681746), audit (Q193465), management consulting (Q853574), software development (Q638608).
• P169 (chief executive officer) or P488 (chairperson). Linked to the Q-ID of the founder's personal item. This triple closes the loop: the graph knows that person X runs company Y, and that company Y has person X as CEO.
• P1128 (employees). Headcount if it's public. Not mandatory, but useful.
• P856 (official website). Corporate URL.
• P1320 (OpenCorporates ID). Identifier in the OpenCorporates database. Every Spanish company with an active NIF (tax ID) has an automatic entry. It's the easiest external reference to add.

Rule: no item goes live without at least two external properties with a reference (P856 doesn't count as external because it's your own website). ORCID, VIAF, ISBN, OpenCorporates, DOI, GND, ISNI. Any of those will do, and two is comfortable. Without external references, the item survives the first week but gets removed at the second patrol.

The two-way link: sameAs, JSON-LD and why Google can't close the loop without it

Publishing the item on Wikidata isn't enough. You have to tell the rest of the web that this Q-ID is your identity. The standard vehicle is the sameAs attribute inside the JSON-LD your own website serves on every relevant page.

On the home page of the personal or professional website, inside the <head>, goes a block like this.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://consultoriaactuarialdelnorte.example/#founder",
  "name": "First Name Surname",
  "jobTitle": "Chartered actuary",
  "worksFor": {
    "@type": "Organization",
    "@id": "https://consultoriaactuarialdelnorte.example/#organisation"
  },
  "url": "https://consultoriaactuarialdelnorte.example/",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q123456789",
    "https://orcid.org/0000-0002-XXXX-XXXX",
    "https://www.linkedin.com/in/firstnamesurname/",
    "https://scholar.google.com/citations?user=XXXX",
    "https://dialnet.unirioja.es/servlet/autor?codigo=XXXX"
  ]
}
</script>

Alongside it, a second block for the organisation.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "@id": "https://consultoriaactuarialdelnorte.example/#organisation",
  "name": "Consultoría Actuarial del Norte, S.L.P.",
  "founder": {
    "@type": "Person",
    "@id": "https://consultoriaactuarialdelnorte.example/#founder"
  },
  "sameAs": [
    "https://www.wikidata.org/wiki/Q987654321",
    "https://opencorporates.com/companies/es/BXXXXXXX",
    "https://www.linkedin.com/company/consultoria-actuarial-del-norte/"
  ]
}
</script>

The sameAs is the bridge. Google reads the JSON-LD, follows the sameAs links and checks that the other end is consistent: the Wikidata item holds a P856 property pointing to the same URL. The loop closes. Google now knows that the website, the Q-ID, the LinkedIn profile and the ORCID record all describe the same entity.

Detail: the two @id values in the JSON-LD blocks are internal URIs with a fragment (#founder, #organisation). The fragment doesn't resolve as a page you can visit. It only works as a local identifier so the Person block and the Organization block can reference each other. With worksFor and founder using those internal @id values, the page's own internal graph is closed as well.

Without JSON-LD on the website, the Wikidata Q-ID is orphaned. Google doesn't associate it with anything and no Knowledge Panel is generated. Plenty of items have sat on Wikidata for years without ever triggering a panel because their owner never added the sameAs to the site.

Wikidata is half the contract. The JSON-LD with sameAs on your own website is the other half. Without both signatures, the contract has no effect.

One extra that few people bother with, and that helps: the JSON-LD of every blog article should include an author block that references the person's @id, not a plain string with the name. That way every article you publish adds one more triple to the site's internal semantic graph.

Mistakes that get your Wikidata item reverted by patrollers within 48 hours

Wikidata has a community of volunteer patrollers who revert suspicious changes. A badly built item doesn't last long. Here are five common mistakes that trigger an almost automatic revert.

Mistake 1: Obvious self-promotion. Symptom: the item is created from a freshly registered account with no previous edits, and the descriptions use sales language ("leading consultant", "industry benchmark", "recognised expert"). Fix: the description must be a short, neutral phrase such as "Spanish actuary" or "Spanish consultant specialising in Solvency II", with no evaluative adjectives. Evaluative adjectives are an instant red flag.

Mistake 2: Zero external references. Symptom: the item is saved with properties but no reference (the book icon) next to the values. A patroller flags it in the next round and deletes it for lack of support. Fix: every property that can take a reference should have at least one, through stated in (P248) or reference URL (P854). At minimum, P106 (occupation), P108 (employer) and P800 (notable work) must be referenced.

Mistake 3: Circular links with no external source. Symptom: the item's only reference is the consultant's own website. Fix: your own website is accepted in P856, but it doesn't count as an independent source. Add at least one source the subject doesn't control: OpenCorporates, ORCID, Google Scholar, Dialnet (the main Spanish-language academic database), ISBN, the Spanish National Library catalogue, VIAF. Without at least one external source other than the subject's own website, the item goes.

Mistake 4: Name in capitals or with honorifics. Symptom: the label is saved as "First Name SURNAME SURNAME" or "Dr First Name Surname, MBA". Fix: the item label carries no honorifics or post-nominals and uses normal capitalisation. Academic degrees go in P512 (academic degree), not in the name.

Mistake 5: Identical descriptions in several languages. Symptom: the same Spanish text pasted into the English, German and French description fields. Fix: at the very least, the Spanish and English descriptions must each be written in their own language. The rest can be left blank. An empty description is better than one in the wrong language.

An item created with these five precautions survives the initial patrol. Usually, within the first two weeks another editor passes by, corrects something minor and adds one or two properties you had missed. That's healthy. It means the item has been absorbed into the graph and other editors are treating it as part of the whole.

Realistic timeline from publication to Knowledge Panel

There's a recurring expectation: publish the item on a Tuesday and see the Knowledge Panel on Thursday. It doesn't happen. Google takes weeks or months to close the loop and trigger the panel, and there are intermediate steps worth tracking.

Day 0. Item published on Wikidata. The item exists with an assigned Q-ID. Google hasn't yet indexed it as part of the Knowledge Graph.

Days 1 to 3. The Wikidata page gets indexed. The URL https://www.wikidata.org/wiki/QXXXXXXXX is indexed by Google like any other URL. You can already find it by searching the Q-ID directly. No panel yet.

Days 3 to 7. JSON-LD with sameAs goes live on your own website. This step is the consultant's job, not Google's. You add the two JSON-LD blocks to the <head> of the home page and check with Google's Rich Results Test that there are no errors. Skip this step and nothing that follows happens.

Weeks 2 to 6. Googlebot crawls the sameAs. Googlebot visits the home page, reads the JSON-LD, follows the sameAs pointing to the Q-ID and checks the link in both directions. This cross-check happens on every crawl, not just once. The more signals converge, the more confidence Google assigns.

Weeks 6 to 12. A rich result appears in the SERP. The first visible sign is usually a Person or Organization rich result for the exact-name search: the profile photo next to the first result, or a small enhanced snippet. It isn't a full Knowledge Panel yet, but it tells you Google has accepted the association.

Months 3 to 6. An early Knowledge Panel. A panel appears on the right with the photo, the short Wikidata description and the social links from the sameAs. It tends to show first for very specific searches (full name plus city, full name plus profession) and then spreads to the name on its own.

Months 6 to 12. Full Knowledge Panel and citations in LLMs. The panel settles with all the basic information. At the same time, LLMs that use entity graphs derived from Wikidata (several general-purpose models do) start citing the consultant when asked about their niche. Mentions in AI answers clearly pick up from month six onwards.

That's the realistic range for a clean case with minimal academic output. For a consultant with no academic output but some media presence, the curve is slower: it can take more than a year before the panel appears.

Translation: publishing on Wikidata is a play with a one-year horizon. It isn't a campaign. It's an investment in identity that keeps paying for years once the loop is closed.

Periodic maintenance of the item: what to check every quarter

A Wikidata item isn't static. Roles change, affiliations change, a new book comes out, a company is wound up. The discipline is to review it every quarter against a short checklist.

• Occupation (P106). Check that the occupations are still true. If the consultant stops training and only consults, remove the trainer occupation. If they start working as a court-appointed expert, add Q212238 (expert witness).
• Notable work (P800). Add new books, talks at refereed scientific conferences and open projects published under their own name. Every new work is one more property and one more reference.
• Employer (P108) and position held (P39). If the practice changes, the end date goes on the old value (qualifier P582, end date) and the start date goes on the new one (P580, start date). Never delete old values: mark them as ended. Wikidata prefers accumulated history to overwritten history.
• Social accounts (P2002, P2035, etc.). If a profile is closed or a new one opened (Mastodon, Bluesky), update it. Dead accounts return a 404 to Googlebot and lower the graph's confidence.
• The website's sameAs. If a new external profile with a stable identifier appears (a new academic database, a new professional directory), add it both as a property on Wikidata and to the sameAs block in the JSON-LD.
• Descriptions. Check that the short description still reflects the current niche. Change "Spanish actuary" to "Spanish actuary specialising in climate risk" once the niche has narrowed.

The quarterly review takes twenty or thirty minutes if the item is clean. If it has been left to rot for a year, rebuilding it takes a whole afternoon. The net difference in favour of the quarterly review is huge.

Rule: one hour a quarter. No exceptions. It's the maintenance cost of a structured digital identity.

One quiet habit that helps a lot: every time the consultant publishes a blog article or a new book, add the new link to the relevant sameAs and add a P800 statement for the new work on Wikidata. Every publication is a chance to reinforce the graph. Most consultants publish things and leave them disconnected from the item. Hooking every work into the graph is what separates a living identity from a frozen one.

Common mistakes across the whole cycle

On top of the patrol mistakes above, there are five strategic mistakes that stop a Wikidata project from paying off even with an approved item.

Mistake 1: sameAs that only goes one way. Symptom: the Wikidata item has P856 pointing to the website, but the website has no sameAs pointing to the Q-ID. Or the other way round. Google doesn't close the loop and generates no Knowledge Panel. Fix: check both sides with the Rich Results Test and with the Wikidata item's own URL. Both links must be there. No exceptions.

Mistake 2: Mixing person and company in the same item. Symptom: the consultant creates a single item with P31 set to Q5 (human) but fills in company properties (P452 industry, P1128 employees). Or the other way round. The item ends up a hybrid and Google can't tell whether it's a person or an organisation. Fix: two separate items, linked to each other through P108 (employer) and P169 (CEO).

Mistake 3: A description that changes every month. Symptom: the consultant edits the description every time they rework their sales pitch. The description isn't marketing copy. It's the short, neutral label Google will show in the snippet. Fix: freeze the description for at least twelve months and only change it when the niche really changes, not when the campaign does.

Mistake 4: Ignoring ORCID. Symptom: the consultant has published work but hasn't registered an ORCID. Fix: register a free ORCID at orcid.org, load all publications into it, add the P496 property on Wikidata and the sameAs on the website. ORCID is the external source with the most relative weight for technical and academic consultants, and it costs nothing.

Mistake 5: Creating the item from an anonymous account. Symptom: the editor hasn't created an account, or created it that same day. Patrollers are stricter with new accounts. Fix: create a Wikidata account a few months ahead, make five or ten useful edits on existing items (minor corrections, added references, description translations), and only then create your own item. That track record halves the risk of a revert.

Frequently asked questions

How do you create a Wikidata entry for a company or a professional?

Register an account at wikidata.org, make a few minor edits on existing items to build a track record and create the new item with the "Create a new Item" button. The item needs a label (name), a short neutral description and at least a P31 (instance of) property with the right value: Q5 for a person, Q4830453 or a subtype for a company. Then add properties one by one, with at least two external references (ORCID, OpenCorporates, ISBN, VIAF), so it survives the initial patrol.

What real SEO benefit does being on Wikidata bring?

Three concrete benefits. One: it's the shortest route to Google triggering a Knowledge Panel with the photo, the description and the social links when someone searches the exact name. Two: LLMs that use entity graphs derived from Wikidata (several general-purpose ones do) start citing the consultant as a reference when asked about their niche. Three: the Q-ID acts as a stable anchor for all the site's JSON-LD markup, which strengthens the semantic consistency of every page and helps with rankings in rich results.

How do you get a Google Knowledge Panel?

Two requirements have to come together. One: exist as a recognisable entity in the Knowledge Graph, which in 90% of cases is solved through Wikidata with a well-built item and verifiable external references. Two: close the loop with JSON-LD on your own website declaring @type Person or @type Organization with sameAs pointing to the Wikidata Q-ID, ORCID, LinkedIn and other external identifiers. With both parts in place, the panel appears within three to twelve months, depending on how much signal existed beforehand.

What minimum Wikidata properties should a technical consultant fill in?

For the person: P31 set to Q5, P21 (sex or gender), P106 (occupation), P569 (date of birth), P27 (country of citizenship), P856 (official website), P496 (ORCID), P2035 (LinkedIn) and P800 (notable work) with at least one referenced work. For the company, in its own separate item: P31 with a company subtype, P17 (country), P159 (headquarters location), P571 (inception), P452 (industry), P169 (CEO, linked to the person's item) and P1320 (OpenCorporates ID). With those properties, plus at least two external references, the item passes the initial patrol.

Do you need to pay someone to create the item?

No. Accounts and editing on Wikidata are free, and Wikidata doesn't take payment for creating items. Some agencies charge to do it, but anyone who spends a few hours reading the property documentation can do the same work. Paying only makes sense when the consultant doesn't have the hours and wants to hand off the execution, not when they're looking for a shortcut to approval. The item is approved by the patroller community under public rules.

Can you ask Google to trigger the Knowledge Panel faster?

There's no direct channel for that. Google doesn't accept requests to create a panel. The only thing you can do, once the panel appears, is claim it to edit specific details (photo, description) through the "Claim this Knowledge Panel" flow in Search Console. The initial trigger depends on the automatic cross-check between Wikidata, the site's JSON-LD and external mentions. The only way to speed it up is to strengthen the signals, not to ask.

Closing

A Wikidata item isn't marketing. It's digital identity infrastructure, on the same level as registering your own domain or getting a tax ID. The consultant does it once, maintains it for an hour a quarter and gets years of stable presence on Google and citations in LLMs in return. The marginal cost is laughable next to the compound return.

Most consultants don't have one because nobody has explained it to them in this much detail, or because they confused Wikidata with Wikipedia and gave up when they saw the encyclopaedic notability criteria. But the right door was the other one, and it was always open. An actuary with a book and an ORCID fits. An engineer with a talk at an IEEE conference fits. A consultant with a company active for five years on OpenCorporates fits. It isn't a question of fame. It's a question of identifiers.

If you have a minimal public profile (a book, a talk, an ORCID, an active company) and your professional brand sells partly on technical authority, you have a Q-ID waiting to be born. Once it exists, everything you publish afterwards (articles, books, talks, appearances) starts building up on that anchor instead of scattering into loose mentions. If you'd like to go through together which properties apply to you, which external references you already have and how to set up the JSON-LD that closes the loop with Google, book a 30-minute session or see how we handle semantic identity inside an Own Vertical Software build. No cost, no hard sell, and you leave with a written three-step plan.

Related reading

• Wikidata introduction for beginners (Wikimedia Foundation)
• Property guide for people (Wikimedia Foundation)
• Google's Rich Results Test (Google Search Central)
• Official schema.org documentation on Person and Organization
• OpenCorporates: open company data