Кейс: Работаете с JS? Проверяйте Source Code в Google Cache
#кейс_из_жизни #JavaScript @productseo
На всех своих лекциях о технической оптимизации всегда твержу о том, что нет разницы как видите сайт вы, а важно как его видит поисковая система.
В посте о потере краулингового бюджета из-за custom системы аналитики (ссылка) я уже писал о том, что ПС выбирает какие JS стоит выполнять, а какие нет по своим внутренним алгоритмам (ссылка). В данном кейсе как раз важные JS не сработали.
В чем проблема?
На сайте была реализована мобильная версия через Dynamic Serving (по одному URL отдается разных код в зависимости от запроса, например, по User Agent). Изначально в мобильной версии отдавалась минимальная HTML с контентом, а затем происходила регидрация (JavaScript re-hydration), которая обновляла DOM дерево добавляя туда интерфейс и дополнительный контент.
Ребята анализировали конечную версию после подгрузки скриптов, но не обращали внимания на первый код из SSR. Если зайти в “Посмотреть исходный код” (именно вкладка в Google Cache), то там мы увидели минус половину контента (перелинковки, обзоры, комментарии и т.д.), а тот контент, который есть - с ошибками. Например, в карточке товара изначально отправлялся код с H1 на названии товара и еще одним H1 на всем описании этого товара, а затем уже через JS изменялся на <div> (может когда-то это был SEO хак, но фича переросла в баг).
Таким образом мобильная страница теряла большую часть контента, а та часть, которая всё-таки была - оказалась не SEO оптимизированной. К тому же, такие технические проблемы могли приводить к тому, что для поисковой системы это выглядело бы как клоакинг при сверке версий с desktop user agent и mobile.
Важная сноска. Может память подводить, а посмотреть уже нельзя, но из моих записей JS файлы были полностью открыты для ПС, а некоторые части скриптов были вообще добавлены прямо на страницу. Потому проблемы именно с блокировкой доступа и т.п. быть не должно было.
Что делать?
1. При аудите сайта всегда проверять сайт как desktop и mobile агент (ссылка);
2. Проверять как работает сайт с отключенным JS (ссылка);
3. Выбрать типовые страницы и просмотреть их исходный код в Google cache и через test live url в GSC.
P.S. Следующий пост будет в пятницу 11.12.2020, где мы скорее всего поговорим о разметках, а на следующей неделе немного затронем аналитику.
#кейс_из_жизни #JavaScript @productseo
На всех своих лекциях о технической оптимизации всегда твержу о том, что нет разницы как видите сайт вы, а важно как его видит поисковая система.
В посте о потере краулингового бюджета из-за custom системы аналитики (ссылка) я уже писал о том, что ПС выбирает какие JS стоит выполнять, а какие нет по своим внутренним алгоритмам (ссылка). В данном кейсе как раз важные JS не сработали.
В чем проблема?
На сайте была реализована мобильная версия через Dynamic Serving (по одному URL отдается разных код в зависимости от запроса, например, по User Agent). Изначально в мобильной версии отдавалась минимальная HTML с контентом, а затем происходила регидрация (JavaScript re-hydration), которая обновляла DOM дерево добавляя туда интерфейс и дополнительный контент.
Ребята анализировали конечную версию после подгрузки скриптов, но не обращали внимания на первый код из SSR. Если зайти в “Посмотреть исходный код” (именно вкладка в Google Cache), то там мы увидели минус половину контента (перелинковки, обзоры, комментарии и т.д.), а тот контент, который есть - с ошибками. Например, в карточке товара изначально отправлялся код с H1 на названии товара и еще одним H1 на всем описании этого товара, а затем уже через JS изменялся на <div> (может когда-то это был SEO хак, но фича переросла в баг).
Таким образом мобильная страница теряла большую часть контента, а та часть, которая всё-таки была - оказалась не SEO оптимизированной. К тому же, такие технические проблемы могли приводить к тому, что для поисковой системы это выглядело бы как клоакинг при сверке версий с desktop user agent и mobile.
Важная сноска. Может память подводить, а посмотреть уже нельзя, но из моих записей JS файлы были полностью открыты для ПС, а некоторые части скриптов были вообще добавлены прямо на страницу. Потому проблемы именно с блокировкой доступа и т.п. быть не должно было.
Что делать?
1. При аудите сайта всегда проверять сайт как desktop и mobile агент (ссылка);
2. Проверять как работает сайт с отключенным JS (ссылка);
3. Выбрать типовые страницы и просмотреть их исходный код в Google cache и через test live url в GSC.
P.S. Следующий пост будет в пятницу 11.12.2020, где мы скорее всего поговорим о разметках, а на следующей неделе немного затронем аналитику.
Немного о виджетах обратных звонков и чатах
#JavaScript #widget @productseo
Предыстория (можно сразу прокрутить к “практике”)
Писал в чат поддержки крупного сайта, мне не отвечали, я переключался на другие дела и через минут 20 мне отвечали (конечно же я не видел их ответа), ждали ровно 1 минуту и говорили, что больше ждать не могут, отключали оператора. Так произошло раз 5, а потом я решил, что мне уже не нужна их поддержка.
Это мне напомнило историю о том, как лет 5 назад я работал с проектом в котором впервые познакомился с call tracking и у меня были доступы ко всем записям звонков продавцов-консультантов и логам с данными о времени разговоров, пропущенных, истории чатов. Тогда я просто начал вечерами заходить в эту CRM, чтобы поднять себе настроение от этих кринж разговоров и именно тогда я понял, что нужно по телефону\чату отвечать либо нормально, либо лучше вообще никак 🙂
Пошла мода ставить чаты на любой интернет магазин или сайт услуг, а потом отвечать часами или не отвечать и вовсе. Не гонитесь за модой, а решите, что вам важнее: скорость работы сайта или возможная быстрая связь с клиентом. А ещё разберитесь можете ли вы быстро отвечать, а если не быстро, то не потеряете ли заказы и лучше не давать клиенту лишних ожиданий.
Виджеты бывают разные, например, недавно было интересно посмотреть на ИМ, который очень долго мне отвечал в чате (я так и не купил то, что хотел. Ответ через >24 часов - это слишком. Видимо это карма и я только на такие магазины и попадаю). Виджет забирал +- 7 баллов в PageSpeed Insights и к тому же стоял в таком месте, что ты постоянно на него жмешь и не попадаешь по интерфейсу.
Пара советов по чатам из моей ПРАКТИКИ:
Скорость загрузки
Как проверить влияние вашего виджета на скорость загрузки?
1. Открываете нужную страницу сайта в Chrome и запускаете DevTools (MAC: ⌘ Cmd + ⌥ Option + i; WIN: Control + Shift + i);
2. Выбираете вкладку Lighthouse и проводите тест;
3. После завершения теста открываете вкладку Network; (если в ней пусто, то перезагрузите страницу cmd + R)
4. В списке найдите JS с вашим виджетом; (можно для быстроты отсортировать по столбцу domain, если виджет внешний или в фильтрации над timeline выбрать категорию “JS”)
5. Нажимаете на строку с нужным виджетом правой кнопкой и блокируйте либо конкретный URL, либо весь домен (Block request domain);
6. Переходите снова в Lighthouse, сверху в выпадайке выбираете (new report), снова проводите тест;
7. Сравниваете прошлый с предыдущим;
Это можно было сделать и через “отключение JS - Вариант 2” из прошлого поста, но не так “визуально”.
События аналитики о взаимодействии с чатами
Был проект в котором использование чата считали очень важным, поскольку его “вызывали” >90% пользователей (ивент раскрытия чата). Если посмотреть в CRM, то обращений в чат было значительно меньше, чем открытий. Оказалось, что была добавлена настройка виджета при которой он сам раскрывался через N секунд. Это происходило почти у всех пользователей кроме тех, кто использовал различные блокировщики или же тех, кто уходил быстрее.
Если вы используете чаты, то не смотрите на “голые” события. Например, тегируйте обращения (саппорт, заказ, консультация и т.д.), а затем ставьте KPI для каждой категории.
Используйте BrowserStack и данные GA по Device
1) Не все виджеты одинаково хорошо работают во всех браузерах и на всех устройствах. Самые популярные можно проверить в BrowserStack + посмотреть в аналитике события по девайсам.
2) Иногда виджет закрывает важные элементы интерфейса, а потому стоит проверить на разных разрешениях экранов через DevTools или BrowserStack.
P.S. Следующий пост будет в пятницу 18.12 около 22-00 по Киеву 🙂
#JavaScript #widget @productseo
Предыстория (можно сразу прокрутить к “практике”)
Писал в чат поддержки крупного сайта, мне не отвечали, я переключался на другие дела и через минут 20 мне отвечали (конечно же я не видел их ответа), ждали ровно 1 минуту и говорили, что больше ждать не могут, отключали оператора. Так произошло раз 5, а потом я решил, что мне уже не нужна их поддержка.
Это мне напомнило историю о том, как лет 5 назад я работал с проектом в котором впервые познакомился с call tracking и у меня были доступы ко всем записям звонков продавцов-консультантов и логам с данными о времени разговоров, пропущенных, истории чатов. Тогда я просто начал вечерами заходить в эту CRM, чтобы поднять себе настроение от этих кринж разговоров и именно тогда я понял, что нужно по телефону\чату отвечать либо нормально, либо лучше вообще никак 🙂
Пошла мода ставить чаты на любой интернет магазин или сайт услуг, а потом отвечать часами или не отвечать и вовсе. Не гонитесь за модой, а решите, что вам важнее: скорость работы сайта или возможная быстрая связь с клиентом. А ещё разберитесь можете ли вы быстро отвечать, а если не быстро, то не потеряете ли заказы и лучше не давать клиенту лишних ожиданий.
Виджеты бывают разные, например, недавно было интересно посмотреть на ИМ, который очень долго мне отвечал в чате (я так и не купил то, что хотел. Ответ через >24 часов - это слишком. Видимо это карма и я только на такие магазины и попадаю). Виджет забирал +- 7 баллов в PageSpeed Insights и к тому же стоял в таком месте, что ты постоянно на него жмешь и не попадаешь по интерфейсу.
Пара советов по чатам из моей ПРАКТИКИ:
Скорость загрузки
Как проверить влияние вашего виджета на скорость загрузки?
1. Открываете нужную страницу сайта в Chrome и запускаете DevTools (MAC: ⌘ Cmd + ⌥ Option + i; WIN: Control + Shift + i);
2. Выбираете вкладку Lighthouse и проводите тест;
3. После завершения теста открываете вкладку Network; (если в ней пусто, то перезагрузите страницу cmd + R)
4. В списке найдите JS с вашим виджетом; (можно для быстроты отсортировать по столбцу domain, если виджет внешний или в фильтрации над timeline выбрать категорию “JS”)
5. Нажимаете на строку с нужным виджетом правой кнопкой и блокируйте либо конкретный URL, либо весь домен (Block request domain);
6. Переходите снова в Lighthouse, сверху в выпадайке выбираете (new report), снова проводите тест;
7. Сравниваете прошлый с предыдущим;
Это можно было сделать и через “отключение JS - Вариант 2” из прошлого поста, но не так “визуально”.
События аналитики о взаимодействии с чатами
Был проект в котором использование чата считали очень важным, поскольку его “вызывали” >90% пользователей (ивент раскрытия чата). Если посмотреть в CRM, то обращений в чат было значительно меньше, чем открытий. Оказалось, что была добавлена настройка виджета при которой он сам раскрывался через N секунд. Это происходило почти у всех пользователей кроме тех, кто использовал различные блокировщики или же тех, кто уходил быстрее.
Если вы используете чаты, то не смотрите на “голые” события. Например, тегируйте обращения (саппорт, заказ, консультация и т.д.), а затем ставьте KPI для каждой категории.
Используйте BrowserStack и данные GA по Device
1) Не все виджеты одинаково хорошо работают во всех браузерах и на всех устройствах. Самые популярные можно проверить в BrowserStack + посмотреть в аналитике события по девайсам.
2) Иногда виджет закрывает важные элементы интерфейса, а потому стоит проверить на разных разрешениях экранов через DevTools или BrowserStack.
P.S. Следующий пост будет в пятницу 18.12 около 22-00 по Киеву 🙂