Бюджет рендеринга, а не краулинговый бюджет, сутками держит свежий JS-контент без индексации
Google делит краулинг и рендеринг на два прохода.
Краулинг — это быстро и дешево; выполнение JavaScript требует реальных вычислительных мощностей, поэтому тяжелые JS-страницы падают в очередь и рендерятся второй волной, иногда спустя часы или дни.
Именно из-за этой очереди обновленный контент не появляется в выдаче.
Краулинговый бюджет считает страницы, просканированные за день; бюджет рендеринга — это отдельный ресурс, определяющий, на скольких страницах Google выполнит JavaScript.
Диагностируй это в GSC.
Прогони ключевую страницу через URL Inspection и сравни дату Last crawl с датой Last crawl rendered.
Большой разрыв означает, что гуглобот парсит страницу, но откладывает рендер.
Сверься с отчетом Page Indexing, отфильтровав по Crawled, currently not indexed.
Если тяжелые JS-урлы скапливаются там, причина — задержка рендера.
Быстрый тест: открой исходный код через Ctrl+U.
Если в сыром HTML нет основного контента, Гуглу придется отрендерить JS, чтобы вообще его увидеть.
Четыре вещи выжигают бюджет рендеринга быстрее всего: бандлы тяжелее 1 МБ, сторонние скрипты (GA4, Hotjar, Intercom, Optimizely, GTM с 15+ тегами — в сумме это от 2 до 5 секунд выполнения), ленивая загрузка, которая не срабатывает при рендере, и бесконечный скролл.
Гуглобот не скроллит: он рендерит начальный вьюпорт и останавливается, поэтому контент со второй по N-ную страницу, который подгружается только по скроллу, остается невидимым.
Базовое решение — перенести критически важный контент, заголовки и метаданные на SSR.
Next.js: getServerSideProps или getStaticProps.
Nuxt: режим SSR или nuxt generate.
Без фреймворков: отдавай полный HTML, а не пустую оболочку, которую JS заполняет после загрузки.
Проверяй каждое изменение по отрендеренному HTML в URL Inspection.
Затем срежь пейлоад.
Целься в менее 200 КБ распарсенного JavaScript для контента первого экрана.
Найди раздутые пакеты через webpack-bundle-analyzer или source-map-explorer, вычисти неиспользуемый код (tree-shaking), разбей бандл по роутам, отложи некритичные скрипты и запускай сторонние теги по Window Loaded, а не DOM Ready.
Никогда не вешай ленивую загрузку на hero-изображения (используй fetchpriority="high"), основной текст, заголовки или навигацию — всё, что нужно Гуглу для понимания темы страницы, должно быть в первичном рендере.
Для бесконечного скролла выкатывай резервные URL пагинации (/blog/page/2/) с атрибутами rel="next"/rel="prev", где каждый урл отдает полный контент в исходном HTML-ответе.
Если SSR невозможен, пререндеринг через Prerender.io или Rendertron будет отдавать гуглоботу закешированный HTML-снапшот, тогда как юзеры получат JS-версию.
Google разрешает такой подход, если снапшот совпадает с тем, что видят пользователи — расхождение контента считается клоакингом.
Аудит раз в месяц: разрыв дат краулинга и рендера на 10 ключевых страницах, наличие контента первого экрана в сыром коде, Total Blocking Time ниже 200 мс в PageSpeed Insights, запуск сторонних скриптов по window load и наличие резервных ссылок пагинации на каждой странице с бесконечным скроллом.
Инсайты комьюнити
— Полевые тесты на 700-килобайтном бандле показали: Гуглу требовались дни на рендер нового текста; срезка сторонних скриптов и перенос ключевого текста на SSR сократили разрыв в рендере вдвое. Реальный рычаг — это связка сторонних скриптов и SSR, а не вес бандла сам по себе.
#Rendering #JavaScript #CrawlBudget
@MikeBlazerX
⚠️ Закрытый канал: @MikeBlazerPRO
