Бюджет рендеринга, а не краулинговый бюджет, сутками держит...

Бюджет рендеринга, а не краулинговый бюджет, сутками держит свежий 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, а не вес бандла сам по себе.

@MikeBlazerX

⚠️ Закрытый канал: @MikeBlazerPRO

Источник новости https://t.me/mikeblazerx/6570...