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

Manticore Search 27.1.5 выпущен. Этот релиз приносит встроенные аутентификацию и авторизацию, шардированные таблицы, conversational search, более быструю сборку HNSW, улучшенные фасетирование и агрегации, а также длинный список исправлений в KNN, репликации, совместимости протоколов и других областях.

Этот пост - сводка всего, что вышло с 25.0.1 по 27.1.5.

Привет, Хабр!

Меня зовут Дмитрий, руководитель отдела рекламы и продвижения в Аспро. Мы запускаем интернет-магазины и развиваем систему управления бизнесом Аспро.Cloud.

Раньше покупатель сам проходил путь: вводил запрос, открывал несколько вкладок, читал характеристики, сравнивал цены и условия доставки — и в итоге выбирал. Интернет-магазин конкурировал за место в выдаче и за то, чтобы человек остался именно на его странице.

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

Кратко: Три изменения в HNSW-поиске ускоряют KNN-поиск до 29% при больших k и дают более 20% прироста при параллельной нагрузке. Без изменений API, без перестроения индексов и без новых настроек — просто более быстрый поиск.

Пока SEO-специалисты обсуждают теорию GEO-продвижения (Generative Engine Optimization), часть рынка уже вовсю получает трафик из ChatGPT, Perplexity и Алисы, и даже не всегда это замечает. Мы провели масштабное аналитическое исследование в промышленном кластере: металлообработка, машиностроение, заготовительное производство. Данные собирались около года. В этой статье я собрал конкретные цифры, неочевидные выводы и практические рекомендации: что именно делать, чтобы ваша компания появлялась в ответах нейросетей.

Хочу поделится своим опытом создания RAG-системы, где мультиязычная модель E5, классификатор на LLM для обработки отрицаний и реранкер Jina работают в связке. А также неочевидные нюансы работы с синонимами и структурой знаний.

Моя основная профессия — ПМ в ИТ. Плотно занялся LLM год назад, можно сказать, что я «молодой специалист».

В этой статье разберу JSON-LD для сайтов на Tilda: что именно размечать, как разделять общий код и код конкретной страницы, где проверять микроразметку и какие ошибки чаще всего появляются после правок сайта.

Материал не про то, как скопировать готовый JSON из генератора. Такой вариант годится только для самых простых страниц.

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

Часть этих данных относится ко всему сайту, часть - только к одной странице.

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

Для примеров возьму нейтральную нишу - учебный центр.

На рынке SEO‑продвижения давно гуляет заблуждение, что нужно создавать как можно больше целевых страниц. Точнее когда‑то давно это не было заблуждением, но уже давно им стало. Логика простая — трафикоемкость * количество = трафик.

Продвиженцы часто создают/оставляют низко‑релевантные страницы. Например, оставляют открытыми для индексации товары не в наличии. С точки зрения бизнеса логика тут простая — человек зайдет, перейдет в каталог/на рекомендуемые товары и совершит покупку. Либо подпишется на «уведомите меня, когда товар будет в наличии», что создаст маркетинговое касание

И вправду, если смотреть с точки зрения конверсии готового трафика, то это будет работать.

На странице услуги пользователь видел цену «от 25 000 ₽», а meta description и JSON‑LD продолжали отдавать 50000. Валидатор был зелёным.

И это был собственный сайт веб‑студии!

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

Это первая из трёх статей про сайты под управлением ИИ. В этой части — концепции и экономика без маркетинговой пыли: что такое нейросайт на самом деле, чем он принципиально не является, и почему дешёвый VDS за пару тысяч рублей тут вообще ни при чём с точки зрения железа под нейросеть. Во второй части будет внутрянка (MCP‑брокер, пайплайн деплоя, безопасность), в третьей — прод‑механика на тысячах страниц (SSG/ISR, индексация, массовые операции). Здесь сознательно держусь на уровне архитектурных решений, не уходя в реализацию — она дальше.

Есть привычная ошибка в техническом аудите больших сайтов: открыть краулер, поставить лимит побольше и просканировать всё.

На сайте в пару тысяч страниц это работает. На сайте с семизначным инвентарём URL — нет. Полный краул упирается в память, диск, сетевые таймауты, rate limit, JavaScript-рендеринг, дубли, параметры, бесконечные фасеты и в то, что через двое суток вы получаете таблицу на миллионы строк, которую всё равно придётся сегментировать с нуля.

Поэтому я начинаю не с краулера. Я начинаю с sitemap.

В статье показываю sitemap-first подход: как скачать sitemap graph, превратить URL в датасет, разобрать слаги на смысловые группы, сматчить паттерны со спросом, найти пустые посадочные, проверить рендеринг и потом подтвердить гипотезы через GSC, Яндекс.Вебмастер, Метрику и серверные логи.

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

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

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

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

Когда нейросеть отвечает на вопрос и показывает блок «источников», кажется, что у всех систем это одно и то же — список ссылок, на которые модель опиралась. На деле за этим блоком в каждой системе стоит своя реализация: свой способ обмена с сервером, свой формат ответа, свои поля, из которых интерфейс достаёт цитаты. Мы разобрали сетевой обмен веб-клиентов трёх систем — ChatGPT, Gemini и DeepSeek — и параллельно прогнали через них один и тот же набор запросов по 10 раз, чтобы понять не только техническое устройство цитирования, но и что эти системы реально цитируют.

Сразу оговорка: я основатель RankCaster AI — платформы, которая управляет видимостью брендов в ответах нейросетей. То есть мы изучаем категорию, в которой сами работаем. Чтобы не подыгрывать себе, мы исключили собственный домен из всех таблиц ещё до подсчётов, а ограничения методики описали в полном тексте исследования. Здесь — техническая часть: разбор механики цитирования.

IWANT - наш собственный fashion-магазин. Несколько лет он жил на InSales: на старте это правильный выбор: быстро, без разработки, всё из коробки. Но в какой-то момент мы уперлись в потолок платформы: каждый нужный модуль - это либо платное приложение, либо «так нельзя». Мы посчитали и решили перевезти магазин на собственный движок.

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

Сейчас во многих компаниях разворачивается прекрасная сцена. Открыли новый канал — нейросети — и сели считать упоминания. Было сто запросов, нас назвали семь раз. Стало двести — назвали восемнадцать. Положительная динамика! Совет директоров доволен, маркетолог получает премию, все хлопают в ладоши.

А потом выходит исследование агентства Burson под названием «Парадокс достоверности» и спокойно объясняет вещь, которую вообще‑то можно было предположить заранее: упомянуть — это не то же самое, что вызвать доверие.

Если вы работаете с сайтами, рекламой или веб‑аналитикой, то наверняка знаете, сколько времени уходит на сбор данных, проверку отчётов и поиск нужных показателей в интерфейсе Метрики. MCP Яндекс. Метрики помогает упростить эту работу. С его помощью можно запрашивать данные обычным текстом и быстро получать аналитику в понятном виде.

В этой статье разберём, что это за инструмент, как его подключить и как использовать в работе.

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

1.  Что такое управленческая деятельность и что к ней относится.

Посмотрим какие определения даются «управленческой деятельности», в некоторых словарях (см. https://big_economic_dictionary.academic.ru/3548/:

Последние месяцы я наблюдаю одну и ту же картину. Бизнес массово бросился оптимизировать сайты под нейросети, число запросов по теме GEO-оптимизации в Wordstat за январь 2026 года выросло в тысячу раз год к году. Внутренняя аналитика Morizo фиксирует рост спроса на текстовую модернизацию сайтов на 27% за квартал. Пока весь рынок переписывает контент под ИИ-ассистентов, я предлагаю остановиться и задать неудобный вопрос: а вашему бизнесу это вообще нужно?

Я соло-фаундер и единственный разработчик нишевого B2B-продукта. Лендинги для него я переделывал не раз: новая гипотеза — новая посадочная, под кампанию — ещё одна, плюс блог. Каждый раз повторялась одна и та же возня: не забыть мета-теги и Open Graph, прикрутить аналитику, не сломать индексацию, выкатить, проверить. Claude Code заметно ускорял это, но каждый запуск был «с нуля» — качество зависело от того, насколько удачно я в этот раз сформулировал промпт.

В какой-то момент я понял, что повторяю один и тот же процесс, и его можно зафиксировать. Так получилась Landforge — небольшая система Claude Code skills, которая доводит лендинг от брифа до задеплоенной измеримой страницы. Я обезличил её, отвязал от своего продукта и выложил в open-source (MIT). В статье — как она устроена и какие решения за этим стоят. Ссылка на репозиторий в конце; сначала — польза.

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

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

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

Проблема в том, что поисковая система и пользователь смотрят на страницу не как на строку в плане работ. Им важно другое: есть ли на этой странице самостоятельная ценность. Объясняет ли она условия работы в конкретной зоне. Помогает ли принять решение. Снимает ли вопросы по срокам, доставке, выезду, цене, адресу, маршруту, ограничениям.