WooCommerce — одна з найпотужніших e-commerce платформ у світі. За 10+ років екосистема плагінів виросла настільки, що на ньому працюють і магазини на 50 товарів, і серйозні проєкти з тисячами позицій, мультивалютністю, складними знижками й інтеграціями з ERP.
Для 95% магазинів WooCommerce — правильний вибір. І якщо у вас усе працює, переписувати нічого не треба. Ця стаття не про те, що WooCommerce поганий.
Вона про вузьку, але цілком реальну категорію бізнесів, де навіть ідеально налаштований WooCommerce перестає бути правильним фундаментом. І головне — про те, як зрозуміти, чи ви в цій категорії.
Чотири ознаки, що ви вперлися в стелю
Власники таких магазинів зазвичай самі відчувають, що щось не так. Але формулюють це не технічними термінами, а так:
Ознака 1: «У нас людина сидить і переносить дані руками»
Найпоширеніша і найдорожча ознака.
Замовлення прийшло на сайт — менеджер вручну заводить його в 1С. Прийшов товар на склад — хтось оновлює залишки на сайті. Змінилась ціна в обліковій системі — правимо на сайті окремо. Продали на Rozetka — треба не забути зняти залишок на власному сайті.
Кожна така операція — це зарплата людини, помилки й затримки. І коли систем стає три-чотири, ручна синхронізація перестає масштабуватись узагалі.
Тест: порахуйте, скільки годин на тиждень ваші люди витрачають на перенесення даних між системами. Помножте на місяць. Часто виявляється, що це вартість розробки за пів року.
Ознака 2: «Кожне доопрацювання ламає щось інше»
Спочатку поставили плагін для знижок. Потім для B2B-цін. Потім для синхронізації з маркетплейсом. Потім ще один — бо попередній не вміє те, що треба.
Тепер кожне оновлення WordPress — це стрес. Оновили — щось відвалилось. Не оновлюєте — накопичуються дірки в безпеці. Розробник каже «це конфлікт плагінів» і бере гроші за те, щоб знайти який саме.
Причина архітектурна. WooCommerce побудований поверх WordPress, а структура даних WordPress заточена під пости й сторінки — не під складні бізнес-сутності. Тому будь-яка нестандартна логіка реалізується через додатковий плагін, і кожен плагін — окрема точка відмови.
Тест: порахуйте активні плагіни. Якщо їх більше двадцяти і половина відповідає за бізнес-логіку, а не за дрібниці — ви вже платите за цю архітектуру.
Ознака 3: «Наші процеси не вкладаються в стандартну логіку»
Кожен B2B-клієнт має свій прайс і свої умови відстрочки. Замовлення понад певну суму має пройти погодження. Ціна залежить від обсягу, регіону й типу клієнта одночасно. Певні товари доступні тільки окремим контрагентам.
Це нормальні бізнес-процеси — але для магазину, який задумувався як каталог із кнопкою «купити», вони чужі. Кожне таке правило доводиться вбудовувати збоку, обхідними шляхами.
Тест: якщо на питання «а як у вас працює ціноутворення» неможливо відповісти одним реченням — ваша логіка складніша за платформу.
Ознака 4: «Сайт гальмує, і оптимізація вже не допомагає»
Важливо розрізнити дві різні ситуації.
Перша: сайт гальмує через поганий хостинг, невідключений кеш, неоптимізовані зображення й десять зайвих плагінів. Це лікується. І лікується дешево — зазвичай за кілька днів роботи.
Друга: ви вже все це зробили, а магазин усе одно не тримає навантаження, бо позицій десятки тисяч, каталог із фільтрами по двадцяти параметрах, а в піки заходить кілька тисяч людей одночасно.
Перша ситуація — більшість випадків. Не переписуйте магазин, поки не виключили її.
Тест: зробіть нормальний технічний аудит. Якщо після виправлення всіх знахідок швидкість не змінилась — проблема справді у фундаменті.
Коли переписувати НЕ треба
Це важливіше за попередній розділ, тому окремо.
- «Хочу на сучасному стеку» — це не причина. Технології заради технологій коштують грошей і не приносять нічого.
- «У конкурента швидше» — спершу з'ясуйте, чому саме. Найчастіше справа в хостингу й картинках, а не в платформі.
- «Розробник сказав, що WooCommerce — це погано» — запитайте, що конкретно з вашого списку задач він не може зробити. Часто відповіді немає.
- Типовий магазин навіть із серйозними оборотами — WooCommerce справляється. Переписувати заради архітектури сенсу немає.
Проста перевірка: якщо ви не можете назвати конкретну задачу, яку ваша поточна платформа не дозволяє вирішити, — переходити рано.
Що ставити замість: headless-підхід
Якщо ви впізнали себе хоча б у двох ознаках — ось що це означає технічно.
Замість того щоб добудовувати чужу платформу плагінами, бекенд пишеться під ваші процеси. Ми для таких проєктів використовуємо зв'язку Payload CMS + Next.js.
Payload — це headless CMS на Node.js/TypeScript, по суті фреймворк для побудови бекенду: моделі даних, поля, зв'язки, права доступу й реакції на будь-яку подію пишуться як звичайний код у вашому репозиторії, а не налаштовуються через сторонні плагіни.
Що це дає для проблем із чотирьох ознак вище:
- Замість ручного перенесення даних — один ланцюжок подій. Коли змінюється замовлення, система може одночасно створити накладну через API Нової Пошти, надіслати SMS клієнту, оновити залишки на кількох складах і засинхронізувати статус у CRM. Це не набір плагінів, які нічого не знають один про одного, а один контрольований процес, який ми спроєктували й тестуємо цілком.
- Замість конфліктів плагінів — власний код. Немає чужих розширень, які конкурують за одну й ту саму подію. Оновлення не ламає бізнес-логіку, бо бізнес-логіка ваша.
- Замість обхідних шляхів — пряма реалізація ваших правил. Індивідуальні B2B-прайси, погодження замовлень, динамічне ціноутворення описуються прямо, а не збираються з трьох плагінів і милиць.
- Замість боротьби за швидкість — контроль над кожним байтом. REST і GraphQL з коробки, SSR/ISR на Next.js, тонке налаштування структурованих даних і показники Core Web Vitals, яких важко досягти на важкому CMS-стеку.
- Плюс адмінка під ваші процеси, а не під те, що дозволяє чужий движок: свої поля, свої ролі, свої масові дії, свої дашборди.