Как очистить таблицы wp_options в WordPress от устаревших автозагрузок

Если WordPress-сайт давно живёт, в таблице wp_options почти всегда накапливаются автозагружаемые опции. Часть из них нужна ядру, теме или плагинам, но со временем там остаются и следы удалённых расширений, старых настроек и временных данных. Именно они часто раздувают объём автозагрузки и замедляют каждый запрос к сайту.

Задача здесь не в том, чтобы «почистить всё подряд», а в том, чтобы найти тяжёлые и уже неиспользуемые записи с autoload = 'yes', убрать только лишнее и не сломать работающий сайт.

Что именно раздувает wp_options

В wp_options хранятся настройки WordPress, темы и плагинов. Для части записей включена автозагрузка: WordPress подгружает их почти на каждом запросе, чтобы не делать отдельный запрос к базе для каждой мелочи. Это удобно, пока таких опций немного.

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

Особенно это заметно на сайтах с большим количеством плагинов, несколькими сменами темы и долгой историей обновлений. В таких случаях полезно сначала не удалять, а измерить, что именно лежит в автозагрузке.

Как найти тяжёлые autoload-опции

Самый надёжный способ — посмотреть реальные данные в базе. Если у вас есть доступ к phpMyAdmin, Adminer или другому SQL-клиенту, начните с запроса, который покажет самые крупные автозагружаемые опции.

Перед любыми изменениями сделайте резервную копию базы данных. Это не формальность: одна неверно удалённая опция может сломать настройки темы, плагина или даже вход в админку.

Запрос для поиска крупных autoload-записей:

SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 50;

Если префикс таблицы у вас не wp_, подставьте свой. В результате вы увидите, какие опции занимают больше всего места. Обычно уже по названиям можно понять, к чему они относятся: плагин, тема, кэш, статистика, временные данные.

Полезно также посмотреть суммарный объём автозагрузки:

SELECT SUM(LENGTH(option_value)) AS total_autoload_bytes
FROM wp_options
WHERE autoload = 'yes';

Сам по себе большой объём ещё не означает проблему, но если автозагрузка измеряется сотнями килобайт или мегабайтами, это уже повод разбираться предметно.

Как понять, что можно удалять, а что трогать нельзя

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

Ориентируйтесь на такой подход:

• если плагин удалён, а его опции остались — это кандидат на очистку;
• если тема давно заменена, а в wp_options лежат её настройки — их тоже можно проверить;
• если запись похожа на кэш, временные данные или служебный массив старого расширения — сначала убедитесь, что плагин действительно не используется;
• если опция относится к активной теме, текущему плагину безопасности, кэшу, SEO или форме обратной связи — не удаляйте её без проверки.

Важный момент: не все большие опции вредны. Некоторые плагины хранят в автозагрузке действительно нужные настройки. Удаление «по размеру» без понимания назначения — плохая идея.

Безопасная очистка: сначала отключить лишнее, потом удалять записи

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

Для ручной очистки через SQL можно удалить конкретную запись по имени:

DELETE FROM wp_options
WHERE option_name = 'имя_опции';

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

SELECT option_name, option_value
FROM wp_options
WHERE option_name = 'имя_опции';

Если запись явно принадлежит удалённому плагину и больше нигде не используется, её можно убрать. После этого очистите кэш сайта, если он есть, и проверьте фронтенд и админку.

Если вам удобнее работать через WP-CLI, можно сначала найти опцию, а потом удалить её точечно. Команда удаления выглядит так:

wp option delete имя_опции

WP-CLI доступен не на всех хостингах, поэтому этот вариант подходит только если у вас есть SSH-доступ и установлен WP-CLI. На shared-хостинге чаще приходится работать через phpMyAdmin или панель управления.

Что делать с большими опциями, которые нужны, но слишком тяжёлые

Иногда проблема не в устаревших данных, а в том, что активный плагин хранит слишком много информации в автозагрузке. В таком случае удаление записи не поможет: после следующего обновления плагин создаст её снова.

Тут есть три рабочих сценария:

1. обновить плагин или тему — иногда разработчики уже исправили хранение данных;
2. проверить настройки — часть плагинов позволяет отключить лишние модули, статистику или кэширование в базе;
3. заменить расширение, если оно системно раздувает автозагрузку и не даёт нормального контроля.

Если опция относится к активному плагину, а вы не понимаете её структуру, не редактируйте значение вручную. Сериализованные данные легко повредить, и тогда плагин перестанет читать настройки.

Как проверить результат после очистки

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

Дополнительно стоит посмотреть:

• открывается ли главная страница и внутренние страницы без ошибок;
• работает ли вход в админку;
• не сломались ли формы, меню, виджеты и настройки темы;
• не появились ли ошибки в журнале сервера или в debug.log, если он включён.

Если после очистки сайт стал быстрее, но в базе всё ещё есть крупные autoload-опции, не пытайтесь убрать их все за один заход. Лучше идти по одной записи, проверяя результат после каждого изменения. Так проще понять, что именно влияет на сайт.

Когда лучше не чистить wp_options вручную

Ручная очистка не подходит, если у вас нет понятного списка плагинов и тем, которые уже удалены, или если сайт критически важен и любое вмешательство должно быть согласовано. В таких случаях безопаснее сначала сделать копию базы, затем проверить автозагрузку на тестовой копии сайта и только после этого переносить изменения на боевой проект.

Также не стоит чистить wp_options «по совету из интернета», если вам предлагают удалить десятки строк без объяснения, что это за записи. В WordPress одна и та же таблица хранит и безобидные настройки, и данные, без которых сайт не поднимется.

Если нужен более аккуратный подход к чистке сайта в целом, в экосистеме WPShop есть Clearfy Pro, но и в этом случае важно понимать, что именно вы отключаете или удаляете. Автоматизация не отменяет проверки автозагрузки и резервной копии.

Практически полезный порядок действий такой: найти крупные autoload-опции, определить их источник, удалить только следы удалённых расширений, затем перепроверить объём автозагрузки и работу сайта. Именно так очистка wp_options даёт эффект без лишнего риска.