Сколько плагинов WordPress нужно: золотая середина

Каталог на 40 позиций, из них половина «на всякий случай» и не включалась год. PageSpeed Mobile — 38, после обновления одного SEO-комбайна — белый экран. В практике это не «WordPress плохой», а накопленный хаос в разделе «Плагины». Ниже — как найти золотую середину: сколько расширений реально нужно, что удалить первым делом и когда выгоднее написать 50 строк кода, чем ставить очередной комбайн.

Миф «чем больше плагинов — тем хуже сайт»

Число само по себе не приговор. Бывает сайт с 12 лёгкими плагинами быстрее, чем с пятью тяжёлыми «комбайнами». Важны три вещи:

• Вес каждого плагина — сколько CSS/JS и SQL-запросов добавляет на каждой странице.
• Дубли функций — два SEO, два кэша, три счётчика аналитики.
• Состояние — активен ли плагин, обновлялся ли за последний год, совместим ли с PHP 8.2+.

Ориентир из практики для типового корпоративного сайта или каталога без экзотики:

• 8–15 активных плагинов — нормальная рабочая зона.
• 15–25 — уже повод для аудита: ищем дубли, «мертвые души» и комбайны.
• 25+ — почти всегда находятся 5–10 лишних, плюс риск конфликтов при каждом обновлении.

Магазин на WooCommerce + Elementor закономерно тяжелее визитки — но принцип тот же: каждый плагин должен решать одну задачу, которую нельзя закрыть проще.

Как накапливается «плагинный хлам»

Редко кто ставит 30 расширений за один день. Обычно сценарий такой:

1. «Нужна форма» — ставят Contact Form 7. Через полгода «нужен слайдер» — ставят отдельный плагин, хотя слайдер уже есть в теме.
2. «Сайт тормозит» — ставят WP Rocket поверх LiteSpeed Cache, не отключив первый.
3. «Нужна Метрика» — ставят плагин аналитики, потом ещё один «для удобства», плюс код из старой темы — итого три счётчика на одной странице.
4. «Попробовали альтернативу SEO» — Rank Math поставили, Yoast не удалили «на всякий случай».
5. Подрядчик ушёл, плагины остались — половина уже не нужна, но страшно трогать.

Через 2–3 года админка превращается в свалку. Каждое обновление ядра или PHP — лотерея: critical error или белый экран вместо заявок.

Дубли: одна задача — один инструмент

Самые частые пары-дубли, которые видим на аудитах:

SEO

Yoast SEO, Rank Math, All in One SEO, SEOPress — достаточно одного. Базовая настройка title, sitemap и Вебмастера — в чек-листе SEO для WordPress. Два SEO-плагина одновременно дают:

• дублирующиеся title и description в HTML;
• конфликт sitemap.xml (два файла карт сайта);
• лишние запросы к БД на каждой странице админки.

Выбираем один, настраиваем, второй — удаляем (не деактивируем «на потом»).

Кэш и оптимизация

Одновременно не должны работать: WP Rocket + LiteSpeed Cache, W3 Total Cache + Autoptimize с пересекающимися функциями, два плагина «оптимизации изображений» (ShortPixel + Imagify + Smush).

Правило: один кэш-плагин, один оптимизатор картинок. Подробнее про связку кэша и WebP — в статье «Как ускорить сайт на Elementor».

Безопасность

Wordfence + iThemes Security + Sucuri — типичная тройка, которая замедляет админку и блокирует легитимные действия. Достаточно одного решения плюс базовая гигиена из чек-листа защиты.

Формы и SMTP

CF7 + WPForms + Fluent Forms «на пробу» — оставляем одну связку. Для доставки писем — один SMTP-плагин (настройка SMTP), а не три разных «починщика почты».

Бэкапы

UpdraftPlus + BackWPup + встроенные бэкапы хостинга — нормально, если роли разделены (один плагин + облако). Плохо — три плагина бэкапа, каждый гоняет cron и жрёт память. Сравнение способов — в статье про бэкапы.

Аналитика: Метрика не требует плагина

Один из самых бессмысленных «раздуваний» — аналитика через плагины.

Яндекс.Метрика ставится одним из способов:

• код счётчика в header.php темы или через «Вставка кода в header/footer» в настройках темы (Astra, GeneratePress, Kadence);
• хук wp_head в functions.php дочерней темы — 10 строк, без плагина;
• если нужен плагин — один, например «Яндекс.Метрика» от Яндекса или Insert Headers and Footers.

Типичная ошибка: MonsterInsights для Google Analytics + отдельный плагин для Метрики + GTM через четвёртый плагин + старый код в footer от прошлого подрядчика. Итог — 150–400 КБ лишнего JavaScript, PageSpeed падает на 5–15 пунктов, данные в отчётах дублируются.

Google Analytics 4 — аналогично: один тег через GTM или один лёгкий плагин. Не нужен тяжёлый «комбайн аналитики», если задача — просто видеть посещаемость.

Конфликты: почему сайт ломается «сам»

Плагины — это чужой PHP-код, который цепляется к одним и тем же хукам WordPress. Когда два плагина делают одно и то же на одном хуке с разной логикой — получаем:

• fatal error после обновления (несовместимость с PHP 8.2);
• бесконечный редирект (два SEO-плагина правят canonical);
• зависание AJAX (кэш-плагин режет admin-ajax.php — знакомый кейс с CF7);
• пустая корзина WooCommerce (конфликт сессий и кэша) — разбор в отдельной статье.

Чем больше плагинов — тем больше комбинаций. На сайте с 30 расширениями вероятность конфликта при очередном «Update All» растёт почти линейно.

Как локализовать виновника за 15 минут:

1. Включить WP_DEBUG_LOG в wp-config.php (на staging или временно на бою).
2. Переименовать папку wp-content/plugins в plugins.off по FTP — сайт должен ожить (без функционала плагинов).
3. Вернуть имя, отключать плагины пачками по 5 через базу или плагин Health Check (режим troubleshooting).
4. После каждого шага — проверять проблемную страницу.

Подробный алгоритм при падении после обновления — в материале про ошибку 500.

Устаревшие плагины — тихая угроза

В списке плагинов красная точка «требуется обновление» — ещё терпимо. Хуже другое:

• плагин не обновлялся 12+ месяцев — автор мог бросить проект;
• последняя версия помечена «не протестировано с WordPress X.X»;
• плагин скачан с «нулёвого» сайта — без лицензии и без обновлений вообще.

Последствия предсказуемы: дыра для ботов (см. план при взломе), fatal error после перехода на PHP 8.3, несовместимость с WordPress 7.0.

Что делать с «брошенным» плагином:

1. Найти поддерживаемую альтернативу с той же функцией.
2. Если альтернативы нет — оценить кастомный код или отказ от функции.
3. Не обновлять ядро и PHP, пока не решён вопрос с критичным устаревшим плагином — иначе сайт ляжет в самый неудобный момент.

Когда плагин — правильный выбор, а когда — кастом

Плагин оправдан, когда:

• нужна сложная логика (WooCommerce, CRM, доставка СДЭК, многоязычность);
• есть официальный поддерживаемый плагин от сервиса (ЮKassa, AmoCRM);
• задача стандартная и плагин решает её «из коробки» за 30 минут (CF7, Rank Math, UpdraftPlus).

Кастом (код в mu-plugin или дочерней теме) выгоднее, когда:

• нужна одна простая функция — редирект, фильтр, шорткод, вывод поля ACF;
• комбайн весит 1–3 МБ и грузит админку ради одной галочки в настройках;
• плагин давно не обновляется, а функция — 20 строк PHP через хук.

Примеры из практики:

• Вместо плагина «Disable Comments» на всём сайте — три строки в functions.php.
• Вместо тяжёлого «Custom CSS/JS» для одного скрипта Метрики — хук wp_footer.
• Вместо page builder ради одного блока «цены» — шаблон page-prices.php в теме.

Кастом не значит «навсегда без поддержки»: код в дочерней теме или mu-plugin переживает обновление родительской темы и документируется в одном файле. При необходимости — подключаем программиста на точечную задачу, а не ставим очередной комбайн.

Аудит плагинов: пошаговый чек-лист на 1–2 часа

Перед чисткой — полный бэкап (файлы + БД). Дальше по каждому плагину в списке «Плагины»:

• Активен и реально используется? Нет → деактивировать, неделю понаблюдать, удалить.
• Обновлялся за последние 12 месяцев? Нет → искать замену или кастом.
• Есть дубль с другим плагином? Да → оставить один, второй удалить.
• Добавляет CSS/JS на всех страницах? Настроить загрузку только где нужно или заменить.
• Нужен только админам? Проверить через Query Monitor, не грузит ли фронт.
• Можно заменить 10–30 строками кода? Обсудить с разработчиком, убрать комбайн.

Инструменты для аудита:

• Query Monitor — показывает, какой плагин сколько запросов и времени добавляет (ставим временно, потом удаляем).
• Health Check — режим troubleshooting без влияния на посетителей.
• WP Quick Check — снаружи видно, сколько плагинов «светится» в HTML (лишние следы — сигнал).
• PageSpeed Insights / Яндекс.Вебмастер → «Скорость» — до и после чистки.

Типичный результат аудита на «запущенном» сайте: удаляют 5–12 плагинов, PageSpeed Mobile растёт на 10–25 пунктов, админка перестаёт «висеть», обновления проходят спокойнее. Это не магия — просто убрали балласт.

Золотая середина: рабочий набор по типам сайтов

Не догма, а ориентир — что обычно остаётся после чистки:

Визитка / корпоративный сайт (без магазина)

• SEO — один (Rank Math или Yoast).
• Формы — CF7 или Fluent Forms.
• Кэш — LiteSpeed Cache или WP Rocket (если хостинг не LiteSpeed).
• Бэкап — UpdraftPlus или бэкап хостинга + облако.
• Безопасность — Limit Login Attempts + 2FA (или один Wordfence).
• Метрика — код в теме, без плагина.

Итого: 6–10 активных — комфортная зона.

Интернет-магазин WooCommerce

• Всё выше + WooCommerce и платёж/доставка (ЮKassa, СДЭК — официальные плагины).
• SMTP для писем о заказах — один (если письма не доходят).
• Не плодить «улучшайзеры корзины», если хватает настроек Woo + темы.

Итого: 12–18 активных — норма; больше 22 — повод для ревизии.

Сайт на Elementor

• Elementor + Pro (если нужен) + один аддон-пак (Crocoblock или Essential Addons — не оба).
• Остальное — по минимуму из списков выше.

Каждый лишний аддон — +30–80 виджетов в памяти редактора. Отключение неиспользуемых виджетов в настройках аддона часто даёт больше, чем установка «ускорителя».

Что НЕ делать

• Не ставить плагин «на попробовать» и не удалять. Деактивированный плагин всё равно обновляется и может тянуть уязвимости.
• Не жать «Обновить все» без бэкапа. Особенно перед обновлением PHP или major-версии WordPress.
• Не ставить nulled-плагины. Экономия 3 000 ₽ на Pro-лицензии оборачивается бэкдором и потерей позиций в Яндексе.
• Не ускорять скорость новым плагином поверх старого. Сначала аудит, потом одна связка кэш + изображения.
• Не дублировать Метрику и GA через три разных расширения. Один способ вставки кода на сервис.
• Не оставлять два SEO и два кэша «на всякий случай». «На всякий случай» — это +200 мс TTFB и риск конфликта.

Когда звать специалиста

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

• плагинов 25+ и непонятно, что отключит оплату или CRM;
• сайт уже падает после обновлений, а виновник не находится за час;
• нужна замена «брошенного» плагина с критичной бизнес-логикой;
• после аудита PageSpeed всё ещё ниже 50 на Mobile — проблема глубже (хостинг, тема, БД).

Разберём список плагинов, уберём дубли, предложим кастом вместо комбайнов и замерим «до/после» — подробности об ускорении и регулярная поддержка, чтобы хаос не вернулся через полгода.

Для первичной проверки снаружи — бесплатный WP Quick Check: покажет тему, версию ядра и следы плагинов в HTML до входа в админку.