Сайт почав гальмувати, бекап розрісся до гігабайта, а в phpMyAdmin десятки таблиць із префіксами плагінів, які ви «видалили» рік тому. Знайомо?

Стандартна кнопка «Видалити» в розділі плагінів прибирає лише папку з wp-content/plugins. Усе інше, таблиці, опції, cron-завдання, шорткоди в постах, залишається в базі та на диску. Розробники реалізують очищення по-різному: одні сумлінно прибирають за собою через uninstall.php, інші не чіпають нічого.

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

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

• Видалення через панель — це лише перший крок; таблиці, шорткоди та cron-завдання потребують окремої зачистки
• Перед будь-якими маніпуляціями з базою, повний бекап (вбудованими засобами хостингу або плагіном)
• Для WooCommerce, Yoast SEO, Wordfence та інших популярних плагінів є свої константи та SQL-запити
• Деактивований плагін — це не «вимкнений», а «сплячий»; його файли доступні для прямого звернення і є вектором атаки

Чому кнопки «Видалити» недостатньо

WordPress під час видалення плагіна викликає його uninstall.php або callback з основного файлу. Але це спрацьовує, лише якщо розробник створив такий файл. На практиці приблизно половина плагінів із каталогу WordPress.org або не мають uninstall.php, або реалізують його частково: видаляють папку, але не чіпають базу.

Що залишається після штатного видалення:

Особливо критичні рядки з прапорцем autoload: WordPress завантажує їх під час кожного запиту. Пів сотні зайвих autoload-рядків додають 30-80 мс до відповіді сервера. На перший погляд, дрібниці, але за 100 000 переглядів на місяць це відчутне просідання.

Деактивація vs видалення: у чому різниця

Різниця принципова, і її корисно розуміти до початку зачистки.

Деактивований плагін — це не «вимкнений», а «сплячий». PHP-файли фізично лежать на сервері. Якщо в коді знайшли вразливість, зловмисник звертається до файлу напряму через шлях у wp-content/plugins/, оминаючи логіку WordPress. WAF-файрволи цю проблему не вирішують: найкращий захист, видалити невикористовуваний код із сервера повністю.

Правило просте: не користуєтеся плагіном більше тижня, видаляйте. Налаштувати заново швидше, ніж розгрібати злам через діру в занедбаному коді.

Покрокове очищення: 4 етапи

Крок 1: Видалення через панель керування

Перший етап, штатний. Зайдіть у Плагіни → Встановлені, знайдіть потрібний. Активні підсвічені синьою смугою, деактивовані, без неї.

Натисніть «Видалити» під назвою, підтвердьте кнопкою «Так, видалити ці файли». WordPress викличе uninstall.php плагіна (якщо він є) і видалить папку з wp-content/plugins.

Для простих плагінів, легкий віджет, заміна логотипа на сторінці входу, на цьому очищення завершено. Вони не створюють таблиць і не пишуть у wp_postmeta. Але плагіни кешування, SEO, безпеки, галерей і конструкторів сторінок потребують продовження.

Крок 2: Зачистка файлів через FTP

Деякі плагіни створюють папки за межами wp-content/plugins/. Типові локації:

• wp-content/uploads/plugin-name/, кеш, стиснуті зображення, експортовані файли
• wp-content/ngg/, NextGEN Gallery
• wp-content/ewww/, EWWW Image Optimizer
• wp-content/backup/, плагіни бекапів

Підключіться до сервера через FTP (FileZilla, WinSCP) або файловий менеджер хостингу. Перейдіть у wp-content/, знайдіть папку з назвою плагіна та видаліть її. Перед видаленням завантажте папку локально, якщо в ній були користувацькі завантаження, відновіть їх.

Плагіни кешування (WP Rocket, W3 Total Cache, LiteSpeed Cache) додатково пишуть у wp-content/cache/ і створюють wp-content/advanced-cache.php. Файл advanced-cache.php видаліть вручну через FTP, а в wp-config.php знайдіть і видаліть рядок:

1
define('WP_CACHE', true);

Крок 3: Видалення шорткодів із контенту

Плагіни, що додають шорткоди (форми, галереї, слайдери, таблиці), після видалення залишають голі [shortcode] у тексті постів. Виглядає неохайно і збиває читача.

Швидкий спосіб заглушити невикористовувані шорткоди, один рядок у functions.php активної теми:

1
add_shortcode('pluginshortcode', '__return_false');

Замініть pluginshortcode на тег вашого шорткоду. Наприклад: nggallery, gravityform або contact-form-7. Функція __return_false повертає false, і шорткод зникає з фронту без видалення з тексту постів.

Код додавайте через дочірню тему або плагін Code Snippets, правки у functions.php батьківської теми злетять під час наступного оновлення. Якщо вирішите повернути плагін пізніше, просто видаліть цей рядок.

Крок 4: Очищення бази даних

Найвідповідальніший етап. Робіть повний бекап бази перед будь-яким SQL-запитом на видалення, експорт через phpMyAdmin займає пів хвилини і рятує від незворотних помилок.

4a. Знайдіть таблиці плагіна. Зайдіть у phpMyAdmin (через cPanel або адмінку хостингу), виберіть базу даних сайту. Шукайте таблиці з префіксом плагіна: wp_wc_* (WooCommerce), wp_yoast_* (Yoast SEO), wp_wf* (Wordfence). Позначте їх, унизу виберіть «Drop» → підтвердьте.

4b. Автоматизація через Advanced Database Cleaner. Якщо не хочете працювати в phpMyAdmin напряму, встановіть Advanced Database Cleaner. Безплатний плагін сканує базу, знаходить осиротілі таблиці та записи, видаляє їх в один клік.

4c. Очистіть wp_options. Навіть якщо плагін не створював окремих таблиць, він майже напевно писав у wp_options. Виконайте в phpMyAdmin (вкладка SQL):

1
SELECT * FROM wp_options WHERE option_name LIKE '%pluginname%';

Замініть pluginname на частину назви плагіна. Переконайтеся, що рядки справді стосуються видаленого плагіна, потім:

1
DELETE FROM wp_options WHERE option_name LIKE '%pluginname%';

4d. Очистіть cron-завдання. Деякі плагіни реєструють власні cron-події. Встановіть WP Crontrol, він показує всі зареєстровані cron-завдання в одному списку. Знайдіть події з назвою плагіна та видаліть їх вручну.

Особливості видалення популярних плагінів

Кожен великий плагін залишає унікальний слід. Нижче наведено точні інструкції для найпоширеніших.

WooCommerce

WooCommerce створює 16+ таблиць у базі. Щоб під час видалення вони підчистилися автоматично, додайте в wp-config.php (до рядка /* That's all, stop editing! */):

1
define('WC_REMOVE_ALL_DATA', true);

Константа змушує WooCommerce викликати повний uninstall.php під час видалення, буде видалено всі таблиці wp_woocommerce_* і wp_wc_*, включно з товарами, замовленнями та купонами. Операція незворотна, тому бекап обов’язковий.

Після видалення плагіна додатково перевірте wp_options, WooCommerce записує туди десятки рядків із префіксом woocommerce_:

1
SELECT * FROM wp_options WHERE option_name LIKE '%wc_%';

Якщо рядки знайшлися і плагін уже видалено, виконуйте DELETE-запит із тією самою умовою.

Yoast SEO

Yoast SEO залишає записи в wp_postmeta і wp_usermeta, а також власні таблиці wp_yoast_indexable та wp_yoast_seo_links.

Спочатку очистіть wp_postmeta:

1
SELECT * FROM wp_postmeta WHERE meta_key LIKE '%yoast%';

Переконавшись, що це дані Yoast, виконайте:

1
DELETE FROM wp_postmeta WHERE meta_key LIKE '%yoast%';

Потім wp_usermeta:

1
SELECT * FROM wp_usermeta WHERE meta_key LIKE '%yoast%';

Видаліть знайдене аналогічним DELETE-запитом. Yoast також реєструє cron-подію wpseo_onpage_fetch, видаліть її через WP Crontrol. Таблиці wp_yoast_indexable і wp_yoast_seo_links дропніть вручну через phpMyAdmin.

Akismet

Akismet, стандартний плагін захисту від спаму в коментарях, встановлений із WordPress за замовчуванням. Після видалення його дані залишаються в wp_commentmeta:

1
SELECT * FROM wp_commentmeta WHERE meta_key LIKE '%akismet_%';

Потім:

1
DELETE FROM wp_commentmeta WHERE meta_key LIKE '%akismet_%';

Якщо на сайті тисячі коментарів, wp_commentmeta може важити десятки мегабайтів. Після очищення оптимізуйте таблицю:

1
OPTIMIZE TABLE wp_commentmeta;

Більше способів боротьби зі спамом, у нашому матеріалі як зупинити спам у коментарях WordPress: усі 18 рішень.

Gravity Forms

Gravity Forms створює 9 таблиць у базі (wp_gf_*, wp_rg_*). Перед видаленням зайдіть у Forms → Settings → Uninstall і підтвердьте. Потім видаліть плагін з панелі керування.

Після видалення перевірте wp_options:

1
SELECT * FROM wp_options WHERE option_name LIKE '%gravity%' OR option_name LIKE '%gf_%';

Знайдені рядки видаліть аналогічним DELETE-запитом.

Wordfence

Wordfence, один із найважчих плагінів безпеки: він створює 23 таблиці з префіксом wp_wf*. Штатне видалення через панель не очищає їх.

Офіційний плагін-помічник Wordfence Assistant закритий розробником у грудні 2025 року. Тому чистимо вручну: видаліть основний плагін Wordfence через панель, потім зайдіть у phpMyAdmin і виконайте:

1
SELECT * FROM wp_options WHERE option_name LIKE '%wordfence%' OR option_name LIKE '%wf%';

Видаліть знайдені рядки DELETE-запитом із тією самою умовою. Потім знайдіть і дропніть усі таблиці з префіксом wp_wf, їх зазвичай 23 штуки, від wp_wfblockediplog до wp_wflivetraffichuman. Через FTP видаліть папку wp-content/wflogs/ і файл wordfence-waf.php у корені сайту, якщо вони залишилися.

NextGEN Gallery

Плагін створює 3 таблиці (wp_ngg_*) і папку wp-content/ngg/ із завантаженими галереями.

Спочатку видаліть плагін через панель керування. Потім через FTP видаліть папку wp-content/ngg/, попередньо зберігши зображення галерей, якщо вони потрібні. У phpMyAdmin виконайте:

1
SELECT * FROM wp_options WHERE option_name LIKE '%ngg%';

Видаліть знайдені рядки через DELETE-запит із тією самою умовою. Таблиці wp_ngg_pictures, wp_ngg_galleries і wp_ngg_album дропніть вручну.

EWWW Image Optimizer

EWWW зберігає дані про кожне оптимізоване зображення в таблиці wp_ewwwio_images: шлях до файлу, початковий розмір, розмір після стиснення. Також створює папку wp-content/ewww/ із кешем.

Видаліть папку через FTP. Потім у phpMyAdmin:

1
SELECT * FROM wp_options WHERE option_name LIKE '%ewww%';

Видаліть знайдене та дропніть таблицю wp_ewwwio_images.

WP All Export

Плагін створює 4 таблиці в базі. Після видалення через панель керування зайдіть у phpMyAdmin, знайдіть таблиці з префіксом wp_pmxe_*, позначте їх і виконайте «Drop». Додатково перевірте wp_options за ключем pmxe, плагін зберігає там налаштування останнього експорту.

Докладніше про повний цикл видалення плагінів, у відеоінструкції нижче.

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

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

Безпечно за двох умов: ви зробили повний бекап бази та точно ідентифікували таблиці як такі, що належать уже видаленому плагіну. Таблиці сторонніх плагінів завжди мають упізнаваний префікс: wp_wc_, wp_yoast_ або wp_wf. Системні таблиці WordPress (wp_posts, wp_options, wp_users, wp_comments, wp_postmeta та wp_usermeta) не чіпайте DROP-ом, їх можна чистити лише вибірковими DELETE.

Що робити, якщо після видалення плагіна сайт упав у білу сторінку?

Відновіть плагін із бекапу: залийте папку через FTP, імпортуйте його таблиці. Причина, найімовірніше, у functions.php теми, там міг залишитися виклик функції плагіна без fallback-у. Знайдіть і обгорніть такі виклики в function_exists() або видаліть їх, потім повторіть видалення плагіна.

Як знайти всі сліди плагіна в базі даних?

Встановіть плагін Advanced Database Cleaner. Він сканує всі таблиці на предмет осиротілих даних і показує повний список: таблиці, рядки в wp_options і wp_postmeta, cron-завдання. Це швидше й безпечніше, ніж ручний пошук через phpMyAdmin.

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

Так, якщо ви їх не використовуєте. Плагіни у складі тем, WPBakery Page Builder, Slider Revolution, ACF Pro, часто йдуть з обмеженою ліцензією, і оновлення безпеки для них не надходять. Деактивований застарілий WPBakery з відомою вразливістю — це прямий шлях до зламу. Не використовуєте, видаляйте.

Чи можна відновити плагін після повного видалення?

Тільки з бекапу. Після зачистки таблиць і wp_options усі налаштування плагіна втрачені безповоротно. Саме тому алгоритм вище побудований від простого до радикального: спочатку штатне видалення (оборотне), потім зачистка файлів, і лише в кінці, база даних. Проходьте етапи послідовно, не стрибайте одразу до phpMyAdmin.

Чи залишилися дані плагіна в WordPress Multisite?

У Multisite кожен підсайт має власні таблиці: wp_2_options, wp_2_postmeta і так далі. Після видалення плагіна через суперадміна перевірте таблиці кожного підсайта, wp_*_options і wp_*_postmeta для всіх ID блогів. Плагін міг бути активований на окремих сайтах мережі й залишити записи в їхніх таблицях.

Підсумки: коли повна зачистка виправдана

Якщо у вас невеликий сайт і ви видаляєте плагін раз на пів року, штатного видалення через панель і разової чистки wp_options достатньо.

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

Візьміть за звичку: видалили плагін, пробіжіться чек-листом (FTP → wp_options → cron → таблиці). Десять хвилин сьогодні заощаджують години завтра, коли роздута база кладе сайт на піку трафіку.

А який плагін залишив найбільше сміття після видалення на вашому сайті? Напишіть у коментарях.