How do you normalize product data from different retailer websites into one schema?

Pick the target before writing any extractor. Model three levels: the product (what the item is), the variant (the color and size combination someone actually buys), and the offer (one store's price and stock for that variant). Most normalization bugs come from flattening these: a price with no variant, or a "product" that is really one color of one.

{
  "product": {
    "title": "Men's Tree Runner",
    "brand": "Allbirds",
    "category_path": ["Apparel & Accessories", "Shoes", "Sneakers"],
    "attributes": { "material": ["eucalyptus fiber"] },
    "identifiers": { "gtin": null, "mpn": null, "group_id": "mens-tree-runners" }
  },
  "variants": [
    {
      "sku": "33179624669264",
      "options": { "color": "Jet Black (White Sole)", "size": "8", "size_system": "US" },
      "color_family": "black",
      "gtin": null,
      "offer": {
        "store": "allbirds.com",
        "url": "https://www.allbirds.com/products/mens-tree-runners?variant=33179624669264",
        "price": { "amount": "100.00", "currency": "USD" },
        "original_price": null,
        "availability": "in_stock",
        "retrieved_at": "2026-11-06T14:02:11Z",
        "source": "json_ld"
      }
    }
  ]
}

• Prices are a decimal amount plus an ISO 4217 currency code, never a display string. Keep the current and the original price.
• Availability is an enum per variant: in_stock, out_of_stock, preorder, or unknown. Unknown is not the same as out of stock.
• Provenance on every offer: the URL, when it was retrieved, and which source each field came from.
• Raw beside normalized: keep the store's own label ("Oatmeal Heather") next to the value you mapped it to (beige), so you can re-map later without re-crawling.

You don't have to invent field names. schema.org's Product, ProductGroup and Offer, and Google's Merchant Center product data specification (gtin, mpn, item_group_id, size_system), are good starting vocabularies, and stores already publish data in their shape.

A retailer's product page usually carries the same product several times over. Read the sources in order of reliability, and fall back only when a field is missing:

• JSON-LD (<script type="application/ld+json"> with schema.org Product, ProductGroup or Offer). The most common source, but it often describes only the default variant, or carries a price that lags the page.
• Platform data. Shopify stores serve /products/<handle>.js with every variant, its price in cents and its availability. Other platforms expose their own JSON endpoints or embed state in the page, such as __NEXT_DATA__.
• The page's own API calls for price and stock, which are often the only place per-size stock appears.
• Rendered HTML last. Selectors are the first thing to break when a store redesigns.

Record which source each field came from. When sources disagree (JSON-LD says $120, the page shows $96 on sale), prefer the one closest to what a shopper sees and log the disagreement. Disagreement rates per store are the earliest signal that an extractor has drifted.

Use deterministic parsers for prices, currencies and units. An LLM earns its place on the long tail: mapping store categories into your taxonomy and pulling attributes such as material or fit out of descriptions. Validate its output against your schema's enums, and keep the input so you can re-run it when the prompt or model changes.

Normalized records only become comparable once you know which ones are the same item. Use a ladder, strongest key first, and stop at the first rung that answers:

• GTIN (UPC, EAN, ISBN). Left-pad every GTIN to 14 digits and validate the check digit before trusting it. Many stores publish none, and some publish one variant's GTIN on the whole product.
• Brand + MPN (manufacturer part number), after normalizing the brand and stripping punctuation and spaces from the MPN.
• Brand + model + key attributes (model tokens from the title, capacity, color, size), scored for similarity, with a threshold you tune on a few hundred labeled pairs.
• Image similarity as a tiebreaker only: retailers reuse manufacturer images across colors and sizes.

Match variants, not pages. "128 GB" and "256 GB" often share one product page, and a page-level match would compare their prices as if they were the same thing.

The same jacket is one page with a color picker on one store, five pages (one per color) on another, and one listing per color and size on a marketplace. Normalize all three into one product group whose variants are keyed by option values, each with its own SKU, GTIN, price, stock and image. Group with the store's own group ID when there is one (schema.org productGroupID, the Shopify product ID, Google's item_group_id); otherwise group by brand, a normalized title stem and shared images.

Stock belongs to the variant. A product that reads "in stock" because one size is left is the most common wrong answer a shopping assistant gives.

• Refresh on a schedule that matches how fast things change: daily for most catalogs, more often for price-sensitive categories and during sales, and just in time before you show a price to someone.
• Detect changes instead of re-crawling everything: sitemap lastmod, ETag and Last-Modified headers, and product feeds where a store offers one.
• Validate each run against the schema and alert on drift. A sudden share of products with no price, no variants or a price of zero usually means a store redesigned its pages.
• Keep `retrieved_at` on every offer and show it. A price without a timestamp can't be trusted.

You can build every step above yourself, use an extraction API for steps 1 and 2 and keep matching and freshness in house, or use a product data service that does all of it for the stores it covers.

How to choose

• A few stores and full control over the schema: build it. The six steps above are the whole job.
• Long-tail stores or non-commerce pages, in your own schema: an extraction API such as Firecrawl or Zyte, with your own matching and refresh jobs.
• Configurable bulk collection from specific marketplaces: Apify Actors, with your own field mapping.
• Identifier-keyed datasets with price history for analytics: Datafiniti.
• An app or agent that needs current products from many stores in one schema now: a product data API such as StoreRouter or Channel3. Check each one's coverage of the stores you need first.

Prices and capabilities are from each vendor's public docs and pricing pages as of November 6, 2026. Side-by-side detail: StoreRouter comparisons.

StoreRouter runs steps 2 to 6 for the stores it covers. It crawls them, extracts from structured sources first, maps every product into one schema (variants with per-size stock, current and original price, GTIN and group ID where the store publishes them, a normalized category path and enriched attributes such as material and style), and re-crawls a store when it changes. Call parse with any product URL and the same shape comes back, whichever store it came from.

A practical way to adopt it: use it as the normalized source for covered stores, keep your own pipeline for the rest, and compare both outputs on a sample of your URLs first.