Кейс системной оптимизации большого массива контента с помощью ИИ, Screaming Frog и Google Search Console – от инвентаризации сотен URL до карты поисковых интентов и контроля будущих публикаций.
Не написать ещё больше контента, а понять, зачем существует каждая страница
Когда сайт развивается несколько лет, проблема появляется постепенно. Добавляются статьи, услуги, кейсы, рубрики, старые материалы перерабатываются, часть URL исчезает, а часть меняет назначение.
Каждая страница сама по себе может выглядеть нормально. Но на уровне всего контентного массива возникают другие вопросы: какой URL должен отвечать на конкретный поисковый запрос, где начинается внутренняя конкуренция, какие страницы действительно нужно сохранить и что можно публиковать дальше без каннибализации.
В этом проекте задача состояла именно в построении такой системы. ИИ использовался не как машина для массового написания статей, а как инструмент анализа, сопоставления и удержания большого контекста.
Сотни страниц существовали – единой карты их ролей не было
Исторический контентный корпус насчитывал около 300 URL. В актуальном sitemap к моменту анализа находилось уже 359 адресов.
При дальнейшем развитии сайта нельзя было безопасно создавать новые статьи, пока не станет понятно, какие темы уже заняты, какие страницы конкурируют между собой и какой материал является владельцем каждого поискового интента.
Похожие страницы
Материалы с разными названиями могли фактически отвечать на один и тот же запрос.
Разные функции смешивались
Статья, услуга, страница цены и кейс тематически близки, но не должны бороться за один интент.
Исторические URL
Поисковые данные содержали адреса, которых уже не было в актуальной структуре сайта.
Новый контент создавался бы вслепую
Без общей карты каждая новая публикация увеличивала бы риск смысловых пересечений.
Чтобы понять контент, недостаточно прочитать только сами тексты
Мы объединили техническое состояние страниц, фактический поисковый спрос и смысловую роль контента. Каждый источник отвечал на свою часть задачи.
Screaming Frog
HTTP-коды, индексируемость, canonical, Title, Description, H1, внутренние ссылки и фактическая структура сайта.
Google Search Console
Какие реальные запросы уже получают показы и на какие URL поисковая система распределяет этот спрос.
ИИ + ручная проверка
Сопоставление сотен URL, поиск смысловых пересечений, группировка интентов и сохранение принятых решений.
Screaming Frog показал, что находится на сайте сейчас
Первый проход был нужен для создания технического снимка актуального корпуса страниц.
На этом этапе мы ещё не решали, какие статьи хорошие или плохие. Сначала требовалось получить объективный реестр URL и проверить, что именно индексируемо, куда ведут canonical, какие страницы получают внутренние ссылки и нет ли очевидных технических конфликтов.
URL в актуальном sitemap
страниц ответили HTTP 200
дублей Title и H1 в актуальном корпусе
URL с двумя или менее входящими внутренними ссылками
Google Search Console показал, как поисковая система уже распределяет запросы
Технически разные URL ещё не обязательно являются разными по смыслу. Поэтому следующий слой анализа строился на связке поисковый запрос → посадочная страница.
Так стало видно не просто сходство текстов, а реальные случаи, когда Google показывал несколько страниц сайта по одному и тому же запросу.
уникальных запросов в доступной выборке
посадочных страниц присутствовали в Query → URL
точных запросов показывались более чем на одном URL
90 пересекающихся запросов пришлось разбирать по смыслу, а не удалять автоматически
Один запрос действительно может естественно приводить пользователя на несколько близких материалов. Поэтому совпадение URL в Search Console рассматривалось только как сигнал для проверки.
13
Высокий риск
Страницы реально боролись за один и тот же основной интент.
30
Средний риск
Пересечение требовало уточнения границ тем и внутренних сигналов.
47
Низкий риск
Близость была естественной и не требовала агрессивного объединения страниц.
Это позволило избежать другой крайности – объединять полезные самостоятельные материалы только потому, что в них встречаются одинаковые слова.
Для каждой значимой страницы определили её место в общей архитектуре
Чтобы результаты анализа не остались набором разовых рекомендаций, мы создали постоянную систему описания URL.
Primary Intent
Какую основную задачу пользователя должна закрывать конкретная страница.
Owner URL
Какой URL является главным владельцем конкретного поискового интента.
Boundary
Какие вопросы страница раскрывает и куда ей нельзя расширяться, чтобы не отбирать чужой интент.
Closest URLs
Ближайшие по смыслу страницы, которые нужно учитывать при любом будущем изменении.
Похожие по теме страницы получили разные функции
Это особенно важно для коммерческих кластеров. Тематическая близость ещё не означает, что URL нужно объединять.
| Тип страницы | Основная задача | Чего она не должна делать |
|---|---|---|
| Услуга | Отвечать на коммерческий запрос | Превращаться в большой обучающий гайд |
| Страница цены | Закрывать ценовой интент | Отбирать общий запрос основной услуги |
| Информационная статья | Объяснять методику и отвечать на вопросы | Маскироваться под коммерческую посадочную |
| Кейс | Показывать выполненную работу | Автоматически становиться Owner услуги |
| Хаб или рубрика | Организовывать семейство материалов | Конкурировать с дочерними страницами по их узким интентам |
Старый редирект тоже пришлось проверять – сам код 301 ещё ничего не гарантирует
В поисковых данных оставались адреса, которых уже не было в актуальном sitemap. Для отдельного набора из 171 исторического URL мы провели дополнительный обход.
Часть старых адресов действительно перенаправлялась, но некоторые редиректы вели на изображения или другие медиафайлы вместо релевантных HTML-страниц. Поэтому каждый значимый случай проверялся по смыслу.
URL уже возвращали 301
возвращали 404
оставались индексируемыми PDF
точечных редиректов настроены и перепроверены
Где именно в этой работе помогал ИИ
ИИ использовался
Для сопоставления URL, удержания контекста сотен страниц, поиска смысловых соседей, структурирования GSC-данных, подготовки Boundary и проверки новых тем против уже существующей карты.
ИИ не использовался
Как источник безусловно верных SEO-решений или механизм массовой публикации новых статей. Итоговые решения проверялись по содержанию, техническим данным и фактическому поисковому спросу.
Главная ценность ИИ проявилась не в скорости написания текста, а в способности работать с большим объёмом связанных решений и не терять уже определённые границы страниц.
Проверка новой статьи теперь начинается ещё до её публикации
После нормализации существующих страниц мы изменили сам процесс разработки контента. Теперь готовый материал можно занести в паспорт ещё до того, как URL появится на сайте.
Определить Primary Intent будущего материала.
Проверить, существует ли уже Owner этого поискового намерения.
Найти ближайшие опубликованные и запланированные материалы.
Задать Boundary – что статья раскрывает и какие темы ей нельзя забирать.
Зарезервировать URL и роль материала до выхода в индекс.
Только после этого финализировать текст, метаданные и внутренние ссылки.
Так каннибализация предотвращается до публикации, а не обнаруживается через несколько месяцев после того, как несколько URL уже начали делить один запрос.
Из списка страниц получилась управляемая архитектура контента
У значимых URL появилась определённая роль. Коммерческие, информационные, ценовые и кейсовые интенты были разведены. Исторические адреса получили осмысленные решения, а будущие статьи начали проверяться ещё до публикации.
Контентный аудит перестал быть разовым мероприятием и превратился в систему, которая используется при каждом следующем изменении сайта.
Появился единый Master Content Map
В одном месте хранятся URL, роли, интенты, границы, соседние страницы и принятые решения.
Определены владельцы интентов
При появлении новой темы видно, должна ли она получить собственный URL или поддерживать существующий Owner.
Редиректы перестали быть формальностью
Старый адрес ведёт не просто куда-нибудь с кодом 301, а на содержательно подходящую страницу.
Планируемый контент тоже учитывается
Готовые, но ещё не опубликованные материалы резервируются в архитектуре заранее.
Что мы сознательно не записываем в результат
На момент подготовки кейса мы не приписываем проведённой работе рост трафика, позиций или продаж. Для такого вывода нужен достаточный период после переиндексации и накопления новых поисковых данных.
Зато уже можно проверить результаты самого процесса: карта построена, роли URL определены, конфликтные группы разобраны, проблемные редиректы исправлены, а новые материалы проходят проверку до публикации.
При сотнях страниц главным становится уже не производство контента, а управление им
Генеративный ИИ позволяет создавать тексты быстрее. Но без архитектуры именно эта скорость способна ускорить появление дублей, смысловых пересечений и конкурирующих страниц.
Поэтому в большом контентном проекте наиболее полезным применением ИИ оказалось не массовое написание материалов, а анализ связей, сохранение контекста и контроль места каждой новой страницы в общей системе.
Другие материалы и услуги по теме
Исправление выявленных технических проблем и внедрение изменений.
Другие кейсы работ с помощью ИИ →
Практические примеры использования ИИ в аналитике, контенте, рекламе и других задачах.
Этот материал относится к рубрике
кейсов разработки контента с помощью ИИ.
Ещё один пример работы с данными –
анализ отмен заказов интернет-магазина с помощью ИИ.
Сначала разберём существующую систему – потом будем добавлять новые страницы
Если сайт развивался несколько лет и уже сложно понять, какие статьи пересекаются, куда вести новые темы и что делать со старыми URL, начинать лучше с карты контента, а не с очередной публикации.