Бюджет сканирования относится к темам SEO, которые легко чрезмерно усложнить.

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

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

В июле 2026 года Google обновил документацию по бюджету сканирования, добавив подробности об общих ресурсах роботов, hostload и условных запросах с 304 Not Modified.

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

Полезный вопрос в том, испытывает ли Google трудности с обнаружением или обновлением действительно важных страниц.

Кому стоит заниматься бюджетом сканирования?

Расширенные рекомендации Google по бюджету сканирования рассчитаны прежде всего на крупные или быстро меняющиеся сайты.

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

У сайта с несколькими сотнями стабильных страниц обычно есть более важные SEO-задачи.

Сначала определите, существует ли проблема.

Возможности и потребность в сканировании отличаются

На сканирование Google влияют и возможности, и потребность.

Возможности определяются тем, какой объём сканирования хост способен нормально выдержать.

Потребность определяется тем, сколько Google хочет или должен сканировать.

Увеличение мощности сервера не гарантирует, что Google станет чаще сканировать каждый URL.

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

Что означает hostload?

Google теперь использует термин hostload в рекомендациях по сканированию.

На практике Google старается не создавать чрезмерную нагрузку на сервер.

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

Если Googlebot регулярно сталкивается с:

  • ошибками сервера 5xx
  • ответами HTTP 429
  • медленными соединениями
  • истечением времени ожидания

характер сканирования может измениться.

Поэтому SEO-команде и команде инфраструктуры следует совместно оценивать состояние сервера.

Ресурсы сканирования могут делиться между роботами Google

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

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

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

Журналы сервера помогают увидеть реальную картину.

Почему Google рекомендует ответы 304

Когда у Google уже есть копия ресурса и он хочет узнать, изменился ли тот, условные HTTP-запросы могут сократить ненужную передачу данных.

Запрос может содержать валидаторы, например:

If-Modified-Since

или:

If-None-Match

Если контент не изменился, правильно настроенный сервер может вернуть:

304 Not Modified

без повторной отправки всего тела страницы.

Это экономит пропускную способность и вычисления.

Это не означает, что страница была перенаправлена.

Ответ 304 не является обычным перенаправлением

Это частый источник путаницы.

Код 304 входит в семейство HTTP 3xx.

Он не работает как перенаправление 301 или 302.

Он сообщает клиенту, что ранее сохранённое представление всё ещё можно использовать.

Не стройте логику перенаправлений вокруг 304.

ETag и Last-Modified

Два распространённых валидатора:

ETag

и:

Last-Modified

Важно, чтобы они правильно отражали состояние контента.

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

Валидатор, который постоянно меняется при неизменном контенте, лишает механизм значительной части эффективности.

Проверяйте фактическую реализацию.

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

Техническая команда может проверить поведение запросами из командной строки.

Сначала запросите URL и изучите заголовки ответа.

Запишите значение ETag или Last-Modified.

Затем отправьте условный запрос с соответствующим заголовком.

Если страница не изменилась, ожидаемым результатом может быть 304.

Затем измените контент и проверьте снова.

Сервер должен корректно вернуть актуальный контент.

Проводите проверку через те же CDN и инфраструктуру, к которым обычно обращается Google.

Проверка только исходного сервера может пропустить проблему на периферийном уровне.

Изучите журналы

Полезные поля журналов включают:

  • временную метку
  • URL
  • user agent
  • код состояния
  • размер ответа
  • время ответа
  • метод запроса

Анализ журналов может выявить:

  • множество бесполезных URL с параметрами
  • повторяющиеся перенаправления
  • медленные шаблоны
  • группы ошибок 5xx
  • сканирование страниц с 404
  • важные разделы с низкой активностью

Закономерности важнее одного запроса.

Статистика сканирования Search Console добавляет контекст

Search Console помогает определить:

  • коды ответов
  • типы файлов
  • проблемы хоста
  • активность сканирования
  • динамику времени ответа

Используйте её вместе с журналами сервера.

Search Console даёт обзор со стороны Google.

Журналы показывают, что достигло вашей инфраструктуры.

Устраните лишние URL прежде сложного кеширования

Сайт может идеально реализовать условные запросы и всё равно тратить огромный объём сканирования на плохие URL.

Проверьте:

  • дублирующие параметры
  • фасетную навигацию
  • бесконечные страницы календаря
  • страницы внутреннего поиска
  • цепочки перенаправлений
  • soft 404
  • устаревшие URL
  • дублирующийся контент
  • неработающую пагинацию

Эффективность сканирования начинается с разумного набора URL.

Не обещайте роста позиций от 304

Правильная реализация 304 может экономить ресурсы.

Это не делает её фактором ранжирования.

Это не означает, что каждую страницу внезапно станут сканировать чаще.

Цель состоит в технической эффективности.

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