Product vs Service Schema: I Argued With AI, Turns Out We Were Both Half Right

Google Search Console threw a schema error.

Nothing major, Review was attached to the wrong parent. Easy fix. 

But I’ve got this habit, I ask myself Is this actually the best way to do it?

So I dropped it into Gemini and asked for a rewrite.

Read the advice… and just sat there for a second.

Yeah… I don’t agree with this.

Schema Isn’t a Rulebook, Even Though It Looks Like One

Most people treat schema like a checklist:

• Pick a type
• Fill the properties
• Pass validation
• Done

And technically… that works.

But it’s not what schema actually is.

Schema is a relationship system. It’s describing:

• what something is
• how it connects to other things
• and how machines should interpret that context

That’s why properties like about, subjectOf, provider, itemOffered exist. They let you connect entities in ways that aren’t rigid parent-child structures.

Once you see that, the whole thing opens up.

You stop asking:  “What type do I use?”

And start asking:  “What am I actually trying to represent here?”

And maybe even stop trying to cram every possible type into every parent.  (Or at least I used to.)

AI Gave Me the “Right” Answer But it Felt Completely Wrong

So I’m debugging this schema issue.

Trying to integrate reviews properly into a service page. Keep it clean. Keep it compliant. Make sure the relationships actually make sense.

And Gemini suggests: “Use Product schema for your service so reviews can show.”

Immediate reaction: …what?

A massage is a service. Not a product. That’s basic.

And this is Gemini.
Google’s Gemini.

How does it get that wrong?

Plus, I don’t care about rich snippet reviews! I was trying to model the schema properly. Not the same problem.

I had a whole internal logic stack backing that up:

• Services use offers (plural)
• Products use Offer (singular)
• Offers are tied to tangible things
• Therefore → Product must mean physical

< examples here>

It felt consistent. It felt right. 

The Line I’d Never Actually Read Properly

So I switched to Claude.

“Gemini said this… I don’t agree.
A massage is NOT a product… Am I wrong?”

And the response I got back?

Gemini was actually pretty close, it gave good advice but just in the wrong context. 

I re-read what Gemini had actually said. And what Claude explained further. 

I still didn’t believe it. I visited https://schema.org/Product 

Right there, in black and white (and red) Any offered product or service. 

Wait… what? A haircut?

No really. Read that again.

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.

Product includes services.

And the canonical example?

A haircut. That’s the moment.

I never stopped to really read and understand that.  I was running on inference and intuition 

I was treating product as physical.

Schema.org is treating Product as a defined, sellable offer.

Different model entirely.

Why the Advice Was Directionally Right but Conceptually Wrong

Gemini wasn’t exactly wrong. It wasnt exactly right either. 

It skipped the layer that actually mattered.

It assumed: “You’re asking about reviews → you want stars” So it gave: Rich snippet strategy

But I was asking: “How do I model this correctly?”

Two different intents.

This matters more than it seems. Because:

• Schema modelling = describing reality – relationships
• Rich snippets = what Google might choose to show

They overlap. But they are not the same system.

The Real Constraint: Google, Not Schema

People think the option or rather limitation is: Service vs Product

It’s not.

The real constraint is Google.

More specifically:

• Review snippet eligibility
• Self-serving review suppression
• Selective display rules
• Search console Rich Snippet “Errors”

So:

• Schema says what’s valid
• Google decides what’s visible

And now we’ve got a third layer:

• AI systems decide what’s understandable

That’s the Next Level shift.

 How to Model Product vs Service Schema for Service Businesses

Once you strip all the noise away, it becomes simple.

A massage session is:

• A Service → what it is
• A Product → how it’s sold

Its not  a workaround or a hack. Just accurate modelling.

Schema is where you decide: how machines understand what you sell.

If you start with understanding the parent definition and then:

• relationships
• constraints
• and system behaviour

You’re not just implementing a schema. You’re thinking like a schema architect.

Instead of choosing one… You can use both.

• Service → to define the nature of the offering
• Product → to define it as a purchasable, structured offer
• Offer → pricing, availability
• Reviews → attached appropriately, not forced

And everything connects into a clean graph.