Краулинговый бюджет большого магазина на 1С-Битрикс

Большой интернет-магазин часто сталкивается с обидной ситуацией: каталог растёт, товары добавляются, а в поиске они появляются с задержкой в недели, изменения цен и наличия доходят до выдачи медленно, часть важных карточек вообще не в индексе — при том что контент нормальный и запретов на индексацию нет. Причина обычно не в контенте и не в ссылках, а в том, как поисковый робот обходит сайт: он тратит основную массу запросов на мусорные URL фильтра, сортировок и дублей, а до коммерчески важных страниц доходит редко. Это и есть проблема краулингового бюджета — объёма ресурсов, который поиск готов потратить на обход вашего сайта. На маленьком сайте бюджета хватает с запасом, и о нём не думают. На каталоге в десятки и сотни тысяч URL он становится узким местом, и от того, на что робот его расходует, напрямую зависит скорость и полнота индексации.

Эта статья — практический разбор того, как управлять краулинговым бюджетом большого магазина на 1С-Битрикс: что такое crawl budget и когда он реально важен, из чего он складывается (лимит скорости обхода и спрос на обход), что тратит его впустую (мусорные параметры фильтра и сортировки, дубли, сессии, цепочки редиректов, мягкие 404, бесконечная пагинация) и как экономить — через robots.txt и Clean-param, noindex и canonical, приоритизацию важных страниц, чистую структуру и перелинковку, ускорение ответа сервера, sitemap как подсказку приоритетов и lastmod. Разберём, как читать логи веб-сервера и понимать, что и как часто обходит Яндекс и Google, как склеивать дубли и управлять индексацией умного фильтра через агрегатные страницы, и как мониторить обход по связке «загружено роботом» против «страниц в поиске». Материал вырос из нашей практики SEO-продвижения интернет-магазинов — по делу, без «воды» и обещаний «топа за неделю».

Зачем большому магазину думать об обходе

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

Разложим пользу этой работы на конкретные задачи, которые она решает для большого магазина:

• Ускоряет индексацию нового. Когда робот не вязнет в мусорных URL, новые товары и категории он находит и заносит в индекс быстрее — а значит, быстрее начинают собирать трафик.
• Держит выдачу актуальной. Изменения цен, наличия и описаний доходят до поиска оперативнее, потому что робот чаще переобходит важные страницы, а не копии.
• Повышает полноту индекса. Экономия бюджета убирает ситуацию, когда часть каталога годами «загружена, но не в поиске» из-за того, что до неё не доходят руки робота.
• Снимает нагрузку с сервера. Робот перестаёт десятки тысяч раз в сутки дёргать бесполезные URL — меньше паразитной нагрузки, стабильнее ответ для людей.
• Усиливает сигналы. Когда обход и вес не размазаны по тысячам дублей, а сконцентрированы на канонических страницах, эти страницы ранжируются увереннее.
• Делает работу измеримой. Появляются понятные метрики — распределение обхода по логам, разрыв «загружено / в поиске», скорость индексации, — по которым видно прогресс.

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

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

Краулинговый бюджет (англ. crawl budget) — это объём ресурсов, который поисковая система готова потратить на обход конкретного сайта за определённый период. Проще говоря, это ответ на вопрос «сколько ваших страниц робот скачает и как часто он к ним вернётся». Робот не запрашивает страницы бесконечно: у него есть предел по числу обращений к вашему серверу и есть представление о том, сколько ваших URL вообще стоит обходить. Пересечение этих двух ограничений и есть практический бюджет обхода.

Чтобы не путать понятия, разведём три близких, но разных процесса:

• Обход (crawling). Робот запрашивает URL и скачивает его содержимое. Именно на это тратится краулинговый бюджет. Обход не равен попаданию в индекс.
• Индексация (indexing). Система анализирует скачанную страницу и решает, добавлять ли её в индекс. Страница может быть обойдена, но не проиндексирована (дубль, малоценная, неканоническая).
• Ранжирование (ranking). Из проиндексированных страниц система выбирает, что и на каких позициях показать по запросу. Это уже следующий этап, вне темы бюджета.

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

Из чего складывается бюджет обхода

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

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

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

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

Когда бюджет реально важен

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

Признаки, что краулинговый бюджет стал узким местом:

• Большой каталог. Ориентировочно от десятков тысяч URL и выше. На нескольких сотнях или паре тысяч чистых страниц бюджета хватает с запасом — оптимизировать нечего.
• Много мусорных URL. Открытые для обхода параметры фильтра, сортировки, сессии, дубли — робот вынужден их обходить, и они множат число адресов в разы относительно реального числа товаров.
• Медленная индексация нового. Новые товары и категории подолгу не появляются в поиске, хотя запретов на индексацию нет.
• Отставание обновлений. Изменения цен, наличия, описаний медленно доходят до выдачи — робот редко переобходит важные страницы.
• Разрыв «загружено / в поиске». В панелях вебмастеров «загружено роботом» в разы больше, чем «страниц в поиске», и разрыв растёт.
• Мусор в статистике обхода. По логам видно, что основная масса запросов робота уходит на URL с параметрами, а не на канонические товары и категории.

Если этих признаков нет — каталог небольшой, страницы чистые, новое индексируется быстро — работа над бюджетом не даст ощутимого эффекта, и силы лучше вложить в семантику, контент и структуру. Если признаки есть — это прямой сигнал заняться чисткой мусорных URL, ускорением ответа сервера и приоритизацией обхода. Важная оговорка: даже на большом каталоге бюджет — не единственная и часто не главная причина проблем с индексацией. Прежде чем «оптимизировать обход», всегда проверяют базовое: не закрыты ли важные страницы в robots или noindex по ошибке, нет ли на них технических запретов. Бюджетом занимаются, когда «стопы» индексации сняты, а проблема именно в том, что робот не доходит до нужного из-за масштаба и мусора. Как в целом проверять индексацию магазина, мы разбираем в статье про технический SEO-аудит на 1С-Битрикс.

Что тратит бюджет впустую

Прежде чем экономить бюджет, нужно понять, куда он утекает. На большом магазине на 1С-Битрикс есть устойчивый набор «пожирателей» обхода — URL, которые робот запрашивает, но которые не несут пользы: это копии, мусор и технические артефакты. Разберём их по группам, а в следующих разделах — как с каждым бороться.

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

Мусор умного фильтра и сортировок

Умный фильтр — главный источник мусорных URL в магазинах на 1С-Битрикс и обычно самый крупный канал утечки бюджета. Механика простая: каждое пересечение значений характеристик (цвет, размер, бренд, цена, десятки других свойств) формирует отдельный URL. Число возможных комбинаций растёт комбинаторно — на большом каталоге это сотни тысяч и миллионы потенциальных адресов, и робот, если ему не мешать, начинает их обходить.

Что именно порождает мусор в этом блоке:

• Комбинации фасетов. Любое сочетание выбранных значений фильтра — новый URL. Большинство таких комбинаций не имеют поискового спроса и почти дублируют друг друга.
• Параметры сортировки. ?sort=price, по названию, по популярности — один и тот же список товаров в разном порядке под разными адресами.
• Показ по N товаров. Параметры количества выводимых элементов на странице дают дубли одного и того же списка.
• Пагинация внутри фильтра. Комбинации фасетов ещё и разбиваются на страницы — множитель к и без того огромному числу URL.

Правильная стратегия здесь двухуровневая. Часть комбинаций фильтра востребована спросом (например, «холодильники Samsung» или «смартфоны до 20000») — их превращают в полноценные агрегатные посадочные страницы: открывают для обхода и индексации, дают уникальные метатеги и текст, ставят на них внутренние ссылки. Всё остальное — бесконечный «хвост» бессмысленных пересечений, сортировки и показ по N — закрывают от обхода и индексации, чтобы робот на них не тратил бюджет. Именно это разделение «полезное открываем, мусор закрываем» и есть ядро управления обходом фильтра. Тонкая настройка этого механизма — отдельная большая тема, которой посвящена статья про агрегатные страницы фильтра и управление индексацией на 1С-Битрикс.

Дубли, сессии и метки

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

Идентификаторы сессий и метки в URL

Если движок или отдельные механизмы добавляют в адрес идентификатор сессии (?PHPSESSID=) или в ссылки попадают рекламные и партнёрские метки (?utm_source=, метки маркетплейсов), каждая такая метка порождает новый URL с тем же контентом. На большом трафике это плодит десятки тысяч уникальных адресов буквально из воздуха. Сессии в URL для роботов должны быть отключены, а метки — отсекаться на уровне канонического адреса и игнорироваться директивой Clean-param.

Слеш, регистр, index.php

Одна страница часто доступна со слешем на конце и без него, с /index.php и без, в разном регистре букв. Для поиска это разные URL с одинаковым содержимым. Решение — выбрать единый канонический формат и настроить 301-редирект со всех прочих написаний на него, а также следить за единообразием внутренних ссылок, чтобы сам сайт не плодил варианты.

www, протокол и зеркала

Сайт должен открываться строго в одном варианте — только по https, в одном написании домена. Если одновременно доступны http и https, www и без-www без склейки, для поиска это несколько копий сайта, и робот делит бюджет между ними. Настроенный 301 на единое главное зеркало убирает эту утечку.

Товар в нескольких разделах

Частая ситуация в магазинах — один товар доступен по разным адресам, потому что привязан к нескольким разделам каталога. Без единого канонического URL это дубли, размывающие сигналы и обход. Каждому товару назначают одну каноническую страницу, а прочие адреса указывают на неё через canonical.

Каждая из этих групп лечится своим инструментом — 301 для «переехавших навсегда» написаний и зеркал, canonical и Clean-param для «полезных» дублей вроде меток. Детальный разбор склейки URL, борьбы с цепочками и битыми ссылками — в статье про robots.txt и карту сайта на 1С-Битрикс, где мы разбираем и directive-инструменты управления обходом.

Цепочки редиректов и soft-404

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

Цепочки редиректов. Когда URL A перенаправляет на B, B на C, а C на D, робот, чтобы дойти до конечной страницы, делает несколько запросов вместо одного. Каждый промежуточный шаг — потраченный впустую обход, плюс на длинных цепочках часть веса теряется, а робот может и вовсе не дойти до конца. Такие цепочки образуются годами: сменили ЧПУ, потом ещё раз, добавили склейку слешей поверх — и вместо прямого перехода накапливается лестница. Их «схлопывают» в один прямой редирект A → D, чтобы робот тратил на переход ровно один запрос.

Мягкие 404 (soft-404). Это страницы, которые по смыслу «ничего не найдено», но отдают код 200. Классика магазина: товар закончился или удалён, а его страница показывает «нет в наличии» или пустой список, но с кодом успешного ответа. Робот видит рабочую страницу без полезного контента, обходит её, индексирует пустышки и возвращается к ним снова — то есть тратит бюджет на то, чего фактически нет. Правильное поведение зависит от ситуации: временно отсутствующий товар — оставить страницу с кодом 200, показать статус и предложить аналоги; удалённый навсегда — отдать 404/410 или сделать 301 на релевантный раздел.

Отдельная утечка — ошибки 5xx. Серверные ошибки не просто теряют страницу: они прямо снижают лимит скорости обхода, потому что робот воспринимает их как сигнал перегрузки и уменьшает интенсивность запросов. Всплеск 5xx может обвалить обход всего сайта. Поэтому стабильность ответа так же важна для бюджета, как и скорость. Как грамотно организовать логику 404 и 410 для отсутствующих товаров, схлопнуть цепочки и навести порядок в кодах ответа на 1С-Битрикс — подробно в статье про управление обходом через robots и карту сайта.

Пагинация и бесконечные комбинации

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

Что важно учитывать по пагинации:

• Не канонизировать всё на первую страницу. Если у всех страниц пагинации поставить canonical на первую, робот может перестать доходить до товаров со 2-й, 3-й и дальше — они выпадут из обхода.
• Обеспечить доступность товаров иначе. Товары с глубоких страниц должны быть доступны роботу и через другие пути — категории, подкатегории, перелинковку, sitemap, — чтобы не зависеть только от глубокой пагинации.
• Пагинация внутри фильтра — под контроль. Комбинации фасетов, разбитые на страницы, дают множитель к числу URL. Мусорные комбинации закрывают целиком (вместе с их пагинацией), полезные агрегатные — открывают.
• Убирать бессмысленную глубину. Если списки уходят на сотни страниц, стоит подумать о структуре: больше подкатегорий, разумный размер страницы, чтобы важное было доступно за меньшее число шагов.

Общий принцип: пагинация — это транспорт для обхода товаров, а не самостоятельная ценность. Задача не «закрыть пагинацию ради экономии», а сделать так, чтобы все товары были доступны роботу коротким путём, а бюджет не уходил на бесконечные малоценные комбинации. На практике это сочетание чистой структуры каталога (глубокая, но логичная вложенность вместо плоских списков на тысячи позиций), продуманной перелинковки и управляемой индексации фильтра. Именно поэтому пагинацию нельзя трогать в отрыве от структуры и агрегатных страниц — всё это части одной системы обхода.

robots.txt и Clean-param

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

Что закрывают в robots.txt для экономии обхода:

• Служебные разделы. Административная часть, корзина, оформление заказа, сравнение, личный кабинет, результаты внутреннего поиска — то, что роботу обходить незачем.
• Технические скрипты и пути. Служебные обработчики, ajax-эндпоинты, системные каталоги, которые не должны попадать в обход.
• Очевидно мусорные параметрические пути. Часть параметров, которые заведомо не нужны в поиске, закрывают через Disallow с шаблонами.
• Ссылка на sitemap. Строка Sitemap: с адресом актуальной карты — чтобы робот знал приоритетный список URL.

Два важных предупреждения. Первое: robots.txt экономит обход, но не гарантирует исключение из индекса — если на закрытый URL ведут ссылки, он может показаться в выдаче без сниппета. Для гарантированного исключения нужен noindex (о нём дальше), а он требует, чтобы страница была открыта для обхода. Второе: нельзя закрывать ресурсы отрисовки — CSS и JS, нужные для рендеринга; иначе робот увидит «сломанную» страницу.

Практика на 1С-Битрикс: robots.txt формируют так, чтобы закрыть служебное и мусорные пути, прописать Clean-param на параметры сортировки, показа и меток, указать Sitemap и оставить открытыми ресурсы отрисовки. Штатные средства платформы позволяют генерировать корректный robots и карту сайта; типовые ошибки и правильную настройку мы разбираем в статье про robots.txt и sitemap.xml на 1С-Битрикс.

noindex и canonical

Если robots.txt управляет обходом, то noindex и rel="canonical" управляют индексацией и склейкой. Напрямую обход они экономят слабее (робот всё равно должен зайти на страницу, чтобы увидеть тег), но косвенно очень важны: они убирают дубли из индекса, снижают спрос на обход копий и со временем перенаправляют бюджет на канонические страницы. Разберём, где что применять.

• noindex — убрать из поиска, оставить доступной людям. Ставят на страницы, которые нужны пользователю, но не нужны в выдаче: результаты внутреннего поиска, служебные, «пустые» страницы фильтра без спроса. Важно: страница должна быть открыта для обхода, иначе робот не увидит noindex.
• canonical — склеить полезный дубль с главной версией. Ставят на страницы, которые должны открываться (сортировки, метки, вариации), указывая на чистый канонический URL. Поиск считает главной именно его и постепенно перестаёт тратить обход на копии.
• Не смешивать сигналы. Закрыть страницу в robots и одновременно ждать, что сработает noindex, — ошибка: робот не дойдёт до тега. И наоборот, canonical на странице, закрытой в robots, робот не увидит.

Ключевой нюанс для бюджета: canonical — это подсказка, а не запрет обхода. Робот всё равно периодически заходит на неканонические копии, чтобы проверить, что они по-прежнему копии. Поэтому на очень большом числе мусорных URL одного canonical мало — его сочетают с закрытием заведомо бесполезного в robots.txt и с Clean-param, чтобы робот вообще перестал их запрашивать. Схема разделения такая: полезный дубль, который должен открываться, — canonical; страница нужна людям, но не в поиске — noindex; заведомо бесполезный для обхода мусор — Disallow. Правильная комбинация этих трёх инструментов и определяет, насколько эффективно тратится бюджет.

Приоритет важных страниц

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

Чем поднимают приоритет важных страниц в глазах робота:

• Малой глубиной от главной. Чем ближе страница к главной по числу кликов, тем важнее её считает робот и тем чаще обходит. Ключевые категории и хиты продаж не должны быть «зарыты» глубоко.
• Числом и качеством внутренних ссылок. Страницы, на которые ведёт много внутренних ссылок из значимых мест (меню, блоки на главной, перелинковка), робот считает приоритетными.
• Присутствием в sitemap с приоритетом. В карте эти URL есть, помечены как канонические, с актуальным lastmod и, где уместно, с повышенным priority.
• Свежестью и обновлением. Регулярно обновляемые страницы (новинки, изменения цен и наличия) имеют более высокий спрос на обход — робот возвращается к ним чаще.
• Отсутствием конкуренции с дублями. Когда мусорные копии закрыты, вес и обход не размазываются, а концентрируются на канонической странице.

Обратная сторона приоритизации — не мешать роботу самому. Если важные страницы «тонут» среди сотен тысяч мусорных URL, никакие пометки в sitemap не помогут: робот физически не доберётся до нужного. Поэтому приоритизация работает только в паре с чисткой: сначала убираем мусор, освобождая бюджет, потом сигналами (структура, перелинковка, sitemap) направляем освободившийся ресурс на коммерческие страницы. Это две стороны одной работы — «перестать тратить на ненужное» и «начать тратить на нужное». По отдельности каждая даёт половину эффекта.

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

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

Что делает структуру «дружественной обходу»:

• Логичная вложенность. Раздел → подраздел → товар, без избыточной глубины и без плоской свалки тысяч позиций в одном списке. Каждый товар доступен за небольшое число кликов.
• Отсутствие «сирот». На каждую важную страницу ведёт хотя бы одна внутренняя ссылка. URL без ссылок робот находит плохо и обходит редко — их выявляют и включают в перелинковку.
• Осмысленная перелинковка. Блоки «похожие товары», «с этим покупают», ссылки между связанными категориями и на агрегатные страницы фильтра ведут робота по каталогу и распределяют вес.
• Хлебные крошки. Навигационные цепочки дают роботу дополнительные пути обхода вверх по структуре и укрепляют иерархию.
• Единообразие ссылок. Внутренние ссылки ведут на канонические URL в едином формате (без лишних параметров, слешей, index.php), чтобы сам сайт не плодил дубли.

Особенно важна перелинковка для больших каталогов, где часть товаров неизбежно оказывается на глубине. Продуманные ссылочные связи «поднимают» такие страницы ближе к роботу, не меняя саму структуру разделов: товар может лежать глубоко в дереве категорий, но через блоки перелинковки и агрегатные страницы получать ссылки, которые делают его доступным и приоритетным. Это прямой рычаг управления обходом. Как выстраивать перелинковку и структуру ссылок в магазине на 1С-Битрикс, какие блоки использовать и как не создать при этом новых дублей — подробно в статье про перелинковку и структуру ссылок.

Скорость ответа сервера

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

Что влияет на скорость ответа на 1С-Битрикс и что проверяют:

• Кеширование компонентов и страниц. Составные компоненты и страницы каталога должны отдаваться из кеша, а не собираться заново на каждый запрос. Это главный резерв скорости ответа на платформе.
• Отключённый режим отладки. Включённый в продакшене режим отладки резко замедляет генерацию страниц — частая находка, дающая мгновенный выигрыш при отключении.
• Оптимизированные запросы к базе. Тяжёлые и неоптимизированные выборки, особенно на больших инфоблоках, замедляют ответ. Их выявляют и оптимизируют, добавляют индексы.
• Ресурсы хостинга. Достаточные CPU, память и быстрые диски; для крупного каталога — адекватная конфигурация сервера, а не минимальный тариф.
• Акселератор и сжатие. Настроенный PHP-акселератор, сжатие ответа, HTTP-кеширование статики снижают время и объём отдачи.
• Стабильность (отсутствие 5xx). Всплески серверных ошибок робот воспринимает как перегрузку и снижает частоту обхода — стабильность так же важна, как средняя скорость.

Важная связка: ускорение сервера и чистка мусора работают вместе. Быстрый сервер, который отдаёт роботу тысячи копий, тратит бюджет впустую — просто быстрее. Поэтому оптимизацию скорости всегда сочетают с закрытием мусорных URL. Зато вместе они дают максимальный эффект: робот и успевает больше за визит, и тратит это «больше» на нужное. Ускорение ответа сервера полезно и само по себе — оно улучшает Core Web Vitals и конверсию. Комплексно ускорением магазина на 1С-Битрикс мы занимаемся в рамках отдельной услуги.

Sitemap как подсказка приоритетов

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

Что важно в sitemap с точки зрения обхода:

• Только канонические индексируемые URL. В карту попадают страницы с кодом 200, открытые для индексации, канонические. Мусор, редиректы, 404 и неканонические URL в карте — дезинформация робота.
• Актуальность. Новые товары и категории добавлены, удалённые — убраны. Устаревшая карта отправляет робота на несуществующие страницы, тратя обход.
• lastmod — что обновилось. Корректная дата последнего изменения подсказывает роботу, какие страницы стоит переобойти, а какие не менялись, — прямая экономия бюджета на неизменном контенте.
• Приоритеты и структура. Индексный sitemap со ссылками на отдельные карты (товары, разделы, статьи) с соблюдением лимитов на число URL и размер; где уместно — расстановка приоритетов.
• Автогенерация. Для большого каталога карту генерируют штатными средствами платформы и регулярно обновляют, а не ведут руками.
• Ссылка из robots.txt. Адрес карты указан в robots и добавлен в панелях вебмастеров.

Особенно ценен для бюджета корректный lastmod. На большом каталоге огромная часть страниц между обходами не меняется, и если робот об этом знает, он не тратит на них обход, концентрируясь на новом и изменённом. Неверный lastmod (например, когда дата обновляется у всех страниц при любом пересчёте) обесценивает эту подсказку — робот перестаёт ей доверять. Ещё один диагностический приём: сопоставить число URL в sitemap, число «в поиске» и число реально обходимых по логам. Большие расхождения подсвечивают проблему — либо часть каталога не обходится, либо в обход попадает мусор, которого в карте нет. Настройку и типовые ошибки sitemap на 1С-Битрикс мы разбираем в статье про robots.txt и карту сайта.

Логи веб-сервера и бот

Анализ логов веб-сервера — самый точный инструмент управления бюджетом, потому что он показывает реальную картину обхода, а не предположения. Логи фиксируют каждое обращение робота: какой URL он запросил, когда, каким User-Agent (Яндекс, Google, другие боты), какой код ответа получил. Ни одна панель вебмастеров не даёт такой детализации.

Что находят и решают по логам:

• Распределение обхода по типам URL. Сколько процентов запросов робота уходит на канонические товары и категории, а сколько — на параметры, сортировки и дубли. Это главная метрика утечки бюджета.
• Слепые зоны. Важные страницы, которые робот вообще не посещает, — «сироты» без ссылок, глубоко зарытые URL. Их поднимают в структуре и перелинковке.
• Избыточный обход. Разделы, которые робот дёргает слишком часто без нужды, тратя на них ресурс.
• Всплески ошибок. Рост 404 и 5xx в логах — сигнал проблем, которые и теряют страницы, и снижают лимит обхода.
• Обращения к закрытому. Робот всё ещё ходит к тому, что давно должно быть закрыто, — значит, директивы настроены неверно или не применились.
• Разница между ботами. Яндекс и Google обходят по-разному; полезно смотреть их поведение отдельно и настраивать директивы с учётом обоих.

Практический порядок работы с логами: выгружают лог за репрезентативный период, фильтруют по User-Agent поисковых роботов, группируют запросы по типам URL (товары, категории, параметрические, служебные) и строят распределение обхода. Обычно картина на «непричёсанном» большом магазине показывает, что заметная доля запросов уходит на параметрические и мусорные URL. На основе этого принимают решения: что закрыть в robots, какие параметры отдать в Clean-param, какие страницы поднять в перелинковке, где ускорить ответ. Затем через время повторяют анализ и проверяют, что распределение сместилось в пользу коммерческих страниц. Для небольшого сайта логи можно не трогать, но для большого магазина это ключевой и, по сути, единственный способ увидеть обход глазами робота.

Склейка дублей и индексация фильтра

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

Как склеивают основные каналы дублей:

1. Зеркала и написания. www/без-www, http/https, слеш, регистр, index.php — сводят к единому главному зеркалу и формату через 301-редирект. Это «переехало навсегда» — только редирект, не canonical.
2. Параметры и метки. Сортировки, показ по N, utm-метки, сессии — склеивают через canonical на чистый URL и для Яндекса через Clean-param. Страница остаётся доступной, но не плодит дубли в обходе.
3. Товар в нескольких разделах. Назначают каждому товару один канонический URL, прочие адреса указывают на него через canonical.
4. Мусорные комбинации фильтра. Бесконечный «хвост» бессмысленных пересечений фасетов закрывают от обхода и индексации, чтобы робот на них не тратил бюджет.
5. Полезные комбинации фильтра. Востребованные спросом сочетания превращают в агрегатные посадочные страницы: открывают, дают уникальные метатеги и текст, ставят на них ссылки.
6. Проверка в шаблонах. Убеждаются, что решения применены не точечно, а на уровне шаблонов, — иначе проблема тиражируется на тысячи URL заново.

Ключевое разделение по фильтру — «полезное открываем, мусор закрываем». Именно оно определяет, сколько бюджета уйдёт на фильтр: если открыть всё — робот утонет в комбинациях; если закрыть всё — потеряете трафик по востребованным агрегатным запросам. Тонкая настройка этого баланса на 1С-Битрикс, выбор востребованных комбинаций, генерация для них метатегов и текстов, управление их индексацией — отдельная большая тема, которой посвящена статья про агрегатные страницы фильтра и индексацию. Это, пожалуй, самый результативный участок работы над бюджетом большого магазина.

Мониторинг обхода и индексации

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

Как читать главный сигнал. Когда «загружено роботом» близко к «страниц в поиске», а число нужных страниц растёт вместе с каталогом — обход здоров: почти всё, что робот скачивает, идёт в индекс. Когда «загружено» в разы больше «в поиске» и разрыв увеличивается — тревога: робот тратит обход на страницы, которые система потом отбрасывает как дубли или малоценные. Это и есть утечка бюджета, видимая в цифрах. Дополнительно смотрят долю исключений по типам (много «дубль» — каналы дублей открыты), скорость появления нового в индексе и распределение обхода по логам.

Здоровая картина обхода выглядит так: робот тратит основную массу запросов на канонические товары, категории и полезные агрегатные страницы; мусорные параметры почти не запрашивает; новые и изменённые страницы быстро индексируются; разрыв «загружено / в поиске» невелик и стабилен. Мониторинг — это цикл: измерили, увидели утечку, закрыли канал, проверили, что распределение обхода сместилось в пользу коммерческих страниц. Именно повторяемость этого цикла, а не разовая чистка, и даёт устойчивый результат на растущем каталоге.

План работ по бюджету обхода

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

1. Убедиться, что проблема в бюджете. Проверить базовое: важные страницы не закрыты в robots и noindex по ошибке, «стопы» индексации сняты. Оценить масштаб каталога и признаки нехватки бюджета (разрыв «загружено / в поиске», медленная индексация).
2. Снять картину обхода. Проанализировать логи веб-сервера: на что робот тратит запросы, какова доля мусорных URL, где слепые зоны и всплески ошибок. Сопоставить с данными панелей вебмастеров.
3. Перекрыть утечки. Закрыть служебное и мусорные параметры в robots.txt, прописать Clean-param на сортировки, показ и метки, отключить сессии в URL для роботов, склеить зеркала и написания через 301.
4. Разобраться с фильтром. Разделить комбинации на полезные (агрегатные посадочные — открыть и оптимизировать) и мусорные (закрыть от обхода и индексации). Настроить canonical для полезных дублей.
5. Починить коды и редиректы. Схлопнуть цепочки редиректов в прямые, устранить soft-404 (корректные 404/410 или 301 для отсутствующих товаров), убрать всплески 5xx.
6. Ускорить ответ сервера. Кеширование компонентов и страниц, отключение отладки, оптимизация запросов к базе, ресурсы хостинга, акселератор и сжатие — поднять лимит скорости обхода.
7. Настроить sitemap. Только канонические индексируемые URL, корректный lastmod, автогенерация и обновление, разбивка на карты, ссылка из robots.
8. Направить обход на важное. Чистая структура с малой глубиной, перелинковка на ключевые страницы, устранение «сирот», приоритеты в sitemap.
9. Мониторить и повторять. Через время повторить анализ логов и панелей, убедиться, что распределение обхода сместилось в пользу товаров, а разрыв «загружено / в поиске» сократился. Повторять цикл на растущем каталоге.

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

Частые ошибки

Эти промахи в работе с краулинговым бюджетом встречаются чаще всего — в упущенной индексации и потраченных усилиях:

• Думать о бюджете на маленьком сайте. На каталоге в пару тысяч чистых страниц оптимизировать обход нечего — робот и так всё обходит. Силы тратят не туда, вместо контента и структуры.
• Считать бюджет причиной всех бед. Списывать на «нехватку бюджета» проблемы, которые на деле в закрытых по ошибке страницах, noindex или слабом контенте. Сначала проверяют базовое, потом обход.
• Открытый умный фильтр. Комбинации фасетов и сортировки не закрыты — робот тонет в сотнях тысяч почти одинаковых URL, а товары обходятся по остаточному принципу.
• Надежда только на canonical. Ставят canonical на мусор и ждут экономии обхода, но робот всё равно периодически обходит копии. Мусор нужно ещё и закрывать в robots/Clean-param.
• Путаница robots.txt и noindex. Закрывают страницу в robots, ожидая исключения из индекса, — а робот не доходит до noindex. Или ставят noindex на страницу, закрытую в robots, — тег не считывается.
• Бездумное закрытие пагинации. Канонизируют всю пагинацию на первую страницу или закрывают её — и теряют из обхода товары с глубоких страниц списка.
• Игнор скорости ответа. Медленный сервер снижает лимит обхода, но этим не занимаются; чистят URL, а робот всё равно успевает мало за визит.
• Цепочки и soft-404 без внимания. Многоступенчатые редиректы и пустышки с кодом 200 не находят — робот тратит запросы на промежуточные шаги и индексирует «нет товара».
• Мусор в sitemap. В карту попадают неканонические URL, редиректы, 404 или неверный lastmod — робот получает дезинформацию и тратит обход впустую.
• Работа без логов. Оптимизируют обход вслепую, не глядя на логи, и не знают, на что робот реально тратит бюджет и сместилось ли распределение после правок.
• Разовая чистка без мониторинга. Один раз закрыли мусор и забыли; каталог растёт, появляются новые каналы дублей, а обход снова утекает — потому что процесс не сделали цикличным.
• Метки и сессии в URL. Идентификаторы сессий и рекламные метки не отсекаются — плодят десятки тысяч дублей одной страницы из воздуха.

Чек-лист

Практический список для управления краулинговым бюджетом большого магазина на 1С-Битрикс:

1. Масштаб и необходимость оценены. Подтверждено, что каталог большой и есть признаки нехватки бюджета; базовые «стопы» индексации (robots, noindex по ошибке) проверены и сняты.
2. Картина обхода снята. Логи веб-сервера проанализированы: известно распределение запросов робота по типам URL, доля мусора, слепые зоны и всплески ошибок.
3. robots.txt и Clean-param настроены. Закрыто служебное и мусорные пути; Clean-param прописан на сортировки, показ и метки; sitemap указан; ресурсы отрисовки открыты.
4. Дубли склеены. Зеркала и написания сведены 301 к единому формату; параметры и метки — через canonical и Clean-param; товар в нескольких разделах имеет один канонический URL.
5. Фильтр под контролем. Полезные комбинации открыты как агрегатные страницы, мусорные закрыты от обхода и индексации; пагинация не рубит доступ к товарам.
6. Коды и редиректы в порядке. Цепочки схлопнуты в прямые; soft-404 устранены (корректные 404/410 или 301); всплески 5xx убраны.
7. Сервер ускорен. Кеширование включено, отладка отключена, запросы к базе оптимизированы, хостинг адекватен; ответ быстрый и стабильный, лимит обхода растёт.
8. Sitemap как подсказка. Только канонические индексируемые URL, корректный lastmod, автогенерация и обновление, разбивка на карты, ссылка из robots.
9. Обход направлен на важное. Малая глубина ключевых страниц, перелинковка на приоритетные URL, устранены «сироты», приоритеты в sitemap.
10. Мониторинг налажен. Отслеживается разрыв «загружено / в поиске», скорость индексации нового, распределение обхода по логам; цикл «измерили — закрыли — проверили» повторяется на растущем каталоге.

Вывод

Краулинговый бюджет — это объём ресурсов, который поиск готов потратить на обход вашего сайта, и на большом каталоге в десятки и сотни тысяч URL он становится узким местом: от того, на что робот тратит ограниченные запросы, зависит скорость и полнота индексации. Складывается бюджет из двух составляющих — лимита скорости обхода (насколько быстро и стабильно отвечает сервер) и спроса на обход (насколько поиску интересны и уникальны страницы), — и оба фактора дают рычаги управления. Главная проблема магазинов на 1С-Битрикс в том, что бюджет утекает в мусор: параметры умного фильтра и сортировки, сессии и метки, дубли по слешу и зеркалам, цепочки редиректов, мягкие 404 и бесконечная пагинация. Пока эти каналы открыты, робот тратит обход на копии, а важные товары и категории обходит редко.

Экономят бюджет системно: robots.txt и Clean-param закрывают заведомо бесполезное и склеивают параметры; noindex и canonical убирают дубли из индекса; чистая структура, перелинковка и приоритеты в sitemap с корректным lastmod направляют обход на коммерческие страницы; ускорение ответа сервера поднимает лимит обхода; анализ логов показывает реальную картину и подсвечивает утечки; склейка дублей и грамотная индексация фильтра через агрегатные страницы дают самый крупный эффект. И главное — это не разовая чистка, а цикл «измерили по логам и панелям — закрыли канал утечки — проверили, что распределение обхода сместилось в пользу товаров». Ключевая метрика контроля — сокращающийся разрыв между «загружено роботом» и «страниц в поиске». Именно так робот перестаёт тратить бюджет на мусор и начинает быстро и полно обходить то, что приносит магазину заказы.

Другие разборы по техническому и контентному продвижению магазина на 1С-Битрикс — в рубрике SEO и продвижение: от robots.txt, sitemap и агрегатных страниц фильтра до технического аудита, перелинковки и Core Web Vitals.