Сегодня на почту прилетел опрос от Яндекс.

На одном из вопросов во мне проснулся параноик и я ответил вот так - http://joxi.ru/Drlbj0aSVRb6Y2

ПФ, Ссылки, Негативное SEO? Нее не слышал.

А вам приходил этот опросник?
Что ответили?
Какие мысли по этому поводу?)))

Открыл для себя интересное нововведение Яндекса.

http://joxi.ru/52avVl1uEwo43A.
Ранее там была ссылка на рекламную выдачу. Теперь на "коммерческую".
По ссылке смесь рекламы и коммерческой органики.
Выдача органики там и в простом поиске значительно отличается даже по явно коммерческим запросам.

Как и можно ли использовать это SEO-специалисту пока не ясно.

Новая статья в блоге на тему HTML и верстки. 😊

Да, эта тема скорее для новеньких и неопытных специалистов.
Но я решил её написать из-за разного рода недопониманий со стороны уже опытных спецов. Накопилось и прорвало, так сказать.

Например, я имел дело с диалогом по поводу того, что display:none это плохо для SEO.
Ок, есть исследования, где говорится о том, что тексты скрытые в аккордеон влияют на ранжирование хуже, чем те, что полностью отображаются на странице.
Но разговор был о мелких элементах дизайна появляющихся по клику или наведению, а в "спокойном состоянии" скрытых с помощью CSS свойства display:none.

При этом, меню на каждом втором сайте имеет блоки ссылок появляющихся при наведении... Как же так... 😖

В общем, такие перлы рождаются от непонимания элементарных принципов верстки и в этой статье я призываю SEOшников к изучению хотя бы базовых принципов верстки и основ HTML.

https://biryukov-seo.ru/articles/html-seo/

Действительно достойный внимания инструмент. Особенно если вы сталкивались с неопытными разработчиками, которые задают вопросы типа "а что именно сдвигается?", "а куда смотреть?". Данный инструмент наглядно показывает все смещения происходящие при загрузке страницы поэлементно.

👍 Накопительный отладчик сдвига макета (CLS)

Привет, друзья!

Не так давно попался мне на глаза бесплатный SEO tool под названием Cumulative Layout Shift Debugger (CLS).

Этот инструмент генерирует такие отчёты:
1️⃣ Мобильная визуализация с кумулятивным сдвигом макета.
2️⃣ HTML-элементы, вызывающие кумулятивные сдвиги макета (моб.).
3️⃣ Данные мобильного тестирования.
4️⃣ Накопительная визуализация десктопа со сдвигом макета.
5️⃣ HTML-элементы, вызывающие кумулятивные сдвиги макета (десктоп.).
6️⃣ Данные десктопных тестов.
7️⃣ Измерения CLS реального пользователя для протестированного URL.
8️⃣ Измерения CLS реального пользователя для имени хоста (происхождения).

Единственный минус этого инструмента - он немного тормознутый. Проверка одной страницы занимает примерно полторы минуты.

👉 Ссылка на инструмент https://webvitals.dev/cls

*******
📌Более 700 брендов iGaming, уникальные условия под SEO-трафик тут 👉🏻 https://bit.ly/2NEwfYq

В е-коме всё больше сайтов с большим объемом динамического контента. И зачастую очень сложно быстро отследить все технические ошибки которые могут появляться в связи с этим. Я лично сталкивался со случаями, когда динамический контент заменял важные мета-данные документа на неверные и Google индексировал их. Да, такое случается не часто, но имеет место быть.
Потому контроль за отрендеренной версией страницы имеет важную роль в части технического SEO.

Для просмотра отрендерренного HTML можно пользоваться инструментами от Google для проверки микроразметки или mobile-friendly тест (там есть кнопка просмотра отрендеренного html).

Но, есть более быстрое и простое решение 🔥🔥🔥
Данный плагин в одном окне покажет исходный html и отрендеренный. А справа покажет различия между ними, подсвечивая их красным и зеленым.

https://chrome.google.com/webstore/detail/view-rendered-source/ejgngohbdedoabanmclafpkoogegdpob?hl=en


Так же стоит заметить, что имеется возможность подмены юзерагента на мобильный и GoogleBot http://joxi.ru/Grqv5pMu4WeQMm


🔥🔥🔥 Очень к месту свежее заявление Google о том, что просмотр кешированной версии документа - устаревшая и не поддерживаемая функция
https://www.seroundtable.com/google-cache-view-is-an-unmaintained-legacy-feature-31256.html

Очередные похороны SEO не за горами 😁

https://www.google.com/amp/s/www.technologyreview.com/2021/05/14/1024918/language-models-gpt3-search-engine-google/amp/

Опубликовано предложение по кардинальной переработке поисковой системы.
Вместо привычного ранжирования сайтов и предоставления пользователю топа, исследователи Google предлагают заменить всё это на одну большую языковую модель типа BERT, GPT-3 или их преемников.
То есть вместо поиска информации, предполагается, что пользователь будет задавать вопросы и получать ответы, сгенерированые AI.

Друзья, пакуем вещички и идём на завод 😊

Если серьезно, пока эта новость ничего, кроме глупой ухмылки не вызывает. Но кто знает куда кривая заведёт.

А теперь о реальных разработках Google.

На конференции Google IO, Вице-президент Google Прабхакар Рагхаван презентовал новую технологию "Multitask Unified Model" (MUM). Это нейросеть похожая на BERT, но в 1000 раз мощнее. С ней Google сможет ещё лучше понимать сложные поисковые запросы. Причем модель уже понимает информацию в тексте, изображениях, а в будущем будет работать с информацией в видео и аудио форматах.

В презентации автор указал на наличие сложных интентов, которые могут требовать несколько поисковых сессий для их решения. По подсчётам Google в среднем пользователю нужно 8 поисковых сессий чтобы решить такую проблему. С MUM Google намерен сократить это число.

Примером сложного запроса в презентации служил запрос "я уже поднялся на гору Адамс, и теперь хочу взойти на гору Фудзи следующей осенью, что нужно сделать чтобы подготовиться?".
Вооружившись MUM, в ответ на такой запрос Google предоставит информацию о различиях между горами, о том какое оборудование потребуется и тд.

По информации в блоге Google, они уже начали внутренние тесты MUM и результаты впечатляют.

Подробнее можно почитать в блоге Google https://blog.google/products/search/ai-making-information-helpful-io/

И статье https://www.google.com/amp/s/searchengineland.com/google-previews-mum-its-new-tech-thats-1000x-more-powerful-than-bert-348707/amp

Получить данные Яндекс Метрики по поисковым запросам, по которым пользователи переходили на конкретный URL всё еще возможно.

К сожалению не так просто как ранее, т.к. сейчас метрика показывает только те запросы, по которым было более 10 визитов за выбранный период (https://yandex.ru/blog/metrika/34). Для этого потребуется воспользоваться API, но не простым API метрики, а Logs API - https://yandex.ru/blog/metrika/vygruzhayte-syrye-dannye-iz-metriki-cherez-logs-api.

👉 Пример данных, которые я забрал из API (период 7 дней, на скриншоте лишь часть данных) - http://joxi.net/YmE9vMVhw1lddm.

Слева данные в интерфейсе метрики (если это можно назвать данными), справа данные импортированные мной из Logs API в Google Data Studio.
Рядом с каждым запросом указано число визитов. Наглядно видно, что в данном случае нет ограничения по 10 визитам на запрос.

Я не даю инструкцию по использованию API, лишь рассказываю о возможности получить такие данные, т.к. вы можете обратиться к API с помощью разных языков программирования, или вовсе через запросы в браузер. А быть может не самостоятельно, а дадите задачу вашему разработчику 😉

Кстати, не забывайте про более простой вариант получить подобные данные в вебмастере (Вебмастер - поисковые запросы - управление группами). Там тоже можно посмотреть данные по URL http://joxi.ru/EA4XVoNho8lJgA. Да, фильтр тут не идеален, т.к. не хватает регулярок, но в некоторых случаях позволяет получить необходимый результат, к тому же показывает запросы по которым были показы, но не было кликов.

P.S. Я использовал Python (Библиотеку для всех API Яндекс Метрики https://github.com/pavelmaksimov/tapi-yandex-metrika/ и библиотеку для API Google Sheets https://github.com/nithinmurali/pygsheets, чтобы отправить данные в Google таблицу, а затем загрузить данные в Google Data Studio).

Документация Logs Api тут https://yandex.ru/dev/metrika/doc/api2/logs/intro.html.

P.S. На скриншоте есть момент где поисковая фраза "фахверк каркас купить" повторяется - это не ошибка группировки данных (см. в столбец "поисковая система", это переходы с разных источников).

Делюсь мини-хаком.
В своей работе периодически анализирую контент страниц выключая JS и CSS (например, чтобы быстро оценить какой контент точно будет проиндексирован ПС или при проверке внедрения каких-либо технических рекомендаций).
В некоторых случаях SVG графика мешает процессу. Например можно наблюдать такую картинку в браузере - http://joxi.ru/n2YZjx8hbllOeA.

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

Однако, если вы, как и я захотите анализировать контент страницы с выключенным JS - букмарклет не сработает (ему требуется JS).
Но если вставить код букмарклета в консоль, то он отработает даже при выключенном JS. Демонстрация для примера - https://recordit.co/wQ7emqjRlE.

Ссылка на букмарклет - https://clck.ru/V53YV

Короткая история из опыта.
Занимался продвижением одного Российского бренда с названием на латинице. Разделы и товары сайта содержали бренд в названиях и заголовках. Сайт имел положительную динамику, но рос неохотно.
Было обнаружено, что в силу того, что бренд российский и не имеет проблем с произношением/написанием на русском, его частотка на РУ в разы превышает частотность на англ (соотношение 7/1).
Было решено не просто добавить вхождения ру-бренда в заголовках, но и заменить бренд в названиях товаров на его ру-эквивалент, не смотря на то, что "Правильным названием" является англ.
После чего сайт пошел в значительный рост и по разделам и по карточкам товара. Кроме этого ТЗ включало употребление ру/англ вхождений в других зонах документа, но эта часть ТЗ еще не выполнена.
На скрине % в ТОП-5 Яндекс МСК (~1500 запросов в ядре).

Пусть это будет моим небольшим камушком в огород тех, кто говорит "ПС умные и понимают, что это бренд и не надо добавлять альтернативных названий для брендов".

Пересмотрел пару видосов о текстовых факторах ранжирования (далёкий 2013 год).

Вот эти:
https://youtu.be/cXgH9dstwTw
https://youtu.be/BGH5LMP1aSE

Да, это старые видео, 2013 год, но как приятно их смотреть.
Пусть это базовая информация, но она достаточно точная. Ламповая атмосфера, ребята общаются за SEO без промоушена всяких курсов, никакой инфоцыганщины, чистый кайф.
Если вдруг кто-то не смотрел - посмотрите =).
Даже из информации 2013 года можно найти для себя пользу, в зависимости от вашего текущего уровня конечно же.
Да и в целом освежить базовые знания всегда полезно.

Мои руки всё никак не доходили до побаловаться с Google indexing API.
А у автора канала https://t.me/drkwng вышел неплохой эксперимент. Делюсь с вами.
И главное всё это легко можно повторить по инструкции описанной в другом посте канала https://t.me/drkwng/17.

Шоломки ✡️ Тут созрел еще пост про Google Indexing API в дополнение к предыдущему. В этот раз без кода☺️

Провел небольшой эксперимент для изучения, насколько быстро Googlebot реагирует на запросы в Indexing API...

API для отправки на индексацию URL использую давно, но всегда мучали мою маленькую лысую голову 3 вопроса:

1️⃣ Как быстро бот заходит на страницу после отправки запроса через API?
2️⃣ Какое среднее время попадания отправленной страницы в индекс Google?
3️⃣ Переходит ли бот по 301 редиректам при подобной отправке, а именно, междоменным редиректам?

Для этого я взял 10 разных доменов живых сайтов разного уровня, которые уже есть в индексе Google. На каждый сайт залил по 4 .html файла с кодом шапки сайта и сгенерированным контентом на основе сниппетов выдачи Google по содержимому <h1> тега главной страницы каждого сайта в качестве поискового запроса. Естественно, html файлы и генерация контента руками не делались. После составил различные сценарии 301 редиректа в .htaccess каждого сайта для проверки, как бот следует по редиректам в рамках домена и за его пределами.

У всех сайтов включено логирование запросов, ведь именно по логам сервера планировал вычислять путь Googlebot. Отмечу также, что все файлы изолированы и на них можно было перейти только по прямому или заданному редиректному URL.

Ну а теперь ответы на вопросы, которые мучали меня:

1️⃣ Скорость захода Googlebot после отправки запроса через API:
На всех 10 сайтах бот зашел на URL в течение 1 минуты после отправки запроса.
Попадание: 30 из 30

✋Стоп, у нас 10 доменов, по 4 html заглушки на каждый... 10*4 = 30??? Никак нет, мой юный Эркюль Пуаро, тебе не показалось. В п.3 я вскрою все карты.

2️⃣ Скорость попадания страницы в индекс Google после отправки запроса:
- 22 из 30 документов попали в индекс в течение 10 минут (точнее определить не удалось из-за ограничений в скорости сбора данных на моей стороне), еще 3 документа появились в индексе в течение рабочего дня.
- 5 документов на 4 доменах так и не появились в индексе.
Какие выводы можно сделать? Возможно, не совсем качественно сгенерированный контент (в рамках одного домена текст для всех html генерился по одному паттерну, просто слегка перемешивался) или какие-то другие факторы, которые мог упустить из вида. В любом случае попадание в индекс большинства документов считаю показательным.

3️⃣ Следует ли бот по внутренним и междоменным редиректам к конечному URL?
На каждом домене на один из html можно было попасть только по редиректной ссылке с другого домена.
Основываясь на логах сервера, Googlebot не перешел ни по одному из междоменных редиректов, хотя заход на "редиректящий" URL был в 100% случаев.

На другой html вел внутренний редирект (в рамках домена). Бот без проблем перешел по URL с редиректом и проследовал к конечному URL, добавив документ в индекс (с поправкой на данные из п.2).

Подведем итоги:
- Бот заходит сразу после отправки запроса.
- Добавление документа в индекс происходит почти сразу. В некоторых случаях документ залетает в течение дня и совсем редко не залетает вообще (чуть более 10% от тестовой выборки).
- Бот ходит по редиректам в рамках домена и не ходит по междоменным редиректам вообще😒

Напоминаю, что в прошлом посте описал инструкцию и принцип работы модуля для отправки в индекс Google URL через API (ссылка на GitHub).

Буду рад замечаниям/предложениям или просто "норм" в комментах. А кто сделает шер-алишер или кинет другу, у того самый красивый гипоталамус. Чирик!🐥

#seo #googleAPI

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

Ситуация примерно следующая.
Где-то год назад на одном из сайтов при внесении правок косякнули и засунули во внутреннюю перелинковку комбинации ЧПУ фильтров не существующих на сайте и плюсом ко всему сервер отдавал по ним 200 ответ. Ошибку исправили (ссылки убрали, настроили 404) но Яндекс успел накушаться таких страниц сполна (сотни тысяч).
Ссылок на эти страницы 100% нигде нет. Но вот прошел уже год и Яндекс до сих пор бегает по этим страницам. И ладно бы с десяток в день. Нет, он обходит их тысячами.
Откуда он их берет? Они хранятся в базе Яндекса.