# Multi-source reviews without breaking Google markup When Judge.me, Bazaarvoice, and imported syndication all touch the same SKU, structured data breaks quietly—here is how to keep one honest aggregate. By Rohin Aggarwal · 2026-03-05 Your PDP shows stars from a Shopify review app. Your enterprise syndication feed adds retailer reviews. A migration left legacy JSON-LD in the theme. Google Search Console still reports “Review snippets” some weeks and invalid nested aggregates the next. Nobody changed the product—only which engine prints schema. Multi-source review stacks are normal in 2027 replatforms. Broken markup is optional. This article is the strategy we use with merchants running parallel review sources during Q1 cutovers—not a promise of rich-result guarantees, but a way to stop accidentally lying to crawlers. **Quick answer** - Counts double (site reviews + syndicated reviews counted twice) - `itemReviewed` points at different `@id` values (product URL vs SKU vs `ProductGroup`) - Video review widgets add a second `Review` array in a shadow DOM the theme does not know about ## Why duplicate `AggregateRating` is the default failure mode Google expects **one** authoritative aggregate per product page (for the review type you claim), with consistent `ratingValue`, `reviewCount`, and reviews that belong to that SKU or group definition. When two apps inject schema: - Counts **double** (site reviews + syndicated reviews counted twice) - `itemReviewed` points at different `@id` values (product URL vs SKU vs `ProductGroup`) - Video review widgets add a second `Review` array in a shadow DOM the theme does not know about The page looks fine to shoppers. Rich result testing tools show red errors. AI search crawlers may pick the wrong snippet entirely. If you are mid-migration, read our [30-day parallel run for reviews and UGC replatforming](https://idukki.io/blog/q1-replatforming-reviews-ugc-parallel-run-30-day) before you toggle two apps live on production. ## Source-of-truth rules (pick one, document it) Before touching Liquid or tag managers, write a one-page policy: 1. **Which system owns on-site text reviews** for schema purposes? 2. **Which system owns syndicated/off-site counts**—if any—and are they eligible for on-page schema under Google’s guidelines? 3. **Who disables** the loser app’s JSON-LD output? Common patterns: | Pattern | Schema owner | Syndication role | | --- | --- | --- | | Shopify-native app only | Judge.me / Okendo / Loox | Display quotes in UI only, no second aggregate | | Enterprise syndication | Bazaarvoice / PowerReviews | App provides aggregate; Shopify app UI-only | | Headless API | Custom backend | Theme renders one JSON-LD block from API | Budget comparisons for video-capable apps are in our [Judge.me vs Loox vs Okendo buyer’s guide](https://idukki.io/blog/review-app-video-features-2027-judgeme-loox-okendo-budgets)—but the markup owner is a strategy call, not a feature checkbox. ## Parallel run: validate markup weekly, not at launch During parallel operation, run the same four URLs through Rich Results Test every Friday: - Best-selling SKU with syndicated reviews - Long-tail SKU with only on-site reviews - Bundle or `ProductGroup` parent - Variant-heavy SKU with query-param URLs Log: `reviewCount`, `ratingValue`, presence of duplicate `@type": "AggregateRating"`, and whether `review` arrays reference verified purchasers. Disable schema emission in the non-owner app using vendor settings first; if the vendor hides JSON-LD behind a paid tier, use theme guards that strip duplicate scripts (document the strip in runbooks so the next agency does not “fix” it back). Idukki sits adjacent to this stack—we surface UGC and shoppable proof, not star aggregates—so our [docs on gallery embeds and theme placement](https://idukki.io/docs) assume your review app already owns honest rating schema. ## UGC galleries and reviews: do not merge counts in JSON-LD Teams sometimes want Instagram posts beside reviews and a single “social proof score.” That belongs in **merchandising**, not structured data. Mixing UGC likes into `reviewCount` is how you lose trust with regulators and search quality teams. Keep: - **Reviews** → review app schema - **UGC** → visual proof modules, optional `VideoObject` where appropriate, separate from star aggregates Our [compliance checklist for FTC and fake reviews](https://idukki.io/blog/2027-compliance-checklist-ftc-uk-fake-reviews-ugc-rights) covers disclosure on UGC; it does not authorize inventing review counts from posts. ## Headless and composable storefronts If 2027 includes a Hydrogen or custom front end, stop generating JSON-LD in two layers (edge worker + legacy theme snippet). Centralize product schema in the **product API response** with a field `structuredDataOwner: bazaarvoice | okendo | internal`. Public caching makes this harder: a stale aggregate at the CDN edge is worse than no stars. Follow etag patterns we outlined for headless UGC in [headless UGC and public JSON etags](https://idukki.io/blog/headless-ugc-2027-replatforms-public-json-etags)—the same discipline applies to review payloads. ## AI search and citation hygiene Large language models and AI-overviews often quote on-page text plus structured fields. When two aggregates disagree, citations drift (“4.2 stars” vs “4.8 stars” for the same URL). Align visible on-page copy with schema: - If syndicated quotes appear in UI, label source clearly - If schema excludes syndicated counts, UI should not imply they are included in the big star header Our [PDP citation checklist for AI search commerce](https://idukki.io/blog/2027-ai-search-commerce-pdp-citation-checklist) treats rating consistency as a first-class field. ## Operational checklist before you turn off the old app - Search Console → Enhancements → Review snippets: note open issues - Export review count by SKU from old and new systems; reconcile >5% deltas - Paid search extensions using star extensions match on-page aggregate - Email templates pulling dynamic stars updated to new API - Remove old app embed scripts that injected hidden JSON-LD For broader stack cleanup after peak, pair this with the [post-holiday Shopify stack audit](https://idukki.io/blog/post-holiday-shopify-stack-audit-seven-apps). ## When Idukki enters the picture We make Idukki to map **customer posts and shoppable clips** to SKUs—not to replace your review aggregator. In multi-source projects, Idukki widgets should sit **below or beside** the review block, sharing SKU keys but not schema types. Rights for UGC remain separate from review submission flows; see [help center guidance on permissions](https://idukki.io/help). Benchmarks and case study formats—not fabricated lift—live on [resources](https://idukki.io/resources). ## Bottom line Multi-source reviews work when **one system owns markup**, syndication is explicit in UI, and parallel runs are boring weekly rituals. Everything else is a rich-result lottery—and a compliance footgun. Fix the owner, strip the duplicates, and keep UGC out of your star counts. ### FAQs **Q: Who is this guide for?** A: Heads of ecommerce, CMOs and campaign leads preparing holiday and 2027 peak-season proof. **Q: Does this require a new UGC tool?** A: No. The checklist works with any collection workflow; Idukki is one option for tagged, shoppable galleries. **Q: Where should I start?** A: Read the quick answer, then work the first section of Multi-source reviews without breaking Google markup on your top revenue SKUs. ### References - [Idukki help centre](/help) - [Engagement and analytics docs](/docs/engagement-analytics) - [UGC resources and playbooks](/resources) - [Related: q1-replatforming-reviews-ugc-parallel-run-30-day](/blog/q1-replatforming-reviews-ugc-parallel-run-30-day) - [Related: review-app-video-features-2027-judgeme-loox-okendo-budgets](/blog/review-app-video-features-2027-judgeme-loox-okendo-budgets) - [Related: 2027-ai-search-commerce-pdp-citation-checklist](/blog/2027-ai-search-commerce-pdp-citation-checklist) --- Canonical: https://idukki.io/blog/multi-source-reviews-without-breaking-google-markup Tags: reviews, seo, shopify, structured-data