Проверка сигналов E-E-A-T и связи с сущностью: разбор инструмента eeat-entity-signals

Проверка сигналов E-E-A-T и связи с сущностью: разбор нашего инструмента eeat-entity-signals

В эпоху генеративного поиска, когда нейросети синтезируют ответы из множества источников, вопрос доверия к конкретному сайту становится вопросом выживания. Если раньше мы боролись за место в топ-10 выдачи, то теперь алгоритм может просто «пересказать» наш контент, не дав ни одного клика. Но как модель решает, какой источник заслуживает быть основой для ответа? Мы не знаем точных формул, но логично предположить: ей нужно опираться на нечто более весомое, чем просто набор слов. Этим «нечто» является сущность — автор, эксперт, организация, за которой стоит реальная репутация. Именно поэтому мы разработали инструмент eeat-entity-signals, и сегодня честно разберем, что он умеет, а что — нет.

Представьте, что вы задаете вопрос нейросети: «Кто лучше — Стив Джобс или Билл Гейтс?». Модель не может «знать» их лично. Она анализирует миллионы текстов. Но если она увидит статью на example.ru без подписи автора, где нет ни одной ссылки на первоисточник, и статью на example.org, где автор — реальный человек с профилем в Wikipedia и LinkedIn, а каждый тезис подкреплен ссылкой на исследование, выбор очевиден. Второй источник имеет более сильные «следы сущности». Наш инструмент создан для того, чтобы выявить эти следы на вашей странице.

E-E-A-T как концепция: откуда она взялась и что реально измерить

Термин E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) появился не как секретный алгоритм ранжирования, а как инструкция для людей-асессоров качества поиска Google. Эти специалисты вручную оценивают, насколько страница полезна и заслуживает ли она высоких позиций. Представьте, что асессор видит страницу о лечении кашля. Если текст написан анонимом без медицинского образования и ссылок на исследования — это минус. Если же автор — практикующий врач с указанием диплома и ссылками на PubMed — это плюс.

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

Почему это важно для генеративного поиска? Современные большие языковые модели при синтезе ответа вынуждены выбирать, каким источникам доверять больше. Они не читают биографию автора вручную. Вместо этого они анализируют структуру данных. Если на странице есть размеченный JSON-LD с указанием автора как Person, если этот автор имеет ссылки sameAs на свои профили в соцсетях и энциклопедиях, если в тексте есть видимая подпись — это мощный сигнал. Модель понимает: «За этим текстом стоит конкретный человек. У него есть публичная история. Ему можно доверять больше, чем анонимному блогеру».

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

Честный разбор: как именно работает инструмент eeat-entity-signals

Давайте сразу расставим точки над i. Наш инструмент — это чисто структурная проверка одной страницы за один HTTP-запрос. Он не ищет в интернете информацию об авторе, не проверяет его дипломы и не читает его статьи. Он анализирует только HTML-код и JSON-LD разметку конкретного URL. Это важное ограничение, которое нужно понимать до начала работы.

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

Проверка 1: Наличие Person-схемы или автора в JSON-LD

Первое, что делает инструмент — парсит все блоки JSON-LD на странице. Он ищет узел с @type: "Person". Это стандартный словарь Schema.org, который описывает человека. Если такой узел найден — отлично. Если нет, инструмент ищет свойство author, которое должно быть объектом (а не просто строкой). Если в свойстве author указан объект с именем и, возможно, другими полями — это тоже считается прохождением.

Почему это критично? Без именованного автора модели сложнее оценить экспертность источника. Если в JSON-LD нет Person, то вся статья для машины — обезличенный текст. Представьте, что вы читаете медицинский совет на форуме без ника и аватара. Даже если совет гениален, вы не можете проверить, кто его дал. Аналогично работает и нейросеть. Если проверка не пройдена, инструмент выдаст статус fail с пояснением: «без именованного автора модели сложнее оценить экспертность источника».

Пример правильной разметки для example.ru:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Иван Петров",
  "url": "https://example.ru",
  "jobTitle": "Врач-кардиолог",
  "worksFor": {
    "@type": "Organization",
    "name": "Клиника example"
  }
}

Важно, чтобы этот блок находился в коде страницы, а не был просто текстом в статье. Инструмент ищет именно JSON-LD, а не упоминание имени в видимом тексте.

Проверка 2: Ссылки sameAs на внешние профили

Второй шаг — анализ свойства sameAs внутри найденного Person-узла. Это свойство предназначено для указания URL-адресов, которые подтверждают, что этот человек — тот же самый, что и на других платформах. Инструмент извлекает все ссылки из массива sameAs и сверяет их домены с фиксированным списком из 10 распознаваемых площадок.

Вот этот список дословно:

• wikipedia.org
• wikidata.org
• linkedin.com
• vk.com
• t.me
• github.com
• twitter.com
• x.com (при этом twitter.com и x.com считаются разными доменами, хотя ведут на один ресурс)
• facebook.com
• instagram.com

Если инструмент находит совпадение хотя бы с одним доменом из списка — проверка пройдена (статус pass). При этом он перечислит, какие именно домены найдены (например: wikipedia.org, linkedin.com). Если совпадений нет — инструмент выдаст предупреждение (warn) со следующим текстом: «ссылки на Wikipedia/LinkedIn/соцсети подтверждают, что сущность существует за пределами вашего сайта».

Здесь кроется важное ограничение. Список доменов жестко задан в коде инструмента. Если ваш автор ведет блог на платформе example-blog.com или имеет профиль на малоизвестном форуме, инструмент не распознает это как sameAs-сигнал, даже если технически ссылка прописана правильно. Это не ошибка, это осознанная архитектура: мы включили только самые авторитетные и часто используемые площадки, которые реально подтверждают существование человека в вебе.

Проверка 3: Видимая подпись автора в HTML

Третья проверка направлена на поиск видимых следов автора в самом HTML-коде страницы, вне JSON-LD. Инструмент ищет два типа маркеров:

• Атрибут rel="author" — устаревший, но все еще встречающийся способ указать авторство. Обычно он прописывается на ссылке с именем автора.
• CSS-класс, содержащий слово «author». Это может быть class="author-name", class="post-author", class="author-bio" и так далее. Инструмент использует регулярное выражение по всем классам в HTML.

Если найдено хотя бы одно совпадение — статус pass с формулировкой «видимая подпись автора найдена». Если нет — инструмент выдаст предупреждение: «ни rel=author, ни класс с author не обнаружены».

Зачем это нужно? Дело в том, что поисковые системы и модели доверяют не только скрытой разметке, но и тому, что видит пользователь. Если посетитель видит подпись «Автор: Иван Петров» с классом author, это подтверждает, что контент не анонимен. Видимая подпись — это второй уровень подтверждения после JSON-LD. Она не должна противоречить данным из структурированной разметки.

Обратите внимание: инструмент не проверяет, совпадает ли имя в подписи с именем в JSON-LD. Он лишь констатирует факт наличия технического маркера. Это часть осознанного ограничения «проверка следов, а не реальности».

Проверка 4: Количество внешних ссылок на источники

Последняя проверка — самая простая, но не менее важная. Инструмент подсчитывает количество ссылок на странице, у которых атрибут href начинается с http:// или https://. Важная деталь, о которой стоит честно сказать: инструмент не сравнивает домен ссылки с доменом самой страницы. Это значит, что ссылка на вашу же страницу, если она оформлена полным адресом (href="https://example.ru/drugaya-stranitsa"), а не относительным путём (href="/drugaya-stranitsa"), тоже попадёт в счётчик. Технически это не «исходящие ссылки на источники» в строгом смысле, а «ссылки с абсолютным http/https-адресом» — разница важна, если ваша CMS генерирует внутренние ссылки полными URL.

Порог срабатывания жестко задан: более 3 ссылок. То есть если инструмент находит 4 и более внешние ссылки — проверка пройдена (pass) с сообщением «внешние ссылки на источники: есть». Если ссылок 3 или меньше — выдается предупреждение (warn): «внешние ссылки на источники: мало или нет», с пояснением, что ссылки на первоисточники усиливают доверие.

Это чисто количественный подход. Инструмент не анализирует, ведут ли ссылки на авторитетные сайты или на спам-ресурсы. Он не проверяет, уместны ли ссылки в контексте. Если на странице есть 4 ссылки на example.ru, example.org, example.net и example.com — проверка будет пройдена, даже если эти сайты не имеют отношения к теме статьи. Это ограничение следует понимать и использовать осознанно.

Итоговый статус страницы

После выполнения всех четырех проверок инструмент вычисляет итоговый статус по простой логике:

• Если хотя бы одна проверка завершилась со статусом fail — итоговый статус будет fail.
• Если нет ни одного fail, но есть хотя бы одно warn — итоговый статус warn.
• Только если все четыре проверки дали pass, итоговый статус будет pass.

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

Почему список доменов sameAs фиксированный и что с этим делать

Мы уже упомянули, что инструмент распознает только 10 доменов для sameAs. Это осознанное решение, и у него есть как плюсы, так и минусы. Плюс в том, что мы не пытаемся объять необъятное. Wikipedia, LinkedIn и GitHub — это глобальные реестры личностей. Если у человека есть профиль там, это сильное подтверждение его существования. Минус — в том, что вы можете быть автором на Хабр (habr.com), профильным экспертом на VC.ru или иметь аккаунт на профессиональном форуме врачей. Инструмент этого не увидит.

Что делать в такой ситуации? Во-первых, не паниковать. Если ваш автор не представлен в этих 10 доменах, но имеет вес в узкой нише, инструмент покажет warn, а не fail. Это означает, что ситуация улучшаема. Во-вторых, стоит задуматься о создании профилей на распознаваемых площадках. Например, завести карточку в Wikidata или хотя бы создать публичную страницу в LinkedIn. Это бесплатно и занимает 15 минут. Даже если вы не ведете там активную деятельность, сам факт наличия профиля с биографией и ссылкой на ваш сайт — это сильный сигнал.

В-третьих, помните: sameAs должен быть взаимным. Если вы указываете в JSON-LD ссылку на профиль в LinkedIn, убедитесь, что в этом профиле есть ссылка на ваш сайт или на страницу с этим JSON-LD. Иначе связка не будет полной.

Порог «>3 внешних ссылок»: как использовать это осмысленно

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

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

Правильная стратегия — использовать внешние ссылки как доказательную базу. Если вы пишете о кардиологии, ссылайтесь на исследования в PubMed, на рекомендации ВОЗ, на статьи в авторитетных медицинских журналах. Если вы пишете о маркетинге — ссылайтесь на кейсы известных компаний, отчеты исследовательских агентств. Каждая ссылка должна отвечать на вопрос: «Где это подтверждено?». Тогда количество (более 3) станет качеством.

Кстати, инструмент не различает ссылки на example.ru и ссылки на правительственные сайты. Но асессор Google — различает. Поэтому не пытайтесь обмануть систему формальным соблюдением порога. Лучше потратить время на поиск действительно ценных источников.

Практический чек-лист: как пройти все четыре проверки

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

Шаг 1: Добавьте JSON-LD с Person-схемой

Вам нужно разместить в коде страницы блок разметки JSON-LD. Это можно сделать в секции <head> или в конце страницы перед закрывающим тегом </body>. Главное, чтобы скрипт был валидным. Вот минимальный пример для example.ru:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Иван Петров",
  "url": "https://example.ru",
  "jobTitle": "Технический директор",
  "sameAs": [
    "https://ru.wikipedia.org/wiki/Иван_Петров",
    "https://www.linkedin.com/in/ivanpetrov",
    "https://github.com/ivanpetrov"
  ]
}
</script>

Обратите внимание: мы добавили свойство sameAs сразу. Это нужно, чтобы пройти вторую проверку. Если автор не имеет профилей на распознаваемых площадках, сначала создайте их, а потом добавляйте ссылки.

Шаг 2: Убедитесь, что sameAs ведут на реальные профили

Мало прописать ссылку на Wikipedia. Нужно, чтобы страница в Wikipedia существовала и действительно описывала вашего автора. Если у вас нет статьи в Wikipedia, не пытайтесь ее создать — это сложный процесс. Вместо этого используйте LinkedIn или GitHub. Создайте профиль, заполните его биографию, добавьте ссылку на ваш сайт. Только после этого включайте URL в sameAs.

Шаг 3: Добавьте видимую подпись автора с классом author

В шаблоне вашей страницы найдите место, где выводится имя автора. Оберните его в элемент с классом, содержащим слово «author». Например:

<div class="article-author">
  <span class="author-name">Иван Петров</span>
</div>

Если у вас используется WordPress, такие классы часто уже есть в теме. Проверьте код страницы через браузерный инспектор. Если класса нет — добавьте его вручную через файл шаблона или через дополнительный HTML-блок.

Шаг 4: Добавьте более трех внешних ссылок на источники

Перечитайте статью и найдите места, где вы упоминаете факты, цифры или мнения, которые требуют подтверждения. Добавьте ссылки на авторитетные источники. Это могут быть исследования, официальные документы, статьи других экспертов. Убедитесь, что ссылки оформлены как обычные гиперссылки с атрибутом href, начинающимся с http:// или https://, и ведут на домены, отличные от вашего собственного, — инструмент технически не проверяет домен и засчитает даже абсолютную ссылку на ваш же сайт, но пользы для реального доверия читателя и модели такая «внешняя» ссылка не несёт.

Шаг 5: Проверьте результат

Откройте инструмент eeat-entity-signals, введите URL вашей страницы и запустите проверку. Если все сделано правильно, вы увидите четыре пункта со статусом pass и итоговый статус pass.

FAQ: частые вопросы о работе инструмента

1. Проверяет ли инструмент, что автор реально существует и является экспертом?

Нет. Это самый важный честный ответ. Инструмент проверяет только технические следы: наличие Person-схемы в JSON-LD, ссылок sameAs на определенные домены, видимой подписи с классом author и количества внешних ссылок. Он не проверяет биографию, дипломы, публикации или признание в отрасли. Вы можете указать в качестве автора вымышленного персонажа, и если вы правильно разметите JSON-LD и добавите ссылку на несуществующий профиль LinkedIn, инструмент покажет pass. Это ограничение заложено в архитектуру: мы не можем автоматически проверить реальность человека, мы лишь проверяем, оставил ли сайт достаточно улик для машины.

2. Что делать, если автор не хочет светить личные профили в соцсетях?

Это легитимная позиция. В таком случае можно использовать Wikidata или Wikipedia (если статья существует). Также подойдет GitHub для разработчиков или LinkedIn, если вы готовы создать профиль без личных данных (только имя и должность). Если автор категорически против публичности, инструмент покажет warn на второй проверке, но общий статус может остаться pass, если все остальные проверки пройдены. Однако помните, что warn — это сигнал о потенциальной слабости.

3. Влияет ли прохождение этих проверок на позиции в поисковой выдаче?

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

4. Почему в списке sameAs нет, например, Habr или VC.ru?

Мы выбрали 10 доменов, которые имеют глобальное или очень широкое национальное признание и чаще всего используются в качестве реестра личностей. Wikipedia, Wikidata, LinkedIn, GitHub — это международные базы. VK и Telegram — популярные в русскоязычном сегменте. Habr и VC.ru — это нишевые платформы, которые, безусловно, важны, но их аудитория ограничена. Мы не утверждаем, что они хуже, мы просто не включили их в базовый список, чтобы не раздувать его до бесконечности. Возможно, в будущем мы расширим список.

5. Если у меня 3 внешние ссылки, а нужно 4, что делать?

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

6. Нужно ли размещать JSON-LD с Person на каждой странице сайта?

Желательно, но не обязательно на каждой. Инструмент проверяет одну страницу. Если у вас блог, и каждая статья имеет своего автора, логично добавить Person-схему в каждую статью. Если у вас корпоративный сайт с одним автором всех текстов, можно добавить разметку на основные страницы. Однако помните: чем больше страниц имеют четкую привязку к сущности автора, тем лучше для формирования общего доверия к сайту.

Заключение

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

Мы сознательно пошли на компромисс между глубиной анализа и скоростью работы. Один HTTP-запрос, четыре проверки, четкие пороги. Этого достаточно, чтобы понять, есть ли у страницы базовый каркас доверия. Если вы получили fail — не отчаивайтесь. Добавьте JSON-LD, создайте профиль в LinkedIn, укажите автора в видимой подписи. Это займет не более часа, но заложит фундамент для долгосрочного роста доверия к вашему контенту.

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