Product Review Schema Case Study Pakistan

The Client

A Gujranwala-based home and kitchen appliances ecommerce retailer, founded in 2019, selling blenders, air fryers, juicers, non-stick cookware and small kitchen machines under its own label alongside a handful of distributor brands. Gujranwala is one of Pakistan’s established manufacturing hubs for appliances and cookware, which gave the brand a genuine cost and supply advantage: a meaningful share of the catalog was assembled locally and shipped nationwide through TCS and Leopards. The catalog sat at roughly 640 SKUs, with an average order value near PKR 11,500 — a considered-purchase category where buyers research, compare and read reviews before committing. That AOV shaped the entire problem. A buyer spending twelve thousand rupees on an air fryer does not impulse-click the first result; they scan the listings for social proof, compare star ratings across the brand’s site, Daraz and imported alternatives, and only then choose. When the brand’s own listing rendered without any of that proof, it lost the click it had already earned the ranking for, and the buyer drifted to a competitor whose snippet carried five stars and a price — even when that competitor ranked below it. The competitive set included both imported brands with mature review programmes on international marketplaces and local Daraz sellers accumulating marketplace ratings by default, which meant the bar for earning a click was set higher than what a plain blue link could clear.

The brand had built demand through Google Ads, Meta campaigns and a Daraz marketplace storefront, and organic search had grown to about 38,000 monthly sessions. But a persistent gap frustrated the founders: they ranked well, often ahead of competitors, yet competitors collected the clicks because their listings showed star ratings, price and stock status while the brand’s listings rendered as plain blue links. They engaged WeProms to close that gap. The engagement described here is an illustrative composite built from the common patterns WeProms sees across Pakistani appliance and electronics retailers — anonymized and aggregated, not a report on a single named client.

The Problem

The store was visible but not clickable. A crawl combined with Google Search Console and Merchant Center diagnostics surfaced three linked problems:

• Rankings without rich results. The brand held page-one positions for 140-plus product and category terms, but organic CTR on product terms averaged 2.0%, below the appliances category benchmark of roughly 3.0%. Their listings showed a title, a meta description and a URL — nothing else.
• No review data to mark up. Only 11% of SKUs had even a single verified customer review. Competitor listings and parallel Daraz results displayed star ratings because those sellers had either collected reviews or surfaced marketplace ratings. This brand had never built a post-purchase review collection flow, so even perfect schema would have had nothing to render.
• Structured-data errors suppressed eligibility. The product template emitted basic Product JSON-LD, but a crawl found 1,180 product URLs with validation errors: price formatted as a string, missing availability, missing priceCurrency, and conflicting duplicate tags left over from a theme update. Search Console showed zero URLs approved for any rich result type.
• Merchant Center misaligned. The product feed carried structural errors and did not match the on-page schema (GTIN and brand fields were inconsistent between feed and markup), so the store was not eligible for merchant listings experiences — the free shopping surfaces that appear for product queries.

The core diagnosis was simple and is worth stating plainly: you cannot mark up reviews you do not have. This engagement therefore had to run on two tracks at once — building the review collection infrastructure that creates the data, and implementing the review and merchant listing schema that renders it in search.

Phase 1 — Diagnosis and Cleanup (Weeks 1-2)

We opened with a full crawl using Screaming Frog supplemented by manual validation of the highest-revenue templates, then cross-referenced against Search Console enhancements and Merchant Center diagnostics. The audit produced a single prioritized matrix scoring every template on search volume, current ranking position and ease of implementation.

Issue layer	URLs affected	Example defect
Missing schema entirely	96 product pages, 14 category pages	New launches after theme update shipped with no JSON-LD
Broken or invalid schema	1,180 product URLs	price as string, missing availability, duplicate tags
No review data	89% of catalog	No post-purchase review request flow in place
Feed / schema mismatch	All Merchant Center items	GTIN and brand inconsistent between feed and markup

Cleanup happened before any new markup was written. We removed the duplicate and conflicting tags left by the theme update, standardized every block to JSON-LD, corrected data types (price as number, priceCurrency set to PKR, availability mapped to live stock status), and mapped the catalog’s existing fields to schema properties so future products would inherit correct markup automatically. We also prioritized the top 180 SKUs by revenue and 38 category pages with existing rankings, accepting that the long-tail catalog would follow in Phase 3.

In parallel, we instrumented the review collection gap as a measurement problem: baseline review submission was roughly 0.4% of delivered orders, and only 11% of SKUs carried any review at all. Cleaning the schema without addressing this number would have produced technically valid markup with empty aggregateRating fields — eligible for nothing.

Phase 2 — Build and Restructure (Weeks 3-5)

Phase 2 ran the two tracks together: review collection so the data would exist, and schema implementation so the data would render.

Review collection infrastructure

We built a post-purchase review flow across the two channels Pakistani buyers actually respond to. A Klaviyo email sent at day 7 after delivery asked for a rating and a photo, with a small incentive (entry into a monthly PKR 10,000 store-credit draw). A WhatsApp Business API message at day 21 followed up on non-responders, because open rates on WhatsApp in Pakistan run several times higher than email. Review submission rose from 0.4% to roughly 9% of delivered orders within six weeks, and the share of SKUs with at least one review began climbing immediately. We also wrote a moderation workflow so only verified-buyer reviews with a matching order were surfaced in markup, keeping the data policy-compliant. The rule mattered for eligibility as much as ethics: Google’s review snippet policies explicitly discount reviews that cannot be tied to a real purchase on the page they appear on, and the brand’s earlier instinct to surface unverified or syndicated reviews would have triggered manual action rather than rich results. The moderation queue matched each incoming review to an order ID, held anything unmatched for manual review, and excluded reviews below a minimum word count so that the rendered markup carried genuine content rather than star-only ratings. On the rendering side, we capped the number of review entries emitted in the JSON-LD to the most recent five per product to keep the markup payload light, and loaded the full review gallery client-side only when a shopper scrolled to it — a decision that protected the LCP Core Web Vital, which sat near 2.1 seconds on product templates and which we did not want a heavy structured-data block to push back over threshold.

Schema implementation

For the top 180 SKUs we deployed complete Product markup with Review and AggregateRating nested correctly:

Schema property	Data source	Notes
name, description, sku, gtin13, mpn	PIM / Shopify	Aligned to Merchant Center feed
offers.price, priceCurrency, availability	Live store data	price as number, PKR, live stock
aggregateRating (ratingValue, reviewCount)	Review platform	Only verified-buyer reviews counted
review array (author, rating, body, date)	Review platform	Capped render to keep page weight sane
brand, image, productID	Catalog	Matched feed values exactly

The deliberate choice here was aligning the on-page schema with the Merchant Center feed on GTIN, MPN, brand and condition. That alignment is what unlocks merchant listings experiences — the free product cards that appear for commercial queries — and it is the step most Pakistani stores skip. We deployed the markup at the template level rather than page by page, editing the product template so every current and future product inherited correct structured data automatically.

For the 38 category pages we added ItemList markup with a representative aggregateRating and price range, which made category pages eligible for rating snippets in their own right. We also rolled out BreadcrumbList, Organization and WebSite schema site-wide to support sitelinks search box and seller-rating eligibility downstream.

Phase 3 — Optimize and Scale (Weeks 4-8)

We set up weekly Search Console monitoring across three rich result types — product snippets, product review snippets and merchant listings — and tracked impressions, approval status and CTR before and after each URL gained enhancements.

First star ratings appeared in Week 5 for the top 30 SKUs. By Week 6, 2,860 product URLs were approved for product and review rich results, and merchant listing impressions had begun flowing. The CTR split was immediate and stark: product pages that displayed star ratings averaged 2.54% CTR against the 2.0% pre-implementation baseline.

Week	URLs approved	Rich-result impressions	Merchant listing impressions	Avg CTR (product terms)
4	0	0	0	2.0% (baseline)
5	312	1,400	0	2.1%
6	1,480	6,900	3,100	2.3%
7	2,210	12,400	11,800	2.4%
8	2,860	16,200	22,500	2.54%

Three rejections in Week 6 taught us the policy edges fast. Google rejected a batch of 84 URLs because the client had hoped to seed credibility by pulling Daraz marketplace reviews onto the D2C site; that is a policy violation (reviews must be for the product on the page they appear on, and self-serving review markup on merchant pages is restricted). We removed the syndicated reviews, repopulated with verified-buyer reviews only, and the URLs were approved within the next crawl cycle. A second batch was rejected for marking up reviews on category pages instead of products; we corrected the type. These rejections were useful — they confirmed the markup was being read — and the weekly monitoring let us fix them inside 48 hours rather than losing a quarter to silent ineligibility.

With the top 180 SKUs stable, we scaled the rollout to the remaining catalog, prioritizing new launches and seasonal lines, and added productGroup schema for variant families (an air fryer sold in three colours and two sizes) so Google understood the parent-child relationship.

Phase 4 — Measure and Compound (Weeks 8-12)

Phase 4 turned a one-off implementation into a compounding system. Three mechanics made the gains durable rather than a spike.

First, review freshness. Schema that points at stale reviews decays in eligibility over time, so we built a quarterly recrawl-and-refresh routine that re-rendered aggregateRating from the latest verified reviews and flagged SKUs whose review count had stagnated. Second, seller-rating eligibility. Google requires a minimum volume of reviews to qualify for seller ratings at the account level, and crossing that threshold around Week 10 unlocked an additional rating surface in branded searches. Third, feed hygiene. We tied the Merchant Center feed to the same source of truth as the on-page schema, so a price or stock change in the store updated both surfaces together and the feed never drifted out of sync again.

By Week 12, 64% of the catalog carried review data, 2,860 product URLs were approved for rich results, and the store was eligible for merchant listings across its core categories.

Final Results

Measured at 90 days from the start of implementation:

Metric	Before	After	Change
Organic CTR (product terms)	2.0%	2.54%	+27%
Organic product clicks (monthly)	baseline	+34%	—
SKUs with review data	11%	64%	+53 points
URLs approved for rich results	0	2,860	—
Merchant listing impressions / month	0	22,500	—
Structured-data errors	1,180	340	-71%

Revenue context. With a stable organic conversion rate and an average order value near PKR 11,500, the additional organic product clicks from rich results translated into a meaningful lift in assisted organic revenue. These figures are illustrative — a buyer should treat them as a realistic outcome shape to sanity-check fit, not an audited third-party result. The larger point is that the gain came from inventory the brand already owned (rankings it already had) by making that inventory clickable.

What Made This Work

1. Reviews before markup. The single highest-leverage decision was refusing to write schema until a review collection system existed. Markup on empty data renders nothing. Building the day-7 email and day-21 WhatsApp flow first meant every percentage point of schema coverage mapped to real star ratings.

2. Schema aligned to the feed, not just to the page. Matching GTIN, MPN, brand and condition between on-page markup and the Merchant Center feed is what unlocked merchant listings. Most Pakistani stores implement page schema and ignore the feed; doing both multiplied the surfaces the brand appeared on.

3. A prioritized implementation matrix. Focusing first on the top 180 SKUs by revenue and 38 ranked category pages produced visible results in five weeks instead of three months. The long-tail catalog followed once the framework was proven.

4. WhatsApp in the review loop. Email alone would have left review submission near Western benchmarks. Adding a WhatsApp follow-up roughly doubled effective submission rates and reflected how Pakistani buyers actually communicate after delivery.

5. Policy-compliant review data. Resisting the temptation to syndicate Daraz reviews onto the D2C site avoided a policy strike. Verified-buyer reviews only, marked up on the product they belong to, kept the markup eligible.

6. Weekly monitoring with fast rejection fixes. Treating Search Console as a live dashboard — and fixing rejections inside 48 hours — prevented the silent ineligibility that quietly negates months of implementation work on most stores.

What Teams Can Apply

For Pakistani ecommerce and appliance retailers:

• Audit review volume before you touch schema. If fewer than 15% of your SKUs have reviews, your first project is a review collection flow, not markup. Schema simply renders what already exists.
• Treat the Merchant Center feed and on-page schema as one system. Pick GTIN, MPN, brand and condition values once and push them to both surfaces. The free merchant listings surface is underused in Pakistan and rewards this discipline directly.
• Prioritize the revenue head of the catalog. Mark up your top 20% of SKUs first. Eighty percent of the CTR lift typically comes from that slice, and it gives you a result to show stakeholders inside a month.
• Build review collection into the post-purchase flow on WhatsApp and email. Incentivize photo reviews, moderate for verified buyers, and let the data accumulate. Crawl-error reduction and schema fixes matter, but review volume is the constraint that bounds everything else.
• Validate before you deploy, and monitor after. Run markup through a structured-data validator pre-launch, then watch Search Console weekly for rejections. Markup that is technically present but silently rejected is the most common failure mode here, and it is invisible without monitoring.

For a broader look at the underlying service, our product review schema and structured data implementation covers the full scope, and the ecommerce industry hub frames the demand patterns this work plugs into. If crawl health is part of the blocker, a technical SEO audit is usually the right first step before structured-data work begins.