The short answer
Organization schema should identify the business with a stable name, canonical URL, logo, and only verified properties that match visible site content and authoritative profiles.
Business outcome
Search systems receive a clean, machine-readable identity that matches what customers and third-party profiles already see.
The process
Build it in five passes
Choose the canonical entity page
Use the homepage or a durable about page as the main entity URL. Decide the canonical legal or public name, preferred brand name, website URL, logo asset, and primary contact information before writing JSON-LD.
Reconcile visible facts
Compare the website header, footer, contact page, legal pages, Google Business Profile when relevant, major directories, social profiles, and company records. Resolve conflicting names, addresses, phone formats, and URLs at their source.
Add only supported properties
Start with `@type`, `@id`, name, url, and logo. Add alternateName, sameAs, address, contactPoint, or founding information only when true, stable, and useful. Fewer accurate properties are better than many speculative ones.
Connect page-level entities
Reference the same organization `@id` from Article, Dataset, Product, or other relevant markup. Do not create a slightly different organization object on every page. Keep structured data consistent with visible authorship and publisher information.
Validate meaning and syntax
Run syntax validation, Google's relevant structured-data tools, and a manual visible-content check. Monitor Search Console after release, but remember that valid markup does not guarantee a rich result or AI citation.
Before it ships
Quality checklist
- The public name, URL, and logo match visible site content.
- The `@id` is stable and reused across relevant page markup.
- Every `sameAs` URL is an official profile for the same organization.
- Contact and address details are current and publicly supportable.
- No awards, ratings, reviews, or credentials are fabricated or self-declared improperly.
- JSON-LD passes syntax validation and a human truth check.
Copyable artifact
Organization JSON-LD starter
Replace every placeholder, remove unsupported properties, and render this only where it accurately describes the visible organization.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.example.com/#organization",
"name": "Example Company",
"alternateName": "Example",
"url": "https://www.example.com/",
"logo": {
"@type": "ImageObject",
"url": "https://www.example.com/logo.png",
"width": 512,
"height": 512
},
"sameAs": [
"https://www.linkedin.com/company/example"
],
"contactPoint": {
"@type": "ContactPoint",
"contactType": "customer service",
"email": "support@example.com"
}
}
</script>Validation
How you know it is ready
- 01Every value can be confirmed on the site or an authoritative organization-controlled profile.
- 02No page emits conflicting organization IDs for the same business.
- 03The markup remains valid after the production framework renders it.
Do not overclaim
Google says no special schema is required for generative AI features. Organization markup can clarify identity and support search features, but it is not an AI-ranking switch or substitute for useful evidence.
Questions
What teams usually ask
Where should Organization schema appear?
A common pattern is one canonical organization object in the global site markup, with relevant pages referencing its stable `@id`. Avoid conflicting duplicates.
Should every social profile go in sameAs?
No. Include authoritative profiles that clearly represent the same organization. Do not use loose mentions, review pages, or unrelated directory results as identity claims.
Does Organization schema make AI recommend a company?
No. It can clarify machine-readable identity, but recommendation also depends on relevance, evidence, access, external sources, and engine-specific systems.
Sources reviewed