Если сайт работает давно, база данных WordPress почти всегда начинает разрастаться: копятся ревизии записей, спам-комментарии, временные данные плагинов, старые транзиенты и служебные записи, которые уже не нужны. Это не всегда ломает сайт, но со временем усложняет обслуживание и может замедлять отдельные запросы, особенно на недорогом хостинге и при слабой оптимизации таблиц.
Очистка базы полезна, но делать её нужно точечно. В WordPress есть данные, которые можно удалять безболезненно, и есть то, что трогать нельзя без понимания последствий. Ниже — практический порядок действий: что искать, что удалять, как не повредить сайт и как проверить результат.
Что обычно разрастается в базе WordPress
На старых сайтах чаще всего мусор появляется в нескольких местах:
- ревизии записей и страниц — WordPress сохраняет промежуточные версии контента;
- автосохранения — временные копии черновиков;
- спам и корзина комментариев;
- транзиенты — временные кэши, которые должны удаляться сами, но иногда остаются;
- служебные данные плагинов и тем — старые настройки, логи, кэш, очереди задач;
- неиспользуемые таблицы от удалённых плагинов.
Первые четыре пункта обычно безопасны для очистки. Последние два требуют аккуратности: не каждый плагин хранит данные одинаково, и не каждую таблицу можно удалить без последствий.
Что можно удалить безопасно
Если задача — снизить нагрузку и убрать накопившийся мусор, начните с того, что WordPress создаёт сам и что не нужно для работы сайта прямо сейчас.
Ревизии записей и страниц
Ревизии — это сохранённые версии контента. Они полезны, если нужно откатить текст, но на сайтах с активной редактурой их может накопиться очень много. Удалять старые ревизии обычно безопасно, если вы понимаете, что потеряете возможность вернуться к старым версиям.
Перед очисткой проверьте, не нужен ли вам архив изменений за последние месяцы. Если сайт редактируется командой, лучше оставить хотя бы несколько последних ревизий или ограничить их количество на будущее.
Автосохранения
Автосохранения нужны на случай сбоя в браузере или потери соединения. Старые автосохранения, которые уже не относятся к актуальным черновикам, можно удалять. На практике они редко бывают критичны, если у вас есть свежие ревизии и нормальный рабочий процесс.
Спам и корзина комментариев
Комментарии в спаме и корзине не нужны для работы сайта. Их можно удалять полностью. Если на сайте много комментариев, именно этот раздел часто даёт заметный выигрыш по объёму базы.
Сначала очистите корзину, затем спам. Если комментарии проходят модерацию, проверьте, нет ли там случайно полезных сообщений, которые ещё не были одобрены.
Транзиенты
Транзиенты — это временные значения, которые WordPress и плагины используют для кэширования данных. В норме они истекают и удаляются автоматически, но на некоторых сайтах остаются просроченные записи. Такие данные можно чистить, особенно если сайт давно не обслуживался.
Здесь важно не путать просроченные транзиенты с рабочим кэшем плагинов. Если плагин сам управляет кэшем, лучше использовать его штатную очистку, а не удалять всё подряд из базы.
Что трогать не стоит без проверки
Главная ошибка при ручной чистке — удалить не мусор, а рабочие данные. Это особенно опасно, если вы не знаете, как конкретный плагин хранит информацию.
- Таблицы плагинов не удаляйте, пока не уверены, что плагин больше не используется и его данные не нужны.
- Пользовательские метаданные могут содержать настройки, роли, привязки к заказам, профили, SEO-поля и другую важную информацию.
- Записи в таблице опций лучше не чистить вручную без понимания, что именно делает конкретный параметр.
- Критичные таблицы WordPress — `wp_posts`, `wp_postmeta`, `wp_users`, `wp_usermeta`, `wp_options`, `wp_terms` и связанные с ними — нельзя «облегчать» наугад.
Если вы не уверены, что запись лишняя, сначала сделайте резервную копию и проверьте, какой плагин или функция её создали. Удаление «на глаз» часто заканчивается потерей настроек, форм, SEO-данных или связей между объектами.
Как чистить базу без риска
Безопасный порядок всегда один: резервная копия, точечная очистка, проверка сайта. Не начинайте с удаления таблиц и не чистите базу на боевом сайте без возможности отката.
1. Сделайте резервную копию
Перед любыми действиями сохраните полную копию базы данных. Если хостинг позволяет, сделайте ещё и копию файлов сайта. Это не формальность: при ошибке восстановление из бэкапа быстрее и надёжнее, чем попытка вручную собрать потерянные данные обратно.
2. Используйте штатные инструменты WordPress и плагинов
Если нужно удалить спам, корзину или старые ревизии, сначала проверьте встроенные возможности админки и настройки плагинов. Многие плагины для кэша, SEO и оптимизации умеют чистить свои данные сами. Это предпочтительнее, чем прямое удаление из базы.
Для ревизий и транзиентов удобнее использовать инструменты оптимизации базы или специализированные плагины. Они обычно показывают, что именно будет удалено, и дают меньше шансов задеть лишнее.
3. Удаляйте только понятные категории данных
Если вы работаете через phpMyAdmin или другой SQL-интерфейс, удаляйте только то, в чём уверены. Например, старые ревизии, спам-комментарии или просроченные транзиенты. Не запускайте массовые запросы по всем таблицам без понимания структуры базы и префикса таблиц.
На сайтах с нестандартным префиксом таблиц, несколькими установками WordPress в одной базе или мультиязычными плагинами легко ошибиться и затронуть чужие данные. Это особенно актуально для хостингов, где в одной базе лежит несколько проектов.
Как проверить, что очистка прошла нормально
После чистки не ограничивайтесь тем, что админка открывается. Проверьте именно те места, где чаще всего проявляются ошибки после удаления данных.
- Откройте несколько записей и страниц в админке.
- Проверьте сохранение и обновление контента.
- Посмотрите комментарии, если они используются на сайте.
- Убедитесь, что формы, виджеты и настройки плагинов на месте.
- Проверьте главную страницу и несколько внутренних страниц в браузере.
Если после очистки что-то исчезло или перестало работать, сразу восстановите базу из резервной копии и уже потом ищите, какая именно таблица или категория данных была удалена лишней.
Когда чистка базы действительно даёт эффект
Очистка базы полезна не всегда одинаково. На небольшом сайте с десятком записей разница может быть почти незаметна. Но на старом проекте с тысячами ревизий, большим количеством комментариев и накопленными транзиентами база становится тяжелее в обслуживании, а резервные копии — дольше создаются и восстанавливаются.
Практический смысл чистки обычно есть, если вы видите хотя бы одно из этого:
- админка стала заметно медленнее;
- резервные копии занимают слишком много времени;
- в базе много старых ревизий и спама;
- плагины давно удалены, а их следы остались в таблицах;
- хостинг регулярно жалуется на нагрузку от запросов к базе.
Если сайт работает стабильно и база небольшая, не нужно устраивать «генеральную уборку» ради самого процесса. В WordPress лучше удалять только то, что действительно накопилось и больше не нужно.
Что сделать, чтобы мусор не накапливался снова
После очистки имеет смысл немного ограничить рост базы на будущее. Это не требует сложной настройки, но помогает не возвращаться к той же проблеме через несколько месяцев.
- Ограничьте количество ревизий, если на сайте много редактирования.
- Регулярно удаляйте спам и корзину комментариев.
- Периодически проверяйте просроченные транзиенты.
- Не ставьте лишние плагины, которые дублируют функции друг друга и оставляют свои таблицы.
- Удаляйте неиспользуемые плагины полностью, а не просто деактивируйте их.
Если вам нужен более удобный способ чистить ревизии, дубли и служебный мусор без ручной работы, можно посмотреть на Clearfy Pro. Он не заменяет резервную копию и не отменяет необходимость проверять, что именно удаляется, но для регулярного обслуживания сайта может упростить задачу.
В итоге правильная чистка базы WordPress — это не массовое удаление всего подряд, а аккуратная работа с понятными категориями данных. Сначала убирают ревизии, спам, корзину и просроченные временные записи, затем проверяют сайт и только после этого решают, нужно ли трогать остатки от старых плагинов. Такой подход снижает риск поломки и действительно помогает поддерживать сайт в порядке.