Пофиг, что кучу рабочих задач придется перенести и сделать в другое нерабочее время.
Пофиг, что кейс не самый мощный из всех возможных.
Пофиг, что картинки придется делать на скорую руку.
Пофиг, что завтра вставать с сыном в 6-7 утра.

Надо сделать.

Многие из вас знают, что я большую часть времени провожу с сыном с момента его рождения (ему сейчас 1,7), поэтому пришлось ужать рабочий график.

Вокруг: AI, GEO, AEO, QFO, NLP, IPO, QWE, RTY, эмбеддинги, триплеты, автоматизации, генережка и прочие штуки.

Я временами ловил паничку, что безнадежно отстаю от коллег в изучении и освоении всего этого.

Но, чем больше становится мой сын Лев, тем больше врубаюсь, что эти первые 2-3 года, единственный мой шанс, дать ему что-то действительно ценное. И второго такого момента/периода - не будет.

А в SEO изменения не закончатся никогда и это бесконечная гонка знаний/технологий.

Триплеты временны, семья - навсегда.

Беларусские SEOшники, выходите из тени, давайте нетворкать и обмениваться опытом!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На скриншоте спрос на markdown по ws. Честно, я когда шел смотреть, думал будет всплеск из-за популяризации нейросетей, а тут считай плато последние 2 года.

Все данные хранятся локально в браузере. Никаких аккаунтов, никакой слежки, никаких серверов. Экспорт/импорт истории в JSON - на случай переезда или бэкапа.

Короче, сделал бота. Бесплатного. Для себя и для вас.

Я выступлю с докладом, только пока не знаю с каким