Индексация JS сайтов в Яндексе

Сегодня в рубрике «Дурим голову экспертам» задаем вопросы крутой SEOшнице, ведущей @seokakast, новоиспеченному продакту и любительнице баскетбола Лиде Улиткиной @seniolida 👏

Лида - 💣, оч серьезно подошла к делу и ресерчила кейсы, задавала вопросы, подготовила целый пост. Мне осталось только привести цитату.

Обязательно подпишитесь на канал Лиды (она также серьезно подходит к подготовке своих постов).

Далее цитата:

Андрей постучался в лс по теме JS в Яндексе. Тема для меня наболевшая, ибо я держала сайт в топ1-3 Яндекса до большого еком апа без контента на основных посадках (так оказалось итого, когда потеряла ТОП3 и просела по всем каталожным). Долго и мучительно тогда пришлось разбираться в SSR и в том, как Яндекс и Гугл на деле обрабатывают сайты на скриптах, а именно SPA.

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

Есть ли опыт с "Рендеринг страниц JavaScript" (β)?

Да, как выше описала кратко, что опыт был максимально печальный. Главное тут: то, что Яндекс видит после рендера — часто это не тоже самое, что видит пользователь.

Когда стоит отключать рендеринг?

Только если SSR реально отдаёт всё нужное в raw HTML: title, h1, контент, ссылки, canonical, структурированные данные. Тогда JS для индексации не нужен, и отключение снижает риск поймать ошибку рендера в индексе.

Если хоть что-то важное появляется только после JS — не трогаем.

Важное уточнение: многие кейсы показывают, что сделать хороший SPA под сеошку ≠ сделать норм сайт под юзера.

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

Плюсы/минусы отключения, что даёт кроме экономии сервера?

Из положительного: меньше риск словить ошибки или пустую страницу в индексе, предсказуемость индексации, нет сюрпризов от отложенного рендера.

Из минусов: если контент на стороне клиента — теряем его полностью для индексации. Нет JS-рендера = в индексе нет данных вне сгенеренного на сервере HTML.

Как устроена индексация в Яндексе под капотом?

Типа такого:
* краулер забирает HTML
* передаёт в очередь рендеринга
* рендерер выполняет JS (с задержкой, иногда это измеряется в днях: скачал, спустя время обработал)
* результат идёт в индексатор
* только потом ранж

Главное тут: HTML и JS-рендер — это две разные ступени. В кейсе у Андрея именно поэтому всё и сломалось.

Наши кейсы, что в них общего и что может быть полезно всем

Если у вас в индексе появляется куча мусора и есть подозрения, что ломается именно SSR, то Яндекс скорее всего тут винить не стоит. Если Яндекс показывает вам мусор — он как бы намекает, что проблема есть.

У Андрея по кейсу: есть проблема в архитектуре, разрабы сделали все норм под юзера, но не учли сеошку. На его файлах апдейты были условно раз в N дней, а лаг рендера у Яндекса на N дней больше. Итого: разрабы в его случае молодцы, определили проблему и решение верно.

Отключение рендера в этом случае было бы костылём. Ведь часть скриптов таки выполнялась на стороне клиента, а значит отключенный рендер просто бы показал в моменте, что все ок, но при откате ошибки снова бы лезли.

У меня по кейсу: SSR вообще не было, уповали только на рендер. В Яндексе это тупо галка в Вебмастере, в Гугле получше с этим дела. У меня Яндекс ваще не делал рендер, мэйн контент был пустой. А это, на минуточку, был весь листинг целиком.

Я в своем кейсе тупо выводила основные сущности в HTML на стороне сервера.

Мой комментарий, чтоб был понятен контекст моего кейса:

Крупный портал на next.js с SSR. Трафик в Яндексе «прыгал» на некоторых страницах/разделах.
Оказалось, бот индексатор забирал исходники, а рендерил позже. К тому моменту когда он приходил рендерить, часть скриптов уже «протухла» и фронт отдавал пустой html.

Давайте насыпем Лиде лайков 👍👍👍

______________________
Андрей Артёменко, @seo_okolo
#дуримголову@seo_okolo
#цитаты@seo_okolo
#полезное@seo_okolo