SSR в SPA есть, а SEO нет
Вы перевели интернет-магазин на Next.js или Nuxt.js, подключили SSR, все «рендерится на сервере», но органический трафик не растет. В Google Search Console видно частичную индексацию, а в Яндекс Вебмастере почти пусто. Знакомо?
Проблема не в самом SPA. Проблема – в качестве HTML, который отдается с сервера. Наличие SSR – это лишь техническая возможность. Чтобы она работала на SEO, SSR-верстка должна быть полной, семантически корректной и лишенной типичных ошибок.
Типичные ошибки SPA
Разберем девять критических проблем, которые делают сайт «невидимым» для поисковиков даже при формальном наличии SSR. Особенно актуально для проектов, ориентированных на российскую аудиторию и продвигающихся в Яндексе.
- Ссылки без < a >: сайт становится «непроходимым»
Суть ошибки
В SSR-HTML вместо семантической ссылки < a href="/product/123" > используются < div >, < span >, < button > и обработчики кликов (onClick, router.push()).
Почему это критично
Обе поисковые системы – Google и Яндекс – полагаются на тег < a > с атрибутом href как на основной сигнал навигации внутри сайта. Только такие элементы участвуют в построении карты сканирования; передают anchor text, который напрямую влияет на текстовую релевантность целевой страницы; позволяют роботу понять иерархию и структуру сайта, распределить ссылочный вес.
Если ссылка реализована без < a >, она может быть проигнорирована при сканировании, даже если работает в браузере. В результате страница не получает anchor text от других разделов, не участвует во внутренней перелинковке и теряет релевантность по целевым запросам.

Пример отсутствия тега < a > в коде
Sitemap.xml помогает обнаружить URL, но не заменяет внутренние ссылки. Он не дает контекста, не формирует иерархию и не влияет на понимание тематики.
Но даже наличие тега < a > не является страховкой от ошибки.

Тег < a > есть, а атрибута href нет
Правильный подход
Внутренние ссылки на сайте должны использовать семантический тег < a href > с корректным значением адреса. Даже если визуально элемент ведет на страницу через < div >, < span > или < button > с обработчиком клика, поисковые роботы его не распознают.
- Разный HTML в SSR для ПК и мобильных устройств: отсутствие единой структуры
Суть ошибки
На сайте используется раздельная верстка: сервер отдает разные HTML-структуры для десктопных и мобильных устройств. Это не адаптивность через CSS, а фактически две разные страницы.
Приведем типичные примеры различий между версиями сайта.
-
Пагинация. В десктопной версии есть привычная навигация по страницам – ссылки вроде < a href="/page/2" >2< /a > и < a href="/page/3" >3< /a >. В мобильной версии ее заменяют бесконечной лентой: пользователь просто скроллит список, а ссылок на другие страницы при этом нет.
-
Хлебные крошки. На десктопе, отображается полная цепочка навигации со ссылками на все уровни разделов. В мобильной версии она упрощена: например, остается только кнопка «Назад» или укороченная цепочка, где часть уровней вообще отсутствует в DOM.
-
Меню. В десктопной версии это обычно выпадающее меню с разделами. В мобильной – просто ссылка, ведущая на отдельную страницу «Каталог».
Почему это критично
Google использует mobile-first indexing, для него основной является мобильная версия. Яндекс чаще сканирует десктопную версию, особенно если она содержит больше контента. Если в одной из версий нет ссылок на пагинацию, поисковик не может перейти на вторую и последующие страницы категории.
Это становится критичной проблемой, если sitemap.xml отсутствует или не полный. В такой ситуации пагинация – единственный путь для поисковика добраться до глубоких карточек. Если ее нет в SSR, то ассортимент обрезается: индексируются только товары с первой страницы категории.
Аналогично, если в одной из версий отсутствуют промежуточные звенья хлебных крошек, то теряется anchor text для категорий, передача веса по иерархии и контекст для расчета текстовой релевантности.
С помощью инструмента Diff Checker можно сравнить код страниц для разных устройств.

Правильный подход
Чтобы избежать таких проблем, лучше сразу закладывать несколько базовых принципов в архитектуру сайта.
Во-первых, по возможности использовать адаптивную верстку, когда для всех устройств отдается один и тот же HTML. Это снижает риск того, что поисковый робот увидит структуру страниц иначе, чем пользователь.
Во-вторых, если навигация на десктопе и в мобильной версии принципиально отличается, важно сохранять семантические ссылки в HTML. Например, пагинация должна оставаться реализованной через < a href >, даже если визуально она скрыта. То же касается и хлебных крошек: в DOM лучше оставлять полную цепочку разделов.
Еще одна страховка – актуальный sitemap.xml с прямыми ссылками на все товары и страницы каталога. Он помогает поисковым системам находить страницы даже в тех случаях, когда навигация на сайте работает неидеально.
И наконец, стоит регулярно проверять, совпадает ли структура ссылок в исходном HTML для десктопной и мобильной версии. Это простая проверка, которая часто помогает вовремя заметить проблемы с индексируемостью.
- Контент в аккордеонах, вкладках и FAQ отсутствует в SSR
Суть ошибки
Частая проблема – контент, который подгружается только на стороне клиента. Например, тексты во вкладках «Описание», «Характеристики», «Гарантия», «FAQ» могут появляться на странице уже после загрузки, через JavaScript. В результате в SSR-версии страницы этого контента просто нет.
Если посмотреть исходный HTML, картина обычно выглядит так: контейнеры под описание товара или блоки с товарными рекомендациями присутствуют, но остаются пустыми. Вкладки с характеристиками и отзывами могут вообще отсутствовать в разметке, потому что данные для них загружаются асинхронно на клиенте.
Похожая ситуация возникает с контентом внутри аккордеонов, вкладок или выпадающих списков. Нередко он подгружается только после взаимодействия пользователя – например, при клике на вкладку или раскрытии блока. Для поисковых систем такой контент может оказаться недоступным или индексироваться значительно хуже.
Почему это критично
Поисковые системы – и Google, и Яндекс – индексируют контент, скрытый через CSS (display: none, visibility: hidden), если он присутствует в исходном HTML-коде страницы. Критическая разница возникает, когда текст отсутствует в SSR-HTML и подгружается динамически только после выполнения JavaScript на клиенте: Google может выполнить скрипты и проиндексировать такой контент, но с задержкой (в рамках второй волны индексации) и без гарантий, так как рендеринг зависит от доступности ресурсов краулера. Яндекс менее агрессивно выполняет клиентский JavaScript, поэтому контент, которого нет в начальном HTML, с высокой вероятностью не будет проиндексирован. В итоге снижается релевантность, отсутствуют доверительные сигналы.
Правильный подход
Весь важный контент должен быть в SSR-HTML, даже если изначально он скрыт.
«Скрытый» не значит «отсутствующий» – для SEO важно присутствие в DOM. Если API недоступен на сервере, используйте кеширование ответов на стороне сервера.
- Lazy-loading критического контента в SSR
Суть ошибки
Блоки ниже первого экрана (отзывы, преимущества, сравнения) удалены из SSR ради «ускорения» первоначальной загрузки. Часто вместе с текстом через lazy-load отдают и изображения, включая главное фото товара.
Почему это критично
Такая архитектура влияет не только на индексируемость, но и на технические метрики сайта.
Индексация. Если контент появляется только после взаимодействия пользователя, например, после скролла или клика по вкладке, то поисковые роботы могут его просто не увидеть. Для Яндекса это особенно критично: робот не гарантирует выполнение сценариев, требующих действий пользователя, поэтому контент, которого нет в исходном HTML, с высокой вероятностью не попадет в индекс.
Google в подобных случаях может проиндексировать контент позже, при рендеринге. Но это означает задержку: страницы дольше появляются в поиске, а часть сигналов учитывается не сразу. В итоге оба поисковика могут видеть страницу в усеченном виде, что снижает ее оценку полезности.
Core Web Vitals. Подгрузка контента уже после отрисовки страницы часто приводит к сдвигам макета. Это напрямую ухудшает показатель CLS.
Отдельная распространенная ошибка – когда главное изображение страницы помечают атрибутом loading="lazy". В этом случае браузер откладывает его загрузку, из-за чего замедляется отображение ключевого элемента страницы и ухудшается метрика Largest Contentful Paint (LCP).

Пример: крупные изображения с атрибутом loading="lazy", показатель LCP плохой
Правильный подход
Чтобы избежать подобных проблем, важно правильно настроить работу ленивой загрузки. Lazy-load имеет смысл использовать только для тяжелого медиаконтента за пределами первого экрана, например, для изображений или видео. Текстовые блоки и коммерчески значимый контент должны сразу присутствовать в SSR-версии страницы.
Еще один важный момент – предотвращение сдвигов макета. Для этого место под изображения и другие элементы лучше заранее резервировать в CSS. Тогда при их загрузке страница не будет «прыгать», а показатели стабильности верстки останутся в норме.
- В SSR отсутствуют цена и CTA-кнопки
Суть ошибки
Цена, кнопки «Купить» и «В корзину» пустые или отсутствуют в SSR, так как подгружаются только после гидратации.
Почему это критично
Для Яндекса наличие цены и CTA – ключевые коммерческие сигналы. Их отсутствие снижает коммерческую релевантность, особенно по запросам «купить» и «цена».
Для Google отсутствие этих элементов ослабляет E-E-A-T факторы (Experience, Expertise, Authoritativeness, Trustworthiness). Поисковик хуже распознает сайт как надежный интернет-магазин.
В итоге страница теряет позиции в коммерческой выдаче, расширенный сниппет в Google по схеме https://schema.org/Product.
Правильный подход
Важно, чтобы ключевая коммерческая информация была доступна уже в SSR-версии страницы. Например, базовую цену товара лучше отдавать сразу в HTML, хотя бы в формате «от 10 000 руб.».
Кнопку «В корзину» также стоит включать в исходную разметку. Даже если до загрузки JavaScript она неактивна, сам элемент должен присутствовать в HTML – это помогает поисковым системам корректно распознавать коммерческую функцию страницы.
Дополнительно полезно добавлять микроразметку, например, Product и Offer, тоже на уровне SSR. Это упрощает поисковым системам интерпретацию данных о товаре и повышает шансы на корректное отображение страницы в поисковой выдаче.
- В SSR включается лишний, нерелевантный контент
Суть ошибки
В SSR-HTML автоматически вставляется объемный юридический или шаблонный текст в поп-апе, не связанный с основной темой страницы:
-
политика обработки персональных данных (полный текст на каждой странице);
-
пользовательское соглашение;
-
условия доставки, возврата, гарантии дублируются в полном объеме на всех карточках товаров.
Важно! Уведомления о cookie – исключение. Их наличие не вредит SEO, а скорее подтверждает соответствие требованиям прозрачности.
Почему это критично
Поисковики анализируют весь текст в HTML, включая скрытые блоки. Большой объем нерелевантного контента размывает текстовую релевантность страницы (например, «iPhone 15» теряется среди 2000 знаков о политике конфиденциальности), снижает долю уникального целевого текста, может повлиять на классификацию страницы как малополезной, особенно в Яндексе.
В итоге растет риск потери релевантности по целевым запросам, ухудшается ранжирование в конкурентных нишах.
Правильный подход
Полный текст юридических документов лучше размещать на отдельных страницах, а не выводить его в футере или модальных окнах на каждом URL. Это делает структуру сайта чище и не перегружает HTML лишним контентом.
Если модальное окно все-таки необходимо, его содержимое можно подгружать уже на стороне клиента. Главное – не включать такой контент в SSR, если он не несет SEO-ценности.
- Разные SSR-версии для Google и Яндекса: мобильная для Google, десктопная для Яндекса
Суть ошибки
Иногда команды пытаются «подстроить» сайт под разных поисковых роботов на уровне SSR. Например, при User-Agent Googlebot (mobile) сервер отдает мобильную версию страницы с бесконечной лентой и упрощенной навигацией. А при User-Agent YandexBot – десктопную, где есть пагинация и более полная структура ссылок.
На первый взгляд это выглядит как разумный компромисс: каждому поисковику показывается версия, которая лучше соответствует его особенностям. Но на практике такой подход приводит к тому, что фактически существуют две разные модели сайта. Это усложняет индексацию, диагностику ошибок и делает поведение страниц в поиске менее предсказуемым.
Почему это критично
Проблема в том, что в такой схеме поисковые системы начинают видеть разные версии сайта.
Google получает мобильную страницу, где может не быть привычных элементов навигации, например, ссылок на пагинацию, полной цепочки хлебных крошек или даже части товаров в каталоге. Яндекс, наоборот, видит десктопную версию с полной структурой разделов. Но при этом он не понимает, как сайт выглядит для пользователей со смартфонов, а именно мобильный трафик сегодня составляет большую часть поисковых переходов.
Из-за этого усложняется и технический аудит. Фактически приходится проверять не одну, а две разные SSR-версии сайта, отслеживая, как каждая из них отдается разным роботам.
Кроме того, появляется риск расхождений в индексации. Google может не увидеть часть ассортимента, а Яндекс – не учитывать реальные мобильные сценарии использования сайта.
В итоге разные SSR-версии под разных поисковиков превращаются в технический долг: поддержка становится сложнее, поведение сайта в поиске – менее предсказуемым, а риск потери трафика – выше.
Правильный подход
Лучше отдавать одну и ту же SSR-версию страницы для всех устройств и поисковых роботов, используя адаптивную разметку через CSS.
Также полезно периодически проверять сохраненные копии страниц в Google Search Console и Яндекс Вебмастере, чтобы убедиться, что ключевые элементы – цены, кнопки, навигация – присутствуют и индексируются корректно.
- Гидратация как источник «мерцания» контента
Суть ошибки
При использовании SSR сервер отдает готовую разметку с контентом. Однако при загрузке клиентского JavaScript начинается гидратация – процесс перехода от статичной страницы к динамической. Если она реализована некорректно, фреймворк сбрасывает состояние компонентов в «режим загрузки», и контент исчезает, сменяясь скелетонами. Затем, через несколько сотен миллисекунд, контент появляется снова.
Визуально это выглядит так:
-
пользователь видит контент;
-
страница «мигает»;
-
появляются скелетоны;
-
контент возвращается.

Почему это критично
Googlebot сегодня основан на Chromium и при рендеринге страниц фактически имитирует поведение обычного пользователя. Он фиксирует визуальные изменения на странице, измеряет Core Web Vitals в реальном времени и оценивает плавность загрузки как показатель качества. Другими словами, робот смотрит на сайт почти так же, как реальный пользователь, и учитывает это при ранжировании.

Результаты некорректной гидратации
Правильный подход
Некорректная гидратация – это не просто «косметический баг». Это прямой удар по метрикам качества, которые Google использует для ранжирования. Исправление этой ошибки улучшает одновременно и пользовательский опыт, и SEO-показатели.

- Отсутствие или ошибки в rel="canonical"
Суть ошибки
В SSR-версии страницы иногда отсутствует тег < link rel="canonical" >, либо он формируется некорректно, например, указывается относительный путь или появляется ошибка в URL при применении фильтров. В таких случаях поисковым системам сложнее понять, какая версия страницы считается основной.
Почему это критично
Поисковые системы полагаются на каноническую ссылку, чтобы отличать основную страницу от дублирующих, например, при фильтрах, сортировках или UTM-метках. Если тег < link rel="canonical" > отсутствует в исходном HTML, робот может проиндексировать альтернативную версию URL, что приводит к дублированию контента и снижает эффективность SEO.
Правильный подход
Тег < link rel="canonical" > должен присутствовать в секции < head > SSR-версии страницы. При этом важно использовать абсолютный URL, например, https://site.com/catalog, а не относительный путь.
Для главных страниц каждой версии канонический тег обычно ссылается на саму страницу. А для страниц с фильтрами или сортировками, где контент не уникален, canonical указывает на основную категорию. Такой подход помогает поисковикам правильно определять основную версию страницы и избегать проблем с дублирующимся контентом.
Как проверить SSR-верстку: четыре надежных способа
Способ 1: исходный HTML под User-Agent поисковика
Один из способов проверить, что SSR-страница корректно отдается поисковикам, – использовать исходный HTML под разными User-Agent. В Chrome DevTools это делается через вкладку Network:
-
Откройте меню ⋮ → More tools → Network conditions.
-
В разделе User agent снимите галочку Use browser default и вставьте нужный User-Agent:
-
Googlebot (смартфон):
Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) -
YandexBot:
Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)
-
Обновите страницу и в списке запросов выберите основной HTML-документ (совпадает с URL страницы).
-
На вкладке Response вы увидите чистый HTML, полученный от сервера без изменений со стороны JavaScript.
Проверьте, что в этом HTML присутствуют: ссылки < a href="…" > для навигации, цена, описание, кнопки действий, текст в FAQ, характеристиках и хлебных крошках.
Сравнивая ответы под разными User-Agent’ами, вы убедитесь, что структура страницы идентична для всех роботов и устройств – это ключевой момент для корректной индексации.
Способ 2: сохраненные копии в системах вебмастеров
Для проверки того, как поисковые системы видят страницу, можно использовать встроенные инструменты.
В Google Search Console откройте «Проверка URL» и выберите «Просмотреть протестированную страницу». В Яндекс Вебмастере используйте «Проверка страницы» и перейдите на вкладку «Версия страницы в поисковой базе».
Важно убедиться, что в обеих копиях присутствуют все ключевые элементы: навигация, цены, кнопки, тексты. Любые расхождения между версиями сигнализируют о возможной проблеме с SSR или подгрузкой контента.
Способ 3: Поиск по фрагменту контента
Чтобы проверить, что текстовый контент страницы действительно индексируется, можно воспользоваться поиском по уникальному фрагменту из описания товара, достаточно 5-7 слов.
Например:
-
По всему сайту: "уникальный фрагмент текста" site:example.com
-
По конкретной странице: "уникальный фрагмент текста" url:https://example.com/product/123 (URL должен быть в индексе).
Если поиск не возвращает результатов, то это сигнал, что контент может отсутствовать в SSR и не был проиндексирован поисковой системой.
Способ 4: Тест без JavaScript
В Chrome DevTools можно проверить, что важный контент доступен в SSR, даже если JavaScript отключен. Для этого:
-
Нажмите Cmd+Shift+P (Windows: Ctrl+Shift+P) и введите Disable JavaScript, затем выберите соответствующую опцию.
-
Обновите страницу.
Если страница при этом остается читаемой и навигируемой, значит, ключевой контент присутствует в SSR. Если же вместо описания и информации о товаре видна пустота, это сигнал, что SEO-значимый контент загружается только на клиенте и не попадает в исходный HTML.
Зачем нужно работать с SSR: реальные кейсы
Кейс 1
Значимая часть контента карточки товара отсутствовала в SSR и не попадала в HTML, который получал поисковый робот. В результате поисковик не видел ряд ключевых элементов страницы:
-
отзывы о товаре;
-
подробную информацию о действующей скидке или акции;
-
кнопку «Добавить в корзину»;
-
блок с условиями доставки;
-
товарные рекомендации («Вас может заинтересовать»).
После исправления позиции улучшились.



Трафик без бренда
Кейс 2
Цены в каталоге и кнопка «В корзину» в SSR отсутствовали, подгружаясь только на клиенте.
После исправления позиции в Яндексе выросли.

Кейс 3
Часть перелинковки на подборки была скрыта под кнопкой «Показать еще» и не подтягивалась в SSR.
После добавления ссылок из перелинковки в SSR-версию позиции страниц подборок выросли.

Кейс 4
В хлебных крошках не выводилась вся цепочка навигации, только ссылка на страницу «Каталог».
После исправления видимость категорий выросла и в Яндексе, и в Google.

Рост позиций в Яндексе

Рост позиций в Google
Кейс 5
Товарные блоки рекомендаций «Похожие товары» и «Покупают вместе» не индексировались.
После вывода блоков в SSR позиции выросли и в Яндексе, и в Google.

Рост позиций в Яндексе

Рост позиций в Google

Рост трафика из Поиска
Кейс 6
Меню не подгружалось в SSR.
Видимость в Яндексе улучшилась после настройки индексации меню.

Рост позиций в Яндексе
SSR в e-commerce: не формальность, а точка риска
SSR – это не «галочка» в чеклисте. Это ответственность за HTML, который получает поисковик.
Для e-commerce в России SSR должен быть:
-
полным (все ключевые элементы – в HTML);
-
семантически корректным (ссылки – через < a >);
-
единым для всех устройств;
-
чистым от нерелевантного контента.
Если вы продаете в РФ – не ориентируйтесь только на Google. Яндекс по-прежнему требует «честного» HTML. И если ваша SSR-верстка нарушает хотя бы одну из описанных выше проблем, то вы теряете трафик, конверсии и… деньги.

Есть о чем рассказать? Тогда присылайте свои материалы Марине Ибушевой




