Как поисковики оценивают релевантность текста

Два сайта, одна тема, оба с правильными Title, H1 и ключами. Один в топ-3, другой на второй странице. А какого… В смысле, почему?

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

Разберемся, что происходит между вводом запроса и появлением страницы в выдаче.

Про что вообще релевантность

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

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

Обе системы говорят об одном. Поиск давно перестал спрашивать «о чём этот текст?» и начал спрашивать «поможет ли он человеку?».

Первый слой: слова

Начнём с основы, потому что она никуда не делась.

До BM25 был TF-IDF — и понять его полезно, чтобы потом было понятно, зачем BM25 его заменил. TF (term frequency) — сколько раз слово встречается в документе. IDF (inverse document frequency) — насколько редко оно встречается во всей коллекции. Скор считается как произведение: TF · IDF. Ну, например, слово «купить» встречается в каждом втором документе, его IDF близок к нулю, вклад в релевантность минимальный. Слово «синхрофазатрон» редкое — высокий IDF, высокий вклад. Модель рабочая, но у неё есть проблема — TF растёт линейно. Чем чаще слово в тексте — тем выше скор, без ограничения сверху. Это открывало дорогу для спама ключевыми словами.

BM25 (Best Match 25) эту проблему решает. Формула для одного термина запроса выглядит так (это для общего понимая, дальше уже будем разбираться без формул):

Здесь tf — частота термина в документе, |D| — длина документа, avgdl — средняя длина документа в коллекции. Параметр k₁ (обычно 1.2–2.0) управляет насыщением частоты — при больших tf функция выходит на плато, а не растет бесконечно. Параметр b (обычно 0.75) регулирует поправку на длину документа — без него длинные страницы получали бы преимущество просто потому, что в них больше слов. При b = 0 поправка отключается, при b = 1 — максимальная нормировка.

Итоговый скор — сумма по всем словам запроса. Один из инженеров Google в судебных материалах 2025 года по делу США против Google назвал этот подход «традиционным для Google в стиле Okapi BM25».

Практически из формулы следует три вещи:

1. Частота помогает, но нелинейно — второе вхождение даёт прирост, двадцатое почти не меняет скор.

2. Редкие термины весят больше — IDF у «синхрофазатрона» на порядки выше, чем у «купить». 

3. Длинный документ получает штраф за «разбавленность» — ему нужно больше реально значимых вхождений, чтобы выглядеть сфокусированным. Отсюда и понятно, почему набивка текста ключами не работает: BM25 видит это как рост tf при достаточно большом |D|, и насыщение быстро съедает прирост.

Кроме частоты слов, есть расположение. Title, H1, начало текста, подзаголовки весят больше, чем третий абзац снизу. Яндекс пишет, что title передаёт «представление о содержании страницы и её релевантности поисковому запросу». Это то, что система читает в первую очередь.

И есть ещё одна вещь, которую в SEO можно назвать «шириной» и «глубиной». Глубина — насколько проработана основная тема внутри текста, грубо говоря, насколько значимый tf у ключевых терминов. Ширина — сколько связанных подтем и сущностей охвачено — это то, сколько разных релевантных терминов вообще попало в документ и получило ненулевой вклад в суммарный скор. Эти понятия, естественно, неофициальные, не метрики из патентов Яндекса — но они относительно точно описывают реальное поведение лексической модели. Если статья про релевантность упоминает слово «релевантность» один раз на 10 000 символов, tf минимален, и системе сложно понять, что это главная тема. А если охвачены только два-три термина из десяти связанных — конкурент с более полным покрытием при прочих равных выиграет.

Давайте представим такую аналогию. Текст — это карта. Глубина — насколько детально нарисован один район. Ширина — сколько районов вообще попало на карту. Дальше мы увидим, что в векторном поиске «ширина» приобретает новый смысл, мы еще вернемся к этому.

Второй слой: смысл

BM25 не понимает смысл. Это счетчик с поправками — хорошо откалиброванный, но всё равно счётчик, который просто считает.

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

Для этого нужны эмбеддинги (не знаю, как лучше по-русски, возможно “встраивания”, но звучит коряво). Текст преобразуется в числовой вектор в многомерном пространстве, где близкие по смыслу фрагменты оказываются близкими геометрически. Схожесть измеряется через косинусное расстояние или скалярное произведение — в зависимости от того, нормированы ли векторы. Когда они нормированы, это одно и то же.

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

Bi-encoder (модель на основе двух энкодеров) кодирует запрос и документ независимо, каждый в свой вектор. Близость считается потом, одной операцией сравнения. Это быстро — можно заранее посчитать векторы для всех документов и хранить их в индексе. Именно так устроен RankEmbed у Google — поэтому он хорошо работает на первом этапе отбора кандидатов, где нужно быстро перебрать миллиарды страниц и показать пользователю в поисковой выдаче релевантные результаты.

Cross-encoder получает запрос и документ вместе, как одну последовательность, и вычисляет релевантность за один проход. Это намного точнее — модель видит взаимодействие каждого слова запроса с каждым словом документа. Но это дорого. посчитать заранее нельзя, каждую пару нужно прогонять отдельно. Поэтому cross-encoder используется на этапе переранжирования — когда кандидатов уже немного (сотни, не миллиарды) и точность важнее скорости.

Bi-encoder на отборе кандидатов, что-то вроде cross-encoder на переранжировании. Яндексовый YATI — трансформер, работающий с запросом и документом совместно — ближе именно ко второй архитектуре. Отсюда и высокая точность, и высокая вычислительная стоимость, и то, почему он используется как финальный сигнал, а не для первичного отбора.

Google начал открыто говорить об эмбеддинговом поиске ещё в 2018 году под названием Neural Matching. Яндекс шел похожим путём: в 2016-м алгоритм «Палех» начал сопоставлять заголовки страниц и запросы через нейросеть, в 2017-м «Королёв» распространил это на тексты целиком, в 2020-м появился YATI.Яндекс сам назвал YATI крупнейшим скачком качества ранжирования со времён Матрикснета.

Теперь вернемся к предыдущему разделу. «Ширина и глубина» в лексической модели — это про tf и покрытие терминов. В векторной модели это приобретает другой смысл, «ширина» — это сколько релевантных подтем и сущностей документа попадает в эмбеддинговое представление и уменьшает расстояние до запроса. Страница, которая затрагивает только один аспект темы, даёт вектор, далёкий от запросов про другие аспекты. Google явно называет это topical coverage — покрытие темы.

Гибридный поиск — комбинация BM25 и векторного поиска — возникает именно потому, что каждый подход закрывает слабости другого. BM25 даёт точность по конкретным словам, векторы дают охват по смыслу. Яндекс через CatBoost собирает сотни факторов о запросе и документе — и сигнал от YATI с 2020 года называет самым сильным из них.

Третий слой: пользователь

Также идеально оптимизированный текст может оказаться на второй странице, если пользователи с ним не остаются.

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

Google говорит об «агрегированных и обезличенных данных взаимодействий» как сигнале для машинного обучения. Из материалов 2025 года понятно чуть больше, там описывается Navboost — таблица пользовательской активности по парам «запрос-документ» за 13 месяцев. Один из инженеров компании связывает клики с тем, как долго пользователь оставался на странице до возврата в выдачу.

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

Конкретный пример. Команда Webit работала с сайтом Techport и предположила, что перегруженное сквозное меню добавляет слишком много лишних слов в текстовую модель каждой страницы. Отключили JS-рендеринг этого меню для Яндекса. Видимость сайта выросла на 200%, клики — на 175%. Шум в тексте страницы мешает поисковику понять, о чём она.

Четвертый слой: качество

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

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

Для YMYL-тематики — здоровье, финансы, право работает жёстче. Страница юридической компании без имени автора, без реквизитов, без признаков реальной экспертизы слабее страницы, где это всё есть. Не потому что поисковик «видит слог автора» — просто в тексте присутствуют или отсутствуют конкретные сигналы, которые системы научились распознавать.

Кейс KPI Lab по юридической тематике в Яндексе — сгруппировали запросы, подобрали посадочные страницы, переработали контент с участием копирайтера с опытом в юридической теме. Результат — 77% из 440 запросов в топ-10, трафик из Яндекса вырос в 2,5 раза. Хороший аргумент против тезиса «в семантическом поиске ключи больше не нужны». Нужны — но в виде правильной карты релевантности плюс реальная экспертность контента.

AI-выдача как новый слой

В 2025–2026 году поверх всего этого добавился ещё один вопрос, попадет ли страница в ответ Алисы AI или Google AI Overviews.

По данным Ahrefs за февраль 2026, присутствие AI Overview в выдаче коррелирует с падением среднего CTR у первой позиции на 58% — данные по 300 000 ключевым словам. Годом раньше тот же эффект оценивали в 34,5%. Другое исследование зафиксировало, что пользователи кликают по обычному результату в 8% визитов с AI Summary против 15% без него.

Еще одни исследователи при этом обнаружили любопытное — страницы, цитируемые внутри AI Overview, получают более высокий органический CTR, чем не цитируемые страницы в той же выдаче. Попасть в источники — лучше, чем просто быть рядом.

Яндекс в апреле 2026 открыл инструмент «Видимость сайта в Алисе AI» в Вебмастере — с долей упоминаний, динамикой и примерами запросов. Ежемесячная аудитория ответов Алисы AI — 46,5 млн пользователей. У Google появились отдельные отчёты в Search Console по видимости в AI Overviews и AI Mode.

Специальных (или лучше сказать, официальных) требований для попадания в AI-ответы нет. Страница должна быть индексируемой, качественной и соответствовать интенту. Если вы хорошо делали обычное SEO — вы уже в нужной точке. Просто метрика сместилась с «сколько кликов» на «как часто тебя цитируют».

Коммерческие и информационные страницы: разная релевантность

Всё описанное выше работает и для статьи в блоге, и для карточки товара. Но для коммерческих страниц текстовая релевантность — только часть всех факторов.

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

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

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

И ещё один момент. Смешивать коммерческий и информационный интент на одной странице — плохая идея. Попытка продать натяжные потолки и одновременно рассказать, что такое натяжные потолки на одной странице размывает тематический сигнал. Поисковик хуже понимает, под какой запрос оптимизирована страница, пользователь приходит с одной задачей и видит другую — короткий возврат, слабый Профицит. Правило простое. Для информационных запросов — пишем много текста, для коммерческих — отдельные посадочные страницы с полным набором коммерческих сигналов и текстом, размещенным в разных коммерческих блоках. Его может быть тоже много, но не в формате полотна.

Что из этого следует

Релевантность страницы в 2026 году — это одновременно про слова (лексическое совпадение с запросом), про смысл (семантическое сходство), про пользу (поведенческое подтверждение, что задача закрыта) и про доверие (признаки экспертности и авторитетности).

SearchPilot проверял это в контролируемых экспериментах. Добавление реально полезной информации на страницы магазинов — плюс 8%. Вынос скрытого в табах контента в видимую область — плюс 12%. Добавление ещё трёх ключей в title — результат неопределенный, никакого значимого эффекта. А удаление шаблонных SEO-текстов с категорийных страниц дало статистически значимый рост — лишний контент размывал тему и ухудшал удобство страницы.

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

Но, должен четко пояснить, точные формулы поиска кандидатов у Яндекса и Google не опубликованы. BM25 — корректная учебная, а не практическая модель в реальной системе.Точные веса и архитектуры нейросетевых слоёв тоже скрыты.

Как проверить релевантность страницы перед публикацией

Это всё, конечно, интересно — формулы, модели, эмбеддинги. А что с этим делать простым смертным?

1. Выписать основной интент. Человек хочет узнать, купить, сравнить или решить конкретную проблему? Запрос «как перейти из тестировщика в разработку» подразумевает не информацию о “узнать про профессию тестировщика», а про «получить план перехода — что учить, сколько времени займёт, с чего начать». Если страница отвечает на другой вопрос — она нерелевантна, сколько бы ключей в неё ни добавили.

2. Проверить, что Title и H1 попадают в интент, а не просто содержат ключ. Title «Профессия тестировщик: обязанности и зарплаты» и Title «Как перейти из тестирования в разработку: пошаговый план» — оба про тестировщиков, но отвечают на разные вопросы.Проверьте, если убрать ключевое слово из заголовка, понятно ли из него, что получит пользователь?

3. Сравнить топ-10 по интенту. Открыть выдачу Яндекса по целевому запросу — не в SEO-инструменте, а просто в браузере. Посмотреть, какие подтемы есть у всех сильных страниц? Какие блоки присутствуют у большинства? Что есть у топ-3, но нет у топ-10-20? Не нужно тупо копировать структуру (что, кстати говоря, довольно рабочая методика), нужно понять, что алгоритм считает «полным ответом» для данного запроса. Если у всех в топе есть раздел с конкретным планом действий, а у вас только общие рассуждения — это сигнал поисковику, что ваш контент менее релевантен.

4. Убрать шаблонный шум. Большое сквозное меню с десятками ссылок (опять же, тут индивидуально, потому что иногда сквозное меню как нужно для охвата), SEO-портянка в подвале на 500 слов, блоки «мы лучшие с 2005 года» — всё это текстовый шум, который разбавляет тематический сигнал страницы. Спросите себя (а лучше, проанализируйте каким-нибудь сервисом) если поисковик прочитает страницу как один документ, о чём она будет? Возможно, в вашем сквозном меню есть столько вхождений запросов, что они размывают контент на всех страницах.

5. Добавить сущности и конкретику. Даты, цифры, определения, примеры, таблицы. Не «многие компании используют…», а «по данным Яндекс Вебмастера за апрель 2026…». Не «это важно для SEO», а «в проведенном такими-то ребятами эксперименте показаны такие-то результаты». Конкретика работает и для алгоритмов, и для людей — поисковик видит больше тематических сущностей, пользователь получает реальную ценность.

6. Проверить экспертность. Видно ли из страницы, кто её написал и почему ему можно доверять? Для Яндекса это ЭПОС — экспертность и оригинальность. Для Google — E-E-A-T с акцентом на доверие. Есть ли имя автора с биографией, ссылки на первоисточники, методология, признание ограничений («эти данные справедливы для Яндекса, по Google картина другая»)?

7. Проверить видимость важного контента. Ключевые блоки не спрятаны в табах, аккордеонах, JS-компонентах, которые не рендерятся при краулинге (это важно, если контент в табах, но он рендерится сразу — то всё ок)? Яндекс при оценке учитывает удобство структуры текста, абзацев и заголовков. Простой способ проверить — открыть страницу с отключенным JS и посмотреть, что видит краулер.

8. После публикации смотреть правильные метрики. Позиции — не единственный сигнал и даже не самый главный. Из Яндекс Вебмастера важны запросы, по которым страница показывается (охват), CTR сниппета, динамика за 2–4 недели после публикации. Из Метрики — отказы, глубина прочтения, время на странице.

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

Как это выглядит на практике

Покажу на одном примере. Запрос — «как найти работу IT-специалисту» (хм, или надо было пример про hr выбрать?). Интент информационный — человек хочет понять, с чего начать и что реально работает на рынке. Вот первый абзац статьи в трёх версиях — от очевидно плохой к рабочей.

Нерелевантный вариант (старая школа):

Как найти работу IT-специалисту — это важный и актуальный вопрос в современном мире информационных технологий. Поиск работы IT-специалисту играет ключевую роль в построении карьеры. Если вас интересует, как найти работу IT-специалисту, в этой статье мы расскажем, как найти работу IT-специалисту быстро и эффективно. Найти работу IT-специалисту — это просто!

Формально здесь всё «правильно»: ключ «найти работу IT-специалисту» встречается четыре раза в четырёх предложениях. И именно поэтому абзац проваливается. BM25 видит экстремальный tf на коротком документе — классический сигнал переоптимизации. Текст не отвечает ни на один реальный вопрос — ни где искать, ни как составить резюме, ни чего ждут на собеседовании. Эмбеддинг такого абзаца беден — он крутится вокруг одной фразы и не покрывает связанные подтемы. Человек, открыв это, через три секунды вернётся в выдачу. Профицит зафиксирует неуспех. Но это пример совсем жесткий, такого уже не пишут много лет.

Нерелевантный вариант, который выглядит умеренно нормально:

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

А вот это — куда более частый и опасный случай. Здесь нет накачки ключами, текст грамотный, читается гладко. Редактор (который без вкуса) не придерется. Но он так же нерелевантен, как и первый.

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

Это и есть главная ловушка, техническая грамотность текста и его релевантность — разные вещи.

Релевантный вариант:

Поиск работы в IT обычно упирается не в количество откликов, а в их прицельность. Джуниору без коммерческого опыта имеет смысл собрать пет-проекты на GitHub и откликаться на стажировки, а не на вакансии с требованием «от 3 лет». Мидлу — наоборот, реже, но точнее: переписанное под конкретную вакансию резюме плюс сопроводительное письмо работают лучше, чем сто одинаковых откликов. Искать стоит сразу в нескольких местах — на hh и «Хабр Карьере», в Telegram-каналах с вакансиями и через знакомых: по статистике рекрутеров, рефералы закрывают заметную долю IT-позиций еще до публикации.

Здесь ключевая фраза почти не встречается в исходном виде. Зато абзац плотно покрывает связанные сущности: джуниор, мидл, резюме, сопроводительное, пет-проекты, GitHub, стажировки, hh, Хабр Карьера, рефералы. Это и есть «ширина» в действии — векторная модель видит документ, близкий не к одному запросу, а к целому кусту: «как джуниору найти первую работу в IT», «как составить IT-резюме», «где искать вакансии разработчику». Человек получает конкретику сразу и остаётся читать. Та же тема, тот же интент — но релевантность принципиально другая, потому что страница решает задачу, а не повторяет запрос.

Неожиданный вывод

Пишите хорошие тексты, которые несут пользу и отвечают на вопрос пользователя 🙂

BM25, нейросети, поведенческие сигналы, оценка качества — это всё разные приближения к одному вопросу, который раньше алгоритм задать не умел, а человек умел всегда: «ну и помогло тебе это или нет?»

Оптимизировать под алгоритм и писать для человека — это больше не две разные стратегии, между которыми надо выбирать. Лет десять назад выбирать приходилось, и честно говоря, выигрывал чаще тот, кто оптимизировал под алгоритм. Сейчас эти две задачи достаточно близки друг к другу. Алгоритм стал достаточно хорош (что, впрочем, не мешает его обманывать), чтобы отличить текст, который реально отвечает на вопрос, от текста, который просто содержит правильные слова.