Skip to content

Всё для WordPress, веб-разработки — и не только

🧹 Как удалить плагин WordPress полностью: пошаговая очистка базы и файлов

🧹 Как удалить плагин WordPress полностью: пошаговая очистка базы и файлов

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

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

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

💡 Быстрый обзор:

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

Почему кнопки «Удалить» недостаточно

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

Что остаётся после штатного удаления:

Тип остатка

Где искать

Риск

Таблицы в БД

wp_* (префикс плагина)

Рост базы, замедление запросов

Строки в wp_options

option_name LIKE %pluginname%

Захламление autoload-опций

Строки в wp_postmeta

meta_key LIKE %pluginname%

Мёртвые данные при выборке постов

Шорткоды в контенте

Текст постов/страниц

Битые [shortcode] на фронте

Cron-задачи

wp_optionscron

Лишние HTTP-запросы к wp-cron

Файлы вне папки плагина

wp-content/uploads/

Мусор на диске

Правила в .htaccess

Корень сайта

Конфликты с новыми плагинами

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

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

Разница принципиальная, и её полезно понимать до начала зачистки.

Критерий

Деактивация

Полное удаление

Файлы плагина

Остаются в wp-content/plugins/

Удалены

Код

Не выполняется, доступен для чтения

Отсутствует

Таблицы БД

Сохранены

Зависит от разработчика

Настройки

Сохранены

Зависит от uninstall.php

Обновления

Приходят (для бесплатных с.org)

Не приходят

Уязвимости

Код на сервере - вектор атаки

Угрозы нет

Обратимость

Один клик - плагин снова активен

Только из бэкапа

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

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

Пошаговая очистка: 4 этапа

Шаг 1: Удаление через панель управления

Первый этап, штатный. Зайдите в Плагины → Установленные, найдите нужный. Активные подсвечены синей полосой, деактивированные, без неё.

Нажмите «Удалить» под названием, подтвердите кнопкой «Да, удалить эти файлы». WordPress вызовет uninstall.php плагина (если он есть) и удалит папку из wp-content/plugins.

Список плагинов WordPress с кнопкой удаления

Для простых плагинов, лёгкий виджет, замена логотипа на странице входа, на этом очистка завершена. Они не создают таблиц и не пишут в 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 найдите и удалите строку:

1define('WP_CACHE', true);

Шаг 3: Удаление шорткодов из контента

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

Быстрый способ заглушить неиспользуемые шорткоды, одна строка в functions.php активной темы:

1add_shortcode('pluginshortcode', '__return_false');
Код в functions.php для отключения шорткода плагина

Замените 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):

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

Замените pluginname на часть названия плагина. Убедитесь, что строки действительно относятся к удалённому плагину, затем:

1DELETE 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! */):

1define('WC_REMOVE_ALL_DATA', true);

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

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

1SELECT * FROM wp_options WHERE option_name LIKE '%wc_%';
SQL запрос для поиска записей WooCommerce в базе данных

Если строки нашлись и плагин уже удалён, выполняйте DELETE-запрос с тем же условием.

Yoast SEO

Yoast SEO оставляет записи в wp_postmeta и wp_usermeta, а также собственные таблицы wp_yoast_indexable и wp_yoast_seo_links.

Сначала очистите wp_postmeta:

1SELECT * FROM wp_postmeta WHERE meta_key LIKE '%yoast%';
Поиск мета-записей Yoast SEO в таблице wp_postmeta

Убедившись, что это данные Yoast, выполните:

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

Затем, wp_usermeta:

1SELECT * FROM wp_usermeta WHERE meta_key LIKE '%yoast%';
Поиск записей Yoast SEO в таблице wp_usermeta

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

Akismet

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

1SELECT * FROM wp_commentmeta WHERE meta_key LIKE '%akismet_%';
SQL запрос для поиска данных Akismet в комментариях

Затем:

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

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

1OPTIMIZE TABLE wp_commentmeta;

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

Gravity Forms

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

После удаления проверьте wp_options:

1SELECT * FROM wp_options WHERE option_name LIKE '%gravity%' OR option_name LIKE '%gf_%';
SQL запрос очистки wp_options для Gravity Forms

Найденные строки удалите аналогичным DELETE-запросом.

Wordfence

Wordfence, один из самых «тяжёлых» плагинов безопасности: он создаёт 23 таблицы с префиксом wp_wf*. Штатное удаление через панель не очищает их.

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

1SELECT * 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 в корне сайта, если они остались.

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

Сначала удалите плагин через панель управления. Затем через FTP удалите папку wp-content/ngg/, предварительно сохранив изображения галерей, если они нужны. В phpMyAdmin выполните:

1SELECT * 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:

1SELECT * FROM wp_options WHERE option_name LIKE '%ewww%';
SQL запрос очистки опций EWWW Image Optimizer

Удалите найденное и дропните таблицу 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 → таблицы). Десять минут сегодня экономят часы завтра, когда раздутая база кладёт сайт на пике трафика.

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