Products, Services and Reviews: Describe the Real Offer

Start with the visible offer and provider.

Identify what the reader can obtain: a physical item, software, a service, a subscription or a mixed package. Record the offer’s owner, scope, conditions, destination and current supporting source. Do not infer a price from a previous page or expand a local service into worldwide availability.

A Service node can describe work provided by a person or organization, with a supported provider, serviceType, areaServed, audience and offer relationship. Those properties need visible evidence. Reuse the accepted provider identity instead of creating an apparently different business on every service page.

An Offer describes the terms under which an item is offered. It is distinct from the item and the seller. A service may be quote-based rather than have a fixed public price. Omitting an unsupported price is more accurate than adding zero, a guessed starting figure or a stale promotion.

Distinguish practical page roles from vocabulary breadth.

In ordinary editorial planning, a product record focuses on an identifiable offered item and its attributes; a service description focuses on the work, scope and provider. Use that distinction to select evidence and explain the page, without claiming that the vocabulary creates an absolute physical-goods boundary.

Schema.org Product has a broad definition that can include offered services. Service provides service-specific relationships. This overlap does not mean every consulting page qualifies for Google’s Product features. Consumer requirements must be checked independently.

Google’s current structured data gallery, checked on 23 October 2026, does not list a standalone Service rich result. Do not relabel an offering, invent product identifiers or add ratings simply to pursue an appearance. A mixed package may need separate supported entities with clear relationships.

Worked comparison: service scope and a genuine product record.

The service side is an explicitly fictional bicycle inspection offer used for teaching: Example Workshop inspects one bicycle’s brakes and drivetrain, provides a written findings sheet and supplies a quote before any repair. No public fixed fee, service region or customer rating has been supplied. This is not a Semantec service or a verified business offer.

The product side is a genuine manufacturer resource: the official Raspberry Pi 5 product page, read on 23 October 2026. Its specification identifies Raspberry Pi 5 and a Broadcom BCM2712 processor. That record documents an identifiable computer and its stated attributes; it is not a bicycle service description.

For the fictional service, plan Service with the confirmed scope and provider only after those example facts become approved live copy in a real project. Do not add a price, geographic reach or review score from imagination. For the genuine product, preserve the manufacturer identity and model distinction; a merchant would also need its own current seller, variant and offer evidence.

This comparison is a page-role exercise, not production markup for Raspberry Pi, a resale offer or an assertion that this site sells the product. It deliberately omits changing prices and stock. The manufacturer’s product existence does not prove any particular merchant’s offer.

Keep ratings tied to their source and reviewed item.

A rating needs a real reviewed item, visible source, scale and count, with a method for any aggregation. A testimonial does not automatically provide a numerical rating. Do not turn positive prose into five stars, transfer business ratings to every product or combine unrelated items into one average.

Keep the review text or accessible evidence, author or source context, collection dates, permissions, incentives and calculation method where applicable. A supplier’s marketing claim is not an independent customer review. If provenance cannot be checked, leave the score out and record what evidence is missing.

Google’s review snippet rules distinguish supported reviewed types and restrict self-serving reviews of Organization and LocalBusiness. Embedding an external widget does not make a business’s own-page review of itself independently eligible. Do not generalize that rule into a claim that every genuine product review is prohibited.

Never create fake reviews, imaginary reviewers or undisclosed incentive stories. Accurate visible review content and current type-specific policy both need checking; a property being available in Schema.org is not permission to promise stars.

Review the complete offer and graph.

Compare names, provider or seller, canonical, service scope, item variant, currency, tax context, price validity and availability with the visible source. Do not treat an inquiry link as proof of inventory. Check the observed offered item, not merely the organization’s home page.

Use vocabulary validation for the graph and the relevant supported-feature test where appropriate. A Service description may be accurate even when a rich-result test has no Service feature to inspect. Neither a parser nor a test verifies that the commercial facts are true.

Keep a responsible owner and a change trigger for each commercial assertion. Expired promotions, discontinued items, changed service areas and withdrawn review permissions should reopen the record. Remove unsupported assertions rather than retaining them because a template expects a filled field.

Separate description, commercial evidence and feature claims.

Return to the structured data overview or learning overview. Use page and site identities to connect a genuine offering to its containing page.

The Schema.org data model explains type and property relationships. Google’s general guidelines govern its own feature use. Keep those decisions separate in the evidence record.