How to Prepare a Product Catalog for AI, SEO and Marketplaces

In the supplier’s spreadsheet the color is written as “bl.”, on the website as “dark blue”, and the marketplace requires a value from its own dictionary. One product has three different names, incomplete specifications and two article numbers. While the assortment is small, managers fix this by hand. But as the catalog grows, manual edits stop keeping up, and errors start hitting search, advertising, stock and returns.

A strong product catalog structure is not a list of cards but a data model. It has to feed the website and its filters, AI search, SEO, advertising feeds and external sales channels equally well. Below are five maturity levels of a catalog: see where you are now and what moving to the next level gives you.

Level 0. Data lives in supplier files

Signs: names and specifications are copied from price lists, color and material are free text, the same product looks different in different categories. Filters either do not work or show odd values.

What the next step gives: as soon as value dictionaries appear, filters start working correctly and managers stop spending hours hunting for duplicates.

Level 1. There is a source of truth for every field

The first systemic decision is to define where the master version of each data type is stored. The most common scheme: prices and stock live in the ERP, descriptions and attributes in a PIM or CMS, images in a media library, customer data in the CRM. The marketplace is only a publishing channel, not the place where a product is edited.

The principle is simple: one place of change and one responsible person per field. When a price can be changed simultaneously in accounting, on the website and in the marketplace account, discrepancies are inevitable.

Level 2. Attributes have become dictionaries

An attribute is not just a field but a name, a data type and a list of allowed values. Instead of free text where the color is written as “black”, “blk” and “Black”, you need a normalized dictionary.

It helps to split product attributes by purpose: general for everything (brand, country, warranty), category-specific (screen size, material, power), variant-defining (color, size), operational (weight and dimensions for delivery) and channel-specific ones needed only by a particular marketplace. For every category, fix the mandatory fields — and forbid automatic publication of a product with empty ones.

The effect is immediate: filters stop duplicating values, and the share of products rejected by channels falls.

Level 3. Product and variants are separated

The data model has to distinguish a product from its variants. One sneaker model has a shared name, description and photos, but every size-and-color combination is a separate SKU with its own stock and barcode.

If this difference is not built in from the start, the store either multiplies duplicate cards or cannot show availability of a specific size. For variants, define identifiers, the link to the parent product, the set of variant attributes, URL rules and canonical in advance. For marketplaces and Google Merchant Center you will need correct GTIN barcodes: without them some channels will reject the product or show it worse.

Level 4. Search and AI understand the catalog

AI search and assistants use more than the name. They need specifications, purpose, compatibility and limitations. When a shopper asks “will this case fit my phone”, an answer is only possible if compatibility is recorded in the data rather than buried in the description text.

What works best is a short description without marketing noise, a specifications table, usage scenarios, a list of compatible products and a short FAQ on the card. Availability and delivery times must be pulled from an up-to-date source rather than copied into the text. And the rule that saves you from complaints: the model must not invent a missing parameter — if there is no data, the system should ask a clarifying question. More on this in our materials on AI product search and the AI assistant for an online store.

Categories that match demand

Categories are built from the shopper’s perspective, not the warehouse’s. If goods are stored by supplier but people search for “everything for camping”, the tree must follow the second logic.

A good taxonomy has clear names without internal jargon, a minimum of nesting levels and stable addresses that do not change with every reorganization. Google recommends building a crawlable chain of links from the menu to categories and products: a product that can only be reached through internal search may never be found by the robot. Which categories to create is suggested by demand analysis — see our article on keyword search volume.

Catalog SEO

A catalog has unique category and product pages, manageable metadata, canonical, an XML sitemap and Product structured data. Templates for title and description across thousands of cards are normal practice, but priority pages should keep manual editing. A category description should help the choice rather than repeat the keyword. Filter indexing rules are designed separately — see the article on faceted navigation.

Exporting to marketplaces

Rozetka, Prom, Epicentr or Allo have their own category trees, mandatory fields and requirements for photos and names. That is why you need a mapping between the internal model and every channel. Without it, managers fill in cards by hand every time, and import errors accumulate unnoticed.

Before sending the feed, automatically check mandatory attributes, price and currency format, availability, image quality, name length and category matching. It is equally important to return import errors to the responsible manager rather than leave them in a marketplace account nobody opens.

Catalog quality metrics

Data quality is measured just like sales. The most telling metrics are:

• completeness of mandatory attributes by category;
• number of duplicate SKUs and products without a category;
• share of errors during channel export;
• share of zero-result queries in internal search;
• discrepancies in prices and stock between systems.

Once these numbers are on a dashboard, improving the catalog stops being a one-off campaign and becomes a routine process.

An update process without manual fixes

The most robust scheme looks like this: a supplier or manager adds data, the system normalizes values against dictionaries, validation checks mandatory fields, a responsible person approves the content, and only then the data is published to all channels. Errors go back to the owner, and every change is logged — so you can tell who changed a price or a specification and when.

Frequently asked questions

Does a small store need a PIM system?

With up to a few thousand products and one or two channels, a well-configured CMS with attribute dictionaries is enough. A PIM becomes justified with tens of thousands of SKUs, several languages and many sales channels.

Where should catalog cleanup start?

With an audit: which attributes are filled in, where the duplicates are, which categories bring the most sales. Start with the most profitable categories — the effect will be visible fastest there.

How long does moving to the next level take?

Cleaning up attributes in one large category usually takes a few weeks. A full rebuild of the data model with integrations takes several months and is split into stages.

How does the catalog affect AI search?

Directly. AI can only find what is described in the data. The more complete and structured the attributes, the more accurate the answers and recommendations.

The GL.ua team can design a catalog model, integrate PIM and ERP with the website and prepare data for AI search, SEO and marketplaces. The earlier the standards are fixed, the fewer manual corrections after scaling. You can start with an SEO audit of your current catalog.