JavaScript сам по себе не мешает SEO. Google выполняет JavaScript с помощью современного Chromium, но между получением HTML и появлением итогового документа в индексе есть отдельная стадия рендеринга. Поэтому для JS-сайта важно проверить не только «открывается ли страница в браузере», но и что именно видит поисковый робот до и после выполнения скриптов.
Старые семь советов из этого материала были основаны на рекомендациях Martin Splitt. Ниже — актуализированная версия с учётом современной документации Google Search Central.
1. Понимайте цепочку crawl → render → index
Google описывает обработку JavaScript в три этапа: crawling, rendering и indexing. Сначала Googlebot получает URL и исходный ответ сервера, затем страница может попасть в очередь рендеринга, после чего поисковая система анализирует итоговый HTML.
Практический вывод: исходный HTML и rendered DOM могут сильно различаться, и оба состояния полезно проверять.
2. SSR, SSG, ISR и CSR — это не «хорошо» и «плохо»
Серверный или статический рендеринг обычно упрощает обнаружение контента: текст, ссылки и метаданные приходят сразу. Client-side rendering тоже может индексироваться Google, если ресурсы доступны и приложение корректно отрабатывает.
Выбор архитектуры лучше делать по совокупности требований: скорость, кеширование, персонализация, сложность разработки, стоимость инфраструктуры и требования поисковых систем. Важнее результата рендера, чем ярлыка SSR или CSR.
3. Не блокируйте ресурсы, нужные для рендеринга
Если JavaScript или CSS, без которых формируется основной контент, закрыты в robots.txt, поисковик может увидеть неполную страницу. Проверяйте правила robots.txt и сетевые запросы, от которых зависит основной документ.
4. Делайте ссылки crawlable
Для внутренней навигации безопасная база — обычная ссылка <a href="...">. Google умеет обнаруживать ссылки, добавленные JavaScript в DOM, но они всё равно должны формироваться как crawlable links с реальным href.
Кнопка с обработчиком onclick, которая только программно меняет экран, не всегда является полноценной заменой внутренней ссылке.
5. Контролируйте Title, Description и canonical
В SPA метатеги часто меняются на клиенте. Проверьте, что после перехода на каждую индексируемую страницу сформированы правильные title, description и canonical, и что они относятся именно к текущему URL.
Если сервер уже отдаёт конечные метатеги, это обычно проще для диагностики. Если они выставляются JavaScript — обязательно смотрите rendered HTML инструментами поисковой системы.
6. HTTP-статус остаётся важным
SPA может визуально показать «страница не найдена», но сервер при этом вернёт HTTP 200. Это создаёт soft 404 и усложняет обработку URL.
Для несуществующих документов нужен корректный 404/410 или иная архитектура, которая однозначно сообщает поисковику статус. При миграции URL используйте серверные редиректы, если это возможно. Подробнее — в материале про 301, 302, 307 и 308.
7. Не прячьте важный контент за пользовательским действием
Google может выполнить JavaScript, но не обязан нажимать кнопки, прокручивать интерфейс как человек или заполнять форму. Если основной текст загружается только после клика «показать», робот может его не получить.
Accordion или tab сами по себе нормальны. Важно, чтобы содержимое было частью страницы и не использовалось для манипулятивного скрытия. Об этом подробнее в статье про скрытый текст.
8. Lazy loading должен работать без робота-пользователя
Ленивая загрузка изображений и блоков экономит ресурсы, но не должна зависеть только от действий, которые crawler не воспроизводит. Проверьте, что контент появляется при рендеринге и что изображения имеют нормальные URL и alt.
9. Structured data проверяйте после рендеринга
JSON-LD можно добавлять JavaScript, но важен итоговый rendered документ. Разметка должна описывать видимый контент и не расходиться с ним. Для статей полезно отдельно проверить Article/BlogPosting, автора и даты — см. руководство по Article.
10. Не используйте hash как замену индексируемому URL
Состояния интерфейса вида /catalog#item удобны внутри приложения, но самостоятельному поисковому документу лучше иметь собственный обычный URL. History API позволяет менять путь без полной перезагрузки страницы, но URL всё равно должен корректно открываться напрямую с сервера.
11. Проверяйте rendered HTML, а не только исходный код
Минимальная диагностика:
- открыть исходный HTML и сравнить его с DOM после выполнения JavaScript;
- проверить URL в Google Search Console;
- посмотреть title, canonical, structured data и основной текст в rendered version;
- убедиться, что внутренние ссылки имеют
href; - проверить HTTP status;
- проверить robots.txt и загрузку JS/CSS;
- посмотреть ошибки JavaScript и сетевые запросы.
12. Dynamic rendering — не стратегия на годы
Схема, когда пользователю отдаётся клиентское приложение, а роботу — отдельная предварительно отрендеренная версия, использовалась как workaround для сложных JavaScript-сайтов. Для новой разработки лучше стремиться к архитектуре, где поисковик и пользователь получают один логически одинаковый документ без отдельной «версии для роботов».
Google — не единственный потребитель сайта
Даже если Google умеет рендерить современный JavaScript, другие поисковые, социальные и AI-боты могут обрабатывать страницы иначе. Поэтому наличие meaningful HTML до сложного клиентского исполнения часто полезно не только для классического SEO, но и для устойчивости сайта в целом.
Чек-лист JavaScript SEO
- каждый индексируемый URL открывается напрямую;
- сервер отдаёт осмысленный HTTP status;
- основной текст есть в rendered HTML;
- внутренние ссылки — настоящие
<a href>; - title/description/canonical относятся к текущему URL;
- JS/CSS, нужные для контента, не заблокированы;
- lazy loading не скрывает основной контент от crawler;
- structured data совпадает с видимой страницей;
- 404 и редиректы обрабатываются технически корректно;
- результат проверен инструментами поисковой системы.
Официальная база для проверки — JavaScript SEO basics в Google Search Central.
Обновлено: 04.10.2026 4961