Если сайт на WordPress давно живёт и контент активно редактируется, в базе почти всегда накапливаются ревизии записей. Это не ошибка и не мусор в буквальном смысле: WordPress сохраняет версии постов, чтобы можно было откатить изменения. Но на старых проектах ревизий бывает слишком много, база разрастается, резервные копии становятся тяжелее, а запросы к таблице постов — медленнее.
Задача обычно состоит из трёх частей: ограничить количество будущих ревизий, удалить уже накопившиеся старые версии и не сломать удобство редактирования. Ниже — практический порядок действий без лишних шагов.
Что именно удалять и почему это влияет на сайт
Ревизии в WordPress хранятся в той же таблице, что и обычные записи, — в wp_posts. Каждая сохранённая версия статьи, страницы или другого типа записи добавляет новую строку. Чем больше таких строк, тем больше база данных и тем дольше ей приходится работать с таблицей, особенно если сайт старый и контента много.
Удалять стоит именно старые ревизии, а не всё подряд. Они полезны, когда редактор случайно испортил текст, вставил не тот блок или нужно сравнить изменения. Полное отключение ревизий возможно, но обычно это лишает вас удобного отката и не всегда оправдано.
Сначала ограничьте количество будущих ревизий
Если просто удалить старые данные, проблема вернётся. Поэтому сначала имеет смысл задать лимит на новые ревизии. WordPress умеет хранить только несколько последних версий записи, если это указать в конфигурации.
Для этого в файле wp-config.php добавляют константу WP_POST_REVISIONS. Перед изменением файла сделайте резервную копию: ошибка в wp-config.php может временно уронить сайт.
Например, чтобы хранить не больше 5 ревизий на запись, добавьте строку до комментария /* That's all, stop editing! Happy publishing. */:
define( 'WP_POST_REVISIONS', 5 );Если поставить true или не задавать константу вовсе, WordPress будет хранить ревизии по умолчанию. Если поставить false, ревизии отключатся полностью, но это уже более жёсткий сценарий: для редакционного сайта я бы так делал только осознанно и после проверки, что откат версий не нужен.
Ограничение количества ревизий не удаляет старые данные автоматически. Оно только предотвращает дальнейший рост базы.
Как удалить уже накопившиеся ревизии
Тут есть три рабочих варианта: через плагин, через SQL-запрос в базе и через WP-CLI. Выбор зависит от того, как вы управляете сайтом и есть ли доступ к серверу.
Вариант 1: плагин для очистки базы
Если у вас нет удобного доступа к базе или командной строке, проще использовать плагин для обслуживания базы данных. Подходящий инструмент должен уметь удалять ревизии, не трогая обычные записи и страницы. После очистки плагин обычно показывает, сколько строк удалено.
Этот путь удобен для владельца сайта без технического доступа, но есть важное условие: перед запуском сделайте резервную копию базы данных. Очистка выполняется быстро, и откатить удаление без бэкапа уже не получится.
Вариант 2: удалить ревизии SQL-запросом
Если у вас есть доступ к phpMyAdmin или другому SQL-интерфейсу, можно удалить ревизии напрямую. Это самый быстрый способ, но и самый требовательный к внимательности. Перед выполнением запроса обязательно сделайте резервную копию базы.
Запрос для удаления всех ревизий выглядит так:
DELETE FROM wp_posts WHERE post_type = 'revision';Если префикс таблиц у вас не wp_, замените его на свой. После удаления ревизий имеет смысл оптимизировать таблицу через инструменты хостинга или phpMyAdmin, чтобы освободившееся место реально вернулось базе.
Этот способ удаляет все ревизии сразу. Если вам нужно оставить часть истории редактирования, лучше использовать плагин с более гибкими настройками или очистку через WP-CLI с предварительной проверкой.
Вариант 3: WP-CLI
Если сайт обслуживается через консоль, WP-CLI удобнее всего. Команда удаляет ревизии штатным способом WordPress и подходит для больших сайтов, где ручная очистка через админку неудобна.
Используйте команду:
wp post delete $(wp post list --post_type=revision --format=ids) --forceЗдесь --force нужен, чтобы удалить записи без отправки в корзину. Команда рабочая, но требует аккуратности: запускайте её только в нужной установке WordPress и только после бэкапа. Если ревизий очень много, список может быть длинным, и на слабом хостинге лучше удалять их порциями.
Как не сломать редактирование контента после очистки
Сама по себе очистка ревизий не ломает сайт. Проблемы обычно возникают, когда одновременно отключают всё подряд или удаляют не только ревизии, но и другие служебные записи. Чтобы не создать себе лишнюю работу, держитесь нескольких правил.
- Не удаляйте записи вручную по признаку «похоже на мусор», если не уверены в типе поста.
- Сначала ограничьте будущие ревизии, потом удаляйте старые.
- Не отключайте ревизии полностью, если на сайте несколько авторов или контент часто правят.
- После очистки проверьте несколько записей в редакторе: кнопка истории версий должна работать, если вы оставили ревизии включёнными.
Если на сайте используется редактор блоков, ревизии особенно полезны: они помогают откатить неудачную замену блоков или случайное удаление секции. Поэтому для большинства сайтов разумнее оставить небольшой лимит, а не отключать функцию целиком.
Как проверить, что база действительно стала легче
После очистки не ориентируйтесь только на ощущения. Проверьте результат в двух местах: в базе и в админке WordPress.
В базе можно посмотреть количество строк в таблице wp_posts или размер таблицы через phpMyAdmin. Если ревизий было много, разница обычно заметна сразу. В админке откройте несколько старых записей и убедитесь, что у них остались только нужные версии, а новые сохранения продолжают создаваться в пределах заданного лимита.
Если вы используете кэширование на уровне хостинга или плагина, после очистки базы можно сбросить кэш. Это не обязательно для самой ревизии, но помогает быстрее увидеть актуальное состояние сайта и исключить старые данные в интерфейсе.
Когда лучше не чистить ревизии вручную
Есть ситуации, когда спешить не стоит. Если сайт недавно переехал, база ещё не проверена на ошибки, а резервной копии нет, сначала сделайте бэкап и только потом запускайте очистку. Если контент редактируют несколько человек и часть материалов часто возвращают к прошлой версии, слишком жёсткое ограничение ревизий может мешать работе редакции.
Также не стоит ожидать, что удаление ревизий само по себе радикально ускорит любой сайт. На небольшом проекте эффект может быть почти незаметен. Но на старом ресурсе с тысячами записей и длинной историей правок это часто даёт ощутимое уменьшение базы и упрощает обслуживание.
Практически рабочая схема выглядит так: задать лимит ревизий в wp-config.php, удалить накопившиеся старые версии через плагин, SQL или WP-CLI, затем проверить редактор и размер базы. Это безопаснее, чем просто отключать ревизии или чистить таблицу без понимания, что именно удаляется.