Zeo delivery method

Product Schema & Rich Results

Markup generated from visible, current commerce data through one owned emitter, with eligibility monitored and no rich result promised.

Valid JSON-LD can still tell the wrong story, an old price, a missing variant, a rating nobody can see on the page, because passing a validator only confirms the syntax, not the truth. We give every schema property one accountable source, generate the markup through a single owned emitter instead of several scripts drifting apart, and keep monitoring eligibility without ever promising a rich result Google hasn't granted. We publish product markup from visible, current commerce data, keep products, variants, and offers in sync, and monitor eligibility without promising a rich result.

Match your markup with ZeoE-commerce SEO
Zeo figures connect visible product facts to a large JSON-LD card while removing a duplicated and outdated offer block.

Some of the 500+ brands we've worked with

See all references
  • GE
  • Sigortam.net
  • Pegasus Airlines
  • Peak Games
  • Cyberpark
  • Amazon
  • BMW
  • Shell
  • Hyundai
  • PepsiCo
  • Red Bull
  • Decathlon
  • MediaMarkt
  • Bayer
  • Sanofi
  • EY
  • KPMG
  • 3M
  • Domino’s
  • Lexus
  • Trendyol
  • Hepsiburada
  • Yandex
  • LC Waikiki

Stages and gates

How we do it

We trace each property from an owned product value through the emitter to search eligibility.

  1. Choose the product features that fit

    We define the product snippets, merchant listings, variants, reviews, shipping, returns, and other features that match each PDP type, market, lifecycle, and data state. Deciding which products and features stay out of scope for now instead of marking up data that isn't ready.

    A clear eligible cohort, plus an explicit list of products and features left out for now.

  2. Give every property one accountable source

    We connect required and selected properties to stable product, offer, variant, review, shipping, return, and organization fields, each with an owner, transformation, and missing-value rule. Approving the transformation and missing-value rule for every property before the mapping is considered final.

    A field contract the team can maintain after the SEO engagement ends.

  3. Reconcile what people see with what machines read

    We compare product identity, image, price, currency, availability, condition, variants, ratings, shipping, returns, and canonical across rendered PDP and markup. Deciding whether a mismatch is a markup bug, a feed delay, or a genuine data problem before anything gets fixed.

    A visible-to-schema matrix covering normal, unavailable, multi-currency, and sparse-data states.

  4. Generate the graph through one owned emitter

    The PDP template generates markup from canonical fields, with explicit rules for variants and markets and no competing graph from a theme, app, or tag. Choosing the single owned emitter and disabling every duplicate, including one that may already be earning impressions.

    One versioned implementation with fixtures, expected output, tests, release, and rollback.

  5. Validate the live truth, then keep watching it

    We test source and rendered markup, feature rules, merchant diagnostics, visible agreement, and edge states, then watch for feed, template, or market drift. Deciding which recurring error gets fixed at the source versus suppressed from the markup until it is.

    A living issue and eligibility log.

AI checks eligibility, diffs the payload, and watches the feeds; people own the source and the emitter.

AI checks each PDP type and market against the eligibility requirements for every candidate product feature, pairs each required schema property with a candidate source field and flags the ones with no clear owner, diffs rendered PDP values against the JSON-LD payload across every live product page to surface where price, stock, or ratings have drifted, inspects themes, apps, and tags for a second product graph describing the same page, and groups recurring validation errors by field and template. It owns nothing. We do not fabricate ratings, reviews, prices, stock, identifiers, shipping, returns, certifications, or offers, we do not add hidden page content to support a schema property or search feature, and valid markup may support eligibility but cannot guarantee a rich result, merchant display, ranking improvement, or traffic gain.

Deliverables and acceptance

What you get

Source data, the emitter, and what search actually shows stay tied together.

  • Policy document

    Product data contract

  • Architecture map

    Schema mapping specification

  • Evaluation sheet

    Validation example set

  • Dashboard

    Eligibility & freshness log

We call it done when: The data contract, mapping specification, validation example set, and eligibility log are done when every product, offer, variant, rating, and policy field has semantics, source, owner, update event, provenance, and suppression rule, every entity and property maps to a visible fact and a current feature requirement with variants, canonicals, emitters, and exclusions explicit, representative variants, currencies, availability states, ratings, policies, source HTML, rendered DOM, and validators agree, and coverage, errors, warnings, mismatches, source events, releases, owners, fixes, and reruns stay on one record.

Fit and readiness

When you need this

Structured product data needs maintaining like a feed. Pasting a snippet once and never looking at it again is how it goes stale.

A good fit when

  • Product markup passes syntax tests, but its price, availability, variants, reviews, or policies no longer match the PDP.
  • Themes, apps, tags, and integrations each emit part of the graph, and no one owns the final machine-readable account of the product.
  • You need eligible markup across product states, markets, currencies, and variants without disguising gaps in the underlying data.

Better handled as other work when

  • You want to mark up product facts that are not visible and verified on the PDP, or use schema as a substitute for repairing the page.
  • The desired outcome is a guaranteed rich result, merchant display, ranking, or traffic gain.

If one of these is closer to your situation, start here instead: E-commerce SEO

We call it done when: Every emitted property has one owned source and refresh rule, visible and machine-readable product truth agree across normal and edge states, duplicate emitters are gone, live checks pass, and unsupported markup gets removed on sight.

The specialists behind this SEO work

Zeo's SEO work goes back to 2006, when we started what we call the first SEO blog in the MENA region. The consultants shown here are doing that work today, matched to what this page covers.

Content we've produced on this topic

Videoby Ozan KetenciSEO Focused Product Optimization in E-Commerce Brands | Ozan Ketenci, ZeoArticleby Samet ÖzsüleymanHow to Manage Product Variants with isVariantOf Schema?Articleby Samet ÖzsüleymanMost Common JSON-LD Schema Issues and Solutions

Tools we use

Tools behind this work

  • Schema App

    defines the owned product graph and property source mapping

  • Screaming Frog

    extracts rendered JSON-LD beside visible product facts for comparison

  • Sitebulb

    finds duplicate emitters and malformed relationships across PDP templates

  • Lumar

    monitors schema drift across markets, variants, and lifecycle states

  • Google Search Console

    tracks product enhancement eligibility, errors, and affected page groups

  • Bing Webmaster Tools

    provides a second live view of crawl and markup issues

Next step

Trace your product markup back to truth

Bring a few live PDPs and the feeds behind them. We'll show you where visible and machine-readable product facts start to drift.
Match your markup with Zeo

Before we start

Questions we hear

Does valid product schema guarantee rich results?

No. Validity and eligibility are prerequisites. Search systems decide whether and how the feature appears. We monitor the outcome without promising it.

Can AI generate missing schema values?

AI can map approved fields and identify mismatches, but a missing product fact remains missing until the source owner resolves it.

Should we add every recommended property?

A larger graph is not automatically a better one. We add properties only when they are visible, supported, useful, owned, and maintainable for the page and feature.

What if our theme and an app both emit product schema?

Only one should. Two emitters describing the same product usually disagree eventually, and Google has to guess which graph to trust. Themes, apps, and tags are the usual source of that second, uncoordinated graph. We pick one owned emitter, turn the other off, and test that nothing downstream still depends on it.