Поисковая оптимизация *

Это разбор одного канала для B2B-сервиса со сложным продуктом: как за 18 месяцев переходы из нейросетей выросли практически с нуля до 845 и почему три четверти этого трафика дала Алиса, а ChatGPT остался далеко позади. Если вы отвечаете за привлечение в онлайн-сервисе и прикидываете, стоит ли вкладываться в оптимизацию под нейросети, дальше механика без маркетинговой воды: схема замера из трех сигналов, что чинили на сайте, какую микроразметку раскладывали и как выглядит выгрузка по шести нейросетям. Клиент под NDA, поэтому обезличиваю по роду деятельности, но цифры реальные, из Яндекс Метрики, выборка 100 процентов.

У сайта рос органический трафик, позиции были в порядке, а заявок всё равно не хватало. Клиент задал простой вопрос: «Если людей стало больше, где заявки?»

Я полез не только в Метрику, но и в access.log — и там уже начался отдельный зоопарк: Googlebot, YandexBot, GPTBot, Ahrefs, Semrush, MJ12bot, DataForSEO и Chrome, который вёл себя совсем не как человек.

В статье покажу, как отличать визиты от серверных запросов, проверять настоящего Googlebot, разбирать crawler'ов и решать, кого вообще стоит пускать на коммерческий сайт через robots.txt.

99% посетителей сайта — НЕ ЛЮДИ.

И это не «подозрительный трафик», а буквально: из 1,28 миллиона отданных страниц живые люди посмотрели меньше шести тысяч. Чувак, который это заметил (разработчик благотворительной базы PatronView) — вывел формулу: на каждую страницу, увиденную человеком, приходится ещё ≋214 загрузок, которые никто никогда не увидит. Ну то есть вообще никто. Новая норма, просто не все ещё заметили что декорации сменились.

Дальше будет куча цифр, немного паранойи и шрифт, который врёт роботам в лицо.

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

Итак, в 2026 году уже всем как будто понятно, что потенциальные клиенты всё чаще выбирают банк не в поиске, а в диалоге с нейросетью (хотя многие с этим до сих пор почему‑то спорят). На выходе клиент получает короткий список из трёх‑четырёх названий.

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

Ниже я описываю, как за пару вечеров собрал на Python замер видимости банков Казахстана в пяти ИИ‑ассистентах, на что напоролся и к каким выводам в итоге пришел. Код и формулы прилагаю, цифры можно перепроверить, если у вас будет желание.

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

Речь о GEO — продвижении в ответах нейросетей.

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

Двадцать лет можно было расти на манипуляциях — накрутка поведенческих, накрутка ссылочного, накрутка ключей, накрутка чёрта лысого… Эта эпоха «накруток» заканчивается прямо на наших глазах. Дальше (да и сейчас) в выдаче выигрывает не тот, кто обманул алгоритм, а тот, кто создал ценность для живого человека.

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

Эта статья не о том, что SEO перестало работать. Она о том, почему архитектура поиска изменилась настолько, что привычной модели «индексация → ранжирование → клик» уже недостаточно для описания происходящего.

На протяжении более двадцати лет веб-поиск был относительно простой системой.
На высоком уровне ее можно представить следующим образом:

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

Привет! Я Константин Николаев, занимаюсь внедрением нейротехнологий в Поиске по картинкам. В этой статье я расскажу, как наша команда научила модели смотреть на картинку и читать текст документа одновременно: начали с тяжёлой мультимодальной VLM ради максимального качества, а затем дистиллировали её в набор лёгких моделей — по одной под каждую стадию пайплайна. Что из этого удалось довести до realtime‑поиска с десятками тысяч запросов в секунду и как совместный анализ двух модальностей добавил 5% релевантных картинок в топ выдачи — под катом.

После запуска хобби-проекта я заметил, что один робот за сутки открыл календарь 88 632 раза и добрался до 7273 года. Причиной оказалась обычная ссылка “следующий месяц”, которая создавала бесконечную цепочку корректных URL.

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

В обзорной статье мы разобрали, зачем использовать в поиске тот же UUID, что и в основной базе (если таковая имеется). Здесь сразу перейдём к практике: создадим таблицу, выполним основные операции через SQL и JSON API, а затем загрузим несколько документов через /bulk.

Все примеры рассчитаны на Manticore Search 28.5.0 или новее. Значение <generated UUID> в ответах обозначает UUID, который Manticore создаст при обработке запроса. Копировать эту строку в следующий запрос не нужно: подставьте фактический id из своего ответа.

Микроразметке пятнадцать лет, и вокруг неё до сих пор два лагеря: одни верят в магическую кнопку «звёзды в выдаче», другие считают её карго-культом. Разбираю, что из Schema.org реально работает в Яндексе и Google в 2026 году, что тихо умерло за последние три года (FAQ, HowTo, sitelinks searchbox), зачем структурированные данные снова стали важны из-за LLM — и как за самодеятельность с рейтингами прилетает ручная санкция. С кодом, валидаторами и данными из практики агентства: у 95% сайтов, приходящих на продвижение, разметки нет вообще.

Допустим, у вашего товара в основной базе уже есть ID 550e8400-e29b-41d4-a716-446655440000. Он попадает в события, логи и ответы API. Но при загрузке того же товара в Manticore приложению приходится выдавать ему ещё один, числовой ID.

До Manticore Search 28.5.0 ID документа был беззнаковым 64-битным числом. UUID можно было сохранить в отдельном строковом атрибуте, однако идентификатором документа он от этого не становился. Для UPDATE, REPLACE и DELETE всё равно требовался числовой id.

В результате приходилось хранить соответствие между UUID из основной БД и числовым ID в таблице Manticore. Теперь без него можно обойтись: RT-таблица Manticore умеет использовать UUID как ID документа.

Я начинал с учебной социальной сети на Vue/Nuxt и NestJS, а в итоге собрал платформу, где одна публикация превращается в отдельные редактируемые версии на разных языках. Рассказываю о выборе LLM, культурных адаптациях, расчёте стоимости переводов, изменениях интерфейса после запуска и первых результатах индексации в Google.

Почти каждый основатель SaaS или мобильного приложения в какой-то момент приходит к одной и той же мысли: «Может, проблема не в продукте, а просто о нас пока никто не знает?»

Именно с этой идеей разработчик фитнес-приложения GainFrame решил всерьез протестировать платное продвижение. За три месяца он потратил $5674 на рекламу в Apple Search Ads, TikTok и Reddit. Первые результаты выглядели отлично: установки росли, пробных подписок становилось все больше, графики уверенно шли вверх.

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

Я несколько месяцев измеряю, как ChatGPT, Perplexity, Алиса AQI и GigaChat называют бренды в своих ответах: прогоняю контрольные промпты и смотрю, кого модель упомянула, а кого — нет. За этими прогонами всплыла цифра, которая ломает привычную логику SEO, — и заставила меня поменять то, что я вообще отслеживаю у клиентов. Разбираю по порядку.

Фасеты в интернет-магазине кажутся простыми до первого выбранного фильтра.

В каталоге это часть навигации. Выбранный цвет не должен исчезать из списка. Соседние цвета лучше оставить доступными: пользователь может переключиться на них или расширить выбор. А варианты без товаров полезнее сразу показать как недоступные. Внутри одного фасета обычно работает OR: красный или синий. Между разными фасетами - AND: бренд, цвет и размер одновременно.

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

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

В Manticore Search 25.12.0 появился facet_filter_mode, который переносит это поведение в API фасетов. Теперь в запросе можно описать, как ведёт себя панель фильтров магазина, а приложению не нужно вручную собирать почти одинаковые запросы для каждого фасета.

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

Мы решили посчитать, во сколько компании на 200 человек может обходиться ручной поиск документов. Взяли простую модель: 15 минут поиска в день на сотрудника, 247 рабочих дней в 2026 году и среднюю стоимость рабочего часа 700 ₽. Получилось 8 645 000 ₽ в год.

Месяц назад я внедрил разметку ProductGroup на карточки товара с размерами. Google и Яндекс увидели разное. Вплоть до того, что валидатор Яндекса вообще не знает такой тип. Это переработанная версия текста, который я публиковал раньше. Тогда он был снят модерацией, сейчас переписан и дополнен цифрами за месяц после внедрения.

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

Несколько дней назад Meilisearch опубликовал сравнение с Manticore Search . Мы тоже любим сравнения: в 2023 году опубликовали своё с воспроизводимыми бенчмарками. Сразу оговоримся: мы спорим не со всей статьёй. Часть выводов Meilisearch справедлива, а кое-где сравнение говорит в пользу Manticore Search.

Однако часть сведений о Manticore Search уже устарела. Спорить в теории мы не стали: запустили актуальные версии обоих движков (Manticore Search 28.4.4 и Meilisearch 1.41/1.48) и повторили описанные сценарии. Ниже мы приводим команды и ответы обоих движков, чтобы проверку можно было повторить самостоятельно.