
Автор: Mike King. Перевод: Александр И.
20 ценных фактов из утечки документов Google (Кратко)
Эта утечка содержит внутреннюю документацию Google Search API, раскрывающую подробности о хранении данных контента, ссылок и взаимодействий с пользователями.
Документы описывают 2 596 модулей с 14 014 атрибутами, многие из которых связаны с системами и функциями ранжирования.
- Авторитет домена. siteAuthority: Google имеет функцию, которая указывает на авторитетность домена, хранящуюся в сжатых сигналах качества.
- Песочница. HostAge: Этот атрибут используется для “песочницы” нового спама, что указывает на существование механизма песочницы.
- Авторство. Авторские данные: Google сохраняет авторов, связанных с документами, подчеркивая важность авторства.
- Понижения. Различные факторы, такие как несоответствие анкоров, неудовлетворенность SERP, плохая навигация, домены точного соответствия, отзывы о товарах, релевантность местоположения и порнографический контент, могут приводить к понижению позиций.
- Анализ ссылок. Метрики ссылок: Google отслеживает скорость распространения ссылочного спама и учитывает последние 20 изменений для данного URL при анализе ссылок.
- Контент и ключевые слова
- Подсчет токенов: Google оценивает количество лексем в документе и проверяет краткое содержание на оригинальность.
- TitleMatchScore: Заголовки страниц оцениваются по запросам.
- Даты и регистрация доменов
- Отслеживание дат: Различные типы дат, такие как bylineDate, syntacticDate, semanticDate, отслеживаются и используются.
- Регистрация доменов: Информация о регистрации хранится и может использоваться для “песочницы” нового контента.
- Сайты, ориентированные на видео. Видеоконтент: Сайты, где более 50% страниц содержат видео, обрабатываются по-особенному.
- Your Money Your Life (YMYL). Оценки YMYL: Google использует классификаторы для оценки YMYL (здоровье, новости и т.д.), чтобы определить, являются ли запросы YMYL.
- Эмбеддинги сайтов. SiteFocusScore: Google использует эмбеддинги сайтов для определения их тематической релевантности.
- Маленькие персональные сайты. Флаг малых сайтов: Малые персональные сайты могут быть повышены или понижены с помощью специального флага.
- NavBoost и данные о кликах
- NavBoost: Система, использующая данные о кликах для улучшения результатов поиска.
- Сигналы кликов: Различные типы кликов, такие как “goodClicks”, “badClicks”, “lastLongestClicks”, используются для ранжирования.
- Потоки кликов из Chrome браузера. Данные Chrome: Google использует данные о потоках кликов из браузеров Chrome для определения самых популярных URL-адресов на сайте.
- Вайтлисты для чувствительных тем. Путешествия, ковид и политика: Google использует вайтлисты для определенных доменов в чувствительных областях, чтобы обеспечить показ достоверной информации.
- Отзывы о качестве
- Платформа EWOK: Google использует платформу для оценки качества сайтов, где люди дают оценки, влияющие на ранжирование.
- Человеческие рейтинги: Оценки от специалистов по оценке качества используются как обучающие данные или прямые сигналы ранжирования.
- Качество ссылок и данные о кликах
- Уровни индекса ссылок: Google классифицирует ссылки на низкие, средние и высококачественные индексы.
- PageRank и анкоры: Хотя PageRank и ссылки с якорным текстом все еще используются, их значение снизилось.
- Важность бренда
- Узнаваемость бренда: Google отдает предпочтение известным брендам при ранжировании.
- E-E-A-T: Узнаваемость бренда и вовлеченность пользователей важнее, чем E-E-A-T (опыт, знания, авторитетность, надежность).
- Намерения пользователя и навигационные схемы
- Сигналы пользовательского намерения: Google использует шаблоны намерений пользователей для корректировки ранжирования.
- Мощность NavBoost: NavBoost – один из самых сильных сигналов ранжирования Google.
- SEO для малого и среднего бизнеса. Трудности для малого и среднего бизнеса: SEO все больше становится игрой для крупных брендов, что создает трудности для малого и среднего бизнеса.
- Техническая документация. API-документация: Утечка документов содержит информацию о данных, которые собирает Google и как они используются, без указания весов элементов в алгоритме ранжирования.
Утечка внутренней инженерной документации Google Search (Подробное исследование)
Узнайте то, что вы всегда хотели знать об алгоритмах Google. Google, если ты читаешь это, то уже слишком поздно 😉.
Хорошо. *Трещит костяшка*. Давайте перейдем прямо к делу. Произошла утечка внутренней документации по API хранилища контента Google Search. Внутренние микросервисы Google, похоже, зеркально отражают то, что предлагает Google Cloud Platform, и внутренняя версия документации по устаревшему хранилищу Document AI Warehouse была случайно опубликована в открытом доступе в репозитории кода для клиентской библиотеки. Документация по этому коду также была захвачена внешним автоматизированным сервисом документации.
Судя по истории изменений, ошибка с репозиторием кода была исправлена 7 мая, но автоматизированная документация все еще жива. В целях ограничения потенциальной ответственности я не буду приводить здесь ссылки на нее, но поскольку весь код в этом репозитории был опубликован под лицензией Apache 2.0, любой, кто с ним столкнулся, получил широкий набор прав, включая возможность использовать, изменять и распространять его в любом случае.

Я изучил справочные документы по API и сопоставил их с некоторыми другими предыдущими утечками Google и показаниями антимонопольного ведомства. Я объединил это с обширным исследованием патентов и документов, проведенным для моей предстоящей книги «Наука SEO». Хотя в просмотренной мною документации нет никаких подробностей о функциях Google по подсчету баллов, там есть множество информации о данных, хранящихся о контенте, ссылках и взаимодействии с пользователями. Есть также различные описания (от разочаровывающе скудных до удивительно откровенных) функций, которыми манипулируют и которые хранят.
Возникает соблазн назвать все это «факторами ранжирования», но это было бы неточно. Многие из них, даже большинство, являются факторами ранжирования, но многие – нет. Здесь я расскажу о некоторых наиболее интересных системах и функциях ранжирования (по крайней мере, о тех, которые мне удалось найти за первые несколько часов изучения этой масштабной утечки) на основе моих обширных исследований и того, о чем Google рассказывала/сообщала нам на протяжении многих лет.
«Соврал» – это жестко, но это единственное точное слово, которое можно здесь использовать. Хотя я не обвиняю публичных представителей Google в том, что они защищают свою конфиденциальную информацию, я не согласен с их усилиями по активной дискредитации людей из мира маркетинга, технологий и журналистики, которые представили воспроизводимые открытия. Мой совет будущим гуглерам, выступающим на подобные темы: Иногда лучше просто сказать: «Мы не можем об этом говорить». Ваш авторитет имеет значение, и когда появляются такие утечки, как эта, и такие показания, как в суде Минюста, становится невозможно доверять вашим будущим заявлениям.
Предостережения
Думаю, мы все знаем, что люди будут стараться дискредитировать мои выводы и анализ этой утечки. Некоторые будут задаваться вопросом, почему это имеет значение, и говорить: «Но мы и так это знали». Поэтому давайте разберемся с предостережениями, прежде чем перейдем к главному.
- Ограниченное время и контекст – из-за праздничных выходных я смог потратить на все это около 12 часов в глубокой концентрации. Я невероятно благодарен некоторым анонимным участникам, которые поделились со мной своими соображениями, чтобы помочь мне быстро войти в курс дела. Кроме того, как и в случае с утечкой из «Яндекса», о которой я рассказывал в прошлом году, у меня нет полной картины. Если в случае с «Яндексом» у нас был исходный код для разбора и ни одной мысли, стоящей за ним, то в этом случае у нас есть некоторые мысли, стоящие за тысячами функций и модулей, но нет исходного кода. Вы должны простить меня за то, что я рассказываю об этом менее структурированно, чем через несколько недель, когда я посижу с материалом подольше.
- Отсутствие функций оценки – мы не знаем, как взвешиваются характеристики в различных функциях оценки. Мы не знаем, используются ли все доступные функции. Мы знаем, что некоторые функции устарели. Если нет явных указаний, мы не знаем, как используются те или иные функции. Мы не знаем, где все происходит в конвейере. У нас есть ряд названных систем ранжирования, которые слабо согласуются с тем, как Google объясняет их, как SEO-специалисты наблюдают за ранжированием в естественных условиях, как объясняют патентные заявки и литературу IR. В конечном счете, благодаря этой утечке мы теперь имеем более четкое представление о том, что рассматривается, что может послужить основой для определения того, на что мы будем обращать внимание, а что игнорировать в SEO в дальнейшем.
- Скорее всего, это первый из нескольких постов – этот пост будет моей первой попыткой рассказать о том, что я изучил. Я могу опубликовать последующие посты по мере того, как буду продолжать копаться в деталях. Я подозреваю, что эта статья приведет к тому, что SEO-сообщество начнет наперегонки разбирать эти документы, и мы будем коллективно открывать и переосмысливать их в течение нескольких месяцев.
- Это, по-видимому, актуальная информация – насколько я могу судить, эта утечка представляет собой текущую, действующую архитектуру хранилища поискового контента Google по состоянию на март 2024 года. (Реплика пиарщика Google о том, что я ошибаюсь. На самом деле давайте просто пропустим эту песню и танец). Судя по истории коммитов, соответствующий код был размещен 27 марта 2024 года и удален только 7 мая 2024 года.

- Корреляция не является причинно-следственной связью – Ок, это не совсем применимо здесь, но я просто хотел убедиться, что охватил все основы.
14 тысяч функций ранжирования и многое другое в документации
в документации api представлено 2 596 модулей с 14 014 атрибутами (функциями), которые выглядят следующим образом:

Модули связаны с компонентами youtube, assistant, книгами, видеопоиском, ссылками, веб-документами, инфраструктурой ползания, внутренней системой календаря и апи people. как и yandex, системы google работают на основе монолитного репозитория (или «монорепо»), а машины – в общей среде. это означает, что весь код хранится в одном месте и любая машина в сети может быть частью любой из систем google.

Утечка документации описывает каждый модуль API и разбивает их на сводки, типы, функции и атрибуты. В основном мы видим определения свойств различных протокольных буферов (или протобуферов), к которым обращаются системы ранжирования для создания SERP (Search Engine Result Pages – то, что Google показывает поисковикам после выполнения ими запроса).

К сожалению, многие резюме ссылаются на ссылки Go, которые представляют собой URL-адреса в корпоративной интрасети Google, предлагающие дополнительные сведения о различных аспектах системы. Не имея нужных учетных данных Google для входа и просмотра этих страниц (для этого почти наверняка нужно быть действующим гуглером в команде Search), мы предоставлены сами себе для интерпретации.
Документация по API раскрывает некоторые заметные факты лжи Google
Представители Google из кожи вон лезут, чтобы ввести нас в заблуждение по целому ряду аспектов работы своих систем, пытаясь контролировать наше поведение как SEO-специалистов. Я не стану называть это «социальной инженерией», поскольку этот термин имеет богатую историю. Давайте вместо этого выберем… «газовое освещение». Публичные заявления Google, вероятно, не являются намеренной попыткой солгать, а скорее обмануть потенциальных спамеров (а также многих законных SEO-специалистов), чтобы сбить нас с толку, как повлиять на результаты поиска.
Ниже я привожу утверждения сотрудников Google наряду с фактами из документации с ограниченными комментариями, чтобы вы могли судить сами.
«У НАС НЕТ НИЧЕГО ПОХОЖЕГО НА АВТОРИТЕТ ДОМЕНА»
Представители Google много раз говорили, что не используют «авторитет домена». Я всегда считал, что это ложь путем умолчания и запутывания.
Говоря, что они не используют авторитет домена, они могли сказать, что не используют метрику Moz под названием «Авторитет домена» (очевидно 🙄). Они также могут говорить, что не измеряют авторитетность или важность конкретной темы (или домена) применительно к веб-сайту. Эта путаница в семантике позволяет им никогда напрямую не отвечать на вопрос, рассчитывают ли они или используют метрики авторитетности всего сайта.
Гэри Айлес (Gary Ilyes), аналитик из команды Google Search Team, который занимается публикацией информации в помощь создателям сайтов, неоднократно повторял это утверждение.

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

Мы не знаем, как именно вычисляется этот показатель и как он используется в последующих функциях оценки, но теперь мы точно знаем, что он существует и используется в системе ранжирования Q*. Оказывается, у Google действительно есть общий авторитет домена. А теперь гуглеры заявляют, что «он у нас есть, но мы его не используем», или «вы не понимаете, что это значит», или… подождите, я же сказал «ограниченный комментарий», разве нет? Идем дальше.
«МЫ НЕ ИСПОЛЬЗУЕМ КЛИКИ ДЛЯ РАНЖИРОВАНИЯ»
Давайте покончим с этим вопросом навсегда.
Показания Панду Наяка в антимонопольном процессе Минюста США недавно раскрыли существование систем ранжирования Glue и NavBoost. NavBoost – это система, использующая меры, основанные на кликах, для повышения, понижения или иного усиления рейтинга в веб-поиске. Наяк отметил, что NavBoost существует примерно с 2005 года и исторически использует данные о кликах за 18 месяцев. Недавно система была обновлена и теперь использует данные за 13 месяцев и ориентирована на результаты веб-поиска, в то время как система под названием Glue связана с другими результатами универсального поиска. Но и до этого у нас было несколько патентов (включая патент 2007 года на ранжирование по времени), которые конкретно указывают на то, как журналы кликов могут быть использованы для изменения результатов.
Мы также знаем, что клики как мера успеха – это лучшая практика в области поиска информации. Мы знаем, что Google перешел на алгоритмы, основанные на машинном обучении, а ML требует переменных откликов для улучшения своей работы. Несмотря на эти ошеломляющие доказательства, в SEO-сообществе до сих пор царит путаница, вызванная неправильным поведением представителей Google и постыдной публикацией статей в мире поискового маркетинга, которые некритично повторяют публичные заявления Google.
Гэри Иллис неоднократно обращался к этой проблеме измерения кликов. В одном случае он подтвердил слова инженера Google Search Пола Хаара (Paul Haahr), сказанные в его выступлении на SMX West в 2016 году о живых экспериментах, заявив, что «использование кликов непосредственно в ранжировании было бы ошибкой».

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

На самом деле в Navboost есть специальный модуль, полностью посвященный сигналам кликов.
В аннотации к этому модулю он определяется как «сигналы кликов и впечатлений для Craps, одной из систем ранжирования». Как мы видим ниже, плохие клики, хорошие клики, последние самые длинные клики, несквозные клики и несквозные последние самые длинные клики – все они рассматриваются как метрики. Согласно патенту Google «Scoring local search results based on location prominence», «Squashing is a function that prevents one large signal from dominate the others.» Другими словами, системы нормализуют данные о кликах, чтобы исключить возможность манипуляций на основе сигнала клика. Гуглеры утверждают, что системы, описанные в патентах и технических описаниях, не обязательно используются в производстве, но NavBoost было бы нелепо создавать и включать в систему, если бы она не была важной частью информационно-поисковых систем Google.

Многие из этих же измерений, основанных на кликах, можно найти и в другом модуле, связанном с сигналами индексирования. Одним из показателей является дата «последнего удачного клика» на данный документ. Это позволяет предположить, что упадок контента (или потеря трафика с течением времени) также является функцией того, что ранжируемая страница не набирает ожидаемого количества кликов для своей позиции в SERP.
Кроме того, в документации пользователи представлены как избиратели, а их клики хранятся как их голоса. Система подсчитывает количество неудачных кликов и сегментирует данные по странам и устройствам.
Также хранится информация о том, какой результат был самым длинным за время сессии. Таким образом, недостаточно просто выполнить поиск и кликнуть на результат, пользователи должны провести на странице значительное количество времени. Длинные клики являются показателем успешности поисковой сессии, как и время пребывания, но в этой документации нет конкретной функции под названием «время пребывания». Тем не менее, длительные клики – это фактически один и тот же показатель, что противоречит заявлениям Google по этому поводу.
Различные источники утверждают, что NavBoost «уже является одним из самых сильных сигналов ранжирования Google». В просочившейся документации «Navboost» упоминается 84 раза, а пять модулей содержат Navboost в названии. Есть также свидетельства того, что они рассматривают его оценку на уровне поддомена, корневого домена и URL, что явно указывает на то, что они по-разному относятся к разным уровням сайта. Я не буду углубляться в спор между поддоменом и корневым доменом, но позже мы обсудим, как данные из этой системы повлияли на алгоритм Panda.
Итак, да, Google не упоминает «CTR» или «время пребывания» именно этими словами в данной документации, но дух того, что доказал Рэнд: клики по результатам поиска и показатели успешной поисковой сессии, включены. Доказательства достаточно убедительны, и можно не сомневаться, что Google использует клики и поведение после клика в своих алгоритмах ранжирования.
«ПЕСОЧНИЦЫ НЕ СУЩЕСТВУЕТ»
Представители Google не раз заявляли, что не существует «песочницы», в которую попадают сайты по возрасту или отсутствию признаков доверия. В удаленном твите Джон Мюллер ответил на вопрос о том, сколько времени требуется для получения права на ранжирование, сказав: «Песочницы не существует».

В модуле PerDocData в документации указан атрибут hostAge, который используется специально «для „песочницы“ свежего спама при подаче».
Оказывается, песочница все-таки существует. Кто знал? О да, Рэнд знал.
«МЫ НЕ ИСПОЛЬЗУЕМ НИЧЕГО ИЗ ХРОМА ДЛЯ РАНЖИРОВАНИЯ».
Мэтт Каттс ранее заявлял, что Google не использует данные Chrome в органическом поиске. Совсем недавно Джон Мюллер подтвердил эту мысль.

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

Утечка внутренней презентации системы RealTime Boost от мая 2016 года также указывает на то, что данные Chrome придут в поиск. В общем, вы поняли, о чем идет речь.
ПРЕДСТАВИТЕЛИ GOOGLE – ЛЮДИ БЛАГОНАМЕРЕННЫЕ, НО МОЖНО ЛИ ИМ ДОВЕРЯТЬ?
Быстрый ответ – нет, если вы слишком близко подобрались к секретному соусу.
Я не держу зла на тех, кого я здесь цитировал. Я уверен, что все они делают все возможное, чтобы обеспечить поддержку и ценность для сообщества в рамках дозволенного. Однако эти документы ясно дают понять, что мы должны продолжать воспринимать их слова как единое мнение, а наше сообщество должно продолжать экспериментировать, чтобы увидеть, что работает.
Выполните описанные выше действия, чтобы добавить функцию косинусного сходства в свой проект.
Архитектура систем ранжирования Google
Концептуально вы можете думать об «алгоритме Google» как о чем-то одном, гигантском уравнении с рядом взвешенных факторов ранжирования. На самом деле это серия микросервисов, в которых множество функций предварительно обрабатываются и становятся доступными во время выполнения для составления SERP. Судя по различным системам, упоминаемым в документации, их может быть более сотни. Если предположить, что это не все системы, то, возможно, каждая из них представляет собой «сигнал ранжирования», и, возможно, именно таким образом Google достигает 200 сигналов ранжирования, о которых они часто говорят.
В докладе Джеффа Дина «Создание программных систем в Google и извлеченные уроки» он упомянул, что ранние итерации Google отправляли каждый запрос на 1000 машин, которые обрабатывали его и отвечали за время менее 250 миллисекунд. Он также изобразил диаграмму ранней версии абстракции архитектуры системы. На этой диаграмме показано, что Super Root – это мозг Google Search, который отправляет запросы и сшивает все вместе в конце.

Заслуженный инженер-исследователь Марк Найорк в своей недавней презентации Generative Information Retrieval продемонстрировал абстрактную модель поиска Google с его системой RAG (она же Search Generative Experience/AI Overviews). Эта диаграмма иллюстрирует ряд различных хранилищ данных и серверов, которые обрабатывают различные слои результатов.

Разоблачитель Google Зак Ворхис (Zach Vorhies) опубликовал этот слайд, на котором показаны взаимосвязи различных систем в Google по их внутренним названиям. Некоторые из них упоминаются в документации.

Используя эти три высокоуровневые модели, мы можем начать думать о том, как некоторые из этих компонентов работают вместе. Из документации я понял, что этот API работает на базе Spanner от Google. Spanner – это архитектура, которая позволяет бесконечно масштабировать хранение контента и вычисления, рассматривая ряд компьютеров, объединенных в глобальную сеть, как единое целое.
Конечно, на основе одной лишь документации сложно выстроить взаимосвязь между всеми компонентами, но резюме Пола Хаара дает ценное представление о том, что делают некоторые из названных систем ранжирования. Я выделю те, которые мне известны по именам, и распределю их по функциям.
Crawling (Сканирование)
- Trawler – система веб-ползания. Она имеет очередь поползновений, поддерживает скорость поползновений и понимает, как часто меняются страницы.
Индексирование
- Alexandria – основная система индексирования.
- SegIndexer – Система, которая размещает документы по ярусам в индексе.
- TeraGoogle – система вторичного индексирования для документов, которые долго хранятся на диске.
Рендеринг
- HtmlrenderWebkitHeadless – Система рендеринга для страниц JavaScript. Странно, что она названа в честь Webkit, а не Chromium. В документации есть упоминание о Chromium, так что, скорее всего, Google изначально использовала WebKit и переключилась на него после появления Headless Chrome.
Обработка
- LinkExtractor – Извлекает ссылки из страниц.
- WebMirror – Система управления канонизацией и дублированием.
Рейтинг
- Mustang – Основная система оценки, ранжирования и обслуживания.
- Ascorer – Основной алгоритм ранжирования, который ранжирует страницы до внесения изменений в ранжирование.
- NavBoost – Система повторного ранжирования, основанная на журналах кликов и поведения пользователей.
- FreshnessTwiddler – система ранжирования документов на основе их свежести.
- WebChooserScorer – Определяет названия функций, используемых при подсчете сниппетов.
Обслуживание
- Google Web Server – GWS – это сервер, с которым взаимодействует фронтенд Google. Он получает полезную нагрузку в виде данных для отображения пользователю.
- SuperRoot – «мозг» Google Search, который отправляет сообщения на серверы Google и управляет системой постобработки для повторного ранжирования и представления результатов.
- SnippetBrain – система, генерирующая сниппеты для результатов.
- Glue – Система для объединения универсальных результатов с учетом поведения пользователей.
- Cookbook – система для генерации сигналов. Есть признаки того, что значения создаются во время выполнения.
Как я уже сказал, в этих документах описано еще много систем, но не совсем понятно, что они делают. Например, SAFT и Drishti из приведенной выше диаграммы также представлены в этих документах, но их функции неясны.
Что такое твиддлеры?
В сети мало информации о твиддлерах в целом, поэтому я думаю, что стоит объяснить их здесь, чтобы мы могли лучше понять контекст различных систем Boost, которые мы встречаем в документах.
Твиддлеры – это функции повторного ранжирования, которые работают после основного алгоритма поиска Ascorer. Они работают аналогично фильтрам и действиям в WordPress, где то, что отображается, корректируется непосредственно перед тем, как быть представленным пользователю. Твиддлеры могут корректировать оценку информационного поиска документа или изменять его рейтинг. Многие живые эксперименты и именованные системы, о которых мы знаем, реализованы именно таким образом. Как показывает этот Xoogler, они очень важны для различных систем Google:

Twiddlers может предлагать ограничения по категориям, то есть разнообразие можно поощрять, специально ограничивая тип результатов. Например, автор может решить, что в данном SERP будет только 3 записи из блога. Это может прояснить ситуацию, когда ранжирование является проигрышным вариантом, основанным на формате вашей страницы.
Когда Google говорит, что что-то вроде Panda не было частью основного алгоритма, это, скорее всего, означает, что оно было запущено как твидлер для повышения или понижения ранжирования, а затем перешло в основную функцию подсчета. Думайте об этом так же, как о разнице между рендерингом на стороне сервера и на стороне клиента.
Предположительно, любая из функций с суффиксом Boost работает с использованием фреймворка Twiddler. Вот некоторые из Boost’ов, описанных в документации:
- NavBoost
- QualityBoost
- RealTimeBoost
- WebImageBoost.
Судя по названиям, все они не требуют пояснений.
Существует также внутренний документ о Twiddlers, который я изучил, и в котором об этом говорится более подробно, но в этом посте, похоже, автор видел тот же документ, что и я.
Ключевые откровения, которые могут повлиять на то, как вы занимаетесь SEO
Давайте перейдем к тому, ради чего вы, собственно, и пришли. Что Google делает такого, чего мы не знали или в чем не были уверены, и как это может повлиять на мои SEO-усилия?
Небольшое замечание, прежде чем мы продолжим. Моя цель – познакомить SEO-индустрию с новыми концепциями. Я не ставлю перед собой задачу дать вам рецепт, как использовать их в вашем конкретном случае. Если вы хотите именно этого, вам стоит нанять iPullRank для вашего SEO. В противном случае, у вас всегда будет более чем достаточно возможностей для экстраполяции и разработки собственных сценариев использования.
Как работает Panda
Когда появилась Panda, было много путаницы. Является ли она машинным обучением? Использует ли она сигналы пользователей? Почему нам нужно обновление или обновление для восстановления? Является ли она общесайтовой? Почему я потерял трафик для определенного подкаталога?
Panda была выпущена под руководством Амита Сингхала. Сингхал был категорически против машинного обучения из-за его ограниченной наблюдаемости. На самом деле существует ряд патентов, посвященных качеству сайта для Panda, но я хочу остановиться на одном из них – «Ранжирование результатов поиска». Патент поясняет, что Panda гораздо проще, чем мы думали. Речь идет в основном о создании модификатора оценки на основе распределенных сигналов, связанных с поведением пользователей и внешними ссылками. Этот модификатор может применяться на уровне домена, субдомена или подкаталога.
«Система генерирует коэффициент модификации для группы ресурсов на основе подсчета независимых ссылок и подсчета ссылочных запросов (шаг 306). Например, коэффициент модификации может представлять собой отношение количества независимых ссылок для группы к количеству ссылочных запросов для группы. То есть коэффициент модификации (M) может быть выражен как:
M=IL/RQ,
где IL – количество независимых ссылок, учитываемых для группы ресурсов, а RQ – количество ссылочных запросов, учитываемых для группы ресурсов».
Независимые ссылки – это, по сути, то, что мы считаем ссылками на корневые домены, а вот ссылочные запросы – это нечто более сложное. Вот как они определяются в патенте:
«Ссылочный запрос для определенной группы ресурсов может быть ранее отправленным поисковым запросом, который был классифицирован как ссылающийся на ресурс в определенной группе ресурсов. Категоризация конкретного ранее представленного поискового запроса как относящегося к ресурсу в конкретной группе ресурсов может включать: определение того, что конкретный ранее представленный поисковый запрос включает один или более терминов, которые были определены как относящиеся к ресурсу в конкретной группе ресурсов.»
Теперь, когда у нас есть доступ к этой документации, становится ясно, что ссылочные запросы – это запросы от NavBoost.

Это позволяет предположить, что обновления Panda были просто обновлениями скользящего окна запросов, подобно тому, как работают расчеты Core Web Vitals. Это также может означать, что обновления графа ссылок не обрабатывались в режиме реального времени для Panda.
Не будем бить мертвую лошадь, но в другом патенте Panda, Site quality score, также рассматривается оценка, которая представляет собой соотношение между ссылочными запросами и пользовательскими выборами или кликами.
Суть в том, что вам нужно делать больше успешных кликов, используя более широкий набор запросов, и зарабатывать больше разнообразия ссылок, если вы хотите продолжать ранжироваться. Концептуально это имеет смысл, потому что очень сильный контент будет делать это. Фокусировка на привлечении более квалифицированного трафика и улучшении пользовательского опыта даст Google сигнал о том, что ваша страница заслуживает ранжирования. Вам следует сосредоточиться на этом же, чтобы восстановиться после обновления «Полезный контент».
Авторы – явная особенность
Многое было написано о E-E-A-T. Многие SEO-специалисты не верят в эту идею, потому что определение экспертности и авторитетности – дело туманное. Ранее я также рассказывал о том, как мало авторской разметки в Интернете. До того как я узнал о векторных вкраплениях, я не верил, что авторство является достаточно жизнеспособным сигналом в масштабах сети.

Тем не менее, Google явно сохраняет авторов, связанных с документом, в виде текста:

Они также смотрят, является ли сущность на странице автором этой страницы.

В сочетании с подробным отображением сущностей и вкраплений, показанных в этих документах, становится ясно, что существует некая комплексная оценка авторов.
Понижения
В документации обсуждается ряд алгоритмических понижений. Их описание ограничено, но они заслуживают упоминания. Мы уже обсуждали Panda, но остальные понижения, с которыми я столкнулся, таковы:
- Несоответствие анкоров – когда ссылка не соответствует целевому сайту, на который она ссылается, ссылка понижается в расчетах. Как я уже говорил, Google ищет релевантность с обеих сторон ссылки.
- SERP Demotion – сигнал, указывающий на понижение, основанный на факторах, наблюдаемых в SERP, что указывает на потенциальную неудовлетворенность пользователей страницей, которая, вероятно, измеряется кликами.
- Nav Demotion – предположительно, это понижение, применяемое к страницам, демонстрирующим плохую навигацию или проблемы с пользовательским опытом.
- Понижение доменов точного соответствия – в конце 2012 года Мэтт Каттс объявил, что домены точного соответствия не будут иметь такого значения, как это было раньше. Существует специальная функция для их понижения.
- Понижение отзывов о товарах – конкретной информации по этому вопросу нет, но он указан как понижение и, вероятно, связан с недавним обновлением отзывов о товарах 2023.
- Понижение местоположения – есть указание на то, что «глобальные» и «суперглобальные» страницы могут быть понижены в выдаче. Это говорит о том, что Google пытается ассоциировать страницы с местоположением и ранжировать их соответствующим образом.
- Понижение в выдаче за порнографию – Это довольно очевидно.
- Понижение позиций по другим ссылкам – об этом мы поговорим в следующем разделе.
Все эти потенциальные понижения могут лечь в основу стратегии, но если быть честным, то все сводится к созданию звездного контента с сильным пользовательским опытом и построению бренда.
Ссылки все еще кажутся очень важными
Я не видел никаких доказательств, опровергающих недавние заявления о том, что ссылки стали менее важными. Опять же, скорее всего, это связано с функциями оценки, а не с тем, как хранится информация. Тем не менее, было уделено большое внимание извлечению и разработке функций для глубокого понимания графа ссылок.
Уровень индексирования влияет на ценность ссылок
Метрика под названием sourceType показывает нечеткую взаимосвязь между тем, где индексируется страница, и тем, насколько она ценна. Для справки: индекс Google разделен на уровни, где наиболее важный, регулярно обновляемый и доступный контент хранится во флэш-памяти. Менее важный контент хранится на твердотельных накопителях, а нерегулярно обновляемый – на обычных жестких дисках.

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

Это может быть легко использовано для определения того, когда на сайте происходит спам, и свести на нет негативную SEO-атаку. Для тех, кто скептически относится к последнему, Google может использовать эти данные для сравнения базового уровня обнаружения ссылок с текущей тенденцией и просто не учитывать эти ссылки в любом направлении.
При анализе ссылок Google использует только 20 последних изменений для данного URL-адреса
Ранее я уже рассказывал о том, что файловая система Google способна сохранять версии страниц с течением времени, подобно Wayback Machine. Насколько я понимаю, Google хранит проиндексированные страницы вечно. Это одна из причин, по которой вы не можете просто перенаправить страницу на нерелевантную цель и ожидать, что ссылочное равенство будет расти.

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

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

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

Вероятно, this и siteAuthority используются в качестве прокси для новых страниц, пока они не рассчитают свой собственный PageRank.
Доверие к домашней странице
Google решает, как оценивать ссылку, основываясь на том, насколько он доверяет главной странице.

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

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

Penguin уничтожает внутренние ссылки
Во многих модулях, связанных с анкорами, идея «локального» означает тот же сайт. Это dropLocalAnchorCount предполагает, что некоторые внутренние ссылки не учитываются.
Я не увидел ни одного упоминания о дезавуировании
Хотя данные о дезавуировании могут храниться в другом месте, в этом API их нет. Я считаю, что это связано с тем, что данные о райтерах качества доступны непосредственно здесь. Это говорит о том, что данные о дезавуировании отделены от основных систем ранжирования.

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

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

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

Помещение целевых ключевых слов на первое место по-прежнему актуально.
Меры по подсчету символов отсутствуют
К своей чести, Гэри Иллис заявил, что SEO-специалисты сами придумали оптимальное количество символов для метаданных. В этом наборе данных нет ни одной метрики, которая бы подсчитывала длину заголовков страниц или сниппетов. Единственная мера подсчета символов, которую я нашел в документации, – это snippetPrefixCharCount, который, похоже, устанавливается для определения того, что может быть использовано в качестве части сниппета.

Это подтверждает то, что мы уже неоднократно проверяли: длинные заголовки страниц неоптимальны для привлечения кликов, но прекрасно подходят для ранжирования.
Даты очень важны
Google уделяет большое внимание свежим результатам, и документы иллюстрируют его многочисленные попытки связать даты со страницами.
- bylineDate – это явно установленная дата на странице.

- syntacticDate – Это извлеченная дата из URL или заголовка.

- semanticDate – дата, полученная из содержимого страницы.

Лучше всего указывать дату и быть последовательным в структурированных данных, заголовках страниц, XML sitemaps. Если вы указываете в URL дату, которая противоречит датам в других местах на странице, это, скорее всего, приведет к снижению эффективности контента.
Информация о регистрации домена хранится на страницах
Уже давно существует теория заговора, что статус Google как регистратора влияет на алгоритм. Мы можем перейти к конспирологическому факту. Они хранят последнюю регистрационную информацию на уровне составных документов.

Как уже говорилось ранее, это, вероятно, используется для определения песочницы нового контента. Она также может использоваться для «песочницы» ранее зарегистрированного домена, который сменил владельца. Подозреваю, что весомость этого вопроса была повышена в связи с введением спам-политики злоупотребления доменами с истекшим сроком действия.
К сайтам, ориентированным на видео, относятся по-другому
Если более 50 % страниц сайта содержат видео, сайт считается видео-ориентированным и будет рассматриваться по-другому.

Ваши деньги – ваша жизнь оцениваются особым образом
В документации указано, что у Google есть классификаторы, которые генерируют оценки для YMYL Health и YMYL News.

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

И, наконец, YMYL вычисляется на уровне чанков, что говорит о том, что вся система основана на вкраплениях.

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

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

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

Учитывая обратную реакцию и малый бизнес, который пострадал от обновления полезного контента, удивительно, что они используют эту функцию, чтобы что-то сделать с этим.
Мои открытые вопросы
Я мог бы продолжить, и я продолжу, но пришло время для перерыва. Тем временем, я подозреваю, что другие люди неизбежно будут делать свои собственные выводы из этой утечки. На данный момент у меня есть несколько открытых вопросов, которые я бы хотел, чтобы мы все рассмотрели.
Известно ли обновление «Полезный контент» как «Малыш Панда»?
В «Сигналах сжатого качества» есть два упоминания о чем-то, называемом «Baby Panda». Baby Panda – это твидлер, который является корректировкой после первоначального ранжирования.

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

Думаю, мы в целом согласны с тем, что обновление «Полезный контент» имеет многие из тех же характеристик, что и «Панда». Если оно построено на основе системы, использующей ссылочные запросы, ссылки и клики, то это те вещи, на которых вам нужно сосредоточиться после улучшения контента.
Означает ли NSR нейросемантический поиск?
Существует множество ссылок на модули и атрибуты с NSR в качестве части именования. Многие из них связаны с фрагментами сайта и вкраплениями. Ранее Google уже обсуждал «нейронное соответствие» в качестве основного направления для улучшений. Мое предположение заключается в том, что NSR означает Neural Semantic Retrieval, и все эти функции связаны с семантическим поиском. Однако в некоторых случаях они упоминаются рядом с «рангом сайта».
Я был бы рад, если бы какой-нибудь мятежный гуглер зашел в go/NSR и просто отправил мне «вы правы» с анонимного адреса электронной почты или что-то в этом роде.
Советы
Как я уже сказал, у меня нет для вас никаких рецептов. Однако у меня есть несколько стратегических советов.
- Пошлите Рэнду Фишкину извинения – с тех пор как я выступил на PubCon с докладом «Все, о чем Google нам солгала», я начал кампанию по очистке имени Рэнда в связи с NavBoost. Рэнд выполнял неблагодарную работу, пытаясь помочь нашей индустрии подняться в течение многих лет. За это он получил много нареканий со стороны Google и SEO-специалистов. Иногда у него не все получалось, но его сердце всегда было на правильном месте, и он прилагал все усилия, чтобы сделать то, что мы делаем, уважаемым и просто лучшим. В частности, он не ошибался в выводах, сделанных в ходе экспериментов с кликами, неоднократно пытался доказать существование «песочницы» Google, исследовал примеры, показывающие, что Google по-разному ранжирует поддомены, и долго отстаивал свое мнение о том, что Google использует сигналы авторитетности на весь сайт. Вы также должны поблагодарить его за этот анализ, поскольку именно он поделился со мной документацией. Сейчас для многих из вас самое время выразить ему признательность на Threads.
- Создавайте отличный контент и хорошо его продвигайте – я шучу, но я и серьезен. Google продолжает давать этот совет, а мы отмахиваемся от него, считая его недейственным. Для некоторых SEO-специалистов это просто не в их власти.После анализа этих характеристик, дающих Google преимущества, становится совершенно очевидно, что создание лучшего контента и его продвижение среди аудитории, с которой он резонирует, даст наилучший эффект по этим показателям. Показатели ссылочной массы и контента, конечно, помогут вам далеко продвинуться, но если вы действительно хотите выиграть в Google в долгосрочной перспективе, вам придется делать то, что заслуживает ранжирования.
- Верните исследования корреляции – Теперь мы гораздо лучше понимаем многие характеристики, которые Google использует для ранжирования. Благодаря сочетанию данных о потоке кликов и извлечению характеристик мы можем повторить больше, чем раньше. Думаю, пришло время вернуть исследования корреляции по вертикали.
Тестируйте и учитесь – вы должны были видеть достаточно графиков видимости и трафика с осями Y, чтобы понять, что нельзя доверять всему, что вы читаете или слышите в SEO. Эта утечка – еще один признак того, что вы должны принимать данные и экспериментировать с ними, чтобы понять, что будет работать для вашего сайта. Недостаточно ознакомиться с анекдотическими отзывами и предположить, что Google работает именно так. Если у вашей организации нет плана экспериментов в области SEO, сейчас самое время его разработать.
Мы знаем, что делаем
Важная вещь, которую мы все можем вынести из этого: SEO-специалисты знают, что делают. После многих лет, когда нам говорили, что мы не правы, приятно заглянуть за занавес и обнаружить, что все это время мы были правы. И хотя в этих документах есть интересные нюансы работы Google, в них нет ничего, что заставило бы меня кардинально изменить стратегию SEO.
Для тех, кто вникнет в суть, эти документы в первую очередь подтвердят то, за что давно выступают опытные SEO-специалисты. Поймите свою аудиторию, определите, чего она хочет, сделайте лучшее из возможного, что соответствует этому, сделайте его технически доступным и продвигайте его до тех пор, пока он не займет свое место.
Всем, кто не уверен в том, что делает, продолжайте тестировать, учиться и развивать бизнес. Google не сможет делать то, что делает, без нас.
Скачать функции ранжирования
Кто-то должен загрузить и упорядочить все функции в электронную таблицу для вас. Возможно, это буду я. У нас остался всего месяц до конца квартала, а я все равно хочу поднять MQL. 😆
Возьмите свою копию списка функций рейтинга.
Мы только начинаем
Что мне всегда нравилось в SEO, так это то, что это постоянно развивающаяся головоломка. И хотя помогать брендам зарабатывать миллиарды долларов на наших усилиях очень весело, есть что-то очень приятное в том, чтобы удовлетворять свое любопытство, разбираясь в том, как работает Google. Это огромное счастье – наконец-то заглянуть за занавес.
Это все, что у меня есть на данный момент, но дайте мне знать, что вы нашли! Все, кто хочет поделиться со мной чем-то, могут связаться со мной. Меня довольно легко найти!
Автор: Mike King. Перевод: Александр И.
Источник: https://ipullrank.com/google-algo-leak, https://hexdocs.pm/google_api_content_warehouse/api-reference.html








