Плагины WordPress: 14 нужных и 6 опасных

Сайт нашей студии работает на WordPress, и плагинов на нём ровно четыре. Плагины для WordPress удобны ровно тем же, чем и опасны: это чужой код, который выполняется на вашем сайте с правами администратора. Разбираем, что ставить стоит, чего не стоит и как проверять плагин до установки.

Типичная картина, с которой к нам приходят на поддержку: 34 активных плагина, главная грузится 6 секунд, админка открывается по 8-10 секунд, а зачем стоит половина списка, не помнит уже никто. За три года каждый подрядчик добавлял по плагину под свою задачу, и ни один ничего не удалял.

WordPress не изолирует плагины: активированный код видит всю базу, все файлы и все хуки ядра. Песочницы нет. Поэтому вопрос "какие плагины поставить" на деле звучит как "кому вы отдаёте ключи от сайта".

Что стоит у нас и почему так мало

На сайте студии четыре плагина: Advanced Custom Fields PRO для полей контента, Classic Editor для привычного редактора, Yoast SEO для мета-тегов и карты сайта, WP Super Cache для кэша.

Всё остальное сделано кодом в теме: отправка форм, автопостинг статей в Telegram-канал, отложенная публикация, уведомления поисковикам о новых страницах. Каждая такая задача решается сорока строками в файле темы, а в каталоге под неё есть плагин на 300 килобайт с настройками на пять экранов.

Без своего разработчика так не сделать, но принцип полезен: если задача решается один раз и больше не меняется, отдельный плагин под неё чаще всего лишний.

14 плагинов, которые закрывают типовые задачи

Набор, из которого мы собираем сайты клиентам. Ставим не всё сразу, а под задачи проекта.

Зарубежные лицензии с российской карты напрямую не оплатить, покупают через посредников с наценкой 10-20 процентов. Бесплатных версий хватает почти везде: платить обычно приходится только за ACF PRO.

Две позиции стоит пояснить, их часто пропускают.

WP Mail SMTP. По умолчанию WordPress отправляет письма функцией PHP через сервер хостинга, и Яндекс с Mail.ru половину таких писем режут в спам. Плагин отправляет почту через нормальный SMTP вашего домена и снимает вечную проблему "заявки не приходят".

Limit Login Attempts Reloaded. Перебор паролей на форме входа идёт круглосуточно с момента запуска сайта. Плагин блокирует IP после нескольких неудачных попыток и вместе с мерами из статьи Как защитить сайт от взлома закрывает основной сценарий взлома WordPress.

Шесть категорий, которые мы не ставим

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

Конструкторы страниц поверх темы. Elementor, WPBakery и подобные тянут собственный движок вёрстки: десятки лишних запросов, сотни килобайт CSS и JS. На одном проекте отключение конструктора сняло 2 секунды загрузки. Вторая беда в том, что вёрстка хранится в его шорткодах: отказаться потом означает пересобрать все страницы вручную. Про вес сторонних скриптов писали в разборе как ускорить сайт.

Комбайны "всё в одном". Обещают сразу SEO, кэш, защиту, аналитику и картинки. Каждая функция сделана посредственно, отключить ненужные части нельзя, а при удалении отваливается всё разом.

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

Плагины статистики в админке. Пишут каждое посещение в базу и за полгода раздувают её на гигабайты. Яндекс.Метрика делает то же самое лучше и без нагрузки на ваш сервер.

Нулёвки с торрентов. Во взломанных сборках находят закладки: скрытого администратора, отправку данных на чужой сервер, ссылки в текстах статей. Экономия 5 000 рублей оборачивается восстановлением сайта за 30 000.

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

1. Дата обновления. Свежее полугода норма, старше года повод искать замену.
2. Число установок. До 1 000 велик риск, что автор бросит проект; от 100 000 уязвимости чинят быстро.
3. Открытые тикеты. Если последние 20 вопросов без ответа месяцами, автор отошёл от дел.
4. История уязвимостей. Проверяется по базам Patchstack и WPScan. Одна закрытая дыра нормально, пять за год признак низкого качества кода.
5. Что тянет с собой. Свои таблицы в базе и обращения к внешнему API на каждой загрузке бьют по скорости.
6. Совместимость. Не только с вашей версией PHP, но и в обратную сторону: не заблокирует ли плагин обновление ядра.

Сколько плагинов это много

Числа не существует, важен вес: один конструктор страниц вредит сильнее, чем десять мелких утилит без фронтенд-кода.

Ориентиры по практике: до 15 плагинов сайт обычно чувствует себя нормально, 20-25 требуют внимания, после 30 почти всегда есть что удалить. Решает измерение: ставим Query Monitor и смотрим, сколько запросов к базе и времени добавляет каждый. Обычно 3-4 позиции из тридцати дают основную нагрузку, с них и начинаем.

Деактивация не равна удалению

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

При удалении через админку WordPress убирает файлы, но собственные таблицы плагина в базе остаются почти всегда. Так и появляются базы на 3-4 гигабайта у сайта с сотней страниц.

Порядок чистки:

1. Бэкап файлов и базы, с проверкой, что копия разворачивается.
2. Деактивировать и неделю понаблюдать, не отвалилось ли что-то.
3. Удалять через админку, а не стиранием папки: часть плагинов при этом чистит за собой.
4. Проверить базу на осиротевшие таблицы с префиксом плагина.
5. Пройти по страницам: вместе с плагином пропадает шорткод, и на месте блока остаётся текст в скобках.

Порядок обновления, при котором сайт не падает

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

• Автообновления включаем только для ядра и мелких утилит без фронтенда.
• Перед пакетным обновлением делаем бэкап. Как настроить копии автоматически, разбирали в статье про бэкап сайта.
• Обновляем по одному, проверяя после каждого главную, страницу услуги и форму заявки.
• Мажорные версии сначала катим на копии сайта. Порядок описан в инструкции по обновлению CMS без падения сайта.
• Форму заявок проверяем отдельно: конфликт ломает её тихо, ошибок на экране нет, а заявки просто перестают приходить.

Ревизия на существующем сайте: порядок действий

1. Выпишите активные плагины и напротив каждого задачу, которую он решает. Строки, где написать нечего, кандидаты на удаление.
2. Отметьте всё, что не обновлялось больше года: это первоочередной риск независимо от полезности.
3. Найдите дубли по функциям: два плагина кэша, два SEO-плагина, три формы. Оставьте по одному.
4. Определите через Query Monitor 3-5 самых тяжёлых.
5. Сделайте бэкап и копию сайта на поддомене, все опыты сначала там.
6. Удаляйте по одному с паузой на наблюдение, а не пачкой за вечер.
7. Замерьте скорость до и после: чистка обычно даёт от 0,8 до 2 секунд на главной.
8. Зафиксируйте итоговый список и правило: новый плагин ставится только с обоснованием.

На аудит и чистку такого сайта уходит 6-10 часов, это входит в поддержку сайтов. Самостоятельно тоже реально, если не торопиться и делать бэкапы.

Правило, которое стоит завести

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

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