Пускай первый пост в этом канале будет техническим.

Полезные функции Chrome Dev Tools для SEO`шников. Часть 1.

Про ⌘ + ⌥ + I я писать не буду 🙂 Но пойдем по нарастающей.

Изменить User-Agent
Settings (три точки) -> More Tools -> Network Conditions
Убираем галочку с Select automatically и выбираем нужный User Agent. В списке даже сразу есть GoogleBot`ы.

Иногда при аудите нужно проверить как сайт ведет себя с разными агентами + бывают заблокированные ресурсы только для Google Bot на которые хотелось бы взглянуть. Если они проверяют только по UA без проверки Reverse DNS, то этот метод нам подходит.
Есть аналогичные плагины, но а) не все удобные; б) зачем держать лишний плагин, если уже есть функционал?

Изменяем локацию
Settings -> More Tools -> Sensors
Выбираем в выпадающем меню Location.

Я частенько изучаю международные проекты и мне важно знать как сайты реагируют на смену локации и делают ли редиректы и т.д.

Отключить JavaScript

Вариант 1
Command ⌘ + Shift ⇧ + P для MacOS или Control+Shift+P для WIN

В поле вводим Disable и видим в рекомендациях Disable JavaScript -> Кликаем.
Далее перезагружаем страницу через Command ⌘ + R (Control + R)
После того как проанализировали страницу, то включаем обратно командой Enable JavaScript и перезагрузкой страницы.

Сейчас очень важно! Да, поисковые системы следят за трендами SPA, PWA сайтов и модных React, но все же, например, алгоритм определения того, что рендерить, а что нет (Google же не нужно тратить ресурсы на выполнение кода аналитики. Хотя бывает и такое) - не идеален и лучше пока делать максимум SSR, а потому проверять весь ли важный контент есть сразу в коде без JS.

Вариант 2
Как можно отключить не только JS, а какой-то определенный паттерн.
Settings (три точки) -> More Tools -> Network request blocking
Выбираем Add Pattern и вписываем, например, .js

Кстати, это можно было сделать и немного быстрее.
Command ⌘ + Shift ⇧ + P для MacOS или Control+Shift+P для WIN -> Show Network request blocking.
Поиграйтесь с полнотекстовым поиском и, возможно, найдете что-то интересное. Делитесь кейсами 🙂

Данный “Вариант 2” крут тем, что вы можете поиграть со скоростью загрузки убирая определенные элементы. Например, отключить с сайта какую-то рекламную сеть и проверить насколько она влияла на скорость загрузки (показатели Lighthouse).

Проверка неиспользуемых ресурсов на странице
Settings (три точки) -> More Tools -> Coverage
В столбце Usage Visualisation вам будет видно, что не использовалось. А дальше дело за тем, чтобы разобраться за что отвечают данные ресурсы и почему они не использовались. Возможно, что они нужны, а может это просто Legacy код, который забыли удалить.

Больше функций будет завтра 🙂 Если нужно видео о том, как все это делать на практике и кейсы использования, то пишите в комментарии (пока на FB).

by @productseo

Полезные функции Chrome Dev Tools для SEO`шников. Часть 2.
#DevTools #Accessibility #HTTP @productseo

Эмуляция особенностей зрения
1. Предположим, что у людей с возрастом начинают появляться проблемы со зрением. Посмотрим статистику опубликованную 3 ноября 2020 года: “Distribution of internet users worldwide as of 2019, by age group” (ссылка). Видим, что аж 17% пользователей >55 лет. По доступной мне статистике для Украины - около 20%.
2. Посмотрим конкретно на статистику по проблемам со зрением в USA (надеюсь, что в среднем коррелирует со всем миром) и видим 10% (ссылка).
3. Смотрим статистику по color blindness (дальтонизм и прочее: ссылка) и видим “1 из 12 мужчин”.

Это огромная часть аудитории, а потому делаю всегда 2 теста.
1. Setting -> More Tools -> Rendering -> Emulate vision deficiencies - проверка сайта “глазами дальтоника”
2. В Lighthouse проверка на ошибки Contrast ratio. Сейчас популярно сделать серенький текст, но на многих старых девайсах его просто не видно. (P.S. Мы в Flatfy уже работаем над новыми релизами, которые будут более user friendly.) И к тому же, есть вероятность попасть случайно под фильтр клоакинга (от англ. cloak — мантия, маска, прикрытие. Прием «чёрной» поисковой оптимизации, заключающийся в том, что информация, выдаваемая пользователю и поисковым роботам на одной и той же странице, различается.)

Просмотр HTTP-header
Заметил тенденцию, что за рубежом многие наши конкуренты перестают использовать HTML теги, например, meta robots и переходят на x-robots-tag (ссылка). P.S. В своих проектах я пока дублирую.

Из-за этого при анализе конкурентов или же сайтов с бэклинками на вас нужно смотреть еще и HTTP заголовки (ссылка).

Зачастую я использую 2 способа:
1. Открываем страницу -> DevTools -> Network -> Reload страницы -> Выбираем HTTP запрос и изучаем заголовки.
2. Если вы используете Terminal, то я люблю убивать сразу двух зайцев и смотреть через curl -I -L https://domain.com/url (еще и редиректы могу отловить, а если они есть, то увижу их цепочку). Еще цепочки можно смотреть через Network и галочку Preserve Log, но (ИМХО) не так удобно как в сurl.

Просмотр cookies, редактирование и удаление
Это прямо таки любимая тема в продуктах. Мы постоянно проводим различные AB тесты и часто они влияют на контент, который в свою очередь может влиять на ранжирование. И как мы все с вами знаем - GoogleBot всегда заходит как новый пользователь без cookie & cache. А это значит, что он будет постоянно получать случайные версии AB.
Потому всегда нужно следить за тестами и релизами продуктовой команды проверяя все ветки. В своей практике уже не раз встречал ситуации, когда позиции падают, а SEO не знают в чем дело. Идем смотреть cache Google и видим разные “интересности”, которые взялись из AB теста.

Заходим в DevTools -> Application -> Cookies и смотрим на список, изменяем данные в таблицах. Если данных нет, то перезагрузите страницу или сами cookie через кнопку reload.
Могу еще посоветовать плагин EditThisCookie для Google Chrome, если трудно менять через консоль. (ссылка)

Скриншот всей страницы (Full screen\size)
В продукте Flatfy я еще и отвечаю за локализацию (переводы) и иногда за адаптацию (учет особенностей определенных регионов) продукта (это уже больше общая работа всей команды). Так вот тут не обойтись без скриншотов. Как минимум для указания элементов сайта переводчикам (да, у нас есть автоматизация процесса, но бывают моменты…).

Открываем DevTools -> Cmd + Option + P или Ctrl + Shift + P -> вводим Capture full-size screenshot.
Скриншот будет добавлен в Downloads.

Проверка HTTP/2
Google перешел на сканирование через HTTP/2 (ссылка), а значит, что стоит проверить 🙂
DevTools -> Network -> Правой кнопкой на строку с колоссами и найти Protocol -> добавить колонку -> перезагрузить страницу.

В следующей части я напишу про скорость загрузки и анализ быстродействия. Получил разные комментарии и решил, что эти посты про DevTools пойдут в начало лонгрида на блоге с GIF по каждой функции + кейсами использования и скорее всего в видео.

Следующий пост будет в четверг 03.12.2020 об кейсе с огромными затратами краулингового бюджета, а в пятницу 04.12.2020 я напишу пару лайфхаков про быстрый парсинг данных.

P.S. Буду вводить теги для удобства поиска тематических постов + скоро добавлю ботов для обратной связи.

by @productseo

Кейс: потеря краулингового бюджета на собственной системе аналитики

#кейс_из_жизни @productseo - под данным тегом буду публиковать интересные, по моему мнению, случаи из своей практики аудитов. Все кейсы будут анонимизированы без возможности “опознать” сайт, но с полным перечнем данных, которые будут нужны для понимания проблемы и решения.

Дано
Сайт с посещаемостью >2.5 млн. сессий в месяц из органики, пара миллионов страниц в индексе, краулинговый бюджет в день несколько сотень тысяч.

Многие сайты такого размера не могут поместить все данные в Google Analytics из-за ограничений бесплатной версии (ссылка) и им не выгодно покупать GA 360, а потому они идут зачастую двумя путями:
1. разбивают свой сайт на разные GA Property;
2. работают над своей системой аналитики.

В этом кейсе ребята решили пойти по пути 2) и взяли стандартную идею пикселей для создания своей внутренней аналитики.

Техническая составляющая
Пользователь заходит на сайт и у него подгружается невидимый пиксель, то есть происходит запрос на сервер и запись данных в лог, а дальше этот лог разбирается и обрабатывается. Например, вот так выглядит пиксель от FaceBook - ссылка. Зачастую он состоит из двух частей:
1. Для клиентов, которые могут выполнить JS;
2. no js через “картинку” (<img src=“domain .com/pixel?get=”) с get параметрами.

Если мы говорим о части <script>, то ее можно вынести в отдельный файл и закрыть от GoogleBot любым способом (хотя бы от сканирования через robots.txt) или же надеятся на то, что Google поймет, что это аналитика: “Googlebot and its Web Rendering Service (WRS) component continuously analyze and identify resources that don’t contribute to essential page content and may not fetch such resources. For example, reporting and error requests that don’t contribute to essential page content, and other similar types of requests are unused or unnecessary to extract essential page content.” (cсылка). Вот только до сих пор их алгоритм не точен, а потому советую не надется на него и закрывать самим.

Остается вторая часть с “картинкой” и тут Google разгулялся. Для него это была просто картинка и он постоянно ее запрашивал через GoogleBot Image. В данном кейсе повезло, что внутренняя статистика не всегда меняла get запросы, а потому к концу месяца суммарные затраты краулингового бюджета в пустую равнялись бюджету одного дня (и это только одна проблема аналитики). Поскольку система аналитики была на том же домене, то решили проблему через запись в robots.txt Disallow: /pixel?get= . Если бы такие внутренние ресурсы хранились на субдомене или отдельном домене, то можно было бы закрывать через Disallow:/ . Напоминаю, что для каждого субдомена нужно делать свой robots.txt

Вывод: важно смотреть в логи 🤗

P.S. Несколько лет назад у меня был похожий кейс и в ЛУН Поиске (теперь flatfy.ua), когда аналитиками к каждой ссылке на объявления (карточки) о продаже квартир были добавлены custom параметры, условно говоря, stats_position=. Они записывали с какой позиции был клик на карточку и на тот момент совпали звезды, что реализация этого параметра не попала ни под одну маску из robots.txt 😂 Одним словом, я проснулся и увидел +2млн страниц в индексе.

Кейс: потеря краулингового бюджета по невнимательности
#кейс_из_жизни #robots_txt @productseo

Решил этот кейс выделить в отдельный пост, поскольку встречаю слишком часто и уже даже не могу посчитать сколько было потрачено ресурсов поисковых роботов.

SEO’шники почему-то забывают правило, что Disallow:/url - это запрет на сканирование по началу URL. Если переписать в виде regex, то выйдет:
Disallow:^/url*$, где ^ - начало строки (после domain .com).

Если у вас, например, несколько языковых версий и нужно закрыть function.php, то нужно писать или Disallow:/*function.php (или аналогичный вариант, который зависит от того как этот файл используется) или же Disallow:/uk/function.php, Disallow:/en/function.php и так далее.

Аналогично и с get параметрами, которые могут быть в списке. Вы пишите Disallow:?sort=, но не закрываете url вида /url?size=12&sort=desc, который можно закрыть, например, через

Disallow:*?*sort=

. Почему со знаком вопроса? Что бы не закрыть случайно ЧПУ URL. Если уверены в себе, то можно и

Disallow:*sort=

После Disallow: URL НАЧИНАЕТСЯ с данной маски, а не СОДЕРЖИТ, а потому не забываем о звездочках.

Быстрый парсинг “табличного” контента

#софт #плагины @productseo
Сегодня пятничный чилл постик ☺️

Я очень не люблю браузер extensions (а потому скоро сделаю подборку букмарклетов) и у меня есть прям отдельный Google Chrome, который я использую только тогда, когда мне уж точно нужен плагин (ох уж эта паранойя). Один из таких случаев, когда мне нужно что-то спарсить и у меня 0 времени или 0 желания писать свое на Beautiful Soup или Watir.

Открыл для себя недавно Instant Data Scraper (ссылка). Может быть не там смотрел, но ни разу не видел его в SEO подборках.

Чем он мне понравился?
1) Он автоматически пытается найти одинаковые элементы (например, по css class) и парсит с них данные в табличном виде, сохраняя в csv или xlsx. То есть никаких xPath или CSS селекторов вводить не нужно;
2) из коробки умеет работать с пагинацией и инфинит скроллом;
3) умеет делать задержку между запросами, что помогает при долгих ответах от SPA или банах по поведению юзера в браузере.
4) у плагина логотип Pokeball 🙂

Если с первого раза вы не увидели в таблице тех данных, которые нужны, то попробуйте “Try another table”, а если данные излишни, то нажмите на крестик рядом с названием столбца.

P.S. На следующей неделе посты будут выходить в пн 07.12, ср 09.12, пт 11.12 около 22-00 по Киеву. Первым станет кейс о пагинации.

UPD. на requests и scrapy тоже бывает лень :)

Кейс: Пагинация. Проверка Coverage -> Excluded

#кейс_из_жизни #pagination @productseo

Есть множество используемых SEO`шниками схем по реализации пагинации (с точки зрения seo тегов):
1. Canonical на первую;
2. Noindex, follow, canonical self reference;
3. Noindex, follow;
4. Noindex, nofollow;
5. Index, follow.
И т.д.

И каждая из них имеет право на жизнь в зависимости от проекта, задумки SEO`шника и текущей ситуации.

Считаю очень важным отчет Coverage -> Excluded в Google Search Console (ссылка), поскольку он может показать вам места в которых идет “утечка” краулингового бюджета, проблемы с дублями страниц, их качеством (thin content) и т.д.

При анализе одного из проектов в отчетах Excluded я нашел страницы вида “page=182”, которых точно не должно было быть на сайте (столько карточек просто нет). В этом проекте была открыта пагинация для страниц с алфавитным\предметным указателем. Этих страниц не много и они уникализированы + у предметного указателя есть поисковый интент, а значит, что они имеют право быть открытыми. К тому же, это позволяло сделать дополнительную линковку.

Так откуда же взялось множество page=182?
Пускай на сайте было 100 товаров по 10 на странице. Google прошел все 10 страниц и запомнил их. Далее происходит ситуация, что на сайте пропадает 20 товаров (в данном кейсе не важно по какой причине) и теперь у нас всего 8 страниц, но про 9 и 10-ую Google помнит и они есть в Scheduler`е на переобход и рано или поздно он на них зайдет еще раз. В данном кейсе сломалась пагинация и вместо редиректа на первую страницу или выдачи 404 ответа сервера при запросе несуществующей пагинации отдавалась страница 200ок без основного контента (только меню, сайдбар, футер) с кнопками “предыдущая” и “следующая страница”, которая вела дальше по +1 в бесконечность. Таким образом Google просто попал на 10-ую, которой не существовало на данный момент и шел 11,12,13,14…182,183… и в бесконечность. (То чувство, когда вылизанные статьи не попадают в индекс, а тысяча пустых страниц - попала).

Никто не застрахован от ошибок, а потому даже “точно работающие” и очевидные вещи стоит проверять. И это вполне нормально в развивающихся продуктах. Ошибок нет только у тех, кто ничего не делает.

Что стоит делать?
Добавить себе в чеклист периодической проверки:
1. Проверка того, как работает несуществующая пагинация;
2. Какие теги стоят на пагинации + какие http header отдают эти страницы (не забываем о существовании x-robots-tag);
3. Смотреть в Excluded отчет.

А даже, если у вас есть автоматические проверки, то не стоит пренебрегать и ручной проверкой. Кто вам сказал, что чекалка не сломана? 🙂

P.S. Следующий пост будет в среду 09.12.2020 около 22-00 по Киеву. Поговорим про JS рендеринг. И может я еще в ближайшее время напишу пост про свое мнение о том, как можно “готовить” пагинацию при разных начальных данных.

Кейс: Работаете с 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, где мы скорее всего поговорим о разметках, а на следующей неделе немного затронем аналитику.

Использование нескольких type в Schema разметке

Сегодня будет простой, но (надеюсь) полезный пятничный пост про “видимые” и нет разметки #schema. @productseo

Коротко:

”@type”: [“Product”, “Apartment”]

Теория
Есть направление on-SERP SEO в котором мы занимаемся улучшением “видимости” нашего сайта в ТОП. Сейчас мы говорим не о видимости “сколько запросов из семантического ядра в ТОП`е”, а о том какие блоки в выдаче мы занимаем (Featured Snippet, Knowledge Graph, etc.), насколько выделяемся среди конкурентов и как сильно мы их “выталкиваем” из поля зрения пользователя на мобильных устройствах за счет увеличения размера сниппета продвигаемого сайта.

Есть разметки, которые Google выделяет в выдаче (ссылка) и мы не можем вывести сразу все типы вместе. Если разметим, например, Product и FAQ на одной странице, то скорее всего будет выведен только один тип, который Google посчитает приоритетным. Это мы уже знаем.

Кроме этих разметок, есть еще другие сущности из словаря schema.org, которые могут использоваться поисковыми системами для анализа содержания страниц.

Низкий порог входа в профессию разработчика (или лучше сказать “кодера”), множество фреймворков ухудшающих машиночитаемость кода, грубые несоответствия стандартам и другие факторы могут мешать поисковой системе в обработке контента. Так почему не помочь ПС и не разметить данные на странице известными ей сущностями из словаря?

Чаще всего SEO`шники используют microdata и JSON форматы разметки. Сегодня рассмотрим JSON, как более легкий в поддержке и разборе.

Практика
Что делать, если у нас на странице много данных, но они из разных типов и мы хотим улучшить машиночитаемость?
Используем массив 🙂

”@type”: [“Product”, “Apartment”]

и добавляем нужные нам свойства сущностей.
Например, есть страница продажи конкретной квартиры. Зачастую ее размечают просто как Product для вывода цены в SERP, но ведь можно добавить еще локацию квартиры, комнатность и другие ее свойства. Пример можно посмотреть на скриншоте далее.

P.S. Следующие посты будут в понедельник 14.12, среду 16.12 и пятницу 18.12. Начнем неделю с разговора о небольшом хаке для G.Analytics и Data Studio. Всем хороших выходных.

Хак для соединения данных из нескольких Google Analytics Property в Data Studio

#google_analytics #data_studio @productseo

Задача
В посте про систему аналитики я упоминал о том, что большие сайты разделяют свою GA на несколько Property, чтобы избежать лимита бесплатной версии. Пускай нам нужно сделать общий, суммарный dashboard именно в Data Studio (это можно ещё сделать через Google Spreadsheets GA Add-on). Или же вы владелец нескольких сайтов и хотите смотреть на сумму по ___ (подставить нужную метрику, например, сессии или конверсии).

Можно использовать для разных источников, а не только GA (чисто как пример).

Алгоритм решения
(скоро мы придем к проблеме)
1. Создаем новый отчет в GDS;
2. Resource -> Manage added data sources -> Add a data source;
3. Добавляем нужную View из GA с важными показателями\метриками (metrics) и параметрами (dimensions);
(**СОВЕТ**: под каждый новый dashboard я создаю новое подключение, чтобы не попасть в ошибку, когда кто-то для себя в другом отчете поменяет настройки источника, а я этого не замечу).
4. Повторяем с остальными View из других Property;
5. Resource -> Manage blended data -> Add a data source и выбираем добавленные источники для соединения;
(**СОВЕТ**: при выборе показателей вы можете менять им название. Назовите их сразу так, что бы было понятно из какого они источника);
6. Внимательно соединяем эти данные, поскольку в GDS используется left outer join. Это, например, значит, что выбрав первым меньшее множество из имеющихся - вы сразу отсекаете большое количество данных (Например, соединение по дате. Первым выбрали GA созданный полгода назад, а второй - год назад. Потеряете полгода между ними);
7. Сохранили новый источник и добавили в отчет, например, таблицу с данными из этого источника;
8. Добавляем custom metric в которой будет сумма всех сессий\конверсии или другой метрики, которую вы выбирали;

Проблема и хак
Возникает проблема в том, что всегда будут существовать пробелы в данных. Например, на одном сайте есть конверсии за вчера, а на другом нет. Если данных нет, то зачастую GDS ставит значение null и мы не можем корректно использовать математические операции.

Для решения этой проблемы есть (костыль) функция сравнения чисел и поиска большего из них: NARY_MAX. С её помощью мы выберем либо число (ибо оно > 0), либо 0, если в ответе “null”, что позволит использовать операции сложения, умножения и т.д.

NARY_MAX(Сonversion_site_1,0)+NARY_MAX(Сonversion_site_2,0)+NARY_MAX(Сonversion_site_3,0)+NARY_MAX(Сonversion_site_4,0)

P.S. Следующий пост будет в среду 16.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 по Киеву 🙂

Доверяй, но проверяй (справкам и тестам)

#кейс_из_жизни #schema @productseo

Список из интересных (ИМХО) ситуаций по разметкам с которыми я столкнулся на этой неделе:

1. При проверке разметки в формате microdata через Structured Data Testing Tool (который скоро закроют и перенесут в Rich Results Test) отображаются не все очевидные ошибки (специально тестил). При том, что анализ аналогичной разметки в JSON выдает правильный Error. Лучше понемногу привыкать к новому инструменту ибо за ним такого пока не замечено (по крайней мере мной);

2. Разметка мобильной и десктопной версии сайта должна быть идентична. Сейчас уже редко встретишь отдельные субдомены с мобильными версиями, но все еще часто используют динамический показ. Кстати, не все веб-сервера отдают старому Structure Data Testing Tool нужную версию, а потому Rich Result выигрывает бой из-за возможности переключать user-agent;

3. У тех разметок, которые используются в Google SERP для изменения сниппета - более строгие правила. Например, в schema review может быть любой Thing на обзоре, но в Google принимают только определенные типы. Это может вызвать изначально только ошибки в Search Console и отказ в показе расширенного сниппета, но потенциально может быть бан разметки (поскольку вы нарушаете правила). SEO`шники это знают, а вот ТЗ для программистов нужно писать четче;

Следующий пост будет во вторник 22.12, в котором я постараюсь дать схему по работе с архивными товарами и в четверг 24.12 мы поговорим о ссылках.

Схема по работе с товарами “не в наличии” и “архивными” для Junior SEO

#junior #algorithm @productseo

В данном алгоритме нет ничего особенного, но на базовых курсах часто слышу один и тот же вопрос о пропадающих товарах. Потому решил просто один раз сделать схему и делюсь ей со всеми 🙂 Может быть будет полезно для ваших Junior SEO.

Если будут идеи того, что можно добавить именно для джунов, то пишите. Буду очень благодарен.

P.S. Следующий пост будет 24.12 о небольшой автоматизации для работы с ссылками (поделюсь наработкой).

P.S.S. Не забывайте чистить sitemap от всех 301,404,410 и других не 200ОК страниц.

“Get data in batches” или “получаем бесплатные данные массово из Chrome Extension по API”

#автоматизация #api @productseo

‼️ Пост написан для демонстрации алгоритма по работе с API для SEO специалистов, а также для разработчиков SEO плагинов, чтобы показать их уязвимости. Вы можете попробовать подход описанный ниже, но лучше поддержать разработчиков и купить доступы к сервисам. К LRT не имею никакого отношения и их плагин был выбран только из-за наглядности. ‼️

Рассмотрим плагин “Link Research SEO Toolbar” (ссылка) от Christoph C. Cemper и его сервиса Link Research Tool.

Через этот плагин (Chrome Web Store link) вы можете бесплатно получить метрики LRT Power и LRT Trust. Сегодня их рассматривать не будем, но вот ссылка с их описанием, а если коротко, то это (грубо говоря) аналог Majestic Trust и Citation Flow.

Если мы хотим проверить сразу 100 сайтов на данный параметр?

1. Нам нужно получить исходный код плагина. Можно использовать для этого Developer Mode в Chrome, GET запросы к Google Web Store, но для простоты используем сервис crxextractor (ссылка);

2. Start for free -> вводим ссылку на плагин в магазине -> Download и получаем файл с расширением

.crx

;

3. Данный файл добавляем в соседнем блоке “Drop downloaded .CRX and get source code” -> получаем

.zip

архив;

4. Распаковали архив и изучаем его структуру. Нам нужно найти API Endpoint к которому обращается плагин для получения данных. Ищем его в

.js

файлах;

5. В данном примере мы находим файл по пути

js -> lrt -> LRT.js

с строкой

var API_URL = 'https://plugin.linkresearchtools.com/api/api.php';

, которая является переменной с API Endpoint;

6. Ищем API Key (Token), если он есть. В данном случае это строка:

var _apiKey = '6a8c1ddc779a8d760d7f4b209a89fc3361d’;

,
но в других плагинах ключ может быть задан неявно или генерироваться, например, каждый раз для новой сессии;

7. Осталось просмотреть функции и найти GET параметры, чтобы составить запрос;

8. В нашем случае конечный результат будет таков:

https://plugin.linkresearchtools.com/api/api.php?action=get&item=powertrust&key=6a8c1ddc779a8d760d7f4b209a89fc3361d&url=google.com

.
Вы можете этот URL скопировать в браузер и посмотреть ответ;

9. Вы увидите вот такую строку в формате JSON массива:

{"code":200,"message":"ok","datacount":1,"data":{"google.com":{"power":10,"trust":10,"powertrust":100}},"quotaresetdate":"1608905882","usertype":"unlimited","pagecount":1000,"domaincount":1000}

;

10. Дальше уже дело за тем, чтобы эти данные взять, например, аналогично тому, как я писал тут (ссылка) или автоматизировать используя Python.

P.S. Если данный пост наберет 100 лайков на моем FaceBook, то я сделаю более подробный гайд в блог формате + поделюсь своими готовыми скриптами.
P.S.S. Следующий пост будет во вторник 29.12.