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

Происхождение и история термина

16 января 2017 года Google опубликовал разъяснение Гэри Иллиша о краулинговом бюджете. Автор отвечал на уже существовавшие разные трактовки термина: объединял ограничение скорости обхода и потребность в обновлении данных. Поэтому дату публикации нельзя считать рождением понятия. Главный смысл объяснения — робот должен выбирать, что обходить, не перегружая сервер владельца. ^[2]

В современном руководстве Google ограничение описано точнее: учитывается суммарное время открытых соединений с сервером, включая их количество и длительность. Связь возможностей и потребности сохранилась. ^[1] Для владельца сайта это объясняет, почему одной покупки более производительного сервера недостаточно для решения всех задержек обхода.

Суть и механизм

Возможность обхода отвечает на вопрос: выдерживает ли сайт обращения робота? В справке Search Console сказано, что замедление ответов и рост серверных ошибок могут заставить Googlebot снизить активность. Потребность в обходе отвечает на другой вопрос: насколько часто роботу нужно возвращаться за содержанием? Редко меняющиеся страницы могут посещаться реже. ^[3]

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

После сканирования Google отдельно оценивает пригодность страницы для индекса. ^[1] Поэтому вопрос «почему материал не находится в поиске?» сначала стоит разделить на два: получил ли его робот и что произошло после получения.

Какие ситуации различать

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

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

Как применяется на практике

Ещё в 2017 году Google объяснял: когда новые страницы обходятся в день публикации, сосредоточиваться на бюджете обычно не нужно. ^[2] Для небольшого издания разумнее начать с конкретной задержавшейся новости, чем пытаться повысить общий счётчик любой ценой.

Справка Яндекса советует перед изменением скорости изучить серверные журналы и адреса в статистике обхода. ^[4] Для редакции это означает совместную работу: редактор показывает опоздавшие публикации, технический специалист выясняет, какие запросы сервер получил. Общая жалоба «поиск нас не любит» превращается в проверяемую задачу по конкретным материалам.

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

В журнале сервера, или логе, записываются обращения к сайту. Прежде чем выбирать записи Googlebot, нужно проверить происхождение запросов. Google предлагает сверять адрес отправителя с опубликованными диапазонами IP либо проверять обратное и прямое разрешение имени через DNS — систему соответствия имён и сетевых адресов. Одного заявления отправителя о принадлежности к Google недостаточно. ^[6]

Учебный пример: за сутки в выбранном журнале найдено 1000 подтверждённых запросов робота. Из них 700 пришлись на страницы материалов, 200 — на варианты сортировки списков, 100 получили ответ с перенаправлением. Категории здесь заранее определены как непересекающиеся. Для описания этой выборки посчитаем долю обращений к материалам:

Доля = запросы к материалам / все запросы выборки × 100 %.

Получается 700 / 1000 × 100 = 70 %. Числитель и знаменатель относятся к одному роботу, сайту и периоду. Это доля запросов, а не доля уникальных страниц и не оценка качества сайта. Допустим, 700 обращений пришлись на 500 разных материалов: некоторые адреса робот запрашивал повторно. Нельзя записать в отчёт «проиндексировано 700 статей».

Оставшиеся 300 обращений также нельзя автоматически объявить потерями: в нашем примере перенаправление может вести со старого адреса на действующий материал. Сначала нужно рассмотреть назначения переходов и содержание вариантов сортировки. Доля 70 % — результат условной выборки, а не рекомендуемый норматив.

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

Отчёт Crawl Stats в Search Console показывает запросы, включая повторы и отдельные звенья серверных перенаправлений. Его итоги могут отличаться от логов: часть запросов не учитывается, а при недоступности robots.txt в счётчик могут попасть предполагавшиеся, но не выполненные обращения. Примеры адресов в отчёте также не являются полным перечнем. ^[3]

Ошибки и ограничения

noindex запрещает включать страницу в индекс, но Google всё равно должен запросить её, чтобы увидеть указание. Поэтому это не средство экономии обхода. ^[7]

Сам файл robots.txt содержит правила для роботов. Он не заменяет защиту закрытых материалов: RFC 9309 прямо отделяет протокол от авторизации доступа. Более того, перечисленные в файле пути становятся публично видимыми. ^[5] Например, неопубликованный платный материал следует защищать средствами доступа, а не рассчитывать на скрытность строки с его адресом.

Наконец, увеличение частоты обхода не следует превращать в обещание роста позиций. В разъяснении Google 2017 года обход отделён от сигналов ранжирования. ^[2] В рабочем отчёте полезнее показать, сократилось ли ожидание важных публикаций, чем объявлять любое увеличение числа запросов успехом.

Частые вопросы

Связанные термины

• skanirovanie
• indeksatsiya
• robots-txt
• karta-sayta
• paginatsiya
• tsepochka redirektov