What Is employee Schema?

employee is the Schema.org property that connects an Organization to a Person working for that organization.

It describes employment from the employer’s point of view. A company team page, hospital staff page, newsroom masthead, university department, nonprofit leadership page, or agency directory can use it when the listed person is intentionally public and currently works for the organization. The subject must be Organization and the value must be Person. The property supersedes employees, but it does not replace jobTitle, EmployeeRole, founder, member, or author.

• Place employee on Organization.
• Use Person as the value.
• Publish only current, intentionally public staff relationships.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Primary specification: Schema.org definition for employee.

employee identifies a person working for an organization, while titles, roles, dates, and authorship remain separate facts.

employee is used on Organization and expects Person as its value.

It should not be placed on Person to name an employer, on JobPosting to name the hiring company, or on CreativeWork to identify an author. Person can use worksFor, JobPosting can use hiringOrganization, and CreativeWork can use author. EmployeeRole can add role detail when the relationship requires salary or role-specific information. Correct placement avoids graphs in which a person appears to employ a company or an article appears to employ its writer.

1. Identify the employer Organization.
2. Create or reference the public Person entity.
3. Add employee to the Organization node.
4. Use adjacent properties for role, authorship, and hiring.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Use employee from employer to worker and preserve the distinct relationships around that person.

employee and worksFor describe employment from opposite directions: Organization points to Person with employee, while Person points to Organization with worksFor.

A public team page can emit employee, and the employee’s profile can emit worksFor. Schema.org does not label the pair as a formal inverse, but they should still agree when both are present. Reuse canonical Person and Organization ids and derive both directions from one current staff source. If an offboarded employee disappears from the team page but their profile still points to the company, the graph is stale even though each template validates.

1. Choose canonical ids for employer and person.
2. Generate employee from the public staff record.
3. Generate worksFor from the same employment record.
4. Compare both directions across templates.
5. Update both when employment changes.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Both directions should come from one governed employment record so they change together.

A team page should use employee when it intentionally lists current people who work for the Organization and the relationship is supported by the page and organization records.

Leadership, editorial, clinical, research, customer success, and public spokesperson pages may fit. A complete workforce directory is rarely necessary for SEO and can create privacy, security, scraping, and maintenance risk. Select staff based on the purpose of the public page, not on a database export. Contractors, advisors, founders, volunteers, partners, and board members need relationship-specific judgment rather than automatic inclusion.

• Include people whose public role supports the page purpose.
• Use canonical Person ids for repeat profiles.
• Keep private staff and internal contacts out of markup.
• Do not generate the roster from unrestricted HR data.
• Review status and visibility during offboarding.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

A public team graph should be a curated, current profile surface rather than a machine-readable workforce export.

EmployeeRole can represent a more detailed employee relationship when role-specific facts such as dates, role name, numbered position, salary, or salary currency are genuinely needed and appropriate.

Most public team pages only need Person, jobTitle, and employee or worksFor. EmployeeRole is useful when the role itself is the object being described, especially for structured employment histories or specialized organizational roles. Do not publish private compensation just because EmployeeRole supports salary fields. Do not create role nodes without stable meaning or use them to hide uncertainty about whether someone is actually employed.

1. Decide whether a simple employee edge is sufficient.
2. Create EmployeeRole only for meaningful role detail.
3. Connect the Person and Organization consistently.
4. Add dates or title only when current and supported.
5. Exclude private compensation from public pages.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Use EmployeeRole for real role detail, not as a requirement for every employee or a reason to expose sensitive data.

Founders, advisors, board members, volunteers, owners, and contractors should be marked as employees only when they genuinely work for the Organization in an employment relationship.

A founder can be an active employee, a former operator, or a passive owner. An advisor can support the company without employment. A contractor can provide ongoing services yet remain independent. A board member may govern rather than work as staff. Model founder, owns, affiliation, member, or a role structure where those relationships are more accurate, and omit employee when evidence does not support employment.

• Separate employment from founding and ownership.
• Confirm whether advisors and board members are staff.
• Do not treat every contractor as an employee.
• Use first-party role descriptions and current team records.
• Update after leadership or contract changes.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

employee should reflect actual employment, not every way a person can be connected to a company.

Employee markup should include only people and profile fields intentionally approved for public visibility, with special care for contact details, location, schedules, and sensitive roles.

Structured data can make already-visible information easier to collect at scale. Publishing a complete staff list can increase phishing, impersonation, harassment, recruiting, and physical-security risk. Do not add private email, phone, address, employee id, compensation, internal title, or work schedule merely because the source system has those fields. Central profile controls should determine who appears and what fields are allowed.

1. Define public employee eligibility and approved fields.
2. Use an allowlist rather than exporting HR records.
3. Remove personal contact and internal identifiers.
4. Review sensitive roles and location exposure.
5. Test analytics, caches, feeds, and JSON-LD copies.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

A useful team graph is selective: public identity and role can be enough without exposing workforce data.

Common mistakes include using the wrong subject or value type, publishing private rosters, including non-employees, retaining former staff, duplicating identities, and continuing to emit employees.

Teams may put employee on Person, use Text instead of Person, or generate a public list directly from HR or CRM data. Shared templates can leave an offboarded person on team, author, and structured-data surfaces. Locales and subdomains may create several Person ids for one employee. Advisors, founders, partners, customers, and contractors are often misclassified. Validation catches type errors but not privacy or current employment truth.

• employee placed on Person or CreativeWork.
• Text used instead of Person.
• Full workforce exported publicly.
• Advisor, partner, or contractor mislabeled as employee.
• Former worker left active after offboarding.
• Duplicate Person ids across templates.
• Superseded employees property still emitted.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

A correct employee graph needs valid types, current employment, intentional visibility, and canonical identity.