Adding Organization schema
Add Organization schema by placing an Organization JSON-LD block in your shared <head>, with a sameAs array linking to your real profiles (LinkedIn, Wikipedia, Wikidata, Crunchbase). Add a linked Person block for named authors. This tells an AI engine who publishes the page and who wrote it. It is the highest-leverage Known fix on most sites, because an engine that cannot resolve who you are will not name you.
- →Put Organization JSON-LD in the shared head so every page inherits it: a one-change template fix.
- →Use sameAs to point at your authoritative profiles so engines can reconcile your identity.
- →Add a Person block for named authors, linked to the organization with worksFor.
- →Serve it as static JSON-LD and confirm it in view-source, because ChatGPT, Perplexity and Claude do not run JavaScript.
Why entity schema is the first Known fix
Known is the pillar that asks "do they know who you are?" An AI engine retrieves a passage, decides it answers the question, and then decides whether to name the source. If it cannot resolve the entity behind the page, it will use the information and leave you unnamed. Organization and Person schema give the engine an unambiguous, machine-readable statement of who published the page and who wrote it, so it can attribute the quote with confidence.
This is a template fix. Adding the block to the layout every page uses attaches entity clarity to the whole site in a single change, which is why it sits near the top of Phase 01 Foundation in the Action Plan. See the-three-pillars for how Known relates to Findable and Trusted, and entity-clarity-and-sameas for the wider entity picture.
The Organization and Person snippet
Use a single @graph so the Person is linked to the Organization by @id. Replace the example values with your own, and keep the @id values stable so other schema on the site can reference them.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Co",
"url": "https://example.com/",
"logo": "https://example.com/assets/logo.png",
"description": "A one-line description of what the organisation does.",
"sameAs": [
"https://www.linkedin.com/company/example-co",
"https://en.wikipedia.org/wiki/Example_Co",
"https://www.wikidata.org/wiki/Q00000000",
"https://www.crunchbase.com/organization/example-co"
]
},
{
"@type": "Person",
"@id": "https://example.com/#jane-doe",
"name": "Jane Doe",
"url": "https://example.com/team/jane-doe",
"jobTitle": "Head of Content",
"worksFor": { "@id": "https://example.com/#organization" },
"sameAs": [
"https://www.linkedin.com/in/janedoe",
"https://x.com/janedoe"
]
}
]
}
</script>On an article, reference the same Person as the author so the byline is machine-readable too:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "The page's exact H1",
"datePublished": "2026-09-27",
"dateModified": "2026-09-27",
"author": { "@id": "https://example.com/#jane-doe" },
"publisher": { "@id": "https://example.com/#organization" }
}
</script>Getting sameAs right
sameAs is the array of authoritative URLs that describe the same entity, and it is what lets an engine reconcile the entity on your page with the one it already knows.
- Link only profiles that genuinely belong to the entity. LinkedIn, Wikipedia, Wikidata and Crunchbase are strong for an organisation; LinkedIn and a primary social profile suit a person.
- Keep the details consistent. The name, logo and URL in your schema should match what those profiles say. A Wikidata or Wikipedia entry, where one exists, is a particularly strong anchor because engines lean on it to disambiguate.
- Do not pad the list. Five accurate, owned profiles beat twenty loosely related links. Consistency is the signal, not volume.
Put it in the shared head, not the body
Place the block in the <head> of your shared layout so every page inherits it from one edit. That keeps it a template fix rather than something you repeat per page. See template-fixes-vs-page-fixes for why site-wide changes move your score first.
Two placement rules matter for AI engines:
@id, and reference that @id from author, publisher and page-type schema elsewhere, rather than redefining the organisation on every page.Verify it in view-source
Adding the markup is not the same as engines seeing it. Confirm it the way a non-JavaScript engine reads the page.
view-source: before the URL. The inspector shows the DOM after JavaScript runs and will mislead you.