Слив документации команды поиска Google

Rand Fishkin поделился в блоге, что с ним связался анонимный источник, который утверждал, что имеет доступ к сливу документации к API от внутреннего подразделения поиска Google. В дальнейшем этот источник показал сам слив, включающий 2500 страниц документации с 14014 атрибутов из Content API Warehouse. В истории документов указано, что код был залит на Github 27 мар 2024-го и пробыл там до 7 мая 2024.

Чтобы убедиться в достоверности, Rand Fishkin связался с более технически прошаренным Mike King, который подтвердил, что вероятно это действительно документация от внутренней команды поиска Google.

Mike King сделал подробный разбор этих документов у себя на сайте, рекомендую ознакомиться:

https://ipullrank.com/google-algo-leak

Update:

Ссылка на документацию: https://hexdocs.pm/google_api_content_warehouse/api-reference.html

Один из моих travel сайтов, который попал под обновление апдейта в Гугле начал подавать признаки жизни и выходить из под фильтра.
Конечно утверждать, что это 100% выход нельзя, так как возможно ослабили фильтр. Тем не менее что я сделал:

Добавил всплывашку кук. До этого на сайте ее никогда не было.

Удалил около 20 плохих ссылок на сайт с помощью Google Console.

Политика конфиденциальности и Контакты на сайте не индексировались. Добавил больше уникальной информации, в контакты добавил описание автора, телефон, дополнительные ссылки на соцсети, фото автора сайта, опыт в travel (посещенные страны). После отправил на переобход.

Уникализировал текст "О сайте" - был сгенерированный текст от ChatGPT.

Перевел интересную статью от Matthew Woodward о заявлениях Гугла и реальности которую мы видим в слитых документах Гугла. Добавил свои комментарии, так как я не с всем согласен с автором, но это не ухудшает тот объем работы, которую он провел.

https://devvver.ru/seo/15-seo-mifov-oprovergnutyx-utechkoj-dannyx-google/

#seo

Известный seo специалист Михаил Мятов проходит прямо в текущий момент курс Чекушина по продвижению интернет-магазина и делает выжимки в своих постах.

Так, недавно он очень подробно рассказал про современную онпейдж текстовую оптимизацию (да-да, токены, леммы, idf, и т.д.) доступным языком.


Рекомендую изучить и подписаться: https://t.me/myatov/

А ещё Михаил делает крутые ПФ. И в Яндексе за 3 дня (дёшево и безопасно!), и в Гугле под любую страну за 2 месяца.

Написал парсер для получения ответов от Gemini (аналог ChatGPT) с помощью их API.
Скрипт позволяет получить данные из csv и из заголовков написать условия с шаблонами для запросов к чатботу.

Что можно делать с его помощью? Примеры:
1) Массово генерировать статьи с условиями
2) Генерировать Title и дескрипшионы
3) Анализировать данные (как в Excel) после ответа чатбота.
4) Получать LSI или слова задающие тематику для ключевых фраз
5) И так далее. Весь функционал который есть у чатботов.

Ссылка на проект https://github.com/Devvver/gemini_csv_parser
Там же условия использования и запуска.

Буду благодарен репосту за opensource решение.

#seo_python

Что по статейникам?

Это наиболее частый вопрос который задают в личке. После апдейтов Гугла и Яндекса с зачисткой AL контента пострадали в том числе и вполне нормальные сайты.

Личные потери - меньше 1К баксов. Еще в 2020 году я понял что инвестирование в статейники начало терять смысл. Поэтому с того момента я создавал небольшие статейники на 10-30 страниц и продавал тем кто заходил в разные ниши. С точки зрения затрат-прибыли это было очень выгодно.

После изменений в этом году выживут меньше 20% сайтов. На многих биржах (к примеру etxt) падение заказа контента в более 10 раз. Много кто наполнял сайты стопнули заказы. Я тоже ушел с заказа статей, так как в 90% получаешь генерированное гуано, даже если просить не использовать чатботы. Пока биржи не решат эту проблему - возвращаться не планирую.

Что же будет развиваться? Если ваш статейник не прихлопнуло (а я своих нишах вижу даже которые выросли в 2 раза) - наполняйте и развивайте, у вас есть шанс охватить всю семантику.

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

Ближайшее время должны появится новые методы создания статейников, так как понятно, что старые методы вымирают. Парсить вордстат уже бессмысленно, нужно дополнительно чекать конкуренцию, выдачу (на чатбота, картиночную выдачу, видео в топе).

🚨 Решение проблемы с индексацией RSS лент комментариев в WordPress 🚨

Google упорно пытается индексировать страницы, даже если они заблокированы в robots.txt. Особенно это касается RSS лент комментариев, которые не всегда нужны и могут попасть в дополнительный индекс, ухудшая ранжирование сайта.

💡 Как я решил проблему: Создал плагин для WordPress, который блокирует индексацию RSS лент комментариев, но сохраняет основную ленту и Яндекс Турбо.

Плагин: ссылка на скачивание

Прописывает 301 редирект с комментариев на посты.
Позволяет сохранить нужные RSS ленты.

Полный пост с описанием на моем блоге.

Из слива ранжирования Гугла стало более понятно как передается вес от донора акцептору.
Гугл для каждого сайта и страницы рассчитывает вектора.
siteFocusScore - определяет сосредоточенность на определенной теме (тематичность).
siteRadius - указывает на охват темы (чем больше тем лучше, указывает насколько вы выписали ядро по кластеру).
siteEmbeddings и pageEmbeddings - это средний вектор сайта и страницы.
Отдельно также высчитывается вектор анкора ссылки (anchorMismatchDemotion).
На практике это позволяет передавать меньше веса нерелевантным донорам (используется весь topicEmbeddingsVersionedData) и наоборот - увеличивать вес ссылок которые опубликованы с тематичного сайта и тематической статьи.

Как это использовать: под каждую ссылку пишите в ГГЛ или Миралинксе релевантную статью или в требованиях указывайте на это условие, если вы хотите контекстную ссылку.

Если тема вам интересна, можете протестировать Top2Vec и BERTopic или попроще TF-IDF с Word2Vec.

Вопрос от Андрея Сороки по показам в Google:

Мне может кто-то объяснить как так получается, что показы на сайте в консоль растут на проекте одном - но средняя позиция - 60. То есть по логике мою страницу в среднем человек видит на 60 странице ?

Кто туда долизывает и как так может быть много показов и почти нет кликов ? По логике пр такой позиции средней по всем ключам столько показов просто быть не должно, или не прав?)

Для начала самая простая ситуация - у нас страничка (url) ранжируется по 5 ключам. Средние позиции каждого ключа (8,70,70,72,80). Высчитываем среднюю позицию страницы (8 + 70 + 70 + 72 + 80) / 5 = 60 = средняя позиция.
По показам то же самое. К примеру сумма всех ключей 200 показов. Из них 150 показов 8 места, у остальных по 5-10. Для 8 места средний органический ctr = в районе 1.62 % = получим около 2 кликов с копейками (на практике у меня в рунете ctr в разы ниже для 8 места и для своей выдачи я возможно бы и не получил клики).
Также нужно учитывать что вы смотрите среднюю позицию в моменте, как правило среднюю средней. Каждый по своему выставляет диапазон дат, но я как правило смотрю диапазон в 3 месяца. Как вы понимаете, за это время страницы могут быть как в топе (генерируя показы и клики, так и вылететь за +40 среднюю позицию, а потом снова вернуться).

Окей скажите вы, с страницами все понятно. Но откуда на 60 позиции конкретного ключа генерируется 30 показов? Неужели люди туда доходят?

Варианты - мигание в топе, когда вы топ 10, то топ 100. Второе - это персональная выдача, где вы для всех на 60 месте, но для пользователя который не раз ваш сайт посещает на 3 месте. Это региональная выдача, где за счет лучшего ctr вы в топе. Третье - это искусственные показы сгенерированные Ахрефсом, Семраш, AL ботами которые постоянно сканируют выдачу на новый контент с помощью которого можно обучить нейросеть. Это скан позиций, вредоносные парсеры, сервисы LSI, поиска n-gram и так далее. Многие парсеры выдачи получают сразу топ 100 выдачу, показ засчитывается, но ваш сайт никто не видел, парсер сразу импортирует топ 100 url с title и описанием.

Но как быть с ситуацией, когда у вас к примеру 4 позиция в Google , 1000 показов и 0 кликов или ctr в десятые доли процента? Бывает и такое.

Основные причины такой ситуации:
1) Много рекламы + у вас очень плохой сниппет.
2) Фичи в выдаче - к примеру в обычной выдаче блок с картинками. Например по запросу "виды грибов" вы можете показываться на первой позиции, но при этом сайт будет в вкладке "еще 6 изображений"
3) Вы в "Вопросы по теме"
4) Вы в топе по брендовым запросам, по которым может быть 10К показов и пару кликов, потому что люди ищут конкретный бренд или сайт.
5) Ваш сайт вышел в топ по стране в которой ваш сниппет непривлекательный (у меня была ситуация где я получил 3000 показов для русскоязычного сайта из ОАЭ в выдаче ). Для понимания представьте что вы увидите нечто подобное - сильно хочется кликать? А для араба из ОАЭ русский в выдаче выглядит такими же крокозябрами.

Нужны ли подобные посты на канале? Потому что кому то они покажутся элементарными и хочется контент на более senior уровень? Накидайте редакций, там и лайки и дизлайки есть.

#seo #google

Роскомнадзор заблокировал все сайты с технологией Encrypted Client Hello (ECH), поэтому если вы юзаете Cloudflare пора действовать.
1. SSL > Edge Certificates > TLS 1.3 - Выключить.

2. Caching > Configuration > Purge Everything - Сбросить кэш

Если у вас бесплатная версия, то решение через API тут.

Обсуждение проблемы на Серче.

Вроде бы сам Cloudflare пытается что то сделать, судя по Хабру.

Если просуммировать, то думаю с сервиса Cloudflare пора валить, так как РКН ему жить не даст.

Наверное подписчики заметили снижение количества постов последние 4 месяца. Почему не постил?

Знакомые знают, но в блоге я особо не писал, что в 2021 году я пошел получать высшее образование (в почти 35 лет). За это время я апнул бакалавра и магистра (оба красных диплома) по специальности "Компьютерные науки".🧨

Последние пару месяцев я работал с дипломной работой, которую я для себя выбрал. Она напрямую связана с seo оптимизацией, а конкретно семантическим поиском и использованием LLM типа BERT.

Таким образом удалось нехило прокачаться не только в общем понимании работы LLM на основе трансформеров, но и использовать их на практике, работая как с чистым BERT, так и LaBSE для организации поиска с использованием векторных представлений с помощью косинусного расстояния. С BERT удалось поработать не только как пользователь, но и обучать нейронную модель на основе своего датасета.
Паралельно прокачал опыт работы с Python и Streamlit, методами оптимизации задач, хешированием, парсингом.
Кому особенно интересно, может глянуть презентацию работы (на украинском языке).

Летом и в начале осени много времени уделил сливу параметров Гугла. Мое личное мнение - большинство зря полноценно не анализируют этот слив, потому что описание того что запостили блогеры в первый месяц - это все очень поверхностная аналитика. Я до сих пор нахожу все больше и больше важной информации, но не до конца понятно, а нужно ли это в блоге, так как она интересна больше Senior SEO специалистам.

В общем обещаю больше постов в телеграм канал, так как свободного времени стало больше🥹

🔥 Расчет релевантности текстов с помощью нейронных сетей
Скрипт на Python использует LaBSE для оценки текстовой релевантности через косинусную близость. Это мощный инструмент для анализа запросов, статей и URL из выдачи.

📌 Как начать
1️⃣ Установите Python и PyCharm .
2️⃣ Скачайте код с GitHub.
3️⃣ Запустите. При первом старте загрузится нейронная сеть LaBSE (2 ГБ).

📊 Возможности

Проверка релевантности абзацев и заголовков, title.
Автоматическое скачивание текстов из сайтов и расчет семантической релевантности.

Полное описание запуска, работы и скриншотов на сайте

Почти 2 месяца назад я увидел видео от Синди Крум, в котором она утверждала, что Гугл уже давно использует наш Google Chrome для рендеринга JS страничек сайтов прямо на наших мобильных устройствах. Тут короткая статья по теме.
Так как тема очень мне интересна, я решил организовать проверку этого утверждения.
По логике все происходило так:
Пользователь телефона заходил на страничку. Гугл определял, что страница не проиндексирована и отправлял страницу себе с нашего телефона. Далее уже на своих мощностях читал содержимое и решал, стоит ли индексировать или нет.

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

Для проверки этого утверждения я набросал скрипт, который может отловить бота на странице (js+php+mysql). Далее создал страницу html с статьей в отдельной папке (это нужно чтобы гугл не нашел случайно страницу из данных GA,XML карты или д.р.). Для работы с страницей использовался браузер который 100% не сливает данные (Google Chrome, Firefox или Operu не использовал).

С помощью AirtestIDE создал скрипт автоматизирующий действия на своем телефоне в Google Chrome (мне важно было создать скрипт заранее, так как если бы это не возможно автоматизировать - то зачем вообще проверять?)
В результате после 2 месяца я могу сказать:
Теория Синди Крум не подтвердилась. Хотя я не один раз пытался заходить на свой сайт, паралельно просматривая другие сайты, бот так и не пришел.
Я дополнительно проксировал телефон и смотрел, что при просмотре сайтов на телефоне Google Chrome довольно много отправляет данных на свои сервисы (к сожалению зашифровано), но индексирующий бот так и не пришел.

Я пробовал как Wi-FI трафик, так и загрузку страницы с мобильного трафика (была мысль что Гуглу нужны дополнительные данные ). Дополнительно проверил теорию о том, что индексирующий бот может прийти после проверки в сервисе Chrome-Lighthouse - тоже неудачный эксперимент.

И хотя в целом эксперимент неудачный, именно через такие эксперименты вы можете стать senior SEO специалистом. Не верить кому то на слово, несмотря на все регалии и титулы, а проверять самостоятельно.

Ну и напоследок - код отлова бота надо? Может задумаетесь над своими экспериментами. Если нужен - налепите огоньков под постом.

Обещанный скрипт для отлова ботов Google. Скрипт собирает все ip и юзерагенты зашедших на тестовую страницу. Работает даже с кешированными страницами.
В тестовой странице test.html в самом низу вставлен скрипт, который записывает ip и юзерагент в базу данных с помощью write.php.
Посмотреть записанные данные можно с помощью log.php.
В subnets.txt хранятся ip и подсети Google ботов (список не полный, можете редактировать)

Как протестировать.
Создаем с помощью FTP папку и заливаем туда файлы.
В файлы write.php и log.php прописываем данные для подключения к базе данных Mysql.
Создаем таблицу в базе данных (к примеру в Cpanel) заходим в Базы данных->PhpMyAdmin-> выбираем базу данных и переходим в вкладку SQL.
Выполняем код:

CREATE TABLE user_ip_data (
id INT(11) AUTO_INCREMENT PRIMARY KEY,
ip_address VARCHAR(45),
user_agent TEXT,
date_time DATETIME
);

База создана, теперь у вас все должно работать. Проверяем:
1) Переходим по url https://mysite.com/papka/test.html
2) Заходим на https://mysite.com/papka/log.php и увидите свой ip и юзерагент.
3) Проводите эксперименты, привлекая бота на https://mysite.com/papka/test.html

Ссылка на архив.

Если будет интерес, доработаю функционал, тот который напрашивается больше всего - работа с WordPress, показ стран ip и другое.

Много кто считает туристическую тематику не сильно конкурентной. Но это много лет не так. Многие услуги (продажа туров, экскурсий, билетов) попадают под YMYL (с англ. Your Money or Your Life, или дословно «Твои деньги или твоя жизнь»). Поэтому конкуренция тут не хуже медицины или финансов. Кроме этого без внедрения факторов EEAT ранжироваться сложно.

В сливе факторов ранжирования Гугла есть модуль GoogleApi.ContentWarehouse.V1.Model.QualityTravelGoodSitesData который описывает структуру данных помогающих ранжировать сайты туристической тематики. Стоит уточнить, что это не основной модуль, так как основа ранжирования туризма - это прежде всего local SEO.

Давайте пройдемся по основным атрибутам этого модуля.

i18n - Список локализованных версий данных, связанных с сайтом. Фактически это привязка к языку или локальным регионам (напомню что в Гугле работает Local Authority Links - это метод повышения веса ссылок локальным сайтам, к примеру когда сайт на домене fr ссылается на французский сайт).

isAggr - флаг указывающий на агрегатор или агрегацию данных (пример - Букинг или Tripadvisor). По многим нишам агрегаторы имеют приоритет, так как считается что они не являются ангажированными при формировании подборок данных (топ экскурсий, ресторанов и т. д. ).

isAttractionOfficial - официальный источник информации для туристической достопримечательности. Таким сайтам Гугл дает приоритет по кластерам запросов связанным с достопримечательностью. Пример - официальный сайт Лувра.

isHotelOfficial - Аналог для отелей.

isEntity - Указывает, связан ли сайт с конкретной сущностью (например, отель, достопримечательность, курорт). Это может быть полезно для определения релевантности сайта по запросам, связанным с этими сущностями. Кто не понимает о чем речь - гляньте скриншот.

normalizationFactor - данные могут быть в разных числовых значениях и требуют нормализации, к примеру к [0:1].

signal - Список сигналов, связанных с качеством туристического сайта. Это могут быть различные метрики, такие как пользовательские оценки, репутация, поведенческие факторы и т. д.

site - Url сайта

totalScore - сумма всех факторов после нормализации.

type - возможно тип сайта (информационный, коммерческий и т.д.) или по описанию (блог, форум, социальная сеть, каталог, сервис). Может использоваться для отдельных кластеров запросов ранжирования, к примеру для отзывов по достопримечательностях, где нужно давать приоритет форумам, блогам или соцсетям.

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

🔍 Яндекс обновил алгоритмы поиска — качество контента теперь важнее, чем когда-либо


Яндекс внедрил масштабные обновления в своих алгоритмах. Теперь в приоритете — реально полезный контент, а не просто тексты, сгенерированные ИИ на автомате и содержащие низкоуровневый контент.

✅ Точность распознавания низкокачественных и ИИ-сгенерированных страниц выросла до 99%
📉 Количество сомнительных сайтов на первой странице результатов поиска сократилось в несколько раз


📌 Важно: использование нейросетей не запрещено, но контент должен быть ценным, проверенным и не вводить в заблуждение.



🚫 Сайты, маскирующие некачественные тексты под видом экспертного контента, будут терять позиции.
📈 А вот проекты с действительно качественными материалами — получат рост трафика.

Отдельно Яндекс упомянул о том, что использование траста старых доменов (например перехваченных), если они будут злоупотреблять низким контентом - будет ограничено.
Привет всем строителям PBN сеток на перехваченных доменах на ауках. В тоже время похоже что апдейт уже активирован и если вас сильно не покосило - все будет ок.

В процессе работы над дипломным проектом в университете я выделил много времени для работы с BERT. И в процессе обнаружил, что BERT как то очень плохо работает с семантической релевантностью. Напомню, что я написал парсер основных сайтов вакансий работы в Украине и реализовал векторный поиск с помощью BERT (LaBSE). При этом чистый BERT показывал очень плохие результаты.

Когда контекст понятен, вроде запроса "вакансия seo специалиста" , все работает как часы. BERT отлично справляется даже с редкими вакансиями и запросами (хотя тут и bm25 справился).
Но стоит использовать запросы что то вроде "вакансия seo специалиста без знания английского" и BERT не в состоянии дать нормальный ответ, так как по его логике используя косинусную близость ты фактически ищешь по доп ключу "английский" и он не понимает смысла "без".
В процессе оказалось, что то что чаще всего приписывают BERT по настоящему реализовывают алгоритм Колибри и RankBrain, он не шарит не в контекст, не в интент.

К примеру RankBrain задает дополнительные веса релевантности обрабатывая данные по кликам и конечным намерениям пользователя.
Для использования BERT в задачах семантической релевантности часто требуется его дополнительное обучение (fine-tuning) на специфических наборах данных, содержащих пары предложений с оценками их семантического сходства.
Тогда проявляется вся мощь классификации в алгоритме. Классический же BERT это просто расширенный word2vec с точки зрения релевантности.

Имея набор данных dataset 25000 профессий, я взял чистый BERT и дообучил его на этих данных для конкретной задачи - классификации вакансий по запросу, чтобы нейронная сеть угадывала по вакансиям (текст вакансии + заголовок) профессию.
С помощью Python и Google Colab обучил BERT на своих данных (общий процес занял более 8 часов). В результате моя обученная модель угадывала профессии с точностью 60%.
Так как датасет был только по IT профессиям, основные ошибки делались на схожих профессиях, к примеру SEO или SMM специалист, могла попутать Котлин и Java программиста.

При проверке оказалось, что из 25К вакансий всего около 350 профессий, причем данные распределяются по принципу Парето, то есть по большинству профессий не хватает данных для обучения, отсюда и такие плохие результаты.

Вместо вывода - чистый BERT без набора данных у SEO специалиста - довольно слабая вещь для расчета текстовой релевантности (и это не только мой вывод). У Гугла все хорошо работает именно по той причине, что он накопил много данных для расчетов и обучения нейросети. Но если вы задумаетесь использовать BERT для себя, используйте модели с Sentence Embedding (Sentence-BERT (SBERT), LaBSE). Именно они идеально годятся для расчета текстовой релевантности как Title, h1 или всего текста статьи, а также в расчетах siteEmbeddings и pageEmbeddings.