Проверка размера страницы: лимит сканирования Google в 2 МБ

Проверка размера страницы отвечает на точный вопрос: прочитает ли Google вашу страницу целиком? Google заявляет, что при сканировании для Поиска Googlebot сканирует первые 2 МБ поддерживаемого типа файла и первые 64 МБ PDF, останавливает загрузку на границе и отправляет на индексацию только уже загруженную часть (Google Search Central, Googlebot). Всё, что находится после этой точки, будь то описание товара, FAQ, ссылки в подвале или блок JSON-LD, для Google Поиска просто не существует.

К чему именно применяется лимит в 2 МБ?

Он применяется к каждому файлу, который загружает Googlebot, по отдельности, и измеряется по несжатым данным. Gzip или Brotli уменьшают передачу, но не меняют подсчёт. У HTML-документа свой бюджет в 2 МБ, а каждый файл CSS или JavaScript, указанный в нём, загружается отдельно с тем же лимитом.

Именно поэтому цифру в 2 МБ часто понимают неправильно. В 2025 году медианная мобильная главная страница весила в сумме 2,6 МБ, но лишь 22 КБ из них приходилось на HTML; изображения и JavaScript составляли большую часть остального (HTTP Archive Web Almanac 2025, вес страницы). Тяжёлая страница не проблема для этого лимита. Проблема тяжёлый HTML-файл.

Значение в 2 МБ относится именно к Google Поиску. Общая документация Google сообщает, что его краулеры и загрузчики по умолчанию читают первые 15 МБ файла и что отдельные продукты могут задавать меньший лимит (Google, обзор краулеров и загрузчиков). Старые статьи, где для Googlebot называют 15 МБ, описывают это значение по умолчанию, а не поискового краулера.

Как пользоваться проверкой размера страницы?

Вставьте полный URL публичной страницы, пройдите проверку от ботов и запустите анализ. Инструмент загружает страницу так, как это делает краулер, следует за редиректами и измеряет HTML в том виде, в котором его отправляет сервер, до выполнения какого-либо JavaScript.

1. Посмотрите на шкалу. Она показывает размер несжатого HTML, лимит Googlebot (2 МБ, или 2097152 байта) и процент, который вы используете, с оставшимся местом.
2. Изучите четыре карточки: размер необработанного HTML, вес встроенных JS и CSS с их долей в HTML, число HTML-тегов и HTTP-статус.
3. Откройте разбивку HTML: встроенные скрипты, встроенные стили, внешние скрипты, внешние таблицы стилей, изображения и комментарии, у каждого свои количество, размер и доля.
4. Посмотрите сведения о сервере: title, метаописание, итоговый URL после редиректов, использованное сжатие и тип сервера.
5. Примените рекомендации, которые появляются только при превышении порога.

Бесплатная версия позволяет три анализа в день. Сначала проверьте самые тяжёлые шаблоны: страница категории с сотнями товаров или длинная статья со встроенными виджетами скажет больше, чем главная страница.

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

Статус зависит только от доли лимита в 2 МБ, занятой несжатым HTML.

Рекомендации используют фиксированные пороги: отмечаются встроенные скрипты свыше 50 КБ, встроенные стили свыше 30 КБ и комментарии свыше 5 КБ, а также сервер, отправляющий HTML без сжатия. Сжатие не уменьшает размер, который считает Google, но сокращает время передачи для краулеров и посетителей.

Что делает HTML-страницу слишком тяжёлой?

Страницы редко достигают 2 МБ из-за текста. Статья на 3000 слов занимает около 20 КБ. Вес создаётся тем, что шаблоны и фреймворки внедряют в документ:

• Сериализованное состояние фреймворка. JavaScript-приложения с серверным рендерингом часто встраивают все данные страницы как объект JSON в тег script, иногда дублируя каждый товар или статью на странице.
• Встроенные SVG-значки, повторяющиеся в каждой карточке списка, и изображения base64, вставленные прямо в HTML.
• Встроенный CSS от конструкторов страниц, которые записывают стили каждого блока в документ.
• Длинные списки: страницы категорий, архивы тегов или страницы внутреннего поиска, выводящие сотни элементов со всеми вариантами.
• Чрезмерно большие структурированные данные, например блок Product, перечисляющий все варианты с полными описаниями.
• Комментарии и отладочная разметка, оставленные в рабочей версии.

Разбивка в инструменте показывает, что из этого преобладает. Если встроенные скрипты занимают 70% HTML, начните с них; если число тегов исчисляется десятками тысяч, проблема в шаблоне или размере списка.

Как уменьшить размер HTML, не потеряв контент?

Работайте от самого большого блока вниз и держите то, что нужно Google, ближе к началу документа.

1. Вынесите встроенные JavaScript и CSS во внешние файлы. У них будет собственный бюджет в 2 МБ, и браузеры смогут их кешировать.
2. Сократите сериализованное состояние: отправляйте только поля, нужные странице, а не весь ответ API.
3. Замените повторяющиеся встроенные SVG внешним спрайтом или файлами изображений, а изображения base64 обычными URL изображений. Компрессор изображений сохраняет эти файлы лёгкими.
4. Разбейте длинные списки на страницы или подгружайте остальные элементы по запросу, сохраняя доступность каждого URL с пагинацией для сканирования через ссылки.
5. Размещайте важный контент раньше: основной текст, внутренние ссылки и структурированные данные не должны находиться после мегабайтов скриптов. Генератор Schema создаёт компактный JSON-LD.
6. Минифицируйте HTML и удаляйте комментарии в рабочей версии.

После каждого изменения запускайте проверку снова и подтверждайте в Search Console. Инструмент проверки URL показывает HTML, который Google реально загрузил, через «Просмотр просканированной страницы» (Справка Search Console, инструмент проверки URL), что позволяет убедиться, что конец вашей страницы на месте.

Каковы ограничения этой проверки?

Инструмент измеряет один URL, один раз, в том виде, в котором он отдаётся краулеру. Учитывайте три момента.

• Нет рендеринга JavaScript. Инструмент измеряет HTML, который возвращает сервер. Контент, добавленный позже через JavaScript, здесь не учитывается, а Google индексирует только ту часть HTML, которую загрузил в пределах лимита.
• Один user agent. Если ваш сервер отправляет разный HTML Googlebot, мобильным устройствам или авторизованным пользователям, размер может отличаться.
• Одна страница за раз. Проблема шаблона затрагивает каждую страницу, построенную на нём, поэтому проверяйте по одному URL на шаблон, а затем проведите аудит всего сайта с помощью аудита внутренней SEO-оптимизации.

Важен ли размер страницы для ИИ-краулеров?

Да, и часто даже больше. Web Almanac отмечает, что ключевая информация должна присутствовать в исходном необработанном HTML, потому что ИИ-краулеры не выполняют JavaScript. Лёгкий HTML-файл с основным контентом ближе к началу служит и Google, и ИИ-ассистентам. Аудит сканируемости для ИИ проверяет, могут ли ИИ-боты получить доступ к вашим страницам и прочитать их, а краулинговый бюджет объясняет, почему более лёгкие страницы сканируются и эффективнее.

Чтобы следить за этим со временем, дашборд GEO и SEO показывает страницы, у которых падают клики из Google, что часто становится первым признаком проблемы с индексацией, а SEO Chat может проверить страницу и простыми словами объяснить, как исправить.

Держите каждый HTML-файл заметно ниже 2 МБ, с важным контентом в начале. Проверьте свои самые тяжёлые шаблоны выше, а затем ознакомьтесь с тарифами Sorank, чтобы следить за видимостью в Google и ИИ на autopilot.