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

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

Google называет темой управления crawl budget прежде всего очень крупные сайты с миллионом и более страниц, либо проекты от десяти тысяч URL, которые меняются ежедневно, а также сайты с большой долей Discovered - currently not indexed. Числа являются ориентиром, а не порогом для любой компании. Полная логика описана в официальном руководстве Google.

Поэтому начинать нужно с симптома, а не с термина. Новая важная страница может не попасть в обход из-за слабой внутренней связи, запрета в robots, неправильного canonical или недоступности сервера. Ни один из этих случаев не исправляется общим требованием «дать больше бюджета».

Яндекс Вебмастер тоже дает наблюдаемые данные: в разделе «Статистика обхода» можно увидеть дату посещения, URL и код ответа, а также отфильтровать конкретный раздел. Количество обращений может меняться по дням и само по себе не является сигналом падения ранжирования. Это стоит учитывать, прежде чем превращать один график в срочную задачу. Подробнее о возможностях отчета сказано в справке Яндекса.

Из чего складывается «бюджет» на самом деле

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

Это снимает распространенное заблуждение: не существует одной кнопки, которая «увеличивает бюджет». Результат складывается из того, как сайт отвечает, какие адреса производит и какие из них команда последовательно называет основными. Google рекомендует управлять URL-инвентарем, объединять дубли и поддерживать HTTP-кэширование с 304 Not Modified, когда содержание не менялось.

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

Найдите классы URL, а не тысячи отдельных адресов

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

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

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

Три действия, которые дают эффект раньше остальных

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

Не стоит начинать с robots.txt только потому, что он быстро меняется. Закрытие адреса подходит для страниц, которые не должны обходиться, но не исправляет уже созданный хаос в ссылках, Sitemap или canonical. Яндекс отдельно рекомендует сначала посмотреть последние обращения к сайту и обращать внимание на GET-параметры, которые часто ведут к одинаковому содержанию. Его рекомендации по снижению нагрузки полезны именно как диагностика классов URL, а не как повод блокировать все подряд.

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

Sitemap помогает объявить приоритет, но не заменяет структуру

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

Для сайта полезно договориться, где источник истины для URL: CMS, продуктовый каталог, реестр услуг или статический контент. Затем проверить, что генератор Sitemap берет только финальные адреса из этого источника. Подробная приемка файла разобрана в руководстве по XML Sitemap, а сама карта должна поддерживать уже принятую структуру, а не пытаться ее заменить.

Как проверить, что задача решена

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

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

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

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

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

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

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