Google раскрыл подробности работы своего экосистемы краулеров: какие объёмы данных Googlebot загружает, как система обрабатывает «обрезанные» файлы и какие практики помогут избежать потерь критичного контента. Информацию озвучил Gary Illyes и сопроводил публикацией в блоге разработчиков Google под заголовком «Inside Googlebot: demystifying crawling, fetching, and the bytes we process».
Основные детали новости
Google перестал рассматривать Googlebot как один единый паук: сейчас у компании несколько краулеров под разные задачи, у каждого — свой user-agent и часто свои лимиты. Важные технические ограничения, которые теперь подтверждены напрямую, такие:
- По умолчанию Googlebot загружает до 2 МБ для одного URL (PDF-файлы исключаются).
- Предел в 2 МБ учитывает не только тело ответа, но и HTTP-заголовки.
- Для PDF предел значительно выше — 64 МБ.
- Краулеры изображений и видео имеют более гибкие пороговые значения, зависящие от продукта, для которого выполняется обход.
- Если у конкретного краулера не задан явный лимит, применяется значение по умолчанию — 15 МБ вне зависимости от типа контента.
Что происходит при обходе URL с большим размером страницы:
- Если HTML-документ превышает 2 МБ, Googlebot не отбрасывает такой URL: загрузка просто останавливается на границе 2 МБ и передаётся дальше.
- Скачанная часть (первые 2 МБ байт) передаётся в систему индексирования и в Web Rendering Service (WRS) как будто это полный файл.
- Оставшиеся байты после порога игнорируются: не скачиваются, не рендерятся и не индексируются.
- Ресурсы, перечисленные в HTML (за исключением медиаконтента, шрифтов и некоторых редких типов файлов), загружаются WRS отдельно — у каждого URL свой счётчик байт. Размер родительской страницы в это не засчитывается.
Дополнительные факты
Web Rendering Service Google запускает JavaScript и выполняет клиентский код так же, как современный браузер, чтобы получить итоговое визуальное и текстовое состояние страницы. WRS подтягивает и выполняет JS и CSS, обрабатывает XHR-запросы для корректного понимания текстовой структуры и контента страницы. При этом WRS не запрашивает изображения и видео. Для каждого запрошенного ресурса также действует лимит в 2 МБ.
Google указывает на существование документации со списком разных краулеров и их user-agent, что полезно проверять при диагностике логов и настройке серверов. Кроме текстового материала, Google выпустил подкаст, где дополнительно обсуждаются тонкости работы краулеров и нюансы обработки байтов.
Почему это важно для SEO
Из первых рук стало ясно: если ключевые метаданные, канонические теги или важные элементы структурированных данных попадают за предел 2 МБ, их просто не увидят WRS и индексирующие системы. Практические выводы для оптимизаторов:
- Сократите размер начального HTML. Переносите тяжёлые CSS и JavaScript в внешние файлы — они будут загружаться отдельно и имеют собственные лимиты.
- Важная информация должна располагаться как можно выше в HTML-документе: метатеги, канонические ссылки, критичные блоки структурированных данных и контент, который должен быть проиндексирован без зависимости от клиентского рендеринга.
- Следите за логами сервера: замедление ответа приводит к снижению частоты обхода — fetchers автоматически «отступают», чтобы не перегружать инфраструктуру.
- Проверяйте, какие именно краулеры посещают сайт, и учитывайте их лимиты: изображения и видео могут обходиться иначе, чем HTML-страницы и PDF.
Для SEO-специалистов эти уточнения — не просто техническая деталь. Понимание того, какие именно байты и в каком объёме доходят до индексатора и рендерера, позволяет точнее спроектировать загрузку контента и минимизировать риск того, что важные данные останутся невидимыми для Google.
Изменения и пояснения от Google полезно учитывать при аудитах производительности и структурирования страниц: простые шаги по оптимизации порядка загрузки и сокращению начального HTML могут значительно повысить шансы на корректное индексирование и отображение в поиске.
