Schema Markup Is About Entities, Not Just Pages — How @id, Organization Hierarchies, and Person Authorship Actually Work

Schema markup for a LocalBusiness with hundreds of locations requires different thinking than schema for a single-location business — because the decisions about how to represent the organization, which entity types to use, and where to place the markup affect both rich result eligibility and how Google constructs the Knowledge Graph entity for the business

The previous articles on this site covered schema markup basics, which schema types produce rich results, E-E-A-T and structured data, schema validation vs rich results eligibility, and the FAQ schema changes. This article addresses multi-entity schema strategy — how to correctly represent organizations with branches, parent-subsidiary relationships, and the Person vs Organization authorship distinction that affects E-E-A-T signals.

The Organization and LocalBusiness hierarchy

Google's Knowledge Graph represents real-world entities and their relationships. Schema markup helps Google understand these relationships for your pages. For multi-location businesses, the entity structure matters:

Single entity with multiple locations (most retail, franchise, or branch networks):

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme Corporation",
  "url": "https://acme.com",
  "logo": "https://acme.com/logo.png",
  "hasOfferingOf": "...",
  "department": [
    {
      "@type": "LocalBusiness",
      "name": "Acme London",
      "address": {...},
      "telephone": "...",
      "openingHours": "..."
    }
  ]
}

Alternatively, individual LocalBusiness schemas on each location's page:

• Homepage: Organization schema representing the brand
• Each location page: LocalBusiness schema with its specific address, hours, phone number

The general principle: Organization schema belongs on the homepage and sitewide template. LocalBusiness schema belongs on the specific location pages. These can reference each other using @id properties to signal they're related entities.

Using @id for entity disambiguation

Schema markup without @id properties creates anonymous entities — Google may struggle to determine whether a "Acme Corporation" in an Article's author field is the same entity as the "Acme Corporation" in the Organization schema on the homepage.

@id allows you to define an entity once and reference it elsewhere:

// On the homepage or in the sitewide schema
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://acme.com/#organization",
  "name": "Acme Corporation",
  "url": "https://acme.com"
}

// On an article page, referencing the same organization
{
  "@type": "Article",
  "publisher": {
    "@type": "Organization",
    "@id": "https://acme.com/#organization"
  }
}

The @id acts as a persistent identifier for the entity — any schema block that references https://acme.com/#organization is pointing to the same entity, regardless of which page it's on. This helps Google consolidate signals about the same entity across pages.

Person vs Organization for authorship: the E-E-A-T dimension

Articles should have authors. The choice between Person and Organization as the author type carries E-E-A-T implications:

Person author (preferred for editorial content):

{
  "@type": "Article",
  "author": {
    "@type": "Person",
    "name": "Jane Smith",
    "url": "https://acme.com/team/jane-smith",
    "sameAs": [
      "https://www.linkedin.com/in/jane-smith",
      "https://twitter.com/janesmith"
    ]
  }
}

Why Person is preferred: individual authors have verifiable expertise (professional credentials, publication history, subject-matter background) that Google can evaluate for E-E-A-T. "Jane Smith, certified financial planner" signals more relevant authority for a finance article than "Acme Corporation." The sameAs array linking to the author's LinkedIn and Twitter profiles helps Google confirm the author's identity and credentials across sources.

Organization as author: acceptable for corporate content, press releases, and clearly institutional content — but weaker E-E-A-T signal than named Person authorship for editorial or advice content.

BreadcrumbList schema: the site structure signal

BreadcrumbList schema communicates the hierarchical location of a page within the site's structure. It's not just about the visual breadcrumb — it provides Google with site structure information that helps with understanding content organization.

Correct BreadcrumbList for a nested page:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Category",
      "item": "https://example.com/category/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Specific Article",
      "item": "https://example.com/category/article/"
    }
  ]
}

The last item (the current page) technically doesn't require an item URL (since it's the current page), but including it makes the schema more explicit and easier to validate.

Combining multiple schema types on one page

A single page can and should have multiple schema types when multiple entity types are relevant. A blog post page legitimately includes:

• Article (the content type)
• BreadcrumbList (the navigation structure)
• Person (the author entity, often as a nested block inside Article)
• WebSite (on the homepage, with SearchAction for sitelinks search box)

Using @graph to combine them clearly:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://example.com/article/#article",
      "headline": "...",
      "author": {"@id": "https://example.com/team/jane/#person"}
    },
    {
      "@type": "Person",
      "@id": "https://example.com/team/jane/#person",
      "name": "Jane Smith"
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [...]
    }
  ]
}

The @graph wrapper groups related schema blocks, making the entity relationships explicit and the JSON-LD easier for validators to parse.

How to use the Schema Generator on sadiqbd.com

1. Generate the appropriate type for each page: use Article for blog content, Product for e-commerce, LocalBusiness for location pages, Organization for the brand homepage — match the schema type to what the page is actually about
2. Add @id values to primary entities (Organization, Person, WebSite) so they can be referenced consistently across other schema blocks on other pages
3. Validate in Google's Rich Results Test: after generating and implementing, verify in the Rich Results Test (search.google.com/test/rich-results) — this confirms syntax validity and shows which rich result types the page is eligible for

Frequently Asked Questions

Should I use Schema.org's sameAs to link to Wikipedia, Wikidata, and other authority sources? Yes — for organizations and persons with genuine external presence. sameAs tells Google "this entity is the same as the entity described at these other URLs." Linking to a Wikipedia article, a Wikidata entry, a Companies House record, or an official government registration helps Google confidently identify and understand the entity, which strengthens Knowledge Graph association and can contribute to E-E-A-T signals. For businesses, link to the official Companies House page (UK), SEC EDGAR filing (US public companies), or official regulatory registration. For authors, link to LinkedIn, verified social profiles, or professional organization member pages. Don't fabricate sameAs links to entities that aren't genuinely the same entity — this would be misleading markup.

Is the Schema Generator free? Yes — completely free, no sign-up required.

Try the Schema Generator free at sadiqbd.com — create JSON-LD structured data for Article, Product, LocalBusiness, FAQ, and more.