How do I know if I have duplicate review schema?

Run Google's Rich Results Test or Schema Markup Validator on a product URL and look for multiple AggregateRating blocks, multiple Product nodes with different rating values, or errors about conflicting data. Viewing page source and searching for aggregateRating often shows two JSON-LD scripts from different apps.

Can I run two review apps during a migration?

Yes for collection overlap, carefully. Export from the old app first, import into the new one, then disable schema output on one side before both widgets go live. Running two schema emitters on the same templates is what breaks rich results and confuses answer engines.

Does cleaning up duplicate review schema improve my ranking?

No. Cleaning duplicates restores eligibility for rich results and gives machines one coherent rating to read. It does not improve ranking by itself. The point is accurate, single-source markup, not a ranking claim.

What Happens When Two Review Apps Both Add Review Schema?

Q: What happens when two review apps both add review schema?

You get duplicate or conflicting AggregateRating and Review markup on the same product. Google may ignore the rich result entirely. AI assistants and validators see two different rating stories for one product. The fix is one owner of review schema: keep collection where you want, but let a single app emit the structured data.

Conflicting markup. Two apps each emit an AggregateRating (or a whole Product node) for the same URL, Google often drops the rich result, and every machine reader has to guess which stars are real.

If you are migrating review apps, this is the failure mode to plan for on purpose.

What does duplicate review schema look like on a Shopify product?

Two stories about the same product in one HTML response.

Common shapes:

Two JSON-LD blocks, each with AggregateRating, sometimes with different ratingValue or reviewCount.
Theme Product schema plus an app's Product schema, each carrying its own rating.
One app writing aggregateRating on Product while another writes a standalone AggregateRating that floats without a clear @id link.

Shoppers still see one widget (or two stacked widgets). Validators see a mess. The same problem shows up in review and rating schema audits whenever a store has churned through apps without turning the old emitter off.

Why do Google and AI assistants both struggle with it?

Because neither wants to invent a tie-breaker for your data.

Google's review-snippet systems expect one coherent rating for the item. Conflicting counts are a classic reason stars disappear from the SERP even though "you have schema." Answer engines that parse structured data face the same ambiguity: which number is citable? When the page disagrees with itself, the safe behavior is to ignore the rating or skip the citation.

This is unrelated to ranking promises. Duplicate markup does not "demote" you through a published ranking factor you can tune; it breaks eligibility and trust for display and citation. Fixing it restores a clean signal. It does not improve ranking.

How do I check for two review schema emitters?

Use tools, then confirm in source.

Open a product with reviews in Google's Rich Results Test. Note errors, multiple products, or mismatched rating fields.
Search the page source for aggregateRating and Review. Two JSON-LD script tags from different app namespaces is the smoking gun.
In Shopify admin, list every app that touches reviews or SEO schema. Review apps, schema suites, and some themes all compete for the same fields.
If you recently switched apps, assume the old app's embed or script may still be active until you remove it.

While you are there, confirm the surviving markup is actually present on first load. Can AI assistants see my product reviews explains the client-side-only trap that survives even after you pick one app.

How do I fix duplicate review schema without losing reviews?

Separate collection from schema emission.

Export everything from the app you are leaving. Keep CSV or JSON backups before you uninstall. Moving reviews between apps covers Judge.me, Okendo, and Loox formats.
Import into the destination app and spot-check counts on a few products.
Pick one schema owner. Turn off structured data / rich snippet output in the other app, or remove its theme embed. Leave at most one emitter.
Re-test the same product URL until you see a single AggregateRating path.
Only then uninstall the old app, once you are sure widgets and markup both come from the survivor.

During a temporary dual-install, it is fine to collect on both for a short window if the vendor supports it. It is not fine for both to publish schema on the live theme.

What if a schema app and a review app both write ratings?

Same rule: one writer.

Schema suites often pull ratings from Judge.me, Okendo, Loox, or metafields and re-emit AggregateRating. That is useful when the review app's own markup is weak or late. It becomes harmful when the review app still emits its own copy. Choose either the review app or the schema layer as the publisher of rating markup, document the choice, and disable the other.

AgentReady already reads real ratings from many review apps for structured data. AgentReady Reviews targets the wider AEO job of making those ratings readable to answer engines. Either way, the migration rule stays the same: one authoritative rating story per product page.

Where should I start if I am mid-migration?

Export, import, single schema owner, re-test, then uninstall. Run the AI-readiness checker on a flagship product after the cutover. If ratings look clean in the widget but messy in structured data, you still have two writers or a client-side-only delivery problem. For the SERP-versus-AI distinction that motivates keeping markup clean for both audiences, read do review rich snippets help with AI answers.