Почніть не з шаблону, а з одного складного товару. Візьміть модель у кількох кольорах і розмірах, один відсутній варіант та приклад оновлення залишку. Якщо ці дані неможливо однозначно описати в таблиці, їх буде важко правильно перенести в картку, кошик, складську систему й аналітику.
1. Не плутайте модель товару та складський варіант
Модель об’єднує спільні властивості: назву, бренд, крій, склад, догляд і загальний опис. Варіант — конкретна комбінація, яку можна замовити: наприклад, чорне худі розміру M. Саме варіант має стабільний SKU, доступну кількість і, за потреби, власну ціну. Загальний залишок моделі не повинен дозволяти купити відсутній розмір.
Визначте ідентифікатори до першого імпорту. Якщо кожен файл постачальника створює новий артикул для тієї самої позиції, оновлення ризикує створювати дублікати. Узгодьте відповідність артикулу постачальника й внутрішнього SKU, одиниці виміру, формат ціни та хто має право змінювати дані. Не записуйте номер розміру лише в довільний опис: фільтр і кошик повинні отримувати окреме значення.
2. Контрольний приклад для брифу
Нижче умовні навчальні дані, не реальний товар або результат клієнта. На них можна узгодити логіку імпорту й перевірки. Ціну та комерційні умови заповнює продавець у власному файлі.
| Модель | SKU | Колір / розмір | Залишок | Очікуваний стан |
|---|---|---|---|---|
| HOOD-A | HOOD-A-BLK-M | Чорний / M | 2 | Можна замовити доступну кількість |
| HOOD-A | HOOD-A-BLK-L | Чорний / L | 0 | Недоступний, без прихованої заміни на M |
| HOOD-A | HOOD-A-SAND-M | Пісочний / M | 1 | Інший SKU та відповідне фото кольору |
Для кожного рядка додайте джерело залишку, час оновлення, посилання на дозволене фото, розмірну таблицю та відповідального. У повторному імпорті змініть лише кількість одного SKU: інші варіанти не мають зникнути або отримати чужий залишок. Порожнє поле й нуль — різні стани; правило обробки порожніх даних треба погодити.
3. Розмірна сітка та фото мають відповідати варіанту
Для одягу буквене позначення розміру не пояснює посадку. Потрібні погоджені продавцем виміри: що вимірюється, одиниці, спосіб вимірювання та до якої лінійки належить таблиця. Вимір тіла й вимір готового виробу не можна змішувати в одній колонці без пояснення. Якщо виробник не надав даних, не заповнюйте їх приблизними значеннями іншого бренду.
Таблиця має читатися на телефоні й відкриватися поруч із вибором розміру. Для фото визначте порядок кадрів, зв’язок із кольором, права на використання й зрозумілий альтернативний опис. Перемикання на пісочний колір повинно показати пісочний виріб, а не залишити чорне фото з попереднього вибору. Зйомка, ретуш і наповнення великого каталогу — окремі роботи, якщо вони не включені до погодженого обсягу.
4. Хто є джерелом залишків і коли резервується товар
До інтеграції визначте одну відповідальну систему: обліковий сервіс, складська система або адміністратор магазину. Запишіть частоту синхронізації, поведінку під час недоступності сервісу й момент резервування. «Підключити CRM» недостатньо: замовлення, оплата й складський резерв — різні стани з різними власниками.
Сценарій останнього розміру перевіряють окремо: двоє покупців додають той самий SKU, доступний в одному екземплярі. Сервер має повторно перевірити можливість замовлення й не покладатися лише на число в браузері. Після відмови оплати резерв знімається або зберігається за погодженим правилом. Обмін на інший розмір повинен змінювати правильні SKU; довільне збільшення загального залишку моделі зіпсує дані.
Умови доставки, обміну та повернення надає й погоджує продавець. Цей гайд не встановлює юридичних строків або винятків для конкретного виду одягу. Команда реалізує затверджений процес і видимі пояснення, а не вигадує їх замість бізнесу.
5. Категорія, фільтр і варіант — три різні задачі SEO
Категорія допомагає обрати тип товару, фільтр звужує асортимент, а URL варіанту відкриває конкретний вибір. Не кожне поєднання кольору, розміру, ціни та сортування заслуговує на індексовану сторінку. До розробки складіть список посадкових категорій із реальним асортиментом та окремим наміром. Для інших комбінацій окремо погодьте правила обходу й індексації; robots.txt не є універсальним способом прибрати вже індексований URL.
Google рекомендує адреси, за якими варіант можна розрізнити, наприклад через шлях або параметри. Один лише фрагмент після # не створює окремої індексованої сторінки. Сталі адреси й відсутність зайвих дублів полегшують обхід; це не гарантує показів. Джерело: Google про URL інтернет-магазинів.
Для варіантів Google описує ProductGroup і Product з окремими ідентифікаторами. Канонічна модель залежить від реалізації: одна сторінка з вибором варіантів і кілька самостійних сторінок — не однакові схеми. Важливо, щоб прямий URL відкривав правильні фото, ціну, наявність і вибір для кошика. Джерело: офіційні правила product variants.
Практична перевірка MAX SITE: відкрити адресу варіанту в новому вікні, звірити вибір у картці, кошику та schema; потім повторити для відсутнього розміру. Валідація розмітки не виправить неправильний залишок або підміну кольору в замовленні. Рейтинг не додається, якщо немає справжніх відгуків і підстав для їх використання.
6. Матриця обсягу першого релізу
Скопіюйте рядки до шаблону ТЗ й позначте для кожного «у першому релізі / пізніше / не потрібно». До погодження не вважайте інтеграцію або наповнення включеними лише тому, що вони є в бажаному макеті.
| Блок | Надає продавець | Погоджений результат | Як прийняти |
|---|---|---|---|
| Каталог | Моделі, SKU, категорії, атрибути | Імпорт без дублів і втрати зв’язків | Повторний файл оновлює існуючий SKU |
| Розміри й фото | Виміри та дозволені медіа кожного кольору | Зрозумілий вибір на телефоні | Перемикання змінює правильний варіант |
| Наявність | Джерело, частота й правила резерву | Окремий залишок кожного SKU | Останній екземпляр не продається двічі |
| Замовлення | Статуси, оплата, доставка, відповідальний | Узгоджений шлях до менеджера | Відмова й повтор не дублюють замовлення |
| SEO | Пріоритетні категорії та фактичний асортимент | Карта URL, canonical і правила фільтрів | Контрольні адреси відповідають карті |
| Аналітика | Власник GA4 і погоджений перелік подій | Події з коректним ідентифікатором товару | Тестове замовлення звірено без контактних даних у подіях |
Наповнення всіх товарів, кілька мов, програма лояльності, особистий кабінет, маркетплейси й складні обміни не зникають із бюджету через слово MVP. Запишіть рішення по кожному пункту. Загальні етапи запуску зібрані в матеріалі що входить у розробку інтернет-магазину, а витрати — в окремому гайді про кошторис магазину.
7. Сім контрольних сценаріїв до запуску
- Відкрити категорію на телефоні, вибрати колір і розмір, повернутися назад: стан фільтра зрозумілий, кнопки не перекриті.
- Змінити колір моделі: фото, доступні розміри та SKU у кошику відповідають новому вибору.
- Спробувати купити розмір із нульовим залишком: система не підставляє інший товар без згоди покупця.
- Оновити імпорт залишків: зміна одного SKU не обнуляє сусідні варіанти й не створює дубль.
- Повторити запит після перерваної оплати: номер і склад замовлення узгоджені, повторне підтвердження не створює ще одну покупку.
- Відкрити прямий URL варіанту й звірити видимі дані з розміткою, ціною та наявністю.
- Передати тестове замовлення відповідальному: запис містить конкретний колір, розмір і SKU; аналітика не містить імені, телефона або адреси покупця.
Біля кожного тесту збережіть дату, виконавця, тестові дані та посилання на доказ. Неперевірений сценарій позначайте відкритим, а не «готово». Для нового проєкту почніть із брифу та одного контрольного набору товарів; це предметніше за замовлення магазину «як у конкурента».
Межі матеріалу та джерела
Модель даних, навчальна таблиця та сценарії приймання — практичні рекомендації MAX SITE. Офіційні документи Google, наведені в SEO-розділі, перевірено 10.09.2026; перед впровадженням слід звірити актуальну документацію обраної платформи й платіжного сервісу. Приклади не є підтвердженим кейсом магазину одягу, юридичною консультацією або обіцянкою зростання продажів.
Від даних каталогу до працюючого магазину
Погодьте склад системи та бюджет після перевірки одного складного товару, способів оплати і джерела залишків.
Чекліст приймання замовлення (.md). Фіксуйте тестові дані, очікуваний результат і доказ кожної перевірки.