Выгрузка в Яндекс.Маркет: автоматический фид с категориями и фильтрами

Мне позвонил клиент — владелец оптовой компании по продаже промышленных масел и смазок. Каталог на WooCommerce — почти семнадцать тысяч позиций. «Олег, — говорит, — мы полгода пытаемся нормально выгрузиться в Яндекс.Маркет. Перепробовали три плагина, наняли фрилансера, он что-то накодил на коленке, но фид постоянно падает, модерация не принимает, у половины товаров нет категорий, а цены из 1С приходят с задержкой в сутки. Мы теряем деньги каждый день.» Я послушал и подумал — а ведь это не уникальная ситуация. Такое я слышу регулярно, от разных клиентов, из разных ниш. Яндекс.Маркет — крупнейший прайс-агрегатор в России, и выгрузка на него давно превратилась в одну из тех задач, которые кажутся простыми на бумаге, но превращаются в кошмар на практике.

Казалось бы — что сложного? Генерируешь XML-файл в формате YML, загружаешь URL в кабинет Маркета, и товары появляются в выдаче. На деле всё совсем иначе. YML-спецификация Яндекса — это десятки обязательных и рекомендуемых полей, каждое из которых имеет свои ограничения. Категории должны соответствовать дереву Маркета, а не вашей внутренней структуре WooCommerce. Вариации товаров нужно подавать в специальном формате с group_id. Цены должны быть актуальными, а не вчерашними. Изображения — доступными по прямому URL без редиректов. Доставка и самовывоз — с конкретными сроками и стоимостью по регионам. И если хоть что-то не так — модерация отклоняет фид или, что хуже, принимает его частично, и вы даже не знаете, какие из ваших семнадцати тысяч товаров реально показываются покупателям, а какие тихо отвалились.

Я занимаюсь разработкой плагина COS WP Woo для WooCommerce, и модуль выгрузки в Яндекс.Маркет стал одним из тех, которые мы начали делать по прямой просьбе клиентов. Не потому что нам хотелось ещё один плагин-генератор YML-фида — их на рынке и так достаточно. А потому что ни один из существующих не решал весь комплекс задач одновременно: гибкая фильтрация, маппинг категорий, поддержка вариаций, автоматическое обновление по расписанию, интеграция с 1С и, что самое важное, валидация фида до того, как вы загрузите его в Маркет и получите отказ модерации. Давайте разберём по порядку, как всё это работает и почему существующие решения чаще всего недотягивают.

Что такое YML-фид и почему с ним столько проблем

Формат YML — Yandex Market Language — это расширение XML, разработанное Яндексом специально для загрузки товарных предложений. Звучит технически, но по сути это просто файл, в котором описан ваш каталог: название магазина, валюта, дерево категорий и набор товарных предложений (offers). Каждый offer — это карточка товара с названием, ценой, описанием, URL, изображениями и кучей дополнительных параметров вроде производителя, страны происхождения, штрих-кода и характеристик.

Проблема в том, что между «вот у меня WooCommerce-магазин с товарами» и «вот валидный YML-фид для Маркета» лежит огромная пропасть. WooCommerce хранит данные в собственной структуре — product post type, мета-поля, таксономии, атрибуты, вариации как дочерние посты. Ни одно из этих понятий не маппится на YML один к одному. Название товара в WooCommerce может содержать HTML-теги или спецсимволы, которые невалидны в XML. Категории в WooCommerce — это произвольное дерево, которое не совпадает с деревом категорий Яндекс.Маркета. Цена может быть пустой (товар «под запрос»), со скидкой (sale price), с налогом или без — и YML ожидает одно конкретное число. Изображения хранятся как attachment ID, а в фид нужно вставить полный URL — причём URL должен быть рабочим, без битых ссылок, и желательно без query-параметров с размерами.

Я видел фиды, сгенерированные другими плагинами, где в одном файле были товары без категории, товары с ценой ноль, товары без единого изображения и товары с описанием длиной в пятнадцать тысяч символов — при том что Маркет обрезает описание после трёх тысяч. Формально это валидный XML, и даже Маркет его примет. Но половина товаров не пройдёт модерацию, и владелец магазина будет неделями разбираться, почему из семнадцати тысяч позиций в выдаче показываются только две тысячи. Именно поэтому генерация фида — это не просто «сконвертируй данные из одного формата в другой». Это фильтрация, очистка, валидация и обогащение данных перед тем, как они уйдут в Яндекс.

Когда мы проектировали модуль Yandex Feed в COS WP Woo, мы сразу решили, что подход будет другим. Не «выгрузи всё подряд и молись», а «выгрузи только то, что готово к Маркету, и покажи, что нужно доработать». Это принципиальная разница, и она влияет на всю архитектуру.

Давайте посмотрим на конкретные задачи, которые нужно решать при выгрузке, и как мы подошли к каждой из них.

Генерация YML-файла начинается с настроек магазина — название, URL, валюта, компания. Это верхнеуровневые параметры, которые редко меняются, но которые обязательно должны быть в фиде. Дальше идёт блок категорий. Вот тут начинается первая серьёзная проблема — маппинг категорий WooCommerce на дерево Яндекс.Маркета. Маркет имеет свою собственную таксономию из нескольких тысяч категорий, и ваши внутренние категории вроде «Масла промышленные → Гидравлические → HLP» не совпадают с тем, что ожидает Яндекс. У Маркета это может быть «Масла и смазки → Гидравлические масла», и ID категории будет совершенно другой.

Честно говоря, многие плагины просто выгружают ваше дерево категорий WooCommerce as is. И это работает — Яндекс примет ваши категории. Но товары будут распределены неоптимально, поиск по ним будет хуже, и вы потеряете в конверсии. Наш подход — дать возможность замаппить каждую WooCommerce-категорию на соответствующую категорию Яндекса. В настройках модуля есть раздел маппинга, где вы видите два дерева рядом — ваше и Яндекса — и просто соединяете их. Категории, которые вы не замаппили, выгружаются с вашим оригинальным названием, и модуль помечает их предупреждением: «Не замаплена на категорию Яндекса — товары могут быть классифицированы неточно.» Это не ошибка, фид будет работать, но вы хотя бы знаете, что можно улучшить.

Дальше — самое мясо — товарные предложения. Каждый товар WooCommerce превращается в один или несколько offer-элементов в YML. Простой товар — один offer. Вариативный товар — отдельный offer на каждую вариацию, объединённые через group_id. Вот тут начинается вторая большая проблема, с которой я регулярно сталкиваюсь у клиентов.

WooCommerce хранит вариации как дочерние посты (post_type = product_variation), и у них своя логика наследования. Вариация может иметь собственную цену, а может наследовать родительскую. Может иметь собственное описание, а может не иметь — тогда берётся описание родителя. Изображения — если у вариации есть своя галерея, берём её, если нет — берём галерею родителя. SKU — аналогично. Вес, размеры — аналогично. Каждое поле нужно проверить по цепочке наследования, и это не тривиальная задача.

Многие генераторы фидов просто берут данные вариации напрямую и не проверяют fallback на родителя. В результате в фиде появляются offers без описания, без изображений или без цены — потому что у конкретной вариации эти данные не заполнены, они наследуются от родителя, но плагин об этом не знает. Мы обрабатываем всю цепочку наследования корректно, и каждый offer в фиде гарантированно имеет все обязательные поля.

Есть ещё один нюанс с вариациями, который мало кто учитывает. Яндекс.Маркет ожидает, что вариации одного товара будут отличаться конкретными параметрами — цветом, размером, объёмом. И эти параметры должны быть указаны как param-элементы в offer. Просто сгенерировать разные URL для каждой вариации недостаточно — нужно явно показать, чем они отличаются. Наш модуль автоматически определяет атрибуты, по которым различаются вариации, и добавляет их как параметры в фид. Если у вас товар «Масло гидравлическое HLP 46» с вариациями по объёму — 5 литров, 20 литров, 200 литров — то в фиде будут три offer-а с group_id и параметром «Объём» со значениями 5, 20 и 200 соответственно. Маркет поймёт, что это один товар в разных фасовках, и покажет их корректно.

Фильтрация: почему не стоит выгружать весь каталог

Теперь поговорим о фильтрации — и это, пожалуй, тот аспект, который отличает серьёзный модуль выгрузки от любительского скрипта. Первый порыв любого владельца магазина — выгрузить вообще всё. Семнадцать тысяч товаров? Давайте все семнадцать тысяч в Маркет! Чем больше, тем лучше, правда?

Нет. Не правда. И я объясню почему. Яндекс.Маркет — это не витрина, это агрегатор с конкуренцией. За каждый клик на ваш товар вы платите. Если в фиде есть товар, которого нет в наличии — покупатель кликнет, перейдёт к вам на сайт, увидит «нет в наличии» и уйдёт. Вы заплатили за клик, но не получили продажу. Если в фиде есть товар с ценой 150 рублей за канистру масла — это явно ошибка, но покупатель кликнет, а потом оставит негативный отзыв. Если в фиде есть товар без описания и без изображения — он просто не будет конвертировать, но место в фиде займёт и может повлиять на общий рейтинг качества вашего магазина в глазах Яндекса.

Поэтому фильтрация — это не nice-to-have, а must-have. В нашем модуле вы можете настроить фильтры по нескольким параметрам, и я расскажу о каждом из них подробно.

Фильтрация по категориям — самая очевидная. Вы выбираете, какие категории WooCommerce включить в фид, а какие исключить. Типичный сценарий: у вас есть категория «Услуги» или «Бывшие в употреблении» — их в Маркет выгружать нельзя или нецелесообразно. Или у вас есть категория «Новинки», которая дублирует товары из других категорий — и вы не хотите дублей в фиде. Можно включить конкретные категории (whitelist) или исключить конкретные (blacklist) — как удобнее при вашем объёме каталога.

Фильтрация по тегам работает аналогично. У нас на практике клиенты часто используют WooCommerce-теги для внутренней маркировки: «не для Маркета», «сезонный», «ликвидация», «премиум». Добавляете тег в исключения — и все товары с этим тегом не попадают в фид. Это удобнее, чем перемещать товары между категориями, особенно когда один и тот же товар нужно временно убрать из Маркета, не трогая его позицию в каталоге сайта.

Фильтрация по статусу наличия — пожалуй, самая важная. Здесь три варианта. Можно выгружать только товары в наличии — это самый безопасный режим, вы платите только за клики на товары, которые реально можете продать. Можно выгружать товары в наличии и «под заказ» (backorder) — если вы умеете быстро поставлять товар под заказ и хотите охватить больше запросов. И можно выгружать всё, включая отсутствующие — но тогда в фиде будет атрибут available="false", и Маркет покажет их как «нет в наличии», что может быть полезно для удержания позиции в выдаче по конкурентным запросам.

Фильтрация по ценовому диапазону — это то, что спасает от выгрузки ошибочных данных. Вы задаёте минимальную и максимальную цену. Товар с ценой 0 рублей или 1 рубль — очевидная ошибка данных, и он не попадёт в фид. Товар с ценой 10 миллионов рублей — тоже, скорее всего, ошибка. Я видел каталог, где из-за сбоя импорта из 1С цены нескольких товаров были выставлены в копейках вместо рублей — масло по 1 рубль 50 копеек за канистру. Без фильтра по цене эти товары ушли бы в Маркет, и последствия были бы неприятными.

Есть ещё фильтрация по наличию обязательных данных — это не отдельная настройка, а часть логики валидации. Товар без названия, без цены или без хотя бы одного изображения автоматически исключается из фида и попадает в список «проблемных товаров» на дашборде модуля. Об этом мы поговорим чуть позже, когда дойдём до валидации.

Все эти фильтры комбинируются. Вы можете сказать: «Бери категории А, Б и В, исключай товары с тегом "не для маркета", только товары в наличии, с ценой от 100 до 500 000 рублей.» И из ваших семнадцати тысяч позиций в фид попадут, допустим, двенадцать тысяч — именно те, которые готовы к размещению на Маркете и будут реально конвертировать.

Доставка, расписание и интеграция с 1С

Отдельная большая тема — настройки доставки и самовывоза в фиде. Яндекс.Маркет позволяет указать условия доставки прямо в YML, и это сильно влияет на позиционирование ваших товаров в выдаче. Покупатели фильтруют по способу доставки, по срокам, по стоимости — и если у вас эти данные не заполнены, вы просто выпадаете из значительной части поисковых запросов.

В нашем модуле настройки доставки работают на двух уровнях. Глобальный уровень — это дефолтные условия для всего магазина. Вы указываете стоимость доставки, срок в днях, регион — и эти параметры применяются ко всем товарам, если не переопределены. Это элемент delivery-options в секции shop. Второй уровень — индивидуальные условия для конкретных товаров или категорий. Тяжёлый товар — бочка масла 200 литров — имеет другую стоимость доставки, чем канистра 5 литров. Вы можете задать правила по категориям или по весовым диапазонам, и модуль автоматически подставит правильные условия для каждого offer-а.

То же самое с самовывозом — pickup. Если у вас несколько точек самовывоза, вы указываете их все, и каждая точка может иметь свой график работы. Фид будет содержать элементы outlet с корректными данными по каждой точке. Это особенно важно для региональных компаний с несколькими складами — покупатель видит, что может забрать товар в своём городе, и конверсия растёт.

Я знаю, что многие думают: «Ну, доставку я потом настрою в кабинете Маркета.» Да, можно. Но если условия доставки указаны прямо в фиде, они обновляются автоматически вместе с остальными данными. Не нужно ходить в кабинет и менять тарифы вручную. Подняли стоимость доставки — поменяли в настройках модуля — следующая генерация фида уже содержит новые цены. Для компании с динамичными тарифами это экономит часы ручной работы каждый месяц.

Теперь про расписание обновлений — и это та штука, которая отличает «поставил и забыл» от «постоянно слежу и перегенерирую руками». Яндекс.Маркет рекомендует обновлять фид не реже раза в день, а если у вас часто меняются цены или наличие — то каждые несколько часов. Если фид устарел, Маркет может показывать неактуальные цены или товары, которых нет в наличии. Это ведёт к негативным отзывам и снижению рейтинга магазина.

Наш модуль использует Action Scheduler — тот же механизм фоновых задач, который WooCommerce использует для собственных нужд. Вы задаёте расписание: каждый час, каждые два часа, каждые шесть часов, раз в сутки — и модуль автоматически перегенерирует фид в фоне. Не блокируя сайт, не замедляя его для посетителей. Для каталога в семнадцать тысяч позиций генерация занимает от тридцати секунд до пары минут — зависит от сервера и количества вариаций. Action Scheduler обрабатывает это асинхронно, и даже если генерация затянется, сайт продолжает работать как обычно.

И вот тут мы подходим к интеграции с 1С — и это, на мой взгляд, ключевое преимущество единого плагина перед набором отдельных решений. Если вы используете наш модуль интеграции с 1С (который работает через OData API, а не через устаревший CommerceML), то цены и остатки из 1С автоматически попадают в WooCommerce — а оттуда уже в YML-фид. Цепочка выглядит так: менеджер меняет цену в 1С → OData-коннектор ловит изменение через webhook или по расписанию → обновляет цену товара в WooCommerce → следующая генерация фида включает актуальную цену. Всё это происходит без участия человека.

Почему это важно? Потому что альтернатива — это два отдельных плагина (один для 1С, другой для Маркета), которые ничего не знают друг о друге. Плагин 1С обновил цены в два часа ночи, а плагин Маркета перегенерировал фид в шесть утра — но между этими событиями прошло четыре часа, и если кто-то купил товар в это время по старой цене в Маркете, у вас проблема. С единым плагином вы можете настроить генерацию фида сразу после завершения синхронизации с 1С — один экшен запускает другой через Action Scheduler. Цепочка замыкается, и фид всегда содержит самые свежие данные.

Я помню случай с клиентом, который торгует автомаслами. У него было два отдельных плагина — один для интеграции с 1С, другой для генерации фида. Они конфликтовали на уровне крон-задач, потому что оба использовали wp_cron, и WordPress пытался запустить обе задачи одновременно. В результате фид генерировался на половину обновлённых данных — часть товаров уже с новыми ценами из 1С, а часть ещё со старыми. Маркет показывал разные цены на один и тот же товар в разных предложениях. Клиент получал жалобы от покупателей и не мог понять, в чём дело, пока мы не разобрали цепочку. С единым модулем таких конфликтов просто не бывает — все задачи координируются через один Action Scheduler.

Отдельно хочу сказать про остатки. Для Маркета критически важно, чтобы товар, помеченный как «в наличии», реально был в наличии. Если покупатель заказывает товар, а вы не можете его отгрузить — Маркет снижает рейтинг магазина вплоть до блокировки. Когда остатки синхронизируются из 1С, модуль фида автоматически учитывает их при генерации. Товар с нулевым остатком можно либо вообще исключить из фида (если настроена фильтрация по наличию), либо пометить как unavailable. А если у вас несколько складов в 1С — Базовый, Маркетинговый, Катана — модуль суммирует остатки по всем складам, которые вы указали в настройках синхронизации, и использует итоговую цифру. Не просто «есть/нет», а реальное количество, которое Маркет тоже может использовать для ранжирования.

Цены — ещё один момент, который часто ломается при использовании разных плагинов. В 1С может быть несколько типов цен: «Розничная», «Оптовая», «Розничная САЙТ», «Закупочная». Для Маркета нужна конкретная — та, по которой вы продаёте розничным покупателям через сайт. Наш модуль 1С позволяет указать, какой тип цены маппить на WooCommerce regular price, и эта же цена уходит в фид. Если у вас есть скидочная цена (sale price) — она тоже попадает в фид, и Маркет покажет перечёркнутую старую цену рядом с актуальной. Это визуально привлекает покупателей и повышает CTR ваших предложений.

Валидация: ловим проблемы до Яндекса

Теперь о том, что я считаю одной из самых недооценённых функций — валидация фида перед отправкой. Большинство плагинов генерируют фид и всё. Дальше вы загружаете его в Маркет и ждёте результатов модерации. Если что-то не так — получаете ошибки через несколько часов или дней, исправляете, перегенерируете, загружаете снова, ждёте опять. Один цикл «исправил — проверил» может занять неделю, если у вас большой каталог и модерация Маркета загружена.

Мы встроили валидацию прямо в модуль. После каждой генерации фида модуль проходит по всем offer-ам и проверяет их на соответствие требованиям Яндекс.Маркета. Не просто «валидный ли XML», а содержательную проверку каждого товарного предложения. Что проверяется — название не пустое и не слишком длинное, цена положительная и в разумном диапазоне, есть хотя бы одно изображение и URL изображения доступен, описание не превышает лимит символов, категория указана, URL товара валиден и ведёт на существующую страницу. Для вариаций — проверяется наличие group_id и различающих параметров. Для товаров с доставкой — что указаны сроки и стоимость.

Результаты валидации отображаются на дашборде модуля Yandex Feed прямо в админке WooCommerce. Вы видите три группы: успешно прошедшие валидацию (зелёные), с предупреждениями (жёлтые) и с ошибками (красные). Для каждого проблемного товара показывается конкретная причина — «Нет изображения», «Цена равна нулю», «Описание превышает 3000 символов», «Нет ни одного атрибута, который Маркет может использовать как параметр». Вы можете кликнуть на товар, перейти в его карточку в WooCommerce и исправить проблему прямо сейчас, а не после того, как Маркет отклонит ваш фид.

Знаете, что самое частое предупреждение? «Нет alt-текста у изображения.» Яндекс.Маркет не требует alt-текст для изображений в фиде, но рекомендует. И если у вас из семнадцати тысяч товаров у двенадцати тысяч нет alt-текста — это повод задуматься не только о фиде, но и о SEO сайта в целом. Кстати, в COS WP Woo есть модуль пакетной генерации alt-текстов с помощью AI — можно закрыть эту проблему за один запуск.

Другой частый случай — дубликаты. Один и тот же товар может попасть в фид дважды, если он находится в двух категориях, и обе включены в фильтр. Наш модуль отслеживает уникальность по product ID и гарантирует, что каждый товар (или вариация) представлен в фиде ровно один раз. Дубли — это прямой путь к проблемам с модерацией и снижению качества фида в глазах Яндекса.

Ещё одна штука, которую я нигде больше не видел — предварительный просмотр фида. Перед тем как скопировать URL фида и вставить его в кабинет Маркета, вы можете посмотреть первые N товарных предложений прямо в браузере, в читаемом формате. Не сырой XML, а структурированная таблица: название, цена, категория, количество изображений, наличие, параметры. Это позволяет быстро убедиться, что фид выглядит так, как вы ожидаете, без необходимости парсить XML-файл в голове или в стороннем валидаторе.

Отдельно стоит сказать про размер фида. Для каталога в семнадцать тысяч позиций с вариациями YML-файл может весить несколько десятков мегабайт. Яндекс.Маркет принимает файлы до пятисот мегабайт, так что обычно это не проблема, но время скачивания имеет значение. Маркет периодически забирает фид по указанному URL — и если ваш сервер отдаёт файл медленно или с таймаутом, обновление данных задержится. Наш модуль генерирует статический файл и отдаёт его напрямую через Nginx/Apache, без проходки через PHP — это максимально быстро и не нагружает сервер.

Я понимаю, что всё это может звучать как куча технических деталей, которые нужны только разработчикам. Но на самом деле именно эти детали определяют, будет ли ваша выгрузка в Маркет работать стабильно месяцами без вашего вмешательства или потребует постоянного ручного контроля. Мы стремились к первому варианту — настроил один раз, и оно работает. Фид обновляется, цены актуальны, новые товары подтягиваются, снятые с продажи исчезают, валидация ловит проблемы до того, как они дойдут до Маркета.

Параметры товаров и структура offer

Отдельная тема, которая заслуживает внимания — работа с параметрами товаров в фиде. Яндекс.Маркет активно использует параметры (param-элементы) для фасетной фильтрации и сравнения товаров. Если у вашего масла указана вязкость, температура вспышки, тип основы (минеральное, синтетическое, полусинтетическое) — покупатель может отфильтровать товары по этим параметрам прямо в выдаче Маркета. Это существенно влияет на конверсию, потому что покупатель видит именно то, что ему нужно, а не весь ваш каталог из семнадцати тысяч позиций.

В WooCommerce параметры товаров хранятся как атрибуты (taxonomies типа pa_viscosity, pa_base-type) или как мета-поля (если используете кастомные поля). Наш модуль автоматически маппит атрибуты WooCommerce на param-элементы YML. Вы можете настроить, какие атрибуты включать в фид, а какие нет. Например, внутренний атрибут «Код 1С» покупателю не нужен — его можно исключить. А «Вязкость», «Объём», «Производитель» — включить.

Для каждого атрибута можно указать название, которое будет отображаться в Маркете. Если в WooCommerce атрибут называется pa_viscosity-class, а для покупателя это «Класс вязкости по SAE» — вы задаёте человекочитаемое название в маппинге, и в фиде оно появится именно в таком виде. Маркет покажет «Класс вязкости по SAE: 5W-30» — понятно и для покупателя, и для поисковых фильтров.

Если вы используете наш модуль кастомных полей (замена ACF), то данные из кастомных полей тоже можно включить в фид как параметры. Допустим, у вас есть кастомное поле «Сертификат ГОСТ» с номером ГОСТа — оно может стать параметром в YML. Или «Температурный диапазон применения» — от минус сорока до плюс ста двадцати. Всё это обогащает карточку товара на Маркете и повышает доверие покупателя.

Я заметил интересную закономерность на практике: товары с пятью и более параметрами в фиде получают значительно больше кликов, чем товары с одним-двумя параметрами. Маркет любит подробные карточки — они дают больше возможностей для фильтрации, и Яндекс ранжирует их выше. Поэтому если у вас есть данные — используйте их. Заполняйте атрибуты в WooCommerce (или в 1С, откуда они синхронизируются), и модуль автоматически выгрузит их в фид. Каждый заполненный параметр — это маленький плюс к видимости ваших товаров.

Теперь про структуру offer в целом. YML поддерживает несколько типов offer — стандартный (type=vendor.model), упрощённый и произвольный. Мы используем упрощённый тип по умолчанию, потому что он наиболее гибкий и подходит для большинства товаров. Но если у вас товары с чётким разделением на производителя (vendor) и модель — например, «Shell Helix Ultra 5W-40» где Shell — vendor, а Helix Ultra 5W-40 — model — вы можете переключиться на тип vendor.model. Маркет будет лучше структурировать информацию и сможет группировать товары одного производителя.

Производитель (vendor) берётся из атрибута WooCommerce или из кастомного поля — вы указываете, откуда именно, в настройках маппинга. Страна-производитель (country_of_origin) — аналогично. Штрих-код (barcode) — из мета-поля или атрибута. Наш модуль не заставляет вас хранить данные в каком-то конкретном поле — он адаптируется к вашей структуре данных, а не наоборот.

Есть ещё один момент, который часто упускают — URL товара в фиде. Казалось бы, просто берём permalink и вставляем. Но URL должен быть абсолютным, с протоколом https, без лишних query-параметров, и он должен вести на реально существующую страницу. Для вариаций URL должен включать параметры, выбирающие конкретную вариацию. Наш модуль генерирует корректные URL для каждого случая, включая обработку мультиязычных сайтов (если вы используете WPML или Polylang) и IDN-доменов (вроде масла.сайт, который в URL превращается в xn--80aa6ac0a.xn--80aswg).

Кстати, об изображениях. Маркет принимает до десяти изображений на каждый offer. Мы выгружаем основное изображение товара и все изображения из галереи, но не больше десяти. Если URL изображения ведёт на изображение с query-параметрами ресайза (как часто делают CDN-плагины), мы берём оригинальный URL без параметров — так надёжнее. И проверяем, что URL возвращает HTTP 200, а не 404 — битые ссылки на изображения это одна из самых частых причин отклонения товаров модерацией.

Давайте поговорим о том, что происходит, когда фид уже настроен и работает. Потому что настройка — это пятьдесят процентов дела. Вторые пятьдесят — это мониторинг и адаптация. Маркет постоянно меняет свои требования, добавляет новые обязательные поля, ужесточает проверки. Ваш каталог тоже живёт — появляются новые товары, удаляются старые, меняются цены и описания. Фид должен отражать все эти изменения автоматически, без ручного вмешательства.

На дашборде модуля Yandex Feed мы показываем ключевые метрики: сколько товаров в фиде, когда была последняя генерация, сколько времени она заняла, есть ли ошибки или предупреждения, какой объём файла. Если что-то пошло не так — например, генерация упала с ошибкой или количество товаров в фиде резко сократилось — вы увидите предупреждение. Резкое сокращение количества товаров обычно означает, что что-то сломалось в данных: массовое обнуление цен, удаление категории, проблема с синхронизацией 1С. Лучше узнать об этом из дашборда плагина, чем от покупателя, который не может найти ваш товар на Маркете.

Я долго думал, нужно ли добавлять уведомления по email — мол, «ваш фид сгенерирован, вот статистика». Решили пока не добавлять, потому что это быстро превращается в спам, который все игнорируют. Вместо этого — визуальный индикатор на дашборде в админке WooCommerce. Если вы заходите в админку хотя бы раз в день (а кто не заходит?), вы увидите статус фида.

Хочу рассказать ещё об одной ситуации, которая случается чаще, чем хотелось бы — конфликт данных между WooCommerce и Маркетом. Вы загрузили фид, Маркет принял его, товары появились в выдаче. А через неделю вы обновили описание товара в WooCommerce, сделали его длиннее и подробнее. Фид перегенерировался, Маркет обновил данные — и вдруг товар перестал проходить модерацию, потому что новое описание содержит запрещённые слова или превышает лимит символов. Товар пропадает из выдачи, а вы не понимаете, что случилось. Наша валидация ловит такие изменения при генерации и показывает предупреждение: «Товар X: описание увеличилось с 2800 до 3500 символов, превышает лимит Маркета.» Вы можете сократить описание до того, как проблема дойдёт до модерации.

А вот ещё забавная история из практики. У одного клиента — производитель автохимии — фид работал прекрасно три месяца. А потом разом «упало» восемьсот товаров. Начали разбираться — оказалось, что маркетолог массово обновил описания товаров через WP All Import, и в описания попали HTML-теги, которые ломали XML-структуру фида. Не весь фид, а конкретные offer-ы — те, где в описании был, например, незакрытый тег или символ амперсанда без экранирования. XML-парсер Маркета просто пропускал всё после первого битого offer-а, и товары тихо исчезали. Мы добавили санитизацию описаний — strip_tags, очистка спецсимволов, нормализация пробелов — в конвейер генерации фида, и с тех пор такие проблемы не возникают. Но без валидации этот баг мог бы жить месяцами незамеченным.

Знаете, за годы работы с выгрузкой в Маркет я пришёл к одному важному выводу: качество фида важнее количества товаров в нём. Лучше выгрузить три тысячи идеально подготовленных товаров — с заполненными параметрами, качественными изображениями, корректными ценами и описаниями — чем семнадцать тысяч, из которых половина с проблемами. Маркет учитывает качество магазина при ранжировании, и магазин с высоким процентом отклонённых товаров ранжируется ниже, чем магазин, где все товары проходят модерацию с первого раза. Фильтрация и валидация в нашем модуле нацелены именно на это — помочь вам выгрузить максимально качественный фид, а не максимально большой.

Что выбрать и как начать

Я часто слышу вопрос: а чем ваш модуль отличается от существующих плагинов для генерации YML? На рынке есть YML for Yandex Market, WP All Export с шаблоном YML, несколько платных решений с CodeCanyon. Честный ответ — функционально многие из них решают базовую задачу: генерируют XML-файл в формате YML из данных WooCommerce. Разница в деталях.

Первое — интеграция. Отдельный плагин для генерации фида не знает ничего о вашей интеграции с 1С, о ваших B2B-ценах, о кастомных полях, о системе модерации контента. COS WP Woo — это единая экосистема, где все модули работают вместе. Цены из 1С автоматически попадают в фид. Кастомные поля из CF-модуля автоматически становятся параметрами. SEO-проверки из модуля аудита дополняют валидацию фида. Это не маркетинговый бла-бла, а практическая разница: меньше конфликтов, меньше ручной работы, меньше шансов, что что-то сломается.

Второе — валидация. Я не видел ни одного плагина, который проверяет каждый товар на соответствие требованиям Маркета перед генерацией фида и показывает список проблем в удобном интерфейсе. Обычно вы узнаёте о проблемах из отчёта модерации Маркета, через несколько часов или дней. А потом начинается квест «найди проблемный товар среди семнадцати тысяч». Наш дашборд показывает проблемы сразу.

Третье — Action Scheduler вместо wp_cron. WordPress cron — это не настоящий крон, он запускается при посещении сайта. Если ваш сайт малопосещаемый (что бывает с B2B-магазинами в нерабочие часы), крон может не запуститься вовремя, и фид не обновится. Action Scheduler работает иначе — он гарантирует выполнение задач с заданным интервалом, даже если никто не заходит на сайт. Для критически важной задачи вроде обновления фида это существенно.

Четвёртое — поддержка вариаций с корректным наследованием данных. Это звучит как мелочь, но на практике некорректная обработка вариаций — самый частый источник проблем с фидом. Товар без цены, без описания, без изображения — всё это следствие того, что плагин не умеет ходить по цепочке наследования от вариации к родителю.

Если вы сейчас используете другой плагин для генерации YML и он работает — я не говорю, что нужно срочно всё менять. Но если вы сталкиваетесь с проблемами модерации, если фид обновляется нерегулярно, если цены из 1С приходят с задержкой, если вы тратите время на ручную проверку товаров перед выгрузкой — посмотрите на наш модуль. Он решает все эти проблемы комплексно, в рамках одного плагина, без необходимости склеивать разные решения скотчем и надеяться, что они не разъедутся при следующем обновлении WordPress.

Настройка модуля Yandex Feed в COS WP Woo занимает от пятнадцати минут до часа — в зависимости от того, насколько детально вы хотите настроить маппинг категорий и параметров. Базовая настройка — название магазина, выбор категорий, расписание обновлений — пятнадцать минут. Полная настройка с маппингом всех категорий на дерево Яндекса, конфигурацией параметров, правилами доставки и фильтрацией — час. После этого фид живёт своей жизнью: обновляется, валидируется, показывает статус на дашборде. Вы занимаетесь бизнесом, а не возитесь с XML-файлами.

Я часто слышу возражение: «А зачем мне модуль Яндекс.Маркета в плагине для WooCommerce, если я могу просто поставить отдельный плагин именно для этой задачи?» Справедливый вопрос. Отдельный плагин — это нормально, если вам нужна только генерация фида и ничего больше. Но в реальности выгрузка в Маркет — это не изолированная задача. Она связана с ценообразованием, с наличием на складах, с данными о товарах, с SEO-качеством описаний. И когда все эти вещи живут в разных плагинах, которые друг о друге ничего не знают, вы тратите время на склеивание, на ручную синхронизацию, на разбор конфликтов. Единая платформа снимает эту головную боль. Модуль фида «видит» данные 1С напрямую, знает о B2B-ценах и группах, использует валидацию SEO-модуля. Всё это работает без дополнительной настройки, без сторонних интеграций, без риска, что очередное обновление WordPress сломает хрупкую конструкцию из пяти плагинов разных авторов.

Попробуйте COS WP Woo — это единственный WooCommerce-плагин, который закрывает выгрузку в Яндекс.Маркет вместе с интеграцией 1С, кастомными полями, B2B-ценами и SEO-проверками в одном решении. Установите, настройте фид за полчаса и забудьте про ручную работу с прайс-листами.