JavaScript SEO

Основание определения — руководство Google Search Central: оно рассматривает обработку JavaScript через сканирование, рендеринг и индексирование, а также доступность ссылок и ресурсов. Это описание Google, а не универсальная спецификация всех поисковиков. ^[1]

Кратко

Найденный адрес, загруженная страница и страница в поиске — разные результаты. ^[1]
Кнопка с действием не заменяет обычную ссылку с адресом. ^{[1, 2]}
Серверная подготовка HTML может сочетаться с интерактивностью в браузере. ^[3]
Проверка Google не заменяет проверку Яндекса: настройки и способы обработки различаются. ^{[1, 2]}

Происхождение и история термина

Развитие JavaScript SEO связано с проблемой содержимого, которое появляется после выполнения программы. В 2009 году Google предложил специальную схему обхода AJAX-сайтов — страниц с динамически создаваемым содержимым: тогда его системы не могли полноценно обрабатывать такие страницы. В октябре 2015 года Google перестал рекомендовать прежнюю схему, объяснив это развитием рендеринга и предложив ориентироваться на доступность содержимого и обычные адреса. ^[6]

В мае 2019 года Google объявил переход Googlebot на регулярно обновляемый движок Chromium — программную основу браузерного рендеринга. Это расширило поддержку возможностей веба, но ограничения остались. ^[7] Так задача изменилась: вместо подготовки специальной копии только ради старой схемы обхода разработчики стали проверять, какие данные действительно получает и обрабатывает поисковая система. Эти события описывают развитие практики, а не устанавливают дату появления названия JavaScript SEO.

Суть и механизм

Обнаружение — получение адреса страницы, например из ссылки. Сканирование — запрос этого адреса роботом и получение ответа сервера. Рендеринг — построение документа с выполнением необходимого JavaScript. Индексирование — обработка содержимого для поискового индекса; успешная загрузка ещё не равна включению в него. Google обнаруживает ссылки как в исходном, так и в отрендеренном HTML. ^[1]

HTML — разметка страницы. Если сервер прислал только оболочку приложения, основной текст ещё нужно получить и вставить программой. Google помещает страницы в очередь рендеринга; мгновенного выполнения не обещает. Запрет обхода в robots.txt может помешать загрузке страницы или необходимых файлов. Исходный запрет индексирования noindex также важен: Google может пропустить рендеринг, поэтому рассчитывать на последующее удаление запрета JavaScript-кодом нельзя. ^[1]

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

Виды и классификации

Архитектурные подходы ниже даны в терминологии Addy Osmani и Jason Miller из web.dev. Это способы формирования страницы, а не категории её качества в поиске. ^[3]

Подход	Где появляется HTML	Что проверять в конкретной реализации
SSR, серверный рендеринг	Сервер формирует HTML и отправляет клиенту	Содержит ли ответ основной текст
CSR, клиентский рендеринг	JavaScript в браузере изменяет документ	Доступны ли код и данные для создания текста
Пререндеринг при сборке	Начальное состояние приложения заранее сохраняется как HTML	Попали ли нужные данные в сохранённый результат

Гидратация добавляет состояние приложения и интерактивность к серверному HTML. Например, читатель может получить текст до того, как заработают элементы управления. Сам термин не обещает ни быстрого ответа сервера, ни полного содержимого: web.dev разбирает отдельные компромиссы производительности каждого подхода. ^[3]

Конкретное ограничение показывает React: его метод renderToString возвращает строку HTML и не ждёт загрузки данных. Если компонент приостанавливается, метод выдаёт резервное содержимое — например, сообщение об ожидании. Это свойство указанного метода, а не всех способов серверного рендеринга. ^[4]

Как применяется на практике

Учебный пример: новостной сайт отправляет заголовок и сообщение «Загрузка…», а текст запрашивает отдельно. У разработчика новость открывается из ленты благодаря сохранённым данным приложения. Прямое открытие адреса в новых условиях оставляет только сообщение. Для Google такой риск существенен: служба рендеринга WRS не сохраняет cookies и локальное хранилище между загрузками страниц. ^[8] Поэтому приёмку начинают с прямого адреса и выясняют, откуда должен прийти текст.

Другой учебный пример: карточка новости открывается обработчиком нажатия, но в разметке отсутствует ссылка. Для обнаружения адреса Google рекомендует элемент a с атрибутом href; Яндекс также показывает навигацию через href и History API, позволяющий менять адрес без полной перезагрузки. Маршрут вида #/news не следует считать заменой обычному адресу новости. ^{[1, 2]}

Для сайта, ориентированного на российскую аудиторию, важны самостоятельные настройки Яндекса:

Вопрос	Google	Яндекс
Решение о выполнении JavaScript	Описывает очередь рендеринга. ^[1]	По умолчанию оставляет решение роботу; настройка доступна в Вебмастере. ^[2]
Диагностика	URL Inspection и Rich Results Test показывают результат рендеринга. ^[8]	В справке описан раздел «Рендеринг страниц JavaScript β». ^[2]
Задержанная загрузка	Не следует полагаться на состояние предыдущей страницы. ^[8]	Документированы специальные настройки ожидания загрузки. ^[2]

Настройки ожидания Яндекса не являются инструкциями для Google. Справка Яндекса отдельно предупреждает о дополнительной нагрузке при исполнении кода и рекомендует отключать рендеринг при реализованном SSR или пререндеринге. ^[2] Для редакционной проверки это повод прежде сравнить полноту получаемого HTML.

Как измерить или проверить

Предлагаемая процедура начинается с ожидаемого результата: для новости это её заголовок, текст и ссылки; для отсутствующего материала — корректная обработка отсутствия. Затем проверяют ответ сервера, загрузку данных и итоговый документ. В Chrome DevTools панель Network записывает запросы, пока открыта. После перезагрузки страницы можно изучить статус ответа, его содержимое во вкладке Response и инициатора запроса — код, который вызвал загрузку. ^[5]

Очистка кеша с принудительной перезагрузкой помогает проверить загрузку ресурсов заново; ограничение скорости соединения позволяет увидеть поведение при медленной передаче. ^[5] Эти действия исследуют браузерную загрузку. Следующий шаг — проверка конкретного URL средствами нужного поисковика. Для Google доступны отрендеренный документ, загруженные ресурсы и ошибки JavaScript. ^[8] В протоколе редакция предлагает записывать адрес, дату, инструмент, ожидаемый текст и найденное расхождение.

Учебный расчёт приёмки: выбраны 20 адресов разных шаблонов, на 16 итоговый документ содержит весь заранее перечисленный основной текст. Доля прошедших эту проверку равна 16 / 20 × 100 = 80 %. Числитель — прошедшие адреса, знаменатель — все проверенные адреса. Это показатель выбранной выборки, а не доля всего сайта в индексе или прогноз позиций. Если адресов нет, доля не определена; записывать ноль процентов ошибочно.

Ошибки, ограничения и спорные вопросы

Одна из ошибок — отправлять успешный HTTP-ответ для несуществующей страницы приложения. Google называет ситуацию с сообщением об отсутствии при успешном статусе мягкой ошибкой 404 и описывает способы её обработки. ^[8] Поэтому удалённый материал включают в проверку отдельно от работающей новости.

Другая ошибка — требовать для получения текста возможности, которой нет у робота. Googlebot отклоняет запросы разрешений пользователя, например доступа к камере; его получение содержимого не поддерживает WebSocket-соединения, поэтому документация рекомендует доступ через HTTP. ^[8] Из этих ограничений нельзя выводить свойства Яндекса или любого другого робота.

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

Частые вопросы

Нужно ли убирать JavaScript?

Нет: проверяют доступность содержимого и адресов. Сама возможность исполнения кода предусмотрена документацией Google и Яндекса. ^{[1, 2]}

Обязателен ли SSR?

Это один из подходов. Важно проверить результат выбранной реализации; пример renderToString показывает, почему одного названия недостаточно. ^{[3, 4]}

Достаточно ли открыть страницу у себя?

Нет. Личные сохранённые данные могут скрыть зависимость, которая проявится при отдельной загрузке роботом Google. ^[8]

Успешный рендеринг гарантирует индексирование?

Нет. Это разные этапы обработки страницы; проверять поисковое состояние нужно отдельно. ^[1]

Решить с помощью сервиса

«SEO-проверка» проверяет доступность страницы, метатеги, H1 и скорость загрузки. Инструмент работает внутри холдинга и готовится к открытию внешним пользователям; эти проверки не заменяют исследование отрендеренного HTML поискового робота.

Сервисы MEDIATRONE →

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

Источники

Google. (2026, March 4). Understand the JavaScript SEO basics. Google Search Central. https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics (дата обращения: 30.10.2026). ↑ а б в г д е ж з и к
Яндекс. Индексирование AJAX-сайтов; Индексирование страниц с JavaScript β // Справка Вебмастера. Б. д. URL: https://yandex.ru/support/webmaster/ru/robot-workings/ajax-indexing ; https://yandex.ru/support/webmaster/ru/yandex-indexing/rendering (дата обращения: 30.10.2026). Два раздела одной работы. ↑ а б в г д е ж з
Osmani, A., & Miller, J. (2019, February 6; updated 2026, January 5). Rendering on the web. web.dev. https://web.dev/articles/rendering-on-the-web (дата обращения: 30.10.2026). ↑ а б в г
React. (n.d.). renderToString. React documentation. https://react.dev/reference/react-dom/server/renderToString (дата обращения: 30.10.2026). ↑ а б
Basques, K. (2024, October 14). Inspect network activity. Chrome DevTools documentation. https://developer.chrome.com/docs/devtools/network/ (дата обращения: 30.10.2026). ↑ а б
Nagayama, K. (2015, October 14). Deprecating our AJAX crawling scheme. Google Search Central Blog. https://developers.google.com/search/blog/2015/10/deprecating-our-ajax-crawling-scheme (дата обращения: 30.10.2026). Исторический первоисточник. ↑
Splitt, M. (2019, May 7). The new evergreen Googlebot. Google Search Central Blog. https://developers.google.com/search/blog/2019/05/the-new-evergreen-googlebot (дата обращения: 30.10.2026). Исторический первоисточник. ↑
Google. (2025, December 18). Fix Search-related JavaScript problems. Google Search Central. https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript (дата обращения: 30.10.2026). Раздел того же руководства, что источник 1. ↑ а б в г д е ж