Это кейс комплексной переработки существующего интернет-магазина на WooCommerce. Задача включала не только новый внешний вид, но и кастомную тему, переработку каталога и карточек товаров, корзины, checkout, доставки и оплаты — с сохранением действующих процессов магазина.
Сегодня магазин работает на новой технической базе, принимает и обрабатывает реальные заказы. На момент подготовки кейса месячный объём продаж превышает 1,2 млн ₽.
Важно: финансовый показатель приведён исключительно для понимания масштаба production-проекта. Он не означает, что указанная выручка стала результатом только редизайна или выполненной разработки.
Исходная задача
На старте это был не пустой WordPress и не новый проект без пользователей. Интернет-магазин уже располагал каталогом, покупателями, заказами, настроенными сценариями оплаты и доставки, поисковым трафиком и товарными фидами. Любое изменение могло затронуть не только интерфейс, но и ежедневную работу бизнеса.
Требовалось существенно обновить frontend и техническую реализацию: заново собрать ключевые пользовательские сценарии, упростить работу с каталогом и товаром, привести мобильную версию к общей логике и оставить административную часть управляемой. При этом было важно сохранить рабочие данные и совместимость новой реализации с WooCommerce.
Почему это был не просто редизайн
В обычном редизайне можно сосредоточиться на композиции, типографике и визуальных компонентах. В действующем WooCommerce-магазине интерфейс является частью транзакционной системы. Каталог связан с товарами и вариациями, кнопка покупки — с состоянием корзины, checkout — с оплатой, доставкой и созданием заказа, а контент — с административной частью и SEO.
Поэтому каждый новый экран проектировался не изолированно, а как продолжение существующей бизнес-логики. Нужно было учитывать разные состояния товара, поведение вариаций, пересчёт корзины, выбор способа доставки и точки выдачи, передачу данных платёжным модулям и корректное сохранение заказа. Внешне простое изменение в такой системе может затрагивать несколько уровней WooCommerce.
Кастомная WooCommerce-тема
Для проекта разработана собственная WordPress/WooCommerce-тема и новая главная страница. Кастомный frontend позволил не подстраивать сценарии магазина под ограничения универсального шаблона и не переносить в production лишние компоненты, которые проекту не нужны.
Шаблоны и интерактивные элементы собирались вокруг реальных данных WooCommerce: цены, наличия, вариаций, галереи, отзывов, связанных товаров и состояния корзины. Desktop- и mobile-представления проектировались как части одной системы, а не как отдельная «уменьшенная» версия сайта.
Каталог и навигация по товарам
Каталог переработан с учётом сценария последовательного выбора. Покупатель может менять фильтры и сортировку без полной перезагрузки страницы. AJAX-обновление сохраняет контекст просмотра и сокращает число лишних переходов, но остаётся связано с серверной выборкой WooCommerce, а не существует как отдельная витрина.
- структура каталога и карточек в товарной сетке приведена к единой визуальной системе;
- фильтрация и сортировка работают с актуальной товарной выборкой;
- состояния загрузки и обновления результатов учтены в интерфейсе;
- элементы управления адаптированы для desktop и мобильных экранов.
Задача этого слоя — не показать как можно больше контролов, а помочь человеку сузить выбор и перейти к товару, не теряя выбранные параметры.
Карточка товара
Страница товара была собрана как самостоятельный сценарий принятия решения. В верхней части объединены галерея, основные сведения и buybox с ключевым действием Add to Cart. Sticky-панель сохраняет доступ к покупке при просмотре длинной страницы, не заставляя возвращаться к началу.
Ниже размещаются преимущества, дополнительные контентные секции и связанные товары. Отзывы встроены в общую структуру карточки: пользователь видит рейтинг, может открыть popup-форму, оставить отзыв и приложить изображение. Все компоненты учитывают адаптивное отображение и разные объёмы контента.
Гибкий контент через ACF
Для дополнительных секций товара разработан ACF-конструктор. Администратор управляет содержанием из WordPress: добавляет необходимые блоки, меняет их порядок, выбирает расположение текста и изображения и настраивает предусмотренные варианты оформления.
Это отделяет контентную работу от шаблонов темы. Для изменения последовательности секций не требуется править PHP или вручную собирать разметку в редакторе. Одновременно набор доступных вариантов ограничен дизайн-системой, поэтому страницы остаются визуально согласованными.
Корзина и оформление заказа
Корзина переведена на AJAX-взаимодействие: изменения состава заказа и количества товаров отражаются без полной перезагрузки страницы. Checkout кастомизирован под фактическую последовательность оформления, способы оплаты и сценарии доставки магазина.
В этой части внешний вид нельзя отделить от расчётов. При изменении адреса, доставки или состава корзины WooCommerce должен заново получить корректные тарифы и итоговую сумму, а после подтверждения — создать заказ со всеми необходимыми данными. Поэтому интерфейсные изменения проверялись вместе с серверной логикой, а не только визуально.
Интеграции
В production-реализацию входят подключение платёжных методов, доставка и работа с пунктами выдачи. Для внешних площадок формируется товарный YML/XML-фид. Выполнены технические SEO-работы, необходимые при переходе на новую тему и изменении шаблонов ключевых страниц.
Интеграционный слой построен так, чтобы данные внешних сервисов проходили через правила магазина и WooCommerce. Параметры подключений, ключи, внутренние идентификаторы и сведения о провайдерах в кейсе намеренно не раскрываются.
Как дорабатывать магазин, который уже принимает заказы
Когда через сайт проходят реальные платежи и заказы, существенные изменения нельзя без необходимости проверять непосредственно на production. Для новых функций используется тестовая копия, максимально близкая к рабочему окружению. Это не устраняет все риски, но заметно снижает вероятность нарушить работу действующего магазина.
- Постановка задачи. Фиксируется пользовательский сценарий, ожидаемый результат и ограничения.
- Анализ реализации. Изучаются текущая тема, плагины, хуки WooCommerce, данные и связанные интеграции.
- Разработка на staging. Изменение создаётся на тестовой копии, а не в рабочем магазине.
- Самостоятельное тестирование. Проверяются основной сценарий, пограничные состояния, desktop и mobile.
- Проверка заказчиком. Владелец проекта подтверждает соответствие реальному бизнес-процессу.
- Корректировки. Замечания вносятся и повторно проверяются на staging.
- Перенос подтверждённой версии. На production попадает согласованный набор изменений.
- Проверка после релиза. Контролируются затронутые страницы, расчёты, создание заказа и интеграции.
Особенно важен такой порядок для checkout, корзины, скидок, оплаты, доставки, сохранения заказов и обмена с внешними API. Тестовая среда при этом должна учитывать версии PHP, WordPress, WooCommerce, тему, плагины и настройки, способные изменить поведение функции.
Развитие после запуска
Публикация новой версии стала переходом к следующему этапу, а не финальной точкой. Production-магазин продолжает получать задачи из реальной эксплуатации: новые правила появляются по мере изменения процессов, ассортимента и требований внешних сервисов.
Реализовано и работает
Кастомная тема, обновлённые главная страница, каталог и карточка товара, AJAX-фильтрация и корзина, ACF-конструктор, кастомизированный checkout, платёжные методы, доставка с ПВЗ, отзывы с рейтингом и изображениями, товарный фид и адаптивные версии используются в рабочем магазине.
Запланировано или рассматривается
В бэклоге развития рассматриваются улучшение ввода адресов и интеграция DaData, дополнительные правила скидок по категориям и исключениям, управляемые товарные плашки, автоматизация брошенных корзин, трекинг доставки и новые интеграции.
Статус зафиксирован намеренно: перечисленные в этом подразделе возможности не выдаются за работающие на production. Функция переходит в статус «реализовано» только после разработки, проверки, согласования и релиза. На момент подготовки кейса отдельные задачи со статусом «в разработке» публично не заявляются без подтверждения релиза.
Более 1,2 млн ₽ продаж в месяц
1 200 000+ ₽
продаж за месяц
Действующий WooCommerce-магазин · Production project
Магазин работает с реальными покупателями и заказами. Этот агрегированный показатель демонстрирует масштаб проекта, в котором изменения затрагивают действующий канал продаж. Он не является заявлением о росте выручки, конверсии или результате исключительно редизайна и разработки.
Что важно при разработке действующего WooCommerce-магазина
- Не переписывать работающую систему без причины. Сначала нужно определить, какие части действительно ограничивают развитие, а какие достаточно сохранить или локально изменить.
- Учитывать существующую архитектуру. Тема, плагины, кастомные хуки, структура данных и задания cron могут быть связаны неочевидным образом.
- Интегрировать, а не изолировать. Новая функция должна корректно работать с текущими правилами цен, товаров, заказов и ролей пользователей.
- Отдельно проверять критический путь. Корзина, checkout, платежи и доставка требуют сценарного тестирования с пересчётами и пограничными состояниями.
- Поддерживать релевантный staging. Чем сильнее тестовая копия отличается от production, тем меньше ценность проверки.
- Проверять после deployment. Успешный тест на staging не заменяет контроль затронутых сценариев после переноса.
Такой подход применим не только к редизайну. Он нужен для любой доработки WooCommerce-магазина, которая влияет на заказы или работу менеджеров. Если требуется отдельная интеграция или собственная бизнес-логика, полезно заранее определить, достаточно ли изменения темы или нужна разработка плагина под задачу. Другие примеры проектов собраны в разделе кейсов WordPress-разработки.
Нужна доработка существующего WooCommerce-магазина?
Если интернет-магазин уже работает, но ему требуется редизайн, новый функционал, интеграция или переработка существующей WooCommerce-логики, можно начать с анализа конкретной задачи. Полный перезапуск нужен не всегда: иногда безопаснее сохранить устойчивые части системы и заменить только то, что ограничивает проект.
Отправьте ссылку на магазин и кратко опишите, что требуется изменить или разработать. Я изучу текущую реализацию и предложу технический вариант.
Хотите обсудить проект?
Напишите задачу — предложим решение, сроки и этапы. Без воды.
