E-commerce
ГайдЯк наповнити інтернет-магазин товарами
Наповнення інтернет-магазину товарами: парсинг, XML/YML-фіди постачальників і руками. Ризики за законом і політиками Google, вимоги Rozetka й Hotline.

Магазин готовий, дизайн погоджено, оплата працює. А проєкт стоїть третій тиждень, бо в каталозі 12 товарів із 3000. У наших запусках це найчастіша причина зсуву дедлайну: наповнення інтернет-магазину товарами планують останнім, хоча воно зʼїдає більше годин, ніж вся розробка вітрини.
Шляхів заповнити каталог рівно три: спарсити чужий сайт, забрати дані з фіда постачальника чи маркетплейсу, завести все руками. Підрядники, які продають парсинг, докладно описують перший і мовчать про два інших. А головне — мовчать про те, чим за перший платять. Далі всі три без прикрас: норми права, вимоги конкретних платформ і цифри звідти, де їх можна перевірити.
Якщо магазину ще немає, спершу подивіться, як створити інтернет-магазин з нуля — там етапи запуску, і наповнення там лише один крок із девʼяти.
Шлях 1. Парсинг чужого каталогу: швидко, дешево і з двома рахунками потім

Механіка проста настільки, що спокушає. Розробник пише скрипт, той обходить каталог конкурента чи великого маркетплейсу, витягує назви, характеристики, ціни, описи й посилання на фото і складає це у CSV або одразу в базу. Тисяча товарів переїжджає за ніч.
Ціни на цю послугу відкриті. Horoshop продає парсинг товарів із зовнішніх сайтів від 6000 грн за перший сайт-донор — у базу входить до 10 000 товарів, далі +100 грн за кожну тисячу, додатковий донор +2000 грн. Каталог на 5000 позицій з одного донора вкладається в базові 6000 грн і кілька днів роботи. Порівняйте з будь-якою оцінкою ручної роботи на тому ж обсязі, і вибір виглядає очевидним.
Очевидним він бути перестає, коли розписати другий і третій рахунок.
Що каже закон про базу даних, з якої ви берете
Каталог товарів — це не просто набір рядків. Український закон розводить тут дві різні речі, і плутати їх дорого.
Перша — авторське право на контент усередині каталогу. До обʼєктів авторського права закон відносить письмові твори, зокрема статті у письмовій, електронній (цифровій) чи іншій формі, і окремим рядком фотографічні твори. Розгорнутий опис, який написав контент-менеджер конкурента, і студійне фото з його предметної зйомки — це саме воно.
Друга річ цікавіша, і про неї в блогах підрядників не пишуть. Це право на саму базу. Авторським правом база даних охороняється лише якщо добір і впорядкування її складових частин є результатом творчої діяльності. Сам факт, що хтось зібрав 5000 товарів у каталог, цього не дає. На цьому місці аргумент «каталог не охороняється» зазвичай і зупиняється.
Але у статті 21 є друга половина. Виробнику бази даних, який зробив якісно та/або кількісно значний внесок в отримання, перевірку чи подання вмісту бази даних, для запобігання вилученню та/або повторному використанню, надається право особливого роду, sui generis. Перечитайте формулювання: воно написане буквально під ситуацію «хтось вивантажив мій каталог». Діє це право 15 років, а будь-яка істотна зміна вмісту бази, зокрема через накопичення доповнень, дає їй новий власний строк охорони — так прямо написано у частині восьмій тієї ж статті 21.
Норма не українська вигадка, вона гармонізована з європейською. Директива 96/9/EC визначає «вилучення» як постійне або тимчасове перенесення всього чи суттєвої частини вмісту бази даних на інший носій будь-яким способом і в будь-якій формі. Улюблене «ми ж не копіювали сайт, ми зробили до нього запит» — це і є перенесення будь-яким способом.
Найпопулярнішу лазівку закрито окремо. Директива забороняє й повторюване та систематичне вилучення несуттєвих частин вмісту, якщо воно суперечить нормальній експлуатації бази або невиправдано шкодить законним інтересам її виробника. Схему «беремо по 200 товарів на день, щоб не було суттєвої частини» текст директиви описує прямо, і саме як порушення.
Історія, якою прикривають парсинг, закінчилася не так
У FAQ сервісів парсингу майже завжди є рядок «скрейпінг публічних даних законний, є прецедент hiQ проти LinkedIn». Прецедент справді є. Ось чим він закінчився для hiQ.
У листопаді 2022 року суд задовольнив позов LinkedIn за порушення користувацької угоди: автоматизований збір профілів визнано порушенням договору. Нюанс на боці скрейперів у справі теж лишився: за американським CFAA збір публічно доступних даних злочином не визнали. Але вирішила справу не CFAA, а звичайний договір — правила користування сайтом, які ви приймаєте самим фактом користування.
Різниця вийшла дорогою. Судове рішення на 500 тисяч доларів проти hiQ, відповідальність за каліфорнійськими деліктами trespass to chattels і misappropriation, заборонні заходи, які фактично закривають LinkedIn для парсингу назавжди. Компанія зобовʼязалася назавжди припинити скрейпінг і видалити весь код, дані й алгоритми, створені й отримані в процесі.
Українському магазину на 3000 SKU півмільйонний позов не загрожує: юрисдикція інша, масштаб інший. Загрожує сама конструкція. Публічність даних не робить збір дозволеним, коли є договірні умови й право виробника бази.
Другий рахунок — від Google, і він приходить швидше
Юридичний ризик імовірнісний: правовласник може й не помітити. Пошуковий не такий, бо Google за визначенням дивиться на всі каталоги одночасно.
У спам-політиках Google Пошуку скрейпінг визначено як «taking content from other sites, often through automated means, and hosting it with the purpose of manipulating search rankings». Тобто саме те, що робить магазин, який залив чужий каталог, щоб швидше почати ранжуватися.
Далі політика перелічує конкретні практики, і кожна вгадується з першого рядка. Порушенням названо «republishing content from other sites without adding any original content or value» і окремо — «reproducing content feeds from other sites without providing some type of unique benefit to the user». Дослівне копіювання опису у виробника без доданої цінності підпадає під означення thin affiliation: описи й огляди, скопійовані прямо в оригінального продавця, без власного контенту й доданої користі.
Найважливіший для практики пункт стосується рерайту. Стандартна порада «спарсимо і прогонимо через синонімайзер» ламається об пряму цитату: до скрейпінгу Google відносить і практику «copying content from other sites, modify it only slightly (for example, by substituting synonyms or using automated techniques), and republish it». Легкий рерайт — це не обхід політики, це приклад із самої політики.
І фінальний штрих для тих, хто генерує з фіда тисячі сторінок: «scraping feeds, search results, or other content to generate many pages… where little value is provided to users» кваліфікується як scaled content abuse.
Переписати описи справді можна. Але це окрема робота з окремою вартістю, а не безкоштовний додаток до парсера. Як влаштована генерація й редактура описів у промислових обсягах, ми розібрали на сторінці AI-контенту. Тут важливе одне: рядок «переписати 3000 описів» треба закласти в кошторис одразу, інакше економія на парсингу зʼїдається цілком.
Третій рахунок — від маркетплейсу
Якщо ви продаєте не лише на своєму сайті, у спарсеного контенту є ще один контролер. Rozetka за скаргою правовласника ховає товари продавця, які порушують авторське право: у кабінеті вони так і позначаються як приховані модератором. Скарга конкурента, чиї фото ви взяли, спрацьовує швидше за будь-який суд.
Схему «один спарсений фід у кілька вітрин» закрито окремо. Маркетплейс забороняє створення кількох магазинів з ідентичним асортиментом, бо це засмічує пошук. Продаж дропшип-товарів там теж заборонений: товари ховають, а співпрацю можуть розірвати в односторонньому порядку.
Чесний підсумок. Парсинг — найшвидший спосіб отримати структуру каталогу й характеристики. Але як спосіб отримати готовий до продажу контент він оплачується двічі: переписуванням і ризиком.
Шлях 2. Фіди постачальників і маркетплейсів — штатний шлях, про який мовчать
Ось що дивує найбільше. Сервіси парсингу докладно пояснюють, як зібрати дані з чужого сайту, і майже ніколи не згадують, що постачальник цілком легально віддає ті самі дані сам: файлом, за розкладом і зі своєї згоди.
Формат обміну товарними даними в Україні склався навколо XML у діалекті YML. Постачальник дає посилання на файл, ваш магазин забирає його за розкладом, звіряє позиції за ідентифікатором і оновлює ціни, залишки й нові товари. Це не хак, а передбачений спосіб роботи, під який у платформ є штатні інструменти. Що з цього підтримує ваша CMS, варто перевіряти ще на етапі вибору: на чому зробити інтернет-магазин і як обрати платформу для інтернет-магазину — про це в окремих статтях, тут лише те, що стосується каталогу.
Як це виглядає в WooCommerce
У WooCommerce імпорт вбудований. CSV-імпортер дозволяє масово завантажувати великі обсяги товарів разом з атрибутами, категоріями й зображеннями. Обовʼязкових колонок у файлі лише дві: SKU, який генерується автоматично, якщо відсутній, і Name. Решта полів опціональні, тож почати можна з мінімального файлу й доливати дані ітераціями.
Для регулярної роботи головне — повторний імпорт. Наявні товари, які збігаються за ID або SKU, оновлюються, а відсутні пропускаються. Саме на цьому будується щоденне оновлення цін і залишків з файлу постачальника: один і той самий файл заливаєте за розкладом, нічого не дублюється.
Граблі теж документовані. Максимальний розмір файлу задає не плагін, а сервер, тому великий каталог ділять на частини й уперше заливають на staging, а не в бойовому магазині.
В OpenCart усе інакше, ніж часто описують: імпорт там роблять через розширення з маркетплейсу, а не вбудованим інструментом із коробки. Це не мінус, але окремий рядок у кошторисі й окрема точка відмови при оновленні платформи.
Вимоги Rozetka — найсуворіші, і за ними зручно калібруватися
Якщо ви будуєте фід так, щоб він пройшов на Rozetka, він майже напевно пройде всюди.
Автоматизовано маркетплейс приймає товари лише у XML (YML) і лише в одному кодуванні: допустиме кодування даних — тільки UTF-8. Ідентифікатор товару допускає лише символи Aa-Zz і 0-9, тобто жодної кирилиці в артикулах, і після завантаження товару його вже не змінити. Це найдорожча з усіх дрібних помилок: неправильна схема ID означає перезаливку каталогу з нуля.
Зображень на товар від 1 до 15, розмір — мінімум 400×400 px, максимум 4000×4000 px при оптимальному квадраті 1000×1000, вага одного файлу до 10 МБ, формати JPEG, GIF, PNG і WebP.
Опис товару обмежено 50 000 символами, місця більш ніж достатньо. А от заборонений список варто прочитати до того, як контент-менеджер напише перший опис: не можна посилання на сторонні ресурси, ціни та інформацію про інші товари, зображення, відео, емодзі, дані про доставку й способи оплати, контакти магазину, кольоровий текст. Магазини регулярно ловлять відмову модерації саме на «безкоштовна доставка від 1000 грн» усередині опису.
Hotline і Google Merchant Center
У прайс-агрегатора обмеження свої. Товарний фід Hotline не повинен перевищувати 150 тисяч товарів; формати приймаються ширші — XML, YML, CSV, XLS і TXT, кодування UTF-8 або windows-1251, а оновлювати пропозиції дозволено кілька разів на добу. Для зображень вимога, яка одразу відсіює чужі фото: реальні фотографії товару на білому тлі, без логотипів, тексту й водяних знаків.
Google Merchant Center формалізує те саме на своєму боці. Опис — обовʼязковий атрибут, максимум 5000 символів, і в ньому не можна посилань на ваш магазин, інформації про акції, згадок конкурентів, інших товарів чи аксесуарів. Назва — до 150 символів. Зображення не може містити рекламного тексту, водяних знаків чи рамок, і заглушку замість фото подавати не можна.
Один пункт занесіть у календар просто зараз. Google вимагатиме зображення товару щонайменше 500×500 пікселів, і вимога набуває чинності 31 січня 2027 року. Якщо ваш каталог зібрано зі старих фото 300 px по довшій стороні, перезйомка стає задачею на 2026 рік, а не сюрпризом у січні 2027-го.
Для товарних результатів у самому пошуку обовʼязковий мінімум ще скромніший: merchant listing вимагає Offer, бо продавцем товару має бути саме ви. Тобто name, image і offers з ціною та валютою, решта полів рекомендовані.
Підсумок шляху. Красивих описів фід не дає. Він дає точні дані, законне джерело й механізм оновлення — фундамент, на який лягає все інше.
Шлях 3. Руками — коли товарів мало або вони ваші

Ручне наповнення виглядає архаїчно рівно доти, доки не порахувати, чого воно уникає: узгодження форматів, розбору чужого XML, переписування описів і ризиків із двох попередніх розділів. На каталозі до 200–300 позицій руки часто фінішують раніше за автоматику, бо в автоматики є власна фаза налаштування, яку ніхто не закладає в оцінку.
Про ціну скажу чесно. Цифр «вартість за SKU» з чужих блогів ми свідомо не наводимо: їх публікують ті самі підрядники, які цю послугу продають, і перевірити методику неможливо. Рахуйте у своїх годинах. Візьміть десять реальних товарів, заведіть їх повністю — назва, характеристики, опис, фото, категорії, SEO-поля — і засікайте час. Ця цифра, помножена на каталог, буде точнішою за будь-який чужий бенчмарк.
Головний аргумент за ручний шлях навіть не в грошах. Він у тому, що конкуренти цю частину роблять погано. За бенчмарком Baymard, 10% великих інтернет-магазинів мають описи товарів, недостатні для потреб користувача, і це видно в поведінці покупців. Учасник тестування, порівнюючи два крісла, сформулював свій вибір прямо: [«There's a lot of information here, on the chair… I'm starting to discount [the other chair], because there's very little information»](https://baymard.com/blog/product-descriptions). Товар програв не ціною й не фото, а обсягом інформації.
Друга цифра ще цікавіша. Структурують опис за ключовими характеристиками лише 22% сайтів; решта 78% лишають суцільну стіну тексту навіть на топових товарах. Реакція користувача в тестах така сама пряма: «It's like… all of this text… you don't really want to read it».
Ситуація виходить парадоксальна. Скопійований опис від виробника карається Google, а власний, але неструктурований, ігнорується покупцем. Виграє третій варіант, якого майже ніхто не робить: короткі highlights згори, розгорнутий текст нижче.
Три шляхи поруч
| Парсинг | Фіди постачальників | Руками | |
|---|---|---|---|
| Швидкість | Найвища: тисячі позицій за ніч | Середня: 1–3 дні на налаштування, далі автоматично | Найнижча: години на кожні 10 товарів |
| Юридичні ризики | Високі: право sui generis виробника бази (15 років), порушення умов користування, скарги правовласників | Мінімальні: дані передає власник із власної згоди | Відсутні |
| SEO-наслідки | Дублі й scraped content у спам-політиках Google; рерайт синонімами політику не обходить | Нейтральні: дані точні, але описи однакові в усіх, хто взяв той самий фід | Найкращі: власний текст, дублів немає |
| Оновлення цін і залишків | Треба будувати й підтримувати парсер | Штатне: повторний імпорт за ID/SKU | Ручне, не масштабується |
| Коли доречно | Розвідка ринку, збір структури категорій і характеристик — як чернетка, не як контент | Основний робочий шлях для будь-якого каталогу від кількох сотень позицій | Каталог до 200–300 позицій, рідкісні товари чи власне виробництво, топ-товари в будь-якому магазині |
Що з цим робити на практиці
Робоча відповідь майже завжди комбінована, і послідовність у неї така.
Спершу фід. Просите у постачальника XML/YML або CSV, налаштовуєте імпорт за ID/SKU і отримуєте скелет каталогу з точними даними та механізмом оновлення. Це база, і вона законна.
Далі описи. Фід дає технічні дані, але текст у ньому той самий, що й в усіх ваших конкурентів із тим самим постачальником. Переписуйте не все одразу, а за пріоритетом: спершу 50–100 товарів, які приносять гроші, потім решта. І структуровано: highlights згори, деталі нижче.
Парсинг лишається інструментом розвідки, а не наповнення. Подивитися, як конкурент розкладає категорії, які характеристики вважає важливими, де в нього фільтри. Це аналітика, і в ваші сторінки вона дослівно не переїжджає.
Окремо фото. Тут компромісу зазвичай немає: чужі знімки не пройдуть ані вимогу Hotline про відсутність водяних знаків, ані заборону Google на рамки й рекламний текст, ані скаргу правовласника на Rozetka. Предметна зйомка — рядок бюджету, який доведеться закласти.
Якщо ви зараз на етапі, де наповнення інтернет-магазину товарами треба оцінити в грошах і тижнях, напишіть нам. Подивимося ваш каталог і джерела даних та скажемо, що з цього автоматизується, а що доведеться робити руками.
Часті питання
Чи законно парсити сайт конкурента?
Публічність даних сама по собі дозволу не дає. За статтею 21 закону «Про авторське право і суміжні права» виробник бази даних, який зробив значний внесок у її наповнення чи перевірку, має право особливого роду (sui generis) саме для запобігання вилученню й повторному використанню вмісту. Діє воно 15 років, а істотна зміна вмісту бази дає їй новий строк охорони (ч. 8 ст. 21). Окремо працюють умови користування сайтом: у справі hiQ проти LinkedIn вирішальним виявився саме договір, а не компʼютерне законодавство. Оцінку конкретної ситуації має давати юрист, а не підрядник, який продає парсинг.
Ми беремо по 100 товарів на день, а не весь каталог. Це вже не «суттєва частина»?
Директива ЄС 96/9/EC у статті 7(5) окремо забороняє повторюване й систематичне вилучення несуттєвих частин, якщо воно суперечить нормальній експлуатації бази або шкодить законним інтересам її виробника. Тобто дроблення описане в тексті норми прямо і не як виняток.
Якщо переписати спарсені описи синонімами — Google це пропустить?
Ні. У спам-політиках Google приклад скрейпінгу сформульовано дослівно як копіювання з незначною модифікацією, зокрема заміною синонімів або автоматичними техніками. Це не сірий метод — це описаний у політиці приклад порушення.
Скільки коштує наповнення каталогу?
Автоматичну частину рахують прозоро: у Horoshop парсинг починається від 6000 грн за перший сайт-донор (до 10 000 товарів у базі, далі +100 грн за тисячу). Ручну частину коректно рахувати у своїх годинах — заведіть десять товарів повністю, засічіть час і помножте. Чужих бенчмарків «за SKU» ми не наводимо: їх публікують ті, хто цю послугу продає.
Чи можна залити той самий фід у власний магазин і на Rozetka?
На маркетплейсі — з обмеженнями. Rozetka забороняє створення кількох вітрин з ідентичним асортиментом і продаж дропшип-товарів, а за скаргою правовласника ховає товари, що порушують авторське право. Технічно фід один, змістовно картки мають відрізнятися.
Який мінімум даних потрібен, щоб почати?
У WooCommerce обовʼязкових колонок у CSV лише дві — SKU і Name; SKU навіть згенерується автоматично, якщо його немає. Для Google Merchant Center мінімум суворіший: опис обовʼязковий і обмежений 5000 символами, назва — 150 символами. Стартувати можна з мінімального файлу й доливати поля ітераціями.
Які вимоги до фото, щоб не переробляти каталог двічі?
Орієнтуйтеся на найсуворіші. Rozetka приймає від 400×400 до 4000×4000 px, до 10 МБ, від 1 до 15 фото на картку. Hotline вимагає реальні фото на білому тлі без логотипів і водяних знаків. Google вимагатиме щонайменше 500×500 px із 31 січня 2027 року. Квадрат 1000×1000 без сторонніх написів закриває всі три.
Скільки описів переписувати, якщо їх тисячі?
Не всі й не одразу. Спершу 50–100 товарів, які приносять основну виручку, і структуровано: короткі highlights згори, деталі нижче. За даними Baymard, так робить лише 22% сайтів, тож це одна з небагатьох переваг, яку ще можна отримати простою роботою.
Чи була стаття корисною?
Схожі статті
E-commerceContent API for Shopping вимикають 18 серпня 2026
Гайд9 хв читання
18 серпня 2026 Google вимикає Content API for Shopping. Дві перевірки в Merchant Center за п'ять хвилин покажуть, чи стосується це вашого магазину.
E-commerceЧому пошук у магазині не знаходить товар, який є на складі
Гайд17 хв читання
Товар на складі, а пошук по сайту інтернет-магазину віддає нуль. Вісім класів поломки — типи запитів, описки, транслітерація, брехливі лічильники фільтрів.
E-commerceПошук запчастин за VIN-кодом у магазині — і чому він то рятує, то підводить
Гайд14 хв читання
Пошук запчастин за VIN-кодом впізнає авто, але не деталь. Що кодують 17 символів, чому безкоштовний декодер не допоможе і звідки беруться дані сумісності.