Когда новые страницы индексируются медленно, первая реакция обычно предсказуемая: отправить ещё десяток URL на переобход, обновить Sitemap и подождать. Иногда помогает. Но на больших и даже средних сайтах проблема часто находится на шаг раньше — робот уже ходит по сайту, просто значительная часть его внимания уходит не туда.
В Яндекс Вебмастере для этого есть довольно недооценённый отчёт «Статистика обхода». Он показывает, какие URL робот реально посещал, когда это происходило и какой HTTP-код он получил. Это не отчёт о позициях и не список страниц в выдаче. Скорее журнал того, как Яндекс видит сайт на этапе обхода.
Именно поэтому я бы смотрел его не только при авариях. По характеру обхода часто можно заметить технический мусор, дубли, старые URL и проблемы сервера ещё до того, как они превратятся в заметное проседание индексации.
Что именно показывает статистика обхода
По документации Яндекса данные в разделе «Индексирование → Статистика обхода» обновляются ежедневно, обычно в течение нескольких часов после посещения страниц роботом. Для каждого URL можно увидеть дату последнего обхода и код ответа сервера. Отдельно показываются новые и изменившиеся адреса.
Здесь важно не путать два события. Робот может успешно скачать страницу — это ещё не означает, что она обязательно появится в поиске. После обхода документ должен быть обработан, а затем поисковая система решает, участвовать ему в выдаче или нет. Поэтому «робот был вчера» и «страницы нет в поиске» вполне могут существовать одновременно.
Обратная ситуация тоже полезна для диагностики. Если важной страницы вообще нет среди недавно посещённых URL, проблема уже не в качестве её сниппета или позиции. Сначала стоит понять, как робот должен до неё добраться: есть ли внутренние ссылки, присутствует ли URL в Sitemap, не закрыт ли раздел в robots.txt и не образовалась ли слишком глубокая вложенность.
Смотреть надо не на количество обходов, а на их состав
Сам по себе рост или падение числа обращений робота мало о чём говорит. Яндекс прямо отмечает, что количество посещаемых страниц может меняться в разные дни и это само по себе не означает ухудшения индексирования или ранжирования.
Гораздо интереснее вопрос: какие именно адреса съедают обход.
У интернет-магазина это могут быть бесконечные сочетания фильтров и сортировок. У сайта услуг — технические URL CMS, страницы поиска, архивы и параметры. После редизайна робот иногда продолжает ходить по старой структуре, потому что ссылки на неё остались в шаблоне, Sitemap, внешних источниках или где-то в глубине сайта.
В результате возникает странная картина: робот активен, запросов много, а новые полезные страницы он посещает заметно реже, чем хотелось бы. Ускорять скорость обхода в такой ситуации — примерно как сильнее открыть кран, когда половина воды течёт в дырявую трубу.
Первое, что я проверяю: коды ответа
Начать проще всего с HTTP-кодов. Нормальная страница, предназначенная для индексирования, должна стабильно отдавать 200 OK. Но в статистике обхода интереснее отклонения.
404 и 410
Наличие удалённых URL само по себе нормально. Сайты меняются, товары исчезают, старые страницы удаляются. Вопрос в масштабе и происхождении адресов.
Если робот регулярно возвращается к тысячам давно удалённых страниц, надо выяснить, откуда он их продолжает находить. Проверьте внутренние ссылки, XML Sitemap, меню, фильтры, старые карты сайта. Яндекс указывает, что робот может продолжать обращаться к удалённой странице, пока на неё ведут ссылки.
301 и 302
Редиректы тоже не зло. Они необходимы при смене URL. Но длинные цепочки вида старый адрес → промежуточный → ещё один адрес → конечная страница создают лишнюю работу и для робота, и для пользователя.
Если структура менялась несколько раз, полезно обновить внутренние ссылки так, чтобы они сразу вели на конечный URL. Редирект остаётся страховкой для старых внешних ссылок, а не штатным способом навигации внутри сайта.
5xx
Вот здесь уже стоит разбираться быстро. Серверные ошибки означают, что робот пришёл, но не смог получить документ. Разовый сбой бывает у всех, а систематические 500, 502, 503 или 504 — повод смотреть серверные логи, нагрузку, кеширование и работу приложения.
Особенно неприятно, когда ошибки совпадают с периодами активного обхода. Поисковый робот не обязан бесконечно стучаться в недоступный сайт с прежней частотой.
Второе: ищем семейства мусорных URL
Просматривать тысячи строк глазами бессмысленно. Вебмастер позволяет фильтровать URL по фрагментам и использовать регулярные выражения. Это уже превращает отчёт из списка адресов в инструмент технического аудита.
Например, можно отдельно проверить URL, содержащие параметры сортировки, служебные каталоги, результаты внутреннего поиска, метки и характерные части адресов фильтров. Если один шаблон генерирует огромный хвост страниц, это быстро становится заметно.
С GET-параметрами ситуация особенно коварная: часть параметрических страниц действительно нужна поиску, а часть создаёт практически те же документы под другими адресами. Закрывать всё подряд нельзя. Я отдельно разбирал эту тему в материале про GET-параметры и дубли в Яндексе.
Задача здесь не в том, чтобы добиться минимального количества URL. Нужно, чтобы робот тратил основное время на страницы, которые имеют смысл как самостоятельные документы.
Третье: сравниваем обход со структурой сайта
Полезный приём — мысленно разделить сайт на группы: категории, карточки, статьи, страницы услуг, фильтры, служебные разделы. А затем посмотреть, соответствует ли реальный обход тому, что для бизнеса важно.
Если робот ежедневно активно ходит по техническим страницам, но редко возвращается к обновляемым категориям, стоит искать причину в архитектуре. Возможно, полезные разделы глубоко спрятаны. Возможно, внутренняя перелинковка ведёт робота по кругу. Возможно, Sitemap содержит одно, а навигация сайта фактически рассказывает поисковику совсем другую историю.
Sitemap здесь полезен, но не является приказом поисковой системе. Яндекс прямо пишет, что наличие URL в Sitemap не гарантирует его появление в результатах поиска. Это способ сообщить о структуре и важных адресах, а не кнопка «проиндексировать».
Нужно ли вручную увеличивать скорость обхода
В Вебмастере можно изменить рекомендованную скорость обхода. Но делать это первым шагом я бы не стал.
По умолчанию Яндекс сам рассчитывает скорость так, чтобы загрузить максимум страниц без чрезмерной нагрузки на сервер. Более того, заданное вручную значение остаётся рекомендацией: фактическая интенсивность обращений может отличаться.
Если робот тратит запросы на дубли и служебные страницы, сначала логичнее убрать источник мусора. Если сервер отвечает медленно или периодически падает, сначала лечится сервер. И только когда структура чистая, ответы стабильны, а полезных страниц действительно много, имеет смысл думать о скорости как об отдельном параметре.
Почему robots.txt не всегда решает проблему дублей
Есть соблазн увидеть ненужные URL и сразу добавить десяток Disallow. Иногда это правильное решение, но сначала надо понять природу страниц.
Если адрес должен исчезнуть и больше никогда не нужен роботу, запрет обхода может сократить лишние обращения. Но если задача — склеить несколько доступных вариантов одной страницы, могут быть уместнее редирект или canonical. Яндекс отдельно указывает, что страницы с одинаковым содержимым могут объединяться в группы дублей, а выбранный поиском главный URL иногда меняется.
То есть «не хочу видеть этот URL в статистике обхода» и «хочу правильно решить проблему дубля» — не всегда одна и та же задача.
Как я бы проводил проверку
- Открыть статистику обхода минимум за несколько дней, а не делать вывод по одному пику.
- Отфильтровать 4xx и 5xx и понять происхождение ошибок.
- Посмотреть редиректы и проверить, нет ли массовых цепочек.
- Сгруппировать URL по характерным фрагментам: параметры, фильтры, поиск, служебные каталоги.
- Сравнить активность робота по полезным и техническим разделам.
- Проверить внутренние ссылки, Sitemap, canonical и robots.txt для подозрительных групп.
- После исправлений наблюдать не только за обходом, но и за разделом «Страницы в поиске».
Если после исправлений нужно быстрее сообщить Яндексу об изменённых документах, можно использовать переобход и обновление Sitemap. Но это уже следующий этап. Про него есть отдельный разбор — как ускорить переиндексацию и не тратить лимиты впустую.
Главная мысль
Статистика обхода полезна не потому, что позволяет считать визиты робота. Ценность отчёта в другом: он показывает техническую реальность сайта глазами индексатора.
Если там преобладают полезные канонические страницы с нормальными ответами сервера — хорошо. Если робот занят параметрами, дублями, цепочками редиректов и старыми адресами, бесконечно отправлять новые URL на переобход бессмысленно.
Сначала стоит привести в порядок маршруты, по которым робот ходит. И только потом ускорять его.