
🧹 Как удалить плагин WordPress полностью: пошаговая очистка базы и файлов
Сайт начал тормозить, бэкап разросся до гигабайта, а в phpMyAdmin десятки таблиц с префиксами плагинов, которые вы «удалили» год назад. Знакомо?
Стандартная кнопка «Удалить» в разделе плагинов убирает только папку из wp-content/plugins. Всё остальное, таблицы, опции, cron-задачи, шорткоды в постах, остаётся в базе и на диске. Разработчики реализуют очистку по-разному: одни добросовестно подчищают за собой через uninstall.php, другие не трогают ничего.
Ниже, полный алгоритм зачистки плагина без остатка: от панели управления до ручного SQL. С бэкапом на каждом этапе и точными инструкциями для популярных плагинов.
💡 Быстрый обзор:
- Удаление через панель, только первый шаг; таблицы, шорткоды и cron-задачи требуют отдельной зачистки
- Перед любыми манипуляциями с базой, полный бэкап (встроенными средствами хостинга или плагином)
- Для WooCommerce, Yoast SEO, Wordfence и других популярных плагинов есть свои константы и SQL-запросы
- Деактивированный плагин, не «выключенный», а «спящий»; его файлы доступны для прямого обращения и являются вектором атаки
Почему кнопки «Удалить» недостаточно
WordPress при удалении плагина вызывает его uninstall.php или callback из основного файла. Но это срабатывает только если разработчик такой файл создал. На практике примерно половина плагинов из каталога WordPress.org либо не имеют uninstall.php, либо реализуют его частично: удаляют папку, но не трогают базу.
Что остаётся после штатного удаления:
Тип остатка | Где искать | Риск |
|---|---|---|
Таблицы в БД |
| Рост базы, замедление запросов |
Строки в |
| Захламление |
Строки в |
| Мёртвые данные при выборке постов |
Шорткоды в контенте | Текст постов/страниц | Битые |
Cron-задачи |
| Лишние HTTP-запросы к wp-cron |
Файлы вне папки плагина |
| Мусор на диске |
Правила в | Корень сайта | Конфликты с новыми плагинами |
Особенно критичны строки с флагом autoload: WordPress загружает их при каждом запросе. Полсотни лишних autoload-строк добавляют 30-80 мс к ответу сервера. На первый взгляд копейки, но при 100 000 просмотров в месяц это ощутимая просадка.
Деактивация vs удаление: в чём разница
Разница принципиальная, и её полезно понимать до начала зачистки.
Критерий | Деактивация | Полное удаление |
|---|---|---|
Файлы плагина | Остаются в | Удалены |
Код | Не выполняется, доступен для чтения | Отсутствует |
Таблицы БД | Сохранены | Зависит от разработчика |
Настройки | Сохранены | Зависит от |
Обновления | Приходят (для бесплатных с.org) | Не приходят |
Уязвимости | Код на сервере - вектор атаки | Угрозы нет |
Обратимость | Один клик - плагин снова активен | Только из бэкапа |
Деактивированный плагин, не «выключенный», а «спящий». 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 Gallerywp-content/ewww/, EWWW Image Optimizerwp-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 → таблицы). Десять минут сегодня экономят часы завтра, когда раздутая база кладёт сайт на пике трафика.
А какой плагин оставил больше всего мусора после удаления на вашем сайте? Напишите в комментариях.



