11 / SEO Audit / Live architecture

SEO-аудит каталога Impulse Media AM: методика и приоритеты

Это модель роста: что уже работает, где система теряет поисковый спрос и какое изменение даст максимальный эффект. Разбираю метод на публичной версии Impulse Media AM.

Снимок: 22.08.2026
5 шаблонов в выборке
20 120 URL в sitemap

SEOне один score

Граница данных

Это внешний аудит публичной версии: HTML, HTTP-ответы, robots.txt, sitemap и видимая структура. Позиции, реальные Core Web Vitals, логи, конверсии и индексирование в Google Search Console нельзя честно оценить без доступа — поэтому они отмечены как следующий слой, а не выдуманный балл.

01 / Полнота аудита

Глубина зависит от доступа к данным.

Переключите режим: это не оценка качества сайта, а доля проверок, которую можно доказательно выполнить.

58% покрытия

Можно проверить 58% системы

Архитектура, ответы, метаданные, sitemap, robots и видимая перелинковка. Индексирование и поведение пользователей остаются гипотезой.

02 / URL inventory

Сначала измеряем масштаб.

Один общий sitemap разделён на два независимых массива: основной контент и каталог.

19 790URL каталога

330основных URL

20 120всего

Каталог98,36%

Карточки товаров, категории и подкатегории — главный объём обхода.

Контент1,64%

Главная, услуги, кейсы, статьи и навигационные страницы.

03 / Наблюдаемый срез

Пять типов страниц — пять ролей.

Во внешней выборке все страницы вернули HTTP 200 и содержали title, description, H1, canonical и JSON-LD.

Шаблон	Title	H1	Description	Canonical	JSON-LD
Главная	56 знаков	56	140	Есть	Есть
Каталог	54 знака	26	150	Есть	Есть
Категория	39 знаков	30	119	Есть	Есть
Портфолио	57 знаков	50	116	Есть	Есть
Блог	54 знака	32	136	Есть	Есть

Наличие тега не гарантирует качество всех 20 120 URL. Следующий шаг — массовая выгрузка дублей, пустых значений, canonical-конфликтов и страниц вне sitemap.

Данным SEO-аудита нужен контекст — Идеальный аудит разделяет наблюдаемое, требующее доступа и приоритет для бизнеса.

04 / Crawl control

Фильтр должен помогать человеку, но не размножать индекс.

robots.txt

User-agent: *
Allow: /
Disallow: /search/
Disallow: /*?currency=
Disallow: /*?sort=
Disallow: /*?filter=

Фасетный UX→чистый canonical→sitemap с полезными URL

Что проверить глубже

Robots.txt ограничивает обход, но не удаляет уже известный URL из индекса. Для каждой группы параметров всё равно нужны проверка canonical, внутренних ссылок и фактического покрытия в Search Console.

05 / Приоритеты

Исправления ранжируются по эффекту и масштабу.

Нажмите на приоритет, чтобы отфильтровать рабочую матрицу.

P0Массовая проверка шаблонов

Дубли title/H1, пустые описания, canonical, 404 и soft 404 на полном URL-наборе.

× 20 120 URL

P0Index Coverage

Сопоставить sitemap с индексом, исключёнными страницами и причинами.

нужен GSC

P1Семантика категорий

Разделить товарные, сценарные и отраслевые интенты без каннибализации.

рост входов

P1Внутренние связи

Связать статьи, кейсы, категории и товары по задаче пользователя.

глубина + crawl

P1Field CWV

Проверить LCP, INP и CLS по типам шаблонов, а не одной главной странице.

нужны CrUX / RUM

P2Контентные кластеры

Развивать статьи вокруг материалов, технологий, поводов и закупочных сценариев.

долгий спрос

07 / Полный протокол

От выборки к доказательному плану работ.

Публичный срез фиксирует масштаб и видимые шаблоны. Полный аудит дополняет его выгрузкой краулера, Google Search Console, Яндекс Вебмастера, полевыми Web Vitals, аналитикой и CRM — без смешивания наблюдений и гипотез.

01 / Crawl

Полная выгрузка URL

Сопоставить sitemap, внутренние ссылки и ответы сервера. Выделить 200, 3xx, 404, soft 404, цепочки, orphan URL и страницы глубже четырёх переходов.

02 / Index

Фактическое покрытие

Сравнить отправленные и индексируемые URL, причины исключения, выбранные поисковиком canonical и динамику по шаблонам каталога.

03 / Templates

Проверка на масштабе

Для категорий, фильтров и карточек измерить дубли Title, Description и H1, пустые поля, конфликтующие canonical, Schema.org и качество изображений.

04 / Demand

Спрос и каннибализация

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

05 / Experience

Скорость и маршрут

Проверить LCP, INP и CLS по шаблонам, мобильные фильтры, внутренний поиск, переход категория → карточка → бриф и успешную отправку формы.

06 / Business

Приоритет по эффекту

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

Разбор по типам страниц

Один чек-лист нельзя механически применить ко всему каталогу.

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

Главная и коммерческие входы

Проверяются ясность предложения, сегменты, география, доказательства и маршрут к каталогу или брифу. Брендовый запрос не заменяет проверку небрандового спроса. Title и H1 должны описывать реальное предложение, а первый экран — сокращать неопределённость, не обещая неподтверждённый результат.

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

Категории и подкатегории

Для каждой категории фиксируются самостоятельный спрос, набор товаров, правила сортировки, уникальный вводный контент и внутренние ссылки. Пустая или почти пустая категория не должна существовать только ради ключевой фразы. Соседние разделы проверяются на пересечение интента и каннибализацию.

Навигация обязана помогать выбору: видимые характеристики, понятные названия и стабильные URL важнее длинного SEO-текста внизу.

Фасеты и комбинации фильтров

Сначала составляется инвентарь параметров и фактических URL. Затем комбинации делятся на UX-фильтры и самостоятельные поисковые посадочные. Индекс открывается только там, где есть отдельный спрос, достаточный ассортимент, уникальный ответ и внутренние входящие ссылки.

Robots.txt управляет обходом, но не гарантирует удаление известного URL из индекса. Поэтому отдельно проверяются canonical, noindex, sitemap и ссылки интерфейса.

Карточки товаров

Проверяются уникальность идентификатора, название, изображения, характеристики, доступность, варианты, breadcrumbs и Product schema. Одинаковые товары с разными параметрами не следует размножать без понятной логики canonical и самостоятельной ценности страницы.

Для снятых позиций заранее выбирается политика: аналог, категория, 404 или сохранение страницы. Ответ не должен зависеть от ручной догадки контент-менеджера.

Кейсы, блог и экспертные материалы

Контент оценивается не количеством знаков, а полнотой ответа, источниками, датой, авторством и связью с коммерческим маршрутом. Статья ведёт к релевантной категории, услуге или кейсу, а не к случайной универсальной форме.

Кейс содержит контекст, решение, доказательства, период результата и ограничение вывода. Без этих слоёв он остаётся галереей экранов.

Поиск, формы и технические состояния

Внутренний поиск проверяется на пустой результат, опечатки, фильтрацию и индексируемость URL. Формы должны иметь клиентскую и серверную валидацию, защиту от спама, понятный статус и подтверждённое событие успешной отправки.

Отдельно проверяются 404, 410, редиректы, цепочки, мобильное меню, пагинация и поведение интерфейса без JavaScript.

Какие данные нужны для полного вывода

Публичный слой: Краулер, sitemap, robots.txt, коды ответа, HTML, шаблоны, внутренняя перелинковка и доступные структурированные данные. Этот слой можно повторить без доступа к компании.
Поисковые панели: Google Search Console и Яндекс Вебмастер подтверждают показы, клики, исключения, выбранные canonical, страницы в индексе и динамику по запросам. Без них покрытие остаётся гипотезой.
Полевые данные: CrUX или собственный RUM показывают реальный LCP, INP и CLS по устройствам и шаблонам. Один лабораторный тест главной нельзя переносить на двадцать тысяч URL.
Аналитика и CRM: GA4, Яндекс Метрика, серверные события и CRM связывают вход, полезное действие, успешную заявку и квалификацию. Персональные данные не передаются в аналитические параметры.
Серверные логи: Логи помогают увидеть обход роботов, частоту запросов, ошибки и ресурсы, на которые расходуется crawl budget. Доступ ограничивается и анализируется безопасно.
Команда и процессы: Интервью с продуктом, контентом, разработкой и продажами объясняют владельцев, ограничения и стоимость исправления. Технически правильная рекомендация без операционного владельца не будет внедрена.

Как превращать аудит в очередь разработки

Нормализовать данные.
Удалить дубли из выгрузок, зафиксировать дату, устройство, регион, шаблон и источник. Все расчёты должны воспроизводиться из приложенных файлов.
Отделить факт от риска.
HTTP 200 — факт. Возможная каннибализация — гипотеза до проверки выдачи и поисковых данных. Формулировка задачи обязана сохранять это различие.
Оценить масштаб и зависимость.
Ошибка одного шаблона может затрагивать тысячи URL. Но высокий масштаб не всегда означает высокий бизнес-эффект: учитываются трафик, продуктовая роль и стоимость исправления.
Собрать пакет приёмки.
Для каждой задачи указываются владелец, изменяемый шаблон, тестовый набор URL, ожидаемый ответ сервера, визуальная проверка, событие аналитики и условие отката.
Повторить измерение.
После релиза проверяются техническая приёмка, переобход, изменение покрытия и бизнес-переходы. Срок зависит от типа изменения; мгновенный рост позиций не обещается.

Как читать приоритет

P0 не означает «самая заметная ошибка»

P0 получает проблема, которая мешает обходу, индексации, корректному измерению или безопасному выпуску других изменений. P1 отвечает за рост и качество маршрута после стабилизации основы. P2 — развитие, которое имеет смысл только при работающем базовом контуре. Приоритет зависит от масштаба шаблона, бизнес-роли страниц, сложности исправления и доступности проверки.

Чего аудит не обещает

Исправление не равно гарантированному росту

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

Как контролировать выпуск

Проверка проходит в три момента

До разработки сохраняется исходная выгрузка. На staging проверяются шаблон, данные, мобильный интерфейс и крайние состояния. После публикации подтверждаются ответы сервера, canonical, sitemap, события и отсутствие регрессий. Затем назначается повторный срез поискового покрытия и бизнес-переходов. Так аудит становится циклом управления, а не разовым PDF-файлом.

Контрольный набор включает несколько URL каждого шаблона, крайние значения характеристик, пустые результаты, снятый товар и страницу с тяжёлым медиа. Если изменение касается генерации, проверяется не только выбранная карточка, но и массовая выборка. Такой подход снижает риск, что локально правильная правка создаст регрессию на тысячах страниц.

CSV / 40 проверокСкачать рабочую таблицу SEO-аудита↓

08 / Вывод

Хороший аудит уменьшает неопределённость.

Для Impulse Media AM уже видна сильная основа: разделённые sitemap, чистые роли страниц, управляемые параметры и связка каталога, портфолио и журнала. Главный следующий шаг — не «добавить ещё SEO-текст», а проверить повторяющиеся шаблоны и реальное покрытие по данным поисковых систем.

Источники и методика

Google: sitemap ↗Google: robots.txt ↗Google: canonical ↗web.dev: Web Vitals ↗