Краулинговый бюджет: когда его нужно оптимизировать и что проверять на большом сайте
Большой каталог ежедневно обновляет цены, наличие и карточки товаров, а Google продолжает запрашивать множество старых адресов и похожих вариантов страниц. Возникает вопрос: хватает ли сайту ресурсов обхода и можно ли направить внимание робота на важные изменения? Ответ требует проверки состава URL, доступности сервера и фактической задержки повторного обхода.
Краулинговый бюджет полезно рассматривать как ограничение, которое нужно подтвердить данными. Большое количество запросов Googlebot само по себе не является ни успехом, ни неисправностью. Цель оптимизации обхода сайта — обеспечить обнаружение и получение нужного содержимого без лишней нагрузки. Это не обещание, что каждая полученная страница попадёт в индекс или поднимется в поиске.
Когда вопрос бюджета действительно стоит исследовать
В руководстве Google по crawl budget приведены ориентиры: сайты примерно с миллионом уникальных страниц при еженедельных изменениях или от десяти тысяч страниц с ежедневными обновлениями. Это приблизительные масштабы, а не жёсткие пороги. Ещё один повод для исследования — значительная доля обнаруженных, но не проиндексированных URL.
Сам такой статус не доказывает нехватку бюджета. Сначала выясните, действительно ли нужные адреса давно не посещались, доступны ли они и содержат ли самостоятельную ценность. У каталога может быть десять тысяч полезных карточек и гораздо больше технических вариантов адресов; считать их одним числом неправильно.
Для небольшого сайта, где важные новые страницы регулярно обнаруживаются, отдельная программа «увеличения бюджета» часто не нужна. Полезнее исправить конкретные запреты, ошибки ответов или слабую структуру. Размер сайта не освобождает от этих проверок, но помогает выбрать глубину анализа.
Сформулируйте симптом измеримо: «обновлённые карточки определённой категории долго не получают повторного запроса». Фраза «Google мало ходит» без перечня страниц, времени обновления и наблюдений не позволяет определить, что именно требуется улучшить.
Разделите возможность обхода и потребность в нём
Google различает crawl capacity limit — допустимую нагрузку при обращениях к хосту — и crawl demand, потребность в обходе. На потребность влияют известный набор URL, обновления, популярность и ценность содержимого. Быстрый сервер не создаёт автоматически интерес к каждой странице. В текущем описании Google бюджет относится к отдельному имени хоста.
Для диагностики это два разных вопроса. Первый: может ли приложение устойчиво обслуживать запросы робота одновременно с посетителями? Второй: какие документы робот видит как доступные кандидаты и почему важные изменения должны быть заметны через структуру сайта?
Если сервер перегружен, исправление дублей без устранения задержек может оставить ограничение мощности. Если сервер свободен, покупка дополнительных ресурсов не гарантирует более частого обхода. Проверяйте обе гипотезы отдельно, не делая вывод только по загрузке процессора или общему числу посещений робота.
Также различайте запрос к URL и индексирование его содержимого. Лог подтверждает получение запроса и выданный ответ. Решение поисковой системы о включении страницы, выборе канонического адреса и представлении в выдаче относится к следующему этапу. Эти результаты сопоставляют, но не подменяют друг другом.
Составьте реестр групп URL
Начните с групп, для которых можно описать назначение, объём и частоту существенных изменений. Реестр строят из данных приложения, карты сайта, внутренней навигации и журналов обращений. Один обход сканером показывает только то, что он смог обнаружить выбранным способом.
| Группа | Вопрос для команды | Что сопоставить |
|---|---|---|
| Действующие карточки товаров | Какие изменения требуют свежего обхода | Публикации, обновления, последние запросы |
| Категории и содержательные подборки | Есть ли самостоятельная пользовательская задача | Содержимое, ссылки, доступность |
| Варианты одинакового содержимого | Зачем существуют дополнительные адреса | Параметры, canonical, источники ссылок |
| Старые и удалённые адреса | Есть ли равнозначная замена | Фактический статус и цепочка переходов |
| Служебные страницы и ресурсы | Нужны ли они для понимания каталога | Назначение и правила доступа |
У каждой строки реестра должен появиться владелец решения. Разработчик объясняет происхождение адресов, владелец каталога — назначение страниц, SEO-специалист — желаемое участие в поиске. Без такого разделения параметр легко объявить мусором, хотя он открывает самостоятельный раздел.
Не объединяйте адреса слишком агрессивно при анализе. Удаление всех параметров из журнала скроет различия между полезной страницей и дублем. Сохраните исходный URL, выделите нормализованную группу и документируйте правило классификации. Неизвестные варианты оставляйте отдельной категорией до проверки.
Добавьте к реестру несколько характерных примеров каждой группы и ожидаемое поведение ответа. Это позволит проверить правило на реальных различиях: один параметр меняет содержимое, другой только отмечает источник перехода. Полезно считать как количество известных адресов, так и число адресов, реально запрошенных за период. Большой теоретический набор, который не создаётся в ссылках и не встречается в наблюдениях, не следует автоматически объявлять главным потребителем обхода.
Убедитесь, что измеряете нужного робота
Если Googlebot делает много запросов, сначала подтвердите их происхождение. Одного текста User-Agent недостаточно. Официальная проверка запросов Google предусматривает сопоставление адресов с опубликованными IP-диапазонами либо проверку DNS в обе стороны. Для регулярного анализа большого журнала удобна автоматизированная классификация по актуальным данным.
Разделяйте обычный поисковый обход, другие роботы Google и обращения инструментов, запущенных пользователем. Иначе активная проверка сайта сотрудниками может выглядеть как изменение поведения поискового робота. Для каждого сравнения закрепите одинаковое правило отбора.
Минимальный набор наблюдений: время с часовым поясом, хост, URL, тип запроса, статус, длительность ответа, размер и группа страницы. Если используется CDN, определите точку измерения. Запрос, обслуженный кешем, может отсутствовать в журнале приложения; отсутствие такой записи не доказывает отсутствия обхода.
Проверьте полноту периода и разрывы сбора. Потеря части журналов способна создать видимость резкого падения нагрузки. В итоговом отчёте укажите границы данных и известные ограничения: какие узлы включены, какие ответы не видны и какие группы пока не классифицированы.
Проверьте, чем ограничена отдача страниц
Сопоставьте всплески обращений с задержками, ошибками и нагрузкой на пользовательские операции. Смотрите время ответа нужных маршрутов, очередь обработчиков, обращения к базе и состояние кеша. Быстрая главная страница не подтверждает, что тяжёлые карточки или категории выдерживают обход.
Google в рекомендациях по проблемам обхода отмечает: улучшение доступности само по себе не обязательно увеличивает бюджет. Значение имеют также скорость получения и рендеринга содержимого. Ускорение малоценной страницы не гарантирует дополнительных запросов к ней.
В практическом плане сначала устраняют подтверждённую причину: дорогой запрос категории, очередь на приложении, ошибку кеширования или ограничение на промежуточном узле. Измерьте, улучшился ли ответ после изменения, прежде чем связывать последующее поведение робота с этой работой.
Не разрешайте любой поток обращений только по строке Googlebot и не отключайте общие защитные ограничения без оценки мощности. При реальной перегрузке требуется согласованное действие команды эксплуатации. Для оценки полезны одновременно два результата: сервер стабильно отвечает роботу, а обслуживание обычных посетителей не ухудшается.
Уменьшайте лишние адреса у источника
Если одна карточка доступна по многим адресам, выясните, что создаёт варианты: внутренние ссылки, параметры, старые маршруты или ошибки шаблона. Исправление генератора адресов обычно понятнее, чем бесконечное добавление исключений для каждого нового сочетания.
Документация Google по канонизации описывает согласованные сигналы для дублей: canonical, перенаправления и включение предпочтительных адресов в sitemap. Внутренние ссылки следует направлять на выбранный вариант. Canonical сообщает предпочтение, но не является запретом обращения к остальным URL.
На тестовой выборке подтвердите, что страницы действительно эквивалентны. Разные товары, полезные подборки и самостоятельные части каталога нельзя объединять только ради меньшего числа адресов. Ошибка такого объединения способна скрыть нужное содержимое.
Отдельно сократите внутренние ссылки через устаревшие цепочки перенаправлений: пусть навигация сразу ведёт к действующему адресу. Сами необходимые переходы для старых ссылок сохраняют согласно назначению. После исправления повторно проверьте, перестал ли сайт производить новые дубли, и только затем оценивайте изменения обхода уже известных вариантов.
Выбирайте robots.txt и noindex по задаче
Robots.txt управляет доступом поддерживающего правила робота к адресам. Он не гарантирует удаления известного URL из поиска: адрес может быть показан без получения содержимого. Это также не средство защиты приватных данных.
Noindex относится к индексированию. Чтобы обработать инструкцию, Google должен получить страницу или соответствующий заголовок. Поэтому массовая установка noindex не является способом сэкономить обход. Если одновременно закрыть URL в robots.txt, робот не сможет прочитать находящуюся на странице инструкцию.
Для каждой группы запишите цель: не обращаться к ненужному пространству адресов, исключить документ из поиска или объединить дубли. Это разные решения. Перед широким запретом проверьте выборку URL, включая исключения и ресурсы, необходимые для отображения страниц.
Не чередуйте запреты по расписанию в расчёте автоматически перенаправлять освободившиеся запросы в другую категорию. Нужен устойчивый договор о том, какие адреса вообще предназначены для обхода. Сокращение ненужного пространства полезно, но конкретное распределение оставшихся обращений остаётся решением систем Google.
Не используйте HTTP-ошибки как постоянную SEO-настройку
Статус ответа должен соответствовать реальному состоянию ресурса. По документации Google об HTTP-статусах, 429 и серверные ошибки могут замедлять обход, а длительная недоступность создаёт риск потери URL из индекса. Удалённый документ и временно перегруженный сервер требуют разных ответов.
| Ситуация | Корректное направление решения | Ошибочное обобщение |
|---|---|---|
| Страница окончательно удалена без замены | 404 или 410 и удаление устаревших внутренних ссылок | Любая 404 ухудшает весь сайт |
| Есть равнозначный новый адрес | Осмысленное перенаправление к нему | Все старые URL нужно отправить на главную |
| Временная перегрузка | Временные 429/503 по плану эксплуатации и устранение причины | Ошибками можно постоянно управлять приоритетом обхода |
| Пустой шаблон вместо отсутствующей страницы | Исправить содержимое или статус по фактическому состоянию | Код 200 всегда означает полезный успешный ответ |
Не превращайте временную ошибку базы в подтверждение удаления товара. И наоборот, не выдавайте пустую страницу 200 для каждого произвольного адреса. В обоих случаях поисковая система получает неточное описание состояния сайта.
В отчёте отделяйте ожидаемые ответы удалённых URL от неожиданных ошибок действующего каталога. Снижение всех 404 до нуля не является самостоятельной целью: важнее правильная семантика и отсутствие сломанных путей к актуальным страницам.
Сообщайте о значимых изменениях согласованно
Важные страницы должны находиться через действующую навигацию и попадать в актуальный список адресов. Проверьте, что новый товар не существует только в административной системе, а обновлённая карточка не скрыта за устаревшей ссылкой или ошибочным запретом.
В правилах создания sitemap Google указывает, что учитывает достоверный lastmod, отражающий существенное изменение страницы. Значения priority и changefreq Google игнорирует. Отправка карты сайта остаётся подсказкой, а не требованием немедленно получить перечисленные URL.
Не обновляйте дату всех карточек при каждой сборке, если содержимое осталось прежним. Определите события, которые меняют дату в вашей системе, и проверьте несколько примеров по журналу публикаций. Редакционное изменение, обновление товара и техническое пересоздание кеша могут быть разными событиями.
Для большого каталога удобно отдельно учитывать новые страницы и изменённые существующие. У первой группы измеряется обнаружение и первый запрос, у второй — повторный запрос после изменения. Если смешать их, невозможно понять, помогает ли исправление навигации или проблема остаётся в получении обновлений.
Посчитайте распределение запросов на учебном примере
Предположим, сравниваются два периода одинаковой продолжительности. Учитываются только подтверждённые запросы выбранного поискового робота к документам одного хоста; изображения, скрипты и обращения проверочных инструментов исключены. Все числа ниже вымышлены и показывают способ расчёта.
| Группа документов | До изменения | После изменения |
|---|---|---|
| Приоритетные новые и обновляемые страницы | 40 000 | 54 000 |
| Прочие действующие основные страницы | 20 000 | 18 000 |
| Подтверждённые дубли с параметрами | 30 000 | 9 000 |
| Старые адреса и переходы | 10 000 | 9 000 |
| Всего запросов | 100 000 | 90 000 |
Доля приоритетной группы выросла с 40 000 / 100 000 = 40% до 54 000 / 90 000 = 60%. Разница составляет 20 процентных пунктов. Всего запросов стало на 10% меньше, но к приоритетной группе их стало на 14 000 больше.
Это полезное наблюдение о распределении, а не доказательство полноты. Десятки тысяч обращений могут повторно получать небольшое число адресов. Дополнительно посчитайте уникальные URL каждой группы, статусы и фактическое получение обновлённого содержимого.
Само название «приоритетный» задаёт команда для анализа, а не передаёт поисковой системе команду. Приоритет обосновывается задачами каталога и потребностью пользователей; высокая маржинальность товара сама по себе не устанавливает частоту обхода Google.
Измеряйте задержку относительно публикации
Для обновлённой карточки зафиксируйте момент, когда новая версия стала доступна посетителям, и первый последующий успешный запрос нужного робота. Учебный пример: публикация в 10:00 UTC, получение новой версии в 16:30 UTC. Наблюдаемая задержка составляет 6 часов 30 минут. Время начала импорта не заменяет момент фактической публикации.
Чтобы сравнить группы, заранее задайте окно наблюдения. Допустим, до исправления из 1000 обновлённых страниц за первые 24 часа были успешно получены 600, после — 800 из другой сопоставимой тысячи. Доли составляют 60% и 80%. Это условный внутренний показатель, а не норматив Google.
Для каждой страницы должны пройти полные 24 часа наблюдения. Страницы, опубликованные час назад, нельзя автоматически записывать в неуспех за сутки. Запрос без нужной версии, серверная ошибка и отсутствие обращения — разные результаты, которые следует различать.
Обычная строка access log со статусом 200 не всегда показывает, какую версию содержимого получил робот. Если этот вопрос важен для измерения, команда связывает ответ с внутренней версией публикации или другим проверяемым признаком, учитывая кеширование. Не называйте любой запрос после обновления подтверждением свежести, если промежуточный слой мог вернуть прежний документ. Метод проверки версии должен быть одинаковым в обоих сравниваемых периодах.
Если рассчитываете медиану задержки только по уже посещённым URL, укажите это ограничение: самые медленные ещё не наблюдались и не попали в расчёт. Рядом показывайте долю оставшихся без успешного запроса. Получение страницы также не подтверждает, что новая версия уже отражена в выдаче.
Проведите сравнение до и после без поспешных выводов
Выберите одно понятное изменение или небольшой связанный набор: исправление генерации дублей, устранение тяжёлого маршрута, актуализацию ссылок. Запишите дату внедрения, затронутые группы и ожидаемый механизм улучшения. Сравнивайте периоды с похожей публикационной активностью, составом каталога и правилами сбора данных.
- Проверить, перестали ли появляться лишние адреса.
- Сопоставить число запросов и уникальных URL по группам.
- Оценить ошибки и время ответа действующих страниц.
- Сравнить долю обновлений, полученных в выбранное окно.
- Проверить, не закрыты ли нужные документы и ресурсы.
- Отделить технический результат от изменений индексирования и поискового трафика.
Рост обхода после релиза ещё не доказывает причинную связь: одновременно могла измениться частота публикаций, популярность раздела или нагрузка других роботов. Если возможно, оставьте сопоставимую незатронутую группу для сравнения. Итогом должен быть подтверждённый технический эффект и перечень оставшихся неопределённостей.
Для каждого изменения назначьте владельца и критерий завершения. Например, разработчик подтверждает прекращение генерации конкретного дубля, специалист эксплуатации — устойчивые ответы при сопоставимой нагрузке, а аналитик — корректность выборки обновлений. Если улучшилась только доля приоритетных запросов, но задержка получения новых версий не изменилась, это промежуточный результат. Он помогает выбрать следующую гипотезу, а не закрывает задачу автоматически.
Для внешнего контроля HTTP-доступности важных страниц подключите SiteGuard. Распределение обхода, журналы Googlebot и свежесть получения обновлений команда анализирует отдельно; доступный сервер остаётся необходимой частью этой работы.