Служебные страницы WooCommerce: что проверить перед запуском

Каждый раз, когда я запускаю интернет-магазин на WooCommerce, отдельным пунктом чек-листа идут служебные страницы WooCommerce: магазин, корзина, оформление заказа и личный кабинет. Ошибка в одной из них останавливает продажи в день запуска, а не через месяц, когда её проще заметить и незаметно исправить. Ниже - список того, что я проверяю перед тем, как отдать проект клиенту или включить рекламу.

Какие страницы считаются служебными и где их назначить

При установке WooCommerce автоматически создаёт четыре страницы: Магазин, Корзина, Оформление заказа и Мой аккаунт. Назначаются они в WooCommerce - Настройки - Дополнительно, в блоке «Настройка страниц». Первое, что я делаю на чужом проекте - сверяю, что в этих настройках стоят реальные, а не старые страницы.

Частая история после переноса сайта или смены темы: конструктор вроде Elementor создаёт дубль страницы «Корзина» с собственным шаблоном, а в настройках WooCommerce остаётся ссылка на прежнюю. Внешне всё работает, кнопка «В корзину» кликается, но покупатель попадает не туда, где подключены нужные блоки. Проверяю вручную: открываю каждую из четырёх страниц в браузере и смотрю, что на ней действительно выводится виджет корзины, форма оформления заказа и личный кабинет, а не пустой шаблон страницы.

Страница магазина: каталог, сортировка и карточки товара

На странице магазина смотрю на количество товаров на странице (обычно 12 или 16, чтобы не грузить лишнее), сортировку по умолчанию и доступные варианты - по цене, по популярности, по новизне. Отдельно проверяю карточки товаров без остатка: у части клиентов кнопка «Купить» остаётся активной даже при нулевом складском остатке, если в настройках склада не включено управление количеством.

Если каталог большой, от пары сотен товаров и выше, отдельно тестирую пагинацию и фильтры по атрибутам. На одном проекте после переноса каталога в фильтре по цене долго показывался диапазон из старого кэша транзиентов - товары уже поменялись, а фильтр остался прежним. Помогает пересчёт кэша через WP-CLI командой wp transient delete - expired, но перед запуском проще один раз пройтись по фильтрам руками.

Хлебные крошки и переключение вида каталога (сетка или список, если тема это поддерживает) тоже беру в чек-лист - мелочь, но именно на неё чаще всего жалуются в первую неделю после запуска.

Корзина и оформление заказа: обязательные поля, способы оплаты и эквайринг

В корзине проверяю пересчёт суммы при изменении количества товара, применение и отмену промокодов, и то, что кросс-селлы не тормозят загрузку страницы лишними запросами к базе. Отдельно смотрю, что удаление товара из корзины не оставляет «повисший» промокод, который потом ломает итоговую сумму на оформлении заказа.

На странице оформления заказа проверяю обязательные поля: адрес, телефон в правильном формате, email, и чекбокс согласия на обработку персональных данных - без него принимать оплату юридически нельзя. Если подключена доставка СДЭК, тестирую расчёт стоимости и виджет выбора пункта выдачи по нескольким городам, включая регионы с нестандартной доставкой до склада.

Способы оплаты тестирую в режиме реальных платежей на минимальную сумму, а не только в тестовом режиме плагина. У большинства моих проектов на WooCommerce эквайринг подключён через официальный плагин T‑Bank - там важно проверить, что webhook-уведомления о статусе оплаты долетают до сайта, иначе заказ годами висит в статусе «Ожидает оплаты», даже если деньги уже списались у покупателя. Причина обычно в неправильно настроенном SSL-сертификате или в блокировке запросов от банка на уровне хостинга.

Личный кабинет покупателя: регистрация, история заказов и уведомления

В личном кабинете проверяю регистрацию нового покупателя и восстановление пароля - письмо со ссылкой должно приходить в течение минуты, а не теряться в спаме. Если письма не доходят, обычно дело в том, что сайт отправляет их через стандартную функцию wp_mail без настроенного SMTP: почтовые сервисы такие письма массово режут. Настраиваю отправку через SMTP-сервис или собственный почтовый сервер и проверяю доставку на несколько разных провайдеров - Яндекс, Mail, Gmail.

История заказов должна отображать статус и сумму, а если подключён плагин генерации счетов и накладных - проверяю, что документ реально формируется и скачивается, а не выдаёт ошибку 404 на PDF.

Отдельно смотрю, куда попадают данные покупателей при интеграции с CRM или таблицами. Если в форме заказа собираются ФИО, телефон и адрес, эти данные по 152-ФЗ обязаны храниться на серверах в России, а не в иностранном облачном сервисе, куда их иногда сваливают через n8n или готовый коннектор.

Доставка и юридические страницы перед приёмом оплаты

Банк, который подключает эквайринг, требует ссылку на публичную оферту и политику обработки персональных данных прямо в форме оформления заказа - без них модерация платежей может не пройти. Проверяю, что эти страницы существуют, актуальны и действительно ссылаются на реквизиты продавца, а не остались шаблоном от предыдущего исполнителя.

Зоны доставки тестирую на реальных адресах: если магазин работает по всей России через СДЭК, беру три-четыре региона с разной логикой расчёта, например крупный город, райцентр без ПВЗ и отдалённый регион с удорожанием. Если готовых текстов юридических документов ещё нет или нужно правильно связать их с настройками эквайринга, эту часть обычно выношу в отдельную консультацию по документам и подключению оплаты перед запуском, чтобы не тормозить остальную разработку.

Технические проверки перед запуском: SSL, кэширование и скорость

SSL-сертификат проверяю не только на «зелёный замок» в браузере, но и на срок действия - у одного клиента Let’s Encrypt не продлился автоматически из-за смены хостинга, и через три недели после запуска форма оплаты просто перестала работать.

Кэш-плагины вроде WP Rocket, W3 Total Cache или LiteSpeed Cache по умолчанию кэшируют вообще все страницы сайта, и если не исключить из кэша корзину, оформление заказа и личный кабинет, покупатель может увидеть чужую сумму заказа или устаревший статус. В настройках исключений обычно достаточно указать три пути:

• /cart/ - страница корзины
• /checkout/ - оформление заказа
• /my-account/ - личный кабинет

После этого делаю контрольную покупку в режиме инкогнито с телефона и с десктопа - это единственный способ поймать разницу в поведении мобильной и десктопной версии checkout, которая на скриншотах обычно не видна. Отдельно смотрю скорость загрузки страницы оформления заказа через PageSpeed Insights: она обычно тяжелее остальных из-за скриптов эквайринга и виджета доставки, и часть из них стоит подключать асинхронно.

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

Как назначить страницы WooCommerce после переноса на новый домен?

Иду в WooCommerce - Настройки - Дополнительно - Настройка страниц и проверяю, что для каждого пункта (Магазин, Корзина, Оформление заказа, Мой аккаунт) выбрана актуальная страница на новом домене, а не старая, перенесённая вместе с базой данных по ошибке.

Почему корзина показывает старые товары после оформления заказа?

Обычно это кэширование страницы корзины кэш-плагином или CDN. Нужно добавить /cart/, /checkout/ и /my-account/ в список исключений из кэша - эти страницы должны отдаваться заново при каждом запросе, потому что их содержимое разное для каждого покупателя.

Нужна ли отдельная страница для СДЭК и других способов доставки?

Отдельная страница не нужна - способы доставки подключаются как метод на странице оформления заказа через настройки зон доставки в WooCommerce. Но стоит проверить расчёт стоимости на нескольких реальных адресах перед запуском, а не полагаться на тестовые данные плагина.

Что делать, если оплата через T‑Bank не меняет статус заказа?

В первую очередь проверить, доходит ли webhook-уведомление от банка до сайта - обычно это блокируется файрволом хостинга или неправильным SSL-сертификатом. Если журналы плагина эквайринга показывают ошибку соединения, дело почти всегда в этом.