Робот пришёл раньше сайта: как 8 свежих статей выпали из индекса

Уведомление поисковой системе о новой странице (протокол IndexNow) отправлялось сразу после публикации материала. Но сайт собирается статически: между командой публикации и появлением страницы в интернете проходит 5–10 минут. Робот Яндекса реагирует на уведомление за 1–3 минуты — то есть приходит на адрес, которого ещё физически нет, получает ошибку 404 и записывает страницу в исключённые.

За неделю так «утонули» 8 свежих статей. Число исключённых страниц выросло с 267 до 322 ровно на этой серии. Формально всё выглядело успешно: материал опубликован, уведомление отправлено, страница через десять минут доступна. Ошибку было видно только в одном месте — истории обхода Яндекс.Вебмастера.

Все промежуточные шаги отчитываются об успехе. Публикация прошла, уведомление доставлено (сервис вернул код принятия), страница в итоге работает. Проверка вручную через полчаса покажет обычную рабочую страницу.

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

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

Проблема характерна для статических сайтов на любой платформе с автоматической выкладкой: Netlify, Vercel, GitHub Pages, а также самописных сборок в CI. Чем больше сайт, тем дольше сборка и тем шире опасное окно. У нас на 5000+ страниц сборка занимает около 8 минут.

На классических CMS вроде WordPress проблемы обычно нет: страница появляется в момент публикации. Но если поверх стоит кеширование или предгенерация статики, окно возвращается.

Отдельный риск — массовые пинги при переносе или редизайне сайта. Уведомить поисковик о тысяче адресов до завершения выкладки означает получить тысячу ошибок в отчёте.

Между публикацией и уведомлением добавили барьер: скрипт сначала проверяет, что адрес реально отдаёт код 200, и только потом сообщает о нём поисковику. Ожидание до десяти минут с повторной проверкой каждые полминуты.

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

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

1. Откройте историю обхода в Яндекс.Вебмастере и найдите страницы с кодом 404. Проверьте каждую вручную: если сейчас открывается — вы поймали ту же ошибку.

2. Посмотрите на порядок шагов в вашей автоматизации публикации. Если уведомление поисковику идёт сразу за командой выкладки, без проверки готовности — окно для ошибки открыто.

3. Сравните число исключённых страниц до и после серии публикаций. Рост, совпадающий по времени с выходом новых материалов, — характерный признак.

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

Никогда не зовите поискового робота на адрес, который не проверен на доступность. Уведомление о новой странице — это обещание: «здесь есть контент». Нарушенное обещание стоит дороже, чем задержка в десять минут.

Более широкий принцип: в любой автоматизации, где есть асинхронный шаг (сборка, выкладка, обработка на стороне сервиса), нужен явный барьер проверки. Успешный ответ предыдущего шага не означает, что результат уже доступен.

Мы записали этот случай в собственный журнал инцидентов — там же, где разбор 5453 страниц-дублей. Оба случая объединяет одно: система рапортовала об успехе, а проблема жила в отчётах поисковой системы.