Rozetka feed: why products get rejected when the validator says «OK»

The seller's cabinet says «N of M products uploaded» and stops there. Which positions failed, on what grounds and what to do about them now — not a word. The owner runs an online validator, it counts the structure of the file and awards a hundred points. Then the question goes to the developer, the developer opens the feed in a browser, sees perfectly normal XML and replies that everything is being served correctly on the site's side. Both are right, and that is exactly why nothing moves.

On 5 September 2026 we collected 28 public YML feed addresses belonging to other people's stores and ran them through the core of our validator with the Rozetka preset, plus additional checks taken from the marketplace's official «XML file requirements» help page, retrieved the same day. Twenty-one feeds parsed, holding 88,991 products. Nine of them were built specifically for Rozetka — it shows in the address — and those nine hold 30,279 positions. Seven addresses did not parse: four dead or closed, one hit a request limit, two have broken structure, more on those below.

The headline result of the run is this. The basic structure — identifier, price, currency, category — is intact in 16 feeds out of 21. That is precisely what most online validators check, and precisely what they award a hundred points for. Feeds with no violation of Rozetka's mandatory elements at all: two, and one of those is rejected wholesale anyway for a missing currencyId. Genuinely clean, one remains. It holds 28 products.

What Rozetka treats as mandatory

The marketplace's help page lists the mandatory elements outright: yml_catalog, shop, currencies, categories, offers, offer with id and available, stock_quantity or quantity_in_stock, price, currencyId, categoryId, picture, vendor, name or model, description, param. On attributes it is explicit: «name and value must be filled in». On stock: «positions without this tag will have the status „out of stock“». On the identifier: «the characters Aa-Zz and 0-9 are permitted, Cyrillic and spaces are not».

Half of that list is not structure but content. A structural validator will notice a missing param only if it has been specifically taught that the tag is mandatory for Rozetka. Here is how often the content was missing in the run of 5 September 2026.

The ordering in the two right-hand columns differs, and that is the most interesting thing in the table. Attributes drop out most often by feed, stock hurts most by product: six files, yet almost 43% of the whole sample. The reason is that stock is never missing «a bit»: either the tag is on every position or on none. In a wholesale price list of tableware and household goods with 19,907 positions the stock tag is nowhere to be found. The store is used to the available="true" attribute and considers the availability question closed, while Rozetka keeps a position on sale only as long as the stock number is above zero.

The right-hand column exists to answer the easiest objection: that the sample is full of generic files nobody intended for Rozetka in the first place. Among the nine feeds built specifically for this marketplace, seven have no attributes, five no brand, three no description. So the issue is not that a file is «not for Rozetka» — it is that the export module works the same way everywhere.

Small things that are not small

Descriptions shorter than 50 characters: 13 feeds out of 21 (62%), 1,726 products. In a souvenir feed that is 500 positions out of 551. Formally the description is filled in, the letter of the help page is satisfied, and the product card is empty.

Duplicate names: 11 feeds (52%), 903 products. The help page words the requirement as «there must not be more than one position with an absolutely identical name». In practice these are the same product in different colours or sizes, with the difference never carried into the name. In an auto parts feed there are 529 such positions, 13% of the file; in a wholesale cosmetics feed, 101 positions, 15%.

Identifiers with a hyphen or a colon (277685-07, MO:39689-5546) appear in three feeds, and that is 23,926 products — 26.9% of the sample. Honesty is required here: formally such characters fall outside the permitted set, while in practice a hyphen usually passes. We saw no rejection caused by it and we do not claim there will be one. But before uploading a large catalogue this is the item that is cheaper to check separately than to work out after the fact.

Images over http instead of https: one feed, but the whole of it — 5,088 products. More than fifteen images per position: three feeds, 319 products; the consequence here is mild, the marketplace simply takes the first fifteen.

When it is the whole file, not a product

In four feeds an error in a single line removes the catalogue entirely.

In feed E, built for Rozetka, all 6,108 positions carry a currencyId with the value BRG while the currencies block is empty. By the marketplace's own guide only hryvnia, dollar and euro are accepted, so not one position in this file carries a valid currency — it looks like a module setting nobody noticed. In feed N the currency is declared as id="1.00000000" instead of a code, so UAH in the products does not match what was declared: 1,103 positions. In feed O every currencyId is empty and the description is empty in 978 products out of 981. In feed T with 31 products there is no currencyId at all — this is that second «clean» file, rejected not on content but on currency.

Two more files did not parse at all. A sporting goods feed with 11,410 positions has shop as its root without yml_catalog: formally it is not YML, and parsing stops on the first line. In a clothing and gifts feed with 2,661 positions the products are wrapped in item instead of offer and the images sit in image — a private format that no marketplace reads as YML.

Where this comes from

The export module produces the YML format, not a feed for a particular marketplace. It takes the fields already present in the store's database and lays them out into tags: name, price, category, image, availability flag. Everything Rozetka demands on top of that usually exists in the store as well — but it sits somewhere other than where the module reads.

Attributes live in product options or simply in the description text, whereas the feed needs them as separate param entries with name and value filled in. The brand in many catalogues is either empty or replaced by the article number. Stock exists in the accounting system, but nobody mapped it into the stock_quantity tag, because for another marketplace the available attribute was enough. The file meanwhile is valid, it parses, it weighs its tens of megabytes — in the run of 5 September 2026 three feeds were larger than 60 MB, the biggest 89 MB — and it looks entirely workable.

One further observation about where these files come from. Six of the eleven feeds found by walking typical paths are served by one and the same export module for OpenCart. So the mistake is not personal: stores export their catalogue with one tool on the same default settings.

What to do about it

First, run your own file through the Rozetka preset in the YML feed validator. Since 5 September 2026 it checks these exact elements and returns specific offer id values with the name of the check, rather than an overall score. How to read the result and what to hand the developer is covered in the seven reasons a marketplace rejects a feed — no need to repeat it here.

Second, look at the lists of positions rather than at the score. A hundred points means the file is structurally intact and nothing more: in our run 16 feeds out of 21 earned that mark, among them the one without a single attribute on a single product.

Third, and this is the tool's honest limit: the validator does not know whether the product card itself will pass moderation. It sees the file, not the requirements of a particular marketplace category, not photo quality, not whether the description matches the product. It does not replace the check inside the seller's cabinet — it only cuts down how many times you go through it.

When it turns out the fields have to change on the store's side rather than in the file, work on the catalogue and field mapping begins: how we do it is described on the Rozetka integration page.

The order of work suggests itself. Currency and the root of the file come first, because they remove the catalogue as a whole. Stock comes next: it silently moves a position to «out of stock», and the buyer sees a card they cannot buy from. Then brand and attributes, without which the card does not meet category requirements. Duplicate names and over-short descriptions come last: they break the letter of the help page, but they do not stop the file from parsing.

What this run does not prove

The stores for it were found through open feed addresses: walking typical paths across 118 domains produced 11 files (9%), another 12 addresses came from searching open source code on GitHub, and five of those are already dead or closed. That method skews the sample — it holds more OpenCart installations and dropshipping warehouses than the market at large.

Twelve feeds out of 21 were built not for Rozetka but for other marketplaces or as generic YML. We applied Rozetka's requirements to them as candidates: what if this same file were handed to Rozetka. The situation is not invented, it is exactly what stores do when they enter a second marketplace. But the figures across all 21 and the figures across the nine dedicated feeds differ, which is why the table carries both columns.

And finally. The run of 5 September 2026 describes the state of files, not the outcome of an import: the feeds were measured from the outside, and we did not upload them into these stores' cabinets.