What does a machine know about your company before it reads a single sentence of your copy? Usually your name, your domain and whatever it pieced together from your profiles. Organization schema markup is the one place where you get to state those facts yourself, in a format built to be parsed instead of interpreted.
Most sites ship the organization schema markup their SEO plugin generated in 2019: a name, a URL, a logo and nothing else. That object is not wrong. It is just too thin to settle any question an AI engine might have about which company you are, what you do and who stands behind you.
Start from what Google documents
Google’s Organization structured data documentation is the closest thing to an official spec for how a search engine uses this markup. It says there are no required properties and recommends adding the ones that apply. It also says the markup can help Google understand your organization’s administrative details and disambiguate it in search results, which is the exact job you want done for AI answers too.
The page lists a long set of supported properties: name, alternateName, legalName, url, logo, description, address, contactPoint, email, telephone, sameAs, foundingDate, numberOfEmployees and a set of identifiers such as duns, leiCode, naics, taxID and vatID. You will not need all of them. A local agency has no use for an LEI code. A public company should almost certainly include one.
On AI search specifically, Google has said that no special schema is required to appear in AI Overviews. Microsoft has been more forward. At SMX Munich in March 2025, Bing’s Fabrice Canel said schema markup helps Microsoft’s large language models understand content, as reported by Search Engine Land. Neither statement promises a ranking boost. Both support the practical case: structured facts that match your visible text make your entity easier to resolve.
Which @type you choose matters as much as the fields. Schema.org treats Organization as the parent of dozens of subtypes, including Corporation, NGO, EducationalOrganization, MedicalOrganization and LocalBusiness, which itself splits into hundreds of specific types like Dentist, LegalService and Restaurant. Google’s documentation notes that you should use the most specific subtype that applies. A subtype inherits every Organization property, so you lose nothing by being precise, and you give a parser one fewer thing to infer.
Companies with several brands face a harder choice. If you run two product lines under separate names, give each its own Organization object with its own @id, then link them with parentOrganization and subOrganization. Do not cram both brand names into one object’s alternateName array. That tells a machine the two names are the same entity, which is the opposite of what you want when a customer asks an assistant to compare them.
You can also check how AI assistants describe you today, before you change anything. Ask ChatGPT, Perplexity, Gemini and Claude the same three questions: what does your company do, who founded it, and where is it based. Save the answers with the date. Wrong founders, outdated cities and vague category labels are the symptoms Organization markup and its supporting pages are meant to treat. Rerun the same questions a few months after your changes ship. The answers will not flip overnight, because models refresh on their own schedules, but the comparison gives you a before-and-after record that is far more useful than a validator’s green checkmark.
Keep the test fair. Use a logged-out browser or a fresh account so the assistant is not drawing on your own chat history, and ask the questions word for word each time. Small phrasing changes produce different answers, which makes trend-spotting impossible.
The Three-Layer Org Graph
We organize Organization markup into three layers, and we fill them in order. We call it the Three-Layer Org Graph because each layer answers a different question a machine asks, and skipping a layer leaves that question open.
The Identity layer answers “which company is this?” It holds @id, name, legalName, alternateName, url and logo. These fields must match your visible site and your major profiles character for character. If your footer says “Northwind Analytics, Inc.” and your LinkedIn says “Northwind,” pick one as name and put the other in alternateName.
The Proof layer answers “is this company real and established?” It holds foundingDate, address, contactPoint, numberOfEmployees and the official identifiers. These are the facts a journalist would verify before quoting you, and they are the facts a model can cross-check against business registries.
The Relationship layer answers “who and what is this company connected to?” It holds founder, sameAs, parentOrganization, subOrganization and knowsAbout. This is where your entity stops floating and attaches to people, profiles and topics. Our sameAs schema guide covers which profile links belong in that array and in what order.
The order matters because the layers depend on each other. A Relationship layer built on a shaky Identity layer spreads the confusion further. If your markup says your name is “Northwind” and your sameAs array points to a LinkedIn page titled “Northwind Analytics Group,” you have just asked a model to reconcile three names at once. Fix identity first, and every link you add afterward reinforces it.
In audits, we score each layer from zero to five. An Identity score of five means every field is present and matches the visible site and the top three profiles exactly. A Proof score of five means a stranger could verify the company’s existence from the markup alone. A Relationship score of five means founders, profiles and topics are all linked by @id or URL. Most sites we review score four on Identity, one on Proof and one on Relationship, which explains why AI engines describe them vaguely.
The 14 fields, ranked by impact
Ranked by how much each field does to settle your identity, here is the order we fill organization schema markup for clients.
First comes @id, a stable URL on your own domain like https://www.example.com/#organization. It costs nothing and lets every other page reference the same entity. Second is name, matching your visible brand exactly. Third is url, the canonical home page with the right protocol and subdomain. Fourth is logo, a crawlable image URL at least 112 pixels square, which Google’s documentation calls out.
Fifth is sameAs, your official profiles. Sixth is legalName, which matters when your trading name differs from your registered one. Seventh is description, one or two plain sentences that say what you do, written the way you want an AI summary to read. Eighth is founder, ideally as a Person object with its own @id pointing to a founder page, which our person schema markup guide walks through.
Ninth is foundingDate. Tenth is address, as a PostalAddress, even if you only list a city and country. Eleventh is contactPoint with a contactType and an email or telephone. Twelfth is alternateName for acronyms, former names and common misspellings. Thirteenth is knowsAbout, a short list of the topics you want to be associated with. Fourteenth is an official identifier, such as an LEI, DUNS number or national company registration, wherever one exists.
Three mistakes show up in nearly every audit. The first is a logo URL that points to an SVG or a lazy-loaded placeholder that a crawler cannot fetch. Use a PNG or JPG at a stable path. The second is a description copied from a meta description, stuffed with keywords and written for clicks. Write it for a reader who has never heard of you. The third is a founder field that holds only a name string. A string tells a machine there is a person called Jane Doe somewhere in the world. A Person object with an @id, a jobTitle and sameAs links tells it which Jane Doe.
Copy this JSON-LD and edit it
Paste this on your home page or About page, replace every example value, and delete any line you cannot fill truthfully. An empty or invented field does more harm than a missing one.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.example.com/#organization",
"name": "Northwind Analytics",
"legalName": "Northwind Analytics, Inc.",
"alternateName": ["Northwind", "NWA"],
"url": "https://www.example.com/",
"logo": "https://www.example.com/images/logo-512.png",
"description": "Northwind Analytics builds revenue forecasting software for mid-market SaaS finance teams.",
"foundingDate": "2019-03-01",
"founder": { "@id": "https://www.example.com/about/jane-doe/#person" },
"address": {
"@type": "PostalAddress",
"addressLocality": "Austin",
"addressRegion": "TX",
"addressCountry": "US"
},
"contactPoint": {
"@type": "ContactPoint",
"contactType": "press",
"email": "press@example.com"
},
"numberOfEmployees": { "@type": "QuantitativeValue", "value": 48 },
"knowsAbout": ["revenue forecasting", "SaaS financial planning"],
"sameAs": [
"https://www.linkedin.com/company/northwind-analytics/",
"https://www.crunchbase.com/organization/northwind-analytics",
"https://www.wikidata.org/wiki/Q00000000"
]
}
</script>Two choices in that template are deliberate. The contactPoint uses “press” as its type, which tells anyone parsing the page where media inquiries go. And founder references an @id instead of repeating the full Person object, so the founder’s details live in one place and cannot drift.
If you use an SEO plugin that outputs its own Organization object, check the page source before you paste anything. Two competing Organization objects with different @id values on the same page create the exact ambiguity you are trying to remove. Either turn off the plugin’s output or extend it through the plugin’s settings so one complete object ships.
Keep the graph consistent after launch
Organization markup decays the same way an About page does. Someone changes the tagline, the company moves cities, a cofounder leaves, and the JSON-LD keeps saying what it said on launch day. Contradictions between your markup, your visible text and your profiles are worse than silence, because they give a model two answers to choose from.
Set a quarterly check. Run the page through Google’s Rich Results Test and the Schema Markup Validator, then compare the name, description, address and founder fields against your LinkedIn page, your Crunchbase profile and any registry listing. If any of them disagree, fix the source of truth first and the markup second.
Watch for one more drift source: your own press. When a publication describes you as “a fintech startup” and your markup says “revenue forecasting software,” a model now has a third description. You cannot control every article, but you can make your description specific enough that journalists copy it, and you can include it in every press release and boilerplate you send.
Pair the markup with a page that says the same things in plain text. Our guide to building an entity home page covers that page in detail. Structured data works best as a summary of content a reader can see, not a substitute for it.
The companies that get described correctly by AI engines next year will be the ones that told the machines who they were, in one consistent voice, this year.