Секреты алгоритма: в сеть попала внутренняя инженерная документация Google Search

Перевод https://ipullrank.com/google-algo-leak

Автор: Майк Кинг

Узнайте то, что вы всегда хотели знать об алгоритмах Google.

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

Хорошо. Хруст костяшками пальцев. Давайте приступим к делу. Утечка внутренней документации API Content Warehouse API Google Search. Внутренние микросервисы Google, похоже, отражают то, что предлагает Google Cloud Platform, а внутренняя версия документации для устаревшего документа AI Warehouse была случайно опубликована публично в репозитории кода клиентской библиотеки. Документация для этого кода также была собрана внешней автоматизированной службой документации.

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

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

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

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

ПРЕДОСТЕРЕЖЕНИЯ

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

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

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

В ДОКУМЕНТАХ ЕСТЬ 14 ТЫС. ФУНКЦИЙ РЕЙТИНГА И БОЛЬШЕ

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

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

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

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

ДОКУМЕНТЫ API РАССКАЗЫВАЮТ НЕКОТОРУЮ ПРИМЕЧАТЕЛЬНУЮ ЛОЖЬ GOOGLE

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

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

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

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

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

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

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

Мы не знаем конкретно, как эта мера рассчитывается или используется в последующих функциях оценки, но теперь мы точно знаем, что она существует и используется в системе ранжирования Q*. Оказывается, у Google действительно есть общий авторитет домена. Подайте сигнал сотрудникам Google, утверждающим: «Оно у нас есть, но мы его не используем», или «Вы не понимаете, что это значит», или… подождите, я сказал «ограниченные комментарии», не так ли? Двигаемся дальше.

Давай уложим это в голове раз и навсегда.

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

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

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

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

На самом деле в Navboost есть специальный модуль, полностью ориентированный на сигналы кликов.

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

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

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

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

Различные источники указывают, что NavBoost «уже является одним из самых сильных сигналов ранжирования Google». В просочившейся документации имя «Navboost» упоминается 84 раза, а в названии пяти модулей упоминается Navboost. Есть также свидетельства того, что они рассматривают возможность оценки на уровне поддомена, корневого домена и URL-адреса, что по своей сути указывает на то, что они по-разному относятся к различным уровням сайта. Я не буду вдаваться в спор о поддоменах и sudirectory, но позже мы обсудим, как данные из системы также используются в алгоритме Panda.

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

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

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

Оказывается, песочница все-таки есть. Кто знал? О да, Рэнд знал.

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

Изображение содержит фрагмент технической документации, описывающий атрибут, относящийся к представлениям Chrome. Текст следующий: chromeInTotal (тип: число(), по умолчанию: ноль) — представления Chrome на уровне сайта. Этот атрибут имеет тип Number() со значением по умолчанию, равным нулю, и относится к представлениям на уровне сайта в Chrome.

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

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

Быстрый ответ: не тогда, когда вы подходите слишком близко к секретному “соусу”.

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

АРХИТЕКТУРА РЕЙТИНГОВЫХ СИСТЕМ GOOGLE

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

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

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

Изображение представляет собой диаграмму под названием «Архитектура системы GQA с поисковыми расширениями», представленную Google DeepMind.

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

Изображение представляет собой диаграмму под названием «Пример машинного обучения в компании»

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

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

Сканирование

• Траулер – система сканирования веб-страниц. Он имеет очередь сканирования, поддерживает скорость сканирования и понимает, как часто меняются страницы.

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

• Александрия – основная система индексации.
• SegIndexer — система, которая помещает документы уровней в уровни индекса.
• TeraGoogle — вторичная система индексирования документов, которые долго хранятся на диске.

Рендеринг

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

Обработка

• LinkExtractor — извлекает ссылки со страниц.
• WebMirror – Система управления канонизацией и дублированием.

Рейтинг

• Мустанг – основная система подсчета очков, ранжирования и обслуживания.
• Ascorer – основной алгоритм ранжирования, который ранжирует страницы перед любыми корректировками повторного ранжирования.
• NavBoost – система повторного ранжирования на основе журналов кликов о поведении пользователей.
• FreshnessTwiddler – система изменения рейтинга документов на основе свежести.
• WebChooserScorer — определяет имена функций, используемые при оценке фрагментов.

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

• Веб-сервер Google. GWS — это сервер, с которым взаимодействует интерфейс Google. Он получает полезные данные для отображения пользователю.
• SuperRoot – это мозг поиска Google, который отправляет сообщения на серверы Google и управляет системой постобработки для повторного ранжирования и представления результатов.
• SnippetBrain — система, которая генерирует фрагменты результатов.
• Glue – система объединения универсальных результатов на основе поведения пользователя.
• Cookbook – Система генерации сигналов. Есть указание на то, что значения создаются во время выполнения.

Как я уже сказал, в этих документах описано гораздо больше систем, но не совсем понятно, что они делают. Например, в этих документах также представлены САФТ и Дришти из приведенной выше схемы, но их функции неясны.

ЧТО ТАКОЕ ТВИДДЛЕРЫ?

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

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

Изображение представляет собой скриншот твита Диди (@deedydas) от 27 сентября 2023 года.

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

Когда Google говорит, что что-то вроде Panda не было частью основного алгоритма, это, скорее всего, означает, что оно было запущено как Twiddler для расчета повышения или понижения рейтинга, а затем позже перешло в основную функцию оценки. Думайте об этом как о разнице между рендерингом на стороне сервера и на стороне клиента.

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

• НавБуст
• Повышение качества
• RealTimeBoost
• WebImageBoost

Судя по соглашениям об именах, все они говорят сами за себя.

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

КЛЮЧЕВЫЕ ОТКРЫТИЯ, КОТОРЫЕ МОГУТ ПОВЛИЯТЬ НА ТАК, КАК ВЫ ЗАНИМАЕТЕСЬ SEO

Давайте перейдем к тому, зачем вы на самом деле пришли. Что делает Google, о чем мы не знали или в чем не были уверены, и как это может повлиять на мои усилия по SEO?

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

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

Когда Panda вышла, возникла большая путаница. Это машинное обучение? Использует ли он пользовательские сигналы? Зачем нам нужно обновление или обновление для восстановления? Это по всему сайту? Почему я потерял трафик для определенного подкаталога?

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

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

М=ИЛ/РК,

где IL — количество независимых ссылок, подсчитанных для группы ресурсов, а RQ — количество ссылочных запросов, подсчитанных для группы ресурсов».

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

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

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

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

Не для того, чтобы “добить мертвую лошадь”, но другой патент Panda, показатель качества сайта, также предполагает оценку, которая представляет собой соотношение между ссылочными запросами и выбором или кликами пользователей.

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

Авторы — явная особенность

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

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

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

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

Понижения

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

• Несоответствие привязки. Если ссылка не соответствует целевому сайту, на который она ссылается, ссылка понижается в расчетах. Как я уже говорил ранее, Google ищет релевантность по обе стороны ссылки.
• Понижение результатов выдачи — сигнал, указывающий на понижение на основе факторов, наблюдаемых в результатах выдачи, предполагающий потенциальное недовольство пользователя страницей, которое, вероятно, измеряется кликами.
• Понижение уровня навигации. Предположительно, это понижение уровня навигации, применяемое к страницам, демонстрирующим плохую навигацию или проблемы с пользовательским интерфейсом.
• Понижение уровня доменов с точным соответствием. В конце 2012 года Мэтт Каттс объявил, что домены с точным соответствием не будут иметь такой большой ценности, как это было исторически. Есть специфическая особенность их понижения в должности.
• Понижение уровня обзора продукта. Конкретной информации по этому поводу нет, но оно указано как понижение уровня и, вероятно, связано с недавним обновлением обзоров продуктов в 2023 году.
• Понижение местоположения. Есть признаки того, что «глобальные» и «суперглобальные» страницы могут быть понижены. Это говорит о том, что Google пытается связать страницы с местоположением и соответствующим образом ранжировать их.
• Понижение порно – это довольно очевидно.
• Другие понижения ссылок – мы обсудим в следующем разделе.

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

Ссылки все еще кажутся очень важными

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

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

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

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

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

Существует целый ряд показателей выявления всплесков спам-анкорного текста. Принимая во внимание функцию фразы AnchorSpamDays, 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 предполагает, что некоторые внутренние ссылки не учитываются.

Я не увидел ни одного упоминания об Disavow

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

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

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

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

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

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

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

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

Заголовки страниц по-прежнему оцениваются по запросам

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

Размещение целевых ключевых слов на первом месте по-прежнему является ходом.

Нет никаких мер по подсчету символов

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

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

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

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

• bylineDate — это явно установленная дата на странице.

• SyntacticDate – это дата, извлеченная из URL-адреса или заголовка.

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

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

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

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

К сайтам, ориентированным на видео, относятся по-разному

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

Ваши деньги, ваша жизнь имеет специальную оценку

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

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

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

Существуют документы золотого стандарта

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

Внедрения сайта используются для измерения того, насколько страница соответствует теме.

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

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

Google может целенаправленно сжигать небольшие сайты

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

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

МОИ ОТКРЫТЫЕ ВОПРОСЫ

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

Обновление полезного контента известно как Baby Panda?

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

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

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

Означает ли NSR нейронный семантический поиск?

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

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

ДЕЙСТВИЯ

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

1. Отправьте Рэну Фишкину извинения. После моего основного доклада «Все, о чем нам лгал Google» на PubCon, я участвую в кампании по очистке имени Рэнда в отношении NavBoost. Рэнд проделал неблагодарную работу, пытаясь помочь нашей отрасли развиваться в течение многих лет. За это он получил много критики со стороны Google и со стороны SEO. Иногда он не понимал вещи правильно, но его сердце всегда было на правильном месте, и он прилагал большие усилия, чтобы сделать то, что мы делаем, уважаемым и просто лучше. В частности, он не ошибся в выводах своих экспериментов с кликами, своих неоднократных попытках продемонстрировать существование «песочницы» Google, своих тематических исследованиях, показывающих, что Google по-разному ранжирует поддомены, и своем давно принижаемом убеждении, что Google использует авторитетные сигналы для всего сайта. . Вы также должны поблагодарить его за этот анализ, поскольку именно он поделился со мной документацией. Сейчас хорошее время для многих из вас, чтобы показать ему свою любовь в Threads.
2. Создавайте отличный контент и хорошо его продвигайте – я шучу, но я также и серьезен. Google продолжает давать такие советы, и мы отвергаем их как неосуществимые. Для некоторых оптимизаторов это просто вне их контроля. После рассмотрения этих функций, которые дают Google преимущества, становится совершенно очевидно, что создание более качественного контента и его продвижение среди аудиторий, с которыми он находит отклик, окажет наилучшее влияние на эти показатели. Измерения характеристик ссылок и контента, безусловно, помогут вам довольно далеко, но если вы действительно хотите побеждать в Google в долгосрочной перспективе, вам придется создавать вещи, которые по-прежнему заслуживают рейтинга.
3. Верните корреляционные исследования. Теперь мы гораздо лучше понимаем многие функции, которые Google использует для построения рейтинга. Благодаря сочетанию данных о посещениях и извлечению признаков мы можем воспроизвести больше, чем раньше. Я думаю, что пришло время вернуться к исследованиям вертикальных корреляций.
4. Тестируйте и учитесь. Вы должны были видеть достаточно диаграмм видимости и трафика с осями Y, чтобы знать, что нельзя доверять ничему, что вы читаете или слышите в SEO. Эта утечка является еще одним признаком того, что вам следует принять входные данные и поэкспериментировать с ними, чтобы увидеть, что подойдет для вашего веб-сайта. Недостаточно посмотреть на отдельные обзоры вещей и предположить, что именно так работает Google. Если у вашей организации нет плана экспериментов по SEO, сейчас самое время его начать.

 

МЫ ЗНАЕМ, ЧТО ДЕЛАЕМ

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

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

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

СКАЧАТЬ ОСОБЕННОСТИ РЕЙТИНГА

Что ж, кто-то загрузит и систематизирует для вас все функции в электронной таблице. С таким же успехом это мог быть я. У нас остался всего месяц до конца квартала, и я все равно хочу повысить наши MQL. 😆

Возьмите копию списка функций рейтинга.

МЫ ТОЛЬКО НАЧИНАЕМ

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

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

СЛЕДУЮЩИЕ ШАГИ

Вот 3 способа, которыми iPullRank может помочь вам объединить SEO и контент, чтобы повысить узнаваемость вашего бизнеса и увеличить доход:

1. Запланируйте 30-минутную стратегическую сессию: поделитесь своими самыми большими проблемами в области SEO и контента, чтобы мы могли составить специальную колоду открытий после изучения вашего цифрового присутствия. Никаких универсальных решений, только индивидуальные советы для развития вашего бизнеса. Запишитесь на консультацию прямо сейчас.
2. Смягчите потенциальное влияние обзоров ИИ: насколько подготовлена ​​ваша стратегия SEO к обзорам ИИ от Google? Предупреждайте потенциальные угрозы и обеспечьте сохранение конкурентоспособности вашего сайта с помощью нашего подробного отчета об угрозах с обзорами ИИ. Получите отчет «Обзоры ИИ».
3. Повысьте релевантность вашего контента с помощью Orbitwise: не уверены, что ваш контент математически релевантный? Используйте Orbitwise, чтобы проверить и улучшить релевантность вашего контента, гарантируя, что он будет ранжироваться по целевым ключевым словам. Проверьте актуальность вашего контента сегодня.

Хотите больше? Посетите нашу страницу ресурсов, чтобы получить доступ к прошлым вебинарам, эксклюзивным руководствам и информативным блогам, созданным нашей командой экспертов.

Майк Кинг

Майк Кинг — основатель и генеральный директор iPullRank. Глубоко техничный и очень креативный, Майк помог своим клиентам получить доход в размере более 4 миллиардов долларов. Рэпер и выздоравливающий парень из крупного агентства, лучшие клиенты Майка — две его дочери: Зора и Глори.