Uploading to Yandex.Market: automatic feed with categories and filters

I received a call from a client who owns a wholesale company selling industrial oils and lubricants. Catalog on WooCommerce - almost seventeen thousand positions. “Oleg,” he says, “we’ve been trying to upload normally to Yandex.Market for six months. We tried three plugins, hired a freelancer, he did some coding on his knees, but the feed constantly crashes, moderation does not accept, half of the products do not have categories, and prices from 1C come with a delay of a day. We are losing money every day." I listened and thought - this is not a unique situation. I hear this regularly, from different clients, from different niches. Yandex.Market is the largest price aggregator in Russia, and uploading to it has long turned into one of those tasks that seems simple on paper, but turns into a nightmare in practice.

It would seem - what’s so complicated? You generate an XML file in YML format, upload the URL to your Market account, and the products appear in the search results. In reality, everything is completely different. The YML specification of Yandex consists of dozens of required and recommended fields, each of which has its own restrictions. Categories should follow the Market tree, not your internal WooCommerce structure. Product variations must be submitted in a special format with group_id. Prices should be current, not yesterday's. Images are available via direct URL without redirects. Delivery and pickup - with specific terms and costs by region. And if anything is wrong, moderation rejects the feed or, worse, accepts it partially, and you don’t even know which of your seventeen thousand products are actually shown to customers and which ones quietly fell off.

I am developing the COS WP Woo plugin for WooCommerce, and the upload module to Yandex.Market was one of those that we started making at the direct request of clients. Not because we wanted another YML feed generator plugin - there are already enough of them on the market. But because none of the existing ones solved the whole complex of problems at the same time: flexible filtering, category mapping, support for variations, automatic updating on a schedule, integration with 1C and, most importantly, validating the feed before you upload it to the Market and receive a moderation refusal. Let's take a look at how it all works and why existing solutions most often fall short.

What is a YML feed and why are there so many problems with it

YML format - Yandex Market Language - is an XML extension developed by Yandex specifically for loading product offerings. It sounds technical, but in essence it is just a file that describes your catalog: store name, currency, category tree and a set of product offers (offers). Each offer is a product card with a name, price, description, URL, images and a bunch of additional parameters such as manufacturer, country of origin, barcode and characteristics.

The problem is that there is a huge gap between “here is my WooCommerce store with products” and “here is a valid YML feed for the Market”. WooCommerce stores data in its own structure - product post type, meta fields, taxonomies, attributes, variations as child posts. None of these concepts map one to one on YML. The product name in WooCommerce may contain HTML tags or special characters that are not valid in XML. Categories in WooCommerce are an arbitrary tree that does not coincide with the Yandex.Market category tree. The price can be empty (product “on request”), with a discount (sale price), with or without tax - and YML expects one specific number. Images are stored as attachment ID, and the full URL must be inserted into the feed - and the URL must be working, without broken links, and preferably without query parameters with dimensions.

I've seen feeds generated by other plugins where in one file there were products without a category, products with a price of zero, products without a single image, and products with a description of fifteen thousand characters - despite the fact that Market cuts off the description after three thousand. Formally, this is valid XML, and even the Market will accept it. But half of the products will not pass moderation, and the store owner will spend weeks figuring out why out of seventeen thousand positions only two thousand are shown in the search results. This is why feed generation is not just a matter of “converting data from one format to another.” This is filtering, cleaning, validating and enriching data before it goes to Yandex.

When we designed the Yandex Feed module in COS WP Woo, we immediately decided that the approach would be different. Not “unload everything and pray”, but “unload only what is ready for the Market, and show what needs to be improved.” This is a fundamental difference, and it affects the entire architecture.

Let's look at the specific tasks that need to be addressed during unloading and how we approached each of them.

YML file generation begins with store settings - name, URL, currency, company. These are top-level parameters that rarely change, but which must be in the feed. Next comes a block of categories. This is where the first serious problem begins - mapping WooCommerce categories onto the Yandex.Market tree. The market has its own taxonomy of several thousand categories, and your internal categories like “Industrial oils → Hydraulic → HLP” do not match what Yandex expects. In the Market it may be “Oils and lubricants → Hydraulic oils”, and the category ID will be completely different.

Honestly, a lot of plugins just dump your WooCommerce category tree as is. And it works - Yandex will accept your categories. But the products will not be distributed optimally, the search for them will be worse, and you will lose in conversion. Our approach is to make it possible to map each WooCommerce category to the corresponding Yandex category. In the module settings there is a mapping section where you see two trees side by side - yours and Yandex's - and simply connect them. Categories that you have not mapped are uploaded with your original name, and the module marks them with a warning: “Not mapped to a Yandex category - products may not be classified accurately.” This is not a bug, the feed will work, but at least you know what can be improved.

Next is the meat of the matter - product offerings. Each WooCommerce product is turned into one or more offer elements in YML. A simple product - one offer. Variable product - a separate offer for each variation, united through group_id. This is where the second big problem begins that I regularly encounter with clients.

WooCommerce stores variations as child posts (post_type = product_variation) and they have their own inheritance logic. A variation can have its own price, or it can inherit its parent price. It may have its own description, or it may not - then the parent’s description is taken. Images - if the variation has its own gallery, take it, if not, take the parent's gallery. SKU - similar. Weight and dimensions are the same. Each field needs to be checked along the inheritance chain, and this is not a trivial task.

Many feed generators simply take variation data directly and do not check the fallback against the parent. As a result, offers appear in the feed without a description, without images or without a price - because for a particular variation this data is not filled in, it is inherited from the parent, but the plugin does not know about it. We process the entire inheritance chain correctly, and each offer in the feed is guaranteed to have all required fields.

There is another nuance with variations that few people take into account. Yandex.Market expects that variations of one product will differ in specific parameters - color, size, volume. And these parameters must be specified as param elements in the offer. Simply generating different URLs for each variation is not enough - you need to clearly show how they differ. Our module automatically detects the attributes that differentiate variations and adds them as parameters to the feed. If you have a product “Hydraulic oil HLP 46” with variations in volume - 5 liters, 20 liters, 200 liters - then in the feed there will be three offers with group_id and the “Volume” parameter with values ​​5, 20 and 200, respectively. The market will understand that this is one product in different packaging and will display them correctly.

Filtering: why you shouldn't upload the entire catalog

Now let's talk about filtering - and this is, perhaps, the aspect that distinguishes a serious unloading module from an amateur script. The first instinct of any store owner is to unload everything. Seventeen thousand products? Let's get all seventeen thousand to the Market! The more the merrier, right?

No. Not true. And I'll explain why. Yandex.Market is not a storefront, it is an aggregator with competition. You pay for every click on your product. If there is an item in the feed that is out of stock, the buyer will click, go to your site, see “out of stock” and leave. You paid for the click but didn't get the sale. If there is a product in the feed with a price of 150 rubles per canister of oil, this is clearly an error, but the buyer will click and then leave a negative review. If there is a product in the feed without a description and without an image, it simply will not convert, but it will take up space in the feed and can affect the overall quality rating of your store in the eyes of Yandex.

Therefore, filtering is not a nice-to-have, but a must-have. In our module, you can configure filters based on several parameters, and I will talk about each of them in detail.

Filtering by category is the most obvious. You choose which WooCommerce categories to include in your feed and which to exclude. Typical scenario: you have a category “Services” or “Used” - they cannot be uploaded to the Market or it is impractical. Or you have a “New Items” category that duplicates products from other categories—and you don’t want duplicates in your feed. You can include specific categories (whitelist) or exclude specific ones (blacklist) - as is more convenient for your catalog size.

Filtering by tags works similarly. In practice, our clients often use WooCommerce tags for internal marking: “not for Market”, “seasonal”, “liquidation”, “premium”. If you add a tag to exclusions, all products with this tag will not be included in the feed. This is more convenient than moving products between categories, especially when the same product needs to be temporarily removed from the Market without affecting its position in the site catalog.

Filtering by availability status is perhaps the most important. There are three options here. You can only upload products that are in stock - this is the safest mode, you only pay for clicks on products that you can actually sell. You can upload products in stock and “to order” (backorder) - if you know how to quickly deliver goods to order and want to cover more requests. And you can upload everything, including missing ones - but then the feed will have the available="false" attribute, and the Market will show them as “out of stock,” which can be useful for maintaining a position in the search results for competitive queries.

Filtering by price range is what saves you from uploading erroneous data. You set the minimum and maximum price. A product with a price of 0 rubles or 1 ruble is an obvious data error and will not be included in the feed. A product with a price of 10 million rubles is also most likely a mistake. I saw a catalog where, due to an import failure from 1C, the prices of several products were listed in kopecks instead of rubles - oil for 1 ruble 50 kopecks per canister. Without a price filter, these goods would go to the Market, and the consequences would be unpleasant.

There is also filtering based on the presence of mandatory data - this is not a separate setting, but part of the validation logic. A product without a name, without a price, or without at least one image is automatically excluded from the feed and ends up in the list of “problem products” on the module’s dashboard. We'll talk about this a little later, when we get to validation.

All these filters are combined. You can say: “Take categories A, B and C, exclude products with the tag “not for the market”, only products in stock, with a price from 100 to 500,000 rubles.” And out of your seventeen thousand positions, let’s say, twelve thousand will end up in the feed—exactly those that are ready to be placed on the Market and will actually convert.

Delivery, scheduling and integration with 1C

A separate big topic is settings for delivery and pickup in the feed. Yandex.Market allows you to specify delivery terms directly in YML, and this greatly influences the positioning of your products in search results. Buyers filter by delivery method, by time, by cost - and if you do not have this data filled in, you simply fall out of a significant part of the search queries.

In our module, delivery settings work on two levels. The global level is the default conditions for the entire store. You specify the delivery cost, time in days, region - and these parameters apply to all products, unless overridden. This is the delivery-options element in the shop section. The second level is individual conditions for specific products or categories. A heavy product - a 200 liter barrel of oil - has a different delivery cost than a 5 liter canister. You can set rules by categories or by weight ranges, and the module will automatically set the correct conditions for each offer.

The same thing with pickup - pickup. If you have several pickup points, you indicate them all, and each point can have its own operating hours. The feed will contain outlet elements with correct data for each point. This is especially important for regional companies with several warehouses - the buyer sees that they can pick up the goods in their city, and conversion increases.

I know that many people think: “Well, then I’ll set up delivery in the Market account.” Yes, you can. But if the delivery terms are specified directly in the feed, they are updated automatically along with the rest of the data. There is no need to go to your account and change tariffs manually. We raised the shipping cost - changed it in the module settings - the next generation of the feed already contains new prices. For a company with dynamic rates, this saves hours of manual work every month.

Now about the update schedule - and this is the thing that distinguishes “set and forget” from “I constantly monitor and regenerate by hand.” Yandex.Market recommends updating your feed at least once a day, and if your prices or availability change frequently, then every few hours. If the feed is out of date, the Market may show out-of-date prices or products that are out of stock. This leads to negative reviews and a decrease in the store’s rating.

Our module uses Action Scheduler, the same background task engine that WooCommerce uses for its own needs. You set a schedule: every hour, every two hours, every six hours, once a day - and the module automatically regenerates the feed in the background. Without blocking the site or slowing it down for visitors. For a catalog of seventeen thousand positions, generation takes from thirty seconds to a couple of minutes - depending on the server and the number of variations. Action Scheduler processes this asynchronously, and even if the generation takes longer, the site continues to work as usual.

And here we come to integration with 1C - and this, in my opinion, is the key advantage of a single plugin over a set of separate solutions. If you use our integration module with 1C (which works through the OData API, and not through the outdated CommerceML), then prices and balances from 1C automatically go to WooCommerce - and from there to the YML feed. The chain looks like this: the manager changes the price in 1C → the OData connector catches the change via a webhook or on a schedule → updates the price of the product in WooCommerce → the next generation of the feed includes the current price. All this happens without human intervention.

Why is this important? Because the alternative is two separate plugins (one for 1C, the other for Market) that know nothing about each other. The 1C plugin updated prices at two in the morning, and the Market plugin regenerated the feed at six in the morning - but four hours passed between these events, and if someone bought a product at that time at the old price in the Market, you have a problem. With a single plugin, you can set up feed generation immediately after synchronization with 1C is completed - one action launches another through the Action Scheduler. The chain is closed, and the feed always contains the latest data.

I remember a case with a client who sells motor oils. He had two separate plugins - one for integration with 1C, the other for generating a feed. They were conflicting at the cron task level because they were both using wp_cron and WordPress was trying to run both tasks at the same time. As a result, the feed was generated with half of the updated data - some of the products already had new prices from 1C, and some still had the old ones. The market showed different prices for the same product in different offers. The client received complaints from customers and could not understand what was wrong until we sorted out the chain. With a single module, such conflicts simply do not happen - all tasks are coordinated through one Action Scheduler.

Separately, I want to say about the leftovers. It is critically important for the Market that a product marked as “in stock” is actually in stock. If a buyer orders a product and you cannot ship it, Market reduces the store’s rating, even blocking it. When balances are synchronized from 1C, the feed module automatically takes them into account when generating. A product with zero balance can be either excluded from the feed altogether (if filtering by availability is configured) or marked as unavailable. And if you have several warehouses in 1C - Basic, Marketing, Katana - the module summarizes the balances for all warehouses that you specified in the synchronization settings and uses the final figure. Not just “yes/no”, but a real number that Market can also use for ranking.

Pricing is another thing that often breaks down when using different plugins. In 1C there can be several types of prices: “Retail”, “Wholesale”, “Retail SITE”, “Purchase”. For the Market, you need a specific one - the one for which you sell to retail customers through the website. Our 1C module allows you to specify what type of price to map on WooCommerce regular price, and the same price goes into the feed. If you have a discount price (sale price), it also goes into the feed, and the Market will show the old price crossed out next to the current one. This visually attracts buyers and increases the CTR of your offers.

Validation: catching problems before Yandex

Now for what I think is one of the most underrated features - feed validation before sending. Most plugins generate a feed and that’s it. Then you upload it to the Market and wait for the results of moderation. If something is wrong, you get errors after a few hours or days, fix it, regenerate it, download it again, wait again. One “fixed - checked” cycle can take a week if you have a large catalog and Market moderation is busy.

We've built validation directly into the module. After each feed generation, the module goes through all offers and checks them for compliance with Yandex.Market requirements. Not just “is the XML valid”, but a meaningful check of each product offering. What is checked is that the title is not empty or too long, the price is positive and in a reasonable range, there is at least one image and the image URL is available, the description does not exceed the character limit, the category is specified, the product URL is valid and leads to an existing page. For variations, the presence of group_id and distinguishing parameters is checked. For goods with delivery - that the terms and costs are indicated.

Validation results are displayed on the Yandex Feed module dashboard directly in the WooCommerce admin panel. You see three groups: successfully validated (green), with warnings (yellow) and with errors (red). For each problematic product, a specific reason is shown - “No image”, “Price is zero”, “Description exceeds 3000 characters”, “There is not a single attribute that the Market can use as a parameter.” You can click on a product, go to its card in WooCommerce and fix the problem right now, not after Market rejects your feed.

Do you know what the most common warning is? “There is no alt text for the image.” Yandex.Market does not require alt text for images in the feed, but recommends it. And if out of seventeen thousand products you have, twelve thousand do not have alt text, this is a reason to think not only about the feed, but also about the SEO of the site as a whole. By the way, COS WP Woo has a module for batch generation of alt texts using AI - you can solve this problem in one launch.

Another common problem is duplicates. The same product can appear in the feed twice if it is in two categories and both are included in the filter. Our module tracks uniqueness by product ID and ensures that each product (or variation) is presented exactly once in the feed. Duplicates are a direct path to problems with moderation and a decrease in the quality of the feed in the eyes of Yandex.

Another thing I haven’t seen anywhere else is feed preview. Before you copy the feed URL and paste it into the Market dashboard, you can view the first N product offers directly in the browser, in a readable format. Not raw XML, but a structured table: title, price, category, number of images, availability, parameters. This allows you to quickly verify that your feed looks the way you expect, without having to parse the XML file in head or in a third-party validator.

It’s worth mentioning separately about the feed size. For a catalog of seventeen thousand positions with variations, the YML file can weigh several tens of megabytes. Yandex.Market accepts files up to five hundred megabytes, so this is usually not a problem, but download time does matter. The market periodically retrieves the feed at the specified URL - and if your server serves the file slowly or with a timeout, the data update will be delayed. Our module generates a static file and serves it directly via Nginx/Apache, without going through PHP - this is as fast as possible and does not load the server.

I realize this may all sound like a bunch of technical details that only developers need. But in fact, it is these details that determine whether your upload to the Market will work stably for months without your intervention or will require constant manual control. We aimed for the first option - set it up once, and it works. The feed is updated, prices are up to date, new products are added, those removed from sale disappear, validation catches problems before they reach the Market.

Product parameters and offer structure

A separate topic that deserves attention is working with product parameters in the feed. Yandex.Market actively uses parameters (param elements) for faceted filtering and product comparison. If your oil has a specified viscosity, flash point, base type (mineral, synthetic, semi-synthetic) - the buyer can filter products by these parameters directly in the Market results. This significantly affects conversion, because the buyer sees exactly what he needs, and not your entire catalog of seventeen thousand items.

In WooCommerce, product parameters are stored as attributes (taxonomies like pa_viscosity, pa_base-type) or as meta fields (if you use custom fields). Our module automatically maps WooCommerce attributes to YML param elements. You can customize which attributes to include in your feed and which not. For example, the buyer does not need the internal attribute “1C Code” - it can be excluded. And “Viscosity”, “Volume”, “Manufacturer” - turn on.

For each attribute, you can specify a name that will be displayed in the Market. If in WooCommerce the attribute is called pa_viscosity-class, and for the buyer it is “SAE Viscosity Class” - you set a human-readable name in the mapping, and it will appear in the feed exactly in this form. The market will show “SAE viscosity class: 5W-30” - it is clear both for the buyer and for search filters.

If you use our custom fields module (ACF replacement), then data from custom fields can also be included in the feed as parameters. Let's say you have a custom field "GOST Certificate" with a GOST number - it can become a parameter in YML. Or “Temperature range of application” - from minus forty to plus one hundred and twenty. All this enriches the product card on the Market and increases buyer confidence.

I noticed an interesting pattern in practice: products with five or more parameters in the feed receive significantly more clicks than products with one or two parameters. The market loves detailed cards - they provide more filtering options, and Yandex ranks them higher. So if you have data, use it. Fill in the attributes in WooCommerce (or in 1C, from where they are synchronized), and the module will automatically upload them to the feed. Each completed parameter is a small plus for the visibility of your products.

Now about the offer structure as a whole. YML supports several offer types - standard (type=vendor.model), simplified and custom. We use the simplified type as the default because it is the most flexible and fits most products. But if you have products with a clear division into manufacturer (vendor) and model - for example, “Shell Helix Ultra 5W-40” where Shell is vendor, and Helix Ultra 5W-40 is model - you can switch to the vendor.model type. The market will better structure information and will be able to group products from the same manufacturer.

Vendor is taken from the WooCommerce attribute or from a custom field - you specify where exactly it comes from in the mapping settings. Country of origin (country_of_origin) - similar. Barcode - from a meta field or attribute. Our module doesn't force you to store data in any specific field - it adapts to your data structure, not the other way around.

There is another point that is often missed - the product URL in the feed. It would seem that we just take permalink and insert it. But the URL must be absolute, with the https protocol, without unnecessary query parameters, and it must lead to an actual page. For variations, the URL must include parameters that select the specific variation. Our module generates correct URLs for every case, including handling multilingual sites (if you use WPML or Polylang) and IDN domains (like butter.site, which turns into xn--80aa6ac0a.xn--80aswg in the URL).

Speaking of images. The market accepts up to ten images per offer. We upload the main image of the product and all images from the gallery, but no more than ten. If the image URL leads to an image with resize query parameters (as CDN plugins often do), we take the original URL without parameters - it’s more reliable. And we check that the URL returns HTTP 200 and not 404 - broken links to images are one of the most common reasons for product rejection by moderation.

Let's talk about what happens once the feed is up and running. Because customization is fifty percent of the business. The second fifty are monitoring and adaptation. The market is constantly changing its requirements, adding new required fields, and tightening checks. Your catalog also lives - new products appear, old ones are deleted, prices and descriptions change. The feed should reflect all these changes automatically, without manual intervention.

On the dashboard of the Yandex Feed module we show key metrics: how many products are in the feed, when was the last generation, how long did it take, are there any errors or warnings, what is the file size. If something went wrong - for example, the generation failed with an error or the number of products in the feed decreased sharply - you will see a warning. A sharp reduction in the number of products usually means that something has broken in the data: mass price reset, category deletion, problem with 1C synchronization. It’s better to learn about this from the plugin’s dashboard than from a buyer who can’t find your product on the Market.

I thought for a long time whether it was necessary to add notifications by email - like, “your feed has been generated, here are the statistics.” We decided not to add it yet, because it quickly turns into spam, which everyone ignores. Instead, a visual indicator on the dashboard in the WooCommerce admin panel. If you log into the admin area at least once a day (and who doesn't?), you will see the status of the feed.

I want to tell you about one more situation that happens more often than we would like - a data conflict between WooCommerce and Market. You uploaded the feed, the Market accepted it, and the products appeared in the search results. And a week later you updated the product description in WooCommerce, making it longer and more detailed. The feed was regenerated, the Market updated the data - and suddenly the product stopped being moderated because the new description contained prohibited words or exceeded the character limit. The product disappears from the display, and you don’t understand what happened. Our validation catches such changes during generation and displays a warning: “Product X: description has increased from 2800 to 3500 characters, exceeds the Market limit.” You can shorten the description before the issue reaches moderation.

Here's another funny story from practice. For one client, an auto chemicals manufacturer, the feed worked perfectly for three months. And then eight hundred goods “fell” at once. We started to look into it - it turned out that the marketer had massively updated product descriptions through WP All Import, and the descriptions included HTML tags that broke the XML structure of the feed. Not the entire feed, but specific offers - those where the description contained, for example, an unclosed tag or an ampersand symbol without escaping. The Market's XML parser simply skipped everything after the first broken offer, and the products quietly disappeared. We added sanitization of descriptions - strip_tags, cleaning of special characters, normalization of spaces - into the feed generation pipeline, and since then such problems have not arisen. But without validation, this bug could live for months undetected.

You know, over the years of working with uploading to the Market, I came to one important conclusion: the quality of the feed is more important than the number of products in it. It’s better to upload three thousand perfectly prepared products - with filled parameters, high-quality images, correct prices and descriptions - than seventeen thousand, half of which have problems. The market takes into account the quality of the store when ranking, and a store with a high percentage of rejected products is ranked lower than a store where all products are moderated the first time. Filtering and validation in our module are aimed at exactly this - to help you upload the highest quality feed, and not the largest one.

What to choose and how to start

I often hear the question: how does your module differ from existing plugins for generating YML? On the market there is YML for Yandex Market, WP All Export with a YML template, several paid solutions from CodeCanyon. The honest answer is that functionally, many of them solve a basic problem: generating an XML file in YML format from WooCommerce data. The difference is in the details.

The first is integration. A separate plugin for generating a feed does not know anything about your integration with 1C, about your B2B prices, about custom fields, or about the content moderation system. COS WP Woo is a single ecosystem where all modules work together. Prices from 1C automatically appear in the feed. Custom fields from the CF module automatically become parameters. SEO checks from the audit module complement feed validation. This is not marketing blah blah, but a practical difference: less conflict, less manual work, less chance of something breaking.

The second is validation. I have not seen a single plugin that checks each product for compliance with Market requirements before generating a feed and displays a list of problems in a user-friendly interface. Usually you learn about problems from the Market moderation report, after a few hours or days. And then the quest “find the problematic product among seventeen thousand” begins. Our dashboard shows problems right away.

Third - Action Scheduler instead of wp_cron. WordPress cron is not a real cron, it runs when you visit a site. If your site has little traffic (which happens with B2B stores during non-business hours), the cron may not launch on time and the feed will not be updated. Action Scheduler works differently - it guarantees that tasks are completed at a given interval, even if no one visits the site. For a mission-critical task like updating a feed, this is essential.

Fourth, support for variations with correct data inheritance. This sounds like a small thing, but in practice, incorrect handling of variations is the most common source of feed problems. A product without a price, without a description, without an image - all this is a consequence of the fact that the plugin does not know how to follow the inheritance chain from variation to parent.

If you are currently using another plugin for generating YML and it works, I am not saying that you urgently need to change everything. But if you encounter moderation problems, if the feed is updated irregularly, if prices from 1C arrive with a delay, if you spend time manually checking products before uploading, take a look at our module. It solves all these problems comprehensively, within one plugin, without having to tape together different solutions and hope they don't fall apart the next time you update WordPress.

Setting up the Yandex Feed module in COS WP Woo takes from fifteen minutes to an hour, depending on how detailed you want to configure the mapping of categories and parameters. Basic settings - store name, selection of categories, update schedule - fifteen minutes. Full setup with mapping of all categories to the Yandex tree, configuration of parameters, delivery rules and filtering - an hour. After this, the feed lives its own life: it is updated, validated, and shows the status on the dashboard. You're running a business, not messing around with XML files.

I often hear the objection: “Why do I need the Yandex.Market module in a plugin for WooCommerce, if I can just install a separate plugin for exactly this task?” Fair question. A separate plugin is fine if you only need feed generation and nothing else. But in reality, uploading to the Market is not an isolated task. It is related to pricing, availability in warehouses, product data, and SEO quality of descriptions. And when all these things live in different plugins that know nothing about each other, you spend time gluing together, manual synchronization, and sorting out conflicts. A single platform removes this headache. The feed module “sees” 1C data directly, knows about B2B prices and groups, and uses the SEO module validation. All this works without additional configuration, without third-party integrations, without the risk that the next WordPress update will break the fragile structure of five plugins from different authors.

Try COS WP Woo - this is the only WooCommerce plugin that covers uploading to Yandex.Market along with 1C integration, custom fields, B2B prices and SEO checks in one solution. Install, set up your feed in half an hour and forget about manual work with price lists.