Don't confuse product and service markup

When is product markup correct, and when should a service be modeled as a service?

Product describes a good offered or a service unit clearly defined as a product with appropriate product attributes. Service represents a service provided and its scope; the decisive factors are the actual form of the offering, visible content, and the meaning intended by the vocabulary.

Actual offering

• Actual offering – The page clearly indicates whether customers are purchasing a standardized good or receiving a service from a provider.

• Appropriate Attributes – Price, provider, region, model, and other values ​​are only used if they are relevant to the selected type.

• Visible Correspondence – Name, description, offer, and terms in the markup match the information visible to users.

Rich Result Type Selection

• Rich Result Type Selection – A type is chosen solely for the purpose of a desired search display, turning a service into a fictitious product.

• Inappropriate Product Fields – SKU, stock status, or rating are added even though the actual service offering does not possess these attributes.

• Mixed Primary Entity A page describes the provider, service, and package without clearly defining its primary content.

Practical Example: "Rich Result Type Selection"

An agency sells a specifically named audit with a defined scope and price, while still providing a technical service. The page models the service and its provider instead of inventing inventory and product identifiers; however, an actual manual that is sent out remains a product.

Appropriate Attributes

1. Describe the offer type, contract unit, and visible statements in a business context before selecting a schema type.

2. Only transfer matching properties from the same controlled data source to the respective entity.

3. Check the rendered output against vocabulary, search guidelines, and page content, and remove inapplicable fields.

Visible Correspondence

• Percentage of excellent offers with a business-justified type selection and complete visible correspondence of all core values.

• Number of validated fields that are syntactically valid but do not accurately describe the actual subject of the offer.

Related questions and next steps

Separates "product and service markup" Use structured data only for actually visible content Raises an important follow-up question: Why must structured data match the visible page content?

For those who want to delve deeper into "Separating Product and Service Markup" from the perspective of the "Local SEO & Entity Management" cluster, see Using Schema.org cleanly and completely for LocalBusiness .

If you want to practically implement "Separating Product and Service Markup," you can refer to Robust Website Systems This focuses on "Commercial Types and Rating Markups" and "Real Offering."

Conclusion: Separating Product and Service Markup

Structured data should clarify reality, not reinterpret the offering for search functions. Therefore, the business type meaning takes precedence over desired presentation and available fields.

Sources and Further Information

These primary sources are crucial for platform behavior, terminology, and validation limits when "Separating Product and Service Markup."

• Review snippet structured data – Google Search CentralOfficial rules for permissible review objects, required properties, and self-referential reviews.

• Product snippet structured data – Google Search CentralOfficial type, property, and content requirements for product snippets in Google Search.

• Local Business structured data – Google Search CentralOfficial guidance on selecting appropriate Local Business subtypes and location, opening hours, and business data.