Секреты алгоритма поисковика Google

Google, если ты читаешь это, то уже слишком поздно. 😉

Итак. Перейдём сразу к делу и утечке алгоритма Google.

Недавно была опубликована внутренняя документация API (интерфейс программирования приложения — п.п.) хранилища контента Google Search. Похоже, что внутренние микросервисы Google имитируют Google Cloud Platform, — и внутренняя версия документации устаревшего Document AI Warehouse случайно попала в репозиторий кода для клиентской библиотеки. Документацию этого кода также обнаружили внешним автоматизированным сервисом документации.

Судя по истории изменений, ошибка в хранилище кода была исправлена 7 мая, но автоматизированная документация всё ещё не удалена. В целях ограничения потенциальных претензий я не буду приводить ссылки на неё. Но поскольку весь код в этом репозитории был опубликован под лицензией Apache 2.0, любой, кто на него наткнётся, в любом случае получит широкий набор прав, включая возможность использовать, изменять и распространять его.

Я изучил справочные документы по API и сопоставил их с предыдущими утечками Google и показаниями антимонопольного ведомства Министерства юстиции. Я также использовал материалы для своей предстоящей книги «Наука SEO», где подробно исследовал патенты и техническую документацию. Хотя в просмотренной мной документации и нет никаких подробностей об оценочных функциях Google, там есть множество информации о контенте, ссылках и взаимодействии пользователей. В документах также содержатся различные описания (от разочаровывающе скудных до удивительно откровенных) ключевых функций, которыми можно управлять.

Может возникнуть соблазн обобщающе назвать эти функции «факторами ранжирования», но это было бы слишком неточно. Многие из них, даже большинство, — это действительно факторы ранжирования, но многие — нет. Здесь я расскажу о некоторых наиболее интересных системах и функциях ранжирования (по крайней мере, о тех, которые мне удалось найти за первые несколько часов изучения этой масштабной утечки), опираясь на свои масштабные исследования и то, о чём Google рассказывал/лгал нам на протяжении многих лет.

«Лгал» — это немного грубо, но это единственное слово, которое подходит. Хотя я и не осуждаю публичных представителей Google за желание защитить свою внутреннюю корпоративную информацию, я считаю проблематичными их попытки активной дискредитации людей из мира маркетинга, технологий и журналистики, которые публиковали свои открытия об этом. Мой совет будущим сотрудникам Google, выступающим на подобные темы: иногда лучше просто сказать: «Мы не можем об этом говорить». Ваш авторитет важен, и когда появляются такие утечки, как эта, и такие показания, какие вы давали на заседании в Минюсте, доверять вашим будущим заявлениям становится невозможно.

Несколько оговорок

Я думаю, мы все понимаем, что многие будут пытаться дискредитировать мои выводы и анализ этой утечки. Некоторые будут задаваться вопросом, почему это хоть сколько-либо значимо, и говорить: «Но мы и так это знали». Так что давайте я дам несколько пояснений, прежде чем мы перейдём к главному.

• Ограниченное время и контекст. Из-за праздничных выходных я смог продуктивно потратить на всё это только около 12 часов. Я невероятно благодарен некоторым анонимным людям, которые очень помогли мне своими соображениями, чтобы быстро ввести меня в курс дела. Кроме того, как и в случае с утечкой из «Яндекса», о которой я рассказывал в прошлом году, полной картины у меня нет. Если в случае с «Яндексом» у нас для разбора был исходный код, но не было никаких размышлений, за ним стоящих, то в этом случае мы можем понять, что именно стоит за тысячами функций и модулями, но исходного кода не имеем. Вы должны простить меня за то, что я рассказываю об этой утечке в менее структурированном виде, чем через несколько недель, когда я посижу с материалом подольше.

• Отсутствие оценочных функций. Мы не знаем, какой вес имеют характеристики в различных оценочных функциях. Мы не знаем, используются ли все доступные функции, но знаем, что некоторые функции устарели. Если это не указано напрямую, мы не знаем, как используются те или иные функции. Мы не знаем, какое именно место что занимает в процессе. У нас есть ряд систем ранжирования, которые приблизительно согласуются с тем, как их объясняет Google, как SEO-специалисты (специалисты по поисковой оптимизации — п.п) наблюдают ранжирование в естественных условиях и как объясняют патентные заявки и литература по поиску информации. В конечном счёте, благодаря этой утечке теперь мы имеем более чёткое представление о том, на чём в будущем можно заострить внимание при работе с SEO, а что можно проигнорировать.

• Скорее всего, это первый из нескольких постов. Этот пост — мой первичный анализ обнаруженной информации. Я буду публиковать последующие посты по мере того, как буду копаться в деталях. Подозреваю, что эта статья приведет к тому, что SEO-сообщество бросится разбирать эти документы, и мы все вместе будем открывать новое и переосмысливать их в течение следующих месяцев.

• Это актуальная информация. Насколько я могу судить, эта утечка представляет собой текущую, действующую архитектуру хранилища поискового контента Google по состоянию на март 2024 года. (Жду, когда пиарщик Google скажет, что я не прав. Давайте уж обойдёмся без этих отговорок). Судя по истории коммитов, соответствующий код был размещён 27 марта 2024 года и удалён только 7 мая 2024 года.

• Корреляция — не причинно-следственная связь. Хорошо, здесь это не совсем применимо, но я просто хотел перестраховаться.

В утечке документов Google — 14 тысяч факторов ранжирования и многое другое

В документации API представлено 2 596 модулей с 14 014 атрибутами (факторами), которые выглядят следующим образом:

Модули связаны с компонентами YouTube, Assistant, Books, видеопоиска, ссылок, веб-документов, инфраструктуры краулинга (обнаружение и сбор информации с последующей загрузкой в поисковую систему — п.п.), внутренней системы календаря и API контактов. Как и у «Яндекса», системы Google работают на основе монолитного репозитория (или «монорепо»), а машины функционируют в общей среде. Это означает, что весь код хранится в одном месте и любая машина в сети может быть частью любой из систем Google.

Утекшая документация описывает каждый модуль API и разбивает его на аннотации, типы, функции и атрибуты. В основном мы видим определения свойств различных протокольных буферов (или протобуферов), к которым обращаются системы ранжирования для создания SERP (Результаты поисковой системы — то, что Google выдаёт после выполнения запроса).

К сожалению, многие аннотации ссылаются на ссылки Go, которые представляют собой URL-адреса в корпоративной интрасети Google, предлагающие дополнительные сведения о различных аспектах системы. Без соответствующих учётных данных Google, необходимых для открытия этих страниц (а для этого почти наверняка нужно быть действующим сотрудником в команде поиска Google), нам остаётся только делать предположения.

Документация по API открывает глаза на некоторую важную ложь Google

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

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

«У нас нет ничего похожего на авторитет домена».

Представители Google много раз говорили, что не используют «авторитет домена» (комплексный показатель, который отображает качество сайта — п.п.). Я всегда считал, что это ложь через замалчивание и умышленное сбивание с толку.

Говоря, что они не используют авторитет домена, они могут иметь в виду, что не используют метрику Moz под названием «aвторитет домена» (очевидно 🙄). Они также могут говорить, что не измеряют авторитет или важность конкретной темы (или домена) применительно к веб-сайту. Эта путаница в семантике позволяет им никогда напрямую не отвечать на вопрос о том, вычисляют ли они или используют ли метрики авторитета для всего сайта.

Гэри Айлес, аналитик из поисковой команды Google, который занимается публикацией информации для помощи создателям сайтов, неоднократно повторял это утверждение.

И Гэри не одинок. Джон Мюллер, «апологет поиска, который координирует связи в поисковой команде Google», заявил в этом видео: «У нас нет показателей авторитета сайта».

На самом деле у Google есть параметр под названием «siteAuthority» — это часть Сжатых показателей качества, которые хранятся в каждом отдельном документе.

Мы не знаем, как именно вычисляется этот показатель и как он используется в последующих оценочных функциях, но теперь мы точно знаем, что он существует и используется в системе Q-ранжирования (коэффициент известности и привлекательности — п.п.). Оказывается, Google действительно пользуется общим авторитетом домена. А теперь сотрудники Google должны заявить, что, мол, «он у нас есть, но мы его не используем», или «вы не понимаете, что это значит», или... Подождите, я обещал вам «ограниченные комментарии», да? Идём дальше.

«Мы не используем число кликов для ранжирования»

Давайте разберёмся с этим раз и навсегда.

Показания Панду Наяка в антимонопольном процессе Минюста США недавно раскрыли существование систем ранжирования Glue и NavBoost. NavBoost — это система, использующая основанные на кликах пользователей меры для повышения, понижения или иного воздействия на рейтинг страниц в веб-поиске. Наяк отметил, что NavBoost существует примерно с 2005 года и исторически использует данные о кликах за 18 месяцев. Недавно система была обновлена и теперь использует данные за 13 месяцев и ориентирована на результаты веб-поиска, в то время как система под названием Glue связана с другими результатами универсального поиска. Но ещё до этого откровения существовало несколько патентов (в том числе патент 2007 года на ранжирование по времени), которые конкретно указывают на то, как протоколы кликов могут быть использованы для изменения результатов.

Мы также знаем, что использование кликов как показателя успеха — это лучшая практика в области получения информации. Мы знаем, что Google перешел на алгоритмы машинного обучения (ML), а ML требует переменные отклика для улучшения своей работы. Несмотря на эти ошеломляющие доказательства, в SEO-сообществе до сих пор царит путаница, вызванная представителями Google и постыдными статьями в мире поискового маркетинга, которые без какой-либо критики повторяют публичные заявления Google.

Гэри Айлес неоднократно говорил об этой проблеме измерения кликов. В одном случае он подтвердил слова инженера Google Search Пола Хаара о живых экспериментах, сказанные в его выступлении на SMX West в 2016 году: «Использование кликов непосредственно при ранжировании было бы ошибкой».

Однако позже он, как известно, использовал свою платформу, чтобы унизить Рэнда Фишкина (основателя/генерального директора Moz и давнего SEO-практика), сказав, что «время пребывания на странице, CTR (коэффициент кликабельности — п.п) или какая бы другая новая теория ни возникла у Фишкина, всё это — выдуманная чушь».

На самом же деле у Navboost есть особый модуль, который полностью заточен на кликабельность.

Этот модуль в аннотации описывается как «сигналы кликов и показов для Craps», одной из систем ранжирования. Как мы видим ниже, в качестве показателей рассматриваются плохие клики, хорошие клики, длящиеся дольше всего клики, несквошированные клики и несквошированные длящиеся дольше всего клики. Согласно патенту Google «Оценка локальных результатов поиска в зависимости от популярности в регионе», «сквошинг — это функция, которая не позволяет одному сильному сигналу подавить остальные». Другими словами, системы нормализуют данные о кликах, чтобы исключить возможность манипуляций на основе сигнала клика. Сотрудники Google утверждают, что системы, описанные в патентах и технических документах, не обязательно используются в производстве, но было бы нелепо создавать и включать в систему NavBoost, если бы она не была важной частью систем поиска информации Google.

Многие из этих основанных на кликах измерений можно найти и в другом модуле, связанном с индексированием сигналов. Одна из метрик — дата «последнего хорошего клика» на определённый документ. Это позволяет предположить, что упадок контента (или потеря трафика со временем) тоже является функцией ранжирования страниц, которые не набирают ожидаемое количество кликов для позиции в SERP.

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

В ней также хранится информация о том, на какой сайт был сделан самый долгий клик в течение сессии. Таким образом, недостаточно просто ввести запрос в поиск и кликнуть на результат: пользователи должны также провести значительное количество времени на странице. Длинные клики — показатель успешности поисковой сессии, как и время пребывания на странице, но в этой документации нет конкретной функции под названием «время пребывания». Тем не менее, длинные клики фактически измеряют тот же показатель, что противоречит заявлениям Google по этому поводу.

Различные источники сообщают, что NavBoost «уже является одним из самых сильных сигналов ранжирования Google». В утекшей документации «Navboost» упоминается 84 раза, причем в пяти модулях он фигурирует в заголовке. Есть также свидетельства того, что его оценка проявляется на уровне поддомена, корневого домена и URL, что явно указывает на то, что они по-разному оценивают разные уровни сайта. Я не буду углубляться в тему различий между поддоменом подкаталогом, но позже мы обсудим, как данные из этой системы повлияли на алгоритм «Панда» (внедрённый в 2011 году алгоритм ранжирования выдачи поисковика Google — п.п.).

Итак, да, в этой документации Google не упоминает «CTR» или «время пребывания» именно в таких формулировках, но суть такая же, как доказал Рэнд: включены клики по результатам поиска и показатели успешной поисковой сессии. Доказательства достаточно убедительны, можно не сомневаться, что Google использует клики и поведение после клика в своих алгоритмах ранжирования.

«Нет никакой песочницы»

Представители Google не раз заявляли, что не существует никакой песочницы, в которую сайты отбираются по времени создания или отсутствию признаков доверия. В удалённом твите Джон Мюллер ответил на вопрос о том, сколько времени требуется для получения права на ранжирование, сказав: «Никакой песочницы нет».

В модуле PerDocData документация указывает на атрибут hostAge, который используется специально «для отсеивания свежего спама в „песочницы“ во время обслуживания».

Оказывается, песочница всё-таки существует. Кто бы мог подумать? А, точно, Рэнд мог.

«Мы не используем ничего из Chrome для ранжирования»

Мэтт Каттс ранее заявлял, что Google не использует данные Chrome в органическом поиске. Совсем недавно это подтвердил Джон Мюллер.

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

Утечка внутренней презентации системы RealTime Boost от мая 2016 года также указывает на то, что данные Chrome используются поиске. Ну в общем вы поняли.

Представители Google — люди благонамеренные, но можно ли им доверять?

Короткий ответ — нет, если вы слишком близко подобрались к его уникальным особенностям.

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

Архитектура систем ранжирования Google

Концептуально можно представлять «алгоритм Google» как что-то единое, некое гигантское уравнение с рядом взвешенных факторов ранжирования. На самом деле он представляет из себя множество микросервисов, в которых множество функций проходят предварительную обработку, а затем становятся доступными при выполнении кода для составления SERP. Судя по различным системам, упоминаемым в документации, таких функций может быть более сотни. Если предположить, что это не все системы, то, возможно, каждая из них представляет собой «сигнал ранжирования», и, возможно, именно таким образом Google достигает 200 сигналов ранжирования, о которых часто говорят.

В докладе Джеффа Дина «Создание программных систем в Google и извлечённые из этого уроки» он упомянул, что ранние итерации Google отправляли каждый запрос на 1 000 машин, которые обрабатывали его и давали результат менее чем за 250 миллисекунд. Он также показал диаграмму ранней версии абстракции архитектуры системы. На этой диаграмме показано, что Super Root — это мозг Google Search, который отправляет запросы и собирает всё воедино в конце.

Заслуженный инженер-исследователь Марк Найорк в своей недавней презентации «Генеративный поиск информации» продемонстрировал абстрактную модель Google Search с системой RAG (она же Опыт генеративного поиска/Обзор ИИ). Эта диаграмма иллюстрирует ряд различных хранилищ данных и серверов, которые обрабатывают различные слои результатов.

Информатор из Google Зак Ворхис опубликовал слайд, на котором показаны взаимосвязи различных систем в компании по их внутренним названиям. Некоторые из них упоминаются в документации.

Используя эти три модели, мы можем начать думать о том, как некоторые из этих компонентов работают вместе. Из документации я понял, что этот API работает на базе Google Spanner. Spanner — это структура, которая позволяет бесконечно масштабировать хранилище контента и вычисления, рассматривая как единое целое ряд компьютеров, объединённых в глобальную сеть.

Конечно, на основе одной лишь документации сложно определить взаимосвязь между всеми элементами, но сводка Пола Хаара может дать хорошее представление о том, что делают некоторые из названных систем ранжирования. Я выделю те, которые мне известны, и распределю их по применению.

Кроулинг (автоматический сбор информации — п.п.)

• Trawler — система веб-кроулинга. Она включает в себя список ожидания, поддерживает скорость кроулинга и даёт информацию о частоте изменений страницы.

Индексирование

• Alexandria — главная система индексирования.

• SegIndexer — система, размещающая документы по уровням в пределах индекса.

• TeraGoogle — вторичная система индексирования для документов, которые хранятся на диске долгосрочно.

Рендеринг

• HtmlrenderWebkitHeadless — система рендеринга для страниц на JavaScript. Интересно, что название идёт от Webkit, а не от Chromium. Chromium упоминается в документации, поэтому вероятно, что Google изначально использовал WebKit, а после появления Headless Chrome переключился на Chromium.

Обработка

• LinkExtractor — извлекает ссылки со страниц.

• WebMirror — система для управления каноникализацией (процесс выбора наиболее подходящего URL — п.п.) и дупликацией.

Ранжирование

• Mustang — первичная система оценки, ранжирования и обслуживания.
      ·   Ascorer — первичный алгоритм ранжирования, который ранжирует страницы до каких-либо коррекций повторного ранжирования.

• NavBoost — система повторного ранжирования, зависящая от кликов пользователей.

• FreshnessTwiddler — система повторного ранжирования для документов, зависящая от даты их создания.

• WebChooserScorer — определяет наименование параметров в оценке сниппетов.

Обслуживание

• Google Web Server (GWS) — сервер, с которым взаимодействует фронтенд Google. Он получает информацию, которая потом отображается пользователям.

• SuperRoot — это мозг Google Search, который отсылает сигналы серверам и управляет системой пост-обработки для повторного ранжирования и отображения результатов.

• SnippetBrain — система, которая генерирует сниппеты результатов.

• Glue — система, которая объединяет общие результаты, используя поведение пользователей.

• Cookbook — система генерирования сигналов. Есть признаки того, что значения создаются во время выполнения задачи.

Как я уже говорил, в этих документах описано ещё много систем, но не совсем понятно, что они делают. Например, SAFT и Drishti из приведённой выше диаграммы также представлены в этих документах, но их функции неясны.

Что такое твиддлеры?

В сети мало информации о твиддлерах в целом, поэтому я думаю, что стоит рассказать о них здесь, чтобы мы могли лучше понять контекст различных Boost-систем, которые видим в документах.

Твиддлеры — это функции повторного ранжирования, которые работают после основного поискового алгоритма Ascorer. Они работают аналогично фильтрам и действиям в WordPress, где отображаемые данные, корректируются непосредственно перед тем, как быть представленным пользователю. Твиддлеры могут корректировать оценку информационного поиска документа или изменять его рейтинг. Многие существующие эксперименты и названные выше известные нам системы реализованы именно таким образом. Как показывает этот бывший сотрудник Google, они очень важны для различных систем:

Твиддлеры могут делать ограничения по категориям, то есть разнообразие можно поощрять, специально ограничивая тип результатов. Например, автор может решить, что в данном SERP будет только 3 записи из блога. Это может объяснить потерю уровня ранжирования из-за формата страницы.

Когда Google говорит, что что-то вроде «„Панда“ не была частью основного алгоритма», это, скорее всего, означает, что изначально её запустили в качестве твиддлера для повышения или понижения рейтинга и затем она перешла в основную оценочную функцию. Это также можно представить как разницу между рендерингом на стороне сервера и на стороне клиента.

Предположительно, любая из функций с суффиксом Boost работает с использованием фреймворка твиддлеров. Вот некоторые из них в документации:

• NavBoost (навигация — п.п)
• QualityBoost (качество — п.п.)
• RealTimeBoost (режим реального времени — п.п.)
• WebImageBoost (веб-изображения — п.п.)

Названия говорят сами за себя.

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

Главные открытия, которые могут повлиять на проведение SEO

Давайте перейдём к тому, ради чего вы, собственно, и пришли. Что такого делает Google, чего мы не знали или в чём не были уверены, и как это может повлиять на работу с SEO?
Небольшое замечание, прежде чем мы продолжим. Моя цель — познакомить SEO-индустрию с новыми концепциями. Я не ставлю перед собой задачу предоставить вам рецепт успеха и рассказать, как пользоваться этой информацией в вашем конкретном случае. Если вы хотите именно этого, вам стоит нанять iPullRank для вашего SEO. Здесь будет достаточно информации, из которой можно сделать выводы и разработать свои собственные сценарии использования.

Как работает «Панда»

Когда появилась «Панда», было много путаницы. Работает ли она с помощью машинного обучения? Используются ли сигналы пользователей? Почему нужно обновлять или перезагружать, чтобы восстановить страницу? Она действует на всём сайте? Почему теряется трафик для определённого подкаталога?

«Панда» была выпущена под руководством Амита Сингхала. Он был категорически против машинного обучения из-за его ограниченной наблюдаемости. Более того, существует ряд патентов, посвящённых качеству сайтов для «Панды», но я хочу остановиться на одном из них — неприметном «Ранжировании результатов поиска». Патент поясняет, что «Панда» гораздо проще, чем мы думали. Речь идёт в основном о создании модификатора оценки на основе распределенных сигналов, связанных с поведением пользователей и внешними ссылками. Этот модификатор может применяться на уровне домена, субдомена или подкаталога.

«Система генерирует коэффициент модификации для группы ресурсов на основе подсчёта независимых ссылок и подсчёта ссылочных запросов (шаг 306). Например, коэффициент модификации может представлять собой отношение количества независимых ссылок для группы к количеству ссылочных запросов для группы. То есть коэффициент модификации (M) можно выразить так:
 
M=IL/RQ,
 
где IL — количество независимых ссылок, подсчитанных для группы ресурсов, а RQ — количество ссылочных запросов, подсчитанных для группы ресурсов».

Независимые ссылки — это по сути связывание корневых доменов, но ссылочные запросы играют немного большую роль. Вот как они определены в патенте:

«Ссылочной запрос для определенной группы ресурсов может быть ранее отправленным поисковым запросом, который был классифицирован как ссылающийся на ресурс в определённой группе ресурсов. Категоризация конкретного ранее отправленного поискового запроса как относящегося к ресурсу в конкретной группе ресурсов может включать: определение того, что конкретный ранее отправленный поисковый запрос включает в себя один или более терминов, которые были определены как относящиеся к ресурсу в конкретной группе ресурсов».

Теперь, когда у нас есть доступ к документации, стало понятно, что ссылочные запросы — это запросы из NavBoost.

Это означает, что обновления «Панды» были просто обновлениями скользящего окна запросов, подобно тому, как работают расчёты Core Web Vitals. Это также может означать, что в «Панде» обновления ссылочного графа не обрабатывались в режиме реального времени.

Не хотелось бы повторяться, но в другом патенте «Панды» под названием «Оценка качества сайта» также рассматривается показатель, который представляет собой соотношение между ориентирными запросами и пользовательскими выборами или кликами.

Суть в необходимости большего числа успешных кликов по более широкому набору запросов и получении большего разнообразия ссылок, чтобы продолжать ранжироваться. Концептуально это имеет смысл, потому что именно это будет происходить с очень сильным контентом. Фокус на привлечении более квалифицированного трафика и улучшении пользовательского опыта даст Google сигнал, что ваша страница заслуживает ранжирования. Следует сосредоточиться на этом же, чтобы восстановиться после обновления «Полезного контента».

Авторство — это отдельный параметр

Об E-E-A-T (Экспертность, авторитетность и достоверность — п.п.) написано немало. Многие SEO-специалисты не верят в эту идею из-за того, насколько туманны оценки экспертности и авторитетности. Я также ранее подчёркивал, как мало на самом деле в Интернете мало пометок об авторстве. До того как я узнал о векторных эмбеддингах, я не верил, что авторство — достаточно практичный сигнал в масштабах сети.

Тем не менее, Google, очевидно, использует авторов как текстовую переменную в документах

Они также пытаются определить, является ли объект страницы её автором.

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

Понижение в ранжировании

В документации обсуждается ряд алгоритмических понижений. Их описание ограничено, но они заслуживают упоминания. Мы уже обсудили «Панду», но остальные инструменты для понижения, с которыми я сталкивался, это:

• Anchor Mismatch. Когда ссылка не соответствует сайту, на который она должна отсылать, то приоритет этой ссылки опускается в расчётах. Как я уже говорил, Google проверяет релевантность по обе стороны ссылки.

• SERP Demotion. Сигнал о понижении, зависящий от факторов из SERP, который предполагает потенциальное недовольство пользователей страницей с помощью измерения кликов.

• Nav Demotion. Предположительно, это понижение относится к страницам, которые используют неподобающую практику навигации или на которых у пользователей возникают проблемы.

• Exact Match Вomains Demotion. В конце 2012 года Мэтт Кертис объявил, что точное соответствие доменов не будет иметь столько же значения, как раньше. Для их понижения существует специальная функция.

• Product Review Demotion. Какой-то точной информации нет, но эта функция находится в списке понижений и скорее всего связана с недавним обновлением 2023 года о обзорах продуктов.

• Location demotions. Похоже, что «глобальные» и «супер глобальные» страницы тоже могут быть понижены. Можно предположить, что таким образом Google пытается привязать страницы к локации и соответствующим образом их ранжировать.

• Porn demotions (понижение порно — п.п.). Ну, тут все довольно очевидно.

• Other link demotions (понижение других ссылок — п.п.). Это мы обсудим далее.

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

Похоже, что ссылки всё ещё очень даже важны

Я не видел никаких доказательств, опровергающих недавние заявления о том, что ссылки считаются менее важными. Опять же, этим, скорее всего, занимаются сами оценочные функции, независимо от того, как хранится информация. Тем не менее, извлечению и разработке функций для глубокого понимания графа ссылок было также уделено большое внимание.

Уровень индексирования влияет на качество ссылки

Метрика под названием sourceType показывает неявную зависимость между тем, как индексируется страница, и её важностью. Для справки: индекс Google разделён на уровни, где наиболее важный, регулярно обновляемый и посещаемый контент хранится во флэш-памяти. Менее важный контент хранится на физических накопителях, а нерегулярно обновляемый — на обычных жёстких дисках.

По сути это означает, что чем выше уровень, тем ценнее ссылка. Страницы, которые считаются «свежими», также считаются высококачественными. Достаточно сказать, что вы хотите, чтобы ваши ссылки приходили либо со свежих страниц, либо со страниц, иным образом оказавшихся в верхних уровнях. Это частично объясняет, почему ранжирование с высокорейтинговых и новостных страниц даёт лучшие показатели ранжирования. Посмотрите, я только что возродил крутость цифрового PR!

Сигналы скорости спама по ссылке

Существует целая серия метрик, посвящённых выявлению всплесков спамных анкорных текстов. Учитывая функцию phraseAnchorSpamDays, Google фактически имеет возможность измерять скорость распространения спама по ссылке.

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

Google использует только 20 последних изменений определенного URL во время анализа ссылки

Ранее я уже рассказывал о том, что файловая система Google способна сохранять прошлые версии страниц, подобно Wayback Machine. Насколько я понимаю, Google хранит проиндексированные страницы вечно. Это одна из причин, по которой вы не можете просто перенаправить страницу на нерелевантную цель и ожидать, что ссылочный капитал будет расти.

Документация только подтверждает эту идею, подразумевая, что хранятся все версии страницы.

Когда они получают данные для сравнения путём извлечения DocInfo (информации документа — п.п.), они учитывают только 20 последних версий страницы.

Это должно дать вам представление о том, сколько раз нужно менять и индексировать страницы, чтобы добиться «чистого листа» в Google.

PageRank (ранжирование — п.п.) главной страницы учитывается для всех страниц

У каждого документа есть свой PageRank для главной страницы (версия близжайшего начального значения). Он, вероятно, используется как прокси для новых страниц, пока они не получат свой собственный PageRank.

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

Доверие главной странице

Google решает, как оценивать важность ссылки, основываясь на доверии к главной странице.

Как и всегда, фокусироваться следует на качестве и релевантности ваших ссылок, а не на их количестве.

Размер шрифта имеет значение

Когда я только начинал заниматься SEO в 2006 году, мы выделяли текст жирным шрифтом, подчёркивали его или делали определенные фрагменты крупнее, чтобы они казались более важными. В последние 5 лет я наблюдаю, как люди говорят, что это всё ещё стоит делать. Я был настроен скептически, но теперь вижу, что Google действительно отслеживает средневзвешенный размер шрифта в документах.

Они также это делают и для анкорного текста ссылок.

«Пингвин» (алгоритм для борьбы со ссылочным спамом — п.п.) игнорирует внутренние ссылки

Во многих модулях, связанных с анкорами, понятие «локальный» означает тот же сайт. dropLocalAnchorCount (отбросить локальное число анкоров — п.п.) предполагает, что некоторые внутренние ссылки не учитываются.

Я не увидел ни одного упоминания отклонения ссылок

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

Я долгое время полагал, что функция disavow (отклонение ссылок — п.п.) — это краудсорсная попытка обучить классификаторы спама Google. То, что эти данные не расположены в «онлайне», говорит о том, что это может быть правдой.

Я мог бы продолжать рассказывать о ссылках и о таких функциях, как IndyRank, PageRankNS и т. д. Но достаточно сказать, что у Google очень хорошо отработан анализ ссылок, и многое из того, что они делают, даже приблизительно не похоже на наши индексы ссылок. Сейчас самое время пересмотреть свои программы по созданию ссылок, опираясь на всё, что вы только что прочитали.

Документы урезаются

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

Короткий контент оценивается на оригинальность

OriginalContentScore предполагает, что короткий контент оценивается на оригинальность. Возможно, именно поэтому «тонкость» контента не всегда зависит от его длины.

И наоборот, существует также показатель избытка ключевых слов

Названия страниц всё ещё играют роль в поисковом запросе
В документации указано, что существует показатель titlematchScore. Из описания следует, что соответствие заголовка страницы запросу — это всё ещё то, чему Google активно придает значение.

Размещать целевые ключевые слова на первом месте — это всё ещё верное решение.

Мер по подсчёту символов нет

Отдам Гэри Айлесу должное: он сказал, что SEO-специалисты сами придумали оптимальное количество символов для метаданных. В этом наборе данных нет метрики, которая подсчитывала бы длину заголовков страниц или сниппетов. Единственная мера подсчёта символов, которую я нашёл в документации, — это snippetPrefixCharCount, который, по-видимому, устанавливается для определения того, что может быть использовано в качестве части сниппета.

Это подтверждает то, что мы видели на практике множество раз: длинные заголовки страниц не оптимальны для увеличения количества кликов, но помогают улучшать место в ранжировании.

Даты очень важны

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

• bylineDate — это эксплицитно заданная дата на странице.

• sintacticDate — это дата, извлечённая из URL или заданная в заголовке.

• semanticDate — это дата, извлечённая из самого содержимого страницы.

Лучше всего указывать дату и быть последовательным в структурированных данных, заголовках страниц и XML картах сайта. Указание в URL даты, которая противоречит датам в других местах на странице, скорее всего, приведёт к понижению ранжирования.

Информация о регистрации домена хранится на страницах

Уже давно существует конспирологическая теория, согласно которой статус Google как регистратора влияет на алгоритм. Можем повысить её до конспирологического факта. Google хранит последнюю регистрационную информацию на уровне составных документов.

Как уже говорилось ранее, это, скорее всего, применяется для информирования о «песочнице» нового контента. Информация также может быть использована для помещения в «песочницу» ранее зарегистрированного домена, который сменил владельца. Подозреваю, что весомость этого вопроса повысили из-за введения политики борьбы со спамом на доменах с истёкшим сроком действия.

К сайтам с видео иной подход

Если больше 50% страниц сайты содержат видео, сайт считается сфокусированным на видео и к нему будет другой подход.

Страницы YMYL («ваши деньги или ваша жизнь», сайты, влияющие на финансовое благополучие, безопасности и здоровье людей — п.п.) оцениваются отдельно

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

Они также делают предсказания для «пограничных запросов» или запросов, которые не были замечены ранее, чтобы определить, считаются ли они YMYL или нет.

И наконец, YMYL базируется на уровне блоков, что говорит о том, что вся система основана на эмбеддингах.

Существует «золотой стандарт» документов

Там не указано, что это значит, но в описании упоминаются «документы, помеченные человеком», а не «автоматически помеченные аннотации». Не знаю, является ли это функцией рейтинга качества, но Google утверждает, что рейтинг качества не влияет на ранжирование. Так что, возможно, мы никогда не узнаем.🤔

Эмбеддинги сайтов используются для измерения соответствия тематике страницы

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

siteFocusScore отражает, насколько сайт придерживается одной темы. Радиус сайта (siteRadius) показывает, насколько далеко страница выходит за пределы основной темы, основываясь на сгенерированных для сайта векторах site2vec.

Возможно, Google специально понижает рейтинги маленьких сайтов

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

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

Мои открытые вопросы

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

Обновление «Полезного контента» — это «Малыш панды» (ещё один алгоритм Google — п.п.)?

В Сигналах сжатого качества есть два упоминания о чём-то под названием «малыш панды». Это твидлер, который корректируется после первоначального ранжирования.

Есть упоминание о том, что он работает поверх «Панды», но никакой другой информации в документации нет.

Думаю, мы в целом согласны с тем, что обновление «Полезный контент» во многом повторяет поведение «Панды». Если оно построено на основе системы, использующей ссылочные запросы, ссылки и клики, то это то, на чём стоит сосредоточиться после улучшения контента.

NSR — это нейросемантический поиск?

Существует множество ссылок на модули и атрибуты с NSR в названии. Многие из них связаны с фрагментами сайта и эмбеддингами. Ранее Google уже обсуждал «Нейронное соответствие» в качестве основного направления для улучшений. Моё предположение заключается в том, что NSR означает Neural Semantic Retrieval (нейросемантический поиск — п.п.) и все эти функции связаны с семантическим поиском. Однако в некоторых случаях они упоминаются рядом с «рейтингом сайта».

Я был бы рад, если бы какой-нибудь мятежный сотрудник Google использовал go/NSR и просто прислал мне «ты прав» с анонимного адреса электронной почты или что-то в этом роде.

Что можно сделать

Как я уже сказал, у меня нет для вас руководства к действию. Зато у меня есть несколько стратегических советов.

1. Отправьте Рэнду Фишкину свои извинения. С тех пор как я выступил на PubCon с докладом «Всё, о чём нам солгал Google», я веду кампанию по очистке имени Рэнда в связи с NavBoost. Рэнд в течение многих лет выполнял неблагодарную работу, пытаясь помочь нашей индустрии подняться. За это он получал много нареканий со стороны Google и со стороны SEO. Иногда у него получалось не всё, но его намерения всегда были благие, и он прилагал все усилия, чтобы сделать нашу работу более уважаемой и приятной. В частности, он не ошибался в выводах, сделанных в ходе экспериментов с кликами, неоднократно пытался доказать существование «песочницы» Google, исследовал примеры, показывающие, что Google по-разному ранжирует поддомены, и долгое время считал, что Google использует сигналы авторитетности на сайте. Его также стоит поблагодарить за этот анализ, поскольку именно он поделился со мной документацией. Сейчас для многих пришло самое время отправить ему приятных сообщений на Threads.

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

3. Верните корреляционные исследования. Теперь мы гораздо лучше понимаем многие характеристики, которые Google использует для ранжирования. Благодаря сочетанию данных о потоке кликов и извлечению характеристик мы можем воспроизвести больше элементов, чем раньше. Я считаю, что настало время вернуть исследования корреляции по вертикали.

4. Тестируйте и учитесь. Вы должны были увидеть уже достаточно графиков видимости и трафика с осями Y, чтобы понять, что нельзя доверять всему, что вы читаете или слышите в области SEO. Эта утечка — ещё один признак того, что необходимо продолжать собирать данные и экспериментировать с ними, чтобы понять, что будет работать для вашего сайта. Недостаточно ознакомиться с анекдотическими отзывами и предположить, что именно так работает Google. Если у вашей организации нет плана экспериментов в области SEO, сейчас самое время начать.

Мы знаем, что делаем

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

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

Всем, кто не уверен в том, что делает: продолжайте тестировать, учиться и развивать бизнес. Google не сможет делать свое дело без нас.

Мы только начинаем

Что мне всегда нравилось в SEO, так это то, что это постоянно развивающаяся головоломка. И хотя помогать брендам зарабатывать миллиарды долларов благодаря нашим усилиям очень увлекательно, есть что-то очень приятное в том, чтобы удовлетворять своё любопытство, разбираясь в том, как работает Google. Это огромное счастье — наконец-то заглянуть за кулисы.

Это всё, что у меня есть на данный момент, но дайте мне знать, что вы нашли! Все, кто хочет поделиться со мной чем-то, могут связаться со мной. Меня довольно легко найти!