What Is seller Schema?

The seller schema property identifies the Organization or Person that offers goods or services for sale, lease, lending or loan within a supported transaction context.

It models the commercial party making the offer. The seller may also be the provider, manufacturer or brand owner, but those roles are not automatically identical. A marketplace can sell a service performed by another company, while a retailer can sell a product manufactured under another brand.

Schema.org defines seller on BuyAction, Demand, Flight, Offer and Order. It accepts Organization or Person and supersedes the older merchant and vendor properties. The page should make the seller visible through offer, checkout, merchant or order information.

1. Frame the decision raised by What Is seller 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.

• Identify the party offering the transaction.
• Use Organization or Person.
• Separate selling from fulfillment and production.

seller schema should name the real merchant or transactional party, not whichever brand is most prominent.

The seller property is supported on BuyAction, Demand, Flight, Offer and Order, so its exact meaning depends on the transaction entity that owns the relationship.

Offer is the most common commercial context: it describes terms under which rights to an item or service are transferred, and seller names the party making those terms available. In Order, seller identifies the merchant associated with the recorded purchase. In Demand, it can identify the seller involved in the demand context.

Do not place seller directly on Product, Service or Organization. Connect Product or Service to Offer, then place seller on the Offer when the page supports the transaction.

• Evidence for Which Types Can Use seller: 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 transaction entity.
2. Confirm seller is supported there.
3. Name the visible merchant.
4. Connect the offered item separately.

Correct parent placement ties the seller to a real offer, order or transaction instead of the item in isolation.

seller identifies who offers the transaction, while provider identifies who supplies, operates or performs the service or goods; one party can hold both roles, but marketplaces often separate them.

A consulting agency selling and delivering its own work can be both seller and provider. A booking platform may sell a reservation while a hotel provides the stay. A software reseller can sell a plan provided by the software company.

Trace checkout responsibility and delivery responsibility separately. The provider schema guide explains fulfillment identity. When roles match, reuse one canonical Organization node rather than creating duplicates.

1. Frame the decision raised by How Is seller Different From provider.
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.

• Audit payment and fulfillment independently.
• Model the same entity once when roles match.
• Preserve different parties when roles differ.

Seller owns the commercial offer; provider owns delivery or performance.

The seller transacts with the buyer, the manufacturer produces the product, the brand identifies its commercial identity, and the broker arranges an exchange without normally owning the item.

A marketplace listing can involve all four: a manufacturer makes the product, a brand appears on it, a third-party merchant sells it and the platform brokers the transaction. Collapsing these roles into the platform Organization changes who is responsible for what.

Use visible first-party disclosures such as “sold by,” manufacturer details, brand labels and intermediary terms. Domain ownership or logo prominence is not enough to assign every role.

• Evidence for How Is seller Different From manufacturer, brand and broker: 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 transaction flow.
2. Identify production and brand ownership.
3. Identify any intermediary.
4. Assign only evidence-backed roles.

Seller, manufacturer, brand and broker describe different relationships even when one company holds several.

Use Organization for a company, store, institution or marketplace merchant, and Person when an individual is the actual party offering the item or service.

Most ecommerce and SaaS offers use Organization because the company contracts with the buyer. An independent consultant or individual marketplace merchant may be Person when the transaction is genuinely in that person’s name. Do not choose Person merely because a founder appears prominently on the page.

The seller node needs only supported identity facts. A stable @id, name and URL can be enough. Do not add private addresses, personal identifiers or unsupported legal information for completeness.

1. Frame the decision raised by Should seller 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 the contracting merchant.
• Use the most accurate Organization subtype.
• Protect personal data and avoid assumptions.

The seller value should match the legal or commercial party that makes the offer to the buyer.

Add seller to an Offer by referencing the merchant’s canonical Organization or Person identity alongside accurate price, currency, availability and itemOffered data.

A stable @id prevents merchant identity from drifting across product or service pages. The Offer should point to the actual item being sold, and the page should display the same commercial terms. Avoid creating a new seller node for every offer when one merchant owns them all.

{
  "@type": "Offer",
  "price": "99.00",
  "priceCurrency": "USD",
  "availability": "https://schema.org/InStock",
  "seller": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example Software Company"
  },
  "itemOffered": {"@type": "Service", "name": "SEO Audit"}
}

If the offer applies only in certain regions, combine it with verified coverage described in the areaServed guide.

• Evidence for How Do You Add seller to an Offer: 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 canonical merchant.
2. Create or reuse its @id.
3. Add it to the correct Offer.
4. Validate all visible commercial terms.

Seller markup is trustworthy only when merchant identity and the surrounding Offer agree with the live transaction.

One Product or Service can be sold by multiple parties, but each merchant should normally have its own Offer so seller-specific price, availability, region and terms remain attached to the correct transaction.

Marketplace product pages often aggregate several offers for the same item. A single Offer with multiple sellers can hide which price belongs to which merchant. Separate Offer nodes preserve merchant-level commercial truth.

When one merchant operates several storefronts, decide whether the seller identity is the parent company or each Store based on who contracts with the buyer. Reuse stable identifiers and avoid duplicate seller nodes that differ only in spelling.

1. Frame the decision raised by Can One Item Have Multiple Sellers.
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.

• Separate merchant-specific offers.
• Keep price and availability with the seller.
• Resolve storefront and parent identities deliberately.

Multiple sellers are best represented through distinct offers with complete seller-specific terms.

Common seller mistakes include placing it on Product or Service, using the provider or brand without transaction evidence, assigning a marketplace platform to every offer, duplicating merchant identities and leaving stale sellers after inventory changes.

Type validation cannot prove which party takes the order. A well-formed Organization value can still be commercially false. Review sold-by labels, checkout entities, invoices and current marketplace data.

Template defaults create broad risk. If the site’s own Organization is automatically injected as seller on third-party listings, thousands of offers can misstate the merchant. Merchant identity must come from the offer source, not page ownership.

• Evidence for What seller 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. Check the seller’s parent entity.
2. Compare merchant and fulfillment roles.
3. Resolve canonical identity.
4. Remove stale or inferred sellers.

Seller markup must reflect the current transaction, not the page owner or a convenient template default.