Проблемы индексации JS-контента: бюджет рендеринга Google
Ключевые факты
- 1 Google разделяет краулинг и рендеринг, что приводит к задержкам индексации JS-контента.
- 2 Бюджет рендеринга — это ресурс, определяющий объем выполнения JavaScript Googlebot.
- 3 Диагностика проблем проводится через URL Inspection и отчет Page Indexing в GSC.
- 4 Тяжелые JS-бандлы, сторонние скрипты, некорректная ленивая загрузка и бесконечный скролл расходуют бюджет рендеринга.
- 5 Основные решения включают Server-Side Rendering (SSR) и оптимизацию JS-пейлоада.
- 6 Для бесконечного скролла необходимо предоставлять резервные URL пагинации.
- 7 Пререндеринг допустим, если контент совпадает с тем, что видят пользователи.
Google обрабатывает веб-страницы в два этапа: сначала происходит быстрый краулинг HTML, а затем, при необходимости, рендеринг JavaScript. Выполнение JS требует значительных вычислительных ресурсов, поэтому страницы с тяжелым JS попадают в очередь на рендеринг, что может занимать от нескольких часов до нескольких дней. Это объясняет, почему обновленный контент на таких страницах долго не появляется в поисковой выдаче. Существует отдельный ресурс, называемый бюджетом рендеринга, который определяет, на скольких страницах Google выполнит JavaScript. Проблемы с этим бюджетом можно диагностировать в Google Search Console (GSC) с помощью инструмента URL Inspection, сравнивая даты 'Last crawl' и 'Last crawl rendered'. Большой разрыв между этими датами указывает на задержку рендеринга. Также полезно проверить отчет Page Indexing, отфильтровав по 'Crawled, currently not indexed', чтобы выявить JS-урлы, ожидающие рендеринга. Основные факторы, быстро расходующие бюджет рендеринга, включают: JS-бандлы тяжелее 1 МБ, многочисленные сторонние скрипты (GA4, Hotjar, Intercom, Optimizely, GTM с множеством тегов), некорректно работающая ленивая загрузка и бесконечный скролл. Googlebot не прокручивает страницу, индексируя только контент в начальном вьюпорте, поэтому контент, подгружаемый при скролле, остается невидимым. Базовое решение — перенос критически важного контента, заголовков и метаданных на Server-Side Rendering (SSR) с использованием таких фреймворков, как Next.js (getServerSideProps, getStaticProps) или Nuxt (режим SSR, nuxt generate). Для сайтов без фреймворков рекомендуется отдавать полный HTML-ответ, а не пустую оболочку. После внедрения изменений необходимо проверять отрендеренный HTML в URL Inspection. Дополнительные меры оптимизации включают сокращение размера JS-пейлоада до менее 200 КБ для контента первого экрана, анализ и очистку раздутых пакетов (webpack-bundle-analyzer, source-map-explorer), tree-shaking, разбиение бандлов по роутам, отложенную загрузку некритичных скриптов и запуск сторонних тегов по событию Window Loaded. Важно не применять ленивую загрузку к hero-изображениям (используя fetchpriority="high"), основному тексту, заголовкам или навигации. Для бесконечного скролла следует предоставить резервные URL пагинации (например, /blog/page/2/) с полным контентом в исходном HTML-ответе. Если SSR невозможен, можно использовать пререндеринг через сервисы вроде Prerender.io или Rendertron, которые отдают Googlebot закешированный HTML-снапшот. Google разрешает такой подход при условии, что снапшот полностью совпадает с контентом, видимым пользователям, чтобы избежать клоакинга. Рекомендуется ежемесячный аудит, включающий проверку разрыва дат краулинга и рендера, наличие контента первого экрана в сыром коде, Total Blocking Time ниже 200 мс в PageSpeed Insights и корректность пагинации.