Short answer: Organization schema is a small block of structured data that tells machines which real company is behind your site: its name, its canonical URL, its logo and the other profiles where it exists, such as LinkedIn or a business registry.
For AI assistants it works as disambiguation, not as a ranking lever: it makes your company easier to identify and attribute, and it does not guarantee a citation, a Knowledge Panel or any visible search feature. It is worth doing once, correctly and consistently, and not worth agonising over beyond that.
What does Organization schema actually do for AI answers?
When an assistant or a search engine reads your site, it sees text. It does not know whether the company name on your homepage is the same company as the one on a directory listing, or a different one with a similar name in another city. Organization markup is you stating the answer in a form a machine can read without guessing.
That is the whole benefit: disambiguation. A consistent entity with sameAs links to profiles that corroborate it is easier for a model or a knowledge graph to resolve and attribute. It is not a ranking factor you can point to, and nobody outside the engines can show that adding it makes an assistant recommend you. Anyone who promises that is selling something the evidence does not support.
Google's Organization documentation lists no required properties, and says the markup does not need to be on every page: the homepage or a single About page is enough. Nothing in it promises a visible search feature. (Google Search Central, Organization)
So the honest framing is cheap hygiene with one real downside risk. The upside is modest and unmeasured. The downside, covered below, is that two pages describing your company differently makes the signal worse than having none.
When does it matter, and when is it the wrong fix?
It matters for any site that represents a company, a product, a publication or an institution. It matters most when the company has more than one web property, because that is where the markup starts to disagree with itself.
- It is the wrong type if the site is a person: A freelancer's portfolio or a solo author blog is about a Person. Marking a person up as an Organization is incorrect. Use a Person node with the same discipline: a stable @id and honest sameAs links.
- It is not why a page is missing from search: If your pages are blocked from crawling, behind a login, or rendered only in JavaScript, Organization markup changes nothing. Fix access first.
- It will not conjure a Knowledge Panel: Google does not promise a Knowledge Panel for any markup. Treat it as an outcome that may follow from being a real, well-documented entity, not as a task you complete.
- It does not need to be everywhere: One full definition on the homepage, and optionally the About page, is enough. More copies means more chances to contradict yourself.
Do not invent facts to fill the schema
No sameAs link to a profile that does not exist, no foundingDate you are guessing at, no logo the company does not use. Markup that does not match reality is worse than missing markup, and it breaks Google's guidelines on describing what is actually true.
What goes in an Organization node?
Only a few properties carry the disambiguation. Everything else is optional and should be included only when it is true and public.
| Property | What it does | Watch out for |
|---|---|---|
| @id | A permanent identifier for the entity, such as https://example.com/#organization | Use a fragment. Using the bare homepage URL collides with the WebSite or WebPage node. Never change it later. |
| name | The name you use everywhere else | It should match your visible site name. Use alternateName for a short form. |
| url | The canonical homepage of the entity | Set it to the site root, not the current page, or every page claims a different organization. |
| logo | An image Google can fetch | At least 112 by 112 pixels, crawlable, and legible on a plain white background. |
| sameAs | Other pages that are genuinely about this company | Only profiles that exist. Linking to your own pages corroborates nothing. |
| description, address, telephone | Plain facts | Add them when true and public, not to look complete. |
Wikidata deserves one honest paragraph. A sameAs link to a Wikidata item is a strong disambiguation signal, but you cannot earn one by markup. If an item already exists for your company, link it. If it does not, do not create one for a company that does not meet Wikidata's notability criteria: self-promotional entries get deleted and can do more harm than good.
Why is consistency a bigger deal than presence?
Most sites that fail here do not have no markup. They have two. A marketing site emits one Organization, the app on a subdomain emits another, and an SEO plugin on the blog adds a third. Each has a slightly different @id, URL or name, and together they describe three companies.
The fix is a modelling decision, not a code trick. Pick one canonical entity, almost always the apex marketing site, and have every other host either say nothing about the organization or repeat the same name, url and @id verbatim. If a product is genuinely a separate company or brand, give it its own @id and point parentOrganization at the main entity, and make that call deliberately. Do not merge two legal entities into one node just to satisfy a checker.
Identical beats clever
Whether an engine will follow a bare reference to an @id on a host it has not crawled alongside yours is not guaranteed. Where it matters, repeat the same name, url and @id in a short node on the subdomain instead of relying on the reference.
How do you add it, in summary?
Choose the canonical @id
Use your homepage URL plus a fragment, for example https://example.com/#organization. It is an identifier, not a page, and it never changes.
Publish the full node once
Put the complete Organization on the homepage, and optionally the About page, as JSON-LD in the served HTML. Include name, url, logo and the sameAs links that really exist.
Make every other page and host agree
Either emit nothing about the organization, or emit a short node with the identical name, url and @id. Never publish a second full definition that differs.
Generate it from one source
Build the JSON-LD from a single config object so it cannot drift between apps. Connect it to your WebSite node in one graph, with publisher pointing at the organization @id.
Check the rendered output
Fetch the live page, count the JSON-LD blocks, and confirm each host reports the same @id, url and name. Run Google's Rich Results Test and the Schema Markup Validator for errors.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Corporation",
"url": "https://example.com/",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/images/logo-512.png",
"width": 512,
"height": 512
},
"sameAs": [
"https://www.linkedin.com/company/example",
"https://github.com/example"
]
},
{
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "https://example.com/",
"publisher": { "@id": "https://example.com/#organization" }
}
]
}That is the shape, trimmed. Stack-specific versions for Next.js, Astro, WordPress and static HTML are in the implementation guide for the agent skill, and the skill can be installed into Claude Code and other coding agents so the agent makes the change in your repository and checks the result.
Read the full implementation guideHow do you know it worked?
There are three layers, and they answer different questions. Be clear about which one you are measuring.
- Is the markup present and consistent?: This is checkable today. Every host should report one @id, one url and one name, and the logo URL should return an image with a 200 status. The AEO Toolkit audit checks presence and cross-page consistency as separate rules.
- Is it valid?: Google's Rich Results Test and the Schema Markup Validator should show no errors on the Organization node. Warnings about missing recommended properties are acceptable.
- Did an engine connect the entity?: This one is slow and uncertain. Passing the audit means the markup is present and self-consistent. It does not mean any engine has used it. The AEO Toolkit's visibility checks sample Perplexity only, so they cannot tell you what ChatGPT, Claude or Gemini do, and a single run is one sample. Watch a trend over weeks and treat any one result as weak evidence.
The source for the agent skill, including the detection logic, is public.
View the skill source on GitHubTo install the skill into an agent, start from the skills index.
See how to install AEO agent skillsWhat are the common mistakes?
- Two plugins, two Organizations: An SEO plugin and a theme or schema plugin each emit one with different ids. Keep one emitter and disable the others.
- An @id that is a page URL: It collides with the WebPage or WebSite node for the same address. Always use a fragment.
- www and the apex disagreeing: Redirect one to the other and set url to the canonical host.
- A wordmark on a transparent PNG: It fails the white-background legibility guidance. Use a logo that reads on white.
- Claiming to be a LocalBusiness to get detected: Use that type only if you serve a physical location. Some audit tools count only the exact type Organization plus LocalBusiness, so if you use a more specific subtype, keep Organization in a type array.
Common questions
Does Organization schema help me show up in ChatGPT or AI Overviews?
It helps an engine identify and attribute your company, which is a precondition for being named accurately. Nobody outside the engines can show that the markup alone causes a citation, and Google lists no required properties and promises no visible feature. Treat it as inexpensive hygiene, not a lever, and measure outcomes separately over weeks.
Where should Organization schema go on my site?
Publish one full definition on the homepage, and optionally on the About page, in JSON-LD inside the served HTML. Google says it does not need to be on every page. Other pages and subdomains should either say nothing about the organization or repeat the same name, url and @id exactly.
What is sameAs and what should I put in it?
sameAs lists other pages on other sites that are genuinely about your organization, such as a LinkedIn company page, a business registry entry, a GitHub organization or an existing Wikidata item. Include only profiles that exist and that clearly describe you. Linking to your own pages corroborates nothing, and a link to a profile that does not exist is a false claim.
Should a freelancer or solo author use Organization schema?
No. A site that is about one person should use a Person node, with a stable @id and honest sameAs links. Marking a person up as an Organization is the wrong type, and Google's author guidance says not to use the wrong one.
Sources
Related guides
Want it done for you
Want this done and re-checked every month? Our monthly maintenance re-runs your buying questions in ChatGPT, Perplexity and Google, ships the fixes that keep you out of the answers, and reports what moved. Or run the free check on your site first at advancelabs.dev/tools/audit.
See how it works