Самый важный технический вопрос перед стартом разработки — где собирается HTML. На сервере или в браузере пользователя? Это одно решение определяет скорость индексации, показатели загрузки и даже то, как ссылка на сайт выглядит в Телеграме.
На практике я не раз видел одну и ту же картину: на красивый современный React-сайт потрачены серьёзные деньги, контент написан отлично, а Google два месяца не берёт страницы в индекс. Причина — неверно выбранный способ рендеринга.
Базовые понятия
SSR — Server-Side Rendering
Сервер отдаёт готовый HTML на каждый запрос. Поисковый робот, запросив страницу, сразу получает полный текст, заголовки, метатеги и структурированные данные.
Это классический подход: PHP (Laravel, Yii2), Django, Rails. А также серверный режим современных JS-фреймворков — Next.js, Nuxt, SvelteKit.
SSG — Static Site Generation
HTML готовится заранее, во время сборки проекта. Пользователь получает готовый файл, сервер ничего не вычисляет.
Самый быстрый вариант. Минус: при изменении контента сайт нужно пересобрать. Идеально для блогов, документации, лендингов.
CSR / SPA — Client-Side Rendering
Сервер отдаёт пустой <div id="app"></div> и бандл JavaScript. Весь контент рисует браузер.
Это сайты на React, Vue или Angular, работающие без серверного рендера. Именно здесь начинаются проблемы с SEO.
Гибридные решения
ISR (Next.js), Astro Islands, React Server Components — по сути это SSR или SSG с точечной интерактивностью там, где она нужна. Сегодня это самое разумное направление.
Как Google обрабатывает JavaScript
Googlebot выполняет JavaScript — это давно не спорный вопрос. Но процесс идёт в два этапа:
- Робот загружает HTML и видит ссылки в нём
- Страница попадает в очередь на рендеринг, где Chromium выполняет JS
Представители Google говорят, что в медиане задержка составляет несколько секунд. Проблема не в медиане, а в «хвосте» распределения. На крупных или малозначимых сайтах отдельные страницы могут стоять в очереди сутками.
Для новостного сайта это катастрофа: новость устареет раньше, чем попадёт в индекс. Для блога — терпимо.
Главная проблема — не Google
Сегодня основной аргумент против SPA связан вовсе не с Googlebot. Дело в остальных роботах:
| Робот | Выполняет JS | Почему это важно |
|---|---|---|
| Googlebot | Да, с задержкой | — |
| YandexBot | Ограниченно | В Узбекистане доля Яндекса заметна |
| Bingbot | Частично | Источник для Copilot |
| GPTBot, ClaudeBot, PerplexityBot | Нет | Доля AI-поиска растёт |
| Боты превью Telegram, Facebook | Нет | Вид ссылки в мессенджерах |
Последняя строка — отдельная боль для узбекского рынка. Кидаете ссылку на SPA-сайт в Телеграм, а превью пустое, потому что Open Graph теги проставляются джаваскриптом. Трафик теряется ещё до того, как дойдёт до поисковика.
AI-поиск тоже растёт быстро. Упоминание сайта как источника в ответах ChatGPT, Perplexity и Claude становится новым каналом трафика. Эти роботы JS не выполняют — они видят ровно то, что отдал сервер.
Влияние на Core Web Vitals
В SPA тяжёлый JS-бандл портит все три ключевые метрики:
LCP — основной контент появляется только после загрузки JS, его выполнения и ответа от API. При SSR он уже в первом ответе.
INP — процесс гидратации блокирует основной поток. Страница видна, но не реагирует на клики.
CLS — макет прыгает, когда скелетоны-заглушки сменяются реальным контентом.
На медленном 3G и среднем телефоне бандл в 500 КБ — это несколько секунд задержки. С учётом доли мобильного трафика в Узбекистане это реальная потеря конверсии.
Типичные ошибки SPA-сайтов
На аудитах почти всегда нахожу одно и то же:
- Навигация через
onclick— робот не видит<a href>, а значит внутренних ссылок для него не существует. Структура сайта для краулера невидима. - Хэш-роутинг (
#/article/5) — такие URL не индексируются, Google игнорирует фрагмент. - Несуществующая страница отдаёт 200 — проблема soft 404. Сервер всегда возвращает
index.html, даже если URL ошибочный. - Canonical и hreflang проставляются через JS — для Google может сработать, для остальных роботов их просто нет.
- Контент за кнопкой «Показать ещё» — то, что не нажали, в индекс не попадёт.
- Динамические метатеги — с сервера приходит одинаковый
<title>для всех страниц, потом JS его меняет. Боты превью берут первый вариант.
Что выбирать под задачу
Контентные проекты — блог, новости, каталог, сайт услуг. Только SSR или SSG, альтернатив нет.
Интерактивные инструменты — калькуляторы, конвертеры, редакторы. Здесь CSR уместен, но посадочные страницы должны рендериться на сервере. Например, сам конвертер файлов может работать в браузере, но страница с описанием под каждый формат обязана быть SSR.
Личный кабинет, админка — индексация не нужна, SPA идеален.
Если React-сайт уже готов, есть три пути:
- Перевести на Next.js или Nuxt — правильно, но дорого
- Подключить пререндер-сервис (Prerender.io и аналоги) — быстро, но это костыль
- Вынести на серверный рендер только критичные для SEO страницы — промежуточное решение
Чек-лист проверки
Чтобы понять, всё ли в порядке с рендерингом:
- Нажмите
Ctrl+Uи посмотрите исходный код. Текст есть? Если нет — это CSR. - Отключите JavaScript в браузере и обновите страницу. Что осталось?
- В Google Search Console: «Проверка URL» → «Проверенная страница» → посмотрите HTML.
- Киньте ссылку в Телеграм — превью появилось?
- Выполните
curl -A "GPTBot" https://site.uz/pageи проверьте, есть ли контент в HTML. - Посмотрите LCP и INP в PageSpeed Insights.
- Убедитесь по коду, что внутренние ссылки — настоящие
<a href>.
Пятый пункт раскрывает больше всего: если curl возвращает пустой HTML, для AI-поиска и мессенджеров вас не существует.