Загрузка...
Загрузка...
Found a bug, outage, or unexpected behavior in reChecker? Send us a message and we will check and fix it.
Как разные стратегии рендеринга — server-side, client-side, статическая генерация и ISR — влияют на индексацию сайта поисковыми системами. Практические риски и как их избежать.
Быстрые определения и связанные понятия из SEO-глоссария reChecker.
Мета-теги — HTML-элементы в секции head, передающие информацию о странице поисковикам и браузерам. Узнайте какие мета-теги важны для SEO.
Читать в глоссарии →Robots.txt — текстовый файл в корне сайта, управляющий доступом поисковых роботов к страницам. Узнайте как правильно настроить robots.txt для SEO.
Читать в глоссарии →Core Web Vitals — три метрики Google для оценки пользовательского опыта: LCP, INP и CLS. Влияют на ранжирование и скорость работы сайта.
Читать в глоссарии →Краулинг (crawlability) — способность поисковых роботов обходить страницы сайта. Проблемы с краулингом приводят к тому что страницы не попадают в индекс.
Читать в глоссарии →Полное руководство по современной разработке на Next.js. App Router, Server Components, серверные действия, оптимизация производительности и практические рекомендации.
РазработкаСовременные подходы к написанию TypeScript-кода. Строгая типизация, паттерны проектирования, интеграция с фреймворками и советы по повышению качества кодовой базы.
РазработкаРазбираем CORS простыми словами: preflight-запросы, заголовки Access-Control-*, типичные ошибки настройки на бэкенде и примеры конфигурации для Nginx и Express.
CSS & ДизайнПолное руководство по дизайн-токенам: CSS custom properties, Tailwind config, JSON-формат. Как создать единую дизайн-систему и синхронизировать стили между кодом и дизайном.
Поделитесь с коллегами или изучите другие материалы блога
«Google давно умеет рендерить JavaScript, можно не париться» — пожалуй, самое опасное упрощение в современном фронтенд-SEO. Googlebot действительно рендерит JS, но не мгновенно, не бесплатно с точки зрения краулингового бюджета и не всегда полностью. Разберём, как реально работает индексация при разных стратегиях рендеринга и какую выбрать для конкретной страницы.
Сервер отдаёт почти пустой HTML с тегом <div id="root"> и пачкой JS-бандлов. Весь контент собирается в браузере после загрузки и выполнения скриптов.
Что видит робот: сначала — пустую страницу. Чтобы получить финальный контент, Google должен поставить страницу в очередь на рендеринг (это отдельный, более медленный конвейер, чем обычное сканирование HTML), дождаться очереди, выполнить JS и только тогда проиндексировать результат. На практике это означает задержку в индексации — от часов до нескольких дней — и риск, что часть контента (особенно если он подгружается по дополнительным запросам после первого рендера) робот вообще не дождётся.
Сервер на каждый запрос рендерит полный HTML с контентом и отдаёт его сразу. Робот получает готовую разметку без необходимости выполнять JS для базовой индексации.
Цена — нагрузка на сервер: каждый визит, включая визиты ботов, требует серверного рендеринга. При высокой посещаемости это требует масштабирования бэкенда или кэширования отрендеренного HTML.
HTML генерируется один раз при сборке проекта и раздаётся как статика — самый быстрый вариант и для пользователя, и для робота: сервер просто отдаёт готовый файл, без вычислений на лету.
Подходит для контента, который не меняется при каждом запросе — блог, документация, лендинги. Не подходит для страниц с персонализацией или часто меняющимися данными (если только не сочетать с ISR).
Гибрид: страница генерируется статически, но переодически перегенерируется в фоне (по таймеру или по запросу), не требуя полной пересборки всего сайта. Хороший компромисс для каталогов с тысячами страниц, где полная статическая пересборка при каждом изменении слишком дорога.
Контент, который подгружается по клику или скроллу. Если основной текст появляется только после взаимодействия пользователя (вкладки, «показать ещё», бесконечный скролл без серверной пагинации), робот может его просто не увидеть — он не кликает и не скроллит как человек.
Критичные мета-теги, генерируемые на клиенте. Title и description, которые ставятся через JS после монтирования компонента, иногда успевают попасть в индекс, а иногда — нет, в зависимости от того, в какой момент Google «сфотографировал» состояние страницы. Надёжный вариант — выставлять метаданные на сервере.
Гидратация, ломающая контент до полной загрузки. Если на CSR-странице сервер успел отдать что-то (например, через предварительный рендер), а потом клиентский JS полностью переписывает DOM, есть риск рассинхронизации между тем, что увидел робот, и тем, что видит пользователь — это может восприниматься как cloaking, даже если это случайность, а не злой умысел.
Бесконечная зависимость от внешних API во время рендеринга. Если SSR-страница рендерится медленно из-за того, что ждёт ответ от трёх внешних сервисов, при высокой нагрузке сервер может начать отдавать роботу таймауты вместо контента — а это куда хуже, чем просто медленная страница.
У нас на reChecker есть страницы публичных отчётов (/report/[домен]). Технический аудит показывает результат через клиентский компонент ('use client') — потому что там нужна интерактивность: вкладки, раскрывающиеся блоки, состояние. Формально это клиентский рендеринг.
Но критичной проблемой для индексации это не стало — потому что Next.js App Router рендерит клиентские компоненты на сервере при первом запросе (так называемый server-side render клиентского компонента), и в HTML, который получает робот, уже есть весь контент. Гидратация на клиенте происходит поверх готовой разметки, не перезаписывая её с нуля.
Мораль: «use client» в современных фреймворках — не приговор для SEO сам по себе, важно, что именно происходит при первом запросе к серверу. Прежде чем делать выводы, стоит реально посмотреть на HTML, который получает робот, а не гадать по архитектуре компонента.
Самый надёжный способ — не гадать, а посмотреть на сырой HTML-ответ сервера до выполнения JS:
curl -s https://example.com/page | grep -o '<title>[^<]*</title>'
Если в первом ответе сервера уже есть заголовок, описание и основной текстовый контент — индексация, скорее всего, не пострадает даже при сложном клиентском взаимодействии поверх. Если страница приходит почти пустой («<div id="root"></div>» и ничего больше) — стоит разобраться, действительно ли критичный для SEO контент рендерится на сервере.
Дополнительно полезно прогнать страницу через технический аудит — он показывает мета-теги и часть структурных данных так, как их видит автоматический парсер, а не браузер с включённым JS, что близко к тому, как страницу читает поисковый робот при первичном сканировании.
curl или «просмотр кода страницы») на наличие title, description и основного контента;document.title в клиентском JS;Выбор стратегии рендеринга — это не религиозный спор «SSR хорош, CSR плох». Это инженерный компромисс между скоростью разработки, нагрузкой на сервер и тем, что реально получает робот при первом запросе. Главное правило простое: для всего, что должно ранжироваться, контент должен быть в HTML-ответе сервера — будь то через SSR, SSG или ISR. Всё остальное — детали реализации.
Если сомневаетесь, что робот видит на ваших ключевых страницах — не гадайте, проверьте: технический аудит и контроль Core Web Vitals дают честную картину того, с чем реально имеет дело поисковая система, а не то, что видно в браузере разработчика с тёплым кэшем.