LSI-ключевые слова: почему их не существует, что на самом деле оценивают Яндекс и Google и как собрать тематическую полноту текста вместо мифических LSI-ключей

LSI-ключевые слова продаются как обязательный элемент SEO-текста: собери синонимы и связанные фразы, вставь в текст, получи рост позиций. Совет повторяется в десятках статей, под него сделаны сервисы, по нему принимают работу у копирайтеров. Проблема в том, что технологии, о которой идёт речь, в поисковых системах нет — и не было никогда.

Ниже разбор: откуда взялся термин, что на самом деле происходит с текстом внутри Яндекса и Google, почему совет при этом продолжает давать результат и какую работу нужно делать вместо сбора «LSI». Материал актуален на август 2026 года.

Что такое LSI-ключевые слова и откуда взялся термин

Latent Semantic Indexing — латентно-семантическое индексирование — реальная технология из области обработки текста. Её описали в конце 1980-х: метод строит матрицу «термин — документ», а затем сжимает её через сингулярное разложение, чтобы выявить скрытые связи между словами. Слова, которые часто встречаются в похожих контекстах, оказываются рядом в полученном пространстве. Технология работала на коллекциях в тысячи документов и была большим шагом для своего времени.

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

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

Чего не говорят в топе: LSI поисковыми системами не используется

Начнём с прямой атрибуции, потому что в таком вопросе она важнее любых рассуждений. Джон Мюллер, сотрудник Google, публично заявил в 2019 году: «There's no such thing as LSI keywords» — «Такой вещи, как LSI-ключевые слова, не существует; тот, кто говорит вам обратное, ошибается». Позже он повторял это неоднократно. Google не подтверждал использование латентно-семантического индексирования ни разу.

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

Что используется на самом деле — известно и описано публично. Google назвал RankBrain в 2015 году и BERT в 2019-м; обе системы работают с векторными представлениями слов и предложений, обученными на нейросетевых моделях. Яндекс шёл тем же путём: «Палех» в 2016 году, «Королёв» в 2017-м, YATI в ноябре 2020-го. YATI построен на архитектуре трансформера — той же, что лежит в основе современных языковых моделей. Ни в одном из этих анонсов латентно-семантическое индексирование не упоминается.

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

Почему совет всё равно работает

Здесь начинается интересное. Если поисковики не считают синонимы, почему тексты, написанные по методичке LSI, действительно ранжируются лучше плохих текстов? Потому что под неверным названием решается настоящая задача.

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

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

Типы LSI-ключей, которые вы встретите в статьях

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

Синонимические (sLSI)

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

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

Релевантные (rLSI)

Слова, которые не являются синонимами, но относятся к теме: для того же «продвижения сайта» — «семантическое ядро», «поведенческие факторы», «внутренняя перелинковка», «Вебмастер». Именно эта категория делает основную работу, и именно её обычно собирают хуже всего.

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

Чем вредит вера в термин

Разговор был бы академическим, если бы миф не приводил к конкретным потерям. Приводит, и потери повторяются от проекта к проекту.

Первое — подмена работы инструментом. «Собрать LSI» звучит как задача с чётким результатом: запустил сервис, получил список, вставил. Настоящая задача — понять, из каких вопросов состоит тема, — звучит расплывчато и требует времени. Команда выбирает первое, отчитывается списком и считает работу сделанной.

Второе — вписывание ради количества. Если приняли метрику «не менее двадцати LSI-слов на текст», их вставят, даже когда пятнадцать из них там не нужны. Появляются предложения, написанные ради размещения фразы, а не ради смысла — и текст, который читателю тяжело читать.

Третье — ложное чувство контроля. Список из сервиса создаёт впечатление, что семантика проработана, и снимает вопрос «а всё ли мы раскрыли». Проверка полноты не проводится, потому что кажется уже выполненной.

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

Что делать вместо: карта сущностей темы

Работа, которую стоит выполнять вместо сбора «LSI», называется проще: собрать карту сущностей и подвопросов темы. Она даёт тот же список слов, но по осмысленному принципу, и заодно задаёт структуру материала. Порядок такой.

1. Сформулировать основной вопрос текста одним предложением. Не тему, а вопрос, с которым человек приходит. «LSI-ключевые слова» — тема; «нужно ли собирать LSI-ключи и как» — вопрос. Всё дальнейшее проверяется этим предложением.
2. Снять структуру у десяти сайтов из топа. Выписать все заголовки H2 и H3. То, что есть у большинства, — обязательный минимум; то, что есть у одного-двух, — потенциальная точка отличия.
3. Собрать подвопросы из выдачи. Блок «Вместе с этим ищут», поисковые подсказки при вводе запроса, вопросы из блоков быстрых ответов. Это готовый список того, что аудитория спрашивает рядом.
4. Выписать сущности предметной области. Названия технологий, алгоритмов, инструментов, метрик, ролей, документов — всё, без чего специалист тему не раскрывает. Именно этот список заменяет «релевантные LSI» и собирается головой, а не сервисом.
5. Добавить соседние этапы задачи пользователя. Что человек делал до того, как пришёл с этим вопросом, и что будет делать после. Часто именно здесь находится то, чего нет ни у кого в топе.
6. Отсеять лишнее по основному вопросу. Каждый пункт проверить: приближает ли он к ответу. Не приближает — вычеркнуть целиком, а не сократить.

На выходе получается не список слов для вставки, а план материала, где каждый пункт — это раздел или абзац. Слова появятся сами: невозможно раскрыть тему алгоритмов Яндекса и не упомянуть YATI, «Королёв» и трансформеры.

Проверка результата тоже меняется. Вместо «сколько LSI-слов вошло» вы спрашиваете: на какие вопросы из собранного списка текст отвечает, а на какие нет. Ответ на второй вопрос — конкретный список правок, а не ощущение.

Куда вставлять и сколько

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

Практическое правило другое: тематическая сущность должна появиться там, где она по смыслу нужна, и столько раз, сколько нужно для объяснения. Если тема требует раздела про Вордстат — будет раздел, и слово встретится в нём десять раз естественным образом. Если не требует — не нужно ни одного упоминания ради галочки.

Что действительно имеет значение — распределение по структуре. Заголовки H2 и H3 весят больше обычного текста, потому что задают тему блока и попадают в оглавление и сниппеты. Формулируйте их как ответы на подвопросы из карты, а не как абстрактные названия. То же касается первого абзаца раздела: он должен начинаться с утверждения, а не с разгона.

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

Ещё одна причина заниматься полнотой, а не синонимами, появилась недавно. Быстрый ответ Алисы AI в Яндексе и обзоры от ИИ в Google собираются не из страницы целиком, а из фрагментов, каждый из которых отвечает на отдельный подвопрос. Система берёт несколько источников и склеивает ответ из кусков.

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

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

Чек-лист перед сдачей текста

1. Основной вопрос материала сформулирован одним предложением и записан.
2. Снята структура минимум десяти сайтов из топа по запросу.
3. Собраны подвопросы из подсказок и блока «Вместе с этим ищут».
4. Составлен список сущностей предметной области — руками, не сервисом.
5. По заголовкам подряд виден ответ на основной вопрос.
6. Каждый раздел начинается с утверждения, а не с введения в тему.
7. Ни одна фраза не вставлена только ради вхождения.
8. Есть блок о том, что в теме не работает или переоценено.
9. Синонимы использованы для читаемости, а не для набора количества.
10. Указана дата актуальности материала.

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

Частые вопросы

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

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

Google действительно не использует LSI?Представитель Google Джон Мюллер публично заявлял об этом в 2019 году и повторял позже. Подтверждения обратного не публиковалось. Google описывал RankBrain и BERT — системы на векторных представлениях, а не на латентно-семантическом индексировании.

А Яндекс?Яндекс никогда не заявлял об использовании LSI. Публично описаны «Палех», «Королёв» и YATI — нейросетевые модели анализа текста, последняя на архитектуре трансформера, запущена в ноябре 2020 года.

Как быстро проверить, полон ли текст?Прочитать подряд только заголовки. Если по ним не виден ответ на основной вопрос — проблема в структуре, и правка абзацев её не решит. Затем сверить заголовки со списком подвопросов из выдачи и посмотреть, чего не хватает.

Что делать дальше

Термин «LSI-ключевые слова» останется в отрасли — он удобен, привычен и его понимают все стороны переговоров. Пользоваться им можно; вредно только верить в то, что за ним стоит алгоритм поисковой системы. Верите — оптимизируете под несуществующий механизм и тратите время на синонимы. Понимаете, что речь о полноте раскрытия темы, — делаете работу, которая даёт результат и в органике, и в генеративных ответах.

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

Интересует проработка семантики и структуры текстов? Пишите в тг, обсудим ваш проект: @th3inventor