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

Рад всех приветствовать, тема на мой взгляд очень интересная! Приступим?

Постановка задачи

Есть короткая аудио запись продолжительностью от 3 до 6 секунд. Требуется найти: откуда она?

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

Я собрал в Я.Метрике сегмент по реферальным доменам ИИ-сервисов для своего небольшого сайта и прогнал его за четыре окна. Число получилось маленькое — 10 визитов из 634 за 90 дней. Но интереснее не само число, а то, что с ним по-честному можно делать, а что нельзя. Разобрался, почему любой такой замер по определению даёт оценку снизу: реальная величина всегда больше, а насколько — метод сказать не может.

Для кого

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

Кратко

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

Меня зовут Дмитрий Шестаков, основатель компании Сайткрафт. Чаще всего ко мне приходят с запросом в стиле: нам нужно SEO, конкуренты в топе, мы отстаём. И почти всегда мой первый честный ответ — давайте сначала посчитаем, окупится ли это у вас в ближайший год. Потому что для подписочного сервиса поиск умеет приносить дешёвые заявки годами, а умеет полгода жечь бюджет на трафик, с которого никто не покупает. Дело тут не в подрядчике и не в усердии. Решает то, готов ли продукт к этому каналу.

Содержание

1. Почему SEO советуют всем подряд

2. Признак первый: вы не знаете, по каким запросам у вас покупают

3. Признак второй: экономика не сходится даже на платном трафике

4. Признак третий: сайт не превращает визиты в заявки

5. Признак четвёртый: нет запаса хода на длинную окупаемость

6. Признак пятый: SEO некому вести в долгую

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

Нейросеть не рекламирует ваш продукт — она пересказывает ценность вашей компании своими словами. Она не повторяет ваши рекламные лозунги, сколько бы раз вы их где-нибудь ни написали. То есть если вы сто раз напишете, что ваш сервис самый сервисный, качество самое качественное, а ассортимент самый многообразный — модель, скорее всего, вас даже не упомянет. Не потому, что вы плохие. А потому, что ей про вас нечего пересказать. Это сказано везде — значит, не сказано нигде.

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

Кратко

SEO для SaaS — это не одна механика, а три разные: контентный подход (растём на статьях и длинном хвосте), продуктовый (выводим в топ и докручиваем сами страницы сервиса) и массовый (программно генерируем тысячи похожих страниц под низкочастотку). Они дают разный результат, разную скорость и разные риски. Большинство сервисов сжигают бюджет не потому, что делают SEO плохо, а потому что взяли подход не под свою структуру спроса. Ниже — как они устроены под капотом, на реальных дашбордах Метрики и Топвизора, и как выбрать свой.

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

Содержание

1. Почему один и тот же SEO у двух SaaS даёт разный результат

2. Подход 1 — контентный: рост на статьях и длинном хвосте

3. Подход 2 — продуктовый: заявки дают сами страницы сервиса

4. Подход 3 — массовый: тысячи похожих страниц под низкочастотку

5. Три подхода в одной таблице

6. Как понять, какой подход ваш

7. Сколько ждать результата и чем мерить

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

Сайт на Тильде может получать поисковый трафик.

В 2026 году это уже странно доказывать: в выдаче достаточно проектов на конструкторах, у которых индексируются страницы, растут запросы, приходят заявки.

Поэтому вопрос лучше ставить практичнее: в каких случаях Тильда выдерживает SEO-задачу, а в каких начинает мешать работе.

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

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

Последние пять лет продавцы массово шли на маркетплейсы — казалось, это единственно верная стратегия. К 2026 году картина уже изменилась. По данным Sellmonitor, еще за 2024–2025 годы число продавцов на Wildberries и Ozon сократилось на 24,5%.

Значит ли это, что маркетплейсы умирают? Нет. Значит ли это, что работать только на маркетплейсе в 2026 году — рискованно? Уже да!

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

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

Сразу про масштаб. Это одна ниша и всего 60 обращений, так что на вселенскую истину я не претендую, хотя очень хотелось бы. Но даже на таком объёме картинка получилась на удивление устойчивой, пусть и не такой, как мнение Греты Тунберг обо всём на свете.

Я изучаю AEO/GEO (продвижение брендов в ответах нейросетей) и наткнулся на разбор про странную вещь: нейросети называют одни бренды и будто не замечают другие, причём качество продукта тут ни при чём (SearchAtlas). Объясняют это через понятие сущности: и поиск, и нейросети воспринимают бренд как отдельный объект знания со своими свойствами и связями.

Тема показалась любопытной, и я полез в первоисточники: доки Google, schema.org, Wikidata, замеры Ahrefs и Frase, пару работ с arXiv. Там и уткнулся в неожиданное. Знание о бренде у машины устроено двумя совершенно разными способами, и их постоянно путают. Один способ работает у обычного поиска Google, это Knowledge Graph. Другой у языковых моделей вроде ChatGPT, это память в весах нейросети.

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

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

Автоматический шардинг, встроенный в Manticore Search и доступный начиная с релиза 27.1.5 , решает обе проблемы, разбивая таблицу на несколько физических фрагментов меньшего размера (шардов), по которым можно выполнять поиск параллельно и которые можно размещать на разных узлах:

Раньше построение KNN-индекса было самым медленным этапом при сохранении и слиянии чанков в таблицах с векторными атрибутами. Начиная с v27.1.5 , Manticore может задействовать несколько ядер CPU при сохранении чанков, слияниях через OPTIMIZE, авто-оптимизации и ALTER TABLE ... REBUILD KNN. На 16-ядерном Ryzen 9 5950X построение KNN-индекса для 1 миллиона 1536-мерных векторов сократилось с 8 минут до 39 секунд.

В общем, базовая история с аудитом страниц — мы каждый месяц отправляли подрядчику несколько страниц на проверку. Отбирали несколько максимально разных. Если находились проблемы на одной, мы также правили и на однотипных. В месяц так проверяли 4–6 страниц. И тут, из очевидных минусов — оплата подрядчика и ожидание.

Учитывая, что по сути нужно проверять однотипные вещи, вроде title, description, H1 и, например, ошибки в консоли, то я подумал, почему бы не попробовать отдать это агенту. Да, в деталях все не так просто, но общая процедура каждый раз плюс‑минус одинаковая, а значит можно настроить сценарий. 

Так появилась идея научить нашего AI‑ассистента делать аудит новых страниц самостоятельно. Не в стиле «посмотри сайт и скажи, что думаешь», а по нормальной процедуре, с фиксированным результатом. На выходе я хотел получать гугл‑таблицу с чек‑листом и PDF со скриншотами проблемных мест.

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

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

Мечта любого бизнесмена — чтобы в ответ на релевантный вопрос пользователя поисковая система (или нейронка) рекомендовала именно его товар. Нативно, без рекламы. Просто на первом месте поиска. А в случае LLM — как «правильный» и наиболее верный ответ, со ссылкой на сайт.

И так называемые «оптимизаторы» реализуют эту мечту. Они адаптируют контент сайта таким образом, что его можно продвинуть и «скормить» краулерам LLM.

Как сеошники прошлых лет портили оптимизировали контент старых сайтов, так оптимизаторы нового поколения наполняют Хабр текстами, которые пишутся для нейронок. Теперь это называется AEO (answer engine optimization) — оптимизация для AI-движков.

Я сделал ContentCombine — мультинишевый контент-комбайн, который собирает материалы из RSS, Telegram, сайтов и других источников, нормализует их, считает скор, склеивает повторы в сюжеты, отделяет кейсы от шума и готовит ежедневный дайджест. Сначала движок работал на игровых новостях, потом я перенёс его на SEO и AI — без переписывания ядра, но с кучей неожиданных граблей: entity blobs, старые статьи под видом свежих, молчащие фиды, ложные тренды и LLM-недетерминизм в проде.

У меня есть сайт на Next.js. Часть страниц индексируется почти сразу. Часть застряла в статусе «Обнаружено, не проиндексировано» уже две недели. Самое неприятное в том что все страницы технически одинаковые. Тот же фреймворк, тот же сервер, тот же sitemap.

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

Привет, Хабр! Меня зовут Борис, я инди‑хакер и разработчик. Обычно я пилю Telegram‑ботов и настраиваю автоматизации, но чуть менее года назад меня затянула идея создать собственный большой, удобный и, главное, полностью авторский веб‑проект в тематике ИИ — Нейро.PRO.

Я сразу решил, что не буду использовать никакие конструкторы, шаблоны из 2010х и унылые рерайтов. Всё пишем руками (с помощью ИИ‑шки конечно же), вылизываем UX и делаем упор на пользу для людей.

Если вы запускаете Manticore Search на Linux, в качестве основного инструмента управления стоит выбрать systemd.

На текущий момент это общепринятая практика, хотя ранее существовали определённые ограничения. Да, Manticore Search мог работать под systemd, но интеграция обладала рядом функциональных ограничений. Архитектура демона основана на традиционных подходах Unix; systemd появился позже и хотел от службы совсем другого. Так что настройка работала, но не соответствовала современным требованиям к управлению службами.

Теперь Manticore Search поддерживает нативные уведомления systemd — это и есть главное изменение.

Почему это важно? Потому что устраняется ряд операционных проблем: