Если WordPress начал заметно тормозить, а база данных разрослась после нескольких лет работы, чаще всего проблема не в «сломавшемся» сайте, а в накопившемся мусоре: ревизиях записей, автосохранениях, временных данных transient и спаме в комментариях. Это типичная история для живых проектов, где контент регулярно редактируют, а плагины и темы оставляют после себя временные записи.
Чистить такую базу можно, но не вслепую. Одни данные действительно безопасно удалить, другие лучше сначала проверить, а часть вообще не стоит трогать вручную, если не понимаете, что делает конкретный плагин. Ниже — практичный порядок действий, который помогает убрать лишнее без риска потерять контент.
Что в базе WordPress можно чистить безболезненно
В WordPress мусор обычно сидит в нескольких местах. Самые распространённые категории такие:
- Ревизии — сохранённые версии записей и страниц. Они полезны при редактировании, но со временем их становится слишком много.
- Автосохранения — временные копии черновиков, которые WordPress делает автоматически во время редактирования.
- Transient — временные записи кэша, которые используют ядро, темы и плагины.
- Спам и корзина комментариев — мусор, который уже не нужен для работы сайта.
Если говорить коротко: ревизии, старые автосохранения, просроченные transient и спам-комментарии обычно можно удалять. Но перед очисткой важно понимать, что transient бывают двух типов: часть из них устаревает сама и безопасно исчезает, а часть может использоваться плагином как рабочий кэш. Поэтому правильнее удалять не «всё подряд», а только то, что действительно просрочено или явно не нужно.
С чего начать: резервная копия и проверка объёма
Перед любой чисткой базы сделайте резервную копию. Это не формальность: если удалить не то или если плагин кэширования/оптимизации работает нестандартно, откат сэкономит время и нервы. Бэкап должен включать и файлы, и базу данных.
После этого имеет смысл посмотреть, что именно раздувает таблицы. Если у вас есть доступ к phpMyAdmin или другому инструменту управления MySQL, обычно больше всего растут таблицы wp_posts и wp_options. В первой лежат записи, страницы, ревизии и автосохранения, во второй — настройки и transient.
Если доступа к базе нет или не хочется работать вручную, удобнее использовать плагин для обслуживания базы. Но даже в этом случае сначала проверьте, есть ли у него понятный список того, что будет удалено, а не только кнопка «очистить всё».
Как удалить ревизии и автосохранения
Ревизии — самый частый источник лишнего объёма. WordPress сохраняет их при каждом существенном изменении записи, и на длинных проектах их может быть сотни и тысячи. Автосохранения обычно занимают меньше места, но тоже накапливаются.
Самый безопасный подход — удалить старые ревизии и оставить одну-две последние версии на случай отката. Для этого можно использовать плагин оптимизации базы или выполнить SQL-запрос вручную, если вы уверены в своих действиях и уже сделали резервную копию.
Пример запроса, который удаляет ревизии записей:
DELETE FROM wp_posts WHERE post_type = 'revision';Этот вариант рабочий, но довольно жёсткий: он удалит все ревизии без разбора. На реальном сайте чаще разумнее сначала использовать плагин, который умеет ограничивать количество ревизий или удалять только старые. Если вы всё же работаете напрямую с SQL, проверьте префикс таблиц: он не всегда wp_.
Автосохранения тоже лежат в таблице wp_posts, но имеют тип auto-draft или связанный механизм автосохранения. Вручную их лучше не удалять массово без понимания, как именно они используются в вашей версии WordPress и в конкретном редакторе. На практике достаточно удалить старые ревизии и дать WordPress самому перезаписать актуальные автосохранения при следующем редактировании.
Что делать с transient и почему здесь нужна осторожность
Transient — это временные данные, которые WordPress и плагины используют как кэш. Они хранятся в базе, если нет отдельного объектного кэша. Просроченные transient можно удалять, и именно они чаще всего безопасны для чистки.
Проблема в том, что transient бывают полезными прямо сейчас. Если удалить их все подряд, сайт обычно не ломается, но может временно начать медленнее работать: плагины заново создадут кэш, а часть данных будет пересчитана. Поэтому лучше чистить именно истёкшие transient, а не все без исключения.
Если вы работаете через SQL, просроченные transient обычно связаны с записями в wp_options. Но вручную искать и удалять их неудобно и легко ошибиться. Для обычного владельца сайта практичнее использовать инструмент, который умеет удалять только expired transient. После такой очистки сайт может кратковременно обратиться к внешним API или пересобрать кэш — это нормально.
Как убрать спам и корзину комментариев
Спам-комментарии не только захламляют админку, но и увеличивают объём таблиц комментариев. Если сайт давно живёт без регулярной модерации, там может накопиться много тысяч записей.
Здесь логика простая: сначала очистите корзину комментариев, затем удалите спам. Если комментарии вам не нужны как функция сайта, имеет смысл отключить их для будущих записей, но это уже отдельная настройка, а не часть очистки базы.
Удаление спама через админку безопаснее, чем прямое удаление из базы. В интерфейсе WordPress вы видите, что именно удаляете, и не затрагиваете обычные комментарии. Если же комментариев очень много и админка работает медленно, можно использовать массовое удаление, но только после проверки, что в очереди нет полезных сообщений.
Когда лучше использовать плагин, а когда работать вручную
Для большинства сайтов удобнее плагин обслуживания базы: он показывает, что именно будет удалено, и снижает риск ошибки. Ручной SQL имеет смысл только тогда, когда вы понимаете структуру таблиц и хотите точечно убрать конкретный тип мусора.
| Подход | Когда подходит | Риски |
|---|---|---|
| Плагин очистки базы | Обычный сайт, нет желания работать с SQL | Нужно доверять плагину и внимательно смотреть, что он удаляет |
| Ручной SQL | Есть опыт и нужен точечный контроль | Можно удалить лишнее, если ошибиться с запросом или префиксом таблиц |
| Очистка через админку WordPress | Спам, корзина, часть ревизий | Медленнее на больших объёмах, но безопаснее для обычного пользователя |
Если вы не администрируете сервер и не уверены в структуре базы, не начинайте с SQL-запросов. Для типовой задачи достаточно плагина, который умеет удалять ревизии, старые автосохранения, просроченные transient и спам.
Как проверить, что очистка прошла нормально
После удаления мусора не ограничивайтесь только сообщением «успешно выполнено». Откройте несколько страниц сайта, проверьте вход в админку, сохранение записи и работу комментариев, если они включены. Если вы чистили transient, нормально, что некоторые блоки или виджеты первое время подгружаются чуть медленнее — кэш пересоздаётся.
Полезно также сравнить размер базы до и после очистки. Если вы работали через phpMyAdmin, это видно по объёму таблиц. Если через плагин — он обычно показывает количество удалённых записей. Главное не цифра сама по себе, а то, что сайт остался рабочим, а лишние записи исчезли.
Если после очистки появились ошибки, первым делом проверьте, не удаляли ли вы что-то вручную из wp_options или таблиц плагинов. В таком случае восстановление из резервной копии обычно быстрее, чем попытка чинить последствия по частям.
Что не стоит чистить без понимания
Есть соблазн удалить из базы всё, что выглядит «временным», но это плохая идея. Не трогайте вручную записи плагинов и темы, если не знаете их назначение. Не удаляйте настройки из wp_options только потому, что они кажутся лишними. Не чистите таблицы наугад по названию, если не уверены, что они относятся именно к мусору.
Безопасная стратегия простая: сначала резервная копия, затем удаление очевидного мусора, потом проверка сайта. Для WordPress этого обычно достаточно, чтобы вернуть базе нормальный размер и убрать лишнюю нагрузку без побочных эффектов.
Если нужен более удобный способ обслуживать сайт без ручной работы с базой, можно использовать инструменты оптимизации и чистки, которые умеют удалять ревизии, transient и спам выборочно. Например, в экосистеме WPShop для этой задачи подходит Clearfy Pro, если вам нужен именно плагин для обслуживания и оптимизации сайта. Но даже с ним правило остаётся тем же: сначала бэкап, потом точечная очистка, затем проверка работы сайта.