Можно ли продвигать сайт на React?

Да. React-сайт может индексироваться, если поисковик получает доступ к содержанию, маршрутам, метаданным и необходимым ресурсам. Проблема обычно связана не с React, а с конкретным способом рендеринга.

Индексирует ли Google JavaScript?

Да, Google умеет обрабатывать JavaScript, но делает это через отдельный этап рендеринга после первичного обхода HTML. Поэтому критически важный контент лучше размещать в первоначальном серверном ответе.

Нужно ли использовать SSR для каждой страницы?

Нет. Для статичных страниц, блога и документации часто подходит SSG. SSR нужен там, где содержимое формируется на запрос, быстро меняется или зависит от параметров пользователя.

Подходит ли SSG для блога?

Да. Статьи блога обычно не меняются при каждом запросе, поэтому их можно генерировать во время сборки и отдавать как статический HTML.

Можно ли использовать CSR для главной страницы?

Технически можно, но если главная должна получать поисковый трафик, зависимость основного контента от JavaScript увеличивает риск ошибок обхода и рендеринга. Для SEO-важной главной страницы лучше отдавать готовый HTML.

Что такое пререндеринг?

Пререндеринг — предварительное формирование HTML для маршрутов приложения. Готовые страницы сохраняются и отдаются пользователю или роботу как HTML-файлы.

Чем пререндеринг отличается от SSR?

При SSR HTML создаётся во время каждого запроса. При статическом пререндеринге HTML создаётся заранее, обычно во время сборки. Поэтому пререндеринг снижает нагрузку на сервер, но требует пересборки после изменений.

Может ли React скрыть текст от поисковика?

Да, если текст появляется только после выполнения JavaScript, загружается по недоступному API, находится за действием пользователя или не попадает в доступный DOM.

Нужно ли добавлять JSON-LD через React?

Можно, но для критически важных страниц предпочтительнее, чтобы JSON-LD присутствовал в исходном HTML. Разметка должна соответствовать видимому содержанию страницы.

Достаточно ли отключить JavaScript в браузере для проверки?

Нет. Это быстрый тест, но он не полностью имитирует работу поисковой системы. Нужно также сравнить исходный HTML, отрендеренный DOM, Search Console, Яндекс.Вебмастер и серверные логи.

Нужно ли блокировать JavaScript в robots.txt?

Нет, если он необходим для отображения страницы. Заблокированные ресурсы могут помешать корректному рендерингу.

Что использовать для публичного сайта Like Sites?

Для статей, страниц услуг и геопосадочных страниц рационально использовать статическую генерацию или пререндеринг. React можно оставить для интерактивных элементов, форм, меню, калькуляторов и клиентской аналитики.

JavaScript SEO: как поисковики индексируют React-сайты в 2026 году

Краткий ответ

React сам по себе не мешает SEO. Основной риск возникает, когда сервер отдаёт только пустой контейнер вроде <div id="root"></div>, а текст, заголовки, ссылки и метаданные появляются только после выполнения JavaScript.

Google обрабатывает JavaScript-сайты в несколько этапов: сначала обходит URL и получает исходный HTML, затем при необходимости выполняет JavaScript, после чего использует обработанный результат для индексации. Поэтому для публичных страниц, которым нужен поисковый трафик, основной контент, H1, ссылки, title, description и canonical желательно отдавать уже в первоначальном HTML-ответе.

Для этого применяют серверный рендеринг, статическую генерацию или статический пререндеринг. Клиентский React при этом можно использовать для меню, форм, калькуляторов и других интерактивных элементов.

Содержание

Что такое JavaScript SEO.
Как поисковик обрабатывает React-сайт.
Почему CSR создаёт проблемы.
Чем отличаются CSR, SSR, SSG и пререндеринг.
Что происходит с метаданными.
Как поисковики находят ссылки в React.
Как проверить страницу.
Типовые ошибки React-сайтов.
Когда CSR подходит.
Частые вопросы.
Практический чек-лист.

Что такое JavaScript SEO

JavaScript SEO — это набор технических решений, которые помогают поисковым системам обнаружить, обработать и проиндексировать содержание сайта, сформированное или изменённое JavaScript.

В обычном HTML-сайте сервер сразу возвращает документ, в котором находятся заголовок страницы, основной текст, заголовки H1–H3, ссылки, изображения, метатеги и структурированные данные.

В клиентском React-приложении сервер может вернуть только минимальную оболочку:

<!doctype html>
<html lang="ru">
  <head>
    <title>Сайт</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/assets/index.js"></script>
  </body>
</html>

После загрузки JavaScript браузер запускает приложение, React создаёт компоненты и вставляет содержимое в #root. Для пользователя процесс может быть почти незаметным. Для поискового робота всё зависит от того, сможет ли он загрузить JavaScript, выполнить его, получить данные API и дождаться формирования итогового DOM.

Поисковая система может обрабатывать JavaScript, но это не означает, что любой JavaScript-сайт будет проиндексирован без проблем. Чем больше важных элементов зависит от дополнительного рендеринга, тем больше технических условий необходимо выполнить.

Как обрабатывается React-сайт

Обход страницы

Поисковый робот запрашивает URL и получает HTTP-ответ. До загрузки страницы он проверяет правила robots.txt. Если URL запрещён для обхода, робот не сможет нормально получить страницу. Если запрещены JavaScript-файлы или другие необходимые ресурсы, итоговый рендеринг также может быть неполным.

На этапе первичного обхода робот может получить:

HTTP-статус;
исходный HTML;
title;
meta description;
canonical;
ссылки в атрибуте href;
часть текста;
директивы robots;
ссылки на CSS и JavaScript.

Если исходный HTML уже содержит полный текст статьи, поисковику не нужно ждать выполнения React, чтобы получить основное содержание.

Рендеринг JavaScript

Если страница содержит JavaScript, поисковая система может поставить её в очередь рендеринга. Затем браузерный движок выполняет код и формирует итоговый DOM.

В результате могут появиться:

текст, добавленный React;
ссылки, появившиеся после выполнения кода;
данные, загруженные из API;
JSON-LD, добавленный скриптом;
динамически сформированные метатеги.

Но рендеринг может завершиться ошибкой. Причинами становятся недоступный API, заблокированные ресурсы, ошибка JavaScript, неправильный маршрут или ожидание действия пользователя.

Индексация

После обработки страницы поисковая система анализирует полученный результат и решает, какие элементы использовать в индексе. Важен не только внешний вид страницы в браузере, но и доступность содержания, корректность HTTP-статуса, канонический URL, ссылки и соответствие техническим требованиям.

Проверять только то, что страница открывается в обычном браузере, недостаточно. Браузер пользователя может выполнить JavaScript, дождаться API и показать статью, тогда как исходный HTML, полученный роботом, окажется почти пустым.

CSR: клиентский рендеринг

CSR, или Client-Side Rendering, означает, что основная разметка страницы создаётся в браузере пользователя.

Типичная схема выглядит так:

сервер отдаёт минимальный HTML;
браузер загружает JavaScript;
React запускает приложение;
приложение получает данные;
React формирует DOM;
пользователь видит страницу.

Для закрытого личного кабинета такая схема часто подходит. Пользователь авторизуется, а содержимое кабинета не предназначено для индексации.

Для публичной статьи, страницы услуги или коммерческого каталога CSR может создавать дополнительные риски:

текст отсутствует в исходном HTML;
метатеги формируются слишком поздно;
поисковик не может получить данные API;
JavaScript заблокирован правилами;
страница отдаёт код 200, но содержит только экран загрузки;
внутренние ссылки появляются только после выполнения скрипта;
разные маршруты возвращают одинаковую оболочку.

CSR не является автоматически неправильным решением. Проблема появляется тогда, когда клиентский рендеринг используется для публичного контента, но его доступность для роботов не проверяется.

SSR: серверный рендеринг

SSR, или Server-Side Rendering, означает, что сервер формирует HTML для конкретного запроса.

Упрощённая схема:

пользователь или робот запрашивает URL;
сервер получает данные;
React формирует HTML на сервере;
сервер отдаёт готовую разметку;
браузер отображает содержание;
React подключает интерактивность.

React предоставляет серверные API для генерации HTML. renderToString формирует HTML-строку на сервере, а hydrateRoot подключает React к уже существующей разметке в браузере.

Пример подключения React к серверной разметке:

import { hydrateRoot } from "react-dom/client";
import App from "./App";

hydrateRoot(
  document.getElementById("root")!,
  <App />
);

При SSR сервер должен сформировать тот же React-вывод, который затем ожидает клиент. Если сервер и браузер формируют разную разметку, возникает hydration mismatch. Причинами могут быть текущее время, случайные значения, локаль, размер окна и данные, доступные только в браузере.

Преимущества SSR:

основной контент доступен в первом HTML-ответе;
робот может получить H1, текст и ссылки без ожидания клиентского рендера;
страница может содержать индивидуальные данные;
HTML можно формировать для каждого запроса.

Ограничения SSR:

сервер выполняет работу при каждом запросе;
возрастает нагрузка на инфраструктуру;
без кеширования может увеличиться время ответа;
ошибки получения данных могут повлиять на HTML;
необходимо контролировать соответствие серверного и клиентского результата.

SSR подходит для страниц, содержимое которых часто меняется или зависит от параметров запроса.

SSG: статическая генерация

SSG, или Static Site Generation, означает, что HTML создаётся заранее во время сборки проекта.

Схема выглядит так:

система получает список маршрутов;
React формирует HTML для каждого маршрута;
результат сохраняется в статические файлы;
сервер или CDN отдаёт эти файлы пользователю и роботу.

Для блога, сайта услуг, документации и большинства маркетинговых страниц SSG является практичным вариантом. Такие страницы не требуют отдельной генерации при каждом запросе.

Пример структуры результата:

dist/
  index.html
  blog/
    javascript-seo-react/
      index.html
  services/
    web-development/
      index.html

Если пользователь или робот запрашивает /blog/javascript-seo-react/, сервер должен вернуть HTML этой страницы, а не только общий index.html приложения.

Преимущества SSG:

HTML готов до первого запроса;
страницы можно отдавать через CDN;
серверу не нужно рендерить React при каждом просмотре;
результат проще проверять;
скорость ответа стабильнее;
статические страницы подходят для блога и сайта услуг.

Ограничения SSG:

после изменения контента требуется новая сборка;
большое количество маршрутов увеличивает время сборки;
часто меняющиеся данные неудобно генерировать заранее;
необходимо правильно настроить список маршрутов и неизвестные URL.

Для блога Like Sites статьи, страницы услуг и географические посадочные относятся к типам контента, для которых логично рассматривать статическую генерацию или пререндеринг.

Пререндеринг React-сайта

Пререндеринг — это предварительная генерация HTML для маршрутов React-приложения. В отличие от SSR, HTML создаётся не при каждом запросе, а во время сборки или отдельным сервисом.

Типичная схема:

формируется список публичных URL;
приложение запускается для каждого маршрута;
браузерный движок или серверный рендерер получает итоговую страницу;
содержимое сохраняется в HTML;
готовый файл размещается на сервере.

Пререндеринг позволяет сохранить клиентскую архитектуру React и одновременно получить готовый HTML для публичных страниц.

Важно различать статический пререндеринг на этапе сборки и динамический рендеринг для роботов по User-Agent. Динамический рендеринг создаёт отдельную версию страницы для роботов и рассматривается поисковыми системами как временное решение для проблем с JavaScript, а не как универсальная замена серверному или статическому рендерингу.

Для нового сайта предпочтительнее построить единый предсказуемый HTML-результат, который получают и пользователи, и поисковые роботы. Версия для робота не должна отличаться по смыслу от версии для пользователя.

Гидратация и SEO

Гидратация — это подключение React-логики к HTML, который уже был сформирован сервером или во время сборки.

До гидратации пользователь уже может увидеть текст и структуру страницы. После гидратации начинают работать кнопки, формы, меню, фильтры и другие интерактивные элементы.

React требует, чтобы клиентская разметка соответствовала серверной. Например, потенциальный конфликт может создать вывод текущего времени:

function Clock() {
  return <span>{new Date().toLocaleTimeString()}</span>;
}

Если сервер и браузер сформируют разные значения, React получит различие между исходной разметкой и клиентским результатом.

Для SEO важно, чтобы гидратация не заменяла основной контент экраном загрузки и не удаляла текст, который уже был доступен в HTML. Интерактивность должна дополнять содержание, а не быть единственным способом его получить.

Метаданные React-страницы

Каждый индексируемый URL должен иметь собственные метаданные:

уникальный <title>;
содержательный meta description;
canonical;
Open Graph при необходимости;
корректный H1;
структурированные данные, если они соответствуют странице.

Критические метаданные желательно формировать в исходном HTML. Если title и canonical добавляются только после выполнения JavaScript, поисковику приходится ждать рендеринга страницы.

Пример HTML-метаданных:

<title>JavaScript SEO: как поисковики индексируют React-сайты</title>
<meta
  name="description"
  content="Как поисковики обрабатывают React-сайты, чем отличаются CSR, SSR, SSG и пререндеринг."
/>
<link
  rel="canonical"
  href="https://example.ru/blog/javascript-seo-react/"
/>

Canonical должен указывать на предпочтительную версию URL. Адреса в canonical, sitemap и внутренних ссылках должны быть согласованы.

Структурированные данные JSON-LD помогают поисковику понять тип страницы, но не заменяют основной текст и не исправляют проблемы рендеринга. Разметка должна соответствовать видимому содержанию страницы.

Внутренние ссылки и React Router

Поисковому роботу нужно находить страницы через обычные ссылки.

Предпочтительный вариант:

<a href="/blog/javascript-seo-react/">
  JavaScript SEO для React-сайтов
</a>

Потенциально проблемный вариант:

<button => navigate("/blog/javascript-seo-react/")}>
  Читать статью
</button>

Кнопка может работать для пользователя, но не является обычной ссылкой в HTML. Важные URL должны быть доступны через атрибут href.

Для React Router необходимо контролировать:

отсутствие hash-маршрутов вида /#/page;
корректный ответ сервера для прямого открытия URL;
уникальный HTML для каждого маршрута;
обработку 404;
canonical для каждого адреса;
отсутствие дублей со слешем и без слеша.

Если неизвестный URL возвращает главную страницу с кодом 200, поисковик может воспринять его как существующую страницу. Это создаёт проблему soft 404. Для несуществующего маршрута должен возвращаться корректный ответ 404 или 410.

Как проверить React-сайт

Проверка должна выполняться на нескольких уровнях.

Исходный HTML

Откройте страницу и выберите просмотр исходного кода. В HTML должны присутствовать:

H1;
основной текст;
ссылки;
title;
description;
canonical;
необходимые JSON-LD;
важные изображения и alt.

Если в исходном коде находится только <div id="root"></div>, публичная страница зависит от клиентского рендера.

Проверка через curl:

curl -L https://example.ru/page/

Поиск H1:

curl -Ls https://example.ru/page/ | grep -i "<h1"

Также можно проверить ответ с User-Agent поискового робота:

curl -Ls \
  -A "Googlebot" \
  https://example.ru/page/

Этот тест показывает серверный ответ, но не заменяет официальные инструменты проверки индексации.

Отрендеренный DOM

Исходный HTML и DOM после выполнения JavaScript — не одно и то же. В DevTools сравните:

что пришло от сервера;
что добавил React;
появились ли текст и ссылки;
не изменились ли title и canonical;
нет ли ошибки JavaScript.

Google Search Console

В Google Search Console используется инструмент проверки URL. Он позволяет проверить страницу, увидеть информацию о доступности и посмотреть отрендеренный результат.

Яндекс.Вебмастер

Для Яндекса отдельно проверьте:

ответ сервера;
доступность URL;
наличие страницы в индексе;
состояние sitemap;
ошибки обхода;
корректность robots.txt.

Проверка в одной поисковой системе не подтверждает автоматически, что страница одинаково обрабатывается всеми поисковиками.

Логи сервера

Логи показывают, какие URL запрашивались, с какими User-Agent и какими статусами отвечал сервер.

Ищите:

частые ответы 404;
запросы к старым URL;
заблокированные ресурсы;
повторяющиеся обращения к одному маршруту;
ошибки 5xx;
запросы роботов к sitemap;
отсутствие обхода новых страниц.

Типовые ошибки React-сайтов

Пустой HTML

Сервер отдаёт приложение без текста, а контент появляется только после загрузки JavaScript. Для SEO-важных страниц это ненадёжная архитектура.

Запрет JavaScript в robots.txt

Если robots.txt блокирует JS-файлы, поисковик может не суметь корректно отрендерить страницу.

Навигация только через onClick

Робот может не обнаружить URL, если он не представлен обычным href.

Динамические метатеги после загрузки

Если title и canonical меняются только после запуска React, исходный HTML не содержит важные сигналы.

API недоступен роботу

React может ожидать данные от API, которое требует авторизацию, блокирует User-Agent или отвечает ошибкой. Пользователь видит статью, а робот получает экран загрузки.

Неправильные HTTP-статусы

SPA часто возвращает код 200 для любого маршрута. В результате несуществующие страницы выглядят для поисковика как существующие.

Разные результаты на сервере и клиенте

Hydration mismatch возникает, когда сервер и браузер формируют разную разметку. Это может произойти из-за времени, случайных значений, локали, размера окна и данных, доступных только в браузере.

Бесконечный скролл без URL

Если новые материалы появляются только после прокрутки, но не имеют отдельных доступных URL и ссылок, поисковик может не обнаружить весь контент.

Когда CSR подходит

CSR подходит для частей сайта, которым не нужен органический трафик:

личный кабинет;
CRM;
административная панель;
закрытые документы;
персональные отчёты;
интерактивные инструменты после авторизации;
элементы, зависящие от конкретного пользователя.

Для публичных страниц, которые должны ранжироваться, предпочтительнее использовать SSR, SSG или статический пререндеринг. Выбор зависит от частоты обновления данных, количества URL, персонализации и возможностей сервера.

Тип страницы	Предпочтительная стратегия
Статья блога	SSG или пререндеринг
Страница услуги	SSG или пререндеринг
Географическая посадочная	SSG или пререндеринг
Часто меняющийся каталог	SSR или гибридная схема
Персональный кабинет	CSR
Админ-панель	CSR
Документация	SSG
Форма с интерактивной логикой	HTML-контент плюс клиентский React

Практический чек-лист

Перед публикацией React-страницы проверьте:

URL открывается напрямую без перехода с главной страницы.
Сервер возвращает код 200 для существующей страницы.
В исходном HTML присутствует H1.
В исходном HTML находится основной текст.
Title уникален.
Meta description уникален.
Canonical указывает на правильный URL.
Внутренние ссылки используют <a href>.
Страница не зависит от обязательного клика или прокрутки.
API доступен для формирования публичного контента.
JavaScript и CSS не заблокированы без причины.
JSON-LD соответствует видимым данным.
Неизвестные URL возвращают 404 или 410.
Нет дублей со слешем и без слеша.
Страница корректно работает на мобильном устройстве.
Проверен отрендеренный DOM.
URL проверен в Google Search Console.
URL проверен в Яндекс.Вебмастере.
Внутренние ссылки добавлены в тематический кластер.
URL включён в sitemap.xml.
Маршрут добавлен в список пререндеринга.
После сборки выполнен повторный запрос через curl.

Связанные материалы Like Sites

Итог

React подходит для SEO-ориентированных сайтов, если публичные страницы отдают поисковику полноценный HTML. Основной контент, заголовки, ссылки и метаданные не должны зависеть только от выполнения JavaScript в браузере.

Для блога и сайта услуг Like Sites базовой стратегией может быть SSG или статический пререндеринг. SSR следует применять для страниц с динамическими данными, а CSR оставить для закрытых и интерактивных частей сайта.

Главная практическая проверка проста: если открыть исходный HTML страницы и увидеть в нём H1, основной текст, ссылки, title и canonical, архитектура значительно надёжнее, чем у приложения, которое возвращает только пустой root. Окончательная проверка должна включать отрендеренный DOM, Google Search Console, Яндекс.Вебмастер и серверные логи.

JavaScript SEO: как поисковики индексируют React-сайты в