Первый час решает, потеряете вы позиции в поиске или нет. Смените пароли от хостинга, админки, FTP и базы, снимите копию заражённого сайта «как есть» для разбора и закройте сайт заглушкой, если он рассылает спам или редиректит посетителей. Дальше — точка входа, чистая версия, закрытая уязвимость и лечение сайта от вредоносного кода, если чистить самостоятельно некому.
Короткий ответ: план на 24 часа
Ниже — таблица по окнам. Действия внутри окна можно переставлять местами. Порядок самих окон — нет: смена паролей раньше снятия копии обнулит часть улик, а слишком ранняя заглушка помешает найти точку входа по живому трафику.
| Окно | Что сделать | Чего не делать |
| 0–1 ч | Сменить пароли хостинга, админки, FTP, БД. Снять полную копию сайта и логов «как есть». Заглушка — если сайт рассылает спам или редиректит | Не переустанавливать CMS «с нуля»: сотрёте улики |
| 1–4 ч | Найти изменённые за последние дни файлы, новых админов и cron-задачи. Проверить логи доступа на подозрительные IP | Не публиковать в соцсетях о взломе до диагностики масштаба |
| 4–12 ч | Откатиться на чистую копию или вычистить код вручную, закрыть найденную уязвимость, обновить CMS и плагины | Не открывать заглушку раньше, чем закрыта точка входа |
| 12–24 ч | Снять пометку в Вебмастере и Search Console, запросить перепроверку, включить мониторинг файлов | Не ждать, что пометка снимется сама — без запроса она висит неделями |
Четыре окна, четыре разных задачи. Смешивать их не нужно.
Как понять, что сайт взломан
Не каждое подозрение — взлом. Но каждый из этих признаков заслуживает проверки в первый же час. Таблица переводит симптом в диагноз и в действие.
| Что видите | Что это скорее всего | Первое действие |
| Пометка «сайт может угрожать безопасности вашего компьютера» в поиске | Заражение обнаружил краулер Яндекса или Google | Открыть «Безопасность и нарушения» в Вебмастере, смотреть тип заражения |
| Редирект срабатывает только с мобильных | Мобильный клоакинг: вредоносный код показывает разный контент ботам и людям | Проверить исходный код страницы через curl с мобильным User-Agent |
| С домена уходит спам-рассылка | Почтовый скрипт или веб-шелл на сервере рассылает письма | Смотреть очередь исходящей почты на хостинге, искать посторонние php-файлы |
| В индексе Яндекса или Google чужие страницы (казино, реплики, фарма) | Дорвей-заражение: злоумышленник добавил тысячи скрытых страниц | Выгрузить список URL из Вебмастера, сверить со структурой сайта |
| Хостинг заблокировал аккаунт или отключил сайт | Автоматическая защита среагировала на аномальную активность | Написать в поддержку хостинга, запросить причину и логи блокировки |
Одного признака достаточно, чтобы запустить план. Ждать второго — терять время.
Часы 0–1: пароли, копия «как есть», заглушка
Порядок смены паролей имеет значение. Сначала хостинг-панель: она открывает доступ ко всему остальному. Затем админка CMS, FTP или SSH, база данных. Если старые пароли хранились в открытом виде в коде или в почтовой переписке — считайте скомпрометированными и их тоже, даже если они формально не «взломаны». Двухфакторная защита на этом этапе не спасёт: пока не сменены секреты, действителен старый доступ, и никакой второй фактор его не отменяет.
Дальше — копия. Снимите архив файлов и дамп базы «как есть», до всех правок. Без этой копии точку входа не найти: как только начнётся чистка, следы взломщика начнут исчезать вместе с изменёнными файлами. Архив храните за пределами заражённого хостинга. Если скомпрометирован весь аккаунт, копия внутри него бесполезна — злоумышленник получит доступ и к ней.
Заглушку ставят не всегда. Сайт с редиректами, спам-страницами или майнером в браузере посетителя закрывают немедленно: репутационный урон растёт с каждым часом открытого доступа. Сайт с испорченной, но безопасной для посетителей главной страницей можно оставить открытым на время диагностики. Так меньше теряется живой трафик, а лишнюю правку вносить не приходится дважды.
Часы 1–12: точка входа и восстановление
Где искать точку входа
Три источника закрывают почти весь вопрос. Файлы, изменённые за последние 2–4 недели: на хостинге с shell-доступом — команда find по времени модификации, в панели без shell — сортировка файлового менеджера по дате. Список администраторов и пользователей с правами публикации: злоумышленник чаще создаёт нового пользователя, чем ворует существующего. Access-логи веб-сервера: массовые POST-запросы к одному URL, обращения к несуществующим файлам, необычные User-Agent в дни перед заражением.
Устаревший плагин, тема или модуль почти всегда в списке подозреваемых первым. Сверьте версии установленных компонентов с changelog на сайте разработчика. Отставание на несколько релизов при упоминании безопасности в списке изменений — почти наверняка точка входа.
Помимо устаревших компонентов, разбор десятков инцидентов техподдержкой обычно указывает на несколько повторяющихся сценариев: слабый или переиспользованный на разных сайтах пароль администратора; фишинговое письмо, из-за которого пароль от админки попал к злоумышленнику напрямую; уязвимая форма обратной связи без проверки загружаемых файлов, через которую на сервер закинули веб-шелл; заражённый вирусом рабочий компьютер, с которого сохранённые в браузере пароли от FTP и хостинга ушли третьим лицам. Каждый из этих путей оставляет свой след в логах, и найденный след определяет, что чинить в первую очередь — не только код на сервере, но иногда и процесс работы с доступами внутри компании.
Если сайт на WordPress
На WordPress признаком вторжения нередко оказывается белый экран после автообновления плагина, а не заражённый файл: конфликт кода выглядит как взлом, но им не является. Если ошибка появилась без ваших действий и без недавних обновлений — это, скорее, именно взлом, и разбирать его нужно так же: пароли, копия, точка входа. Если же перед ошибкой обновлялся плагин или тема — вероятнее конфликт кода, а не заражение. Порядок на случай, если это белый экран и критическая ошибка WordPress, разобран в отдельной статье и пригодится, если после проверки взлом не подтвердится.
Чистка или откат
Здесь два пути. Первый — вручную вычистить изменённые файлы и записи в базе, сверяя с чистой версией CMS и плагинов. Подходит, если заражение точечное и найдено полностью, без остатков. Второй — откат на резервную копию, снятую до заражения, с последующим накатыванием легитимных правок поверх неё. Быстрее и надёжнее первого, если копия действительно рабочая, а не просто существует. Резервные копии, которые хранятся отдельно от сайта, не пострадают вместе с сервером и остаются пригодны для отката даже при полной компрометации хостинга. Как восстановить сайт из чистой копии и проверить, что она рабочая, — тема отдельного материала.
Каким бы путь ни был, следующий шаг один: закрыть уязвимость. Обновление CMS без закрытия дыры, через которую вошли, вернёт заражение за считаные дни.
Если утекли персональные данные: 24 и 72 часа
Если среди украденного были данные посетителей — заказы, телефоны, адреса, платёжные реквизиты, — включаются отдельные сроки уведомления. По ч. 3.1 ст. 21 152-ФЗ оператор обязан сообщить уполномоченному органу по защите прав субъектов персональных данных о самом факте инцидента в течение 24 часов и о результатах внутреннего расследования — в течение 72 часов (текст статьи: consultant.ru, проверено 29.09.2026). Эта статья не юридическая консультация. Как классифицировать конкретный инцидент и что именно писать в уведомлении, решает юрист. Порядок, как уведомить Роскомнадзор об утечке персональных данных, разобран в отдельном материале о 152-ФЗ для сайта.
Снять пометку «опасный сайт»: Вебмастер и Search Console
Пометка не исчезает сама после чистки. Её нужно снять запросом. В Яндекс Вебмастере откройте раздел «Безопасность и нарушения», убедитесь, что список заражённых страниц пуст, и отправьте сайт на перепроверку. Срок зависит от частоты обхода и типа проблемы; повторное заражение того же домена увеличивает интервал между проверками (источник: справка Вебмастера о безопасности сайта, проверено 29.09.2026).
В Google Search Console аналог — отчёт «Проблемы безопасности». После устранения всех пунктов на всех страницах откроется кнопка «Запросить проверку». К запросу разумно приложить короткое описание найденной причины и предпринятых шагов: это ускоряет рассмотрение (источник: справка Search Console о проблемах безопасности, проверено 29.09.2026). Само рассмотрение занимает от нескольких дней до нескольких недель.
Обе системы независимы. Снятие пометки в одной не снимает её в другой. Подавайте оба запроса, даже если кажется, что достаточно одного.
Помимо самих поисковых систем, репутацию домена держат и сторонние списки блокировок, на которые ориентируются антивирусы и браузерные расширения безопасности: попадание в такой список тормозит переходы по ссылке даже после снятия пометки у Яндекса и Google. Проверить текущий статус домена по нескольким источникам одновременно можно через открытые агрегаторы вроде VirusTotal — там же видно, какой именно антивирусный движок посчитал сайт опасным, и это ускоряет запрос на исключение из конкретного списка.
Как не повторить
Четыре вещи снижают риск повторного заражения сильнее прочих.
Обновления CMS, плагинов и тем — без пауз на «протестировать потом». Критические патчи безопасности ставят в день выхода. Остальные — в ближайшее плановое окно, а не когда найдётся время.
Двухфакторный вход в админку и на хостинг. Даже украденный пароль без второго фактора бесполезен для входа: злоумышленнику нужен ещё код из приложения или SMS, которого у него нет.
Резервные копии за пределами сервера, куда взломщик не дотянется вместе с заражённым сайтом. Копия внутри того же аккаунта хостинга — иллюзия защиты, а не защита.
Мониторинг изменения файлов, который присылает уведомление раньше, чем проблему заметят посетители или поисковик. Разница между «узнали через час» и «узнали через неделю по жалобе клиента» — это разница между устранённым инцидентом и полноценным репутационным кризисом.
Кто и за сколько реагирует
Если за поддержку отвечает подрядчик, а не штатный специалист, время реакции на инцидент — не абстракция, а строка в договоре. Пакет с реакцией 15 минут заметно сокращает окно уязвимости по сравнению с часом ожидания. Какое время реакции в договоре на поддержку закрепить — разбор в статье про договор на техподдержку сайта. Плановая техподдержка сайта закрывает большинство точек входа до того, как ими успевают воспользоваться — регламент проверок по дням, неделям и месяцам в отдельном материале.
Частые вопросы
Нужно ли платить хостингу за снятие блокировки?
Зависит от хостинга. Часть провайдеров снимает блокировку бесплатно после подтверждения, что заражение устранено, часть берёт плату за ручную проверку аккаунта. Уточняйте условия в тикете при обращении — единого правила у рынка нет.
Сколько ждать, пока Яндекс снимет пометку после чистки?
Единого срока нет. Он зависит от частоты обхода сайта и от того, заражался ли домен раньше. При первом инциденте перепроверка обычно проходит быстрее, чем при повторном: интервалы между проверками у Яндекса растут с каждым новым заражением одного и того же сайта.
Можно ли восстановить сайт без резервной копии?
Можно, но дольше и рискованнее. Придётся вручную вычищать код и сверять базу без эталона для сравнения. Часть контента и настроек в этом случае не восстановить — только то, что осталось не тронутым вредоносным кодом.
Что делать, если взлом произошёл через подрядчика с доступом к сайту?
Сменить пароли и отозвать доступы у всех, включая подрядчика, до выяснения причины — это стандартная гигиена при инциденте, а не обвинение. Дальше разбираться, был ли доступ подрядчика точкой входа, нужно по логам, а не по догадкам: логи покажут точное время и IP входа.
Могут ли конкуренты специально пометить сайт как опасный?
Сама пометка ставится автоматически по результатам сканирования, а не по жалобе конкурента. Но конкурент теоретически может попытаться подсадить вредоносный код через уязвимость — тогда пометка окажется честной реакцией на реальное заражение, а не результатом чужого доноса.
Сколько стоит лечение сайта от вирусов?
Цена зависит от масштаба заражения. По расценкам на 29.09.2026: локальная проблема на одном приложении — от 10 000 ₽, заражение нескольких систем — от 25 000 ₽, устойчивая угроза с откатом и усилением защиты по всему хостинг-аккаунту — от 50 000 ₽ (страница лечения сайта от вредоносного кода). Итоговая сумма зависит от того, сколько времени заражение оставалось незамеченным: чем раньше начали чистку, тем меньше объём работ. Точную оценку даёт только осмотр конкретного сайта, а не общий диапазон по прайсу.