У одного из ваших плагинов дата Last updated, на которую уже неприятно смотреть? Желание поискать «его вообще еще обновляют?» - правильное. Заброшенный плагин может годами работать на сайте, и руки до него не доходят. Но «работает» и «получает исправления безопасности» - разные вещи.
Зачем вообще это проверять? Атакующие не выбирают сайты вручную, они сканируют интернет на плагины с известными дырами, а у плагина, который никто не чинит, такая дыра остается навсегда. Отключить его мало: файлы остаются на сервере, и это тот самый скрытый риск старых плагинов. Поэтому дальше - практика: смотрим признаки, решаем, что оставить, и меняем то, чему нельзя доверять.
Сначала откройте страницу плагина на WordPress.org
Если плагин размещен на WordPress.org, выделите пять минут на его страницу. По одной дате вывод не делайте - оценивайте картину целиком.
Last updated: Давно ли вышел последний релиз? Загляните в историю изменений. Свежая дата сама по себе не значит, что автор закрыл дыру в безопасности.Tested up to: Указана ли недавняя версия WordPress? Если плагин не заявляет совместимость с тремя последними крупными версиями, WordPress.org показывает желтое предупреждение: плагин «may no longer be maintained or supported» - возможно, его больше не поддерживают. Сигнал серьезный. А вот свежее значение доказывает меньше: разработчик может поправить поле в readme, не выпуская новый код.- Красное сообщение о закрытии: Если страница говорит, что плагин закрыт и недоступен для скачивания - «closed and isn’t available for download», не отмахивайтесь. Причиной может быть проблема с безопасностью, нарушение правил или просьба автора. Общую причину показывают через 60 дней. Сайты, где плагин уже стоит, не получат обновление или предупреждение в консоли просто из-за его закрытия.
- Форум поддержки: Не зацикливайтесь на числе решенных тем. Разработчики отвечают на свежие вопросы? Вопросы про безопасность не висят без ответа?
- История изменений и
Advanced View: Почитайте записи о релизах. Упоминания безопасности, очистки входных данных, экранирования, nonce-проверок и прав доступа полезнее многолетнего «исправлены ошибки». Сравните даты релизов с датами найденных сообщений об уязвимостях. - Число активных установок: Популярность не доказывает, что плагин поддерживают. Можно позже проверить, меняется ли число установок, но оценивать по нему безопасность не стоит.
Желтое предупреждение - повод копнуть глубже, а не срочно жать «Удалить». Оно зависит от поля в readme, поэтому проверьте реальные релизы. Красное сообщение о закрытии - другая история: скачать или установить плагин с WordPress.org уже нельзя, а установленному экземпляру исправление оттуда не придет.
Есть ли известная уязвимость без исправления?
Поищите название плагина в бесплатных базах Patchstack и Wordfence Intelligence. Откройте свежие записи об уязвимостях и найдите версию, в которой проблему исправили. No known fix или отсутствие исправленной версии означает, что кнопка «Обновить» здесь не спасет. Заодно сверьте версию у себя на сайте: исправление помогает, только если вы можете его получить и установить.
Зачем отдельная проверка? В отчете Patchstack State of WordPress Security in 2026 сказано, что для 46 % уязвимостей разработчики не успели выпустить исправление к моменту публичного раскрытия. Это не значит, что все такие плагины забросили навсегда. Но ждать апдейт, ничего больше не делая, - так себе план.
Если у вас несколько сайтов, сканер уязвимостей WordPress поможет увидеть, какие плагины у вас стоят и что по ним нашли. Но запись в базе все равно прочитайте: важно понять, затрагивает ли проблема именно вашу настройку.
А если плагин куплен не на WordPress.org?
У платных плагинов, которые продаются на других площадках, этих подсказок на WordPress.org нет. Идите на сайт продавца: проверьте дату последнего релиза, записи об исправлениях безопасности и срок лицензии. Если лицензия истекла, новые версии могут не появляться в консоли, хотя разработчик их выпускает. Найдите и контакт для сообщений об уязвимостях или правила их приема.
Для бизнеса в ЕС есть еще один повод спросить. Закон ЕС о киберустойчивости, Cyber Resilience Act, подталкивает продавцов коммерческого ПО - в том числе платных плагинов для пользователей из ЕС - принимать сообщения об уязвимостях и выпускать исправления. Требования к отчетности заработали в сентябре 2026 года, остальные вступят в силу в декабре 2027 года. Отсутствие опубликованных правил само по себе не делает плагин плохим. Но я бы спросил продавца, кому писать о найденной дыре.
Разве WordPress теперь не проверяет обновления плагинов?
Проверяет, но это решает другую задачу. В статье о том, как WordPress.org проверяет обновления перед выпуском, речь о новых релизах. Проверка помогает, только когда релиз вообще есть. Если плагин никто не поддерживает и исправление не выпускает, проверять и доставлять на сайт нечего. Вот этот пробел мы и ищем.
Что делать с заброшенным плагином
Не ставьте сразу первый похожий вариант. Для начала выясните, что старый плагин сейчас делает на сайте. Функцию, которой вы больше не пользуетесь, проще убрать, чем переносить.
- Уже не нужен? Запланируйте удаление. Сначала проверьте, не остались ли его формы, блоки и шорткоды на страницах.
- Функцию уже что-то выполняет? Возможно, ее взяли на себя сам WordPress, тема или другой установленный плагин. Минус один плагин - отличная замена.
- Все еще нужен? Ищите поддерживаемый вариант с понятной историей изменений и живой поддержкой.
- Нашли форк? Смотрите на разработчика и историю релизов, а не на знакомое название. В октябре 2024 года WordPress.org создал форк Advanced Custom Fields под названием Secure Custom Fields - такое бывает и с крупными плагинами. Но форк с одним релизом и без поддержки автоматически не лучше оригинала.
Если какое-то время без старого плагина никак, ограничьте доступ к его функции, где это возможно, отключите то, чем не пользуетесь, и продолжайте следить за базами уязвимостей. Это временная мера, не ремонт. А если для известной дыры нет исправленной версии, тишина в консоли WordPress ничего хорошего не доказывает.
Как заменить плагин и не сломать сайт
С магазином, где прямо сейчас идут заказы, я бы не торопился. Новый плагин может делать то же самое, но хранить данные иначе. Лучше проверить перенос самим, чем поручить эту проверку покупателям.
- Сделайте бэкап и тестовую копию сайта. До изменений на рабочем сайте убедитесь, что копию можно восстановить. Если у хостинга уже есть тестовый сайт, за него часто не надо платить отдельно; на подготовку заложите хотя бы полчаса.
- Запишите, за что отвечает старый плагин. Настройки, шорткоды, блоки, данные. Проверьте страницы и шаблоны, где виден результат его работы.
- Поставьте замену на тестовую копию. Настройте ее там и перенесите нужные данные. Простая смена плагина не обязана переносить старые записи.
- Проверьте реальные сценарии. Отправьте форму, пройдите оформление заказа, если продаете онлайн, откройте страницы с нужной функцией. Посмотрите на сайт глазами посетителя, не только администратора.
- Переключите рабочий сайт в спокойный час. Перенесите проверенную настройку, отключите старый плагин, затем удалите его. После одного лишь отключения файлы останутся на сервере.
- Поищите остатки. Проверьте, не торчат ли на страницах шорткоды, не сломались ли блоки и не пропали ли данные. День-два заглядывайте в журнал ошибок.
Если такую работу приходится повторять на нескольких сайтах, в обслуживание WordPress от 39 € в месяц можно включить проверки и аккуратную замену плагинов. Запланировать и протестировать перенос куда приятнее, чем разбираться с ним в разгар оформления заказов.
Одна проверка на сегодня
Откройте список плагинов и выберите три, у которых вы не замечали обновлений целый год. Проверьте их страницы на WordPress.org или историю релизов у продавца, если плагины платные. Потом поищите каждое название в базах уязвимостей. Менять все три сегодня не нужно. А вот узнать, какой из них ждет исправления, которое может и не выйти, - стоит.