Person Schema vs Organization Schema: When to Use Which

The question sounds trivial until you sit down to write the JSON-LD. Are you the entity, or is your company the entity, or are you somehow both at once? Schema.org has a firm answer, and it is not a matter of preference.

Two different questions, not one choice of label

Person and Organization are separate branches of the schema.org type hierarchy, and they exist to answer different questions. Person schema answers "who is this human, what do they know, where else do they show up." Organization schema answers "what is this legal or commercial entity, who works there, what does it publish." A consultancy with one employee still needs both types, because the human and the business are two different facts that happen to share an address, a phone number and, often, a name.

The confusion usually starts because solo operators write their about page in the first person and their schema in whichever type feels closer. Neither instinct is wrong, exactly, but the schema decision has to follow the facts, not the prose. If a buyer can hire you as an individual, you need a Person entity. If they can also sign a contract with a registered business, you need an Organization entity too. Skipping one because it feels redundant is how the signals engines use to recommend a person end up attached to the wrong node.

Why the wrong choice actually confuses machines

Schema.org properties are type-specific for a reason: an engine parsing your markup checks which properties are legal on which type, and a mismatch is a small but real signal that the markup was assembled carelessly. jobTitle, alumniOf and knowsAbout belong to Person. founder, employee, legalName and numberOfEmployees belong to Organization. Put jobTitle directly on an Organization node and a strict parser either drops it or, worse, a knowledge-graph builder trying to reconcile your markup with public records has to guess whether you meant the company's title or your own.

There is a second, more consequential failure mode: collapsing the two into a single node with a mixed @type array like ["Person","Organization"]. This is technically permitted by the JSON-LD spec, but almost nothing consuming schema.org data expects it for this pairing, because a thing cannot simultaneously be a human being and a registered legal entity. The safer, and far more common, real-world pattern used by publications, directories and knowledge graphs alike is two separate typed nodes connected by a relationship property.

The four situations you will actually encounter

Almost every professional's setup reduces to one of four shapes. Identify yours before writing a single line of JSON-LD.

Pick the row that matches your actual legal and working relationship with the business, not the row that sounds most impressive.

Notice the pattern across every row that involves a company: the relationship is always expressed as a property linking two separate nodes, never as a merged type. This is the same declare-once, reference-everywhere discipline covered for a single entity in the full Person schema JSON-LD guide; here it extends across two entity types instead of one.

How to nest Person inside Organization schema, correctly

The working pattern gives your Person entity a stable @id, then references that @id from the Organization's founder or employee field rather than repeating the whole Person object. Here is a founder case, written for a solo-founded consultancy:

<script type="application/ld+json">
[
  {
    "@context": "https://schema.org",
    "@type": "Person",
    "@id": "https://yoursite.com/#person",
    "name": "Your Name",
    "jobTitle": "Founder",
    "knowsAbout": ["supply chain risk", "vendor audits"],
    "sameAs": [
      "https://www.linkedin.com/in/yourname",
      "https://x.com/yourname"
    ]
  },
  {
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://yoursite.com/#organization",
    "name": "Your Company LLC",
    "url": "https://yoursite.com/",
    "founder": { "@id": "https://yoursite.com/#person" }
  }
]
</script>

Both nodes sit in the same JSON-LD array, each with its own @id, connected by one property. An engine reading this sees one human and one business, correctly related, rather than a single ambiguous blob or two disconnected fragments. If you are the one being employed rather than the founder, flip the direction: the Person carries worksFor pointing at the Organization's @id, and the Organization optionally lists you under employee for the reciprocal link.

Which entity should carry the byline?

When you publish an article, the author field of its BlogPosting or Article schema should almost always point at the Person @id, not the Organization, even if the business's name appears in the byline on the page. Buyers hire people, and citation systems increasingly credit the individual behind a piece of writing, a distinction explored more fully in the difference between a mention, a citation and a recommendation. Reserve the Organization as author only for genuinely unsigned, institutional content, a press release or a terms-of-service page with no single writer attached to it.

Common mistakes worth checking for right now

• One node wearing two hats. A Person entity with a legalName or numberOfEmployees property bolted on, because writing one node felt simpler than writing two.
• Two nodes, no connection. A Person and an Organization both declared correctly but never linked by founder, worksFor or employee, leaving an engine to guess whether they are related at all.
• The company outshining the founder. Every citation-worthy insight attributed to the Organization node, leaving the Person entity thin and hard to recommend by name, the exact failure mode covered in structuring your identity for machines.
• Duplicate near-identical entities. A Person node on the about page and a second, slightly different Person node embedded in the Organization's markup, each missing the other's details, which is how name collisions get manufactured by the site owner rather than by a stranger sharing your name.
• Renaming without updating the link. Rebranding the company changes the Organization's name but the founder reference, and the Person entity behind it, gets forgotten in the migration.

How this choice interacts with trust signals

Once the two nodes are correctly split and linked, the split pays off in a place many people do not expect: how outside signals accumulate. Coverage that names you personally, a podcast appearance, a quoted line in an industry article, a guest byline, should reinforce the Person entity. Coverage that names your company, a funding note, a client case study published by a partner, a directory listing, should reinforce the Organization entity. When the two nodes are merged or left unlinked, all of that reinforcement piles onto one fuzzy blob and an engine cannot tell which fact belongs to the human and which belongs to the business. Keeping them distinct but connected means every mention strengthens the correct entity, and the connecting property lets that strength flow between them anyway, since a well-cited founder makes the company more credible by association, and a well-cited company makes the founder easier to place. This is the same compounding logic that underlies the trust-signal work described in E-E-A-T treated as data rather than as a marketing checklist; the nesting choice here is what determines whether that compounding actually happens or gets diluted across two half-built entities.

The split also matters for anyone who eventually sells, exits, or steps back from the company they founded. If your Person entity was built independently, with its own sameAs cluster, its own knowsAbout list and its own citation history, your reputation as a professional survives the transaction cleanly. If everything was folded into the Organization node from the start, stepping away from the company can strand years of earned recognition inside an entity you no longer control.

Validating the nested structure

Paste the full JSON-LD array into the schema.org validator and confirm it reports two distinct top-level items, a Person and an Organization, each with the properties you expect. Then check the relationship manually: does the Organization's founder or employee field resolve to the exact same @id string used on the Person node, character for character. A trailing slash mismatch between https://yoursite.com/#person and https://yoursite.com#person is enough to silently break the link while both nodes still validate individually, since the validator checks each node's shape, not whether your two @id strings actually match.

Once both nodes validate and the link resolves, the last check is a content check rather than a syntax check: read your about page and your company page side by side, and confirm nothing in either page's visible text contradicts what the schema declares. Mismatched facts between markup and prose undermine both entities at once, a problem covered in general terms across every schema type in how machines connect facts about people.