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, an invisible rating, or two apps describing the same product differently. Passing a validator is only the beginning.

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

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.

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

    AI assist
    Checking each PDP type and market against the eligibility requirements for every candidate product feature.
    Human gate
    Deciding which products and features stay out of scope for now instead of marking up data that isn't ready. Eligible cohort and exclusions named

  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.

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

    AI assist
    Pairing each required schema property with a candidate source field and flagging properties that still lack a clear owner.
    Human gate
    Approving the transformation and missing-value rule for every property before the mapping is considered final. Property-to-source mapping signed off

  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.

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

    AI assist
    Diffing rendered PDP values against the JSON-LD payload across every live product page to surface where price, stock, or ratings have drifted.
    Human gate
    Deciding whether a mismatch is a markup bug, a feed delay, or a genuine data problem before anything gets fixed. Visible-to-schema mismatches triaged

  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.

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

    AI assist
    Inspecting themes, apps, and tags for a second product graph that describes the same page without shared ownership.
    Human gate
    Choosing the single owned emitter and disabling every duplicate, including one that may already be earning impressions. Single owned emitter confirmed live

  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.

    A living issue and eligibility log.

    AI assist
    Watching merchant diagnostics and validation feeds continuously and grouping recurring errors by field and template.
    Human gate
    Deciding which recurring error gets fixed at the source versus suppressed from the markup until it is. Recurring errors routed to an owner

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

    Accepted when

    Every product, offer, variant, rating, and policy field has semantics, source, owner, update event, provenance, and suppression rule.

  • Architecture map

    Schema mapping specification

    Accepted when

    Every entity and property maps to a visible fact and current feature requirement. Variants, canonicals, emitters, and exclusions are explicit.

  • Evaluation sheet

    Validation example set

    Accepted when

    Representative variants, currencies, availability states, ratings, policies, source HTML, rendered DOM, and validators agree.

  • Dashboard

    Eligibility & freshness log

    Accepted when

    Coverage, errors, warnings, mismatches, source events, releases, owners, fixes, and reruns stay on one record.

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

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