DEV Community

Cover image for Cleaning Up a 1,500-Product Halal Grocery Catalog: A WooCommerce SEO Case Study
Sandra Sakura
Sandra Sakura

Posted on

Cleaning Up a 1,500-Product Halal Grocery Catalog: A WooCommerce SEO Case Study

Cleaning Up a 1,500-Product WooCommerce Catalog: What I Learned the Hard Way

TL;DR: I spent months working on the catalog for a halal grocery store in Shinjuku, Tokyo (JB Halal Food) that serves the Bangladeshi, South Asian, and Southeast Asian communities living in Japan. 1,500+ WooCommerce products, hundreds blank or half-written, no product variations set up anywhere, inconsistent claims on the packaging, and imports that quietly failed without anyone noticing. Here's what that actually looked like day to day.

The starting point

The store imports and sells halal groceries — everything from Bangladeshi fish and Pran-brand snacks to Indonesian sambal and instant noodles — to a diaspora customer base scattered across Japan. It runs on WordPress + WooCommerce with the Umart theme and Rank Math for on-page optimization, plus Klaviyo for email.

The catalog itself told a messier story:

  • ~1,547 total products
  • 400 completely blank
  • 115 with poor/thin descriptions
  • Zero existing variable products — every different weight or size of the same item was a separate, unrelated simple-product listing

That last point mattered more than it sounds. A store selling the same rice brand in 1kg, 5kg, and 10kg bags had three disconnected product pages, no shared reviews, and no way for a customer to switch sizes without leaving the page.

Problem 1: "Halal" isn't a checkbox, it's a content policy

You can't just slap a halal badge on everything and call it done — some suppliers publish dual-market products (domestic vs. export-certified versions of the same packaging), and getting that wrong is a trust problem, not just an SEO one. I ended up writing an actual policy:

  • Only claim halal when there's real evidence (certification language visible on the label/photo)
  • Whole categories like dry spice blends and rice are treated as low-risk by default
  • Products from majority-Muslim countries of origin get a more liberal pass
  • Anything with a known dual-market conflict (a well-known instant noodle brand, for example) gets flagged and the claim withheld until confirmed

This turned "write a product description" into "write a product description that won't misrepresent what's actually in the package."

Problem 2: Multilingual SEO for a catalog nobody else is optimizing

Most of this inventory has never been properly indexed anywhere in English or Japanese — it's diaspora-specific and long-tail by nature. The fix wasn't "translate the title," it was matching the language in the title to the product's actual origin:

  • Bangladeshi brand → Bengali term in the title
  • Indonesian brand → Bahasa Indonesia term
  • Generic/no-brand item → English + Japanese only, never defaulting to Bengali just because most of the catalog skews Bangladeshi

Getting this wrong (defaulting everything to Bengali) was a mistake I made and had to correct — a generic no-brand spice doesn't need a Bangladeshi label just because the store's core customer base is Bangladeshi.

Problem 3: The import that silently never happened

At one point I discovered a batch of 20+ product descriptions — fully written, reviewed, ready — that had simply never made it live. The CSV existed. The work was done. But re-checking a later store export showed the same products still blank. Somewhere between "file delivered" and "product live," an import step had failed silently.

The fix was procedural, not technical: never assume a written batch is live. Cross-check every batch against the next fresh store export before marking it done. I caught multiple recurrences of this same gap over the course of the project.

Problem 4: What's actually a duplicate

With a catalog this size, "duplicate" isn't binary. I ended up with three real categories:

  1. True duplicates — same product, same weight, accidentally listed twice (delete/merge)
  2. Size/weight variants — same product, different sizes, that should be WooCommerce product variations, not separate listings
  3. False positives — different products that just have similar names (a 100g and 500g mustard seed listing from two different unrelated brands, for instance) — these are not duplicates at all, and treating them as such would have removed real inventory

Getting the third category wrong early on meant real products were being incorrectly flagged and held back from going live.

Problem 5: Setting up variations from zero

Since the store had never used WooCommerce variable products, I had to build the pattern from scratch on a real example (a tea brand sold in three sizes across four different old listing IDs, one of which was already a duplicate). That meant:

  • picking one listing to become the "parent" variable product (keeping its URL for SEO continuity)
  • converting the others into variation rows
  • setting the old duplicate listing IDs to a non-published status
  • flagging that 301 redirects were needed from the old URLs to the new parent URL

That single conversion became the template for every subsequent multi-size product line.

What this actually looked like week to week

Not glamorous. Mostly:

  • Batches of 15–30 product descriptions at a time, grouped by category or origin
  • Every batch cross-checked against the live sitemap before adding internal links (never guessing a URL)
  • A running "unresolved duplicates" list that got triaged in bulk at the end rather than one at a time
  • A biweekly report covering hosting, SEO, Google Ads/Merchant Center, email, and video — because content work alone doesn't mean much if the site had a multi-day outage that quarter (it did — about 4–5 days of downtime that had to be factored into any traffic or sales analysis)

The takeaway

None of the individual problems here are exotic — bad imports, unclear duplicates, missing variations, inconsistent claims. What made this project hard was scale plus the lack of any existing convention to fall back on: no prior variable products, no reliable SEO plugin scores to audit against (Rank Math's fields were confirmed unreliable on this install and had to be ignored), and a catalog serving eight-plus language communities at once.

The unglamorous fix, every time, was the same: don't guess, verify against the live site, and build the missing convention once so the next 100 products don't repeat the same decision from scratch.


Have you dealt with a WooCommerce catalog that grew faster than its data model? Curious how others have handled variable-product retrofits on a live store — drop your approach below.

Top comments (0)