Дизайн-система влияет на SEO всякий раз, когда компонент создаёт ссылку, заголовок, изображение, скрытый контент, пагинацию, метаданные или поведение загрузки. Поэтому у компонента нужен SEO-контракт: что он выводит в исходный HTML, какие URL создаёт, как работает без JavaScript, какие состояния допустимы и что проверяется перед релизом. Такой контракт превращает SEO из финальной ручной проверки в часть проектирования, Storybook, CI и приёмки.
Какие компоненты критичны для поиска
В первую очередь контролируйте компоненты, которые повторяются на тысячах страниц:
навигацию, хлебные крошки и ссылки в карточках;
заголовки и текстовые блоки;
изображения первого экрана и галереи;
листинги, фильтры, сортировки и пагинацию;
табы, аккордеоны, модальные окна и бесконечную прокрутку;
шаблоны Title, Description, canonical и robots;
структурированные данные;
формы и сообщения об ошибках.
Локальная ошибка в таком компоненте масштабируется вместе с числом его использований. Поэтому проверяется не только внешний вид, но и HTML-контракт.
SEO-контракт компонента
Для каждого критичного компонента зафиксируйте:
назначение и страницы использования;
обязательные входные данные;
семантический HTML и порядок заголовков;
правила формирования URL и ссылок;
исходное состояние до выполнения JavaScript;
состояния загрузки, пустого результата и ошибки;
требования к изображениям и размерам контейнера;
влияние на LCP, INP и CLS;
события аналитики и исключение персональных данных;
автоматические и ручные проверки;
владельца изменения и условие отката.
Контракт хранится рядом с компонентом и обновляется вместе с ним. Текст «SEO учтено» без проверяемых условий не является контрактом.
Компоненты листинга и пагинации
Карточка должна содержать обычную ссылку <a href> на устойчивый URL. Не стоит делать единственным способом перехода обработчик клика на контейнере. Изображение получает корректные размеры и alt по смыслу, а элемент первого экрана не должен лениво загружаться только из-за общего правила компонента.
Пагинация должна создавать отдельные доступные URL и последовательные ссылки между страницами. Бесконечная прокрутка может дополнять интерфейс, но не должна быть единственным способом обнаружить следующие товары. Фильтры обязаны разделять пользовательское состояние и индексируемые посадочные: дизайн-компонент не должен самовольно создавать бесконечные комбинации адресов.
Контроль в Storybook и CI
В Storybook нужны состояния с реальным объёмом текста: короткий и длинный заголовок, отсутствие изображения, ошибка API, пустой список, медленная загрузка, несколько страниц пагинации. Проверяется DOM, фокус, клавиатурная навигация, размеры медиа и устойчивость макета.
В CI можно проверять наличие обязательных атрибутов, валидность ссылок, единственность H1 в шаблоне, допустимую вложенность заголовков, canonical, robots, JSON-LD и отсутствие критичного контента только после взаимодействия. Автотест не решает, полезен ли текст и правильно ли выбран интент, поэтому редакционная и SEO-приёмка остаются отдельным шагом.
Матрица сигналов и реакции
| Сигнал | Условие | Приоритет | Ответственный | Срок реакции | Диагностика | Критерий закрытия | Откат |
|---|---|---|---|---|---|---|---|
| Crawl | Целевой раздел недоступен по ссылкам | P0 | разработчик + SEO | до продолжения релиза | DOM, inlinks, robots, маршруты | раздел снова обходится из навигации | вернуть предыдущую навигацию |
| Index | Массовый noindex или неверный canonical | P0 | разработчик + SEO | немедленно | исходный HTML и HTTP-заголовки | директива соответствует матрице шаблонов | откатить шаблон метаданных |
| HTTP | Целевые страницы дают 4xx/5xx | P0 | backend/DevOps | немедленно | логи, маршрутизация, выборка URL | целевые URL стабильно отвечают 200 | вернуть предыдущий маршрут |
| On-page | Пропал H1 или изменён порядок заголовков | P1 | frontend + редактор | до выпуска | DOM и визуальная проверка | заголовки соответствуют контракту | вернуть предыдущую разметку |
| Rendering | Текст или ссылка появляются только после ошибки JS | P0 | frontend | немедленно | исходный и rendered HTML, консоль | ключевой контент доступен и без сбоя JS | отключить проблемный вариант |
| LCP | Первый экран стал загружаться заметно позже в контрольном тесте | P1 | frontend | до масштабирования | LCP-элемент, сеть, приоритет ресурса | причина устранена без потери контента | вернуть предыдущий ресурс/компонент |
| INP | Ключевое действие блокируется долгой задачей | P1 | frontend | до масштабирования | профилирование обработчика | действие выполняется без блокировки интерфейса | отключить новую обработку |
| CLS | Компонент сдвигает уже показанный контент | P1 | frontend + дизайнер | до выпуска | запись макета, размеры контейнера | место зарезервировано во всех состояниях | вернуть стабильный контейнер |
| Данные | Аналитическое событие пропало или дублируется | P1 | аналитик + разработчик | до анализа эффекта | payload, триггеры, журнал событий | одно событие на фактическое действие | вернуть предыдущую схему событий |
Сроки здесь описывают порядок релизной реакции, а не статистику проекта. Числовые SLA команда устанавливает только после согласования своей поддержки и критичности шаблонов.
Как выпускать изменение компонента
Сначала определите страницы и сценарии, которые затрагивает новая версия. Затем проверьте компонент изолированно, соберите тестовый шаблон и выполните crawl/DOM-проверку. На ограниченном выпуске сравните HTTP, метаданные, ссылки, рендеринг, основные действия и показатели производительности. Масштабируйте только после прохождения гейта.
Если после релиза карточка перестала выводить обычный href, порядок действий такой: остановить расширение релиза, подтвердить проблему в исходном HTML, проверить затронутые шаблоны, вернуть рабочую версию ссылки, повторить crawl и только затем закрыть инцидент. Это сценарий приёмки, а не описание произошедшего проекта.
QA-гейт перед публикацией
URL и коды ответа соответствуют карте шаблонов;
важные ссылки присутствуют в исходном HTML;
H1 и уровни H2–H3 не зависят от оформления;
canonical и robots формируются из правильного источника;
ключевой текст доступен при ошибке необязательного JavaScript;
изображения имеют размеры и не вызывают сдвиг;
состояния загрузки и пустого результата не создают ложные страницы;
аналитические события не дублируются и не содержат лишних данных;
подготовлен точный откат компонента.
Частые ошибки
Самая частая ошибка — считать компонент только визуальным объектом. Вторая — тестировать один идеальный набор данных. Третья — выпускать изменение сразу на всех шаблонах. Четвёртая — проверять только отрисованный DOM и не видеть, что исходный HTML потерял ссылку или метаданные.
Итог
Поисково-безопасная дизайн-система задаёт не набор запретов, а проверяемый контракт. Команда знает, что компонент обязан выводить, кто реагирует на отклонение, как подтвердить исправление и какой вариант вернуть при неудачном релизе.
Получите бесплатный аудит и стратегию роста
Изучим сайт, покажем точки роста и подготовим прогноз до квалифицированных лидов и оборота из SEO/GEO.