JavaScript SEO
По данным исследования Ahrefs, 26% из топ-100 сайтов используют JavaScript как основной способ рендеринга. Но не все индексируются Google одинаково хорошо. Это главная проблема, которую разбирает данная статья.

Партнёры

Как Google индексирует JavaScript
Googlebot, поисковый робот Google, индексирует веб-страницы в два этапа. На первой волне робот получает HTML-ответ сервера и сразу анализирует его содержание. Если весь необходимый контент уже в HTML, индексация завершается после первого краула. Но когда содержимое генерируется клиентским JavaScript, запускается вторая волна обработки. Googlebot запускает браузер на основе Chromium, выполняет скрипты, ждёт загрузки данных. Это куда более медленный и затратный процесс.
Вот почему между первой и второй волной возникает задержка индексации. Google может обнаружить страницу на первой волне — увидеть ссылку в HTML, — но не получить её контент. Страница попадает в знакомый статус "Обнаружено, но не проиндексировано" в Google Search Console. Это не ошибка кода разработчика, а следствие архитектурного решения. Если контент полностью генерируется JavaScript, поисковый робот ждёт завершения второй волны рендеринга.
Google значительно улучшила поддержку JavaScript, но это не полное решение проблемы. Googlebot работает в очереди обработки: миллионы страниц ждут краула, вторая волна может отодвинуться на дни или недели. Несоответствия между браузером и рендерером Google тоже частое явление. Время рендеринга критично: если страница загружается свыше трёх секунд, Google может не дождаться готового контента для индексации.
Примеры: YouTube и Netflix правильно интегрируют JavaScript с учётом индексации в поисковых системах. YouTube рендерит основной контент на сервере (SSR), интерактивность добавляет клиентский JavaScript. Netflix применяет Server-Side Rendering для SEO, Progressive Web App для приложения. Простое SPA приложение без SSR теряет органический трафик. Это не недостаток JavaScript, а особенность архитектурного подхода.
Методы рендеринга и SEO требования
Существует три основных метода отправки контента в браузер. Client-Side Rendering означает, что сервер отправляет пустой HTML, весь контент рисует JavaScript на клиенте. Server-Side Rendering готовит HTML на сервере, браузер получает полностью готовую страницу. Static Site Generation генерирует HTML при сборке проекта и раздаёт готовые файлы с CDN. YouTube и Netflix используют все три в комбинации: SSR для первого просмотра, CSR для интерактивной навигации внутри приложения. Выбор архитектуры определяет, сможет ли Google правильно индексировать ваш контент.
На практике выбор критичен для SEO. CSR требует от Google дополнительное время на рендеринг JavaScript, SSR отдаёт готовый контент сразу, SSG раздаёт статические файлы без обработки сервером. Core Web Vitals напрямую зависят от метода рендеринга — CSR часто медленнее. Но не переписывайте всё на Server-Side Rendering просто так. Для маломеняющегося контента подойдёт Static Site Generation. Для динамических сайтов и SPA используйте гибридный подход или оптимизированный CSR.


Инструменты проверки и мониторинга
По данным Ahrefs, 26% топ-100 сайтов используют JavaScript основным методом рендеринга. Узнать, правильно ли Google их индексирует, помогает диагностика. Если видели 'Обнаружено, но не проиндексировано' в Google Search Console — знаете эту боль. Lighthouse встроен в DevTools браузера и показывает SEO score. Google Search Console выявляет, как поисковик индексирует ваш сайт и на что обращает внимание при обходе.
Мониторинг начинается с регулярных проверок. Core Web Vitals смотрите в PageSpeed Insights и Chrome UX Report — это реальные данные от пользователей, а не имитация. Еженедельный запуск Lighthouse ловит регрессии быстро. Для SEO-специалистов полезны Screaming Frog с поддержкой JavaScript рендеринга и техаудит в SEMrush. Настройте алерты в Google Search Console на изменения индексации.
Оптимизация популярных фреймворков
Диагностика выявила проблемы — теперь нужно выбрать, как их решать. Выбор фреймворка определяет, насколько SEO-дружественной будет архитектура изначально. Next.js, Vue с Nuxt, Angular — каждый решает SEO-задачи по-разному. Если используешь React в Create React App, столкнёшься, что это CSR по умолчанию, и Google индексирует медленнее. Переход на Next.js или полное переписывание конфигурации — боль. Лучше выбрать правильный инструмент с самого начала.
Next.js из коробки решает все SEO-проблемы напрямую. Server-Side Rendering через getServerSideProps отправляет в браузер готовый HTML — Google видит весь контент сразу и не дожидается JavaScript загрузки. Static Generation с getStaticProps рендирует один раз при сборке и кешируется на CDN для максимальной скорости. Incremental Static Regeneration обновляет страницы в фоне без простоев. Мета-теги и структурированные данные легко настраиваются в конфигурации или компонентах.
React с Create React App этого не имеет. Стандартная настройка рендирует всё в браузере, и Google видит пустую страницу до загрузки JavaScript. Решения есть: либо добавлять скрипты предрендеринга вроде react-snap, но это костыль. Либо мигрировать на Next.js, что сразу даёт SSR и SSG. Третий вариант — вообще выбрать другой стек. Если SEO критичен, CRA + React это неправильный выбор архитектуры. Лучше сделать правильный ход сразу.
Vue с Nuxt открывает те же возможности SSR и SSG как Next.js, но для экосистемы Vue. Angular встраивает Server-Side Rendering через @angular/platform-server, но сам фреймворк тяжелее и требует больше кода. Vue и Nuxt обычно легче и проще. Главное при выборе — SSR должен быть встроен или легко настраивается. Остальное вторично. Опыт команды часто важнее, чем мода на новый фреймворк.
- Настраивай title и meta-теги в _document и _app или в конфигурации фреймворка один раз для всех страниц.
- Проверь, используя View Page Source, что критичный контент рендирится на сервере, а не только в браузере при инициализации.
- Выбирай фреймворк с встроенным SSR изначально, а не пытайся натянуть эту архитектуру на уже готовое CSR приложение позже.
Checklist и часто задаваемые вопросы
Чек-лист для junior разработчика
Начните с проверки перелинковки и sitemap.xml. Убедитесь, что мета-теги title и description рендирятся на сервере, а не в браузере. Запустите Lighthouse и проверьте исходный код: там должен быть весь контент, а не только после загрузки JavaScript.
Чек-лист для SEO специалиста
Используйте инструмент GSC Inspection, чтобы проверить исходный код в глазах Google. Сравните то, что видно в браузере, с тем, что видно в поиске — разница может быть значительной при JavaScript SEO. Мониторьте Core Web Vitals; низкие LCP, FID, CLS быстро разрушают ранжирование.
Чек-лист для tech-lead
Выберите архитектуру (CSR, SSR или SSG) исходя из требований бизнеса и пользователей. Включите SEO best practices в требования разработки с первого дня. Настройте мониторинг Core Web Vitals и GSC. Это не конфликт JavaScript и SEO, это результат правильной архитектуры.