Налаштування фіду Google Shopping на 1С-Бітрікс

Налаштування фіду для 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 і не підтримує вкладеність атрибутів. Результат — фід з помилками схеми.

Покрокова інструкція: від аудиту до деплою

1. Аудит структури інфоблоків та торгових пропозицій — перевіряємо наявність обов'язкових властивостей (GTIN, бренд, розміри), оцінюємо об'єм каталогу та частоту змін.
2. Визначення маппінгу властивостей — складаємо карту відповідності між полями Бітрікс та тегами Google Base. Враховуємо специфіку типу товару: для одягу — колір і розмір, для електроніки — GTIN і MPN.
3. Написання кастомного PHP-скрипта — реалізуємо генерацію XML з коректними просторами імен, підтримкою g:item_group_id та fallback для відсутніх властивостей.
4. Налаштування агента або cron — забезпечуємо автоматичну перегенерацію фіду з потрібною періодичністю. Для каталогів понад 50 000 товарів використовуємо посторінкову вибірку та set_time_limit(0).
5. Тестування та відправка в Merchant Center — проганяємо фід через валідатор W3C, перевіряємо в розділі Diagnostics, виправляємо типові помилки.
6. Моніторинг та коригування — після запуску відстежуємо статус у 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

Ми перевіряємо фід трьома способами:

1. Вбудовані інструменти Google — розділ Diagnostics у Merchant Center одразу покаже помилки валідації. Згідно з офіційною документацією, більше 40% відхилень пов'язані з відсутністю GTIN.
2. Валідатор W3C — перевіряє коректність XML-структури.
3. Google Rich Results Test — переконайтесь, що структуровані дані на сайті відповідають очікуванням Google.

Обов'язкові атрибути фіду

Що входить у налаштування фіду під ключ

• Аудит поточного каталогу: перевіряємо наявність властивостей (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 років, реалізували 50+ проектів, і жоден не обходиться без правильного вибору парсера.

Проблеми, які вирішує парсинг

• Первинне наповнення каталогу — 15 000 карток з описами, характеристиками, фото. Вручну це три місяці контент-менеджера; парсер — тиждень з налагодженням. Економія часу — до 90%.
• Моніторинг цін конкурентів — збір даних з Ozon, Wildberries, сайтів конкурентів. Конкурент знизив ціну на ходову позицію — дізнаєтеся через дві години, а не через два тижні. Окупається за 2–3 місяці.
• Агрегація постачальників — п’ять прайсів у різних форматах (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, обробляємо пагінацію.

Як влаштований пайплайн автонаповнення?

Чотири етапи. Кожен може зламатися по-своєму.

1. Збір. Парсер обходить джерела по cron-розкладу. Сирі дані пишемо в проміжну таблицю — не одразу в b_iblock_element. Логуємо все: скільки сторінок обійшли, скільки елементів розпарсили, де отримали 403 або timeout. Без логів налагодження парсера — ворожіння на кавовій гущі.

2. Нормалізація. Тут основна робота:

   • Очищення HTML-тегів, зайвих пробілів, Unicode-сміття
   • Одиниці виміру: «мм» → «мм», «millimeters» → «мм», «миллиметр» → «мм»
   • Мапінг категорій постачальника → розділи інфоблоку Бітрікс. В одного постачальника «Ноутбуки», в іншого «Ноутбуки та планшети», у третього «Laptops» — все в одну секцію
   • Дедуплікація за артикулом, EAN/GTIN. Один товар від трьох постачальників не повинен з’явитися тричі

3. Завантаження в Бітрікс. Через CIBlockElement::Add() для нових елементів, CIBlockElement::Update() для існуючих. Зображення: завантажуємо, ресайзимо через CFile::ResizeImageGet(), конвертуємо в WebP. Властивості — через CIBlockElement::SetPropertyValuesEx(). SEO-мета через \Bitrix\Iblock\InheritedProperty\ElementValues. ЧПУ генеруємо з транслітерації назви.

4. Оновлення. Ключовий момент — не затерти ручні правки контент-менеджера. Оновлюємо лише ціну, залишки, активність. Опис та фото, доопрацьовані вручну, позначаємо прапорцем UF_MANUAL_EDIT у властивостях елемента і пропускаємо при імпорті. Товари, що зникли з фіду — деактивуємо, але не видаляємо.

Моніторинг цін конкурентів: необхідність та реалізація

Окрема підсистема зі своєю специфікою:

Результат — дашборд: ваш товар vs конкуренти, історія цін, тренди. Менеджер бачить, де можна підняти ціну без втрати позиції, а де потрібно реагувати.

Модуль імпорту CSV/XML: налаштування під ваш формат

Для файлів від постачальників — кастомний модуль з адмінкою:

• Налаштовуваний мапінг: «колонка B у файлі → властивість BRAND інфоблоку»
• Автодетект кодування (CP1251, UTF-8, UTF-16) через mb_detect_encoding() з перевіркою
• Завантаження зображень за URL з чергою агентів Bitrix — щоб не забити канал
• Інкрементальне оновлення за хешем рядка: змінився рядок — оновлюємо, ні — пропускаємо
• Cron-розклад, звіт: створено 145, оновлено 892, помилок 3 (з деталями)

Великі файли: CSV обробляємо батчами по 1000 рядків через fgetcsv(), XML потоково через XMLReader, фонове виконання через чергу агентів Бітрікс — ніяких PHP-таймаутів.

Правова сторона — що важливо врахувати

• robots.txt — поважаємо. Crawl-delay — дотримуємося.
• Частота запитів — 1–2 в секунду, не більше. Не потрібно DDoS-ити чужий сайт.
• Контент виробників — використовуємо. Унікальні авторські тексти — не копіюємо.
• Персональні дані — не збираємо.

Що входить в розробку парсера під ключ?

Скільки часу займає розробка парсера?

Процес і терміни:

1. Прототип — парсер для 1–2 джерел за 2–3 дні. Оцінюємо якість даних, підводні камені (захист Cloudflare, капча, динамічне підвантаження).
2. Розробка — повний пайплайн: парсер → нормалізація → імпорт в Бітрікс → адмінка для управління.
3. Тестування — проганяємо на повному обсязі каталогу, перевіряємо edge-кейси (порожні поля, кривий HTML, биті картинки).
4. Запуск — налаштовуємо cron, моніторинг помилок через Telegram-бот.
5. Підтримка — конкурент переробив верстку? Оновлюємо CSS-селектори в парсері.

Отримайте консультацію: розкажіть про своє джерело даних — ми підберемо оптимальний підхід. Зв’яжіться для оцінки вашого проекту — запропонуємо рішення під ваш бюджет. Гарантуємо стабільну роботу парсерів і повну підтримку.