Knowledge Graph Navigator

JSON-LD Schema Examples for Entity SEO and Knowledge Panels

JSON-LD schema examples for entity SEO are complete, valid schema.org blocks that describe an organization, its people, and its content as connected entities, each with a stable @id and sameAs links to identifiers search engines already hold. This page is a template library: every block below parses as JSON, uses only properties schema.org defines for that type, and can be pasted and edited. The syntax itself (@context, @id, @graph, nesting versus referencing) is covered in the JSON-LD guide.

None of these templates produces a ranking change or a knowledge panel by itself. Markup states facts about entities in a form machines can read; Google decides what to show, and rich results are a matter of eligibility for the features on Google’s supported structured data list, not a guaranteed outcome. What consistent markup does is remove ambiguity, so the entities on a site are easier to reconcile with the ones in the Google Knowledge Graph and in Wikidata.

Two conventions run through every example. Fictional entities use example.com or example.edu. Each entity that appears on more than one page gets one @id, written once and referenced everywhere else.

1. Entity home: Organization and WebSite

Use this on the home page, or on whichever page the organization treats as its canonical description. It defines the organization node that every other block on the site will point to.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.example.com/#organization",
      "name": "Example Analytics",
      "legalName": "Example Analytics, Inc.",
      "url": "https://www.example.com/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://www.example.com/assets/logo-512.png"
      },
      "description": "Example Analytics builds data pipelines for research libraries.",
      "sameAs": [
        "https://www.wikidata.org/wiki/REPLACE-WITH-Q-ID",
        "https://www.linkedin.com/company/example-analytics/",
        "https://github.com/example-analytics"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://www.example.com/#website",
      "url": "https://www.example.com/",
      "name": "Example Analytics",
      "inLanguage": "en-US",
      "publisher": { "@id": "https://www.example.com/#organization" }
    }
  ]
}

What to change, and what to leave alone:

  • Replace name, legalName, url, logo and description with values that match the visible site exactly.
  • Replace the placeholder Wikidata URL with the URL of the organization’s real item, or delete the line if no item exists. Never point sameAs at an item for a different entity with a similar name.
  • Keep the #organization fragment once it is published. Changing an @id later severs every reference to it.
  • Keep sameAs to profiles the organization controls or authoritative records about it. Directory listings and press coverage do not belong there.

Detailed property guidance is on the organization schema page.

2. Person and author entity

Use this on an author or staff profile page. The Person node gets its own @id on the profile URL and points to the organization by reference.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://www.example.com/team/jane-doe/#person",
  "name": "Jane Doe",
  "url": "https://www.example.com/team/jane-doe/",
  "image": "https://www.example.com/team/jane-doe/photo.jpg",
  "jobTitle": "Head of Data Engineering",
  "worksFor": { "@id": "https://www.example.com/#organization" },
  "knowsAbout": ["Knowledge graphs", "Entity resolution", "SPARQL"],
  "sameAs": [
    "https://orcid.org/0000-0000-0000-0000",
    "https://www.linkedin.com/in/jane-doe-example/"
  ]
}
  • Change every value to the real person. jobTitle and image should match the profile page.
  • worksFor must reuse the exact @id string from template 1, including the trailing fragment.
  • Use sameAs only for profiles that belong to this person. A shared name is not evidence.
  • Do not add alumniOf, award or honorificPrefix unless the profile page states those facts.

More on author entities is on the Person schema page.

3. Article that references author and publisher by @id

Use this on every article or blog post. The author and publisher are not described here, only referenced.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://www.example.com/blog/entity-resolution/#article",
  "headline": "How entity resolution works",
  "description": "A walk-through of matching records that describe the same real-world entity.",
  "image": "https://www.example.com/blog/entity-resolution/cover.png",
  "datePublished": "2026-02-11",
  "dateModified": "2026-09-08",
  "inLanguage": "en-US",
  "mainEntityOfPage": { "@id": "https://www.example.com/blog/entity-resolution/" },
  "author": { "@id": "https://www.example.com/team/jane-doe/#person" },
  "publisher": { "@id": "https://www.example.com/#organization" }
}

The @id reference is the point of this template. When an article embeds a full Person object, each page creates what looks like a separate person, and any difference between copies (an old job title, a missing sameAs) becomes a contradiction a consumer has to resolve. A reference instead adds one edge to an existing node: this article was written by the same Jane Doe described on her profile page, published by the same organization described on the home page. Across hundreds of articles, the site’s markup converges on one author node and one organization node with many connections, which is the shape a knowledge graph expects.

  • Change headline, dates, image and the URLs. headline should match the visible title.
  • Keep datePublished and dateModified in ISO 8601.
  • Do not inline the author or publisher here once templates 1 and 2 are live.

4. Nested organizations: parentOrganization and subOrganization

Use this when one organization belongs to another: a university and its colleges, a hospital system and its hospitals, a holding company and a subsidiary. parentOrganization and subOrganization are inverse properties on Organization, so either direction states the same relationship.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "CollegeOrUniversity",
      "@id": "https://www.example.edu/#organization",
      "name": "Example State University",
      "url": "https://www.example.edu/",
      "subOrganization": { "@id": "https://engineering.example.edu/#organization" }
    },
    {
      "@type": "EducationalOrganization",
      "@id": "https://engineering.example.edu/#organization",
      "name": "Example State University College of Engineering",
      "url": "https://engineering.example.edu/",
      "parentOrganization": { "@id": "https://www.example.edu/#organization" }
    }
  ]
}
  • On the parent’s home page, publish the parent node with subOrganization. On the college’s home page, publish the college node with parentOrganization. Both pages reference the other by @id.
  • For a company and a subsidiary, use Organization (or a subtype such as Corporation) for both nodes; the properties are identical.
  • Use the child’s own full name. “College of Engineering” alone is ambiguous across thousands of institutions.
  • Do not use department and subOrganization for the same relationship; pick one and apply it site-wide.

5. College or university with CollegeOrUniversity

CollegeOrUniversity is a schema.org subtype of EducationalOrganization, which is itself a subtype of Organization, so every Organization property is available. The example below uses the University of Florida to show a real Wikidata link (Q501758). It is an illustration of the pattern, not the university’s published markup, and the @id would live on whichever page the institution designates as its entity home.

{
  "@context": "https://schema.org",
  "@type": "CollegeOrUniversity",
  "@id": "https://www.ufl.edu/#organization",
  "name": "University of Florida",
  "url": "https://www.ufl.edu/",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Gainesville",
    "addressRegion": "FL",
    "addressCountry": "US"
  },
  "sameAs": [
    "https://www.wikidata.org/wiki/Q501758",
    "https://en.wikipedia.org/wiki/University_of_Florida"
  ]
}
  • Use CollegeOrUniversity for degree-granting institutions. Schools that are not post-secondary have their own subtypes (HighSchool, MiddleSchool, ElementarySchool).
  • Add logo, foundingDate and further sameAs profiles only with values taken from the institution’s own records.
  • Do not mark a program page or an admissions page as the CollegeOrUniversity; those pages reference the institution’s @id.

6. Linking an entity to Wikidata: sameAs, about and mentions

Three properties connect markup to a Wikidata item, and they make different claims. Choosing the wrong one states something false about the page or the entity. Background on Wikidata itself is on the Wikidata page, and the full treatment of identity links is on the sameAs schema page.

Property Domain Claim it makes Correct when
sameAs Thing This node is the entity the URL identifies The node describes exactly that entity
about CreativeWork This work’s subject is that entity The entity is the main topic of the page
mentions CreativeWork This work refers to that entity The entity appears but is not the main topic

sameAs is an identity statement on the entity node itself:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/entities/google/#organization",
  "name": "Google",
  "sameAs": "https://www.wikidata.org/wiki/Q95"
}

about belongs on the page or article and names its primary subject:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://www.example.com/travel/eiffel-tower-guide/#article",
  "headline": "A visitor's guide to the Eiffel Tower",
  "about": {
    "@type": "LandmarksOrHistoricalBuildings",
    "name": "Eiffel Tower",
    "sameAs": "https://www.wikidata.org/wiki/Q243"
  }
}

mentions lists secondary entities the text discusses:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://www.example.com/blog/what-is-a-knowledge-graph/#article",
  "headline": "What is a knowledge graph",
  "about": {
    "@type": "Thing",
    "name": "Knowledge graph",
    "sameAs": "https://www.wikidata.org/wiki/Q33002955"
  },
  "mentions": [
    {
      "@type": "Thing",
      "name": "Semantic Web",
      "sameAs": "https://www.wikidata.org/wiki/Q54837"
    },
    {
      "@type": "Organization",
      "name": "Google",
      "sameAs": "https://www.wikidata.org/wiki/Q95"
    }
  ]
}
  • Put sameAs inside the nested node, never directly on the Article. "sameAs": "...Q243" on an Article would claim the article is the Eiffel Tower.
  • Keep about to one or two entities. A long about list reads as keyword stuffing in graph form.
  • Copy Q-IDs from the Wikidata item page itself and confirm the label before publishing.

7. FAQPage

Use this only on a page that shows a list of questions, each with one answer written by the site. Google limited FAQ rich results to well-known government and health sites in August 2023, so for most sites this markup describes content rather than enabling a visual feature. Check the current supported-features list before expecting any display.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "@id": "https://www.example.edu/admissions/faq/#faq",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "When is the application deadline for fall admission?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Applications for fall admission close on March 1. Late applications are reviewed if space remains."
      }
    },
    {
      "@type": "Question",
      "name": "Is the SAT required?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Test scores are optional for all undergraduate programs."
      }
    }
  ]
}

The rule that matters: every name and text value must match the question and answer visible on the page. Markup for content a visitor cannot see violates Google’s structured data guidelines, and an answer that has drifted from the page text is a contradiction in the data.

  • Use FAQPage for site-authored answers. A page where users submit answers is a QAPage.
  • Do not add FAQ markup to every page with a heading that ends in a question mark.
  • Regenerate the markup from the same source as the visible FAQ so the two cannot drift.

8. One combined @graph for the whole site

This is templates 1, 2 and 3 published together as one graph, as they would appear on the article page. In practice a CMS emits the Organization and WebSite nodes site-wide and adds the Person and Article nodes on the relevant pages. Consumers merge every block on a page, and nodes with the same @id across blocks and across pages are treated as one entity.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.example.com/#organization",
      "name": "Example Analytics",
      "url": "https://www.example.com/",
      "logo": "https://www.example.com/assets/logo-512.png",
      "sameAs": [
        "https://www.wikidata.org/wiki/REPLACE-WITH-Q-ID",
        "https://www.linkedin.com/company/example-analytics/"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://www.example.com/#website",
      "url": "https://www.example.com/",
      "name": "Example Analytics",
      "publisher": { "@id": "https://www.example.com/#organization" }
    },
    {
      "@type": "WebPage",
      "@id": "https://www.example.com/blog/entity-resolution/",
      "url": "https://www.example.com/blog/entity-resolution/",
      "name": "How entity resolution works",
      "isPartOf": { "@id": "https://www.example.com/#website" }
    },
    {
      "@type": "Person",
      "@id": "https://www.example.com/team/jane-doe/#person",
      "name": "Jane Doe",
      "url": "https://www.example.com/team/jane-doe/",
      "jobTitle": "Head of Data Engineering",
      "worksFor": { "@id": "https://www.example.com/#organization" },
      "sameAs": ["https://orcid.org/0000-0000-0000-0000"]
    },
    {
      "@type": "Article",
      "@id": "https://www.example.com/blog/entity-resolution/#article",
      "headline": "How entity resolution works",
      "datePublished": "2026-02-11",
      "dateModified": "2026-09-08",
      "mainEntityOfPage": { "@id": "https://www.example.com/blog/entity-resolution/" },
      "author": { "@id": "https://www.example.com/team/jane-doe/#person" },
      "publisher": { "@id": "https://www.example.com/#organization" }
    }
  ]
}

Read as a graph, this is five nodes and six edges: the WebSite is published by the Organization, the WebPage is part of the WebSite, the Person works for the Organization, and the Article is the main entity of the WebPage, was written by the Person and was published by the Organization. Each edge is a reference, so no entity is described twice.

  • Keep every @id byte-identical across templates, including protocol, www, and trailing slash.
  • If an SEO plugin already emits Organization and WebSite nodes, reuse its @id values instead of adding a second set.
  • Run the output through the tools on the structured data testing tools page after any template change.

For developers

Every template above is a valid RDF document. Loading the combined graph into rdflib or a triple store yields schema.org triples that can be queried with SPARQL, which is a practical way to audit a whole site: crawl every page, extract the JSON-LD, merge it, and query for Person nodes with no worksFor or for more than one distinct name on the same @id. Generate the blocks from the same data objects that render the page and serialize with a JSON library, never by string concatenation.

For SEOs

These templates are the markup half of entity SEO. They work alongside the off-site signals: a Wikidata item that describes the organization accurately, official profiles that link back, and consistent naming across the web. A Google knowledge panel draws on the Google Knowledge Graph, not directly on a page’s markup, so the realistic goal of these blocks is an unambiguous, internally consistent description that matches what other sources say.

Related pages

FAQ

What is the best JSON-LD schema for a company home page?

An Organization node with a stable @id such as #organization, plus a WebSite node whose publisher references that @id. Include name, url, logo and sameAs links to the organization’s Wikidata item and official profiles. Use a more specific subtype, such as CollegeOrUniversity or Corporation, when one accurately describes the organization.

Should the author be nested inside Article schema or referenced by @id?

Referenced, once a Person node exists on the author’s profile page. Nesting the full Person on every article creates many copies that can drift apart. A reference such as author with an @id pointing to the profile’s #person node adds one edge to a single author entity, which keeps the site’s graph consistent across every page.

What is the difference between sameAs and about in schema.org?

sameAs says a node is the same entity a URL identifies, so it belongs on the entity node itself. about is a CreativeWork property saying what a page or article is about, and its value is a separate node for that entity. An article about the Eiffel Tower uses about, and the nested Eiffel Tower node uses sameAs.

Does JSON-LD schema markup get a knowledge panel?

No markup guarantees a knowledge panel. Google builds knowledge panels from the Google Knowledge Graph, which draws on many sources. Consistent Organization or Person markup with accurate sameAs links makes an entity easier to identify and reconcile, but whether a panel appears is Google’s decision. Rich results are similarly a matter of eligibility, not a guaranteed outcome.

Sources and further reading

  • schema.org, Organization: https://schema.org/Organization
  • schema.org, CollegeOrUniversity: https://schema.org/CollegeOrUniversity
  • schema.org, sameAs: https://schema.org/sameAs
  • Google Search Central, Organization structured data: https://developers.google.com/search/docs/appearance/structured-data/organization
  • Google Search Central, Structured data search gallery: https://developers.google.com/search/docs/appearance/structured-data/search-gallery
  • W3C, JSON-LD 1.1: https://www.w3.org/TR/json-ld11/

Powered by CookieAdmin