Google давно перестал быть машиной строкового совпадения. Между запросом и документом стоит слой сущностей: система распознаёт, о каких объектах реального мира идёт речь, связывает их с Knowledge Graph и оценивает, насколько центрально документ раскрывает нужную сущность. Этот разбор собран по утечке Content Warehouse API (май 2024), показаниям и экспонатам в антимонопольном процессе DOJ против Google, патентам и Quality Rater Guidelines. Дальше будет много конкретики, поэтому сразу граница.
Ядро WebRef: вектор сущностей документаЭто реконструкция по утечкам, судебным материалам и патентам, а не официальная формула ранжирования. Часть полей из утечки могла никогда не доходить до продакшна, часть переименована или выключена. Имена факторов и MID-сущностей настоящие, но вес каждого сигнала Google не публиковал. Относитесь к этому как к карте, а не к таблице коэффициентов.
Центральная подсистема всего слоя - аннотатор WebRef. На индексации он прогоняет страницу через named entity recognition, находит упоминания объектов, разрешает омонимию (disambiguation) и прикрепляет к документу массив сущностей. В утечке это поле PerDocData.webrefEntities и аттачмент RepositoryWebrefMustangAttachment. Сообщество подтвердило: WebRef - это и есть entity understanding engine, питающий Knowledge Graph.
Код: Выделить всё
WebRef-вектор документа (per-doc), отсортирован по топикальности
поле / источник смысл ID статус
---------------------------------------- ------------------------------ ---------- ------------------
webrefEntities (MID+topicality+conf) базовый объект entity-ранга F-ENTITY-001 подтверждён
topicalityE2 / normalizedTopicality центральность; сумма по док=1 F-ENTITY-002 подтверждён
confidenceE2 / confidenceScore уверенность что сущность есть F-ENTITY-003 подтверждён
DetailedEntityScores.docScore относит. конкуренция доков F-ENTITY-004 документирован
DetailedEntityScores.connectedness связанность с co-сущностями F-ENTITY-006 документирован
статус: подтверждён = official-confirms-unofficial; документирован = поле в утечке без офиц. слов
Topicality (центральность). Скор нормализован: сумма топикальности по всем сущностям одного документа равна единице. Это значит, что внимание - игра с нулевой суммой. Каждая лишняя несвязанная сущность откусывает долю у целевой. Страница, целиком про "iPhone 16 Pro", отдаёт этой сущности почти всю топикальность. Статья "20 лучших гаджетов года" размазывает её на двадцать объектов, и каждый получает крохи.
Confidence (уверенность). Агрегируется из per-mention скоров, и упоминания в title, h1 и анкорных текстах входящих ссылок весят заметно больше, чем строка в середине абзаца. Практический вывод прямой: каноническое имя сущности должно быть в теге title, в h1 и в анкорах внутренних ссылок на эту страницу. Не "маркетплейс компании", а точное имя бренда.
docScore (конкуренция). Ненормализованный скор того, насколько именно этот документ соответствует сущности - относительно других документов про ту же сущность. Это и есть поле боя за entity-выдачу. Здесь побеждает глубина и полнота раскрытия, а не частота ключа.
Reference Page: владение сущностьюГлавный вывод по ядру: у страницы должна быть одна ясная главная сущность. Топикальность нормирована на единицу, поэтому мегаматериал обо всём по определению проигрывает в центральности узкой странице под конкретный объект. Несколько фокусных URL обычно сильнее одного раздутого.
Отдельный механизм - выбор эталонной страницы сущности. WebRef офлайн проводит что-то вроде голосования: кто из документов является официальным/reference-источником объекта (поля DetailedEntityScores.isReferencePage, ReferencePageScores.referencePageScore, флаг selected). Побеждает кандидат с максимальным referencePageScore при высокой однотемности - singleTopicness в диапазоне [0,1].
Код: Выделить всё
Кто становится reference page сущности
фактор что повышает шанс ID
------------------------------ ------------------------------------------ -------------
referencePageScore авторитетные анкорные упоминания F-ENTITY-050
singleTopicness (0..1) страница про ОДНУ сущность, без побочных тем
isReferencePage flag URL воспринимается как офиц. источник F-ENTITY-012
ловушка: isDisambiguationPage (страница-список омонимов "X может означать...")
исключается из конкурса reference pages. Не делать её посадочной под сущность.
Knowledge Graph: попадание, факты, верификация
В материалах суда (стр. 148) KG описан как граф порядка 5 млрд сущностей и около 500 млрд связей, и - важно - он используется не только для панелей в выдаче, но и для интерпретации запросов и обогащения обычного ранжирования (F-ENTITY-009). Там же зафиксирован принципиальный факт: KG строится из data feeds, партнёрств и структурированных данных, а НЕ из кликов и запросов пользователей (F-ENTITY-010).
Из текста WebRef извлекает тройки subject-predicate-object с confidence [0,1] (TripleAnnotation). Флаг kgVerified=true означает, что тройка уже подтверждена графом, то есть факт на странице совпадает с тем, что Google уже знает (F-ENTITY-025). Отсюда правило: согласовывайте ключевые атрибуты сущности (год основания, официальное название, сфера) с Wikidata, Wikipedia и отраслевыми справочниками. Противоречия - это риск, а не нейтральный шум.Не путайте поведенческий слой с entity-слоем. Накрутка кликов и поведения не создаёт запись в Knowledge Graph. Entity-ясность строится через авторитетные структурированные источники, официальные данные, фиды и непротиворечивые факты. Это разные конвейеры.
Свежий контекст 2025 года это только усиливает. В июне 2025 Google провёл то, что Jason Barnard назвал Great Clarity Cleanup: за неделю из Knowledge Graph удалили порядка 3 млрд сущностей - сознательный размен количества на ясность и достоверность, чтобы граф надёжнее питал AI Overviews, AI Mode и Google Learn About. Вывод для практиков: ставка сместилась с "как-нибудь попасть в граф" на "быть однозначно и непротиворечиво определённым". Размытые, дублирующиеся, плохо подтверждённые сущности теперь скорее вычищаются.
Имплицитные сущности и связанность
WebRef умеет выводить сущности, которые на странице прямо не названы: "gym" тянет за собой Sports, "Lionel Messi" - FC Barcelona (поля Mention.isImplicit, ExtraMetadata.latentEntities). Это расширяет семантическое покрытие за пределы буквально написанного и обесценивает keyword-стаффинг - механически перечислять все термины уже не нужно.
Рядом - Entity Connectedness Score (F-ENTITY-006): насколько целевая сущность вписана в окружение из родственных объектов. Изолированное слово без контекста слабее, чем сущность, окружённая своими co-entities.
Код: Выделить всё
Connectedness на практике, страница про "Python (язык программирования)"
укрепляет главную сущность ослабляет / размывает
------------------------------- ----------------------------------
Django, pip, PyPI, CPython случайные несвязанные темы на том же URL
GIL, virtualenv, asyncio упоминание Python без контекста экосистемы
примеры кода, версии релизов смешение с "Python" (змея) без disambiguation
В entity-векторе документа есть отдельные индексы: isAuthorIndex и isPublisherIndex (WebrefMustangAttachment), а на уровне сущности - флаги isAuthor (настраивался под новости и научные статьи) и isPublisher, например CNN на cnn.com (DetailedEntityScores, F-ENTITY-032 и F-ENTITY-049). То есть статья связывается не просто со строкой-именем, а с entity-авторитетом конкретного автора и издателя как объектов KG.
Практика, которую подтверждает и SEO-консенсус 2025-2026: делайте автора и издателя распознаваемыми сущностями. Отдельная страница автора с биографией, разметка Person и Organization в schema.org, и главное - sameAs на авторитетные внешние идентификаторы (Wikidata, LinkedIn, Crunchbase, Google Scholar). Свойство sameAs называют соединительной тканью между сайтом и Knowledge Graph: каждый его адрес - внешний источник, по которому Google перепроверяет личность сущности.
Deep-learning retrieval: RankEmbed и эмбеддинги
Семантический матчинг идёт мимо точных слов. В материалах DOJ (стр. 154) описан RankEmbed (F-ENTITY-042) - это, по показаниям, dual-encoder модель: запрос и документ проецируются в общее embedding-пространство, а близость считается через скалярное произведение или расстояние. Очень быстро и сильно на частотных запросах; на редком длинном хвосте слабее. Плюс PassageEmbed Score (F-ENTITY-045) - релевантность отдельного абзаца по его эмбеддингу, используется при скоринге сниппетов.
Для PassageEmbed пишите абзацы как самодостаточные блоки: чёткий тезис плюс раскрытие в несколько предложений. Абзац, отвечающий на конкретный вопрос, выигрывает у длинного фрагмента без ясной мысли.Главный практический сдвиг: оптимизируйте под смысл и полноту охвата темы, а не под точную ключевую фразу. Документ, всесторонне раскрывший тему, подтягивается по семантически близким запросам, даже если конкретной формулировки на странице нет. Особенно это важно для длинного хвоста. Но: RankEmbed - не вся выдача. Судебные документы показывают стек, где сохраняется PageRank и поведенческие сигналы (Navboost), а LLM-слой надстраивается поверх. Семантика дополняет, а не отменяет ссылки и поведение.
Категоризация и негативные сигналы
Код: Выделить всё
Сигнал поведение ID знак
----------------------------------- ------------------------------------------- ------------- -------
Category Confidence (0..1) уверенность в теме; <0.05 = нерелевантна F-ENTITY-048 +
иерархия: NBA тянет Basketball
Name Variant Prior / volumeBased artificial = prior - volumeBased; F-ENTITY-027 анти-манип.
отделяет органический авторитет от надутого
Entity Fringe / contextFringeScore "окраинность": имя нетипично для контекста F-ENTITY-040 штраф
ассоциация с fringe-запросами, минус доверие
Name Variant Prior отделяет органический авторитет имени (измеримый объём из авторитетных источников) от искусственно раздутого: artificial_score = prior_score минус volume_based_score. Массовые неестественные упоминания не дают доверенного prior. Fringe-сигналы понижают доверие к контенту по маргинальным, конспирологическим и чрезмерно нишевым темам.
Чего избегать (сжатый чек-лист)
Код: Выделить всё
- Размытие темы множеством несвязанных сущностей на одном URL (топикальность нормирована).
- Сущность только в URL и анкорах, но не в видимом тексте -> WebRef метит isImplicit = слабое покрытие.
- Накачка имени неестественными упоминаниями -> зона artificial_score, не органический prior.
- Disambiguation-страница ("X может означать...") как посадочная под сущность -> вне reference-конкурса.
- Факты на странице против KG (год, название, сфера) -> kgVerified не сработает, риск недоверия.
Слой сущностей у Google устроен непротиворечиво: WebRef через NER привязывает к документу вектор сущностей с топикальностью и confidence, Knowledge Graph даёт интерпретацию и верификацию фактов, RankEmbed добавляет семантический матчинг по смыслу. Подтверждённое ядро (F-ENTITY-001..004, 009, 012) - это база. Конкретные пороги, веса и судьба отдельных полей после 2024 - спорная зона, ничего гарантировать здесь нельзя. Рабочая стратегия не меняется от номера фактора: одна ясная главная сущность на URL, каноническое имя в title/h1/анкорах, согласованные с KG факты, разметка author/publisher с sameAs на авторитетные идентификаторы, полнота охвата вместо плотности ключей.