Dynamic Rendering (динамический рендеринг)
Динамический рендеринг (dynamic rendering) - это техника, при которой сайт отдает две версии каждой страницы: предварительно отрисованный статический HTML-снимок краулерам поисковых систем и полноценный опыт одностраничного JavaScript-приложения людям. Google публично одобрил его как обходное решение для сайтов с большим объемом JS в 2018 году, а затем к 2024 году тихо понизил его до "устаревшего обходного приема", по мере того как рендеринг JS у Googlebot совершенствовался.
Динамический рендеринг (dynamic rendering) - это техника, при которой сайт отдает две версии каждой страницы: предварительно отрисованный статический HTML-снимок краулерам поисковых систем и полноценный опыт одностраничного JavaScript-приложения людям. Google публично одобрил его как обходное решение для сайтов с большим объемом JS в 2018 году, а затем к 2024 году тихо понизил его до "устаревшего обходного приема", по мере того как рендеринг JS у Googlebot совершенствовался.
Почему это важно
Сайты с большим объемом JavaScript раньше отдавали пустые HTML-оболочки, рассчитывая, что краулер выполнит JS и увидит реальный контент. В конце концов Googlebot научился это делать, но медленно - часто спустя дни после первоначальной загрузки HTML, - а другие краулеры (Bing, AI-боты, превью Facebook) справлялись еще хуже. Динамический рендеринг позволял SEO-командам гарантировать, что краулеры сразу видят полностью отрисованный HTML, без переписывания приложения. Для каталогов интернет-магазинов, JS-дашбордов и SPA с критичными для SEO потребностями это был прагматичный мост. Понимать его все еще важно, потому что многие сайты сегодня работают на динамическом рендеринге и нуждаются в переходе на другое решение.
Как это работает
1. Поступает запрос: edge-узел или сервер анализирует user-agent.
2. Распознавание краулера: если user-agent совпадает с известным поисковым ботом (Googlebot, Bingbot, Twitterbot, LinkedInBot, AI-краулеры), запрос направляется в сервис предварительного рендеринга. В противном случае он попадает в обычное SPA.
3. Сервис предварительного рендеринга: безголовый Chrome (часто через prerender.io, Rendertron, Puppeteer или Playwright) загружает страницу, дожидается завершения JS, фиксирует DOM и возвращает статический HTML.
4. Кеш: отрисованный HTML кешируется, чтобы последующие обращения краулеров не запускали повторный рендеринг.
5. Бот видит HTML, пользователь видит SPA: один и тот же URL, два разных опыта.
Почему сейчас это "устаревший обходной прием"
Рекомендации Google 2024 года перевели динамический рендеринг из категории "рекомендуется" в "обходной прием, а не долгосрочное решение". Причины:
Googlebot теперь хорошо отрисовывает JS: Google использует актуальный безголовый Chrome и быстро обрабатывает JS на большинстве страниц. Изначальная причина для динамического рендеринга для Google по большей части исчезла.
Бремя обслуживания: параллельное поддержание второго конвейера рендеринга - это операционная сложность, которая обычно перевешивает выгоду.
Риск расхождения: когда сервис предварительного рендеринга ломается или устаревает, боты видят старый контент, а пользователи - новый - классический сигнал клоакинга.
Не санкция за клоакинг, но близко к этому: Google прямо заявляет, что динамический рендеринг не является клоакингом, но расхождение между тем, что видят бот и пользователь, может спровоцировать ручную проверку.
Современные SSR / SSG лучше: Next.js, Nuxt, SvelteKit, Astro и Remix по умолчанию отдают серверно отрисованные или статически сгенерированные страницы. Динамический рендеринг не нужен.
Когда (если вообще) это все еще имеет смысл
Устаревшие SPA, которые нельзя переписать: зрелое приложение с большим объемом JS без бюджета на миграцию на SSR. Динамический рендеринг все еще жизнеспособен как временная мера.
Краулеры помимо Google: AI-краулеры, Bing, Baidu и нишевые боты по-прежнему отрисовывают JS хуже Google. Если они важны для вашего трафика, динамический рендеринг может помочь.
Виджеты и встраиваемые блоки: контент, который подгружается через JS после первоначального HTML, - иногда это единственный способ показать его краулерам.
Обходные решения на edge-рендеринге: тонкий динамический рендеринг на edge-узле CDN, который на лету преобразует SPA в HTML, без отдельного сервиса предварительного рендеринга.
Как уйти от динамического рендеринга
1. Проверьте, что на самом деле не работает в JS: используйте проверку URL в Search Console и сравнение рендеринга. Многие "проблемы JS SEO" - это просто отсутствие SSR на критичных страницах.
2. Переведите критичные страницы на SSR или SSG: в первую очередь главную, целевые, товарные страницы и статьи. Дашборды и зоны для авторизованных пользователей оставьте как SPA.
3. Используйте современный фреймворк: Next.js / Nuxt / SvelteKit поддерживают гибридный рендеринг "из коробки".
4. Проверьте соответствие: после миграции просканируйте новый сайт с помощью Screaming Frog и убедитесь, что HTML совпадает с тем, что выдавал старый предварительный рендеринг.
5. Выведите сервис предварительного рендеринга из эксплуатации: только после нескольких недель чистых отчетов о покрытии в Search Console.
Распространенные ошибки
Намеренная отдача разного контента: динамический рендеринг - это "тот же контент, другая форма". Иной контент - это клоакинг, и он наказывается.
Необновление кеша предварительного рендеринга: устаревшие предварительные рендеры скармливают ботам старый контент, ранжируя сайт по вчерашнему товару.
Опора на предварительный рендеринг во всем: размещение предварительного рендеринга перед сайтом без стратегии SSR означает, что вы всегда в одном сбое от слепоты для краулеров.
Игнорирование списков UA для краулеров, кроме Googlebot: у Bing, Yandex, Baidu, AI-краулеров разные UA. Забытый бот окажется в ситуации клоакинга по отношению к этому боту.
Использование динамического рендеринга для новых проектов: не делайте этого. Вместо этого используйте SSR/SSG в современном фреймворке.
Источники: