Сайт недоступен ночью: вы узнали утром, а робот Яндекса — сразу

Сайт недоступен всего несколько часов ночью — и вопрос только один: кто узнал об этом первым, вы или робот Яндекса. Мониторинг доступности нужен не ради зелёного графика в личном кабинете, а ради ответа на этот вопрос. Обычно первым узнаёт робот. Сайт лёг в 02:40, поднялся в 08:50, владелец открыл ноутбук в десять утра и ничего не заметил: главная открывается, заявки идут. А в это время в логах уже лежат три десятка строк, где YandexBot стучался в важные страницы и получал 502. Через две недели человек пишет мне: «позиции просели, ничего не меняли». Меняли. Сервер лежал шесть часов, и это единственное изменение, которое робот зафиксировал.

Я занимаюсь SEO-продвижением сайтов в Яндексе с 2005 года, и недоступность сервера стабильно входит в тройку причин, по которым технически здоровый сайт теряет позиции без видимого повода. Причём это самая дешёвая в починке причина из всех: настройка нормального мониторинга занимает полчаса и в базовом варианте не стоит ничего.

Коротко

• Единичный сбой робот прощает: одна ошибка 5xx при следующем удачном обходе просто забывается.
• Повторяющиеся ошибки снижают частоту обхода — робот приходит реже, новые страницы индексируются дольше.
• Длительная недоступность (сутки и больше, несколько обходов подряд с ошибкой) выбрасывает страницы из индекса. Возврат занимает недели, а не часы.
• Для плановых работ есть ровно один правильный ответ — 503 с заголовком Retry-After. Всё остальное вредит.
• Отдавать 200 с текстом «ведутся работы» или редиректить всё на главную — худшее, что можно сделать: робот сохранит заглушку как содержимое страниц.
• Часть «падений» — вовсе не падения, а блокировка робота фаерволом или антибот-защитой. Сайт работает у всех, кроме Яндекса.
• Мониторинг не чинит сервер. Если хостинг падает еженедельно, ставить будильник бессмысленно — надо менять хостинг.

Что происходит, пока сайт лежит, а вы спите

Робот Яндекса ходит по сайту круглосуточно, и ночь для него — обычное рабочее время. Более того, у многих сайтов основная доля обходов приходится как раз на ночные часы: днём сервер занят людьми, ночью нагрузка падает, и робот наращивает темп. То есть шестичасовое падение с двух до восьми утра попадает ровно в тот интервал, где робот работает активнее всего.

Когда сервер не отвечает, робот не видит «сайт на техобслуживании». Он видит числовой код или пустоту вместо ответа. Дальше запускается простая логика: адрес помечается как проблемный, обход по нему откладывается, при повторении ситуации проблемным помечается весь хост.

Важный момент, который многие упускают: у падения нет «зрителей», но есть последствия. Ночью на сайте могло не быть ни одного живого посетителя, счётчик Метрики не покажет провала, отдел продаж не заметит пропавших звонков. Единственный свидетель — сервер-лог и очередь обхода Яндекса. Именно поэтому владелец узнаёт о проблеме из месячного отчёта, когда чинить уже поздно: позиции просели, и надо не устранять аварию, а восстанавливать индекс.

Отдельная категория — падения в выходные и праздники. Хостинг обновляет ПО в ночь на субботу, что-то ломается, техподдержка отвечает в понедельник. Двое суток недоступности — это уже не «сбой», это выпадение страниц из поиска. Похожая история происходит, когда заканчивается оплаченный период хостинга: сайт выключают в конце месяца, письмо о просрочке уходит на почту, которую никто не читает.

Последствия по нарастающей: от одной ошибки до выпадения из индекса

Реакция поиска не бинарная — «упал и всё пропало». Она ступенчатая, и понимание ступеней помогает не паниковать после десятиминутного сбоя и, наоборот, срочно шевелиться после суточного.

Ступень первая: единичный сбой. Робот пришёл, получил 502, ушёл. Через несколько часов пришёл снова, получил 200. Ничего не произошло. Страница остаётся в индексе, позиции не двигаются. Такие сбои случаются у всех, включая крупные площадки, и закладывать бюджет на борьбу с ними не нужно.

Ступень вторая: сбои повторяются. Сервер падает по два-три раза в неделю, каждый раз на 20–60 минут. Робот попадает на ошибку регулярно. Для очереди обхода это сигнал «сюда ходить дорого»: запросы к нестабильному хосту снижаются, чтобы не тратить ресурсы впустую и не добивать чужой сервер. Внешне это выглядит как замедление индексации: новая страница вместо суток попадает в поиск через неделю. Тема тесно связана с тем, как вообще распределяется краулинговый бюджет и почему Яндекс не обходит сайт целиком.

Ступень третья: длительная недоступность. Сайт лежит сутки и больше. Робот несколько раз подряд получает ошибку на одних и тех же адресах. Страницы начинают исключаться из поиска со статусом ошибки HTTP. Причём вылетают не все сразу: сначала уходит хвост — редко посещаемые, глубоко вложенные страницы, товары, старые статьи. Главная и основные разделы держатся дольше, потому что робот заходит на них чаще и быстрее видит восстановление.

Ступень четвёртая: возврат. Здесь главная несправедливость. Выпадение занимает сутки, возврат — недели. Роботу нужно снова обойти каждый исключённый адрес, убедиться, что ответ нормальный, вернуть страницу в индекс, и только потом она снова начнёт участвовать в ранжировании. Ускорить процесс частично можно переобходом в Вебмастере, но лимит переобхода конечен, и на сайте в тысячи страниц он не спасает. Это тот случай, когда авария на шесть часов оборачивается месяцем восстановления. Если после аварии страницы не возвращаются, стоит пройтись по списку причин, по которым Яндекс перестаёт индексировать страницы: часто к падению добавляется вторая проблема, которая и держит сайт вне индекса.

Что именно видит робот: коды ответа и таймауты

Робот не различает «хостинг перегружен» и «программист сломал плагин». Он оперирует кодом ответа сервера. Вот что означают коды, которые чаще всего попадают в логи во время аварии, и как на них реагирует поиск.

Код	Что означает технически	Как реагирует Яндекс	Когда его правильно отдавать
500	Внутренняя ошибка приложения: фатальная ошибка PHP, сломанный плагин, битое соединение с базой	Обход откладывается, при повторении страница исключается из поиска	Никогда намеренно. Это всегда авария, которую надо чинить
502	Обратный прокси (nginx) не дождался внятного ответа от бэкенда — PHP-FPM упал или кончились воркеры	Так же, как 500. Массовые 502 быстро роняют частоту обхода	Никогда намеренно
503	Сервис временно недоступен: перегрузка или плановые работы	Понимается как «зайди позже». С заголовком Retry-After робот планирует повторный визит и не спешит исключать страницу	Плановые техработы, обновление CMS, миграция базы, кратковременная перегрузка
504	Прокси дождался ответа дольше лимита и разорвал соединение. Обычно — тяжёлый запрос к базе	Как ошибка сервера. Дополнительно портит оценку скорости ответа	Никогда намеренно
Таймаут соединения	Ответа нет вообще: сервер выключен, порт закрыт, сеть недоступна	Худший вариант. Нет даже кода, чтобы понять причину. Хост помечается недоступным целиком	Никогда
403 / 429 для робота	Доступ запрещён или слишком много запросов — ответ фаервола или антибот-защиты	Робот считает, что его не пускают. Страницы исключаются, хотя сайт «работает»	Только для реальных вредоносных ботов, никогда для YandexBot
200 с заглушкой	Сервер отвечает успешно, но отдаёт страницу «ведутся работы» или капчу	Самое опасное. Робот сохраняет заглушку как содержимое страницы и выкидывает её из поиска как пустую	Никогда

Разница между 500 и 502 важна для диагностики: 500 почти всегда указывает на код сайта, 502 и 504 — на сервер и его ресурсы. Подробный разбор этой развилки я делал отдельно — как отличить ошибку 500 из-за хостинга от ошибки из-за плагина.

Почему 503 с Retry-After принципиально лучше остальных

Код 503 — единственный из семейства 5xx, который несёт роботу осмысленную информацию: «я жив, я в курсе, зайди позже». Все остальные пятисотые означают поломку, о которой сервер сам ничего не знает.

Заголовок Retry-After усиливает сигнал. Он говорит, через сколько секунд имеет смысл вернуться, и принимает либо число секунд, либо дату в HTTP-формате:

HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Content-Type: text/html; charset=utf-8

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

Ставить в Retry-After сутки и больше не нужно: если техработы занимают день, проблема не в заголовке, а в планировании. Разумный диапазон — от нескольких минут до нескольких часов, с запасом относительно реального срока работ.

Способы мониторинга: три рабочих варианта

Задача мониторинга простая — узнать о падении раньше, чем робот сходит на сайт второй раз. Для этого нужен внешний наблюдатель: проверка изнутри сервера бесполезна, потому что если сервер лёг, то лёг и скрипт проверки.

Внешние сервисы аптайма. UptimeRobot, HetrixTools, Better Stack, из российских — Ping-Admin. Регистрируетесь, добавляете адрес, указываете куда слать уведомления. На бесплатных тарифах обычно дают несколько десятков проверяемых адресов с интервалом около пяти минут; платные тарифы сокращают интервал до минуты и добавляют SMS и звонки. Для сайта малого бизнеса бесплатного тарифа достаточно. Важная деталь для рунета: проверяйте, откуда сервис пингует. Если все узлы за границей, а ваш сервер отсекает зарубежные IP, вы получите ложные тревоги, а реальное падение для российских посетителей не заметите.

Мониторинг в Яндекс.Вебмастере. Единственный источник, который смотрит на сайт глазами настоящего YandexBot. В разделе индексирования есть мониторинг важных страниц: туда добавляются ключевые адреса — главная, разделы услуг, топовые товары. Список ограничен по числу адресов, весь сайт туда не залить, поэтому кладите то, на чём держатся деньги. Вебмастер уведомляет об изменении кода ответа, о пропаже страницы из поиска и о недоступности сайта целиком. Минус один и он существенный: уведомление приходит не мгновенно, задержка может составлять часы. Как аварийная сигнализация Вебмастер слаб, как контрольная инстанция — незаменим, потому что показывает именно ту картину, на основе которой принимаются решения о вашем индексе.

Свой скрипт по cron. Нужен, когда важно проверять не только код ответа, но и содержимое: не подменилась ли главная, на месте ли форма заявки, отвечает ли база. Ставится на любой чужой сервер или VPS — принципиально не на тот, который проверяем.

#!/bin/bash
URL="https://example.ru/"
TOKEN="ваш_токен_бота"
CHAT="ваш_chat_id"

CODE=$(curl -s -o /tmp/body.html -w "%{http_code}" --max-time 15 "$URL")

if [ "$CODE" != "200" ] || ! grep -q "Оставить заявку" /tmp/body.html; then
  curl -s "https://api.telegram.org/bot$TOKEN/sendMessage" \
    -d chat_id="$CHAT" \
    --data-urlencode "text=Сайт недоступен. Код ответа: $CODE"
fi

В crontab строка вида */5 * * * * /root/check.sh запускает проверку каждые пять минут. Проверка по коду и по куску текста ловит случай, когда сервер отвечает 200, но отдаёт заглушку хостера или страницу антибот-защиты. Это ровно та ситуация, которую внешние сервисы аптайма показывают зелёной.

Способ	Интервал проверки	Откуда проверяет	Куда шлёт уведомление	Цена
Внешний сервис аптайма (бесплатный тариф)	Около 5 минут	Сеть узлов провайдера, часто зарубежных	Почта, Телеграм, вебхук	0 ₽
Внешний сервис аптайма (платный)	От 30–60 секунд	Больше узлов, есть выбор региона	Почта, Телеграм, SMS, звонок	Несколько сотен рублей в месяц
Мониторинг важных страниц в Вебмастере	Нерегулярно, по расписанию робота	Реальный робот Яндекса	Почта, уведомления в интерфейсе	0 ₽
Свой скрипт на cron	Любой, вплоть до 1 минуты	Ваш второй сервер или VPS	Телеграм, почта, что угодно	0 ₽ при наличии второго сервера
Мониторинг от хостинг-провайдера	Обычно 5–15 минут	Изнутри инфраструктуры хостера	Почта	0 ₽, часто включён

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

Сайт работает у всех, кроме Яндекса: как отличить падение от блокировки

Это самый частый ложный диагноз. Владелец открывает сайт с телефона — работает. Внешний мониторинг зелёный. А в Вебмастере страницы валятся с ошибкой доступа. Сервер жив, лежит не он — лежит доступ конкретно для робота.

Причины почти всегда одни и те же:

• Антибот-защита или WAF принимает частые запросы YandexBot за атаку и отдаёт ему 403, 429 или JS-челлендж.
• Плагин безопасности CMS с включённой блокировкой по частоте запросов банит IP робота на час-другой.
• Фаервол настроен по принципу «пускаем только российские IP», а часть узлов робота приходит с адресов, которые в базе геолокации помечены иначе.
• Хостер включил защиту от DDoS и раздаёт всем страницу проверки с кодом 200.
• Ограничение числа одновременных соединений с одного IP: робот открывает несколько потоков и упирается в лимит.

Отличить блокировку от падения можно за пятнадцать минут, и порядок действий такой.

Шаг 1. Проверка ответа сервера в Вебмастере. Инструмент запрашивает страницу настоящим роботом с настоящего IP. Если браузер видит 200, а инструмент — 403, 429 или таймаут, вопрос закрыт: это блокировка.

Шаг 2. Логи. Отфильтруйте строки с YandexBot и посмотрите коды ответа. Ровный поток 200 — всё нормально. Пачка 403 или 429 в одном интервале — работает защита. Пачка 500/502 в том же интервале, что и у обычных посетителей, — это настоящая авария.

Шаг 3. Проверка подлинности робота. Прежде чем разблокировать IP, убедитесь, что это действительно Яндекс, а не подделка под его User-Agent. Способ официальный и надёжный: обратный DNS-запрос для IP должен вернуть имя в зоне yandex.ru, yandex.net или yandex.com, а прямой запрос по этому имени — вернуть тот же самый IP. В консоли это делается парой команд host или dig -x. Если проверка не проходит — перед вами чужой бот, маскирующийся под робота, и его как раз блокировать правильно.

Шаг 4. Разбор правил защиты. Проверьте .htaccess, конфиг nginx, панель CDN и настройки плагина безопасности на предмет правил, отсекающих роботов по частоте или по User-Agent. У плагинов-комбайнов такие правила часто включены по умолчанию — я разбирал, как защищать WordPress без плагинов-комбайнов, чтобы защита не била по своим.

Отдельно про 200 с капчей. Внешний мониторинг видит код 200 и молчит. Робот получает страницу проверки с текстом на десять слов вместо вашей статьи и постепенно заменяет ею содержимое страницы в индексе. Именно поэтому проверка по содержимому в самописном скрипте — не паранойя, а необходимость.

Заглушка на время техработ: как правильно и как нельзя

Техработы — единственный случай, когда сайт лежит по вашей воле, и единственный, где вы полностью контролируете, что увидит робот. Тем обиднее, что именно здесь ошибаются чаще всего.

Что делают	Что видит робот	Чем заканчивается	Как правильно
Редирект всех страниц на главную	302 или 301 на один адрес	Содержимое страниц подменяется главной, при 301 — склейка адресов и потеря страниц из индекса	Никаких редиректов. Каждый адрес отвечает 503 сам за себя
Страница «ведутся работы» с кодом 200	Успешный ответ с пустым содержимым	Страницы переиндексируются как малосодержательные и вылетают из поиска	Тот же текст, но с кодом 503
Закрытие сайта в robots.txt на время работ	Запрет обхода	Забыли снять — сайт месяцами вне индекса. Классическая забытая строка	Не трогать robots.txt ради техработ вообще
Отдача 404 на время работ	Страницы не существует	Быстрое исключение из индекса: 404 — сигнал «удалено навсегда»	503, а не 404
Просто выключить сервер	Таймаут без кода ответа	Хост помечается недоступным целиком	Поднять лёгкий сервер, отдающий 503 на все адреса
503 с Retry-After и понятным текстом	Временная недоступность с указанием срока	Робот возвращается позже, страницы остаются в индексе	Это и есть правильный вариант

Пример для Apache — в .htaccess перед остальными правилами:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule ^.*$ /maintenance.html [R=503,L]

ErrorDocument 503 /maintenance.html
Header always set Retry-After "3600"

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

Пример для nginx:

location / {
    return 503;
}

error_page 503 /maintenance.html;

location = /maintenance.html {
    root /var/www/maintenance;
    add_header Retry-After 3600 always;
    internal;
}

Сама страница заглушки должна содержать нормальный человеческий текст: что происходит, когда закончится, телефон и почта для связи. Живые посетители никуда не делись, и терять заявки из-за молчаливого белого экрана глупо. Отдельно проследите, чтобы заглушка не превратилась потом в мусорный адрес: после работ уберите правило целиком, а не оставляйте /maintenance.html доступным с кодом 200.

И главное про редиректы. Соблазн «пусть всё пока идёт на главную» возникает регулярно, и он же порождает одну из самых живучих технических болезней — я показывал механику в материале о том, как редирект на главную вместо честного кода плодит soft 404. На время техработ этот приём вреден вдвойне: он не просто портит один адрес, он разом переписывает роботу содержимое всего сайта.

Когда мониторинг не спасёт

Мониторинг — датчик, а не лекарство. Он показывает температуру, но не лечит. Есть ситуации, где ставить его бессмысленно или недостаточно, и честнее признать это сразу.

Хостинг падает регулярно. Если сервер уходит в 502 каждую неделю, уведомление в Телеграм сообщит вам об этом 52 раза в год и не изменит ровным счётом ничего. Здесь решение одно — переезд. Причём переезжать надо аккуратно, с сохранением адресов и кодов ответа; порядок действий я описывал в инструкции по переносу сайта WordPress на другой хостинг без потери позиций. И считайте деньги честно: экономия ста рублей в месяц на тарифе легко оборачивается потерей заявок, которые этот тариф окупали многократно.

Некому реагировать ночью. Уведомление в 03:00 работает, только если кто-то его прочитает и нажмёт кнопку. Если реакции физически не будет до утра, мониторинг превращается в летопись аварий. Тогда деньги лучше вложить не в платный тариф с проверкой раз в минуту, а в автоматику: автоперезапуск упавшего процесса, резервный сервер, тариф с SLA и круглосуточной поддержкой.

Сайт не падает, а тормозит. Мониторинг аптайма отвечает на вопрос «жив или нет». Он не заметит, что страница отвечает за восемь секунд вместо одной, — код-то 200. Между тем медленный ответ бьёт по обходу почти так же, как ошибки. Это отдельная тема — куда исчезает секунда до первого байта, и лечится она не мониторингом, а профилированием.

Проблема не в доступности, а в содержимом. Сервер отвечает 200, но страница отдаётся пустой, без товаров, со сломанной вёрсткой. Аптайм-мониторинг это пропустит. Ловится только проверкой по ключевому фрагменту текста или регулярным ручным контролем.

Сайт-визитка без поискового трафика. Если сайт не продвигается и посетителей на нём десяток в месяц, выстраивать систему уведомлений незачем — хватит бесплатного мониторинга от хостера. Экономия внимания тоже ресурс.

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

Что делать, если падение уже случилось

Порядок действий после аварии важнее, чем скорость реакции на неё саму. Сервер подняли — работа не закончена.

1. Зафиксируйте окно недоступности по логам: точное время начала и конца, какие коды отдавались. Без этого дальше вы будете гадать.
2. Отфильтруйте в логах запросы робота за это окно. Посмотрите, на какие именно адреса он приходил и что получил. Это список страниц под ударом.
3. Проверьте в Вебмастере ответ сервера по этим адресам сейчас — убедитесь, что отдаётся 200 и нормальное содержимое.
4. Отправьте пострадавшие адреса на переобход. Приоритет — коммерческие страницы и то, что приносит заявки, а не блог.
5. Через неделю сверьте число страниц в поиске с показателем до аварии. Расхождение покажет реальный масштаб.
6. Найдите и устраните причину. «Само упало, само поднялось» — не диагноз, а отложенная вторая авария.
7. Настройте мониторинг, если его не было. Именно сейчас, пока больно, а не через месяц.

Если разбираться в логах и кодах ответа некогда, это ровно та работа, которую я делаю в рамках бесплатного аудита сайта: смотрю ответы сервера, историю доступности и то, что видит робот. Технические правки, если они нужны, выносятся отдельно — в доработку сайта.

Чеклист: мониторинг доступности за один вечер

Пункт	Как проверить	Норма
Внешний мониторинг подключён	Личный кабинет сервиса аптайма	Адрес добавлен, интервал не реже 5 минут
Уведомления доходят	Намеренно указать несуществующий адрес и дождаться сигнала	Сообщение в Телеграм или на почту в течение 5–10 минут
Проверка не только кода, но и содержимого	Скрипт ищет ключевой фрагмент текста на странице	Тревога срабатывает при заглушке с кодом 200
Мониторинг важных страниц в Вебмастере	Раздел индексирования	Добавлены главная и ключевые коммерческие адреса
Уведомления Вебмастера включены	Настройки уведомлений, актуальный адрес почты	Почта реально читается, а не заведена «для галочки»
Робот Яндекса не блокируется	Проверка ответа сервера в Вебмастере + фильтр логов по YandexBot	Только коды 200 и 304, никаких 403 и 429
Заглушка техработ отдаёт 503	curl -I по любому внутреннему адресу при включённом режиме работ	503 плюс заголовок Retry-After
На время работ нет редиректов на главную	Тот же curl -I по нескольким адресам	Каждый адрес отвечает 503 сам за себя
robots.txt не используется для отключения сайта	Открыть файл и прочитать	Нет строки Disallow: /
Оплата хостинга и домена автоматизирована	Панель хостера и регистратора	Автопродление включено, баланс с запасом
История аварий ведётся	Отчёт сервиса аптайма за 30 дней	Аптайм выше 99,5 %; ниже — повод менять хостинг
Есть план на случай падения	Записанный порядок действий и контакты поддержки	Понятно, кому звонить в 3 часа ночи

Ночное падение сервера — редкий случай, когда SEO-проблема решается не текстами и не ссылками, а получасовой настройкой. Робот приходит к вам круглосуточно и оценивает сайт по тому, что застал. Ваша задача — застать аварию раньше него.