Как закрыть старые ревизии в WordPress и не раздувать базу данных

Автор: Ксения Мельникова | Опубликовано: 26.09.2026

Если сайт давно живёт, а редакция активно правит тексты, ревизии начинают занимать заметное место в базе данных. Проблема обычно не в одной записи, а в накоплении тысяч автосохранений и старых версий постов. На небольшом сайте это незаметно, но на рабочем проекте с частыми правками база растёт, резервные копии становятся тяжелее, а запросы к таблице wp_posts и связанным метаданным — медленнее.

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

Когда ревизии действительно становятся проблемой

Ревизии сами по себе не ошибка. Это штатный механизм WordPress. Но есть несколько типичных симптомов, по которым видно, что их пора приводить в порядок:

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

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

SELECT post_type, COUNT(*) AS cnt
FROM wp_posts
WHERE post_type = 'revision'
GROUP BY post_type;

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

Что лучше: ограничить, отключить или удалить

Перед чисткой важно выбрать подход. У каждого варианта свой компромисс.

Подход	Что делает	Плюсы	Минусы
Ограничить число ревизий	WordPress хранит только последние версии	Сохраняется откат, база не раздувается бесконечно	Старые версии исчезают
Отключить ревизии полностью	Новые версии не создаются	Минимум мусора	Риск потерять удобный откат при правках
Удалить старые ревизии вручную	Чистит уже накопленное	Быстрый эффект	Нужен бэкап и аккуратность

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

Пошаговое решение: ограничиваем ревизии через код

Самый надёжный способ — задать лимит в wp-config.php. Это работает на уровне ядра и не зависит от темы или плагинов.

define( 'WP_POST_REVISIONS', 5 );

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

define( 'WP_POST_REVISIONS', false );

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

Если нужен более гибкий вариант, например ограничить ревизии только для некоторых типов записей, можно использовать фильтр wp_revisions_to_keep в теме или мини-плагине:

<?php
add_filter( 'wp_revisions_to_keep', function( $num, $post ) {
    if ( $post->post_type === 'page' ) {
        return 3;
    }

    if ( $post->post_type === 'post' ) {
        return 5;
    }

    return $num;
}, 10, 2 );

Такой подход удобен, если у вас разные сценарии работы с контентом. Например, для страниц достаточно трёх версий, а для длинных статей — пяти.

Как удалить уже накопившиеся ревизии

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

Если у вас есть доступ к SQL, можно удалить ревизии напрямую:

DELETE FROM wp_posts
WHERE post_type = 'revision';

Этот запрос удалит все ревизии сразу. Он быстрый, но грубый. Если нужно оставить последние версии и убрать только старый мусор, лучше использовать плагин для обслуживания базы или WP-CLI, если он доступен в вашей среде.

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

Когда лучше не трогать ревизии SQL-запросом

Не удаляйте ревизии напрямую, если:

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

Последний пункт особенно важен. На реальном сайте префикс таблиц часто отличается от стандартного.

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

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

Откройте несколько записей и сохраните их 2–3 раза.
Проверьте, что число ревизий не растёт бесконечно.
Сравните размер таблицы wp_posts до и после очистки.
Откройте редактор и убедитесь, что история изменений доступна.
Проверьте, что автосохранение работает и черновик можно восстановить после перезагрузки страницы.

Если вы ограничили ревизии через wp-config.php, в карточке записи в редакторе должно отображаться только заданное количество версий. Если вы удаляли старые ревизии, в истории не должно остаться пустых или битых ссылок на версии.

Частые ошибки и как их исправить

Отключили ревизии полностью и потеряли удобный откат

Это типичная ошибка на сайтах, где тексты редактируются вручную. Если редактор часто вносит правки, полное отключение ревизий создаёт лишний риск. Исправление простое: верните лимит, например 3–5 версий, и не отключайте механизм целиком.

Удалили ревизии без бэкапа

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

Перепутали ревизии и автосохранения

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

Использовали SQL на неправильной базе

Если на сервере несколько сайтов, легко выполнить запрос не в той базе. Перед удалением проверьте имя базы, префикс таблиц и сделайте выборку SELECT COUNT(*) вместо немедленного удаления. Это банально, но именно здесь чаще всего ошибаются.

Практические советы по безопасности и производительности

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

ограничьте ревизии в wp-config.php, а не только в плагине;
не храните бесконечную историю для коротких служебных страниц;
периодически проверяйте размер таблицы wp_posts и wp_postmeta;
перед массовой очисткой делайте бэкап базы;
если редакция большая, протестируйте лимит ревизий на staging-копии;
не отключайте механизм восстановления контента ради экономии нескольких мегабайт.

Если вам нужен более широкий набор инструментов для чистки сайта, отключения лишнего мусора и управления техническими настройками WordPress, можно посмотреть на Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, что именно он меняет в базе и в конфигурации.

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