Field notesStructured dataEntity confidence
Organization schema: how to stop machines guessing who you are
When identity is left to inference, the wrong company gets named. Here is the minimum structured data that makes your organisation unambiguous, and the mistakes that undo it.
AI Detective6 min read
If a system cannot establish who a site belongs to, it does not stop — it guesses. Usually it guesses from prose, sometimes from a similarly named company, occasionally from a competitor who stated their identity more clearly. Structured data is how you take that guess off the table.
Why inference fails in practice
Company names are rarely unique. They collide across industries, across countries, and with common words. A human reading your homepage resolves this instantly from context. A parser extracting an entity has far less to work with, and the failure mode is silent: nothing errors, a plausible wrong answer is simply produced.
This matters most for exactly the organisations least likely to have addressed it — small and mid-sized companies whose name overlaps with a larger one, and businesses whose sector is not obvious from their name.
The minimum that actually helps
A single JSON-LD block in the head of your homepage covers most of the value:
- name — exactly as you use it publicly, not a legal variant nobody recognises
- url — your canonical homepage
- description — what the organisation actually does, in plain language
- logo — an absolute URL
- sameAs — links to profiles that independently corroborate your identity
Of these, sameAs does the most work and is most often omitted. It is the difference between asserting an identity and connecting it to independent records elsewhere.
What it looks like
A complete, honest Organization block for a mid-sized business is short. It goes in a script tag of type application/ld+json, in the head of the served HTML:
{ "@context": "https://schema.org", "@type": "Organization", "name": "Northgate Analytics", "url": "https://northgate-analytics.com/", "description": "Accessibility testing for financial services, based in Bengaluru.", "logo": "https://northgate-analytics.com/logo.png", "sameAs": ["https://www.linkedin.com/company/northgate-analytics", "https://github.com/northgate-analytics"] }
Note the absolute URLs throughout, and a description that says what and where
That is the whole thing. There is no advantage in padding it with properties you cannot fill accurately — an empty or invented field is worse than an absent one.
Choosing sameAs links
Not every profile is worth listing. The useful ones are those that independently corroborate your identity and are maintained:
- Profiles you actively control and keep current
- Records held by someone other than you — a company register, an industry body, a recognised directory
- Platforms where your identity is verified rather than self-asserted
Skip abandoned accounts. A link to a profile last updated in 2019, describing a product you discontinued, connects your identity to stale information and actively works against you. Deleting the link is usually better than updating a profile you will not maintain.
Where it goes
The homepage, at minimum. Organisation identity is a site-level fact, and the homepage is where it is looked for. Placing it in a shared layout so it appears on every page is also fine and slightly more robust, since it does not depend on which page is read first.
What matters more than placement is that it is in the HTML the server sends. A block assembled by a tag manager after load is invisible to any reader that does not execute scripts, which includes a good deal of automated traffic.
Four mistakes that neutralise the effort
Structured data that contradicts the visible page
A description in your markup that disagrees with the description on the page is worse than neither. Disagreement between sources is itself a negative signal, and it is the most common defect we see in generated schema.
Copying a competitor's markup
It happens more than you would expect, usually via a template. A stale name or URL left in a copied block asserts, in machine-readable form, that you are someone else.
Injecting it with JavaScript
Structured data added after page load is invisible to anything that reads the served HTML without executing scripts. If it matters, it belongs in the initial response.
Publishing it once and never revisiting
Companies rebrand, move domains, change descriptions. Structured data is rarely updated alongside, and stale identity assertions can persist for years.
Consistency is the whole point
Before adding anything, it is worth auditing what you already assert. Sites frequently carry two or three subtly different descriptions of themselves, written years apart by different people, all still live. Resolving that costs nothing and removes real ambiguity.