Индексация JS сайтов в Яндексе
Сегодня в рубрике «Дурим голову экспертам» задаем вопросы крутой SEOшнице, ведущей
https://t.me/seokakast, новоиспеченному продакту и любительнице баскетбола Лиде Улиткиной 👏
Лида - 💣, оч серьезно подошла к делу и ресерчила кейсы, задавала вопросы, подготовила целый пост. Мне осталось только привести цитату.
Обязательно подпишитесь на канал Лиды (она также серьезно подходит к подготовке своих постов).
Далее цитата:
Андрей постучался в лс по теме 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.
Давайте насыпем Лиде лайков 👍👍👍
______________________
Андрей Артёменко,
https://t.me/seo_okolo
#дуримголову@seo_okolo
#цитаты@seo_okolo
#полезное@seo_okolo
