Organization, Person & Brand Schema

Organization, Person, and Brand schema all serve the same underlying purpose: telling Google precisely who or what an entity is, and disambiguating it from every other entity that might share its name. Google’s own documentation frames it that way directly, adding organization structured data “can help Google better understand your organization’s administrative details and disambiguate your organization in search results” (Organization structured data). Done well, this is genuinely useful, currently-relevant work. Done as a numbers game promising a specific Knowledge Panel outcome, it’s fabrication, and this guide won’t do that.

Organization vs LocalBusiness: when to use each

LocalBusiness (or one of its more specific subtypes, like Restaurant or Dentist) is the right choice when customers visit a physical location and that address is a meaningful part of how they find or evaluate the business. Organization is the better fit when there’s no single relevant address, an ecommerce business, a service company that travels to customers, or any company operating without a defining physical location tied to the brand.

Both types are eligible for Google’s supported rich result features. LocalBusiness is a schema.org subtype of Organization, so the two aren’t fully separate categories, and some sites legitimately use both: Organization markup on the corporate “About” page describing the company as a whole, and LocalBusiness markup on individual location pages. Use the most specific type available rather than defaulting to the generic one when a more precise subtype exists, a coffee shop should use CafeOrCoffeeShop rather than the generic LocalBusiness, and a law firm should use LegalService rather than Organization, if a matching subtype exists.

A common real-world case is a national or online-first company that also operates a small number of physical offices, a SaaS company with one headquarters, for instance. That’s usually still an Organization, since the address isn’t the reason customers find or evaluate the business, unlike a retail storefront where foot traffic and a mappable address are central to how the business actually operates. When in doubt, the test is whether a customer’s decision to visit a specific address is part of how they use the business.

Minimal vs comprehensive Organization implementation

A minimal, valid Organization implementation needs very little. Google doesn’t require any specific properties, it recommends adding the ones that genuinely apply:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Company",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png"
}

A more comprehensive implementation adds the properties that give Google (and any system reading the markup) a fuller, more disambiguated picture: address, telephone, foundingDate, founder, sameAs (covered below), and contactPoint for structured customer service information. A contactPoint block looks like this nested inside the Organization entity:

"contactPoint": {
  "@type": "ContactPoint",
  "telephone": "+1-555-010-0000",
  "contactType": "customer service",
  "areaServed": "US"
}

There’s no minimum threshold of properties required to be “valid,” more properties simply give Google more to work with. Add what’s accurate and skip what isn’t, rather than padding the block with placeholder values to look complete. A phone number that goes to voicemail with no customer service function, or a foundingDate you’re guessing at because it looks more established, undermines the same disambiguation goal the markup exists to serve.

Person schema for authors and executives

Person schema identifies an individual, most commonly used on author bio pages or as the author property nested inside Article schema. The properties worth populating are the ones that are independently verifiable: name, url (a bio or profile page), jobTitle, worksFor (linking to the Organization), and sameAs for verified external profiles.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Author Name",
  "url": "https://example.com/about/author-name",
  "jobTitle": "Senior Editor",
  "worksFor": {
    "@type": "Organization",
    "name": "Example Company"
  },
  "sameAs": [
    "https://www.linkedin.com/in/authorname"
  ]
}

The honest framing here matters: Person schema doesn’t grant an authority boost by itself. What it does is make an authorship claim machine-readable and connect it to a verifiable identity elsewhere on the web, which is a legitimate, real contribution to how confidently a system (search or otherwise) can associate content with a real, identifiable person. That’s a meaningfully different claim than promising a ranking or trust “boost” tied to a specific number, which is not something Google has published.

sameAs and entity disambiguation

sameAs is the property doing the most genuinely useful, underused work in this entire schema category. It’s an array of URLs pointing to other verified profiles for the same entity, a Wikipedia page, a Wikidata entry, an official LinkedIn or Crunchbase profile, verified social accounts, tying your organization or person markup to profiles Google (and its Knowledge Graph) can cross-reference.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Company",
  "url": "https://example.com",
  "sameAs": [
    "https://en.wikipedia.org/wiki/Example_Company",
    "https://www.wikidata.org/wiki/Q00000000",
    "https://www.linkedin.com/company/example-company",
    "https://twitter.com/examplecompany"
  ]
}

The mechanics worth getting right: only include profiles that are actually verified and actually belong to the entity in question, list the canonical URL for each profile rather than a redirect or a regional variant, and update the list if a profile is deprecated or replaced rather than leaving a dead link in the array indefinitely. sameAs is a disambiguation signal, not a link-building opportunity, and padding it with low-relevance directory listings undermines the thing it’s meant to do.

This same logic applies to Person entities, not just Organizations. An author’s sameAs array pointing to a verified, active LinkedIn profile or an official publication byline page does real disambiguation work, especially for a common name where multiple people share it. A sameAs link to an abandoned social account, or a profile that doesn’t actually belong to the person (a common mistake when a writer shares a name with someone more prominent), does the opposite of what the property is for, it actively misattributes the entity rather than clarifying it. Treat every sameAs URL as a claim you’re making on the record, verify it belongs to the right entity before adding it, not after.

Brand within Organization and multi-brand structures

For a company operating multiple distinct consumer-facing brands, Brand is a separate schema.org type nested inside Organization or attached to individual Product entries, letting you distinguish “the company that makes this” from “the brand name a customer recognizes on the shelf.” This is worth implementing specifically when a legal/parent entity and its consumer-facing brand name genuinely differ, a holding company and its retail brand, for instance:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example Product",
  "brand": {
    "@type": "Brand",
    "name": "Consumer Brand Name"
  },
  "manufacturer": {
    "@type": "Organization",
    "name": "Parent Holding Company"
  }
}

If your organization’s legal name and brand name are simply the same string, adding a separate Brand block that just restates Organization‘s name property isn’t adding new information, it’s decorative repetition, and can be skipped. The same logic applies to franchise structures: a franchisor’s Organization entity is distinct from each individual franchise location’s LocalBusiness entity, and the relationship between them (branch/parentOrganization) is worth marking up explicitly rather than treating every location as an unconnected standalone business, since that connection is part of what genuinely helps disambiguate one location from a competitor with a similar name in a different city.

Knowledge Panels: what schema can plausibly influence

A Knowledge Panel is the summary box Google sometimes displays alongside search results for a well-known entity, pulling from multiple sources including but not limited to a site’s own structured data. Google’s Knowledge Panel help documentation describes claiming and suggesting edits to an existing panel, but Google has not published a formula, weighted or otherwise, for how a panel gets generated or when one appears for a given entity in the first place (Knowledge Panel Help).

What can plausibly help, based on how Google describes the underlying systems, is consistency and verifiability: accurate, consistent Organization/Person markup across your own site, a complete and accurate sameAs set pointing to profiles Google’s Knowledge Graph already trusts, and genuine third-party coverage and citations that corroborate the same facts your markup states. None of that is a guarantee, and none of it comes with a specific timeline or a minimum operating history requirement, Google has never published one, so treat any claim of a required minimum age or a specific weighting between these factors as unsupported until a real source turns up.

If your organization already has a Knowledge Panel and something in it is wrong, the fix isn’t better schema markup, it’s Google’s actual correction process: claim the panel through the verification flow in Knowledge Panel Help, then use “Suggest an edit” for specific factual corrections. That’s a separate, direct channel from structured data, and it’s the one Google has documented as actually leading to a change, rather than waiting for a schema update to eventually be reflected. Schema markup contributes to how confidently Google can construct or corroborate a panel in the first place; it isn’t the editing interface for one that already exists.

Quick reference: which type fits which situation

Situation	Type to use
Physical location customers visit (retail, restaurant, clinic)	<!–INLINECODE44–> (or its most specific subtype)
No single relevant address, SaaS, e-commerce, service that travels to customers	<!–INLINECODE45–>
Author bio page or byline attribution	<!–INLINECODE46–>
Parent company's legal name differs from its consumer-facing product name	<!–INLINECODE47–>, nested inside <!–INLINECODE48–> or <!–INLINECODE49–>
Franchise network	<!–INLINECODE50–> for the franchisor, <!–INLINECODE51–> per location, connected via <!–INLINECODE52–>/<!–INLINECODE53–>

Conclusion

The mechanically real, useful work in this category is precise entity typing (Organization vs. LocalBusiness), accurate sameAs disambiguation, and honest Person markup tied to verifiable identity. None of it comes with a guaranteed Knowledge Panel outcome or a published scoring model, and any content promising one is inventing a precision Google hasn’t provided. For checking that any of this markup actually validates, see the structured data troubleshooting and validation guide.