WP: автоматическая чистка ревизий и оптимизация БД — шаги для упрощения работы с медиа
Есть странная особенность у WordPress: чем больше он помогает вести блог, корпоративный сайт или магазин, тем сильнее превращается в захламлённый гараж. Снаружи сайт может выглядеть аккуратно, а внутри лежат тысячи ревизий записей, старые медиафайлы, мусорные транзиенты и спам-комменты, которые годами жрут ресурсы сервера. Хостер пишет: «у вас база разрослась, пора апгрейдить тариф», LCP в метриках горит красным, SEOшник шепчет про Core Web Vitals, а ты просто хотел пару статей в блог заливать и лендинги к акциям делать.
И вот тут начинаются пляски: какой плагин чистки поставить, что он сломает, а что нет, почему после очередной «оптимизации» пропала половина миниатюр, и можно ли всё это вообще автоматизировать так, чтобы забыть, как выглядит phpMyAdmin. И да, можно. Более того, всё это можно аккуратно связать с автоматизациями в Make.com, чтобы база не пухла, медиафайлы не размножались как кролики, а ты занимался чем-то более приятным, чем ручная чистка ревизий субботним утром.
Меня зовут Артур Хорошев, я довольно много возился с WordPress, видел пару кошмарных баз данных на 3+ гигабайта и пару раз спасал людей, которые решили «ну я сам тут в SQL почищу, что мне, сложно что ли». Поэтому сейчас разложу по шагам, как приручить ревизии, оптимизировать базу и медиа, а заодно покажу, где тут место Make и зачем тебе вообще эти автоматизации, если ты не фанат ковыряться в админке ночами.
Почему WordPress тормозит, хотя «по идее всё нормально»
Картина типичная: сайт на WordPress, пара десятков страниц, блог, медиабиблиотека вроде бы вменяемая. Человек заходит в админку утром, открывает «Записи», жмёт «Редактировать» — и кофе успевает остыть, пока редактор грузится. На фронтенде посетители тоже не в восторге: страница открывается медленно, выдача в поиске проседает, а Яндекс.Вебмастер показывает печальные графики времени ответа сервера. Вроде хостинг не самый дешёвый, а впечатление, что сайт живёт на флешке с рынка.
Проблема часто не в шаблоне и даже не в плагинах. Виновата забитая под завязку база данных и свалка медиафайлов. WordPress очень любит хранить историю: написал пост — вот тебе ревизия, поправил заголовок — ещё одна, исправил одну опечатку — на, держи ещё ревизию. Через пару лет блогерской активности в таблице wp_posts может жить больше ревизий, чем реальных записей, и каждая такая радость дружно участвует в запросах к базе. Плюс к этому спам-комментарии, старые метаданные, забытые временные данные (transients), мусор от плагинов и тысячи картинок, которые уже давно не используются ни на одной странице, но продолжают занимать место и индексироваться как попало.
Теперь умножаем это на то, что большинство бизнес-сайтов не трогают базу годами — она копит всё подряд, как кухонный ящик, куда складывают «потом разберу». В какой-то момент база разбухает настолько, что даже нормальный сервер начинает думать дольше, чем хотелось бы. Исследования и просто здравый смысл говорят, что регулярная оптимизация базы может срезать 20-30% времени отклика. Это не «магические проценты с потолка», а банальная история: меньше мусора — быстрее запросы — меньше нагрузка — лучше скорость.
Ревизии: тихие убийцы производительности
Если открыть базу WordPress и посмотреть таблицу wp_posts, можно слегка ужаснуться. Помимо реальных записей, страниц и вложений, там живёт огромное количество постов типа revision. Это ревизии — копии записей, которые WordPress хранит на каждый чих. Для редактора контента это иногда полезно: можно откатиться к старой версии. Для производительности это не всегда праздник. Когда на сайте сотни записей, а у каждой по 20-30 ревизий, база пухнет великолепно.
Есть простой способ остановить этот карнавал. В корне сайта лежит файл wp-config.php, который отвечает за всякие базовые настройки. Если добавить туда строку:
define('WP_POST_REVISIONS', false);
то WordPress перестанет создавать новые ревизии. Можно задать и число, например 5, чтобы он хранил не бесконечную историю правок, а только последние несколько. Это уже компромисс между удобством и производительностью. Но тут важный момент: если просто отключить создание новых ревизий, старые сами по себе никуда не денутся, они так и останутся висеть в базе. Поэтому подход нормальный такой: сперва настроить ограничение ревизий, потом почистить существующие.
И вот тут включается автоматика. Можно, конечно, зайти в phpMyAdmin и руками написать запрос на удаление постов с типом revision, но я видел, чем это заканчивается, если человек ошибётся в WHERE. Гораздо безопаснее доверить это плагину или внешнему сценарию, который делает именно то, что нужно, и не пытается быть героем вечера.
WP-Sweep и компания: навести порядок без истерик
Среди плагинов для уборки в базе есть много вариантов. Один из нормальных — WP-Sweep. Он аккуратно удаляет ревизии, авто-сохранения, спам-комментарии, неиспользуемые метаданные, мусорные термины и прочие «артефакты» жизни WordPress. Из приятного — он использует официальные функции WordPress, а не долбит базу прямыми запросами «с ноги». Это снижает шанс, что он снесёт что-нибудь важное. Ну, конечно, если не включать все галочки подряд в состоянии лёгкой усталости.
Я обычно рекомендую такой ритуал: сначала бэкап, потом WP-Sweep, потом ещё раз бэкап (на случай, если что-то захотелось откатить), и только потом жить дальше. Ручная чистка раз в пару месяцев уже заметно облегчает базу. Но штука в том, что мы живём в эпоху, когда руками хорошо делать те вещи, где нужна голова, а вот монотонные процедуры вроде «каждый месяц зайти и нажать кнопку очистки» грех не отдать автоматизации. На этом месте осторожно подмигивает Make.com.
Зачем тут вообще Make.com и при чём тут медиа
Если ты до этого использовал Make только для всяких модных штук вроде автопостинга в Telegram, автозаливки статей в Дзен или связки сайта с CRM, то оптимизация базы и медиа может звучать скучно. Но ровно до того момента, пока ты не посчитаешь, сколько времени уходит на ручное удаление мусора и разбор медиа. Когда у сайта много контента, картинки, файлы, видосы на серваке начинают вести себя как старые документы в шкафу: кажется, что всё нужно, но 70% можно смело выкинуть.
Типичный пример: контентщик загрузил 10 вариантов обложки для статьи, выбрал один, остальные повисли мёртвым грузом. За год таких неиспользуемых файлов набегает прилично, особенно если у вас интернет-магазин, каталог, фотогалерея или активный блог. Исследования и здравый смысл говорят, что вычищение неиспользуемых медиа может освободить до половины дискового пространства. На дешёвых тарифах это прям больно заметно, на дорогих — тоже, просто боль дороже.
Make.com как раз хорош тем, что может регулярно «проходиться» по сайту и делать рутину. Например, раз в неделю выкачивать список медиафайлов, сравнивать их с реально используемыми в постах и страницах, помечать подозрительные на удаление и либо складывать их в отчёт в Telegram, либо автоматически переносить в корзину. Вариантов сценариев масса — от суперосторожных до «жёстких, но справедливых», когда файлы, неиспользуемые больше полугода, улетают в архив, а ещё через месяц — с сервера.
Как это выглядит на практике: цепочка WordPress + Make
Представим, что у тебя есть сайт на WordPress и нормальное человеческое желание — чтобы он не превращался в свалку. Подключаем его к Make через плагин или API, создаём сценарий, который раз в неделю или месяц запускается по расписанию. Сценарий тянет список постов, медиа и, например, их дату создания или последнего использования. Далее включается логика: если файл нигде не привязан как миниатюра, не вставлен в контент и при этом старше, скажем, 120 дней — помечаем его как «подозрительный».
Дальше два пути. Осторожный: Make собирает тебе отчёт — например, в Google Sheets или Notion — и шлёт ссылку в Telegram: мол, вот список старых, неиспользуемых медиа, посмотри, удали, если всё ок. Более прожаренный вариант: Make через API помечает эти файлы как «в корзине» в WordPress или вообще удаляет физически с диска. Чтобы не нервничать, можно сохранять лог всех удалённых файлов, и если кто-то вдруг крикнет «верните картинку, она была нужна для лендинга 2019 года», можно хотя бы понять, что с ней было.
Параллельно можно автоматизировать и историю с ревизиями. Да, их уже можно чистить WP-Sweep, но никто не мешает запускать этот процесс по крону через Make: сценарий раз в месяц вызывает нужный хук или URL на стороне сайта, который запускает заданную чистку. Руки свободны, база худеет, хостинг меньше ноет. А ты в это время занимаешься чем-то более осмысленным, чем наблюдение за полоской прогресса «Оптимизация таблиц».
Медиафайлы, которые ничего не делают, но всем мешают
С медиа всё ещё интереснее. Многие думают, что большой объём файлов — проблема только диска. Ну, подумаешь, занято 20 гигабайт, добавим тариф, делов-то. Но на практике это влияет и на резервное копирование (бэкапы становятся жирными и долгими), и на миграцию сайта, и на резервное хранение. Плюс часть плагинов, работающих с медиа, начинают тупить на больших объёмах, а библиотека в админке превращается в вечный скролл, где ты ищешь нужное фото 5 минут.
Математика простая: если системно удалять неиспользуемые файлы, оптимизировать размеры картинок и не хранить на сайте всё подряд «на всякий случай», можно реально разгрузить сервер и ускорить отдачу страниц. Ещё один момент — SEO. Поисковики не обожают кучу дубликатов картинок и мусорных URL. Чистая медиабиблиотека — это аккуратные alt-теги, осмысленные имена файлов и минимум барахла, которое индексатору придётся пережёвывать.
Тут на сцену выходят связки Make + WordPress + иногда нейросети. Например, ты можешь сделать сценарий, который автоматически уменьшает слишком большие загруженные картинки, задаёт им осмысленные имена (а не IMG_937462.jpg), проставляет alt на основе заголовка записи или описания, а также сохраняет оригиналы где-нибудь во внешнем хранилище. Это уже следующий уровень автоматизации, когда сайт сам поддерживает адекватное состояние, а медиабиблиотека не выглядит свалкой фотографий с телефона.
Безопасность: бэкапы — это не занудство, а инстинкт самосохранения
Перед тем как начинать любую чистку — хоть плагинами, хоть сценариями в Make, хоть лично напильником — резервные копии надо делать всегда. Не «когда-нибудь», а прям перед. Здесь нет никакого геройства: любой, кто хоть раз по ошибке снёс половину контента, потом становится фанатом бэкапов. Причём нормальных, которые можно действительно развернуть, а не «архив где-то на том же сервере, который как раз лёг».
И тут, кстати, тоже можно подключить Make. Он спокойно делает автозапуски бэкапов через плагины резервного копирования, выгружает архивы в Яндекс.Диск, Google Drive или другое облако, пишет в Telegram: «архив создан, всё живо». Ты не вспоминаешь про бэкапы, но они есть. Когда человек живёт без автоматизации, он полагается на дисциплину. А дисциплина рано или поздно проигрывает усталости и «сделаю потом». Автоматизация хороша тем, что ей не лень.
Тренды: автоматизация, ИИ и «сайт сам о себе заботится»
Сейчас интересный тренд: WordPress всё ещё доминирует в русском сегменте, но вокруг него вырос целый зоопарк сервисов и интеграций. Автоматизации на Make.com, сценарии с нейросетями, генерация контента в блог и Дзен, автопостинг в ВК и Telegram, автогенерация картинок под статьи — вся эта история уже стала обыденностью. И странно на этом фоне продолжать чистить базу «по старинке», вручную, будто у тебя сайт на 5 страниц из 2012 года.
Можно ведь пойти дальше. Например, связать сценарий, который автоматом генерирует статью, картинки, публикует её в WordPress, дублирует в Дзен и ВК, и при этом следит, чтобы медиахлам не копился. Картинки, не привязанные ни к одной записи спустя месяц — в корзину. Ревизии старше трёх месяцев — удаляем. Спам-комменты — вылезли, тут же чистятся. И всё это на фоне автоматизированных витрин, лендингов и страниц, которые тот же Make собирает по шаблону.
Если тебе сама идея «сайт, который сам за собой подметает» откликается, то логично не ограничиваться одной задачей. Оптимизация БД и медиабиблиотеки — просто хороший повод войти в тему автоматизаций по-взрослому. Иначе получается странно: на входе у тебя нейросети, генерация, автодублирование, а внутри проекта база напоминает старую кладовку, в которой страшно шевельнуть коробку.
Если хочется научиться делать всё это не наугад
Когда начинаешь работать с Make, очень легко уйти в импровизацию: «сейчас я тут сам склею модуль с модулем, что мне, сложно что ли». А потом сценарий падает, что-то удаляет лишнее, что-то не удаляет нужное, и наступает фаза лёгкой рефлексии. Нормальный путь проще: сначала понять логику платформы, типовые сценарии, ограничения и подводные камни, а уже потом крутить свои финты.
Я как раз делаю обучение по автоматизации задач на Make.com, в том числе связанных с WordPress, медиа и оптимизацией. Если тебе хочется не просто «разобраться на уровне пары туториалов», а выстроить систему так, чтобы сайт, рассылки, соцсети и боты работали в единой логике, тебе сюда: Обучение по make.com. Там от разбора интерфейса и базовых модулей до сложных сценариев с условной логикой, ИИ и интеграцией с бизнес-процессами.
Если времени мало и хочется «дайте рабочие схемы, я сам их допилю под себя», есть вариант попроще — готовые сценарии и шаблоны: Блюпринты по make.com. Берёшь черновик автоматизации, цепляешь к своему WordPress, хостингу, CRM — и уже не с нуля колхозишь, а адаптируешь готовое. Для тех, кто устал учиться по вечерам, но всё равно хочет, чтобы всё работало без ручного труда.
Ну и если надо иногда подглядывать идеи, обучения, разборы кейсов и свежие фишки связок Make + нейросети, я всё это регулярно разбираю в канале. Короткие форматы, без трехчасовых философских монологов: Хотите научиться автоматизации рабочих процессов с помощью сервиса make.com и нейросетей ? Подпишитесь на наш Telegram-канал.
FAQ: частые вопросы про чистку ревизий, оптимизацию БД и автоматизацию
Нужно ли отключать ревизии полностью?
Не обязательно. Если у вас большой редакционный отдел и важна история правок, лучше ограничить количество ревизий, а не рубить их под ноль. Например, задать 5-10 последних версий. Для личного блога или небольшого корпоративного сайта часто вообще достаточно отключить ревизии, чтобы база не пухла от бессмысленных правок запятой в заголовке.
Как часто имеет смысл чистить базу WordPress?
Если сайт живой, с регулярными публикациями и активными пользователями, то раз в месяц — нормальный режим. Для тихих проектов с редкими обновлениями хватает раз в квартал. Главное — чтобы это было системно. Здесь как с уборкой квартиры: лучше по чуть-чуть и регулярно, чем раз в год, но с трёхдневным разбором завалов.
Можно ли всё сломать, если неправильно очистить базу?
Можно. Если лезть в SQL без понимания, что ты удаляешь, и без бэкапа — шанс «сделать красиво» очень реальный. Поэтому любой эксперимент, особенно с ручными запросами, только через резервную копию. Плагины вроде WP-Sweep безопаснее, но тоже лучше запускать не в боевой пик трафика, а в спокойное время, и поэтапно, а не «галочка на всё сразу».
Как понять, какие медиафайлы точно можно удалять?
Базовая логика такая: если файл не привязан к записи, не является миниатюрой записи или таксономии и нигде не используется в контенте, он кандидат на удаление. Но лучше делать это в два шага: сначала собрать список «подозрительных» файлов, а затем проверить выборочно, всё ли там действительно лишнее. Make.com тут хорош тем, что может автоматически находить такие файлы и формировать отчёты, а уже ты решаешь, насколько агрессивно чистить.
Make.com — это про программистов или можно без кода?
Большую часть задач на Make можно собирать без программирования, через визуальные сценарии. Понимание логики «если — то», работы с данными и базовых API сильно помогает, но чистый код нужен далеко не всегда. Для типовых связок WordPress, Telegram, CRM, медиа-хранилищ и ботов хватает стандартных модулей и адекватной головы.
С чего начать, если WordPress уже тормозит?
Шаги такие: сделать нормальный бэкап, поставить и аккуратно прогнать WP-Sweep (ревизии, спам, мусорные метаданные), проверить ошибки в логах сервера и включить какой-нибудь кеширующий плагин. Потом уже смотреть, где можно включить автоматизацию: перенос бэкапов в облако, регулярная чистка, разбор медиа. И только если всё это не помогает, копать хостинг и тяжёлые плагины.
Реально ли через автоматизации экономить на хостинге?
Да, местами весьма ощутимо. Когда база и медиа разрастаются без ограничений, рано или поздно всё упирается в дисковое пространство и ресурсы. Регулярная оптимизация и автоматическая чистка мусора позволяют дольше жить на адекватном тарифе, а не сразу прыгать в «бизнес премиум», просто потому что файлов стало слишком много. Плюс сайт начинает отвечать быстрее, что приятно и пользователям, и поисковикам.
Где можно посмотреть живые примеры автоматизаций для WordPress и Make?
Регулярные разборы и кейсы я выкладываю у себя в канале: разборы сценариев, интеграции с нейросетями, оптимизация контента и медиа, всё, что крутится вокруг автоматизации рабочих процессов. Вот ссылка: Telegram-канал. Для тех, кто хочет не просто почитать, а системно обучиться, есть курсы и готовые схемы: Обучение по make.com и Блюпринты по make.com.