Most Organization markup on SaaS sites carries three things. A name, a logo and a URL. All three were already obvious from the page, which means the markup added nothing a parser did not have.
The fields that do the work are the ones connecting you to records that exist outside your own domain. Those are mostly left blank, and filling them in is an hour of work that changes whether you are treated as a thing or as a string.
What the markup is actually for
Not ranking. Disambiguation.
Company names are rarely unique. There are multiple businesses called Apex, several called Northbeam, and a great many whose names are ordinary English words. When an engine encounters your name in a third-party article, it has to decide which company that refers to before it can attribute anything to you. Get that wrong and your customer’s case study is credited to a firm in another industry.
Identifiers solve that. A record on your site pointing at the same company in three independent databases makes the match verifiable rather than probabilistic. Why that resolution step matters at all is covered in what an entity is in AI search, and this page is the narrow practical version of it.
The test for whether a field is worth adding. Would this value help somebody decide that two mentions refer to the same company? Name and logo fail that test because every company has them. A registration number passes it immediately.
The fields, ranked by what they carry
| Field | What it does | Worth it? |
|---|---|---|
sameAs | Points at the same company in independent records | The single most valuable field. Almost always blank |
legalName | The registered name, often different from the trading name | High. Resolves the filings-versus-marketing mismatch |
identifier | Company number, LEI, VAT or similar | High. A verifiable key rather than a string |
foundingDate | Separates you from a namesake of a different vintage | Moderate, and free |
address | Geographic disambiguation | Moderate. Matters more for common names |
numberOfEmployees | Size band | Low, and goes stale. Use a range or omit |
name, logo, url | Restates the page | Required, carries nothing |
slogan, description | Marketing copy in a structured wrapper | Near zero. Skip |
The vocabulary itself is defined at schema.org, and it is worth reading the property list once rather than copying a generator’s output. Generators produce the universal fields and skip the discriminating ones, which is exactly backwards.
What to put in sameAs
This is the field that matters, so be deliberate. You want records maintained by somebody other than you, because a link to a page you control corroborates nothing.
Good targets, roughly in order of value. Your Wikidata item if one exists, because it is the structured record other systems actually consult. Your company registry entry. Your Crunchbase profile. Your LinkedIn company page. Your GitHub organisation if you publish code.
Skip social profiles that nobody maintains and any directory that will accept a listing from anyone. A link to a low-quality aggregator does not strengthen the claim and adds a maintenance burden.
The identifier field, which almost nobody uses
Most jurisdictions issue a company number and it is public. That number is a far stronger identifier than your name, because it was assigned by somebody with no interest in your marketing.
If you operate at any scale in financial markets you may also have a Legal Entity Identifier, a twenty character code designed precisely for the problem of working out which legal entity a name refers to. The background on why the LEI exists is worth five minutes, because the problem it was created to solve after the financial crisis is structurally the same problem an AI engine has when it reads your name.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Northbeam",
"legalName": "Northbeam Software Limited",
"url": "https://example.com/",
"logo": "https://example.com/logo.png",
"foundingDate": "2019-04-11",
"identifier": [
{ "@type": "PropertyValue", "name": "Companies House", "value": "11938204" },
{ "@type": "PropertyValue", "name": "VAT", "value": "GB328471920" }
],
"address": {
"@type": "PostalAddress",
"streetAddress": "14 Bridge Street",
"addressLocality": "Manchester",
"postalCode": "M3 3AB",
"addressCountry": "GB"
},
"sameAs": [
"https://www.wikidata.org/wiki/Q000000000",
"https://find-and-update.company-information.service.gov.uk/company/11938204",
"https://www.crunchbase.com/organization/northbeam",
"https://www.linkedin.com/company/northbeam",
"https://github.com/northbeam"
]
}Put it once, on a single canonical URL, with a stable @id. Then reference that @id from your other markup rather than repeating the whole block on every page. Duplicated organisation blocks with drifting values are worse than one block, because they create three slightly different claims about the same company.
Identifiers only help if the records they point at agree with each other.
The common failure is not missing markup. It is markup pointing at four records that disagree about your founding year, your legal name and your headquarters, which leaves an engine with more ambiguity than it started with. Nobody owns checking this internally, so nobody does.
Reconciling those records across the sources engines actually read is part of our free AI visibility check. You get the list of contradictions and where each one lives, whether or not you ever work with us.
Five ways this goes wrong
Markup that disagrees with the page. The block says one founding year, the about page says another. This happens constantly because the markup was written once and the copy was updated twice. Audit both together or the structured version quietly becomes fiction.
Organization on every page with different values. A plugin emits the block sitewide and a template variable makes the description differ by section. Now there are forty organisation records. Use one canonical block and reference it.
Confusing Organization with the product. The company and the software are different entities. If you mark the company up as the thing being sold, engines conflate the two and pricing gets attributed to the legal entity. Use SoftwareApplication or Product for the product, and link the two properly.
Filling numberOfEmployees precisely. It is wrong within a quarter and stale markup is worse than absent markup, because it is confidently wrong rather than silent.
sameAs pointing at your own properties. Your blog, your docs site and your status page are all you. Listing them corroborates nothing. The field is for independent records.
Where it sits relative to everything else
Low effort, real but bounded value, and it is not a substitute for anything. An hour of work that removes ambiguity about who you are. It will not get you named in a category answer and it will help ensure that when you are named, the things said about you are attributed to the right company.
Do it after crawler access and after passage structure, both of which gate more. The order for the whole technical programme is in the AEO technical playbook, and the broader question of which schema types repay the effort is in what matters and what does not in schema.
One last thing. Set a calendar reminder for every six months to check that the records in your sameAs list still say the same things about you that your site does. Companies change address, rename legal entities and raise funding, and the structured record is the last thing anybody updates. A contradiction between your markup and a registry is resolved in favour of the registry, which is the correct outcome and rarely the one you wanted.
Related reading
- Your about page is an entity document. The prose counterpart to this markup, on the page that should carry the same facts.
- What a knowledge graph holds. Where these identifiers end up and why an engine consults them before naming anybody.
- Answer-first writing. The editing side of making a page legible, which gates more than markup does.
Shaban runs answer engine optimisation for B2B SaaS companies at Uncited Brands. He works the unglamorous end of the problem, mostly crawler access, retrieval diagnostics and measurement baselines, and publishes the tests that do not go his way alongside the ones that do.