Сбой Beget в ноябре 2026: что делать с сайтом и SEO

Что произошло с Beget и кто пострадал

В ночь с 1 на 2 ноября 2026 года злоумышленники получили доступ к управляющей инфраструктуре Beget и запустили вредоносное ПО для удаления данных, сообщил провайдер. Утром 2 ноября компания отключила серверы от сети, чтобы остановить распространение атаки. К 14:00 МСК Beget сообщил о восстановлении выделенных серверов без своего администрирования, к 17:00 — о восстановлении NS-серверов. Виртуальный хостинг начали поднимать поэтапно 3 ноября. Хронология Beget

Схема 01

Кого затронул сбой Beget

• Виртуальный хостинг

  Сайты и базы данных

  • Сайты возвращались по мере запуска серверов и восстановления данных из резервных копий.

• Облако

  VPS, S3 и Kubernetes

  • Beget сообщил об утрате данных в облаке. Файловые копии VPS сохранились, наличие и состав копии нужно проверять для своего проекта.

• DNS, почта и панель

  Зависимости за пределами сайта

  • Перебои могли затронуть проект с сервером у другого провайдера, если DNS, почта или другие компоненты оставались у Beget.

К 7 ноября Beget сообщал, что запустил более 60% серверов виртуального хостинга. Это доля серверов. По срезу независимого мониторинга «Пульс рунета» на 9 ноября, 09:56 МСК, не открывались 303 из 5 900 наблюдаемых сайтов — около 5,1% выборки. По ней нельзя оценить ни общее число пострадавших клиентов Beget, ни число сайтов, потерявших данные. Обновления Beget · Данные «Пульса рунета»

Публичный пример — информационный портал «Честного знака». ЦРПТ подтвердил перебои с порталом и сообщил, что сама система маркировки и личный кабинет продолжали работать. Доступ к порталу восстановили 2 ноября. Для своего проекта проверяйте отдельно витрину, личный кабинет, оплату и почту: у них могут быть разные точки отказа. Комментарий ЦРПТ

Как сбой хостинга влияет на SEO

Трафик, заявки и индексация меняются в разное время. Страница может оставаться в выдаче, пока посетители видят ошибку, а счётчик аналитики не загружается. Клики в Google Search Console при этом могут сохраняться, а визиты в Метрике и заявки в CRM — падать. Если сбой продолжается, поисковики повторно запрашивают страницы, замедляют обход, а часть URL может выпасть из поиска. Оценивать последствия нужно по конкретным страницам и ответам, которые получали роботы. Google о серверных ошибках · Яндекс об индексации

Схема 02

Что видит поисковый робот и что делать

Критерий	Риск для поиска	Первое действие
DNS, TLS или тайм-аут	Робот не может получить страницу. Ошибка возможна до HTTP-ответа.	Проверить делегирование, A и AAAA, сертификат и доступность сервера из разных сетей.
Повторяющиеся 500, 502 или 504	Обход может замедлиться. При длительной недоступности URL могут исчезнуть из выдачи.	Восстановить приложение или развернуть проверенную копию.
Временный 503	Код сообщает о временной недоступности. Если он сохраняется, риск для индекса растёт.	Использовать для коротких работ, пока сервер может отвечать. Как можно скорее вернуть рабочие страницы.
Одинаковая заглушка с 200	Поиск может распознать страницы как дубли или мягкие ошибки 404.	Вернуть содержимое по исходным URL. На время коротких работ отдавать 503 на недоступных страницах.
404 или 410 на важных URL	Поисковик воспринимает страницы как отсутствующие.	Восстановить адрес и контент. При постоянной смене URL настроить 301 на соответствующую страницу.

При коротком простое с доступным резервным сервером можно вернуть 503 Service Unavailable и добавить Retry-After, если есть обоснованный срок следующей проверки. Не закрывайте весь сайт через robots.txt или noindex из-за аварии. Если витрина работает, а недоступна только оплата, оставьте рабочие страницы открытыми и предупредите посетителей о проблеме с заказом. Google о временном отключении функций · Google об ошибках DNS и сети

Что делать, если сайт на Beget не открывается

1. Выясните, из чего можно восстановить сайт

Если сайт уже недоступен из-за сбоя Beget, сразу ищите резервную копию файлов и базы данных. Проверьте копии у разработчика, на отдельном сервере или во внешнем хранилище. Параллельно выясните, кто может изменить DNS-записи домена.

• Есть рабочая копия и доступ к DNS. Если Beget не назвал приемлемый срок восстановления вашего сервера, разворачивайте копию на резервном хостинге. Перед переключением проверьте, какие заказы и изменения могли не попасть в копию.
• Своей копии нет. Запросите у Beget статус восстановления именно вашего сайта и доступную копию. Уточните её дату и состав, в том числе есть ли база данных. Если поддержка пока не может выдать копию, используйте независимый канал связи для заявок и заказов.
• Копия есть, доступа к DNS нет. Готовьте сайт на новом сервере параллельно с восстановлением доступа к управлению доменом. До смены записей посетители будут попадать по прежнему адресу сервера.

2. Восстановите сайт на прежних URL

1. Разверните копию на новом сервере и проверьте файлы, базу, изображения, зависимости, формы и оплату. Закройте тестовый экземпляр авторизацией или ограничением доступа.
2. Сохраните домен, HTTPS, пути страниц, канонические адреса и рабочие перенаправления. При смене IP без изменения URL перенос домена в Search Console не нужен. Проверьте отдельно адреса файлов, если они обслуживались из S3 или через CDN.
3. Перед переключением проверьте сертификат и сайт на новом IP, например через curl --resolve. Уберите тестовые ограничения и noindex с рабочей версии. Обновите записи A и AAAA по фактической конфигурации. При переносе DNS-зоны заранее скопируйте почтовые и проверочные записи и проверьте настройку DNSSEC, если он включён.
4. Проверьте ответы с разных сетей. Если обе версии принимают заказы, организуйте одну точку записи на время переключения, иначе заказы могут разойтись между базами.

Руководство Google по смене хостинга без изменения URL

Как проверить SEO после восстановления

1. Пройдите по важным посадочным. Начните с главной, страниц с трафиком, категорий и карточек, которые приносят заявки. Проверьте содержимое, код ответа, canonical, robots.txt, sitemap.xml и отсутствие случайного noindex. Отдельно отправьте тестовую заявку и проверьте её появление в CRM.
2. Проверьте доступ глазами поисковиков. В Google Search Console используйте «Проверку URL» с проверкой опубликованной страницы. В Яндекс Вебмастере проверьте ответ сервера и диагностику. После устранения ошибок отправьте несколько ключевых URL на переобход и проверьте статус карты сайта.
3. Сравните динамику по страницам. Смотрите отдельно ошибки обхода, число страниц в индексе, показы, клики, визиты и заявки. Сравнивайте одинаковые дни недели и учитывайте сезонность. Если сайт уже отвечает стабильно, а показы одной группы страниц остаются ниже, проверьте эти URL и журналы запросов роботов. Если показы восстановились, а заявки отстают, проверьте счётчики, формы, почту и CRM.

Диагностика в Яндекс Вебмастере · Как Google обрабатывает HTTP-ответы · Техническое SEO RootRex

Как RootRex помогает после сбоя Beget

Представьте, что ваш интернет-магазин снова открывается после восстановления из копии. Главная на месте, но часть карточек отдаёт 404, а тестовый заказ не доходит до CRM. Для покупателя магазин всё ещё не работает. В такой ситуации мы начинаем со страниц, которые приводят покупателей, и проверяем весь путь от перехода из поиска до заказа.

• Сайт ещё лежит. Проверяем, где обрыв: в DNS, на сервере или в приложении. Если есть пригодная копия файлов и базы, можем развернуть её на другом хостинге, проверить сайт до переключения и вернуть его на прежний домен. Если копии пока нет, выясняем, какие данные доступны и какие разделы можно восстановить в первую очередь.
• Сайт уже подняли. Проверяем важные URL, редиректы, доступ для поисковых роботов и карту сайта. Затем отправляем тестовую заявку или заказ и проверяем, что они доходят до почты или CRM.
• После восстановления упал трафик. Сопоставляем данные Google Search Console, Яндекс Вебмастера и Метрики. Если просели показы по конкретным разделам, проверяем их обход и индексацию. Если клики вернулись, а заявок всё ещё мало, ищем проблему в аналитике, формах или оформлении заказа.

Для начала пришлите домен, пример страницы с ошибкой, время, когда заметили сбой, и напишите, есть ли резервная копия. По этим данным определим, с чего начать и какие доступы понадобятся для работ. Обсудить восстановление сайта с RootRex

Как подготовиться к следующему сбою

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

Частые вопросы