Не обновляются остатки товаров в WooCommerce: причины и как исправить
В WooCommerce остаток может выглядеть простой цифрой: было 5 товаров, один купили — должно стать 4. На практике между заказом и числом «4» работают настройки склада, статус заказа, резервирование, вариации, платёжный сценарий, кэш и иногда внешняя система учёта. Поэтому ошибка «остатки не обновляются» — это не одна поломка, а несколько разных сценариев с похожим симптомом.
Коротко: что делать сейчас. Сначала проверьте один конкретный товар и один тестовый заказ. Не начинайте с массового пересчёта базы, SQL-запросов и отключения половины магазина. В складском учёте особенно полезен принцип: сначала найти место, где расходятся данные, и только потом что-либо исправлять.
Как понять, где именно сломался учёт остатков
Откройте товар в админке и запишите его текущий остаток. Затем оформите тестовый заказ на одну единицу и посмотрите одновременно на три вещи: новый остаток товара, статус заказа и примечания заказа. Если товар вариативный, проверяйте именно купленную вариацию, а не только родительский товар.
WooCommerce умеет вести количественный склад только при включённом управлении запасами. В общих настройках WooCommerce → Настройки → Товары → Запасы должна быть включена опция управления запасами. На уровне товара также нужно проверить «Управлять запасами», количество, разрешение предзаказов и статус наличия.
Если видите это — вероятнее всего… Количество заполнено, но после покупки вообще не меняется — сначала проверяйте управление запасами и жизненный цикл заказа. В админке число правильное, а покупатель видит старое — подозрение уже смещается к кэшу, шаблону или внешней синхронизации.
1. Управление запасами отключено
Это самая безопасная проверка и одна из самых частых причин. Если глобальное управление запасами выключено, WooCommerce может хранить только состояние «в наличии», «нет в наличии» или «предзаказ», но не вести полноценное уменьшение количества.
У вариативного товара возможны два подхода: запас контролируется на уровне отдельных вариаций либо используется логика родительского товара. Поэтому ситуация «у товара 10 штук, а красный размер M всё равно недоступен» не обязательно означает повреждение базы. Проверьте настройки конкретной вариации.
Если проблема возникает именно при выборе размера или цвета, сначала полезнее пройти отдельную диагностику неработающих вариаций WooCommerce, чтобы не смешивать две разные причины.
2. Остаток зависит от статуса и истории заказа
Остаток нельзя диагностировать только по финальному статусу заказа. Важно понять, уменьшался ли он раньше и должен ли затем восстановиться. Например, неоплаченный заказ может временно удерживать товар, а отмена или неудачная оплата — возвращать его в доступный запас в зависимости от сценария.
Здесь особенно важна версия WooCommerce. Начиная с WooCommerce 11.0 изменена обработка заказов со статусом failed: если такой заказ ранее уменьшил запас, WooCommerce автоматически восстанавливает его. Поэтому старые инструкции из интернета, советующие вручную прибавлять товар после каждого failed-заказа, могут привести уже к обратной проблеме — двойному возврату остатков.
Быстрая проверка. Откройте заказ → примечания. Сопоставьте время изменения статуса с изменением количества товара. Если есть платёжный шлюз, проверьте его журнал за тот же период. Так можно отличить ошибку склада от ошибки платёжного сценария. Если проблема начинается после неудачной транзакции, используйте также инструкцию о том, почему не проходит оплата в WooCommerce.
3. Неправильно настроено резервирование товара
В настройках запасов WooCommerce есть параметр удержания товара для неоплаченных заказов. Он определяет, сколько минут запас может резервироваться за заказом в ожидании оплаты. После истечения периода pending-заказ отменяется, а удержанный товар освобождается.
Если магазин принимает способы оплаты с задержкой, слишком короткий период может создавать путаницу. Слишком длинный — визуально «замораживать» доступный товар. Здесь нет универсального числа: настройка должна соответствовать реальному времени оплаты в вашем магазине.
4. У вариации свой остаток
Для футболки «чёрная / M» и «чёрная / L» WooCommerce может хранить разные количества. Владелец магазина смотрит на родительский товар, покупатель — на конкретную вариацию, и кажется, что система показывает разные данные. На самом деле сравниваются разные сущности.
Проверьте у проблемной вариации: включено ли управление запасами, какое количество записано, разрешены ли предзаказы и совпадает ли SKU с данными внешней системы. Особенно внимательно смотрите импортированные товары: интеграция может обновлять родителя, хотя продаваться должны дочерние вариации.
5. Остаток изменился в базе, но на сайте показывается старое значение
Это уже другая ветка диагностики. Если в редакторе товара стоит «7», а карточка магазина продолжает показывать «8» или «нет в наличии», повторно менять склад не нужно. Проверьте страницу в приватном окне, затем очистите page cache/CDN и объектный кэш, если он используется.
Elementor получает данные WooCommerce динамически, в том числе stock. Поэтому при шаблоне Single Product убедитесь, что выводится динамическое значение товара, а не вручную введённый текст. Кэш способен сохранить старую HTML-версию страницы даже после корректного изменения данных.
Не делайте так: не отключайте кэш магазина навсегда только потому, что после очистки остаток стал правильным. Это диагностический сигнал. Нужно выяснить, какой слой не инвалидирует данные, а не отказываться от кэширования целиком.
6. Остатки перезаписывает 1С, CRM, склад или импорт
Если количество вручную меняется с 5 на 4, а через несколько минут снова становится 5, WooCommerce, скорее всего, не «забывает» изменение. Кто-то записывает старое значение повторно. Проверяйте обмен с 1С, ERP/CRM, фиды, импорт CSV/XML, REST API, вебхуки и плагины синхронизации.
Хороший диагностический эксперимент: изменить один тестовый SKU и записать точное время. Если значение возвращается через стабильный интервал, ищите плановую задачу или внешний обмен. Если возвращается сразу после определённого действия — проверяйте хук или запрос, связанный с этим действием.
Для бизнеса это важнее косметической ошибки. Неверный остаток способен пройти цепочку из нескольких уровней: покупатель видит ложное наличие → оформляет заказ → менеджер обнаруживает дефицит → заказ приходится менять или отменять → магазин теряет доверие и деньги. Поэтому «просто поставить правильную цифру» недостаточно, если источник повторной записи остаётся.
7. После обновления WooCommerce остатки ведут себя странно
Не списывайте любое совпадение по времени на «несовместимость WooCommerce», но учитывайте реальные регрессии. В 2026 году в официальном репозитории WooCommerce исправлялись ошибки управления запасами, включая Quick Edit и опасный сценарий, при котором изменение stock из блока Low Stock на главной WooCommerce могло преобразовать вариативный товар в простой и удалить его вариации.
Поэтому после обновления сначала воспроизведите проблему на одном тестовом товаре и проверьте changelog/Issues для установленной версии. Если сбой начался одновременно с обновлением плагина и сопровождается PHP-ошибками, пригодится алгоритм диагностики критической ошибки после обновления плагина.
8. Проверьте логи, прежде чем менять базу данных
В WooCommerce откройте Статус → Журналы и найдите записи, совпадающие по времени с проблемным заказом или синхронизацией. Полезны логи платёжного шлюза, интеграции и fatal errors.
Для более глубокой проверки WordPress допускает логирование через WP_DEBUG и WP_DEBUG_LOG. На рабочем сайте ошибки не следует выводить посетителям. Диагностику лучше проводить на staging или на ограниченном временном интервале, а журнал после проверки отключить и защитить от публичного доступа.
Если вместо ошибки склада вы получаете HTTP 500, используйте отдельный алгоритм — как найти причину ошибки 500 в WordPress. Это уже серверная ветка диагностики.
9. Почему неверные остатки вредят не только продажам, но и SEO
Наличие товара входит в ecommerce-данные, которые Google может получать со страницы, из Product structured data и Merchant Center. Если сайт говорит «в наличии», а фид — «нет в наличии», возникает рассинхронизация. Google прямо рекомендует поддерживать актуальность товарных данных и для часто меняющихся каталогов использовать регулярные обновления фида или API.
Универсальный принцип здесь простой: у магазина должен быть понятный источник истины для остатка. Если WooCommerce, ERP, маркетплейс и импорт одновременно считают себя главным складом, рано или поздно данные начинают спорить друг с другом — а покупатель оказывается арбитром, которого никто не приглашал.
Когда пора остановиться
Безопасно самостоятельно проверить настройки запасов, товар, вариации, статусы заказов, примечания, кэш и журналы. Остановитесь, если для продолжения нужно вручную изменять post meta/таблицы базы, массово пересчитывать остатки, править обработчики заказов, отключать production-интеграцию или экспериментировать с уже оплачиваемыми заказами.
Перед такими действиями нужна резервная копия и желательно staging. Ошибка в складской логике редко ограничивается одной красивой цифрой: она может затронуть реальные заказы и финансовый учёт.
FAQ
Почему WooCommerce не уменьшает остаток после заказа?
Проверьте, включено ли управление запасами глобально и у товара, какой статус получил заказ и не управляет ли остатком конкретная вариация или внешняя интеграция.
Почему товар показывает «нет в наличии», хотя количество больше нуля?
Проверьте stock status, настройки вариации, предзаказы и кэш. Если в админке данные правильные, а на витрине старые, вероятна проблема отображения или кэширования.
Почему остаток сам возвращается к старому значению?
Частая причина — внешний обмен: 1С, CRM/ERP, импорт, REST API или плагин синхронизации повторно записывает старые данные. Сопоставьте время изменения с расписанием обмена.
Нужно ли вручную возвращать остаток после failed-заказа?
Не спешите. В WooCommerce 11.0 изменена логика: если failed-заказ ранее уменьшил запас, WooCommerce способен восстановить его автоматически. Сначала проверьте историю заказа и фактическое изменение количества.
Можно ли исправить остатки напрямую в базе данных?
Технически данные можно менять напрямую, но на рабочем магазине это плохой первый шаг. Вы можете исправить число, не устранив причину, нарушить связанные данные или получить повторную перезапись.
Остатки продолжают расходиться?
Если диагностика упирается в базу данных, обработку заказов, платёжный сценарий или синхронизацию со складской системой, разумнее остановить эксперименты на рабочем магазине. Ошибка может затронуть оплаченные заказы и реальные товарные остатки. Можно обратиться за платной диагностикой — сначала найду источник расхождения, затем предложу безопасное исправление.






