Organization identity markup

Organization identity markup is the sitewide that says who publishes this site: one stable Organization (and usually a WebSite) with a name, URL, logo, and links to your verified profiles elsewhere. It is the company-level counterpart to Author pages and bylines - authors resolve people; this technique resolves the brand.

Throughout this page, suppose Fernwood is an expense-management company at https://fernwood.example, with LinkedIn, a G2 profile, and a Crunchbase page.

This technique is distinct from the broader Structured data markup playbook. That page covers which types to use where. This page is the how-to for the one entity almost every marketing site should ship once and reuse everywhere.

Why it works

Search engines and AI assistants both need to answer a boring but load-bearing question: is this the same Fernwood as the one on LinkedIn, G2, and that press article? Google's Organization structured data exists specifically to help Google "understand your organization's administrative details and disambiguate your organization in search results." Answer engines inherit the same problem at citation time: a source they cannot pin to a known entity gets hedged, paraphrased carefully, or skipped.

Identity confidence comes from three things working together:

A single canonical entity with a stable @id (for example https://fernwood.example/#org) that every article, product, and breadcrumb can point at as publisher or brand.
A logo and official URL that match what visitors actually see - Google uses logo when deciding which mark to show in results and knowledge panels.
sameAs links to profiles you control on other sites. Those URLs are how machines cross-check that fernwood.example is the Fernwood with employees on LinkedIn and reviews on G2. Silktide's AI schema signals check specifically flags Organization blocks that omit sameAs, because that field is the one that makes identity checkable.

Visible naming matters too. Markup that says "Fernwood" while the header says "FW Expense Cloud" and the footer says "Fernwood Inc." teaches machines to distrust every version. Silktide's AEO reports judge the visible half of this as Clear who and what this is.

What to publish

1. One Organization block, reused sitewide

Publish this on the homepage at minimum. Many CMS setups also emit it on every page via the site header template - that is fine as long as every copy is identical and shares the same @id.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://fernwood.example/#org",
  "name": "Fernwood",
  "legalName": "Fernwood Software, Inc.",
  "url": "https://fernwood.example/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://fernwood.example/brand/fernwood-logo.png",
    "width": 512,
    "height": 512
  },
  "description": "Expense management software for mid-workspace finance teams.",
  "foundingDate": "2019-04-02",
  "sameAs": [
    "https://www.linkedin.com/company/fernwood-example",
    "https://www.g2.com/products/fernwood/reviews",
    "https://www.crunchbase.com/organization/fernwood-example"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer support",
    "email": "support@fernwood.example",
    "url": "https://fernwood.example/support"
  }
}
</script>

Field guidance, aligned with Google's Organization documentation:

Field	What to put
`@id`	A fragment URL you will never change. Every other schema block that mentions the company should reference this `@id`, not invent a new copy.
`name` / `legalName`	The brand name people search for, plus the registered legal name if they differ.
`url`	The canonical homepage, including trailing slash consistency with your redirects.
`logo`	A crawlable, indexable image, at least 112×112 px per Google's logo guidelines. Prefer a mark that still reads on a white background.
`sameAs`	Only profiles you actually control and keep current: LinkedIn company page, Wikipedia/Wikidata if they exist, Crunchbase, major review platforms, official social accounts. Do not invent Wikipedia entries.
`foundingDate`, address, identifiers	Optional but useful for disambiguation when you have them (`iso6523Code`, `naics`, `leiCode`, and similar are documented for this purpose).

If Fernwood were a storefront rather than SaaS, use a more specific subtype such as OnlineBusiness or OnlineStore where it fits - Google recommends subtypes when they apply.

2. A WebSite block on the homepage

WebSite tells engines the site's public name and home URL. Keep it thin; do not stuff it with marketing claims.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://fernwood.example/#website",
  "name": "Fernwood",
  "url": "https://fernwood.example/",
  "publisher": { "@id": "https://fernwood.example/#org" }
}
</script>

Wire publisher (and on product pages, brand) to the Organization @id. That graph pattern - one org, many pages pointing at it - is how you avoid five slightly different "Fernwoods" floating around your templates.

3. Prefer CMS settings over hand-edited scripts

Yoast, Rank Math, and most modern CMS identity settings already emit Organization and WebSite markup from a single "organization name / logo / social profiles" form. Fill that form from the same source of truth as your About page. Hand-maintained JSON-LD drifts: someone renames the product line, the visible site updates, the script block does not, and engines notice the contradiction.

4. Match the visible page

Google's structured data policies require markup to describe content users can see. Your Organization name should match the name in the header and footer. Your logo should be the mark you actually use. Your sameAs URLs should resolve to live, official profiles - dead LinkedIn pages and placeholder social accounts are worse than omitting the link.

Common failure patterns

Organization without sameAs. You declared who you claim to be, but gave machines nothing to verify against. This is exactly what AI schema signals flags.
A new Organization copy on every template with a slightly different name, missing @id, or conflicting logo URL. Pick one record; reference it.
sameAs to pages that are not you - a Wikipedia disambiguation page, a similarly named competitor, or an employee's personal LinkedIn. Only link entities that are unambiguously the organization.
Markup only after JavaScript hydrates. GPTBot and peers often never see it. Ship identity JSON-LD in the initial HTML - see Content readable without JavaScript.
Confusing Organization with LocalBusiness. If Fernwood has offices people visit, add LocalBusiness (or a subtype) on location pages in addition to the sitewide Organization - do not replace the company entity with a single storefront.

How Silktide helps

AI schema signals - flags Organization entities that lack sameAs, and articles that lack dateModified.
Structured data / Structured data validity - whether markup exists and parses.
Clear who and what this is - the AEO report's judgment on visible identity.
Structured data matches the page - honesty between markup and what the visitor sees.

Structured data markup - the full type map this belongs to
Local SEO and Google Business Profile - LocalBusiness on location pages; keep Organization separate
Press kit and newsroom - the human-readable identity page that should match this markup
Wikipedia and Wikidata presence - when encyclopedia sameAs links are earned, not manufactured
Author pages and bylines - Person identity; connect authors with publisher: { "@id": "...#org" }
Review platform presence - the profiles worth listing in sameAs
Machine-readable dates - freshness on the articles your Organization publishes
Organization structured data (Google Search Central)
sameAs (schema.org)