What Is provider Schema?

The provider schema property identifies the Organization or Person that provides, operates or performs a service, or produces goods associated with the parent entity.

On a Service page, provider answers who actually performs the work. That party may be the same company that sells the service, but Schema.org allows another seller to offer services or goods on the provider’s behalf. The relationship should follow the business’s real operating model.

provider accepts Organization or Person. It is used on Action, CreativeWork, EducationalOccupationalProgram, FinancialIncentive, Invoice, ParcelDelivery, Reservation, Service and Trip. The page should visibly identify the responsible party before the graph makes that connection.

1. Frame the decision raised by What Is provider Schema.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Name the party actually providing the item.
• Use Organization or Person.
• Keep seller and provider roles distinct.

provider schema should connect an item to the party genuinely responsible for delivering or performing it.

The provider property can be used on Action, CreativeWork, EducationalOccupationalProgram, FinancialIncentive, Invoice, ParcelDelivery, Reservation, Service and Trip.

The meaning changes with the parent. On Service, it is the service provider or performer. On Course or another CreativeWork, it can identify the institution providing the content or program. On ParcelDelivery, it identifies the delivery provider. The graph must preserve that context.

Do not add provider directly to Organization merely to repeat the organization itself. Organizations can provide other entities; they are not their own provider statement. Choose the parent item first, then connect the responsible Person or Organization.

• Evidence for Which Types Can Use provider: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Identify the item being provided.
2. Confirm its type supports provider.
3. Identify the responsible party.
4. Connect the entities with visible evidence.

Correct parent context determines exactly what the provider is responsible for.

provider identifies who supplies, operates or performs the service or goods, while seller identifies the party offering a product, service or reservation for sale.

The roles often match in a direct business: an agency both sells and provides its consulting. In marketplaces, resellers and booking platforms, they can differ. A platform may be the seller while an independent company performs the service.

Do not assume the checkout brand is the provider or that the provider processes payment. Review offer terms, fulfillment language and contracts presented on the page. When one entity fills both roles, reuse the same Organization identity rather than creating duplicate nodes.

1. Frame the decision raised by How Is provider Different From seller.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Trace delivery and transaction separately.
• Reuse one identity when roles match.
• Model different parties when they truly differ.

provider answers who fulfills the item; seller answers who offers the transaction.

provider performs or supplies the item, broker arranges an exchange without normally acquiring it, and brand identifies the brand associated with the product or service.

An insurance marketplace may broker policies provided by insurers under distinct brands. A franchise location may provide a service under a national brand. Collapsing all three roles into one Organization creates a graph that is simple but commercially false.

Start from first-party disclosures: who performs the work, who arranges the deal and which brand is presented. If the page does not clarify a relationship, avoid guessing from logos or domain ownership.

• Evidence for How Is provider Different From broker and brand: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Map the actual commercial flow.
2. Assign each party one or more true roles.
3. Reuse identifiers for the same entity.
4. Omit uncertain relationships.

Provider, broker, brand and seller are separate commercial roles even when one company sometimes holds several.

Use Organization when a company, institution or practice is responsible for the item, and Person when a named individual personally provides or performs it.

A law firm providing estate-planning services is an Organization even when one attorney authors the page. A solo consultant who contracts and performs the engagement personally may be Person. A medical practice can be the provider while a physician is connected through a more specific role elsewhere.

Choose the entity that bears delivery responsibility, not simply the most visible name. Keep employee, author, instructor and provider relationships distinct. If both an organization and person meaningfully provide the service, model the relationship that the page can clearly support.

1. Frame the decision raised by Should provider Use Organization or Person.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Follow delivery responsibility.
• Do not confuse author with provider.
• Use the most specific Organization subtype available.

The provider value should identify the accountable delivery entity, whether that is an Organization or a Person.

Connect a Service to its provider by nesting or referencing an Organization or Person through provider, using a stable identifier when the same entity appears elsewhere on the site.

A stable @id lets Service pages point to one canonical Organization node instead of creating slightly different copies. The provider’s name, URL and other first-party facts should remain consistent across pages. Avoid adding unsupported ratings, addresses or legal details merely to make the nested node look complete.

{
  "@type": "Service",
  "name": "Technical SEO Audit",
  "serviceType": "Technical SEO Consulting",
  "provider": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example SEO Company",
    "url": "https://example.com/"
  }
}

Pair the provider relationship with the real service classification explained in the serviceType guide and coverage from the areaServed guide.

• Evidence for How Do You Connect a Service to Its Provider: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Create or identify the canonical provider node.
2. Use a stable @id.
3. Reference it from each real Service.
4. Validate the combined graph.

A stable provider identity connects service pages without duplicating or drifting company facts.

A Service can have multiple provider values when several Organizations or People genuinely share delivery responsibility, but contributors, sellers and referral partners should not be mislabeled as providers.

A joint program run by two institutions may support two providers. A marketplace listing many independent professionals may need provider relationships at the individual offering level rather than one generic service node. A subcontractor should be named only when the public page presents that responsibility.

Do not add every employee involved in delivery. Provider describes the responsible service provider or performer, not an internal project roster. Separate instructor, employee or contributor roles where appropriate.

1. Frame the decision raised by Can a Service Have Multiple Providers.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Require shared delivery responsibility.
• Scope providers to the correct offer or listing.
• Keep supporting roles separate.

Multiple providers are appropriate only when the page clearly shows that each party helps provide or perform the item.

Common provider mistakes include naming the seller or platform instead of the performer, using a brand as the legal provider, confusing the author with the provider, duplicating Organization identities and publishing unsupported third-party relationships.

A validator can confirm that an Organization is an allowed value but cannot prove the company delivers the service. Commercial roles require first-party evidence. Marketplace templates are particularly risky because the same platform identity can overwrite thousands of independent providers.

Identity drift also weakens the graph. One page may use a trading name, another a legal name and a third a location name without shared identifiers. Decide which entity provides each service and reuse that identity consistently.

• Evidence for What provider Schema Mistakes Are Common: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Trace who performs the item.
2. Compare seller, broker and brand roles.
3. Consolidate stable identities.
4. Remove unproven relationships.

Provider markup must reflect real delivery responsibility and a consistent public identity.