Утечка внутренней документации Гугл. Часть 1: Мифы + поведенка + Twiddlers.
Все уже увидели, что слили документацию Гугла. Кому лень читать всю - я сделал для себя выдержку разбора, делюсь с вами.
В документации описано 2,596 модулей API, содержащих 14,014 атрибутов (функций).
Все модули связаны с компонентами YouTube, Google Assistant, Google Books, видео-поиском, ссылками, веб-документами, инфраструктурой для сбора данных, внутренней календарной системой и People API.
Очень часто документация ссылается на страницы, которые являются URL-адресами внутренней сети Гугл и требуют учетных данных Гугл для доступа. Без доступа к этим страницам остаётся только интерпретировать доступную информацию самостоятельно.
Представители Гугл намеренно вводят в заблуждение пользователей и специалистов относительно работы своих систем. Вещи заявленные как не рабочие - работают.
Основной пример “Авторитет домена” ("siteAuthority") - используется в системе ранжирование. Утверждалось обратное.
Заявленное “Не использования кликовых (поведенческих) факторов” для ранжирования, также опровергнуто. С 2005 года используется система Navboost, которая использовала кликовые данные собранные за последние 18 месяцев. С недавнего времени - 13 месяцев.
Инженер Гугл Paul Haahr заявлял, что “использование в ранжировании кликов непосредственно на поисковой выдаче - было бы ошибкой”. При этом Navboost имеет модуль полностью заточенный под “показы и клики”. Данный модуль включает в себя: плохие клики, хорошие клики, последние длинные клики, unsquashed clicks, а также unsquashed last longest clicks. Под словом “Squashing” согласно патенту Гугла мы подразумеваем функцию, которая не позволяет одному большому сигналу доминировать над другими.
Другой модуль с индексацией сигналов имеет метрику “Последний хороший клик”, метрика которая может указывать на неактуальность контента на странице.
Гугл считает и хранит общее количество плохих кликов и сегментирует их по странам и устройствам.
Здесь я немного поспорю с автором. Если мы говорим о вышеперечисленном, то проводя аналогию с Яндексом, все это факторы поведенки внутри сайта, но не СЕРП. Поэтому заявление Paul Haahr’а все еще имеет смысл.
Все указывает на то, что NavBoost "уже является одним из самых сильных сигналов рейтинга Гугл". В утечке присутствует 84 упоминания Navboost и 5 модулей с Navboost в названии. Также есть сведения о том, что для поддомена/морды/внутр урла действует своя формула расчета.
Миф о “песочнице” - развеян. В модуле “PerDocData” имеется атрибут “hostAge” направленный исключительно для помещения в песочницу свежих спам сайтов в целях защиты выдачи.
Миф “мы не используем ничего из Гугл Хром для ранжирования”. Один из модулей использует статистику посещений из Хром, также атрибут Гугл Хром есть в модуле связанном со ссылками.
В документации вводится понятие “Twiddler”.
Twiddlers - это функции, которые изменяют ранжирование результатов поиска после работы основного алгоритма Гугл. Они работают подобно фильтрам на странице, изменяя отображаемый контент прямо перед его показом пользователю.
Основные функции Twiddlers:
Изменение ранжирования: Корректируют баллы и позиции документов в результатах поиска.
Категорийные ограничения: Ограничивают количество результатов определенного типа, например, до трех блогов на одной странице выдачи.
Эксперименты и Boost-системы: Многие системы, такие как Panda, начинали как Twiddlers и позже интегрировались в основной алгоритм.
Примеры Boost-систем:
NavBoost: Улучшает навигационные результаты.
QualityBoost: Повышает качество результатов.
RealTimeBoost: Обрабатывает результаты в реальном времени.
WebImageBoost: Оптимизирует результаты для веб-изображений.