SEO и аналитика
SEO магазина: ТЗ на категории, фильтры, варианты и наличие
Какие требования задать для SEO интернет-магазина: карта индексируемых страниц, фильтры, товарные варианты, снятые товары и контроль релиза.
Определите, какие страницы помогают выбрать товар
ТЗ на SEO интернет-магазина начинается с ассортимента и задач покупателя. Категория, подборка по свойству и карточка варианта отвечают на разные вопросы. Если открыть поиску все адреса, которые способен создать каталог, получится множество похожих страниц. Если закрыть всё, кроме верхних категорий, полезные товарные направления могут остаться без самостоятельного представления.
Соберите карту типов страниц: главная каталога, категория, подкатегория, подборка, товар, вариант, поиск, фильтр, сортировка и пагинация. Для каждого типа укажите задачу человека, источник данных и ожидаемый способ обнаружения. Затем выберите небольшую контрольную выборку реальных адресов. Она станет рабочим приложением к ТЗ и позволит обсуждать правила на конкретных страницах.
Не начинайте с требования написать одинаковое число знаков для всех категорий. Страница должна объяснять различия товаров, помогать сузить выбор и показывать актуальное предложение. Для одной категории полезна таблица совместимости, для другой — правила измерения размера. Сначала определяют информационный пробел, затем формат материала. Объём текста не является самостоятельным доказательством качества.
Составьте матрицу индексируемости
Для каждой группы адресов запишите решение: должна ли она участвовать в поиске, какой адрес считается основным, присутствует ли он в sitemap и откуда на него ведут внутренние ссылки. Это разные настройки, которые должны работать согласованно. Не используйте слово «закрыть» без уточнения механизма и ожидаемого результата: запрет обхода и запрет индексации решают разные задачи.
Google отдельно предупреждает о сложности обхода фасетной навигации: множество сочетаний параметров способно резко увеличить число URL. Используйте официальное руководство как технический ориентир, а перечень полезных сочетаний определяйте по ассортименту и задачам покупателей. Наш практический подход — хранить явный реестр поисковых подборок с владельцем и правилами обновления, а не считать любую комбинацию автоматически полезной.
Учебный пример: «ботинки» — категория, «непромокаемые ботинки» — потенциальная самостоятельная подборка, «ботинки, сортировка по цене, страница семь» — состояние просмотра. Решение о подборке требует проверки предложения и интереса аудитории; приведённые фразы не подтверждают спрос. Если данных Wordstat или Search Console нет, так и запишите. Не подменяйте неизвестный спрос придуманными числами.
Согласуйте товары, варианты и постоянные адреса
Товарная модель влияет на SEO сильнее, чем косметическое изменение заголовка. Определите, являются ли цвет и размер вариантами одной модели или отдельными товарами, какие различия меняют содержание страницы и что происходит при выборе варианта. Покупатель, поисковая система, товарная выгрузка и аналитика должны одинаково понимать, какой объект представлен по адресу.
В руководстве Google по URL магазина описаны постоянные адреса, параметры вариантов и согласованность внутренних ссылок с canonical и sitemap. Для конкретного каталога перенесите эти принципы в таблицу адресных правил. Важно не просто записать образец красивого URL, а перечислить альтернативные пути к тому же содержимому и проверить их фактическое поведение.
Проверьте неприятные случаи: товар доступен из двух категорий, название изменилось, вариант закончился, поставщик прислал новый артикул для прежней модели. Укажите, сохраняется ли адрес, где хранится связь старого и нового объекта, нужен ли переход. Не меняйте URL массово без карты последствий. Любой переход должен вести к действительно соответствующему содержанию, а не отправлять все старые товары на главную магазина.
Опишите наличие и прекращение продажи
В каталоге нужно различать минимум три ситуации: товар временно отсутствует, окончательно снят с продажи или не загрузился из источника. Последняя ситуация является ошибкой данных, а не коммерческим решением. Если система превращает пустую выгрузку в массовое удаление карточек, технический сбой может изменить поисковое представление всего магазина.
Для временного отсутствия согласуйте содержание карточки, доступные действия и порядок обновления. Для снятого товара оцените, сохраняется ли польза страницы: инструкция, характеристики, совместимые замены. Если страница удаляется, задайте корректное поведение адреса и обновление внутренних ссылок. Универсальная команда «всё отсутствующее скрывать» не учитывает различий между сезонным ожиданием и окончательным прекращением продаж.
Добавьте защитный сценарий для резкого изменения ассортимента. Например, перед применением выгрузки система показывает число отключаемых товаров и требует согласованного действия при превышении заданного проектом порога. Число порога определяют по истории каталога, а не берут из случайной статьи. Приёмка должна подтвердить, что ошибочный пустой файл не выдаётся за корректное обновление наличия.
Задайте полезный состав категории и карточки
Для категории перечислите элементы, которые помогают выбору: понятное название, описание границ подборки, релевантные фильтры, товары, условия покупки и переходы к соседним задачам. Порядок блоков зависит от сценария. Если человек приходит за совместимой деталью, сведения о совместимости важнее длинного вводного текста о преимуществах интернет-покупок.
Для товара определите обязательные данные и источник каждого поля: название, характеристики, изображения, цена, наличие, варианты и условия заказа. Отдельно укажите, какие сведения редактирует контент-команда, а какие приходят из учётной системы. Автоматическое обновление цены не должно стирать подготовленную инструкцию. Пустые или противоречащие поля должны попадать в отчёт, а не заполняться вымышленным описанием.
Шаблоны title и description полезны как страховка, но требуют проверки на реальном ассортименте. Длинное название бренда, одинаковые модели разных производителей и товар без свойства способны сломать аккуратный пример. Возьмите короткие, длинные и неполные записи, проверьте уникальность и естественность фраз. Если редактор меняет текст вручную, в ТЗ нужен приоритет ручной версии при следующем импорте.
Включите навигацию и измерение в требования
Страницы не должны существовать только в файле sitemap. Опишите путь от верхней категории к подкатегории и товару, смысл хлебных крошек и связи с полезными инструкциями. Проверяйте не только наличие ссылки в исходном коде, но и её понятность человеку. Блок из десятков похожих ключевых фраз редко помогает выбрать следующий шаг.
Отдельно проверьте пагинацию, загрузку дополнительных товаров и возвращение назад. Пользователь должен восстановить контекст выбора, а важные товары — оставаться обнаруживаемыми согласованным способом. Для мобильного интерфейса включите в приёмку открытый фильтр, отсутствие результата и смену сортировки. SEO-требования не освобождают страницу от необходимости нормально работать при выборе и покупке.
Измерение разделите на техническое состояние, поисковые показы и действия посетителей. Появление страницы в индексе, просмотр карточки и оплаченный заказ — разные события. Если аналитика не подключена или история недоступна, это ограничение отчёта. Не записывайте неизвестную конверсию как ноль и не выдавайте рост просмотров за рост заявок. Для каждого показателя задайте источник и период сравнения.
Примите правила на контрольной выборке
Для каждой строки матрицы подготовьте тест: адрес, статус HTTP, title, H1, canonical, robots, внутренние ссылки и присутствие в sitemap. Добавьте проверку структурированных данных там, где они реализованы, и сравнение с видимым содержанием. Разметка цены не должна показывать старую сумму, а описание наличия — противоречить карточке.
Контрольная выборка должна включать разные типы товаров и проблемные состояния. Проверьте категорию с одной позицией, пустую категорию, длинную цепочку фильтров, несуществующий вариант, снятый товар и адрес с рекламной меткой. Сначала зафиксируйте ожидаемый результат, затем измерьте фактический. Иначе текущая реализация незаметно станет критерием правильности самой себя.
После выпуска повторите проверки на рабочем домене и сравните sitemap с утверждённым реестром. Индексация не обновляется мгновенно, поэтому техническое завершение релиза и наблюдение за поиском имеют разные сроки. Назначьте ответственного за последующий контроль. Он должен знать, какое изменение считается нормальным ожиданием обхода, а какое требует немедленного исправления.
Подготовьте пакет требований для оценки
Передайте исполнителю карту каталога, матрицу индексируемости, правила вариантов и наличия, образцы товарных данных и контрольные URL. Приложите доступную поисковую статистику с периодом и регионом, список технических ограничений и владельцев изменений. Скачиваемый бриф в источниках помогает собрать эти решения в одном документе и выделить вопросы, на которые пока нет ответа.
Для первого этапа выберите ограниченную группу категорий, достаточно разнообразную для проверки правил. Не начинайте массовую генерацию посадочных страниц до подтверждения модели. Если на пилоте обнаружено, что варианты и остатки определяются неверно, расширение числа страниц только увеличит стоимость исправления. Рабочее правило лучше проверить на десятках осмысленных примеров, чем утвердить по одному красивому макету.
Результат SEO-подготовки — согласованная система полезных страниц и проверяемый выпуск. Позиции, трафик и продажи оцениваются отдельно и не гарантируются самим фактом составления ТЗ. Материалы о категориях, фильтрах и canonical помогут углубить отдельные решения; услуга SEO магазина позволяет обсудить ваш ассортимент и данные. Так оценка начинается с фактов проекта, а не с одинакового пакета обещаний для любого каталога.
Источники
- Designing a URL structure for ecommerce websites
Google Search Central / доступ 2026-10-12
Первичный источник для соответствующей технической темы. Структура брифа и учебные проверки разработаны редакцией; возможности конкретной системы проверяются перед внедрением.
- Managing crawling of faceted navigation URLs
Google / доступ 2026-10-12
Первичный источник для соответствующей технической темы. Структура брифа и учебные проверки разработаны редакцией; возможности конкретной системы проверяются перед внедрением.
- Скачать заполняемый бриф / ТЗ (.txt)
Малевич — практическое приложение / доступ 2026-10-12
Сохраните файл и заполните исходные данные, решения и критерии приёмки своего проекта.
FAQ
Нужно ли открывать для индексации каждый фильтр?
Нет. Отдельную поисковую страницу имеет смысл создавать при самостоятельной задаче покупателя, достаточном ассортименте и полезном содержании. Комбинации сортировки, служебных параметров и случайных значений не становятся посадочными страницами только потому, что у них появился URL.
Удалять ли карточку временно отсутствующего товара?
Универсального решения нет. Если возвращение ожидается и страница остаётся полезной, она может сообщать о наличии и предлагать релевантные альтернативы. Для окончательно снятого товара нужен отдельный сценарий. В ТЗ различайте временное отсутствие, прекращение продажи и техническую ошибку выгрузки.
Гарантирует ли прохождение технической приёмки позиции в поиске?
Нет. Приёмка подтверждает реализацию согласованных требований и отсутствие обнаруженных технических препятствий. Индексацию и видимость оценивают после обхода поиском, а спрос и продажи зависят также от предложения, ассортимента и конкуренции. Срок появления результата не следует подменять обещанием места в выдаче.
