Что получил клиент
| Бизнес-метрика | До | После | Изменение | Изменение % |
|---|---|---|---|---|
| Средний органический трафик за неделю | 27 495 | 32 394 | +4 899 | +18% |
| Средний небрендовый органический трафик за неделю | 3 219 | 7 645 | +4 426 | +138% |
| Ключевые слова в позициях 1-3 | 142 | 303 | +161 | +113% |
| Ключевые слова в позициях 4-10 | 393 | 443 | +50 | +13% |
| Всего отслеживаемых органических ключевых слов | 727 | 910 | +183 | +25% |
| Появления в топ-10 за неделю | 1 548 | 2 532 | +984 | +64% |
| Упоминания в AI Overview | 106 | 306 | +200 | +189% |
| Доля видимости | 10,4% | 20,6% | +10,2 п.п. | +98% |
Источник: Ahrefs. Сравнительный период: с 1 мая по 1 июля 2026 года.
До исправления рендеринга ИИ-системы не получали исходный контент целиком и выдумывали факты и характеристики продуктов. После релиза они смогли читать и цитировать информацию, опубликованную платформой.
Почему продукты не появлялись в ИИ-поиске?
Поисковые системы и ИИ не могли прочитать контент
JavaScript скрывал важный текст на тысячах страниц. Поисковые системы и ИИ находили URL, но не могли надежно получить и понять опубликованную информацию о продуктах.
Краулеры не могли достичь всех запланированных страниц
В картах сайта не было индексируемых URL. Битые внутренние ссылки вели на несуществующие страницы, а редиректы добавляли лишние переходы на пути краулера к полезному контенту.
Общие правила сайта размножали одни и те же ошибки
Правила для метаданных и структурированных данных создавали ошибки в целых группах страниц. Исправив общие правила, мы смогли одним релизом исправлять тысячи страниц.
Мы расставили результаты аудита по влиянию на бизнес, превратили их в задачи, готовые к разработке, и повторяли те же проверки после каждого релиза.
Как мы довели стратегию до релиза
Согласовали критерии успеха с директором по маркетингу
Нашли общие технические ограничения
Передали разработчикам задачи, готовые к внедрению
Сопровождали каждый релиз
Что мы изменили
Аудит Dioptria
| Технический результат | Обнаружено | Оставшееся после исправлений | Изменение | Почему это имело значение |
|---|---|---|---|---|
| Страницы, скрывающие содержимое тела за JavaScript | ~8,000 | 0 | -8,000 (-100%) | Системы ИИ могли читать и цитировать опубликованную информацию о продукте |
| Индексируемые страницы, отсутствующие в картах сайта | 4,266 | 12 | -4,254 (-99.7%) | Краулеры смогли находить нужные страницы |
| Неправильные внутренние ссылки | 1,176 | 4 | -1,172 (-99.7%) | Краулеры перестали попадать в тупики |
| Внутренние ссылки, проходящие через редиректы | 547 | 50 | -497 (-91%) | Краулеры получили прямые пути к контенту |
| Ошибки в полях метаданных | 41,557 | 969 | -40,588 (-98%) | Поисковые системы получали более точные сигналы от страниц |
| Повторно использованные метаданные | 24,332 | 2,371 | -21,961 (-90%) | У большего числа страниц появились уникальные заголовки и описания |
| Конфликтующие значения метаданных | 16,434 | 7,790 | -8,644 (-53%) | Поисковые системы получили меньше противоречивых сигналов |
| Страницы без нужного типа структурированных данных | 2,352 | 0 | -2,352 (-100%) | Поисковые системы и ИИ получили явное описание назначения страницы |
| Ссылки hreflang, ведущие на ошибочные страницы | 874 | 0 | -874 (-100%) | Краулеры достигли правильных языковых целей |
Обнаружено = максимальное количество за неделю аудита с 7 мая по 5 июля. Оставшееся = аудит от 5 июля.
Порядок работ был важен. Сначала мы исправили рендеринг, чтобы краулер получил весь контент. После этого он смог найти более глубокие проблемы в ссылках, картах сайта, метаданных и структурированных данных. Затем мы связали эти проблемы с общими шаблонами и правилами, поэтому каждый технический релиз исправлял тысячи страниц сразу.
Еженедельное сканирование показывало, что сайт отдает после каждого релиза. По его результатам мы принимали исправление или возвращали его в разработку. Изменения в индексации и реальной производительности страниц на протяжении проекта измеряли в Search Console.
Google Search Console
| Технический результат | До | После | Изменение | Почему это имело значение |
|---|---|---|---|---|
| Страницы, проиндексированные Google | 6,014 | 7,491 | +1,477 (+25%) | Больше страниц смогли участвовать в ранжировании и появляться в поиске |
| Страницы для десктопа с оценкой «плохой» по Core Web Vitals | 296 | 1 | -295 (-99,7%) | Google снял плохую классификацию почти со всех затронутых URL |
| Страницы для десктопа с оценкой «требует улучшения» | 674 | 24 | -650 (-96%) | Больше страниц прошло строгие пороги реальной производительности |
Источник: Google Search Console. Сравнение: 1-2 мая по 30 июня-1 июля 2026 года.
В конце проекта мы оценили общие технические результаты в Search Console, а изменения видимости в обычном и ИИ-поиске - в Ahrefs. Для бизнеса это означает, что покупатели теперь находят продукты платформы по небрендовым запросам и в ответах ИИ, где раньше эти продукты не появлялись или были описаны неверно.
Проблемы с canonical, robots meta, производительностью на мобильных устройствах, внешними ссылками и менее значимые ошибки метаданных перешли в следующий этап.
С чего мы начинаем проект
Определяем бизнес-приоритеты
Сначала выясняем, какие продукты приносят выручку сейчас, какие вы хотите развивать, какие рынки важны и что именно покупатели должны находить через обычный поиск и ИИ.
Решаем, что должно стать видимым
Определяем, какой контент нужно создать, улучшить или открыть поисковым системам и ИИ. Затем связываем эти задачи с изменениями сайта, которые нужны для роста видимости.
Доводим работу до релиза
Расставляем задачи по бизнес-приоритетам, проводим план через маркетинговую, продуктовую и техническую команды, проверяем каждый релиз и сравниваем результат с целями, согласованными в начале.
Давайте поговорим о вашем бренде.
Обсудим продукты, которые вы хотите развивать, нужную аудиторию и то, как покупатели могут находить ваши товары через обычный поиск и ответы ИИ.