What Is worksFor Schema?

worksFor is the Schema.org property that connects a Person to an Organization the person works for.

It expresses an employment relationship from the worker’s profile toward the employer. The subject must be Person and the value must be Organization. The property can strengthen consistency across team pages, author profiles, expert biographies, company leadership pages, and content bylines when the employment claim is current and visible. It does not by itself describe a job title, employment dates, founder status, ownership, affiliation, alumni relationship, or membership.

• Place worksFor on Person.
• Use Organization as the value.
• Publish only a current, supported employment relationship.

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 worksFor.

worksFor identifies the employer; other properties and role structures explain what the person does and when.

worksFor is used on Person and expects an Organization value.

It should not be placed on Organization to list employees, on JobPosting to name the hiring company, or on CreativeWork to identify an author. Organization can use employee, JobPosting can use hiringOrganization, and CreativeWork can use author. A shared Person entity may appear inside many page types, but the worksFor property still belongs inside that Person node. Correct placement keeps employment, hiring, authorship, and organizational rosters from collapsing into one relationship.

1. Identify or reference the Person node.
2. Create or reference the employer Organization.
3. Add worksFor inside the Person entity.
4. Use the page-specific property for author, employee, or hiring relationships.

• 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 worksFor from Person to employer and preserve the distinct relationships surrounding that person.

worksFor identifies an employment relationship, while affiliation describes a broader Person-to-Organization connection that may not be employment.

A staff member, executive, or employee profile generally fits worksFor. A visiting scholar, advisory participant, external fellow, clinical affiliate, club member, or institute-associated expert may fit affiliation if the source uses that relationship. Contractors require careful judgment: working on a project for a client does not always mean the person works for the client. Model the actual public relationship rather than stretching one property to cover every professional association.

• Use worksFor when employment is explicit.
• Use affiliation for a genuine non-employment institutional link.
• Do not mark every client as an employer.
• Model both only when two distinct relationships truly exist.

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.

Employment belongs in worksFor; broader associations need affiliation or another more accurate property.

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

A team member’s profile can identify the employer with worksFor, and the company’s team page can identify that person through employee. Reciprocal output is optional, but when both exist, canonical ids, current status, role, and visibility must agree. Do not use reciprocity to publish a private workforce directory or imply employment after someone leaves. Shared profile data should drive both directions so one template cannot retain stale information independently.

1. Choose canonical Person and Organization ids.
2. Generate worksFor from the current profile record.
3. Generate employee from an authorized public roster.
4. Compare both directions across rendered pages.
5. Remove or update edges when employment ends.

• 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

The reciprocal graph is useful when one governed employment record keeps both directions current and public by design.

A Person can have multiple worksFor values when the person genuinely works for multiple Organizations and each relationship is current and public.

Portfolio careers, joint appointments, medical practices, academic roles, and part-time employment may support several employers. Do not combine organization names into one Text string or create one synthetic employer entity. Keep each Organization distinct with a stable @id. If a role is historical, use dated role modeling or remove it from a current profile rather than mixing past and present employers. A client list for a freelancer is not automatically an employer list.

• Create one Organization entity per employer.
• Reuse stable ids across pages and locales.
• Separate current and historical roles.
• Keep clients, partners, and affiliations out of worksFor.
• Use role data when title or dates materially matter.

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.

Multiple employers are valid, but every worksFor edge must independently describe a real current employment relationship.

Founders, owners, and contractors should use worksFor only when they also work for the Organization; founding, ownership, and contracting are separate facts.

A founder may actively serve as CEO and therefore work for the company, or may have left operations while retaining founder status. An investor may own part of a company without employment. An independent contractor may provide services without becoming an employee. Use founder or owns relationships where supported, jobTitle or role data for active positions, and worksFor only when the person’s public profile and organization evidence establish employment.

1. Identify founding, ownership, employment, and service roles separately.
2. Check the person’s current operating role.
3. Use founder or owns for those distinct facts.
4. Use worksFor only for actual employment.
5. Review status after leadership transitions.

• 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

Job, founding, ownership, and contracting should remain separate so worksFor never overstates the current relationship.

Author and team profiles should use worksFor from a centralized Person record that is verified against a current employer profile and reused across every publishing template.

An author may appear on articles, category pages, profile pages, structured data, feeds, and localized sites. Copying employer text into each article creates stale and conflicting claims after a role change. Establish one Person @id and one Organization @id, maintain employment in a governed profile system, and let templates reference those identities. Do not infer an employer from an email domain, author topic, third-party bio, or old event program.

1. Resolve the canonical Person identity.
2. Resolve the canonical employer identity.
3. Verify current employment from first-party profiles.
4. Update one governed author record.
5. Render the same ids across articles and profile pages.
6. Retest after role 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

Centralized first-party profile evidence keeps employment claims consistent across every page that reuses the author.

Common mistakes include using the wrong subject or value type, confusing clients or affiliations with employers, keeping former roles current, and duplicating Person or Organization identities.

Teams may put worksFor on Organization, use plain Text instead of Organization, or infer employment from a byline. Shared author templates can retain a former employer for years. Founders, investors, advisors, contractors, and partners are often marked as employees without evidence. Locales and microsites can create separate employer ids that fragment the graph. Validation catches type errors but cannot prove employment currency.

• worksFor placed on Organization or CreativeWork.
• Text used instead of an Organization entity.
• Client, partner, advisor, or investor treated as employer.
• Former employer left as current.
• One Person duplicated across author templates.
• One Organization duplicated by locale or subdomain.

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 technically valid worksFor edge still needs current employment evidence and stable entity identity.