JavaScript SEO и рендеринг

JavaScript SEO и рендеринг — это вопрос о том, видит ли Google содержимое страницы, которое появляется только после выполнения скриптов. Короткий ответ документации: да, Google запускает JavaScript в актуальной версии Chromium, но у этого процесса есть этапы и условия, от которых зависит результат. Нередко пишут, что Google «возвращается через несколько дней» и что нужен конкретный фреймворк, но таких утверждений в документации нет. Здесь — только то, что в ней описано, и конкретные проверки.

Основа — руководство Google по основам JavaScript SEO и справка по поиску и исправлению проблем.

Три этапа: обход, рендеринг, индексирование

Google обрабатывает JavaScript-приложения в три этапа, и Googlebot ставит страницы в очередь и на обход, и на рендеринг:

1. Обход. Googlebot берёт URL из очереди, сначала проверяет robots.txt. Если URL запрещён, запрос не выполняется, а скрипты из заблокированных файлов и со страниц, закрытых от обхода, Google не рендерит. Затем он ищет ссылки в атрибутах href получившегося HTML;
2. Рендеринг. Все страницы с кодом ответа 200 попадают в очередь рендеринга, независимо от того, есть ли на них JavaScript, кроме тех, где метатег или заголовок robots запрещает индексирование. Страница может ждать несколько секунд, но может и дольше. Когда ресурсы позволяют, браузер без интерфейса выполняет скрипты. Для ответов не 200, например страниц ошибок, рендеринг может быть пропущен;
3. Индексирование. Google использует отрисованный HTML для индексирования и повторно извлекает из него ссылки.

Документация добавляет: серверный рендеринг или предварительный рендеринг остаётся отличной идеей, потому что делает сайт быстрее для пользователей и краулеров, а не все боты умеют выполнять JavaScript.

Способы отдать контент

Google называет три рекомендуемых решения: серверный рендеринг, статический рендеринг и гидратацию. Дополнительно: динамический рендеринг был обходным решением, а не долгосрочным, а вместо него рекомендованы три решения выше. Нередко такие способы ранжируют: SSG и ISR «отлично», клиентский «рискованно». Этих оценок в документации нет, а клиентский рендеринг сам по себе не запрещён: Google видит такой контент вместе с остальным HTML. Критично, чтобы нужное было доступно в итоговой странице и следовало правилам ниже.

Правила для JavaScript-сайтов

• Ссылки. Google находит ссылки только в элементах a с атрибутом href. Внедрять ссылки в DOM скриптом можно, если они соответствуют правилам доступных для обхода ссылок. Подробнее — в уроке про поиск и навигацию и странице о ссылках;
• История браузера вместо фрагментов. В одностраничных приложениях маршрутизируйте через History API: адреса с фрагментом после решётки Googlebot не разрешает надёжно;
• Title и description. Их можно задавать и менять скриптом; они должны быть уникальными и описательными;
• Canonical. Лучше задавать в HTML. Скриптом можно, но нельзя менять его на другой URL по сравнению с исходным HTML; если в HTML задать нельзя, оставьте его там пустым и задайте только скриптом, и убедитесь, что элемент один. Подробнее — в уроке про canonical;
• Коды ответа. Используйте осмысленные коды: 404 для ненайденной страницы, 401 для страниц за входом, перенаправления для переехавших;
• Структурированные данные. JSON-LD можно генерировать и внедрять скриптом; обязательно проверяйте результат. См. урок про структурированные данные;
• Кэширование. Google кэширует агрессивно и может игнорировать заголовки кэширования, из-за чего использует устаревшие JavaScript и CSS. Решение — в имя файла включают отпечаток содержимого, например main.2bb85551.js.

Ловушки robots meta

Скриптом можно добавить метатег robots или изменить его. Но когда Google встречает noindex, он может пропустить рендеринг и выполнение JavaScript, поэтому изменение или удаление noindex скриптом может не сработать. Если страница должна индексироваться, не ставьте noindex в исходный HTML. Это же правило объясняет ещё одну ловушку, описанную в уроке про robots.txt и meta robots.

Мягкая 404 в одностраничном приложении

При клиентской маршрутизации серверный код ответа часто невозможен. Чтобы страницы ошибок не стали soft 404, Google предлагает два способа: перенаправить скриптом на URL, для которого сервер отвечает 404, или добавить на страницу ошибки noindex. О кодах и перенаправлениях — в уроке про редиректы.

Как проверить

1. В Search Console откройте проверку URL или Rich Results Test: видно загруженные ресурсы, вывод консоли JavaScript, исключения и отрисованный DOM.
2. Сравните это с HTML, который отдаёт сервер: наши анализатор страницы и краулер читают именно ответ сервера и скрипты не выполняют. Если важный текст, ссылки или canonical есть только в отрисованном виде, это зависимость от рендеринга.
3. Проверьте, что меню и ссылки — элементы a с href, а не обработчики событий.
4. Убедитесь, что скрипты, CSS и данные не закрыты в robots.txt.
5. Проверьте коды ответа для несуществующих адресов.
6. Для массовой проверки статусов индексирования — аудит URL. Скорость и стабильность — Core Web Vitals.

Чего в документации нет

• Срока «через несколько дней» для рендеринга: сказано лишь, что очередь может занять больше нескольких секунд;
• рейтинга SSR, SSG, ISR и оценок «лучший» и «хороший компромисс»;
• рекомендации конкретных фреймворков;
• утверждения, что клиентский рендеринг сам по себе блокирует индексирование.

Чек-лист

1. Нужный контент и ссылки есть в отрисованном HTML.
2. Ссылки — это a с href; маршрутизация через History API.
3. Canonical один и совпадает с HTML.
4. Нет noindex в исходном коде страниц, которые должны индексироваться.
5. Несуществующие адреса дают 404 или noindex.
6. Ресурсы открыты для Googlebot; файлы с отпечатком в имени.

Ошибки

• Считать, что Google не выполняет JavaScript.
• Считать, что клиентский рендеринг сам по себе безопасен без проверки результата.
• Ставить noindex в HTML и надеяться снять его скриптом.
• Строить навигацию на фрагментах и обработчиках событий.
• Закрыть скрипты в robots.txt.

Что дальше

Дальше — модуль продвинутой технической оптимизации: структурированные данные, Core Web Vitals и переезд сайта.