# What Is a Product Catalog in an Online Store?

> What a product catalog is, what data it keeps for each item, which system is in charge of each field and how it differs from a product feed.

URL: https://clione.ai/glossary/product-catalog/
Lang: en

When someone talks about an online store's catalog they do not mean the PDF a wholesaler sends its customers, or [Shopify Catalog](/glossary/shopify-catalog/), the product database of many stores that Shopify distributes across AI channels. They mean your store's database: **every product you sell, with its data kept in fields**. It matters to you because everything that leaves the store is read from there. The [product page](/glossary/product-page/), the filters on the [category page](/glossary/category-page/), the [product feed](/glossary/product-feed/) you send to Google and the [structured data](/glossary/structured-data/) that search engines and assistants read are views of the same catalog: an error in the catalog repeats in all of them.

## What it includes

Platforms describe it in almost the same words. For BigCommerce, the catalog is the collection of a store's physical and digital products and includes all the information about each product, such as the [MPN](/glossary/mpn/), warranty, price and images.[^bigcommerce-catalog] Shopify organizes that information on three levels:[^shopify-products]

- **The product**, the container for everything shared: title, description, manufacturer.
- **The options**, what the buyer chooses, such as color or size, each with its values.
- **The variants**, each combination that can be bought, such as "Red / S". **Each variant has its own price, stock and barcode.**

[Product variants](/glossary/product-variants/) are the reason a catalog has more rows than products: a T-shirt in four sizes and three colors is one product and twelve items that can be bought, each with its [SKU](/glossary/sku/). BigCommerce models it the same way, with a set of variants per product and a SKU on each one.[^bigcommerce-catalog]

Around that core, a catalog keeps four more kinds of data:

- **Attributes**: [product attributes](/glossary/product-attributes/), such as material or dimensions, in fields of their own. In BigCommerce, whatever has no standard field goes in [custom fields](/glossary/bigcommerce-custom-fields/) of up to 250 characters.[^bigcommerce-catalog]
- **Identifiers**: the [GTIN](/glossary/gtin/), the brand and the MPN, which say exactly which product it is.
- **Organization**: categories and collections. Shopify defines collections as groupings of products that the merchant creates to organize the catalog and make the store easier to browse.[^shopify-products] The more your categories resemble a standard [product taxonomy](/glossary/product-taxonomy/), the less an outside reader has to guess.
- **Content**: the [product description](/glossary/product-description/), the images and the videos.

[Schema.org](/glossary/schema-org/) even has a type for describing a catalog in markup, OfferCatalog: an [ItemList](/glossary/itemlist/) of related offers, or of other catalogs, from the same seller.[^schema-offercatalog] What is usual in a store, though, is not to mark up the whole catalog but each product page, with its product and its offer.

## Who is in charge of each field

A catalog can have one source of truth or several, and it pays to know which one is yours. Shopify distinguishes two ways of working with its API: **either Shopify is the source of truth** and changes are made field by field, **or the source of truth is an external system**, such as an ERP or a [PIM](/glossary/pim/), and a sync replaces the product's full state in one go.[^shopify-products]

The practical consequence is in the second: if a PIM syncs the whole product, whatever someone corrects by hand in the store admin disappears on the next sync. It is nobody's mistake, it is the design. The problem appears when nobody has decided which system is in charge of each field and two systems write the same one.

## Catalog, product page, feed and markup

Nobody outside sees the catalog as it is. What shoppers, search engines and assistants see are its outputs: the published product page, that page's markup and the feeds you send to each platform. Google recommends giving product data both ways, markup on the page and a [Google Merchant Center](/glossary/google-merchant-center/) feed, because that makes you eligible for more experiences and helps it understand and verify your data. And it adds that **some experiences combine the two sources**: a product snippet can take the price from the feed if it is not in the markup.[^google-product-sd] If the catalog is consistent, its outputs are; if it is not, Google sees two versions of the same product.

## In a store

**Fictional example.** A mountain gear store sells a backpack in two colors. This is how it looks in its catalog, with the system in charge of each field:

| Level   | Field    | Value                             | In charge    |
| ------- | -------- | --------------------------------- | ------------ |
| Product | Title    | "Ruta Backpack, 30 liters"        | The platform |
| Product | Brand    | Ruta                              | The PIM      |
| Product | Material | Recycled polyester                | The PIM      |
| Product | Category | Trekking backpacks                | The platform |
| Variant | Color    | Black / Green                     | The PIM      |
| Variant | SKU      | RUTA30-BLK / RUTA30-GRN           | The ERP      |
| Variant | GTIN     | The manufacturer's, one per color | The PIM      |
| Variant | Stock    | In stock / Out of stock           | The ERP      |

From that table come a product page with a color selector, markup with one product and its offer, and two rows in each feed, one per variant. If someone changes the material in the platform's admin, the PIM writes it back on the next sync; **the correction is made in the system in charge**, not in the one you can see.


That the feed is the catalog. When Merchant Center rejects a product, the temptation is to fix the data in the feed, with a rule or a supplemental source, and call the problem closed. But the store still holds the bad data, the product page and its markup still publish it, and Google combines the feed with the page's markup.[^google-product-sd] **Fixing the feed without fixing the catalog leaves two versions of the same product.**


## How to check it

1. **Count products and variants.** Export the catalog from the platform's admin and see how many rows it has against how many products. Each variant should have its own price, stock and code.[^shopify-products]
2. **Pick ten products and note, field by field, where each is edited**: in the platform, in a PIM, in an ERP or in a spreadsheet. If two systems write the same field, one of them overwrites the other.[^shopify-products]
3. **Compare the product page, the markup and the feed** for those products: title, [price and availability](/glossary/price-and-availability/) have to match in all three.[^google-product-sd]
4. **Look for products with no category or in seasonal categories**, such as "New arrivals" or "Sale", which do not say what the product is.
5. **Look at the custom fields**: if an important fact, like size or capacity, lives in the description and not in a field, no filter and no feed will find it.

## Related concept: product feed

The catalog is the complete set of data, inside your store; a feed is an export of part of that catalog, in the format a specific destination asks for and at the frequency that destination accepts. One catalog feeds several feeds, one per platform, and none of them has all the data. That is why **the quality work is done in the catalog**, with [catalog enrichment](/glossary/catalog-enrichment/) and [semantic enrichment](/glossary/semantic-enrichment/), and the feeds inherit it.

To go further, the [catalog and entities reading path](/learn/catalog-and-entities/) orders the rest of the terms, from the attribute to the [product graph](/glossary/product-graph/).