Service vs Product Schema for a Service Business

Every service business that looks into structured data arrives at the same uncomfortable comparison. Service schema describes what you do accurately and produces nothing visible in search. Product schema produces price, availability and star ratings, and it is sitting right there, apparently unguarded.

So the question gets asked constantly, usually in a slightly guilty tone: can I just use Product schema for my services instead?

The answer is more interesting than either "yes, go ahead" or "no, that's spam." Both types are legitimate for a service business, and schema.org is much more permissive here than almost anyone realises. The problem is that the thing people are switching for is not actually in the box.

schema.org already says a haircut is a Product

Start here, because it changes the shape of the whole question.

People assume the vocabulary draws a firm line between goods and services, and that using Product for a service is a misuse of the type. Read schema.org's Product definition and that assumption falls apart:

Any offered product or service. For example: a pair of shoes; a concert ticket; the rental of a car; a haircut; or an episode of a TV show streamed online.

A haircut. A car rental. Both are in schema.org's own list of examples for Product, and neither is a physical object you take home. The vocabulary has never restricted Product to goods.

So marking a service as a Product is not invalid markup, it is not a misuse of the type, and it will not fail validation. If you were expecting to be told off for it, you are off the hook on that specific charge.

Which means the real question was never "is this allowed by schema.org." It is something else.

Two different questions, and everyone merges them

There are two entirely separate tests any piece of markup has to pass, and almost all confusion in this topic comes from treating them as one.

Is it valid? Does schema.org define this type and these properties, and am I using them the way the vocabulary intends? This is a question about the vocabulary.

Is it eligible? Will Google produce a rich result from it? This is a question about one search engine's product decisions, and it has nothing to do with the vocabulary.

The two answers routinely disagree, in both directions. FAQPage is still perfectly valid schema.org markup that Google stopped rendering. Service is valid, well-specified, widely used, and produces no rich result at all. Product is valid and eligible, which is the entire reason this question exists.

Once you separate the two, the choice stops being about correctness:

• On validity, Service and Product are both fine for a service business. schema.org sanctions both.
• On eligibility, they are not close. Product is one of Google's supported rich result types. Service is not on the list, and never has been.

That gap is the whole temptation. It is also where people stop reading and start switching, which is the mistake, because they have not checked what eligibility actually requires.

What switching to Product actually buys you

Here is the part that surprises people, and it is the reason most of these switches are wasted effort.

The usual reasoning goes: Service cannot express a price, or a rating, or an offer, so I need Product for that. That reasoning is simply wrong. Look at what schema.org's Service type already defines directly on itself:

offers, aggregateRating, review, provider, areaServed, serviceType, hasOfferCatalog, hoursAvailable, termsOfService, brand, category, audience, serviceOutput, availableChannel, award, hasCertification, isSimilarTo, isRelatedTo, broker, slogan, logo, providerMobility.

Service carries offers. It carries aggregateRating. It carries review. Everything people believe they have to switch types to express, Service already expresses.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://example.com/services/deep-clean#service",
  "name": "Whole-House Deep Clean",
  "serviceType": "Residential deep cleaning",
  "provider": { "@id": "https://example.com/#organization" },
  "areaServed": { "@type": "City", "name": "Bristol" },
  "offers": {
    "@type": "Offer",
    "price": "180.00",
    "priceCurrency": "GBP",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "126"
  }
}

That is valid schema.org. The price is there. The rating is there. Nothing about it is a fudge.

So switching to Product buys you exactly one thing: rich result eligibility. Not richer description, not more properties, not a better entity. One thing. Which makes the whole decision much simpler, because now you only have to ask whether you can actually collect on it.

What each type carries that the other does not

The overlap between the two is larger than the difference, which is why the switch feels so tempting and delivers so little. Both types define offers, aggregateRating, review, brand, category, audience, award, logo, slogan, isSimilarTo and isRelatedTo directly on themselves.

Where they genuinely differ:

Read the right-hand column and notice how much of it is meaningless for a service. A consultancy engagement has no colour, no weight, no condition, no country of origin, no return policy, and no variants. Those are the fields Product exists to carry, and a service page fills in almost none of them.

Now read the left-hand column, because one entry there matters more than everything else on this page.

Product has no provider property. None. If you swap a Service block for a Product block, the link between the offering and the business that provides it silently disappears, because there is nowhere to put it. provider is the property that ties each of your services back to your business entity, and it is usually the most valuable thing in the markup. Trading it for a rich result you probably cannot earn is a bad exchange.

Product's nearest equivalents are brand and manufacturer, and neither means "the company that performs this work for you."

What eligibility actually requires

Google's Product documentation splits the feature in two, and the split matters for a service business:

• Product snippets, described as being for "product pages where people can't directly purchase the product"
• Merchant listings, for "pages where customers can purchase products from you"

Merchant listings are a commerce feature and assume a purchasable item with a price, availability, and usually a shipping and returns story. Most service pages are not that. A consultancy page that ends in "book a call" is not a page where a customer completes a purchase.

Product snippets are the more plausible target, and they mostly come down to review stars and a price. Which brings the whole question to a single point of failure.

The stars are the thing you wanted, and you cannot have them

Nearly every service business asking this question is asking for one reason: they want the gold stars.

They are not available to you, and the reason has nothing to do with which type you pick. Google's review snippet rule is about who controls the reviews, not about markup:

If the entity that's being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.

Re-typing your service page as a Product does not change who collected the reviews. A cleaning company publishing its own customer testimonials is the reviewed entity controlling reviews about itself, whatever @type sits above them. The rule was written precisely to catch this manoeuvre, and dressing a service as a Product to slip past it is the clearest possible example of what it exists to prevent.

The legitimate route to stars for a service business runs through independent review platforms rather than your own markup, and we cover that path properly in our star ratings guide.

Take the stars off the table and the case for switching mostly evaporates. What is left is price and availability, which Service already carries, minus the rich result.

Where the actual line is

There is a real constraint here, and it is worth stating precisely because it is not "don't use Product for services."

Google's structured data policies require that structured data be "a true representation of the page content," and specifically say not to mark up content that is not visible to readers of the page. A structured data manual action, in Google's words, means "a page loses eligibility for appearance as a rich result."

So the risk is not the type you chose. The risk is the fields you had to invent to qualify. A service page that grows a price it does not display, an availability that means nothing for a bespoke engagement, and a rating assembled from testimonials is not in trouble for saying Product. It is in trouble for describing a page that does not exist. Our post on the schema spam policy covers how that enforcement has sharpened.

The inverse is also true, and it is the permission most service businesses do not realise they have: if your page genuinely shows a fixed price for a defined, purchasable thing, Product markup describes it honestly, and schema.org's haircut example says you are within the vocabulary.

When your industry calls it a product but schema.org calls it a Service

Some industries have used the word "product" for decades to describe things that are not goods. Banking, insurance, lending and investment all talk about their "products," and the people marking up those pages naturally reach for Product schema.

schema.org disagrees, and it is worth seeing how firmly. There is a dedicated type called FinancialProduct, defined as:

A product provided to consumers and businesses by financial institutions such as banks, insurance companies, brokerage firms, consumer finance companies, and investment companies which comprise the financial services industry.

The definition calls it a product twice. Its type hierarchy is Thing > Intangible > Service > FinancialProduct. It sits under Service, not under Product, and it carries provider and areaServed as a result. Beneath it sit BankAccount, LoanOrCredit, PaymentCard, InvestmentOrDeposit, PaymentService and CurrencyConversionService.

So a savings account is, in schema.org's model, a kind of service. A mortgage is a kind of service. Marking either as a Product is a step away from the specific type the vocabulary already provides for it.

The wider lesson applies well beyond finance: before deciding between the two general types, check whether schema.org has a specific type for what you actually sell. Service's other subtypes include FoodService, TaxiService, GovernmentService, BroadcastService and WebAPI, and a specific type always beats a general one. The same logic settles the choice more often than the Service-versus-Product debate does.

Three honest shapes

1. The bespoke service. Use Service.

Consulting, legal work, custom building, anything quoted per job. There is no fixed price to state and nothing to purchase on the page. Service with serviceType, provider and areaServed describes this accurately, and it is the shape that does the most for AI systems trying to match a specific service to a specific place. Our Service schema guide covers the implementation in full, including the one-block-per-service rule that matters more than the type choice ever will.

2. The productized offering. Product is legitimate, and so is both.

A fixed-price package with a defined scope, bought as-is: a £180 deep clean, a £49 tax return, a named audit with a checkout button. This is genuinely product-shaped, the price on the page is real, and Product describes it truthfully. Our Product schema guide covers the required fields and the WooCommerce specifics.

Where an offering is genuinely both, you can carry both types on one node:

{
  "@context": "https://schema.org",
  "@type": ["Product", "Service"],
  "@id": "https://example.com/services/deep-clean#offering",
  "name": "Whole-House Deep Clean",
  "serviceType": "Residential deep cleaning",
  "provider": { "@id": "https://example.com/#organization" },
  "areaServed": { "@type": "City", "name": "Bristol" },
  "offers": {
    "@type": "Offer",
    "price": "180.00",
    "priceCurrency": "GBP",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/services/deep-clean"
  }
}

One node, both types, no duplication. You keep provider and areaServed from the Service side and the commerce fields from the Product side. Do this only when the page really does both jobs, not as a way to smuggle Product onto a quote-only page.

3. Software. Neither of these is your main type.

If you sell software, SoftwareApplication is a supported type with its own rich result potential, and it describes the thing far better than either option here. Service can still describe the "what we do for you" layer around it.

Common mistakes

Switching to Product to get stars. The self-serving rule follows the reviews, not the type. Re-typing changes nothing.

Believing Service cannot carry a price. It carries offers, aggregateRating and review directly. This is the single most common false premise behind the switch.

Inventing a price to qualify for a rich result. This is the actual policy problem, and it is a problem regardless of which type you used.

Marking every service page as a Product because one offering is productized. Type each page as what that page is.

Treating "no rich result" as "no value." Service does entity work: it tells a machine what you do, for whom, and where. That is what gets you matched when someone asks an AI system for a provider, and it is not measured by whether something visual appears in search.

Multi-typing everything as a reflex. ["Product", "Service"] on a quote-only consulting page claims a commerce shape the page does not have.

Marking up a service as a Product and leaving out provider. Product has no provider property, so a straight swap silently drops the link between the offering and your business entity, which is usually the most valuable part of the markup.

Deciding, in three questions

1. Does the page show a real, fixed price for a defined thing? No, and it is Service. There is nothing for Product's key fields to honestly describe. Yes, and Product is legitimately available to you.

2. If yes, can a visitor actually buy it on the page? Yes, and you are in merchant listing territory, so Product is the right primary type. No, but the price is real and displayed, and Product snippet is the realistic target. Multi-typing with Service keeps provider and areaServed.

3. Are you doing this for the stars? Then stop, because they are not available either way, and the effort is better spent on independent review platforms.

Worth saying plainly: for most service businesses the answer to question one is no, and Service is correct. The choice only becomes genuinely open once you have productized something.

How to check what you have

1. Look at what the page actually shows. Open the page, not the markup. Is there a price? Is it fixed or "from"? Can anyone buy it here? Your markup should not claim anything the page does not show.

2. Check whether your Service blocks carry provider. A Service that does not reference your business entity by @id is an orphan, and this is a more common and more costly defect than choosing the wrong type.

3. Check for a price you cannot defend. Any price in your markup that a visitor cannot see on the page is the thing to fix first.

4. Run the Rich Results Test, and read the result correctly. For a Service block it will report no eligible rich result. That is the expected outcome, not a failure. Use validator.schema.org to check the vocabulary itself, which is where Service is properly validated. Our supported types sets expectations for what can and cannot produce a result.

5. Check one service page against another. Copy-pasted blocks differing only in the name are a bigger problem than the type debate.

AI Schema Gen picks the type from what a page actually is, so a quote-only service page gets Service with a real provider link, and a fixed-price offering gets the commerce fields it can support. Start free and see what your service pages currently declare.