Сбой Blogger за один день превратил сотни обычных сайтов в подозреваемых по линии вредоносного контента. Часть блогов оказалась заблокирована, часть удалена, а владельцы потеряли доступ к публикациям и настройкам. Для тех, кто держит на Blogger архив, нишевое медиа или корпоративный блог, это неприятное напоминание: автоматическая защита платформы умеет устроить простой не хуже реальной атаки.
Как пишет BleepingComputer, инцидент начался 4 августа 2026 года и быстро вылез из категории рядовых ложных срабатываний. На официальном форуме Google сотни администраторов попросили вернуть доступ к площадкам: у тематической ветки набралось более 300 отметок о той же проблеме и свыше 100 ответов от издателей. Для форума Blogger, который обычно живет в куда более спокойном ритме, такая плотность жалоб сама по себе выглядит индикатором системной ошибки, а не локального конфликта с правилами. Один из экспертов сообщества Blogger прямо связал массовую блокировку с ошибкой автоматической классификации и заметил, что ложные срабатывания случаются, но не в таком масштабе. Этот сбой Blogger ударил не по серым дорвеям и не по одноразовым лендингам, а по легитимным сайтам, где, по словам владельцев, не было ни вредоносных файлов, ни подозрительных скриптов.
Сценарий для пострадавших выглядел одинаково. В панели Blogger появлялся красный знак блокировки и уведомление о нарушении правил сообщества, после чего блог предлагали отправить на пересмотр. Одновременно система предупреждала, что без апелляции площадку могут удалить в течение трех месяцев. На практике проблема оказалась жестче, чем обычное ограничение на публикацию: пока блог заблокирован, владелец не может зайти в разделы с постами, настройками, темами и другими элементами управления. Фактически человек видел не предупреждение о возможной проблеме, а почти полноценную заморозку рабочей среды. Несколько пользователей жаловались, что удаление происходило сразу после обновления главной страницы или правки шаблона, то есть триггером могла стать рутинная работа по сайту, а не реальный инцидент безопасности.
Google подтвердила, что сбой Blogger был вызван багом, из-за которого часть сайтов на платформе ошибочно получила метку вредоносных, и заявила, что проблема длилась меньше суток. Компания пообещала исправить ее как можно быстрее. Но для владельцев блогов это слабое утешение. Не все пострадавшие столкнулись с одним и тем же сценарием: кто-то после апелляции увидел восстановление сайта, а кто-то, наоборот, сообщил, что блог сначала вернули, а затем удалили снова. Такой маятник особенно плохо выглядит на платформе, где у пользователя нет собственного уровня доступа к инфраструктуре и почти нет инструментов для самостоятельной диагностики. Для малого издателя или автора-одиночки даже несколько часов такой неопределенности легко превращаются в пропущенные публикации, потерянные правки и поток писем от читателей.
Масштаб инцидента до конца неясен еще и потому, что Google не раскрывает, сколько сайтов вообще живет на Blogger. Сторонние трекеры оценивают размер платформы примерно в 200 тысяч сайтов. Даже если воспринимать эту цифру только как ориентир, речь все равно не о мелкой поломке. Сотни жалоб за сутки означают заметный сбой в системе автоматической модерации и проверки на вредоносный контент. Особенно неприятно то, что внешне такой сбой похож на санкцию за реальное нарушение, хотя источник проблемы находится на стороне самой площадки. Для старых хостинговых платформ это неприятная правда: чем сильнее сервис завязан на автоматику, тем выше шанс, что один неверный сигнал выключит не нарушителя, а вполне нормальный проект. И если реальную атаку можно расследовать по логам и изменениям в коде, то ошибку чужого классификатора приходится разбирать почти вслепую.
Отдельный неприятный нюанс в таких историях - асимметрия между платформой и владельцем сайта. Google видит внутренние сигналы, правила и срабатывания, а пользователь видит только красную метку и форму апелляции. Для инженеров это почти худший тип инцидента: эффект есть, а данных для разбора первопричины нет. С точки зрения процессов это почти инцидент формата черного ящика: сервис ломает доступ, но не дает нормального журнала событий. Нельзя быстро проверить, какой именно виджет, фрагмент шаблона или изменение на странице вызвали подозрение, нельзя откатить инфраструктурное решение на своей стороне, нельзя даже понять, был ли это баг, новая эвристика или неудачное обновление антиспам-фильтра. Пока вопрос уходит в очередь на пересмотр, команда теряет время и канал коммуникации с аудиторией.
Для разработчиков, продактов и владельцев контентных проектов эта ложная блокировка блогов важна не только как курьез из жизни старой площадки Google. Она показывает слабое место любого внешнего управляемого сервиса: контроль над доставкой, модерацией и безопасностью принадлежит не вам, а оператору платформы. Бесплатность или привычность площадки здесь ничего не меняют: зависимость от нее все равно остается инфраструктурной, просто ее часто недооценивают. Если блог, документационный раздел или бренд-медиа живут на таком сервисе, у команды должна быть хотя бы минимальная аварийная дисциплина: офплатформенная копия материалов, отдельное хранение шаблонов и настроек, понятный сценарий для быстрого зеркала или резервной публикации. Иначе проблема в чужой системе проверки быстро превращается в ваш редакционный, операционный и репутационный инцидент.
Главный вопрос после этой истории не в том, починит ли Google конкретный баг. С этим компания, вероятно, разберется. Важнее другое: насколько контент-платформы вообще готовы к эпохе, где безопасность и модерация работают через все более жесткую автоматику. Пока ответ выглядит нервно. Если легитимный блог можно потерять после правки шаблона, риск лежит уже не в коде сайта, а в чужой системе принятия решений.