Настройка фида для Google Shopping 1С-Битрикс
Владельцы каталогов на Битрикс часто сталкиваются с проблемой: товары не проходят модерацию в Google Merchant Center, фид отклонён, продажи не растут. Стандартный модуль «Экспорт каталога» не генерирует корректный XML для Google Shopping — не хватает пространства имён xmlns:g и маппинга обязательных атрибутов. Неправильный фид не только теряет продажи, но и может привести к штрафам от Google за некорректные данные. Мы настраиваем фид под ключ: от аудита инфоблоков до полной автоматизации обновлений. За 10+ лет работы мы настроили более 200 фидов для каталогов от 100 до 500 000 товаров — и гарантируем прохождение модерации.
Почему стандартный экспорт не подходит для Google Shopping?
Битрикс по умолчанию умеет выгружать YML (Яндекс.Маркет) и произвольный XML. Но формат Google Base требует специфических тегов: g:id, g:title, g:price, g:availability, g:brand, g:gtin. Стандартный профиль не добавляет префикс g и не поддерживает вложенность атрибутов. Результат — фид с ошибками схемы.
| Характеристика |
Стандартный экспорт (YML) |
Кастомный скрипт |
| Поддержка xmlns:g |
Нет |
Да |
| Маппинг пользовательских свойств |
Ограничен |
Гибкий, любые свойства |
| Торговые предложения |
Выгружаются как отдельные товары без группировки |
Поддержка g:item_group_id |
| Частота обновления |
Ручной запуск |
Агент или cron с любым интервалом |
| Возможность кастомизации |
Настройками профиля |
Полный контроль через PHP |
Пошаговая инструкция: от аудита до деплоя
- Аудит структуры инфоблоков и торговых предложений — проверяем наличие обязательных свойств (GTIN, бренд, размеры), оцениваем объём каталога и частоту изменений.
- Определение маппинга свойств — составляем карту соответствия между полями Битрикс и тегами Google Base. Учитываем специфику типа товара: для одежды — цвет и размер, для электроники — GTIN и MPN.
- Написание кастомного PHP-скрипта — реализуем генерацию XML с корректными пространствами имён, поддержкой
g:item_group_id и fallback для отсутствующих свойств.
- Настройка агента или cron — обеспечиваем автоматическую перегенерацию фида с нужной периодичностью. Для каталогов более 50 000 товаров используем постраничную выборку и
set_time_limit(0).
- Тестирование и отправка в Merchant Center — прогоняем фид через валидатор W3C, проверяем в разделе Diagnostics, исправляем типичные ошибки.
- Мониторинг и корректировка — после запуска отслеживаем статус в Merchant Center и оперативно правим замечания.
Что даёт кастомный скрипт?
Мы используем кастомный PHP-скрипт, размещаемый в /local/cron/google_feed.php. Он собирает все активные товары, включая торговые предложения, маппит свойства в нужные теги и записывает XML в /upload/feeds/google.xml. Скрипт запускается агентом Битрикс каждый час — так фид всегда актуален.
Пример маппинга свойств:
$PROPERTY_MAP = [
'brand' => 'BRAND', // Свойство "Бренд"
'barcode' => 'BARCODE', // EAN/штрихкод
'article' => 'ARTICLE', // Артикул/MPN
'color' => 'COLOR', // Цвет (для одежды)
'size' => 'SIZE', // Размер (для одежды)
'material'=> 'MATERIAL', // Материал
];
Перед генерацией фида мы обязательно проверяем, существуют ли эти свойства в инфоблоке через CIBlockProperty::GetList(). Если свойство отсутствует или не заполнено у товара — добавляем fallback или пропускаем элемент.
Что делать с торговыми предложениями?
Для каталогов с вариантами (размер, цвет) каждое предложение должно быть отдельным <item> с атрибутом g:item_group_id, равным ID родительского товара. Родительский товар в фид не попадает. Вот как это реализовано:
$offers = \CIBlockElement::GetList(
[],
['IBLOCK_ID' => $OFFERS_IBLOCK_ID, 'PROPERTY_CML2_LINK' => $elementId, 'ACTIVE' => 'Y'],
false, false,
['ID', 'NAME', 'CATALOG_QUANTITY', 'CATALOG_PRICE_1']
);
while ($offer = $offers->GetNextElement()) {
$offerFields = $offer->GetFields();
$offerProps = $offer->GetProperties();
// g:item_group_id = ID родительского элемента
// g:id = ID торгового предложения
// g:color, g:size — из свойств предложения
}
Как автоматизировать обновление фида?
Лучше ставить агент Битрикс — он не требует доступа к cron и проще в настройке:
\CAgent::AddAgent(
'\Local\Feed\GoogleFeedGenerator::generate();',
'local.feed',
'N',
3600, // каждый час
'',
'Y',
date('d.m.Y H:i:s', time() + 3600)
);
Файл фида перезаписывается при каждом запуске. Если товаров больше 50 000, увеличьте время выполнения скрипта через set_time_limit(0) и используйте постраничную выборку. В качестве альтернативы можно настроить cron-задачу: * * * * * /usr/bin/php /path/to/bitrix/local/cron/google_feed.php >/dev/null 2>&1.
Проверка фида перед отправкой в Merchant Center
Мы проверяем фид тремя способами:
-
Встроенные инструменты Google — раздел Diagnostics в Merchant Center сразу покажет ошибки валидации. Согласно официальной документации, более 40% отклонений связаны с отсутствием GTIN.
-
Валидатор W3C — проверяет корректность XML-структуры.
-
Google Rich Results Test — убедитесь, что структурированные данные на сайте соответствуют ожиданиям Google.
Обязательные атрибуты фида
| Атрибут |
Обязательность |
Тип |
| g:id |
Да |
Уникальный идентификатор товара |
| g:title |
Да |
Название товара |
| g:description |
Да |
Описание (не менее 30 символов) |
| g:link |
Да |
URL страницы товара |
| g:image_link |
Да |
URL изображения |
| g:price |
Да |
Цена с валютой |
| g:availability |
Да |
in stock / out of stock |
| g:brand |
Да |
Бренд |
| g:gtin или g:mpn |
Да |
Идентификатор производителя |
Что входит в настройку фида под ключ
- Аудит текущего каталога: проверяем наличие свойств (GTIN, бренд, размеры), правильность ведения торговых предложений.
- Маппинг и написание кастомного скрипта генерации фида с поддержкой
xmlns:g.
- Настройка агента или cron-задачи для автоматического обновления.
- Первичная проверка фида в Merchant Center, устранение типичных ошибок.
- Гарантия прохождения модерации — исправляем замечания Google в течение дня. Экономия рекламного бюджета за счёт корректных данных достигает 30%, а снижение доли отклонений на 25% сокращает потери от неучастия в бесплатных листингах.
Наш опыт — более 10 лет работы с Битрикс и 200+ настроенных фидов для каталогов от 100 до 500 000 товаров. Получите консультацию: оценим ваш проект и предложим решение без скрытых доплат. Свяжитесь с нами для бесплатного аудита текущего фида. Закажите настройку фида под ключ — гарантируем прохождение модерации.
Разработка парсеров для 1С-Битрикс: с чего начать?
XMLReader, а не SimpleXML — выбор инструмента определяет судьбу проекта. SimpleXML загружает весь XML в память, и при файле поставщика на 800 МБ PHP упадёт с fatal error на лимите 512 МБ. XMLReader обрабатывает потоково, node за node, потребляя 20–30 МБ — в 30 раз эффективнее. С этой детали стартует любая разработка парсеров под Битрикс. Мы делаем такие системы уже 10+ лет, и ни один проект не обходится без правильного выбора парсера.
Какие проблемы решает парсинг?
- Первичное наполнение каталога — 15 000 карточек с описаниями, характеристиками, фото. Вручную это три месяца контент-менеджера; парсер — неделя с отладкой.
- Мониторинг цен конкурентов — сбор данных с Ozon, Wildberries, сайтов конкурентов. Конкурент снизил цену на ходовую позицию — узнаёте через два часа, а не через две недели.
- Агрегация поставщиков — пять прайсов в разных форматах (CSV с CP1251, XML в CommerceML, Excel с объединёнными ячейками) превращаются в единый каталог с общей системой свойств инфоблока.
- Обогащение карточек — подтягиваем характеристики, инструкции, 3D-модели с сайтов производителей. Без этого карточка товара — пустышка для SEO.
- Обновление ассортимента — товары, пропавшие из фида поставщика, деактивируются через
CIBlockElement::Update($ID, ['ACTIVE' => 'N']). Новые — создаются. Каталог синхронизирован.
Какие инструменты используем в разработке парсеров?
Статические сайты — PHP (Goutte, Symfony DomCrawler) или Python (Scrapy, lxml). Скорость: 50–100 страниц/сек. Хватает для каталогов без JS-рендеринга.
SPA и динамические сайты — Puppeteer или Playwright. Бесконечный скролл, AJAX-фильтры, lazy-load картинок — headless-браузер всё это обработает. Скорость падает до 1–10 страниц/сек, но альтернативы нет: данные существуют только после выполнения JavaScript.
Файлы поставщиков:
- Excel (XLS, XLSX) — PhpSpreadsheet. Осторожно с объединёнными ячейками и формулами — они ломают автоматический маппинг.
- CSV —
fgetcsv() с правильной кодировкой. Поставщики любят CP1251, BOM в UTF-8 и точку с запятой вместо запятой. Всё это нужно детектить и обрабатывать.
- XML/YML — XMLReader для больших файлов, SimpleXML для фидов до 50 МБ.
- CommerceML — стандартный формат обмена с 1С. Разбираем
import.xml и offers.xml, маппим на структуру инфоблоков.
API — REST-эндпоинты поставщиков, API маркетплейсов (Ozon Seller API, Wildberries API). Работаем в рамках rate limits, обрабатываем пагинацию.
Как устроен пайплайн автонаполнения?
Четыре этапа. Каждый может сломаться по-своему.
-
Сбор. Парсер обходит источники по cron-расписанию. Сырые данные пишем в промежуточную таблицу — не сразу в b_iblock_element. Логируем всё: сколько страниц обошли, сколько элементов распарсили, где получили 403 или timeout. Без логов отладка парсера — гадание на кофейной гуще.
-
Нормализация. Здесь основная работа:
- Очистка HTML-тегов, лишних пробелов, Unicode-мусора
- Единицы измерения: «мм» → «мм», «millimeters» → «мм», «миллиметр» → «мм»
- Маппинг категорий поставщика → разделы инфоблока Битрикс. У одного поставщика «Ноутбуки», у другого «Ноутбуки и планшеты», у третьего «Laptops» — всё в одну секцию
- Дедупликация по артикулу, EAN/GTIN. Один товар от трёх поставщиков не должен появиться трижды
-
Загрузка в Битрикс. Через CIBlockElement::Add() для новых элементов, CIBlockElement::Update() для существующих. Изображения: скачиваем, ресайзим через CFile::ResizeImageGet(), конвертируем в WebP. Свойства — через CIBlockElement::SetPropertyValuesEx(). SEO-мета через \Bitrix\Iblock\InheritedProperty\ElementValues. ЧПУ генерируем из транслитерации названия.
-
Обновление. Ключевой момент — не затереть ручные правки контент-менеджера. Обновляем только цену, остатки, активность. Описание и фото, доработанные вручную, помечаем флагом UF_MANUAL_EDIT в свойствах элемента и пропускаем при импорте. Товары, пропавшие из фида — деактивируем, но не удаляем.
Почему мониторинг цен конкурентов необходим?
Отдельная подсистема со своей спецификой:
| Параметр |
Как устроено |
| Частота |
От раза в день до каждых 2 часов — зависит от волатильности рынка |
| Сопоставление |
По артикулу, EAN, нечёткое сравнение названий через расстояние Левенштейна |
| Хранение |
Своя таблица vendor_price_monitor с историей, не инфоблоки |
| Алерты |
Telegram/email при отклонении цены конкурента более чем на X% |
| Автоправила |
«Держать цену на 3% ниже минимальной среди конкурентов, но не ниже себестоимости + 15%» |
Результат — дашборд: ваш товар vs конкуренты, история цен, тренды. Менеджер видит, где можно поднять цену без потери позиции, а где нужно реагировать.
Модуль импорта CSV/XML: настройка под ваш формат
Для файлов от поставщиков — кастомный модуль с админкой:
- Настраиваемый маппинг: «колонка B в файле → свойство BRAND инфоблока»
- Автодетект кодировки (CP1251, UTF-8, UTF-16) через
mb_detect_encoding() с проверкой
- Загрузка изображений по URL с очередью — чтобы не забить канал
- Инкрементальное обновление по хешу строки: изменилась строка — обновляем, нет — пропускаем
- Cron-расписание, отчёт: создано 145, обновлено 892, ошибок 3 (с деталями)
Большие файлы: CSV обрабатываем батчами по 1000 строк через fgetcsv(), XML потоково через XMLReader, фоновое выполнение через очередь агентов Битрикс — никаких PHP-таймаутов.
Правовая сторона — что важно учесть
-
robots.txt — уважаем. Crawl-delay — соблюдаем.
- Частота запросов — 1–2 в секунду, не больше. Не нужно DDoS-ить чужой сайт.
- Контент производителей — используем. Уникальные авторские тексты — не копируем.
- Персональные данные — не собираем.
Что входит в разработку парсера под ключ?
| Составляющая |
Описание |
| Прототип |
Парсер 1–2 источников за 2–3 дня для оценки качества данных |
| Основной парсер |
Полный сбор данных с одного источника (статический/динамический) |
| Модуль импорта в Битрикс |
Нормализация, загрузка, обновление, админка маппинга |
| Мониторинг цен |
Если требуется – система сбора и алертов (до 10 конкурентов) |
| Документация |
Описание архитектуры, инструкция по обновлению селекторов |
| Поддержка |
Гарантия 3 месяца на бесперебойную работу, правка при изменении вёрстки донора |
Как мы работаем и сроки
-
Прототип — парсер для 1–2 источников за 2–3 дня. Оцениваем качество данных, подводные камни (защита Cloudflare, капча, динамическая подгрузка).
-
Разработка — полный пайплайн: парсер → нормализация → импорт в Битрикс → админка для управления.
-
Тестирование — прогоняем на полном объёме каталога, проверяем edge-кейсы (пустые поля, кривой HTML, битые картинки).
-
Запуск — настраиваем cron, мониторинг ошибок через Telegram-бот.
-
Поддержка — конкурент переделал вёрстку? Обновляем CSS-селекторы в парсере.
| Задача |
Сроки |
| Парсер одного сайта (статический HTML) |
3–5 дней |
| Парсер SPA-сайта (Puppeteer/Playwright, обход защиты) |
1–2 недели |
| Модуль импорта CSV/XML в Битрикс |
1–2 недели |
| Система мониторинга цен (5–10 конкурентов) |
2–4 недели |
| Комплексная система автонаполнения |
4–8 недель |
| Поддержка и адаптация парсеров |
по подписке |
Свяжитесь для оценки вашего проекта — мы предложим оптимальное решение под ваш бюджет. Гарантируем стабильную работу парсеров и полную поддержку в течение всего срока использования.