Structured Data Implementation Case Study in Pakistan

The Client

A Sialkot-based sports-goods manufacturer that has made cricket equipment and hand-stitched footballs for export buyers since the early 1990s, supplying club and institutional buyers across Pakistan and the Gulf. Sialkot’s manufacturing cluster gives brands like this one a genuine supply advantage: bats, pads, gloves, kit bags and match-grade footballs are produced in-house or by neighbouring units, which means domestic retail margins stay healthy even when the brand prices below imported alternatives. Three years before this engagement, the company opened a D2C channel — a WooCommerce store carrying roughly 1,150 SKUs, with an average order value near PKR 6,800 and a pronounced seasonal rhythm: club and school procurement peaks between August and October, and the PSL window in February and March lifts bat and merchandise sales nationwide.

The D2C operation ran lean: a four-person marketing team, monthly paid spend near PKR 2.4M across Meta and Google, a Daraz storefront for marketplace demand, and around 92,000 monthly sessions of which 31,000 were organic. An earlier in-house WooCommerce SEO programme had fixed page titles, image alt text and page speed, and rankings responded — the store held page-one positions for 210 product and category terms. But clicks had not followed rankings, and that disconnect is what brought the team to WeProms.

One asset made this store unusual. Its on-site review form was purchase-gated: only buyers with a delivered order could post, verified against the order record. Over two years that form had quietly accumulated 2,917 verified reviews across 472 of the 1,150 SKUs — a review corpus most Pakistani D2C brands would take years to build. The engagement described here is an illustrative composite built from common patterns in Pakistani manufacturer-D2C ecommerce, anonymized and aggregated, not a report on a single named client.

The Problem

The store’s proof existed but was invisible. Diagnostics across a full site crawl, Google Search Console and Merchant Center surfaced six linked defects:

• Stale rating markup on a sliver of the catalog. A review plugin retired in a 2023 theme migration still emitted aggregateRating on 68 product URLs, with counts frozen at a one-time import. Those 68 URLs displayed “14 reviews” in markup while the page showed 61 — a mismatch that holds eligibility back, because review markup has to describe the review content actually visible on the page.
• No rating markup anywhere else. The other 1,082 product URLs carried WooCommerce’s default Product output with no Review or AggregateRating at all, despite 404 of them holding verified reviews in the database.
• Export-era defaults leaking into markup. The theme had been configured when the company’s web presence served export buyers, and priceCurrency: USD survived on 340 URLs now priced in PKR — one of the most common defects in Pakistani manufacturers that add a domestic store to an existing export site.
• Availability not wired to stock. 214 out-of-stock products declared InStock in their Offer markup because availability was a static theme field rather than a live feed from the inventory system.
• Variants splitting the signals. A bat sold in three weights and two sizes generated four indexable URLs. Reviews attached themselves to whichever child URL the buyer landed on, so a product holding 40 reviews in aggregate showed 11 on the ranking URL. Google saw thin, contradictory signals where it should have seen one well-reviewed product.
• Feed and schema disagreeing. The Merchant Center feed was maintained in a spreadsheet with brand names typed inconsistently and GTINs missing for distributor lines, leaving only 9% of items eligible for merchant listings.

The result was measurable in Search Console: 940 URLs carried structured-data warnings, zero URLs were approved for review snippets, and product-URL CTR averaged 1.9% against a category benchmark near 2.9% — while two national competitors and several Daraz listings showed star ratings for the same queries.

Phase 1 — Audit and Source-of-Truth Mapping (Weeks 1-2)

The audit had to answer one question precisely: for every schema property we intended to emit, what is the single system of record that holds the true value? Everything else followed from that map.

We crawled the full domain, exported Search Console enhancement reports, pulled Merchant Center diagnostics, and exported the review database with each review’s SKU, order reference, rating and timestamp. The four sources reconciled into one defect matrix:

Defect layer	URLs affected	Example finding
Stale aggregateRating from retired plugin	68	Markup showed 14 reviews; page showed 61
priceCurrency: USD on PKR-priced URLs	340	Export-era theme default never migrated
Out-of-stock items marked InStock	214	Availability field static, not wired to inventory
Missing brand, gtin13, mpn	1,082	Product identification impossible for Google and Merchant Center
Variant children competing with parents	2,300+ indexable URLs	One bat across 4 URLs, reviews split between them
No BreadcrumbList, Organization, WebSite markup	Sitewide	No seller identity signals for Google to verify

Cleanup preceded any new markup. The retired plugin’s output was removed outright rather than patched — its data source no longer existed, so any fix would have been a new stale snapshot. The variant structure was mapped family by family: 190 variant families were identified, each with a designated parent URL to become the ranking and canonical URL, and every existing review was reassigned to its family parent so the full review history would count in one place.

The phase closed with the source-of-truth map — name, sku and description from the WooCommerce product record; price, priceCurrency and availability from live store data; aggregateRating and individual review entries computed from the verified-review table; brand, gtin13 and mpn from a normalized catalog sheet built once and maintained by the merchandising lead; sameAs and organization details from a fixed profile document. Prioritization followed revenue: the top 220 SKUs by trailing 90-day revenue and 34 ranked category pages went first.

Phase 2 — Template-Level Schema Rebuild (Weeks 3-5)

The build replaced the plugin stack with one function in the child theme that renders JSON-LD per template. Nothing in the new markup is entered by hand at the product level — every value is computed at render time from the sources mapped in Phase 1, which is what makes the implementation durable instead of a one-off cleanup.

Rating markup wired to living data

Product templates now emit Product with offers (price as a number, priceCurrency: PKR, availability mapped live from inventory, itemCondition), plus aggregateRating computed from the review table on every request. The three most recent verified reviews are rendered visibly on the product page and marked up in a capped review array, keeping the markup payload light while satisfying the requirement that review markup describe reviews the page actually shows. The full review gallery loads below the fold for shoppers without entering the structured data at all. BreadcrumbList went sitewide, and Organization plus WebSite schema with consistent sameAs references gave Google a stable seller identity to verify against.

Schema block	Source of truth	Notes
Product name, sku, description, image	WooCommerce product record	Template-rendered, never hand-entered
offers price, priceCurrency, availability	Live store + inventory	PKR, live stock status, item condition
aggregateRating (ratingValue, reviewCount)	Verified-review table	Computed at render; cannot drift
review array (top 3, capped)	Verified-review table	Same entries visible on the page
brand, gtin13, mpn	Normalized catalog sheet	Identical values pushed to the feed
ProductGroup + isVariantOf	Variant family map	Parent URL canonical for each family

Variant consolidation

For the 190 variant families, the parent URL became the canonical, fully marked-up product, with child variants expressed through ProductGroup and isVariantOf instead of standing alone. Reviews reassigned in Phase 1 now aggregate on the parent — where the consolidated rating is also rendered visibly, keeping the markup honest. A bat family that previously showed 11 reviews on its ranking URL now shows its true 40, and the thin duplicate child URLs were consolidated rather than left to compete with the parent.

Feed alignment

The spreadsheet-fed Merchant Center feed was replaced with a scheduled XML export generated from the same normalized catalog table that feeds the schema — one source for brand, gtin13, mpn, PKR price and availability, pushed to both surfaces together. This is the step most Pakistani stores skip, and it is what converts technically valid product markup into merchant listings eligibility. The full scope of this work is covered in our schema markup and structured data implementation service page.

Phase 3 — Validation, Recrawl, and Warning Burn-Down (Weeks 4-8)

Validation moved into the deployment loop rather than sitting at the end. Every template change was tested on staging against Google’s structured-data tools before release, and after each deploy the affected sitemaps were resubmitted to pull recrawls forward. From Week 4 a weekly burn-down tracker reconciled Search Console enhancement reports against the defect matrix from Phase 1.

Week	Valid review snippets	Review-snippet impressions	Product-URL CTR
4	0	0	1.9% (baseline)
5	96	3,100	1.98%
6	318	9,400	2.12%
7	512	19,600	2.27%
8	611	31,000	2.38%

The first star ratings appeared at Week 5 on the highest-revenue cricket SKUs, whose pages Google happened to recrawl first. The warning burn-down ran in parallel: the 340 priceCurrency defects cleared with the template swap, the 214 availability mismatches cleared once inventory became the live source, and the 68 stale-markup URLs converted to valid snippets once their counts were computed from the review table. One batch of 23 URLs was held at “reviewed” status because their visible review counts changed faster than recrawl — a timing artifact that resolved itself over two crawl cycles rather than a defect.

By Week 8 the CTR split told the story cleanly: product URLs displaying review snippets averaged 2.38% against the 1.9% baseline, and the gap widened as coverage grew. Merchant Center followed the same curve — eligibility moved from 9% of items to 44% by Week 8 as the feed and schema started agreeing on brand and GTIN values.

Phase 4 — Review Velocity and Compounding (Weeks 8-12)

Markup renders what exists, so the final phase pushed the constraint that bounds everything else: how many SKUs hold at least one review. At baseline, 472 of 1,150 SKUs (41%) had reviews; the catalog’s remaining two-thirds had nothing for markup to show.

The store had never systematically asked for reviews — the purchase-gated form simply existed. We built a request flow timed to ground truth: order tracking already polled TCS and Leopards courier APIs, so the review request fires by email three days after the courier reports “delivered,” when the product is in the buyer’s hands and the purchase is still remembered. No blanket broadcasts, no incentives — just a single well-timed ask. Review submission rose from roughly 2% to 7% of delivered orders, adding about 230 verified reviews over the window, concentrated on high-traffic SKUs that had never collected one. SKUs holding at least one review rose from 472 to 690 — 60% of the catalog — and valid review snippets followed to the same 690 URLs.

Two routines made the gains durable. A quarterly re-validation now runs the full catalog through structured-data testing and reconciles Search Console against the defect matrix, catching theme updates that silently regress markup — the exact failure mode that created this engagement’s stale plugin problem. And the weekly Search Console tracker continues as a standing report, because silent ineligibility is the default state of unmonitored schema: nothing errors loudly, stars simply never appear.

Final Results

Measured at 90 days from the start of implementation:

Metric	Before	After	Change
Rich-result CTR (product URLs)	1.9%	2.41%	+27%
Product URLs with valid review snippets	68	690	+622 URLs
SKUs with at least one verified review	472 (41%)	690 (60%)	+19 points
Review-snippet impressions / month	0	46,000	—
Merchant listing eligible items	9%	68%	+59 points
Structured-data warnings	940	263	-72%
Non-brand organic clicks (monthly)	14,600	18,100	+24%

Two honesty notes belong next to those numbers. First, the engagement window overlapped the start of club procurement season, so a portion of the click growth is demand that would have arrived anyway; compared against the category trend, the normalized lift is nearer 16%. Second, the revenue translation is modest and should stay modest in any honest accounting — at a 1.4% conversion rate and PKR 6,800 average order value, roughly 3,500 additional monthly non-brand clicks figure to about PKR 330K in incremental monthly organic revenue. The compounding value is structural: organic’s share of online revenue moved from roughly 19% to 24%, and every future review now strengthens markup that renders it automatically. These figures are illustrative — a realistic outcome shape to sanity-check fit, not an audited third-party result.

What Made This Work

1. One source of truth for every emitted value. Because aggregateRating is computed from the same review table that renders the page, markup and visible content cannot disagree — the defect that held the original 68 URLs back is structurally impossible now.

2. Template-level implementation, not plugin-level. Schema written into the WooCommerce product template means every future SKU inherits valid markup on its first day live. The plugin the store retired in 2023 was the source of the stale data; the rebuild deliberately avoided recreating that dependency.

3. Variant consolidation before markup. Moving reviews onto 190 parent URLs concentrated rating signals on the URLs that actually rank. Without that step, even perfect markup would have advertised thin, split review counts.

4. Feed and schema fed from one table. Normalizing brand, gtin13 and mpn once and pushing the values to both Merchant Center and on-page markup took merchant listing eligibility from 9% to 68% — a second free surface from the same repair.

5. Validation living inside the deploy loop. Staging-time structured-data tests, sitemap resubmission on deploy, and a weekly burn-down tracker turned a one-time project into a monitored system, catching timing artifacts and regressions within days instead of quarters.

What Teams Can Apply

1. Inventory the review data you already own before assuming you need a collection programme. Pakistani stores frequently have review corpora trapped in databases, export portals or marketplace accounts. The first diagnostic question is not “how do we get stars” but “where does our proof currently live, and why can’t search see it.”

2. Test whether existing markup matches what’s visibly on the page. Run your highest-revenue templates through a structured-data validator and compare the marked-up review count against the page. Mismatched counts hold eligibility back even when the markup parses cleanly — and stale plugins are the most common cause.

3. Consolidate variants before writing rating markup. If one product lives at four URLs, your reviews are being split four ways. Designate canonical parents, express variants through ProductGroup, and render the consolidated rating visibly on the parent page.

4. Normalize identification fields once, then push them everywhere. Decide brand, gtin13 and mpn values in one sheet and feed both your schema and your Merchant Center export from it. Disagreement between the two surfaces is the single biggest merchant-listings blocker for Pakistani ecommerce.

5. Time review requests to courier delivery status, not to a fixed number of days. In a market where delivery windows swing from two days to two weeks, a “day 7” email is arbitrary. Triggering on the courier’s delivered status lifted submission roughly threefold here without incentives.

For teams mapping this against broader channel strategy, the ecommerce industry hub frames the demand patterns this work plugs into, and structured-data repairs of this kind pair naturally with a wider technical review when crawl health is part of the blocker.