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

Микроразметке пятнадцать лет, и вокруг неё до сих пор два лагеря: одни верят в магическую кнопку «звёзды в выдаче», другие считают её карго-культом. Разбираю, что из 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) и повторили описанные сценарии. Ниже мы приводим команды и ответы обоих движков, чтобы проверку можно было повторить самостоятельно.

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

Разбираю, как устроен MCP-сервер для Яндекс Вебмастера: как уложить пару десятков эндпоинтов в восемь инструментов, какие грабли у API v4 и как сделать вход в Яндекс, который агент выполняет сам — без терминала и без клиентского секрета.

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

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

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

Выберите процедуру по топологии:

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

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

В Manticore Search теперь (с релиза 27.1.5 ) есть встроенная аутентификация и авторизация — для SQL по протоколу MySQL, для HTTP/HTTPS‑эндпоинтов и для операций, связанных с репликацией.

Аутентификация отвечает на вопрос «кто делает запрос?». Авторизация — «что этому пользователю разрешено делать?».

Пользователи, которые уже используют Manticore могут подключить новую функциональность, сохранив привычные способы работы с Manticore. Существующие SQL и HTTP‑клиенты сохраняют свои обычные паттерны подключения. В приложениях требуются минимальные изменения.

Поиск в Next.js App Router связывает несколько механизмов — Server Components, dynamic routes, searchParams, metadata и клиентские фильтры. Если в проекте одна форма и несколько результатов, состояние можно держать в useState. В каталоге или агрегаторе каждый фильтр меняет URL, набор данных и правила индексации.

В статье на примере учебного проекта EventMap — агрегатора событий, разберем, как спроектировать систему фильтрации, которая генерирует чистые, индексируемые URL для поисковых роботов и обновляет выдачу при изменении фильтров. Страницы вроде «Концерты в Москве» или «Выставки в Петербурге» могут работать как отдельные landing pages. Для них нужны серверный HTML, постоянный URL, свой title, description, h1, canonical и отдельная политика index или noindex. Произвольные запросы, сортировки и глубокая пагинация остаются частью поиска и не попадают автоматически в индекс. Поиск построен через App Router, optional catch‑all route, серверный рендер результатов и общий набор функций для URL, metadata, canonical и sitemap.

Поиск по каталогу создаёт отдельное состояние для каждой комбинации фильтров. Категория, город, дата, сортировка, поисковая строка и номер страницы попадают в URL. При десяти категориях, пятидесяти городах и пяти вариантах сортировки получается 2500 комбинаций без учёта пагинации и свободного текста. Интерфейс должен обработать все допустимые комбинации. В поисковый индекс обычно попадает только часть из них. Страница категории music, страница города london и сочетание music/london могут содержать устойчивую подборку. Запрос ?q=free+jazz+tonight, сортировка по цене и восьмая страница выдачи относятся к текущему действию пользователя. Фильтры без отдельной политики создают большое пространство URL. Google описывает эту проблему в документации по faceted navigation. Изменение каждого параметра создаёт новый адрес, краулер тратит запросы на многочисленные комбинации и позже обнаруживает, что многие из них не содержат самостоятельного материала. (Google for Developers)

Всем привет. Меня зовут Владимир Назаров, я основатель агентства поискового маркетинга Head Promo.

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

Из‑за этого заказчик приходит за одним результатом, а агентство несколько месяцев работает над другим. Формально все занимаются GEO, но компания так и не появляется там, где её ожидает увидеть клиент.

Давайте разберёмся, что именно бизнес хочет получить от продвижения в нейросетях и почему сайт компании, часто, вообще остается не у дел.

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

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

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

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

Именно поэтому в Manticore Search теперь встроены аутентификация и авторизация. Функциональность добавлена в версиях 27.x и описана в посте о релизе 27.1.5 : она позволяет Manticore проверять, кто подключается и что этому пользователю разрешено делать.

Новая функциональность работает через SQL, HTTP/HTTPS-клиентов, распределённых и удалённых агентов и поддерживает репликацию.

Вайб-кодинг уронил порог входа до плинтуса: Lovable, Bolt или v0 соберут лендинг за вечер. А потом сайт неделями болтается на дне выдачи, и даже ChatGPT про него не знает. Спрашиваешь у нейронки, почему SEO хромает, — она валит на «непродающие тексты». Причина обычно глубже: для поисковых роботов ваш сайт буквально пустая страница.

Внутри: почему нейронки по умолчанию лепят SPA, как на JavaScript смотрят Google и Яндекс, почему GPTBot и ClaudeBot скачивают ваши скрипты, но никогда их не запускают, работает ли llms. txt и какая одна строчка в промпте все чинит.

Мы выпустили Manticore Search 28.4.4 . В этом релизе ресоринг KNN стал быстрее, диалоговый поиск — гибче, установка и обновление — проще, фасеты получили дополнительные параметры, появились настройки релевантности по умолчанию на уровне таблицы, а также исправления в аутентификации, репликации, совместимости SQL, распределённых запросах и внутренних механизмах columnar/KNN.

В этом посте собраны изменения, вышедшие с 27.2.0 по 28.4.4.

Векторные базы данных в serverless-модели обычно обещают простую вещь: не требуется развёртывание и настройка, а провайдер берёт на себя управление хранилищем, масштабирование и обеспечение доступности. turbopuffer - один из лучших примеров этого класса: быстрый движок векторного поиска, использующий object storage в качестве хранилища, которым пользуются Cursor, Notion, Linear и другие.

Такой подход действительно снижает операционную нагрузку на команду, но он не бесплатен. Поэтому возникает закономерный вопрос: какая часть этих преимуществ нужна небольшому, четко определенному сценарию, и во что обойдется та же нагрузка на двух недорогих VPS с Manticore Search - по цене и по производительности?

В этой статье мы подтверждаем это цифрами: сравниваем две системы в одинаковых условиях на одном и том же наборе данных.