Comments 8
Контент страниц, отдаваемый ботам, должен соответствовать контенту, возвращаемому пользователю. Иначе есть риск попасть в бан за подмену страниц.
Я че-то не понял, вы же как раз разный контент и отдаете: пользователь видит, условно говоря, "скелет" без контента, гугль - уже отрендеренный HTML со всем контентом. Или как?
Неавторизованный пользователь видит страницу с контентом. Для него отдаётся такая же отренедеренная версия, что и для поисковика, но со всем JS. И запускается механизм регидратации, чтобы актуализировать DOM, события и тд.
Первая проблема: после отдачи уже отрендеренной страницы пользователю, отрабатывают события загрузки страницы и JS начинает заново пересоздавать блоки, начинается мигание, происходит двойная загрузка страницы...
Здесь нужно научит клиентский код понимать, что текущая страница уже готова, на ней уже есть необходимые DOM объекты и загружать ничего не нужно.
Вторая проблема это актуализация страницы. Контент-менеджер обновил описание элемента в админке. Кеш в битриксе сбросится автоматически, а вот отрендеренная страница об этом ничего не знает и поисковик/неавторизованный пользователь видит старый контент, а авторизованный пользователь новый.
И тут нужно подписываться на обновления кеша либо апдейты контентных таблиц и прокидывать из битры триггер на перегенерацию страницы.
Только авторизованный пользователь - видит скелет. И это сознательное допущение, чтобы не перерисовывать на лету контент, который видоизменяется для авторизованного. Не могу сказать, как это реализуется при использовании других технологий пререндеринга, возможно имеются какие-то изящные решения для авторизованных.
>Нам нужно сегментировать трафик так, чтобы готовые облегченные страницы отдать поисковым ботам, готовые полноценные страницы отдать неавторизованным пользователям, а на неотрендеренные страницы, функциональные и закрытые, направлять авторизованных пользователей.
Кстати, тот же вопрос.
Боты поисковых систем видят только облегченный вариант (с высокой скоростью загрузки)? Так тот же гугль умеет прикидываться полноценным пользователем (просмотр из браузера со всеми заголовками и событиями).
И как тут не будет бана за подмену страниц?
Боты поисковых систем видят только облегченный вариант (с высокой скоростью загрузки)?
Да, при прямом заходе бота (с заголовками, UA бота), PageSpeed Insights выдаёт 90+. И вы правы, когда гугл "притворяется" пользователем, то он увидит уже отрендеренную версию страницы, но уже плюс JS, аналитика и тд. и оценка будет 80+.
А на закрытые для определённых групп пользователей страницы, страницы в авторизованном режиме, в общем на не отрендеренные страницы - гугл уже не попадёт.
И как тут не будет бана за подмену страниц?
Да, у нас тоже были переживания по этому поводу. Помимо описанного вами случая, поисковики ещё собирают информацию из реального сеанса пользователя, в том числе когда он авторизован.
Консультировались по поводу случаев когда происходит бан страниц. Поисковые системы, когда обнаруживают существенные разницы в страницах, помечают их как подозрительные и отдают на верификацию человеку. Производится сверка страницы и бан выдаётся "если подменённый контент вводит пользователя в заблуждение".
Т.е. если для гугла сайт отдаёт страницу с ромашками и в поисковом индексе ромашки. Пользователь переходя из поисковой выдачи думает, что попадает на сайт про ромашки, а в реальности подменяется контент и пользователю отдаётся страница с покупкой Чебурашек - будет бан. Такой разницы у нас конечно нет.
Также добавлю, что проект категории "не для всех". При заходе на сайт пользователь попадает на страницу верификации. Это отдельная страница выдающаяся по любому адресу сайта. Т.е. в исходном состоянии поисковая система видит только страницу верификации и не индексирует контент.
У нас уже несколько лет, ещё до внедрения Vue.js, используется механизм определения поискового бота, я немного рассказал про него в статье. Когда на сайт заходит поисковик, то он не уходит на страницу верификации, а сразу видит весь контент и может его индексировать. И даже при таком условии у нас не возникало проблем с индексацией и банами.
Скажу честно, внушает доверие, что Puppeteer предлагают сами разработчики Lighthouse, как решение для веб-приложений, архитектура которых не предусматривает заложенный изначально SSR.
Есть риск, что гугл в будущем изменит свою политику? Только одному гуглу известно :) Риски есть всегда. Мы сделали пробу пера с реактивным фреймворком, почти не изменяя текущий код бекенда, результат нас устроил. А дальше уже будет по классике: Bitrix + GraphQL + Nuxt.js ))
Спасибо за развернутый ответ.
>Поисковые системы, когда обнаруживают существенные разницы в страницах, помечают их как подозрительные и отдают на верификацию человеку.
Вот это смело :(
Из личного опыта - тупо робот по закрытым алгоритмам делает бан и потом нужны танцы с бубном, что бы достучаться до реального живого человека, который будет решать проблему.
"Малоинформативная страница..." - и по этому кругу можно долго ходить.
А не рассматривали вариант, когда контент для поисковика отдается в виде микроразметки (хлебные крошки, контакты компании, товарные предложения, отзывы и тп) плюс мета теги?
SSR для Bitrix с Vue.js без Nuxt.js: как не потерять поисковую индексацию