Поисковые технологии *

Bing Webmaster Tools постепенно прокачивает отчет AI Performance. На SEO Week в Нью-Йорке Кришна Мадхаван показал новые функции, часть которых Microsoft уже начала выкатывать. 

Bing — слишком крупный игрок, чтобы отмахиваться от его продуктовой логики. По официальным данным Microsoft, Bing имеет около 155 млн среднемесячных пользователей в ЕС. Глобальные оценки с учетом интеграций в Windows и AI-инструменты показывают аудиторию на уровне 0,9-1 млрд. пользователей в месяц. По данным Яндекса, озвученным на конференции «День Поиска 2026», на сервис приходится 70% поисковых запросов в России, поиском ежемесячно пользуются более 110 млн уникальных пользователей, а быстрые ответы Алисы AI в Поиске получают 46,5 млн пользователей в месяц. 

Вывод очевиден: Bing достаточно велик, чтобы его подход к GEO и AI-выдаче внимательно разбирать, а Яндексу стоило бы быстрее приходить к такой же прозрачной аналитике для вебмастеров. 

На самих слайдах интересно не то, что Bing сказал слово GEO (и они признали вслед за Google). Интересно, в какой форме он это показывает. Там уже виден каркас будущей аналитики: рекомендации, темы, намерения, доля цитирования. Ровно вокруг этих сущностей и будет строиться нормальная работа с присутствием в AI-ответах.

AI‑поиск всё сильнее меняет правила игры. Раньше мы боролись за позиции в Google, теперь всё чаще боремся за то, чтобы бренд попал в ответ ChatGPT, Perplexity, Gemini или Google AI Overviews.

И здесь у SEO‑специалиста возникает неприятный, но важный вопрос:
AI‑системы действительно выбирают лучшие источники — или просто те, которые чаще, понятнее и удобнее подсовывают им информацию?

Два эксперимента SE Ranking дают на это очень интересный ответ.

В первом исследовании команда проверяла, как AI‑generated контент работает в обычном Google‑поиске. Во втором — создала полностью фейковый бренд и посмотрела, сможет ли он получить видимость в AI‑ответах.

Спойлер: да, сможет. Но не всё так просто.

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

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

SEO давно привыкло работать через семантику, интенты, структуру H1-H2, FAQ и анализ конкурентов. Это всё ещё нужно. Но для сложных запросов этого всё чаще недостаточно.

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

Google прямо описывает AI Mode как режим для сложных и многочастных вопросов, а в материалах о AI Mode говорится о query fan‑out — подходе, при котором система запускает несколько связанных поисков по подтемам, чтобы собрать более полный ответ. Google также указывает, что специальных требований для попадания в AI Overviews и AI Mode нет: базовые SEO‑практики остаются актуальными, но формат потребления контента меняется.

У Яндекса похожий сдвиг виден через качество контента и новые поисковые интерфейсы. В марте 2025 Яндекс сообщил, что обновил алгоритмы определения качественного контента и снизил количество низкокачественных источников на первой странице выдачи, включая материалы, созданные с помощью ИИ. В мае 2025 в Поиске появился режим рассуждений и развёрнутые ответы с изображениями, видео и ссылками на источники на базе технологий Алисы.

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

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

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

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

Именно эту задачу решает GEO — Generative Engine Optimization, то есть оптимизация контента и присутствия бренда под генеративные поисковые системы и нейросети.

Эта статья подготовлена по мотивам доклада Владимира Назарова — руководителя агентства поискового маркетинга Head Promo и эксперта в GEO-продвижении. Доклад прошёл в рамках конференции GEO 2026 и был посвящён тому, как бизнесу попасть в ответы ИИ, какие источники используют нейросети и почему продвижение сайта в ИИ уже становится важной частью поискового маркетинга. В презентации доклада отдельно разобраны формула GEO, исследования по источникам, различия между AI-системами и практический кейс продвижения вымышленного автодилера в ответах нейросетей.

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

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

Поехали.

Рынок потихоньку обретает опору вновь. 

Semrush выкатывает одни из первых внятных исследований про механику AI-ответов: какая логика отбора, какие используются источники и критерии контента.

Сегодня много статистики с моими комментариями)

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

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

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

К тому моменту, когда пользователи это замечают, настоящая проблема нередко копится уже несколько часов. Без хорошей видимости остаётся только гадать: система перегружена? Одна таблица съедает ресурсы? Или незаметно что-то идёт не так?

Вот почему мониторинг важен. С ним расплывчатое «поиск стал медленным» превращается в проблему, которую можно диагностировать и исправить.

К тридцатилетию публикации проекта 1994 года, который остаётся самым скорострельным морфологическим анализатором.

Давным-давно, когда Рунет только появлялся, морфологические анализаторы и системы контроля орфографии уже производили вау-эффект: они не только сводили разные словоформы к основной (словарной), но и зачастую умели их склонять/спрягать, описывали грамматику вхождений и предлагали варианты замены ошибочных начертаний. Да и чуть позже, при появлении первого русского морфологического поиска в Интернет – это был Апорт! – на выставках тоже равнодушных не было. Тогда и родился libmorph.

Самый неприятный тип инцидента — когда база данных не падает полностью, а просто начинает работать медленнее.

Пользователи замечают это сразу. Жалобы начинают поступать. Технически всё по-прежнему работает, но явно что‑то не так.

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

Начиная с Manticore Search 24.4.0, компактизация RT-таблиц использует более эффективную модель выполнения. Вместо последовательного слияния пар чанков оптимизация теперь поддерживает два важных улучшения:

Из этого материала вы узнаете о том, как работают векторные базы данных, разобравшись с широким диапазоном тем — от основ поиска по сходству, до стратегий индексирования, которые позволяют применять на практике крупномасштабный поиск данных.

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

Хочу рассказать о наблюдаемом мной парадоксе этой технологии с точки зрения IT и обычной жизни.

Этот термин состоит из конкатенации двух слов: hash и tag. Hash - это прежде всего понятие про уникальность с шифрованием.

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

Такие функции не всегда могут однозначно давать уникальные ответы в виде строк, поэтому существуют так называемые коллизии.

Короче, здесь главный приоритет - уникальность, "не как у других".

Тег, или тэг - это обозначение какой-то метки.

В HTML используются теги верстки, в разработке через систему контроля версий тегами помечали стабильную версию кода. tag-1.2.3

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

Вместо объёмной теории, которой в интернете и так достаточно, держите чеклисты! Ниже представлены чеклисты по оптимизации сайта под SEO и GEO (AI-режим поиска) в виде таблиц: поэтапно, без воды, с приоритетами и инструментами проверки. Скопировать таблицы в Excel / Markdown можно на сайте.

С тех пор как мы представили инструмент резервного копирования в Manticore Search 6, создавать резервные копии данных стало заметно проще. Но мы постоянно слышали один и тот же вопрос: "А как насчёт облачного хранилища?" Сегодня мы рады объявить, что manticore-backup теперь поддерживает S3-совместимое хранилище с потоковой загрузкой — без промежуточных файлов, без проблем с местом на локальном диске, только бэкапы напрямую в облако.

Представьте, что вы создаёте мощное поисковое приложение. Пользователи вводят ключевые слова, а ваш бэкенд должен выполнять запрос к базе данных Manticore Search, чтобы найти подходящие результаты. Распространённый (и соблазнительный!) подход — напрямую вставлять ввод пользователя в SQL‑запросы. Например, вы можете фильтровать по числовому полю, такому как категория или идентификатор записи. Если пользователь передаёт обычное значение, например 5, запрос будет SELECT FROM products WHERE id=5. А что, если он передаст 1 OR 1=1? Запрос станет SELECT FROM products WHERE id=1 OR 1=1 — условие всегда истинно, поэтому запрос вернёт все строки вместо одной. Это SQL‑инъекция.

К счастью, существует более безопасный и эффективный способ: prepared statements. По сути, prepared statements отделяют ваш SQL‑код от передаваемых данных. Вместо того чтобы каждый раз собирать всю строку запроса, вы один раз задаёте структуру запроса с маркерами параметров, а затем отдельно передаёте поисковые термины. Подробнее о концепции можно узнать на Wikipedia .

Manticore Search поддерживает prepared statements через стандартный протокол MySQL, предоставляя мощный инструмент для создания безопасных поисковых приложений. Используя prepared statements, вы не только значительно снизите риск SQL‑инъекций, но и улучшите читаемость вашего кода.

prepared statements — это не просто функция; иногда они являются обязательными. Например, библиотека Rust sqlx работает с MySQL-эндпоинтом, используя исключительно prepared statements. Кроме того, некоторые OLE DB‑коннекторы, позволяющие MS SQL работать с сервером MySQL, тоже используют prepared statements внутри.

Вы слышали, что Manticore Search быстрый. Вы слышали, что он объединяет полнотекстовый, векторный и нечеткий поиск в одном движке. Но когда вы начинаете реально работать с ним, вы сидите перед документацией, угадываете синтаксис SQL и надеетесь, что CREATE TABLE не выдаст непонятную ошибку.

MCP-Manticore меняет правила игры.

Это сервер Model Context Protocol (MCP), который подключает Cursor, Claude Code, Codex CLI или любой другой MCP-совместимый AI-ассистент напрямую к вашему экземпляру Manticore. AI может:

В наше время уже никого не удивишь разработкой агентов, очередной оптимизацией, новой моделью или новой инфраструктурой для нейронок. Всё это в порядке вещей. Однако одно дело читать в Twitter «мы написали агента X и он оптимизировал нам процессы на 300000%», и совсем другое — начать копать чуть глубже. Копнёшь — а «агентом» называют скилл с одним промптом.

Разработка настоящих агентов — задача не тривиальная. Достаточно посмотреть на утёкшие исходники Claude CLI — это не просто CLI, а целая инфраструктура бизнес-логики вокруг LLM. Я бы сравнил разработку агентов с разработкой типичных бэкенд-компонентов. Аналогия такая: если вы пишете каноничный бэкенд-сервис — вам нужна СУБД. Если Web3-сервис — блокчейн. Но на СУБД или блокчейне происходит в лучшем случае 50% всей логики. Вся магия крутится именно на бэкенде. С агентами то же самое: подключаешь AI SDK, конфигурируешь мыслительное ядро и пишешь вокруг него всю обвязку — мониторинги, AIOps, оркестрацию, memory management.

Вот про memory management и пойдёт речь.

Поиск редко сводится к одному универсальному сценарию. Пользователь, вводящий "cheap running shoes", хочет точных совпадений по ключевым словам, а пользователь, задающий "comfortable footwear for jogging", выражает то же намерение другими словами. Традиционный полнотекстовый поиск хорошо справляется с первым случаем. Векторный поиск решает второй. Гибридный поиск объединяет оба в одном запросе, так что вам не приходится выбирать.

В современных поисковых системах это часто описывается как комбинирование лексического (разреженного) поиска с семантическим (плотным) поиском. Разные термины, одна идея: точное совпадение плюс смысл.