Ви заходите в адмінку WooCommerce і бачите: три тисячі товарів, половина, дублі з кривого імпорту, атрибути «Колір 1», «Колір 2», «Розмір_copy_2023». Інтерфейс «Товари → вибрати все → Видалити» зависає на другій сотні. Знайомо? Масове очищення каталогу, задача, з якою стикається кожен, хто пробував мігрувати магазин, зливати тестову базу з бойовою чи перезапускати вітрину після ребрендингу.

Проблема впирається в будову WooCommerce: продукти розкидані по чотирьох таблицях, wp_posts, wp_postmeta, wp_term_relationships і wp_term_taxonomy, а атрибути зберігаються ще в трьох. Просто клацнути «Видалити все» не вийде, рушій впаде раніше, ніж дійде до кінця списку. Потрібен інструмент, який б’є в обхід інтерфейсу, напряму в базу або через CLI.

Нижче, три робочі способи, від радикального SQL до безпечних плагінів. З бекапом, із перевіркою префіксів і з розумінням, що саме відбувається в кожній таблиці.

💡 Швидкий огляд:

• Зробіть повний дамп бази, DELETE незворотний, кошика немає
• Перевірте префікс таблиць у wp-config.php і підставте його замість wp_
• Виконайте SQL-команди каскадно: атрибути → продукти → осиротіла постмета
• Якщо є SSH, WP-CLI впорається однією командою і викличе потрібні хуки
• Для продакшен-магазину без досвіду SQL плагіни з кнопкою «Видалити» безпечніші

Запобіжні заходи: бекап і префікс

Будь-яка SQL-команда, що змінює вміст таблиць WordPress, незворотна. DELETE не запитує підтвердження, не кладе запис у кошик, рядок зникає миттєво і назавжди. Правило номер один: зробіть повний бекап бази до того, як запустите будь-який із запитів нижче.

Найнадійніше, вивантажити дамп через phpMyAdmin: вкладка «Експорт» → формат SQL → стиснути gzip. Або через панель хостингу (cPanel → Backup → Database). Для тих, хто працює з командного рядка:

1
mysqldump -u username -p database_name > backup_$(date +%Y%m%d).sql

Другий момент: усі запити нижче використовують стандартний префікс wp_. Якщо під час встановлення WordPress ви змінювали префікс на wpx_, store_ або будь-який інший, замініть wp_ в усіх командах на свій. Реальний префікс лежить у wp-config.php, рядок $table_prefix. Перевірили? Тепер до справи.

Спосіб 1: SQL-команди в phpMyAdmin, повний контроль

Найшвидший і найрадикальніший метод. Підходить, коли потрібно вичистити сотні або тисячі записів за один прохід, а стандартний інтерфейс WooCommerce падає по таймауту. Усі запити виконуються в phpMyAdmin на вкладці «SQL», по одному, у суворій послідовності.

Видалення атрибутів WooCommerce

Атрибути живуть одразу в трьох таблицях: wp_terms, wp_term_taxonomy і wp_term_relationships. Від звичайних категорій і тегів вони відрізняються префіксом pa_ у полі taxonomy, скорочення від «product attribute». Видаляти потрібно каскадно, починаючи з термів і закінчуючи зв’язками:

1
DELETE FROM wp_terms WHERE term_id IN
2
(SELECT term_id FROM wp_term_taxonomy WHERE taxonomy LIKE 'pa_%');
3
 
4
DELETE FROM wp_term_taxonomy WHERE taxonomy LIKE 'pa_%';
5
 
6
DELETE FROM wp_term_relationships WHERE term_taxonomy_id NOT IN
7
(SELECT term_taxonomy_id FROM wp_term_taxonomy);

Перший запит видаляє назви атрибутів із wp_terms. Другий, їхні таксономічні записи з wp_term_taxonomy. Третій підчищає осиротілі зв’язки «терм-об’єкт» із wp_term_relationships, які залишилися без батьківської таксономії. Порядок важливий: якщо видалити таксономію раніше за терми, третій запит зачепить зайве.

Видалення продуктів WooCommerce

Продукти та їхні варіації — це записи з типом product і product_variation у таблиці wp_posts. Але просто стерти рядки з wp_posts недостатньо: залишаться метадані в wp_postmeta (ціна, артикул, налаштування доставки) і зв’язки з термами в wp_term_relationships (категорії, теги). Три запити, каскад:

1
DELETE FROM wp_term_relationships WHERE object_id IN
2
(SELECT ID FROM wp_posts WHERE post_type IN ('product','product_variation'));
3
 
4
DELETE FROM wp_postmeta WHERE post_id IN
5
(SELECT ID FROM wp_posts WHERE post_type IN ('product','product_variation'));
6
 
7
DELETE FROM wp_posts WHERE post_type IN ('product','product_variation');

Спочатку рвемо зв’язки продукту з таксономіями, потім видаляємо метадані і тільки потім, сам запис продукту. Якщо переставити порядок і грохнути wp_posts першим, підзапити SELECT ID FROM wp_posts на другому і третьому кроці повернуть порожній набір, метадані та зв’язки залишаться мертвим вантажем у базі.

Очищення осиротілої постмети

Після будь-яких маніпуляцій із видаленням записів через SQL варто перевірити, чи не залишилося в wp_postmeta рядків, що посилаються на неіснуючі пости. Таке буває при обриві транзакції, кривому імпорті або якщо видаляли пости не каскадно:

1
DELETE pm
2
FROM wp_postmeta pm
3
LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
4
WHERE wp.ID IS NULL;

Запит знаходить усі рядки wp_postmeta, для яких немає батьківського запису в wp_posts, і видаляє їх. Безпечний, живі дані не чіпає, зачіпає тільки сміття.

Спосіб 2: WP-CLI, швидко і без phpMyAdmin

Якщо є доступ до сервера по SSH, WP-CLI справляється з масовим видаленням елегантніше за будь-які SQL-запити. Одна команда, і WooCommerce сам проходить по пов’язаних таблицях, не залишаючи осиротілих даних:

1
wp wc product delete $(wp wc product list --field=ID --per_page=-1) --force

Прапор --per_page=-1 вивантажує ID взагалі всіх продуктів, без пагінації. --force пропускає кошик і видаляє назавжди. Якщо продуктів більше 10 000, краще розбити на порції по 500, щоб не впертися в ліміт пам’яті:

1
wp wc product list --field=ID --per_page=500 --page=1 | xargs wp wc product delete --force

Для видалення атрибутів через WP-CLI використовуйте:

1
wp wc product_attribute list --field=id --per_page=-1 | xargs -I{} wp wc product_attribute delete {} --force

Головний плюс WP-CLI перед голим SQL: він викликає внутрішні хуки WooCommerce, before_delete_post та after_delete_post. Це дає плагінам кешування та пошуку (Elasticsearch, Redis, Relevanssi) шанс підчистити свої індекси. SQL-запити цього не роблять, після них пошук може якийсь час повертати вже видалені товари.

Спосіб 3: плагіни, коли не хочеться лізти в базу

Тим, кому командний рядок і phpMyAdmin здаються ризикованими, ринок пропонує спеціалізовані плагіни. Працюють поверх тих самих SQL-запитів, але ховають їх за кнопкою.

Delete All Products for WooCommerce, безплатний плагін з офіційного репозиторію WordPress.org. Додає в адмінку одну кнопку. Натиснув → вибрав «у кошик» або «назавжди» → підтвердив. Мінімум рухів, нульовий ризик помилки в SQL. Мінус: працює лише з товарами, атрибути не чіпає.

WooCommerce Store Toolkit (він же Store Toolkit for WooCommerce), варіант серйозніший. Чистить не лише товари й атрибути, а й замовлення, купони, сесії, транзієнти, з фільтрами за датою та статусом. Підходить для повного генерального прибирання магазину перед перезапуском.

Який би плагін ви не обрали, правило бекапу ніхто не скасовував. Плагін виконує ті самі DELETE-запити, просто ви не бачите їх в обличчя.

Порівняння методів: що і коли обирати

Якщо у вас один товар чи десяток, інтерфейс WooCommerce «Товари → вибрати → Видалити» впорається. Сотні й тисячі, SQL або WP-CLI. Бойовий продакшн-магазин, де немає права на помилку,, плагін або WP-CLI.

Важливі обмеження: що НЕ видаляється

Масове видалення товарів та атрибутів через SQL не чіпає медіафайли. Зображення товарів, завантажені в бібліотеку WordPress (записи з post_type = 'attachment'), залишаються на місці, і у файловій системі, і в базі. Якщо ви перестворюєте каталог з нуля і хочете звільнити місце на хостингу, медіафайли доведеться чистити окремо: через «Медіафайли → вибрати → Видалити назавжди» або WP-CLI:

1
wp post delete $(wp post list --post_type=attachment --field=ID --per_page=-1) --force

SQL-команди також не оновлюють лічильники WooCommerce (product counts by category), які кешуються в wp_termmeta та wp_options, транзієнти з префіксом _wc_term_counts_. Після масового видалення в адмінці може тимчасово відображатися неправильна кількість товарів у категорії. Виправляється перерахунком:

1
wp wc tool run recount_terms

Або через однойменний плагін Recount Terms з репозиторію.

На відео, покроковий розбір SQL-команд для видалення атрибутів WooCommerce у phpMyAdmin: навігація таблицями та перевірка результату після кожного запиту.

⁉️🤔 Часті запитання

Чи безпечно видаляти продукти через SQL на працюючому магазині?

На production-магазині прямий SQL для масового видалення, ризикована практика. Одна помилка в назві таблиці або умові WHERE може зачепити замовлення, користувачів або налаштування. Якщо магазин живий і приносить гроші, використовуйте WP-CLI або плагіни, які не дадуть вистрілити собі в ногу. SQL залиште для dev-оточень, стейджингу та ситуацій, коли інтерфейс адмінки вже не завантажується.

Чому після SQL-видалення продукти все ще видно в пошуку на сайті?

Пошукові плагіни, Relevanssi, Elasticsearch, SearchWP, зберігають власний індекс, який не оновлюється під час прямих маніпуляцій із wp_posts в обхід WordPress API. Після чистки через SQL потрібно перебудувати індекс пошуку в налаштуваннях плагіна або через WP-CLI: наприклад, wp relevanssi index --reindex.

Як видалити продукти лише певної категорії, а не всі підряд?

Додайте фільтр за term_taxonomy_id потрібної категорії. Схема: отримати term_id категорії → знайти term_taxonomy_id у wp_term_taxonomy → відфільтрувати object_id у wp_term_relationships перед видаленням із wp_posts. На практиці простіше використовувати WP-CLI: wp wc product list --category=slug-kategorii --field=ID | xargs wp wc product delete --force.

Чи можна відновити продукти після SQL-видалення?

Тільки з бекапу. На відміну від видалення через кошик WordPress (Move to Trash), SQL-команда DELETE стирає рядки фізично та безповоротно. Саме тому правило «спочатку бекап» повторюється в кожному розділі цієї статті. Дві хвилини на дамп зекономлять години на відновлення.

Чим відрізняється видалення атрибутів від видалення варіацій?

Варіації — це підтип продуктів (product_variation). Вони видаляються тими самими SQL-командами, що й прості продукти: умова post_type IN ('product','product_variation') у другому блоці «Способу 1» вже включає варіації. Атрибути (pa_цвет, pa_размер) — це таксономії, вони видаляються окремо, першим блоком SQL-команд. Порядок коректний: спочатку продукти (включно з варіаціями), потім атрибути. Якщо навпаки, варіації втратять прив’язку до атрибутів, але самі записи варіацій залишаться в базі.

Що ставити у 2026 році: підсумковий розклад

SQL-команди, WP-CLI та плагіни, три інструменти різного ступеня небезпеки для одного завдання. Вибір зводиться до простої матриці:

• Є SSH і досвід командного рядка → WP-CLI (wp wc product delete). Безпечно, швидко, з хуками.
• Немає SSH, але є phpMyAdmin і ви розумієте схему таблиць → SQL. Повний контроль, миттєвий результат. Але спочатку бекап.
• Не хочете ризику → Delete All Products або Store Toolkit. Повільніше, зате кнопка замість SQL-запиту.

У будь-якому сценарії бекап бази даних, дія номер один. Без нього не починайте.

🔗 Delete All Products for WooCommerce, безкоштовно на WordPress.org🔗 WooCommerce Store Toolkit, розширене очищення магазину