Взломанный WordPress: что делать в первый час и как защититься

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

Ниже Вы найдёте признаки взлома, план на первый час, способ снять предупреждение в Google Search Console и 10 мер защиты примерно на 30 минут. Я опираюсь на рекомендации WordPress.org и документацию Google.

Признаки: как понять, что WordPress взломали

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

• Перенаправления только для некоторых. Google в справке Search Console описывает скрипты, добавленные хакерами, которые перенаправляют пользователей телефонов на вредоносные сайты. Вы вводите адрес на компьютере и видите обычный сайт, а клиент, зашедший из результатов Google со смартфона, попадает на мошенников.
• Чужие страницы в Google. Введите в поисковик site:yourdomain.pl и просмотрите результаты. Японские заголовки, лекарства, казино или подделки брендовой одежды — как правило, это спам, внедрённый хакерами. Вариант с японскими иероглифами Google называет «Japanese keyword hack»: это автоматически сгенерированные страницы со ссылками на магазины подделок.
• Новые администраторы. В панели WordPress есть учётная запись, которую никто в компании не создавал, или Search Console сообщает, что кто-то новый подтвердил право собственности на Ваш сайт. По мнению Google, это веский признак того, что произошёл взлом.
• Предупреждения Google. Рядом с Вашим сайтом в результатах поиска появляется пометка «Сайт может быть взломан», а Chrome показывает полноэкранное предупреждение, например о вредоносном ПО.
• Блокировка со стороны хостинга. Провайдер отключает сайт или присылает письмо о вредоносных файлах. WordPress.org называет это среди однозначных признаков взлома.
• Корпоративная почта попадает в спам. Взломанный сайт нередко используют для рассылки спама, и тогда IP-адрес сервера попадает в чёрные списки. Если почта работает на том же сервере, страдают и Ваши предложения.

Остерегайтесь ловушки: взломанные страницы могут показывать обычному посетителю ошибку 404, а роботу Google — спам. Чтобы увидеть то, что видит Google, воспользуйтесь в Search Console инструментом проверки URL и кнопкой «Проверить опубликованный URL».

Чего не делать в первые минуты

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

• Не удаляйте файлы вслепую. Вы теряете следы, по которым можно определить, как проникли хакеры. Вы устраните симптом, а уязвимость останется.
• Не восстанавливайте копию, не закрыв уязвимость. В копии до атаки, как правило, та же дыра, например устаревший плагин, поэтому атака может повториться.
• Не меняйте пароли с компьютера, который может быть заражён. WordPress.org напоминает, что атака часто начинается с трояна на компьютере владельца, который крадёт пароли от FTP и панели.
• Не просите Google о проверке сразу. Google прямо пишет, что преждевременный запрос лишь удлиняет время, в течение которого сайт помечен как опасный.

План действий на первый час

Этот список стоит распечатать и хранить вместе с данными доступа к хостингу. Время указано ориентировочно.

1. Запишите симптомы (5 минут). Что Вы видите, с какого времени и на каком устройстве. Сделайте скриншоты и отметьте последние изменения на сайте, например новый плагин. С этого начинается руководство WordPress.org для взломанных сайтов.
2. Позвоните в хостинг (10 минут). Спросите, что они обнаружили и в каких файлах. Попросите логи сервера, пока их не удалили, и список резервных копий с датами.
3. Сделайте копию заражённого сайта (10 минут). Файлы и базу данных скачайте на диск вне сервера, в папку с понятным названием, например INFECTED-2026-10-25. Google и WordPress.org рекомендуют сделать это до любого удаления. Эта копия служит для анализа и никогда не используется для восстановления.
4. Ограничьте ущерб (5 минут). Если сайт перенаправляет клиентов на мошенников или распространяет вредоносные файлы, попросите хостинг временно отключить сайт.
5. Проверьте компьютер (2 минуты на запуск). Запустите полную проверку антивирусом на компьютере, с которого Вы входите в WordPress. Дальнейшие шаги выполняйте с другого, чистого устройства.
6. Смените пароли (10 минут). Панель хостинга, FTP/SFTP, пользователь базы данных (новый пароль впишите и в wp-config.php), все администраторы WordPress и почтовый ящик, на который приходят ссылки для сброса паролей. Затем замените ключи безопасности в wp-config.php на новые из официального генератора WordPress.org. Это завершит сеансы всех пользователей, в том числе злоумышленника.
7. Удалите чужие учётные записи (5 минут). В WordPress просмотрите пользователей с ролью «Администратор», а в Search Console — Настройки → Пользователи и разрешения. Перед удалением запишите логин, e-mail и дату создания учётной записи. Удалите с сайта и токен подтверждения прав злоумышленника (HTML-файл или метатег), иначе, как пишет Google, удалённый владелец сможет снова подтвердить право собственности.
8. Обновите и проверьте (10 минут). Обновите WordPress, плагины и темы. Запустите сканер в панели (WordPress.org упоминает, в частности, Wordfence и Sucuri) и внешний сканер, например Sitecheck. Обновление закрывает уязвимость, но не удаляет файлы, добавленные хакерами.

Если на сайте есть заказы, аккаунты клиентов или сохранённые сообщения из форм, проверьте, не могли ли данные утечь. Согласно ст. 33 GDPR (RODO) администратор уведомляет о нарушении UODO (Urząd Ochrony Danych Osobowych, польское Управление по защите персональных данных) без неоправданной задержки, по возможности не позднее чем через 72 часа после его обнаружения, если только нарушение вряд ли приведёт к риску для прав или свобод клиентов. Уведомление, отправленное после 72 часов, должно объяснять причины задержки, а при высоком риске ст. 34 GDPR требует также уведомить самих клиентов. Форма есть на сайте UODO. Это общая информация, а не юридическая консультация (правовое состояние на 25 октября 2026 г.), поэтому оценку конкретной утечки обсудите с юристом или инспектором по защите данных.

Очистка: копия до атаки или ручная чистка

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

Ручная чистка остаётся, когда копии нет или она слишком старая. WordPress.org рекомендует заменить по SFTP каталоги wp-admin и wp-includes свежими, той же версии, что у Вас. Переустановки из панели недостаточно, потому что она перезаписывает файлы, но не удаляет те, что добавили хакеры. Плагины и темы скачайте заново из официальных источников, а особенно внимательно просмотрите .htaccess, index.php, а также header.php, footer.php и functions.php в теме.

Технический специалист с доступом по SSH проверит самое важное быстрее через WP-CLI:

# файлы WordPress, сверенные с контрольными суммами WordPress.org
wp core verify-checksums
# то же для плагинов из официального каталога
wp plugin verify-checksums --all
# администраторы с датой создания учётной записи
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# PHP-файлы в каталоге с изображениями, где их быть не должно
find wp-content/uploads -name "*.php"

Когда сайт чист, смените пароли ещё раз: WordPress.org рекомендует это и тогда, когда пароли уже были изменены в момент обнаружения атаки. В конце проверьте сайт моим инструментом «Проверить сайт». Он не ищет вирусы, но примерно за 30 секунд покажет, работает ли HTTPS, есть ли заголовки безопасности и не выдаёт ли сервер версию программного обеспечения.

Google Search Console: как снять предупреждение

Без Search Console Вы не сможете попросить Google о повторной проверке. Как добавить в неё сайт, я описываю в статье Сайт компании не отображается в Google.

1. Откройте отчёт «Проблемы безопасности». Вы увидите тип проблемы, например «Взлом: внедрённый контент» или «Взлом: вредоносное ПО», и примеры адресов.
2. Загляните также в отчёт «Меры, принятые вручную». Если там есть запись, после очистки запросите проверку и в нём.
3. Проверьте примеры адресов инструментом проверки URL. Они должны показывать чистый контент или ошибку 404.
4. Нажмите «Запросить проверку» и коротко опишите, что сделано по каждому виду проблем: удалённые страницы, обновлённый плагин, смена паролей.

Сколько это занимает? По данным Google, проверка фишингового сайта занимает около суток, сайта с вредоносным ПО несколько дней, а сайта со спамом, внедрённым хакерами, даже несколько недель.

10 мер защиты за 30 минут

Список основан на рекомендациях WordPress.org по защите сайта.

1. Автоматические обновления (5 минут). Начиная с WordPress 5.5 их можно включить для любого плагина и темы, а в списке плагинов также сразу для всех.
2. Удалите неиспользуемые плагины и темы (4 минуты). Именно удалите, а не просто отключите: отключённый плагин по-прежнему лежит на сервере.
3. Плагины только из надёжного источника (2 минуты). WordPress.org пишет прямо: не устанавливайте плагины и темы из ненадёжных источников, только из официального каталога или от известных компаний. Версии «nulled», то есть пиратские копии платных плагинов, по данным компании Wordfence, часто содержат скрытые лазейки для хакеров.
4. Двухэтапная аутентификация (5 минут). Для каждого администратора, например с помощью плагина Two Factor от сообщества WordPress.org: код из приложения на телефоне и резервные коды. Включите её и в панели хостинга.
5. Меньше администраторов (2 минуты). Сотруднику, который добавляет записи, нужна роль «Редактор» или «Автор». Не используйте логин «admin».
6. Пароли из менеджера паролей и SFTP (3 минуты). Длинный уникальный пароль для каждого доступа. Вместо обычного FTP, который передаёт пароль открытым текстом, используйте SFTP.
7. Копии вне сервера (5 минут). Копия на том же сервере может пропасть или быть заражена вместе с сайтом. Настройте автоматическое копирование файлов и базы данных в облако или на другой сервер, храните несколько версий и раз в квартал проверяйте, что копия восстанавливается.
8. Актуальная версия PHP (1 минута). WordPress.org рекомендует PHP 8.3 или новее, а PHP 8.2 получает исправления безопасности только до 31 декабря 2026 г. Версию можно изменить в панели хостинга, предварительно сделав копию.
9. Уведомления из Search Console (2 минуты). Google отправляет подтверждённым владельцам письмо по e-mail, когда подозревает взлом. Проверьте, включены ли уведомления и не перехватывает ли их почтовый фильтр.
10. Отключите редактор файлов (1 минута). Строка ниже, добавленная в wp-config.php, блокирует редактирование PHP-файлов из панели. Она не остановит любую атаку, но закрывает самый простой путь.

define( 'DISALLOW_FILE_EDIT', true );

Есть и путь, при котором большая часть этого списка отпадает. Простой сайт компании без магазина и аккаунтов клиентов может работать как обычные файлы, без плагинов, которые нужно латать. Именно так я перенёс более 200 страниц сайта компании Żukowscy с WordPress и Elementor на Next.js в рамках модернизации сайта. Минус: изменения контента потребуют тогда другой панели или моей помощи.

Итог

При взломе важен порядок: сначала заметки и копия, затем пароли, учётные записи и обновления, в конце очистка и запрос к Google. Спешка с удалением файлов или восстановлением старой копии часто заканчивается повторной атакой.

Если Вы предпочитаете не следить за обновлениями и копиями самостоятельно, я делаю это в рамках технической поддержки от 149 зл без НДС в месяц. Аудит безопасности с отчётом и исправлениями стоит от 990 зл без НДС. Если сайт уже взломан, напишите мне: отвечу в течение 24 часов с планом действий и расчётом стоимости.