Crawl Budget: что это такое и как оптимизировать краулинговый бюджет сайта

Crawl Budget, или краулинговый бюджет, показывает, сколько URL поисковая система готова просканировать на сайте за определённый период и как она распределяет эти ресурсы между страницами. Если робот тратит большую часть запросов на параметры фильтров, дубли, цепочки редиректов и ошибки, новые товары, статьи и категории могут обнаруживаться и обновляться медленнее.

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

В этом руководстве разберём, из чего складывается crawl budget, как определить реальную проблему, какие отчёты и серверные логи использовать и что исправлять в первую очередь. Главная цель оптимизации — не заставить робота делать как можно больше запросов, а направить доступные ресурсы на важные канонические страницы.

Содержание

• Что такое Crawl Budget
• Как поисковая система планирует обход
• Кому нужна оптимизация
• Как понять, что бюджет расходуется неэффективно
• Факторы краулингового бюджета
• Что расходует бюджет впустую
• Как провести аудит
• Как оптимизировать Crawl Budget
• Практические примеры
• Типичные ошибки
• Чек-лист
• FAQ
• Вывод

Что такое Crawl Budget простыми словами

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

Краулинговый бюджет можно представить как сочетание двух ограничений:

1. Сколько запросов сайт способен стабильно принимать от робота.
2. Сколько URL поисковая система считает полезным и необходимым сканировать.

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

Crawl Budget не является фиксированным числом

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

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

Crawl Budget, сканирование и индексация

Обход не равен индексации. Робот может запросить URL и не добавить его в поиск. Например, документ окажется дублем, получит noindex, укажет canonical на другую страницу или будет признан малополезным.

Путь страницы выглядит упрощённо так:

Обнаружение URL → очередь обхода → запрос к серверу → рендеринг → обработка → решение об индексации

Оптимизация crawl budget работает на первых этапах: помогает роботу быстрее находить и повторно посещать правильные адреса. Она не заменяет качество контента и не гарантирует позиции.

Crawl rate и crawl demand

Для практической работы полезно разделять два понятия.

Crawl rate limit — примерное ограничение интенсивности запросов, при которой робот не создаёт чрезмерную нагрузку на сервер. Если сайт отвечает быстро и без ошибок, лимит может увеличиваться. Если начинаются тайм-ауты и 5xx, робот обычно снижает активность.

Crawl demand — потребность поисковой системы в обходе конкретных URL. Страницы с важными изменениями, входящими ссылками, пользовательским спросом и высокой значимостью могут посещаться чаще. Дубли, пустые фильтры и давно не меняющиеся документы — реже.

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

Как поисковая система планирует обход сайта

Поисковый робот обнаруживает URL из нескольких источников:

• внутренних ссылок;
• XML-карт сайта;
• внешних ссылок;
• ранее известных адресов;
• редиректов;
• RSS и других фидов;
• hreflang;
• ссылок в структурированных данных;
• API и специальных механизмов отправки URL.

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

Приоритет URL в очереди

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

На приоритет влияют:

• глубина клика от главной;
• количество и качество внутренних ссылок;
• внешние ссылки;
• частота обновления;
• наличие в sitemap;
• дата последней модификации;
• востребованность страницы;
• история успешных ответов;
• уникальность и каноничность URL.

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

Повторный обход

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

Не стоит искусственно менять дату lastmod для каждого URL каждый день. Когда робот видит, что дата обновилась, а содержимое осталось прежним, сигнал перестаёт быть полезным.

Рендеринг JavaScript

Для JavaScript-сайтов одного получения HTML иногда недостаточно. Поисковой системе может потребоваться отдельная очередь рендеринга. Если основной контент появляется только после выполнения скриптов, процесс обработки усложняется.

Статическая генерация, SSR и доступный исходный HTML уменьшают зависимость от второго этапа. Для Gatsby важно проверять файлы итоговой сборки, а не только интерфейс в браузере.

Каким сайтам нужна оптимизация Crawl Budget

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

Крупные интернет-магазины

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

Маркетплейсы и агрегаторы

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

Новостные и контентные порталы

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

Сайты объявлений и недвижимости

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

Международные и региональные проекты

Языковые и региональные версии умножают число URL. Ошибки hreflang, дубли регионов и неправильные canonical заметно усложняют обход.

Небольшие сайты

Проекту на 50–500 уникальных страниц обычно не нужна отдельная «борьба за бюджет». Но ему всё равно полезны чистый sitemap, отсутствие битых ссылок, стабильный сервер и нормальная архитектура. Если небольшой сайт индексируется медленно, чаще причина находится в качестве, внутренних ссылках, noindex, canonical или технических ошибках. Разбор таких ситуаций есть в статье почему страницы не индексируются.

Как понять, что Crawl Budget расходуется неэффективно

Нельзя диагностировать проблему только по медленному появлению одной статьи. Нужна совокупность признаков.

Новые важные страницы долго не сканируются

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

Большая разница между известными и полезными URL

Например, в каталоге 50 тысяч товаров, а краулер находит 2 миллиона адресов. Разница создаётся фильтрами, сортировками, идентификаторами сессий и повторяющимися маршрутами.

В логах преобладают технические URL

Если значительная доля запросов Googlebot и YandexBot приходится на ?sort=, ?filter=, внутренний поиск, редиректы и 404, ресурс обхода используется не по приоритету.

Важные разделы посещаются редко

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

Много ответов 3xx, 4xx и 5xx

Редиректы и ошибки не всегда являются потерей: робот должен иногда проверять удалённые URL. Проблема появляется, когда сайт продолжает массово ссылаться на них и включает их в sitemap.

Сервер замедляется во время обхода

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

Основные факторы краулингового бюджета

Стабильность и скорость сервера

Поисковый робот старается не перегружать сайт. Быстрые стабильные ответы позволяют выполнять больше запросов. Повторяющиеся тайм-ауты, 502, 503 и 504 заставляют снизить активность.

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

Размер и структура сайта

Чем больше уникальных страниц, тем больше ресурсов требуется. Но особенно важна разница между логическим размером и числом технически доступных URL.

Сайт из 100 тысяч товаров с чистыми адресами может обходиться эффективнее, чем каталог из 10 тысяч товаров, создающий миллионы фильтров.

Внутренняя перелинковка

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

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

Sitemap.xml

Карта сайта перечисляет URL, которые владелец рекомендует сканировать и индексировать. В ней должны находиться канонические страницы с ответом 200, без noindex и редиректов.

Подробная настройка разобрана в руководстве по sitemap.xml. Для крупных сайтов карты разделяют по типам страниц и контролируют статистику каждой группы.

Популярность и ссылки

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

Частота содержательных изменений

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

Качество и дубли

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

Что расходует краулинговый бюджет впустую

Параметры URL

Сортировки, фильтры, UTM-метки, идентификаторы сессий и служебные параметры создают альтернативные адреса одного содержимого:

/catalog/shoes/
/catalog/shoes/?sort=price
/catalog/shoes/?utm_source=email
/catalog/shoes/?session=123

Если все версии доступны по внутренним ссылкам, робот может обходить их многократно.

Фасетная навигация

Фильтры полезны пользователям и иногда формируют ценные посадочные страницы. Но бесконтрольные комбинации быстро создают практически бесконечное пространство URL.

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

Внутренний поиск

Страницы результатов поиска обычно не предназначены для индексации. Бесконечное число запросов создаёт слабые и нестабильные документы. Не включайте их в sitemap и не делайте массово доступными через индексируемые ссылки.

Дубли протокола, домена и слеша

HTTP/HTTPS, www, регистр, слеш и альтернативные пути должны приводиться к одной версии. Для ненужных вариантов используйте единообразные 301-редиректы, self-canonical и правильные внутренние ссылки.

Цепочки редиректов

Каждый дополнительный переход требует запроса. Обновите ссылки так, чтобы они сразу вели на конечный URL:

Старый URL → 301 → конечный URL

вместо:

URL A → URL B → URL C → URL D

Битые внутренние ссылки

Если сайт продолжает ссылаться на тысячи удалённых страниц, робот снова и снова получает 404. Исправьте ссылку, настройте релевантный редирект или удалите её.

Календарные ловушки

Архивы с бесконечными ссылками «следующий месяц» позволяют роботу уходить на годы вперёд или назад. Ограничьте диапазон и не создавайте пустые архивы.

Бесконечная прокрутка

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

Страницы-сироты

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

Медленные и тяжёлые страницы

Долгий TTFB, большие HTML-документы и дорогой рендеринг снижают эффективность каждого запроса. Практические способы ускорения собраны в материале как сократить время загрузки сайта.

Как провести аудит Crawl Budget

Шаг 1. Определите полезный набор URL

Соберите страницы, которые должны участвовать в поиске: товары в наличии, категории, услуги, статьи и индексируемые региональные документы. Это эталонный список.

Шаг 2. Просканируйте сайт

Используйте технический краулер и получите все доступные URL, коды ответов, canonical, директивы robots, глубину, входящие ссылки и тип контента.

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

Шаг 3. Проверьте sitemap

Выгрузите все карты и найдите:

• редиректы;
• ошибки;
• неканонические URL;
• страницы с noindex;
• дубли;
• устаревшие адреса;
• отсутствующие важные страницы.

Шаг 4. Проанализируйте Google Search Console

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

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

Шаг 5. Проверьте Яндекс.Вебмастер

Сравните загруженные и исключённые страницы, ошибки обхода, sitemap и дату последнего посещения важных URL. Для российского проекта данные Яндекса нужно анализировать отдельно: поведение разных роботов не обязано совпадать.

Шаг 6. Изучите серверные логи

Логи дают фактическую картину запросов. Для каждой записи полезны:

• дата и время;
• URL;
• HTTP-код;
• User-Agent;
• IP;
• время ответа;
• размер ответа;
• referrer, если доступен.

Подтвердите принадлежность бота поисковой системе, потому что User-Agent легко подделать. Затем сгруппируйте запросы по каталогам и шаблонам.

Рассчитайте:

• долю 200, 3xx, 4xx, 5xx;
• самые посещаемые разделы;
• URL, которые не посещались;
• частоту обхода важных страниц;
• долю параметрических URL;
• среднее и высокие перцентили времени ответа;
• различия между Googlebot и YandexBot.

Шаг 7. Найдите страницы-сироты

Сравните URL из логов, sitemap, аналитики и базы сайта с результатом внутреннего краулинга. Адреса, которые существуют, но не обнаружены по ссылкам, требуют отдельного решения.

Шаг 8. Составьте приоритеты

Не исправляйте всё одновременно. Оцените влияние и сложность:

Как подготовить логи к анализу

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

Приведите URL к сопоставимому виду, но не теряйте исходные данные. Отдельно сохраните путь, параметры, код ответа, время ответа и User-Agent. Затем классифицируйте адреса по шаблонам:

/product/      → карточки товаров
/catalog/      → категории
/blog/         → статьи
?filter=       → фасетная навигация
?sort=         → сортировки
/search/       → внутренний поиск

Такая группировка полезнее списка из тысячи самых посещаемых URL: она показывает, какой тип страниц получает ресурсы робота.

Как подтвердить поискового робота

Нельзя доверять только строке User-Agent. Любой сканер способен представиться Googlebot или YandexBot. Для точного анализа проверяют IP с помощью обратного DNS и последующего прямого DNS-запроса либо используют официальные диапазоны адресов, если поисковая система их публикует.

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

Какие показатели рассчитывать

Минимальный отчёт по каждому роботу должен содержать:

Отдельно сформируйте список важных страниц, которые не запрашивались за анализируемый период. Если они присутствуют в sitemap и имеют внутренние ссылки, но не посещаются, проверьте глубину, canonical, качество раздела и историю ответов.

Сегментация по типу устройства и ресурса

В логах могут присутствовать разные роботы и запросы к HTML, изображениям, CSS и JavaScript. Не смешивайте их в одном показателе. Для проблемы индексирования документов сначала анализируйте HTML-URL, затем проверяйте, доступны ли ресурсы, необходимые для рендеринга.

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

Сравнение до и после внедрения

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

Хороший результат может выглядеть так:

• общее количество запросов почти не изменилось;
• доля параметров снизилась;
• доля ответов 200 выросла;
• новые товары обнаруживаются быстрее;
• важные категории посещаются чаще;
• среднее время ответа стало стабильнее.

То есть эффективность повышается даже без роста формального количества обращений робота.

Robots.txt, noindex и canonical: разные инструменты

При оптимизации crawl budget часто пытаются найти одну директиву, которая решит все проблемы. На практике robots.txt, noindex, canonical и редирект выполняют разные задачи.

Robots.txt управляет доступом к обходу

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

Если адрес уже известен по ссылкам, поисковик может продолжать хранить сведения о нём без загрузки содержимого. Кроме того, при запрете обхода робот не увидит изменения HTML, noindex и canonical.

Noindex управляет участием в индексе

Директива noindex означает, что документ не должен находиться в поиске. Чтобы обработать её, робот должен запросить URL. Поэтому большое количество noindex-страниц всё равно может регулярно сканироваться.

Используйте noindex для страниц, которые нужны пользователю, но не должны участвовать в поиске. Не считайте его главным инструментом экономии запросов.

Canonical объединяет похожие версии

Canonical подсказывает, какой URL считать основным. Неканонические версии могут продолжать сканироваться, особенно если на них ведут ссылки. Наибольшая эффективность достигается, когда sitemap, внутренняя перелинковка и редиректы поддерживают выбранную версию.

Редирект переносит пользователя и робота

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

Выбор можно упростить:

Не применяйте несколько противоречивых решений одновременно. Например, URL, закрытый в robots.txt, с noindex и canonical на другую страницу создаёт неоднозначную схему: робот не сможет загрузить документ и проверить две оставшиеся директивы.

Как выбрать первые задачи для внедрения

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

Массовые 5xx на карточках товаров имеют высокий приоритет, потому что одновременно вредят обходу, индексации и пользователям. Несколько старых 404, на которые больше никто не ссылается, почти не требуют срочной работы. Миллион комбинаций фильтров выглядит масштабно, но перед ограничением необходимо выделить посадочные страницы с реальным спросом.

Для каждой задачи зафиксируйте:

• затронутый шаблон;
• пример URL;
• ожидаемое поведение;
• текущее поведение;
• выбранное решение;
• риск потери индексируемых страниц;
• метрику проверки;
• дату внедрения.

Сначала протестируйте правило на ограниченной группе URL. Проверьте коды ответа, canonical, robots, sitemap и внутренние ссылки, затем расширяйте изменение. Особенно осторожно внедряйте регулярные выражения в редиректах и robots.txt: одна слишком широкая маска способна затронуть весь каталог.

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

Как оптимизировать Crawl Budget

1. Устраните ошибки сервера

Стабильность важнее косметической очистки URL. Исправьте 5xx, тайм-ауты, перегруженные запросы и проблемы инфраструктуры. Настройте мониторинг, чтобы видеть ошибки не после падения трафика, а сразу.

2. Приведите зеркала к одной версии

Настройте прямые 301-редиректы с HTTP, альтернативного поддомена и неправильного формата URL. Внутренние ссылки, canonical и sitemap должны использовать итоговую версию.

3. Очистите sitemap.xml

Оставьте только индексируемые канонические страницы с 200 OK. Разделите карты по типам контента, если это помогает диагностике. Не используйте sitemap как архив всех когда-либо существовавших адресов.

4. Исправьте внутренние ссылки

Ссылки должны вести непосредственно на 200-страницы, а не на редиректы и ошибки. Добавьте пути к приоритетным документам и устраните сироты.

5. Управляйте параметрами

Определите назначение каждого параметра. В зависимости от ситуации применяются:

• canonical;
• редирект;
• отказ от генерации ссылки;
• noindex;
• ограничения обхода;
• единый порядок параметров;
• серверная нормализация.

Robots.txt не решает все задачи параметров. Закрытый URL может оставаться известным поисковику, а робот не увидит его canonical или noindex. Настраивать директивы нужно в общей стратегии. Основы файла описаны в статье про robots.txt.

6. Контролируйте фасетную навигацию

Разделите комбинации на три группы:

1. Посадочные страницы с поисковым спросом.
2. Полезные пользователю фильтры без самостоятельного SEO-интента.
3. Бесполезные и пустые комбинации.

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

7. Сократите цепочки редиректов

Обновите внутренние ссылки и sitemap. Старые внешние URL могут оставаться с 301, но робот должен попадать сразу на конечный документ.

8. Удалите ссылки на 404

Сам код 404 корректен для удалённого URL. Проблема — постоянное обнаружение ошибки внутри сайта. Уберите ссылку или замените её актуальной.

9. Улучшите архитектуру

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

10. Используйте canonical последовательно

Canonical должен поддерживаться внутренними ссылками, sitemap и редиректами. Нельзя указывать один основной URL и одновременно усиливать другой. Подробные сценарии разобраны в статье про rel=canonical.

11. Работайте с удалёнными товарами и объявлениями

Решение зависит от ситуации:

• временно отсутствует — сохраните страницу и предложите аналоги;
• заменён новой моделью — релевантный 301;
• удалён без аналога — 404 или 410;
• имеет устойчивый спрос и полезные данные — можно сохранить архивную информационную страницу.

Не перенаправляйте все удалённые товары на главную: это слабая и нерелевантная замена.

12. Оптимизируйте JavaScript

Отдавайте основной контент и ссылки в HTML. Не заставляйте робота выполнять сложные действия для обнаружения товаров. Следите за ошибками рендеринга и доступностью API.

13. Обновляйте lastmod честно

Указывайте дату существенного изменения. Массовое ежедневное обновление дат без изменения содержимого создаёт лишние сигналы и не делает страницы важнее.

14. Закройте тестовые среды

Тестовые домены должны быть защищены авторизацией и не получать публичные ссылки. Одного robots.txt недостаточно для защиты конфиденциальных данных.

15. Измеряйте результат

После внедрения сравните периоды до и после:

• долю запросов к важным URL;
• долю параметров;
• ответы 3xx, 4xx, 5xx;
• время ответа;
• скорость обнаружения новых страниц;
• количество индексируемых канонических документов;
• показы и органический трафик.

Цель не обязательно состоит в росте общего числа запросов. Если робот делает меньше запросов, но чаще посещает полезные страницы, оптимизация успешна.

KPI для контроля краулингового бюджета

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

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

Второй показатель — время до первого обхода. Для новых товаров, статей или объявлений измеряйте промежуток между публикацией и первым запросом робота. Если после улучшения sitemap и перелинковки медианное время сокращается, обнаружение работает эффективнее.

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

Четвёртый показатель — техническое качество ответов:

• доля прямых 200;
• количество переходов через 3xx;
• доля внутренних 404;
• доля 5xx;
• 95-й перцентиль TTFB;
• количество уникальных параметрических URL.

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

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

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

Регулярный отчёт удобно строить по неделям или месяцам. Добавляйте отметки о релизах и крупных изменениях, чтобы отличать эффект оптимизации от сезонности, миграции или временной аварии сервера.

Практические примеры

Интернет-магазин с фильтрами

Исходно каталог содержит 30 тысяч товаров, но технический краулер обнаруживает 1,8 миллиона URL. Основной источник — комбинации бренда, размера, цвета, сортировки и диапазона цены.

Решение:

1. По семантике выбираются востребованные комбинации.
2. Для них создаются отдельные посадочные страницы.
3. Остальные фильтры не добавляются в sitemap.
4. Ссылки на бесконечные комбинации ограничиваются.
5. Canonical и директивы настраиваются по типу фильтра.
6. В логах контролируется снижение обхода параметров.

Результат оценивается не только по числу проиндексированных страниц, но и по росту частоты обхода товаров и категорий.

Новостной портал с архивами

Робот активно посещает календарные URL за будущие и далёкие прошлые даты, в то время как новые публикации обнаруживаются медленно.

Решение:

• ограничить календарную навигацию реальным диапазоном;
• удалить ссылки на пустые месяцы;
• создать отдельный новостной sitemap;
• усилить ссылки с главной и рубрик;
• корректно обновлять lastmod;
• устранить дубли тегов и архивов.

Сайт после миграции

Внутренние ссылки ведут на старые адреса, которые проходят через два редиректа. Sitemap содержит смесь старых и новых URL.

Решение:

• заменить ссылки на конечные;
• оставить прямой 301 со старого на новый URL;
• пересоздать sitemap;
• исправить canonical;
• проверить коды и логи;
• сопоставить страницы до и после миграции.

Каталог с удалёнными товарами

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

Решение:

• своевременно удалять ссылки;
• сохранять полезные карточки временно отсутствующих товаров;
• использовать релевантные редиректы только при наличии замены;
• отдавать корректный 404 или 410 без ложного 200;
• обновлять sitemap.

Типичные ошибки при оптимизации

Закрыть все параметры в robots.txt

Такой подход может помешать роботу увидеть canonical и noindex. Кроме того, среди параметров могут быть полезные посадочные страницы. Сначала классифицируйте URL.

Считать каждый запрос робота расходом, который нужно запретить

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

Удалить пагинацию

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

Массово использовать nofollow во внутренних ссылках

Это не является надёжным способом управления бюджетом и нарушает передачу сигналов внутри архитектуры. Лучше не создавать бесполезный URL или ссылку на него.

Подменять 404 редиректом на главную

Нерелевантный редирект может восприниматься как soft 404. Используйте подходящую замену либо честный код удаления.

Оценивать только sitemap

Робот обнаруживает URL и из других источников. Даже чистая карта не поможет, если меню и фильтры создают миллионы адресов.

Игнорировать Яндекс или Google

У разных систем собственные очереди и частота обхода. Анализируйте данные отдельно и не переносите вывод автоматически.

Вносить десятки изменений одновременно

Сложно определить, какое действие дало результат. Работайте итерациями, фиксируйте даты и сравнивайте логи.

Чек-лист оптимизации Crawl Budget

Сервер

• Важные страницы стабильно возвращают 200.
• Нет массовых 5xx и тайм-аутов.
• TTFB контролируется под нагрузкой.
• Ошибки логируются и сопровождаются мониторингом.
• Поисковые роботы не блокируются CDN или защитой.

URL и дубли

• HTTP и альтернативные зеркала перенаправляются на основную версию.
• Формат слеша и регистра единообразен.
• Параметры классифицированы.
• Нет бесконечных комбинаций фильтров.
• Canonical согласован с внутренними ссылками.
• Удалены идентификаторы сессий из URL.

Внутренняя структура

• На важные страницы ведут обычные HTML-ссылки.
• Нет массовых ссылок на редиректы и ошибки.
• Найдены и обработаны страницы-сироты.
• Глубина клика соответствует приоритету.
• Пагинация позволяет обнаружить содержимое.

Sitemap и директивы

• В sitemap находятся только канонические 200-страницы.
• Нет URL с noindex.
• Нет редиректов и ошибок.
• lastmod отражает реальные изменения.
• Robots.txt не блокирует необходимые ресурсы.
• Карты разделены по типам, если это полезно для анализа.

Контроль

• Проверена статистика сканирования Google.
• Проверены данные Яндекс.Вебмастера.
• Проанализированы серверные логи.
• Подтверждены настоящие боты.
• Рассчитана доля параметров и ошибок.
• Зафиксированы показатели до изменений.
• Результат проверен после повторного обхода.

Часто задаваемые вопросы

Как узнать точный Crawl Budget сайта?

Единого точного числа нет. Оценивайте фактические запросы в логах, статистику сканирования, частоту обхода важных URL и стабильность сервера за достаточно длинный период.

Нужна ли оптимизация сайту на 100 страниц?

Обычно отдельной проблемы бюджета нет. Сначала проверьте доступность, качество, sitemap, canonical и внутренние ссылки. Исключение — сайт генерирует огромное число параметрических дублей.

Увеличивает ли sitemap краулинговый бюджет?

Sitemap помогает обнаруживать и приоритизировать URL, но не создаёт гарантированный дополнительный лимит. Чистая карта делает обход эффективнее.

Нужно ли закрывать фильтры в robots.txt?

Не автоматически. Среди фильтров могут быть полезные посадочные страницы. Для остальных вариантов выбирают сочетание архитектуры, canonical, noindex, ограничения ссылок и правил обхода.

Экономит ли noindex Crawl Budget?

Не напрямую. Чтобы увидеть noindex, робот должен запросить страницу. Директива управляет индексацией, а не запрещает обход.

Влияет ли скорость сайта на обход?

Да, особенно скорость и стабильность ответа сервера. Повторяющиеся тайм-ауты и 5xx могут снизить интенсивность запросов.

Нужно ли удалять 404?

Корректный 404 нужен для удалённых страниц. Следует удалить внутренние ссылки и URL из sitemap, чтобы робот не обнаруживал ошибку снова. При наличии релевантной замены используйте 301.

Как часто анализировать логи?

Для крупного динамического проекта полезен постоянный мониторинг и регулярный отчёт. Для среднего сайта — после миграций, крупных релизов и при появлении проблем индексации.

Может ли canonical полностью решить проблему дублей?

Canonical помогает объединять сигналы, но не отменяет обход всех доступных URL. Лучше дополнительно исправить внутренние ссылки, sitemap и генерацию параметров.

Что важнее: увеличить обход или сократить лишние URL?

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

Когда ждать результат после оптимизации?

Поисковым системам нужно повторно обойти сайт. Изменения в логах могут быть заметны раньше, чем обновление индекса и трафика. Срок зависит от масштаба, частоты обхода и характера исправлений.

Вывод

Crawl Budget — это не магический лимит, который нужно любой ценой увеличить. Это результат взаимодействия возможностей сервера, интереса поисковой системы к URL и качества архитектуры сайта в целом.

Правильная оптимизация начинается с данных: технического краулинга, sitemap, Google Search Console, Яндекс.Вебмастера и серверных логов. После этого устраняются 5xx, бесконечные параметры, дубли, цепочки редиректов, битые ссылки и страницы-сироты.

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

Для дальнейшей проверки используйте материалы про индексацию сайта, причины отсутствия страниц в поиске, robots.txt, sitemap.xml, падение поискового трафика, техническое SEO и определения из SEO-глоссария.