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

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

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

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

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

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

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

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

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

Между публикацией и уведомлением теперь стоит барьер. Скрипт сначала проверяет, что адрес реально отдаёт код 200 (не 404 и не редирект), и только после этого сообщает о нём поисковику, при этом ждёт он до десяти минут и повторяет проверку каждые полминуты, чтобы не дёргать сервер слишком часто.

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

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

1. Откройте историю обхода в Яндекс.Вебмастере и найдите страницы с кодом 404, а потом проверьте каждую вручную в браузере (лучше в режиме инкогнито, чтобы не мешал кеш). Страница сейчас открывается нормально? Значит, вы поймали ту же ошибку.

2. Посмотрите, в каком порядке идут шаги в вашей автоматизации публикации. Уведомление поисковику уходит сразу за командой выкладки, и готовность страницы никто не проверяет? Тогда окно для ошибки у вас открыто, даже если пока вы его не видели.

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

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

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

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

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