Advanced Person and Organization Properties

Most Person and Organization schema implementations look the same: name, url, logo, maybe a description. That covers about 5% of the available properties. The other 95% is where entity recognition lives.

Schema.org defines dozens of properties for Person and Organization types that most people ignore. Each one is a machine-readable entity attribute. Each one creates or strengthens an edge in the knowledge graph. This session covers the properties that matter most for recognition.

Person Schema: Beyond the Basics

The Person type in Schema.org supports properties that describe what someone knows, where they studied, what they have achieved, and who they work with. Here are the properties that directly support entity recognition.

Organization Schema: The Full Picture

Organization schema carries its own set of recognition-building properties. If you run a company, agency, or brand, these properties declare your organizational identity in ways that basic schema never touches.

Key Organization properties for recognition include: founder (linking the organization to its founding entity), numberOfEmployees (organizational scale), foundingDate (establishing timeline), areaServed (geographic scope), knowsAbout (organizational expertise), hasOfferCatalog (products and services), and subOrganization (brand hierarchy).

Connecting Person to Organization

The real power comes from linking Person and Organization schemas together. When your Person schema references your Organization via worksFor or founder, and your Organization schema references your Person via founder or employee, you create a bidirectional relationship that search engines can traverse.

Notice how knowsAbout appears on both the Person and Organization. This is intentional. When both your personal entity and your organizational entity declare the same topical associations, the signal is reinforced. The system sees two connected entities both claiming the same expertise.

Implementation Example

A minimal Layer 1 Person schema might look like this:

{
  "@type": "Person",
  "name": "Jane Smith",
  "url": "https://janesmith.com"
}

A Layer 2 Person schema expands it significantly:

{
  "@type": "Person",
  "name": "Jane Smith",
  "url": "https://janesmith.com",
  "jobTitle": "Entity SEO Strategist",
  "worksFor": { "@type": "Organization", "name": "Smith SEO", "@id": "https://smithseo.com/#org" },
  "knowsAbout": ["entity SEO", "knowledge graph optimization", "structured data strategy"],
  "hasOccupation": { "@type": "Occupation", "name": "SEO Strategist", "occupationalCategory": "15-1252" },
  "alumniOf": { "@type": "CollegeOrUniversity", "name": "MIT" },
  "memberOf": { "@type": "Organization", "name": "Search Engine Professionals Association" },
  "award": "Best Entity SEO Campaign 2025",
  "sameAs": ["https://linkedin.com/in/janesmith", "https://twitter.com/janesmith", "https://www.wikidata.org/wiki/Q123456"]
}

The second version creates at least 10 entity edges. The first creates zero. Both validate. Only one builds recognition.

Specificity Matters

Vague declarations are weak signals. knowsAbout: "marketing" tells the system almost nothing. knowsAbout: "entity-first SEO strategy for B2B SaaS" tells it exactly where you sit in the topical landscape. The same principle applies to every property. A jobTitle of "Consultant" is noise. "Entity SEO Strategist" is a signal.

Use specific terms that match how your industry describes itself. If you are building schema for a law firm, use the actual practice areas. If you are building it for a restaurant, use the cuisine types. Specificity is what separates a useful entity declaration from a generic one.

Further Reading

• Person Type Documentation (Schema.org)
• Organization Type Documentation (Schema.org)
• Organization Schema Markup (Google Search Central)
• How to Implement Schema Markup to Increase E-E-A-T (Schema App)