Как бизнес теряет до 60% SEO-заявок из-за неправильной структуры сайта и почему из-за этого бренд хуже виден в AI-ответах
Почему структура сайта влияет на заявки, а не только на позиции
SEO давно перестало быть задачей «добавить ключи в текст». Поисковая система должна обнаружить URL, просканировать его, понять тему, сопоставить с запросом, выбрать среди похожих страниц, показать пользователю и привести его на понятный следующий шаг. На каждом этапе структура либо помогает, либо мешает.
Google в своих документах описывает базовую логику поиска через сканирование, индексирование и показ результатов. Sitemap помогает находить URL, внутренние ссылки помогают поисковику понимать структуру и важные страницы, а каноникализация нужна, когда один и тот же или очень похожий контент доступен по нескольким адресам. Это не «SEO-ритуалы», а технические условия видимости.
Для бизнеса это выглядит проще. Есть спрос, например:
- "заказать SEO-продвижение интернет-магазина";
- "SEO-аудит сайта услуг";
- "почему сайт не дает заявки";
- "структура сайта для SEO";
- "продвижение сайта в AI-поиске";
- "как сделать сайт понятным для ChatGPT и нейросетей".
Если под эти интенты нет отдельных страниц или блоков, поисковик вынужден выбирать из того, что есть. Иногда он показывает главную страницу, иногда старую статью, иногда вообще страницу конкурента. Пользователь вроде бы был в спросе, но до заявки не дошел.
Правильная структура отвечает на три вопроса:
- Какая страница должна собирать какой тип спроса?
- Как поисковая система поймет, что эта страница главная для данного интента?
- Как пользователь после перехода быстро дойдет до заявки, расчета, консультации или брифа?
Если эти вопросы не решены, SEO может работать "вхолостую": позиции есть, видимость есть, трафик есть, но коммерческий результат слабый.
Где рождаются потери: не одна ошибка, а сумма микро провалов
Потеря SEO-заявок редко возникает из-за одного сломанного элемента. Чаще это цепочка. Один раздел не вынесен в отдельную посадочную страницу. Несколько услуг склеены в один текст. Часть страниц спрятана слишком глубоко. В блоге нет связки с коммерческими страницами. У городских страниц одинаковые тексты. Фильтры открыты без логики. В sitemap попали технические URL, а важные страницы не попали. На странице нет FAQ и четкого CTA. Для пользователя это просто "сайт какой-то мутный". Для поисковой системы - слабая карта смыслов.
Воронку потерь можно разложить так:
- Потеря спроса: у бизнеса есть услуга или товар, но под реальные запросы нет посадочных страниц.
- Потеря индексации: страницы существуют, но не попадают в индекс или попадают нестабильно.
- Потеря релевантности: страница есть, но смешивает несколько интентов и проигрывает более точным конкурентам.
- Потеря авторитетности внутри сайта: важная страница не получает внутренних ссылок и выглядит второстепенной.
- Потеря клика: сниппет слабый, заголовок не отвечает на запрос, структура не дает поисковику понятные фрагменты.
- Потеря конверсии: человек пришел, но не понял, что делать дальше.
- Потеря AI-видимости: генеративная система не видит короткого, структурированного ответа, который можно использовать в обзоре или рекомендациях.
Каждый пункт может давать не катастрофу, а минус 5-15%. Но когда они складываются, бизнес реально может недобирать десятки процентов заявок. Поэтому структура сайта — это не "косметика для SEO", а инфраструктура привлечения.
Как посчитать свои "до 60%", не веря никому на слово
Правильный разговор о потерях начинается не с громкой цифры, а с измерения. Допустим, сайт получает 10 000 органических визитов в месяц и 120 заявок из SEO. Конверсия SEO-трафика - 1,2%. Это базовая точка.
Затем строится экспериментальная модель. Например:
- По отчетам видим 30 коммерческих запросных групп, но на сайте есть только 12 посадочных страниц. Остальные интенты обслуживаются главной, общим разделом или статьями. Это не значит автоматическую потерю всех заявок, но показывает недособранный спрос.
- Из 12 посадочных страниц 3 конкурируют между собой: у них похожие Title, H1, блоки услуг и запросы. Поисковик меняет релевантную страницу, позиции скачут, заявки размазываются.
- Еще 2 страницы есть, но почти не получают внутренних ссылок. Они есть в sitemap, но не встроены в пользовательский путь.
- Блог получает трафик, но часть статей не ведет к услугам. Пользователь получил ответ и ушел.
- В аналитике видно, что страницы с трафиком имеют форму заявки ниже зоны внимания или слишком общий CTA.
После исправлений можно провести A/B-подобный SEO-эксперимент без подмены страницы в реальном времени:
- выбрать кластер страниц;
- зафиксировать 60-90 дней до изменений;
- изменить структуру, перелинковку, заголовки, FAQ, CTA и схему;
- исключить сезонные и рекламные всплески;
- сравнить показы, клики, целевые действия, микроконверсии и заявки через 60-120 дней.
Именно так корректно говорить о потерях. Не "структура всегда отнимает 60%", а "по результатам аудита и последующего эксперимента можно выявить, что сайт недобирал до 60% потенциальных SEO-заявок в конкретном кластере". Это честная и проверяемая формулировка.
Все услуги собраны на одной странице
Одна из самых частых проблем - страница "Услуги", куда добавили все: разработку, SEO, контекст, дизайн, SMM, аналитику, поддержку, интеграции. На первый взгляд удобно: пользователь видит полный список. Для SEO это часто слабая конструкция.
Проблема не в том, что страница услуг плохая. Проблема в том, что она не может одинаково глубоко отвечать на разные интенты. Пользователь, который ищет "SEO-аудит интернет-магазина", ждет один набор аргументов: техническая проверка, индексация, категории, фильтры, коммерческие факторы, аналитика, план исправлений. Пользователь, который ищет "разработка сайта под ключ", ждет совсем другое: этапы проектирования, дизайн, CMS, интеграции, сроки, поддержка.
Если все это живет в одном полотне, поисковик видит широкую, но не самую точную страницу. Она может ранжироваться по брендовым и общим запросам, но проигрывать специализированным посадочным страницам конкурентов.
Правильная структура обычно строится так:
- общая страница "Услуги" как навигационный хаб;
- отдельная страница для SEO-продвижения;
- отдельная страница для SEO-аудита;
- отдельная страница для разработки сайта;
- отдельная страница для поддержки сайта;
- отдельная страница для контекстной рекламы, если услуга есть;
- статьи, которые отвечают на вопросы до покупки и ведут к коммерческим страницам.
Так сайт не разрывает один интент на десять тем. Он дает каждой теме свое место.
Информационные статьи не связаны с коммерческими страницами
Блог часто дает много органического трафика, но мало заявок. Причина не всегда в качестве статей. Иногда статья просто работает как тупик.
Пользователь читает материал "как понять, что сайт теряет заявки", получает пользу и закрывает вкладку. Он не видит рядом логичный следующий шаг: заказать аудит структуры, посмотреть чек-лист, отправить сайт на диагностику, перейти в кейс, сравнить проблемы с похожим проектом.
Для SEO и GEO информационная статья должна выполнять поддержку коммерческого спроса:
- закрывать вопрос, который возникает до обращения;
- показывать экспертность;
- объяснять риск без запугивания;
- ссылаться на релевантную услугу;
- давать диагностический шаг;
- помогать поисковику понять связь между темой статьи и услугами компании.
Например, статья про потери SEO-заявок должна вести не просто на "Главную", а на конкретные страницы: SEO-аудит, продвижение, разработка структуры, контент-стратегия, аналитика. Внутренняя ссылка должна быть смысловой: "если хотите проверить, где именно сайт теряет заявки, начните с SEO-аудита структуры".
Это важно и для AI-поиска. Генеративная система, которая собирает ответ из источников, лучше понимает сайт, где есть связка "проблема -> объяснение -> метод диагностики -> услуга -> доказательство". Если статья не связана с услугами, она остается отдельным текстом, а не частью экспертного узла.
Страницы конкурируют друг с другом
Каннибализация запросов - ситуация, когда несколько страниц одного сайта претендуют на один и тот же интент. Это не всегда плохо: крупные сайты могут иметь несколько материалов вокруг темы. Плохо, когда у страниц нет ясных ролей.
Пример:
- /seo/
- /prodvizhenie-sayta/
- /seo-prodvizhenie/
- /blog/chto-takoe-seo-prodvizhenie/
Если все четыре страницы имеют похожие Title, H1, вводные абзацы и одинаковые запросы, поисковик не получает четкого сигнала: какая страница коммерческая, какая обзорная, какая обучающая, какая должна быть главной для заявки. В результате релевантная страница может меняться, позиции становятся нестабильными, а пользователь попадает не туда.
Лечение не в том, чтобы удалить все лишнее. Сначала нужно назначить роли:
- коммерческая страница "SEO-продвижение" собирает заявки;
- статья "Что такое SEO-продвижение" объясняет базовые понятия и ведет на услугу;
- статья "Как выбрать SEO-подрядчика" закрывает возражения;
- кейс показывает доказательство;
- хаб "Маркетинг" распределяет темы.
После этого меняются заголовки, intro, блоки, внутренние ссылки и канонические сигналы. Страницы перестают спорить и начинают усиливать друг друга.
Глубина вложенности ломает важные страницы
Важная страница может быть технически доступна, но практически невидима. Например, она открывается только через три уровня меню, не получает ссылок из статей, не попадает в хлебные крошки, не видна на странице услуги и не появляется в блоках «похожие материалы».
Поисковая система обнаруживает страницы через ссылки и sitemap. Sitemap помогает сообщить о URL, но он не заменяет нормальную архитектуру сайта. Если коммерческая страница не включена в структуру, для поисковика она выглядит менее важной, а для пользователя — случайной.
Нормальная структура для сайта услуг обычно включает:
- главную страницу как общий вход;
- услуги-хабы;
- узкие услуги;
- кейсы;
- статьи поддержки;
- FAQ;
- страницы отраслей или типов клиентов, если это оправдано спросом;
- контакты и формы обращения;
- сквозную перелинковку между связанными материалами.
Для интернет-магазина логика похожая, но вместо услуг появляются категории, подкатегории, фильтры, товарные группы, бренды, подборки, инструкции и сравнения.
Важно не делать структуру ради структуры. Если страница не имеет спроса, не помогает пользователю и не усиливает коммерческий путь, она может стать мусором в индексе. SEO выигрывает не от количества URL, а от понятной карты спроса.
Региональные и отраслевые страницы сделаны шаблонно
Локальные и отраслевые страницы часто создают пачками: «SEO-продвижение в Москве», «SEO-продвижение в Санкт-Петербурге», «SEO-продвижение в Казани», а дальше меняют только город. Для поисковика и пользователя это слабый сигнал. Для AI-поиска — тем более.
Если у бизнеса реально есть региональная специфика, она должна быть фактической:
- адрес или зона обслуживания;
- схема работы с клиентами из региона;
- локальные кейсы;
- особенности спроса;
- сроки встреч или удалённой работы;
- примеры проектов;
- отзывы;
- документы и условия;
- команда или ответственный специалист;
- понятный способ связаться.
Если фактов нет, лучше не создавать десятки слабых страниц. Иногда достаточно одной сильной страницы с блоком «Работаем с компаниями из разных регионов» и кейсами по отраслям. В SEO не каждая география обязана становиться отдельным URL.
Для GEO это особенно важно. Генеративные системы склонны пересказывать конкретные факты. Если на странице только заменённый город, ей нечего дать в ответ. Если есть адресность, кейс, услуга, метод, результат и ограничения, источник становится полезнее.
Технические файлы есть, но они не помогают понять сайт
На многих сайтах есть sitemap.xml и robots.txt, но они живут отдельно от реальной SEO-логики. В sitemap попадают страницы, которые не нужны в поиске. Важные страницы отсутствуют. Robots.txt закрывает не то, что нужно. Канонические URL противоречат внутренним ссылкам. Структурированные данные добавлены формально или с ошибками.
Базовый набор технических элементов должен отвечать на простые вопросы:
- какие страницы мы хотим видеть в поиске;
- какие страницы не должны участвовать в органической выдаче;
- где главные версии дублей;
- какие разделы являются основными;
- как поисковик обнаруживает новые и обновленные URL;
- какие страницы отвечают за коммерческий интент;
- какие блоки помогают расширенным результатам и AI-ответам.
Robots.txt не является инструментом для скрытия конфиденциальной информации и не заменяет noindex или контроль доступа. Sitemap не гарантирует индексацию. Schema.org не гарантирует расширенный сниппет. Но все эти элементы уменьшают неопределённость. Для SEO это уже много.
Что меняется из-за AI-поиска и GEO
GEO, или Generative Engine Optimization, часто подают как «новое SEO для нейросетей». Это удобное, но опасно упрощённое объяснение. На практике GEO не заменяет SEO. Оно добавляет новый слой: сайт должен быть понятен не только поисковому роботу и человеку, но и системам, которые формируют обобщённый ответ.
Исследование «Generative Engine Optimization» на arXiv тестировало методы повышения видимости источников в генеративных поисковых системах. Среди подходов рассматривались, например, добавление цитат, статистики и более авторитетной подачи. Это не означает, что один приём гарантирует рост заявок. Но вывод практический: структурированный, доказательный и хорошо размеченный контент легче использовать как источник.
AI-поиск усиливает старую проблему структуры. Если сайт непонятен обычному поиску, генеративной системе он тоже не станет внезапно понятнее. Если услуга спрятана в общем тексте, факты разбросаны, FAQ нет, кейсы не связаны с услугами, авторство не указано, а страницы дублируют друг друга, AI-ответу проще взять другой источник.
Для бизнеса GEO означает несколько задач:
- писать страницы так, чтобы абзацы могли работать как самостоятельные ответы;
- добавлять факты, ограничения, методику, примеры и источники;
- использовать FAQ там, где есть реальные вопросы;
- связывать статьи с услугами и кейсами;
- показывать автора, экспертизу, дату обновления;
- поддерживать sitemap, robots.txt, canonical и структурированные данные;
- подготовить краткую карту сайта для LLM-систем, если это уместно.
Важно: сегодня нет единого официального стандарта, который гарантирует попадание сайта в ответы всех AI-систем. Поэтому GEO нужно делать как инженерную дисциплину: гипотеза, внедрение, проверка, логирование, сравнение.
Что делать после мониторинга AI-ответов
Допустим, компания уже проверила 30–50 сценариев в нейросетях и получила отчёт: где бренд упоминается, где проигрывает конкурентам, где описывается неточно, какие источники чаще используются. Следующий шаг — не «написать ещё десять статей про нейросети». Следующий шаг — сопоставить AI-сценарии со структурой сайта.
Нужна таблица из пяти колонок:
- сценарий вопроса в AI-системе;
- какой ответ должен быть идеальным;
- какая страница сайта может подтвердить этот ответ;
- какие доказательства есть на странице;
- какой следующий шаг ведёт к заявке.
Если в третьей колонке пусто, у бизнеса нет страницы-источника. Если страница есть, но без фактов, кейсов и FAQ, она слабая. Если страница хорошая, но на неё нет внутренних ссылок, она плохо встроена в архитектуру. Если ответ есть, но нет CTA, AI-видимость не превращается в лид.
Пример:
- AI-сценарий: «как понять, что сайт теряет заявки из SEO»;
- нужный ответ: «провести аудит структуры, индексации, посадочных страниц, перелинковки и конверсии»;
- страница-источник: статья про потери SEO-заявок и коммерческая страница SEO-аудита;
- доказательства: чек-лист, методика, кейсы, типовые ошибки, источники;
- следующий шаг: отправить сайт на экспресс-разбор.
Так мониторинг становится не отчётом ради отчёта, а дорожной картой контента. Каждое слабое место в AI-ответах превращается в конкретную SEO-задачу: создать страницу, уточнить блок, добавить источник, связать статью с услугой, обновить llms.txt, переработать FAQ или усилить кейс.
Почему "бренд-присутствие" без структуры не дает продаж
Упоминание бренда в AI-ответе само по себе ещё не заявка. Пользователь может увидеть компанию в списке, но не перейти на сайт. Может перейти, но попасть на общую страницу. Может найти статью, но не увидеть услуги. Может увидеть услугу, но не понять, чем компания отличается. На каждом этапе нужна структура.
Для коммерческого результата AI-присутствие должно быть связано с тремя типами страниц:
- страницы выбора: «какое решение мне нужно», «как выбрать подрядчика», «что проверить перед стартом»;
- страницы доверия: кейсы, методики, экспертные статьи, авторы, отзывы, примеры работ;
- страницы действия: услуги, аудит, консультация, расчёт, бриф, контакты.
Если есть только первый тип, сайт обучает рынок, но не продаёт. Если есть только третий тип, сайт просит заявку до того, как человек понял ценность. Если нет второго типа, AI-системам и пользователям трудно объяснить, почему именно этот бренд стоит упоминать.
Здоровая GEO-структура соединяет все три слоя. Тогда нейросеть может назвать бренд в контексте проблемы, пользователь может проверить источник, а сайт может довести его до следующего шага.
Зачем создавать llms.txt и что в нем должно быть
llms.txt - это предложенный формат markdown-файла, который размещают в корне сайта, например https://example.com/llms.txt. Идея простая: дать языковым моделям короткую, чистую карту сайта с важными страницами, описанием проекта и ссылками на ключевые материалы. Это похоже не на sitemap.xml, а на редакторскую подсказку: "вот что важно прочитать, если нужно понять сайт".
Для SEO llms.txt не является заменой sitemap.xml, robots.txt, нормальной навигации, HTML-текстов или Schema.org. Для GEO он может быть полезен как дополнительный слой ориентации.
Что можно включить в llms.txt:
- краткое описание компании;
- список основных услуг;
- ссылки на коммерческие страницы;
- ссылки на сильные экспертные статьи;
- ссылки на кейсы;
- информацию об авторстве и редакционной политике;
- ограничения: что компания не делает, где не работает, какие данные нужно проверять на странице;
- ссылку на sitemap.xml;
- дату обновления.
Чего не стоит делать:
- набивать файл ключевыми словами;
- писать рекламный текст вместо карты;
- скрывать в нем важную информацию, которой нет на сайте;
- обещать AI-системам, что они обязаны использовать контент;
- считать llms.txt "волшебной кнопкой" для ChatGPT, Gemini, Perplexity или других систем.
Мифы и факты про llms.txt
Миф 1.
llms.txt гарантирует попадание сайта в AI-ответы.
Факт: гарантий нет. Формат llms.txt является предложением сообщества, а не универсальным обязательным стандартом для всех поисковых и AI-систем. Его лучше рассматривать как дополнительную подсказку для моделей и инструментов, которые умеют или будут уметь её читать.
Миф 2.
llms.txt заменяет sitemap.xml.
Факт: sitemap.xml нужен поисковым системам для обнаружения URL. llms.txt нужен для краткого смыслового описания важных страниц. Это разные задачи. Хороший сайт может использовать оба файла, но один не заменяет другой.
Миф 3.
В llms.txt нужно добавить все страницы сайта.
Факт: ценность файла в краткости. Если туда выгрузить сотни URL без объяснения, он станет вторым sitemap. Лучше указать ключевые страницы, разделы, документы и материалы, которые объясняют бизнес.
Миф 4.
Достаточно создать llms.txt, и GEO готово.
Факт: GEO начинается со структуры сайта, качества контента, фактов, авторства, внутренних ссылок и технической доступности. llms.txt только помогает ориентироваться. Если страницы слабые, карта не спасет.
Миф 5.
Через llms.txt можно управлять всеми AI-ботами.
Факт: для управления доступом ботов используются другие механизмы, в первую очередь robots.txt и настройки сервера, если конкретный бот их поддерживает. Например, OpenAI публикует информацию о своих user-agent, включая GPTBot, OAI-SearchBot и ChatGPT-User. llms.txt не является файлом запрета или разрешения обхода.
Миф 6.
llms.txt нужен только IT-компаниям.
Факт: формат может быть полезен любому сайту, где важно быстро объяснить структуру знаний: агентству, клинике, производителю, образовательному проекту, интернет-магазину, B2B-компании. Но полезность зависит от качества самой карты и страниц, на которые она ведёт.
Какие эксперименты стоит провести перед внедрением GEO
GEO нельзя внедрять на уровне «нам сказали, что это модно». Нужен набор проверок.
Первый эксперимент — проверка ответов AI-систем. Берём 20–50 запросов, которые потенциальный клиент может задать в ChatGPT, Perplexity, Gemini, Яндекс Алисе или другом сервисе. Формулируем их не как SEO-ключи, а как живые вопросы:
- «как понять, что сайт теряет заявки из SEO»;
- «что проверить в структуре сайта перед SEO-продвижением»;
- «кому заказать SEO-аудит сайта услуг»;
- «зачем бизнесу llms.txt»;
- «как подготовить сайт к AI-поиску»;
- «почему блог даёт трафик, но не заявки».
Дальше фиксируем:
- упоминается ли бренд;
- цитируются ли страницы сайта;
- какие конкуренты появляются;
- какие формулировки AI использует;
- какие источники считает авторитетными;
- есть ли ошибки в описании компании;
- хватает ли на сайте страниц, которые могли бы стать источником ответа.
Второй эксперимент — переработка одного тематического кластера. Например, берём кластер «структура сайта и SEO-заявки»: коммерческая страница, статья, FAQ, кейс, блок услуги, внутренние ссылки и llms.txt. Вносим изменения только в этот кластер, чтобы можно было измерить эффект.
Третий эксперимент — сравнение до и после. Смотрим:
- показы и клики в поисковых системах;
- рост запросов по кластерам;
- заявки с затронутых страниц;
- переходы из статей в услуги;
- видимость в AI-ответах по ручной выборке;
- изменение качества сниппетов;
- поведение пользователей на странице.
Четвертый эксперимент — чистота фактов. Просим несколько AI-систем описать компанию по материалам сайта. Если они ошибаются, значит на сайте не хватает ясных фактов: кто вы, что делаете, для кого, где работаете, какие услуги ключевые, чем подтверждается опыт.
Мини-чек-лист: как понять, что структура уже съедает SEO-заявки
Проверьте сайт по 15 признакам.
- Важные услуги перечислены на одной странице, но не имеют отдельных посадочных страниц.
- В Search Console или Яндекс Вебмастере есть показы по запросам, под которые нет точных URL.
- Несколько страниц сайта ранжируются по одним и тем же запросам.
- Блог получает трафик, но пользователи почти не переходят на услуги.
- Внутренние ссылки ведут на главную вместо релевантных страниц.
- В sitemap.xml есть технические, пустые или слабые страницы.
- Часть коммерческих страниц не получает внутренних ссылок.
- Страницы имеют одинаковые Title и H1.
- У услуг нет FAQ, кейсов, этапов, ценовых факторов и доказательств.
- Городские или отраслевые страницы отличаются только заменой слова.
- Фильтры и теги создают дубли без самостоятельной ценности.
- Пользователь после статьи не видит следующего действия.
- Структурированные данные отсутствуют там, где они уместны.
- На сайте нет ясной связки «услуга -> кейс -> статья -> FAQ».
- AI-системы описывают компанию неточно или не находят её как источник по профильным вопросам.
Если совпало 5–7 пунктов, структура уже может ограничивать рост. Если совпало больше 10, проблема, скорее всего, влияет не только на SEO, но и на конверсию.
Почему "просто добавить статьи" больше не спасает
Раньше многие сайты росли за счёт блога: чем больше статей, тем больше трафика. Сейчас этот подход опасен, если статьи не встроены в структуру. Информационный трафик может расти, а заявки — нет. Более того, часть статей может начать конкурировать с коммерческими страницами.
Например, коммерческая страница называется «SEO-аудит сайта», а статья называется «Что входит в SEO-аудит сайта». Если статья подробнее, лучше структурирована и активнее перелинкована, поисковик может считать её более релевантной по коммерческому запросу. Пользователь попадёт в статью, прочитает общую информацию и не оставит заявку.
Решение:
- коммерческая страница должна быть сильнее по коммерческим факторам;
- статья должна объяснять вопрос и ссылаться на услугу;
- заголовки должны разводить интенты;
- CTA должен быть уместным, а не агрессивным;
- внутренние ссылки должны показывать иерархию.
Статья не должна заменять услугу. Она должна подводить к ней.
Как неправильная структура влияет на сниппеты и AI-обзоры
Когда поисковая система формирует сниппет, она пытается понять, какой фрагмент страницы лучше всего отвечает на запрос. Если страница состоит из общих фраз, повторов и разрозненных блоков, сниппет может быть слабым. Если на странице есть точные ответы, списки, FAQ, понятные заголовки и структурированные данные, шанс получить понятный фрагмент выше.
AI-обзоры работают иначе, но проблема похожая. Система собирает ответ из источников, которым может доверять и которые можно удобно пересказать. Ей нужны:
- ясные определения;
- фактические утверждения;
- ограничения и оговорки;
- пошаговые методы;
- авторство;
- дата обновления;
- источники;
- отсутствие противоречий между страницами.
Если на сайте в одном месте написано «мы делаем SEO под ключ», в другом - «мы только консультируем», в третьем - «мы занимаемся разработкой», а структура не объясняет связь, AI может описать компанию неточно. Это уже не просто SEO-риск. Это риск репутации в новых каналах поиска.
Что говорит практика: структура часто важнее еще одного текста
В проектах с уже накопленным контентом самый быстрый рост часто даёт не написание новой статьи, а перераспределение существующих страниц. Типовой порядок работ:
- Собрать все индексируемые URL.
- Разделить их по ролям: коммерческие, информационные, навигационные, технические, дубли, мусор.
- Найти страницы без трафика и без роли.
- Найти страницы с трафиком, но без заявок.
- Найти страницы, которые конкурируют друг с другом.
- Переписать заголовки и интро под разные интенты.
- Добавить внутренние ссылки и блоки перехода.
- Закрыть или объединить слабые дубли.
- Обновить sitemap и технические сигналы.
- Подготовить краткую карту для llms.txt.
Это не выглядит так эффектно, как «мы написали 50 статей». Зато часто даёт более чистый результат: меньше мусора, больше понятных посадочных страниц, выше конверсия уже существующего трафика.
Пришлите сайт на экспресс-разбор
Мы проверим, какие страницы собирают спрос, где есть дубли и какие интенты сейчас остаются без посадочных страниц.
Это лучше, чем абстрактное «оставьте заявку на продвижение», потому что CTA совпадает с болью статьи.
Что не нужно делать
- Не нужно создавать сотни страниц под каждый похожий запрос. Это приводит к дублям и размывает качество.
- Не нужно закрывать все фильтры в robots.txt без понимания, какие из них собирают спрос.
- Не нужно делать городские страницы без реальных региональных фактов.
- Не нужно переписывать статьи только ради ключевых слов. Лучше добавить недостающие смыслы, примеры, FAQ и внутренние ссылки.
- Не нужно ждать, что AI-поиск решит проблемы обычного SEO. Если сайт плохо структурирован, GEO только подсветит слабые места.
- Не нужно внедрять llms.txt как замену стратегии. Это карта, а не двигатель.
Частые вопросы
Да, такой сценарий возможен, но это не универсальная статистика. Потери нужно считать на данных конкретного сайта: спрос без посадочных страниц, проблемы индексации, каннибализация, слабая перелинковка, низкая конверсия страниц и отсутствие связки между статьями и услугами. В некоторых кластерах сумма этих факторов может давать очень большую недостачу заявок.
Они работают вместе. Хороший текст на неправильной странице часто не раскрывает потенциал. Сильная структура без полезного контента тоже не даст результата. Сначала нужно понять роль страницы и ее место в сайте, затем писать текст под конкретный интент.
Если услугу ищут отдельно и она имеет самостоятельный коммерческий интент, да. Если спрос слабый или услуга является частью более крупного направления, ее можно раскрыть внутри хаба. Решение должно опираться на семантику, аналитику и бизнес-приоритеты.
Sitemap помогает поисковым системам находить URL, но сам по себе не гарантирует индексацию и позиции. Он должен отражать реальную структуру сайта и содержать страницы, которые действительно нужны в поиске.
Robots.txt сообщает ботам правила обхода, если конкретный бот их учитывает. llms.txt предлагает краткую markdown-карту сайта для языковых моделей и AI-инструментов. Это разные файлы с разными задачами.
Если на сайте уже есть понятные услуги, статьи, кейсы и экспертные материалы, llms.txt можно добавить как дополнительный GEO-слой. Если структура слабая, сначала лучше исправить страницы и связи между ними, иначе файл будет вести на неготовый контент.
Да, но не так прямолинейно, как позиции в поиске. Можно фиксировать видимость бренда и страниц в AI-ответах по контрольным запросам, переходы из AI-сервисов там, где они передают referrer, рост брендовых запросов, качество описаний компании и изменения в SEO-кластерах после структурных правок.
Проверьте, какие статьи приводят пользователей, какие интенты они закрывают и есть ли на них переходы к услугам. Добавьте релевантные внутренние ссылки, блоки "что делать дальше", кейсы, формы, CTA и связи с коммерческими страницами. Иногда нужно переписать статью, чтобы она не конкурировала с услугой.
Оба сценария опасны. Нехватка страниц оставляет спрос без посадки. Избыточные страницы создают дубли, каннибализацию и мусор в индексе. Задача структуры — не увеличить количество URL, а дать каждому интенту правильное место.
Начните с выгрузки всех URL, данных по показам и кликам, списка услуг, карты запросов и текущих заявок. Затем назначьте каждой странице роль и проверьте, есть ли у каждого важного интента своя посадочная страница и путь к конверсии.
Вывод
Неправильная структура сайта редко выглядит как авария. Сайт открывается, страницы есть, тексты написаны, заявки иногда приходят. Но внутри SEO-воронки могут накапливаться потери: не тот URL ранжируется, часть спроса не закрыта, блог не ведёт к услугам, страницы дублируются, sitemap не отражает приоритеты, AI-системы не понимают, какие материалы являются главными.
Именно поэтому бизнес может недобирать значительную долю SEO-заявок и долго считать, что проблема в бюджете, конкурентах или «SEO уже не работает». На практике часто нужно не больше текстов, а более ясная архитектура: карта спроса, правильные посадочные страницы, чистая индексация, внутренняя перелинковка, фактический контент, FAQ, Schema.org и аккуратный GEO-слой с llms.txt.
Если вы хотите понять, где именно сайт теряет заявки, начните не с догадок, а с аудита структуры. Проверьте, какие страницы должны собирать спрос, какие реально его собирают, где пользователь уходит и какие ответы о вашей компании уже дают поисковые и AI-системы. После этого SEO перестаёт быть туманной услугой и становится управляемой системой роста.
