MarketLensEvery serious knowledge graph — Google’s, and the graphs distilled into LLM training data — needs a spine of unambiguous identifiers, and for the open web that spine is Wikidata. Each item in it carries a Q-ID: Q95 is Google, Q380 is Mozilla. When your brand has one, machines stop asking “which Apex Consulting?” and start asserting facts against a single, referenced record.
Most guides wave at this — “add your business to Wikidata” — and skip the part where inadequately sourced items get deleted within days. This guide is the full procedure: the notability test, the exact properties and references that make an item stick, and how to wire the finished Q-ID back into your site so the anchor actually transmits authority.
Why a Q-ID Is Worth the Effort
Wikidata sits unusually far upstream in the AI data supply chain. Google’s Knowledge Graph ingests it directly; Wikipedia infoboxes draw from it; and because Wikipedia and Wikidata dumps are core LLM training corpora, facts anchored there propagate into models by default. A Q-ID gives you three concrete things:
- A canonical identifier that your JSON-LD
sameAsarray can point to — the highest-authority bridge available to a site owner, emitted from the Organization block described in our guide to generating JSON-LD from Hugo templates. - A referenced fact record (founding date, website, industry, location) that answer engines can quote instead of inferring.
- A disambiguation page of last resort: when a model weighs two same-named candidates, the one with a structured, referenced graph entry usually wins the resolution.
MarketLens treats the Q-ID as the keystone of what we call closed-loop semantic verification: your site claims the Q-ID, and the Q-ID’s official-website property claims your site back.
Step 1: Pass the Notability Test Before You Start
Wikidata’s inclusion bar (lower than Wikipedia’s, but enforced) requires an item to satisfy at least one of three criteria: it holds a valid sitelink to a Wikimedia project; it refers to a clearly identifiable entity describable using serious and publicly available references; or it fulfills a structural need — for instance, it’s required as the value of another item’s statement.
For a typical business, the second criterion is the target. Inventory your independent evidence honestly:
| Evidence type | Counts toward notability? | Notes |
|---|---|---|
| National or trade press coverage | Yes — strongest | Articles about you, not press releases |
| Official company register (e.g., Companies House, SEC, EU registers) | Yes | Establishes legal existence and inception |
| Industry databases (Crunchbase, professional directories) | Partially | Supporting, not sufficient alone |
| Your own website and blog | No | Usable as a reference for uncontroversial facts only |
| Social media profiles | No | Neither notability nor sourcing value |
If the left column above the line is empty, stop and fix that first — earn coverage, get registered in authoritative databases — because an item sourced only to yourself is a deletion candidate, and a deleted item leaves a log entry that makes the next attempt harder.
Step 2: Search for Existing Items First
Duplicate items are merged or deleted, and merges can scramble your carefully entered statements. Search Wikidata for your brand name and plausible variants (legal name, former names, common misspellings). Also run a SPARQL check for your domain, since an item may exist without your name as a label:
SELECT ?item ?itemLabel WHERE {
?item wdt:P856 ?website .
FILTER(CONTAINS(STR(?website), "yourdomain.com"))
SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}Run it at query.wikidata.org. If an item already exists — sometimes created by bots importing company registers — claim and improve it rather than creating a rival.
Step 3: Create the Item and Set the Core Statements
Create an account (an account with prior constructive edits attracts less scrutiny than a zero-history account whose first act is self-promotion), then use “Create a new Item”. Three fields define the item’s face: the label (common name, no legal suffixes), the description (a neutral, lowercase fragment like “Romanian software auditing company” — it exists to disambiguate, not to market), and aliases (legal name, former names, common variants).
Then add statements. The minimum viable, disambiguation-effective set:
| Property | Meaning | Example value |
|---|---|---|
| P31 | instance of | business (Q4830453) or a more specific class |
| P856 | official website | https://yourdomain.com/ |
| P17 | country | your country item |
| P159 | headquarters location | city item |
| P571 | inception | founding date |
| P452 | industry | e.g., software industry |
P856 deserves special care: it is the property that graph consumers use to bind the entity to your domain, and the one your on-site sameAs markup will reciprocate. Set it to the canonical HTTPS origin — the same origin your JSON-LD @id uses.
Step 4: Reference Every Substantive Statement
Unreferenced statements about commercial entities are the top trigger for deletion discussions. For each statement, add a reference with at minimum reference URL (P854) and retrieved (P813, the date you accessed it); use the register entry for inception and legal facts, press coverage for industry and descriptive facts. The discipline is the point: a fully referenced five-statement item is dramatically more durable than a fifteen-statement item sourced to nothing. It is also more useful — answer engines prefer facts that carry provenance, which is the same reason citing your sources in ordinary body copy makes a passage easier to quote.
Step 5: Close the Loop From Your Website
The Q-ID transmits authority only when your site and the graph agree bidirectionally. Add the item URL to your Organization schema:
"sameAs": [
"https://www.wikidata.org/wiki/Q_YOUR_ENTITY_ID",
"https://www.linkedin.com/company/your-company/"
]Now verification runs both directions: crawlers reading your site find the Q-ID claim; graph consumers reading Wikidata find P856 pointing home. This bidirectional agreement is what makes the anchor trustworthy — one-way claims are assertions, closed loops are corroboration. The same closed-loop principle extends across your whole profile network, and pairs naturally with the broader work of optimizing your brand entity for search and AI systems at the strategy level.
Deletion Traps and Maintenance
Three mistakes account for most failed brand items in our experience: promotional descriptions (“leading provider of…” — instant red flag), self-sourced-only referencing, and abandoning the item after creation. Wikidata is a living graph; check the item quarterly for vandalism or drive-by edits, add new press references as they appear, and update statements when facts change. An item you maintain accrues edit history and reference density — both proxies for reliability in the eyes of human patrollers and downstream consumers alike.
Where This Fits in Your Entity Stack
The Q-ID is one anchor in a larger identity system: registry anchor (Wikidata), on-site definition (Organization JSON-LD with stable @id), and profile corroboration (LinkedIn, Crunchbase, GitHub all pointing home). Build them in that order of durability. If you want the current state of your entity stack mapped before you start — including whether an item already exists for your brand and which loops are open — a MarketLens Standard Audit includes the full entity-layer inventory with every gap printed explicitly.