JavaScript SEO: убедитесь, что ссылки сохраняются при рендеринге

Google рендерит JavaScript с помощью актуальной версии Chromium. Проблема редко заключается в самом процессе рендеринга. Чаще всего ссылки так и не становятся кликабельными якорями, а страницы зависят от состояния, которого нет у поискового робота.

Исследовательская команда ArchiLinks · Обновлено 2026-10-29

Мост, соединяющий каменные фундаменты со стеклянными конструкциями, символизирующий сохранение ссылок

Что видит робот

Googlebot использует актуальную версию Chromium с мая 2019 года. Это окончательно решило вопрос о том, способен ли он выполнять современный JavaScript.

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

SSR, SSG, CSR: что меняется для ссылок

Подход	Контент в первом ответе	Внутренние ссылки как якоря	Подходит для
SSR (Next.js, Nuxt)	Да	Да, если используются настоящие якорные теги	Публичные страницы с изменяющимися данными
SSG или пререндеринг	Да	Да	Документация, блоги, маркетинговые страницы
CSR одностраничное приложение	Нет, пустая оболочка	Только после рендеринга	Панели управления за входом в систему
Гибридная (SSR для главной, CSR для приложения)	Для каждого маршрута	Для каждого маршрута	Большинство продуктов с публичной частью

Тест один: сырой HTML против рендеринга HTML

Если ключевые ссылки появляются в первом ответе, вопрос закрыт. Если нет — сравните с headless-рендерингом.

bash

# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20

# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '

Садовник, осматривающий корни деревьев, символизирующий проверку здоровья внешних обратных ссылок

Откуда берутся внешние ссылки

Ошибка рендеринга скрывает ваш контент. Она не удаляет ссылки, которые другие сайты уже поставили вам.

После перехода на Next.js, Vite или headless-CMS запустите toppages для хоста и проверьте статус, канонические URL и видимый контент 20 самых ссылочных страниц. Сделайте это в первую очередь. Если страница с 40 ссылочными доменами возвращает пустую оболочку или клиентский 404, исправьте это в первую очередь, ведь именно сюда переходит ваш авторитет. Страница внутренний и внешний вес ссылок показывает, как сравнить этот список с вашими внутренними ссылками, а чек-лист миграции включает проверку в план запуска.

Фреймворки важнее дисциплины. Express с шаблонизатором, тема WordPress и роутер приложений Next.js могут обслуживать ссылки, доступные для краулинга. Каждый из них также может дать сбой, если команда выпустит якоря, которые появляются только после клика.

Чек-лист по ссылкам и рендерингу

Навигация и пагинация используют <a href>, а не обработчики кликов на других элементах.
Каждый маршрут возвращает реальный код состояния. Страницы с мягким 404 должны возвращать код 404.
Тег noindex или каноническая ссылка, добавленные через JavaScript, должны совпадать с теми, что возвращает сервер.
Контент в первом ответе должен быть реальным содержимым страницы, а не спиннером загрузки, который Google может проиндексировать.
Код авторизации не должен перенаправлять краулеров на публичных маршрутах.
Файлы CSS и JS, необходимые для рендеринга, не должны быть заблокированы в robots.txt.
Ленивая загрузка использует IntersectionObserver или нативные атрибуты загрузки, а не события прокрутки.

Анализ данных Search Console

Search Console отвечает на большинство вопросов по рендерингу, если выбрать правильный отчет. Используйте инструмент «Проверка URL», затем «Просмотреть проиндексированную страницу».

Сравните три вещи: HTML, который получил Google, скриншот и ресурсы страницы, которые не загрузились. Страница, которая выглядит полной в вашем браузере, но пустой на скриншоте, обычно заблокирована ошибкой скрипта или запрещенным ресурсом, и решение проблемы находится в вашем билде, а не в контенте.

Учитывайте задержку. Изменение, которое вы публикуете сегодня, появится в инструменте проверки только после того, как Google повторно обойдет URL, что может занять несколько дней.

Когда SSR действительно оправдан

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

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

Используйте тест Rich Results и URL Inspection для сравнения результата рендеринга.
Тестируйте с помощью инструмента Live Test в Search Console после каждого обновления фреймворка.

Два дома на холме, показывающие пререндеринг против клиентского рендеринга

Необходим ли серверный рендеринг, или достаточно пререндеринга?

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

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

Пререндеринг только главной страницы

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

Ведите краткий список публичных маршрутов с указанием метода рендеринга. Этот список покажет пробелы быстрее, чем отчет об обходе.

Влияет ли серверный рендеринг на локальную видимость

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

Рассматривайте рендеринг как способ сделать эти сигналы читаемыми для робота, а ссылки измеряйте отдельно через API.

Приложения Vite и React, отдающие один shell

Сборка Vite, которая отдает один HTML-shell для каждого пути, переносит всю работу на клиент. Такое приложение все еще может ранжироваться по некоторым запросам, но для каждого публичного маршрута нужен план: прорендерить его, отдать на сервере или принять потери и зафиксировать это решение.

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

Проверка отображения ссылок на маршруте

Два теста отвечают на большинство вопросов. Сырой ответ показывает то, что получает робот до выполнения скриптов. Отрендеренный DOM показывает то, что строит браузер после. Ссылка, появившаяся только во втором случае, все еще является ссылкой, но она зависит от успешности рендеринга.

Чтение результата Live Test в Search Console

Запускайте Live Test из URL Inspection по одному маршруту за раз. Посмотрите на отрендеренный HTML, затем на список ресурсов, которые не удалось загрузить. Заблокированный скрипт может удалить целый блок навигации, и страница будет выглядеть пустой без видимых ошибок.

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

Когда маршрут рендерится, но контент — это спиннер

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

Фоллбэк, являющийся реальной страницей, может оставаться простым. Его единственная задача — удерживать контент до загрузки остальной части.

Перенос клиентского сайта без потери ссылок

Список маршрутов с внешними ссылками

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

Сравнение сырого и отрендеренного вывода

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

Замена обработчиков кликов на якоря

Превратите навигацию в настоящие якоря с правильным адресом. Оптимизация скорости может подождать спринт, а отсутствие якоря обойдется маршруту его пути в структуре сайта.

Повторение теста после релиза

Через неделю после релиза запустите Live Test на тех же маршрутах и сравните результаты с предыдущими. Различия покажут, где пересборка изменила вывод.

Коды состояния и редиректы в клиентском приложении

Одностраничное приложение часто показывает экран «не найдено», в то время как сервер возвращает статус 200. Google может расценить такую страницу как мягкий 404, и внешние ссылки, ведущие на отсутствующий URL, будут мало полезны. Исправление должно быть на стороне сервера.

Неизвестные маршруты, возвращающие 200

Возвращайте реальный 404 с сервера для любого несуществующего маршрута и оставляйте экран «не найдено» внутри приложения для посетителей, пришедших по клиентскому маршруту. Если существует замена, отправляйте 301.

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

Редиректы, срабатывающие в браузере

Редирект, срабатывающий после загрузки страницы (например, при чтении параметра URL внутри компонента), — это не то же самое, что серверный редирект. Робот может проиндексировать первый ответ до срабатывания редиректа. Если маршрут перемещен навсегда, возвращайте 301 с сервера и сохраняйте параметры, влияющие на контент. Рецепт карты редиректов показывает, как тестировать эти правила.