"WooCommerce: установка и настройка"

MAATRIX

WooCommerce — самый популярный способ превратить обычный WordPress-сайт в интернет-магазин: бесплатный плагин, огромная экосистема расширений и понятная админка. Но «поставить плагин» и «получить работающий магазин» — разные задачи: между ними мастер настройки с десятком развилок, платёжные методы, которые надо реально протестировать, и ресурсы сервера, которые обычный блог-хостинг не потянет. Разберём весь путь от установки до типичных граблей.

Установка плагина WooCommerce

Предполагаем, что WordPress на сервере уже стоит — если нет, сначала разверните его по связке Nginx + PHP-FPM + MySQL, это отдельная тема: пошаговая установка WordPress на LEMP.

Установка самого WooCommerce — через админку, без консоли:

1. В админ-панели WordPress: Плагины → Добавить новый.
2. В поиске — «WooCommerce», первый результат от Automattic.
3. Установить, затем Активировать.

После активации WordPress сам предложит запустить мастер настройки (Setup Wizard) — на нём и остановимся ниже. Если мастер не появился или вы его закрыли, вернуться к нему можно через WooCommerce → Главная, там будет кнопка запуска настройки заново, либо все те же разделы доступны напрямую в WooCommerce → Настройки.

Если ставите через WP-CLI (быстрее при разворачивании магазина с нуля скриптом):

wp plugin install woocommerce --activate

Учтите: сама установка плагина занимает секунды, а вот создание нужных ему страниц (корзина, оформление заказа, мой аккаунт) и таблиц в базе данных — на этом этапе WooCommerce добавляет собственные таблицы поверх стандартных WordPress, и на слабом диске это иногда заметно тормозит первый запуск мастера на 10-20 секунд.

Мастер настройки: валюта, локация, единицы измерения

Мастер задаёт базовые параметры магазина, и часть из них потом неудобно менять на живом каталоге — лучше сразу указать правильно.

Местоположение и валюта. Страна/регион магазина определяет налоговые ставки по умолчанию и доступные способы доставки. Валюта задаётся отдельным полем в WooCommerce → Настройки → Общие — для России это чаще всего RUB, но если магазин ориентирован на зарубежных покупателей, можно выбрать USD или EUR сразу, чтобы не переписывать цены у всех товаров потом.

Тип товаров. Мастер спрашивает, что вы продаёте — физические товары, цифровые, или и то и другое. От этого зависит, появится ли в оформлении заказа поле адреса доставки.

Единицы измерения. Вес (кг/фунты) и размеры (см/дюймы) — важно для расчёта стоимости доставки у некоторых служб, которые считают по объёмному весу.

Что стоит проверить сразу после мастера, в WooCommerce → Настройки → Общие:

Страна/регион продаж — где продаёте физически
Разрешённые страны для доставки — куда готовы отправлять
Валюта и позиция символа валюты (перед/после числа)
Число знаков после запятой в ценах

Отдельно — WooCommerce → Настройки → Продукты, там задаётся, показывать ли цены с налогом или без, и сколько товаров выводить на страницу каталога (по умолчанию берётся значение из настроек чтения WordPress, но можно переопределить).

Настройка способов доставки и налогов

Доставка настраивается через зоны доставки (Shipping Zones) — это гибче, чем один способ на весь магазин.

WooCommerce → Настройки → Доставка → Зоны доставки → Добавить зону

Для каждой зоны (например «Россия», «СНГ», «Остальной мир») можно назначить несколько методов:

• Фиксированная стоимость за заказ — самый простой вариант, одна цена доставки независимо от веса/количества.
• Бесплатная доставка — обычно с условием (минимальная сумма заказа или купон).
• Самовывоз — если есть физическая точка выдачи.
• Интеграции с реальными службами (СДЭК, Почта России и т.п.) — через отдельные плагины, в базовый WooCommerce не входят, ставятся дополнительно из каталога плагинов.

Если методов доставки для зоны несколько, покупатель на чекауте выбирает сам — например, «фиксированная 300₽» или «бесплатно от 5000₽».

Налоги включаются отдельным тумблером в WooCommerce → Настройки → Общие → Включить расчёт налогов, после чего появляется вкладка «Налоги» с настройкой ставок по классам товаров и регионам. Для большинства магазинов, работающих по упрощённой системе налогообложения в РФ, эта функция вообще не нужна — цены задаются сразу с учётом всего, и включать модуль налогов смысла нет, он усложнит настройку без пользы. Включайте его только если у вас реально разные ставки НДС/налога на разные категории товаров или разные регионы продаж.

Платёжные методы: что выбрать в 2026 году

Раздел WooCommerce → Настройки → Платежи — здесь выбираются методы оплаты, доступные на чекауте.

Из коробки WooCommerce предлагает:

• Прямой банковский перевод — покупатель переводит деньги вручную по реквизитам, заказ переходит в статус «На удержании» до подтверждения оплаты вами.
• Чек/оплата при получении — для магазинов с самовывозом или курьерской оплатой наличными.

Для реальной онлайн-оплаты картой нужен платёжный шлюз — отдельный плагин, который подключается к процессинговому сервису. Для российского рынка это обычно интеграции с местными эквайрингами (у каждого банка/сервиса свой плагин или API), для зарубежных продаж — Stripe или аналогичные международные шлюзы. Конкретный выбор зависит от того, в какой юрисдикции зарегистрирован магазин и какие платёжные системы доступны там — это не техническая настройка WooCommerce, а вопрос к вашему платёжному провайдеру.

Важный практический момент: всегда тестируйте платёжный метод в режиме песочницы (sandbox) перед запуском, если шлюз его поддерживает. Ошибка в конфигурации API-ключей или webhook-адреса чаще всего проявляется не сразу, а в момент, когда покупатель уже ввёл данные карты — деньги списались, а заказ в WooCommerce не создался, потому что webhook не долетел до сервера (типичная причина — неправильный SSL или закрытый порт в файрволе).

Тут же, в настройках платежей, задаётся порядок методов на чекауте перетаскиванием — имеет смысл поставить самый ожидаемый покупателями метод первым.

Сколько ресурсов реально нужно магазину

Это главное отличие от обычного блога на WordPress, и его часто недооценивают. Магазин на WooCommerce нагружает базу данных сильнее блога того же размера по нескольким причинам:

• Каждый товар — это не одна запись, а набор из самой записи товара, метаданных (цена, артикул, остаток, атрибуты), связей с категориями/тегами и вариациями, если товар вариативный (разные размеры/цвета). Каталог на 500 товаров с вариациями по факту создаёт в базе на порядок больше строк, чем 500 обычных постов блога.
• Каждое посещение каталога и карточки товара — это динамические запросы к базе (наличие, цена, возможно скидка), которые сложнее эффективно кэшировать, чем статичную статью блога.
• Корзина и сессии пользователей — по своей природе не кэшируются, это персональные данные, генерируемые на лету для каждого посетителя.

Ориентировочно (это именно ориентир, не гарантия — у вас может отличаться в зависимости от темы, количества установленных плагинов и посещаемости):

Отдельно закладывайте место под рост базы данных со временем — таблицы wp_postmeta и wp_options в WooCommerce-магазинах имеют тенденцию разрастаться (в частности из-за transient-кэша, если он не чистится). Более подробно про требования по железу для магазина — в статье сколько ресурсов нужно VPS для интернет-магазина.

Если магазин уже работает и стал заметно медленнее в админке при том же трафике — часто дело именно в разросшейся базе, а не в нехватке CPU.

Конфликт WooCommerce с кэширующими плагинами

Это одна из самых частых практических проблем после запуска. Плагины полностраничного кэша (WP Super Cache, W3 Total Cache и подобные) по умолчанию не знают о том, что часть страниц WooCommerce — динамические и персональные для каждого пользователя: корзина, чекаут, страница аккаунта. Если такую страницу закэшировать «как есть», один посетитель может увидеть чужую корзину или устаревшие данные о наличии товара.

Что обычно ломается без правильной настройки:

• Счётчик товаров в корзине не обновляется после добавления товара (показывает закэшированное «0»).
• На чекауте видны неправильные суммы или чужие данные сессии.
• Скидки по купонам не применяются визуально, хотя фактически применены.

Как избежать:

1. Большинство современных кэширующих плагинов (включая WP Super Cache и W3 Total Cache) умеют определять WooCommerce и автоматически исключать динамические страницы из кэша — проверьте, включена ли эта опция в настройках плагина после установки, не полагайтесь на «умолчания».
2. Вручную исключите из кэша URL корзины, чекаута и личного кабинета — обычно это делается по паттерну пути в настройках исключений плагина.
3. Если кэшируете на уровне Nginx, а не только через WordPress-плагин, добавьте эти же страницы в исключения на уровне конфига — иначе плагин WordPress может ничего не знать о том, что перед ним стоит ещё один слой кэша. Общие принципы настройки описаны в статье про кэширование Nginx на VPS.
4. Держите включённым WooCommerce Fragments (это встроенный в WooCommerce механизм AJAX-обновления корзины поверх кэша) — он и существует именно для того, чтобы кэш страницы можно было держать статичным, а «живые» куски (счётчик корзины, итог) подгружать отдельно.

Если после настройки кэша что-то в магазине ведёт себя странно — первое, что стоит проверить, это не баг WooCommerce, а именно конфликт с кэшем: временно отключите кэширующий плагин и посмотрите, воспроизводится ли проблема.

Частые вопросы