Дизайн не должен выбирать структуру за бизнес
Частая последовательность выглядит так: сначала красивый главный экран, затем «добавим услуги», потом копирайтер ищет ключи, а после релиза команда пытается объяснить поиску, какой URL за что отвечает. Проблема здесь не в дизайне. Он просто получает слишком поздние вводные: кто покупатель, какие вопросы он решает, что компания готова доказать и какие страницы нужны для этого.
До макетов не надо пытаться написать весь сайт. Достаточно согласовать модель: какие задачи покрываем, какие страницы существуют, что является источником каждого важного факта и как команда убедится, что после релиза всё доступно. Google рекомендует логичные адреса, понятную структуру и доступный для обхода контент; в JavaScript-проектах отдельно важно проверить, что нужный материал попадает в отрисованный HTML.
Семь решений, которые должны появиться до первого экрана
| Решение | Что фиксируем до дизайна | Что ломается, если отложить |
|---|---|---|
| 1. Цель и роли | Для кого сайт, какие решения он помогает принять, кто отвечает за факт и согласование. | Главная страница пытается продать всем и не отвечает никому. |
| 2. Спрос и интенты | Группы задач, а не список слов: услуга, сравнение, внедрение, доверие, поддержка. | Появляются одинаковые страницы или важный спрос остаётся без URL. |
| 3. Архитектура | Карта URL, иерархия, связи между типами страниц и правила именования. | После запуска приходится менять меню, хлебные крошки и десятки ссылок. |
| 4. Паспорта страниц | Задача URL, основной ответ, CTA, факты, ограничения, доказательства и владелец обновления. | Тексты становятся набором рекламных блоков без роли и источников. |
| 5. Требования к шаблонам | Место для title, H1, описания, основного контента, ссылок, автора, даты и доступной формы. | Шаблон красив, но нужные данные нельзя показать или поддерживать. |
| 6. Технический контракт | HTTPS, статус-коды, canonical, robots, sitemap, редиректы, метаданные, мобильная версия и контроль ошибок. | Релиз начинается с индексационных регрессий и ручных исправлений. |
| 7. Приёмка | Что проверить до и после выкладки: URL, HTML, ссылки, аналитика, формы, индексация, rollback. | «Готово» означает только то, что страница открылась у разработчика. |
Как соединить SEO и требования к AI-поиску без отдельного «AI-дизайна»
У AI-интерфейса нет единого официального чек-листа, который гарантирует упоминание. Поэтому безопаснее проектировать вещи, которые имеют смысл для пользователя независимо от интерфейса: один понятный ответ на одной странице, открыто названная компания и услуга, видимые условия, автор или ответственный за материал, дата, ссылки на первичные источники и честные границы.
Структурированные данные могут дать поиску явные подсказки о смысле видимой страницы, но они должны соответствовать её фактическому содержанию. Google рекомендует JSON-LD и прямо указывает, что корректная разметка лишь делает страницу подходящей для расширенного показа, а не гарантирует его. Поэтому не надо рисовать скрытый JSON-LD «для нейросетей»: сначала должен быть полезный и проверяемый интерфейс для человека.
Минимальный комплект до передачи в дизайн
- Карта сайта. Список будущих URL, их цель и связь с другими страницами. Это не меню из красивых названий, а рабочая архитектура.
- Семантические кластеры. Для каждой группы спроса — одна основная страница и правила, когда создавать дочернюю, а когда не создавать дубликат.
- Паспорта ключевых страниц. Вопрос клиента, краткий ответ, доказательства, CTA, ограничения и требования к шаблону.
- Реестр фактов. Кто утвердил цену, срок, характеристику или интеграцию; где первоисточник; когда пересмотреть информацию.
- Контракт с разработкой. Каким должен быть HTML, как строятся ссылки и URL, где управляются метаданные и редиректы, как работает preview.
- План запуска. Pre-release и post-release проверки, ответственные, критерии отката и способ зафиксировать найденную проблему.
Проверка шаблонов: короткий разговор дизайнера, SEO и разработки
Для каждого типа страницы задайте одни и те же вопросы: видит ли пользователь основную информацию без препятствий; есть ли у URL понятное назначение; сможет ли редактор обновить факт без правки кода; есть ли место для источника, автора и даты; не ломается ли мобильная версия; будет ли ссылка обычным <a href>, а не только обработчиком JavaScript.
Это не попытка навязать дизайн. Напротив, такая рамка освобождает дизайнера от угадывания бизнес-логики. А разработчик получает не абстрактное «сделайте SEO-дружелюбно», а проверяемые критерии. О типовых технических проверках после релиза читайте в чек-листе технической готовности.
Что происходит после макетов
После дизайна работа не заканчивается: команда проверяет, что карта URL и обязательные блоки пережили вёрстку, а контент не отложен до бесконечности. Перед production нужен preview: затронутые страницы, отличия от согласованной структуры, цена внешних сервисов при наличии, риск и ответственный. Только после подтверждения запускается публикация или изменение инфраструктуры.
После выкладки полезно проверить ответ сервера, canonical, robots, sitemap, ссылки, отображение контента на мобильном экране, формы и фактический HTML. Для сайтов на JavaScript Google советует смотреть рендеринг и ошибки через инструменты Search Console, а не предполагать, что бот увидит то же, что разработчик в локальном браузере.
Чего не обещает этот процесс
- он не гарантирует позицию, трафик, лиды или упоминание в конкретном AI-ответе;
- он не заменяет продуктовую стратегию и интервью с клиентами;
- он не даёт агенту права самостоятельно опубликовать сайт, изменить DNS или потратить бюджет;
- он не требует заполнить все разделы до запуска, но не позволяет отложить архитектуру и технический контракт.
С чего начать
Если новый сайт или редизайн ещё до макетов, полезен отдельный этап SEO для нового сайта: семантика, структура, ТЗ на шаблоны и чек-лист запуска. Если сначала нужно разобрать только спрос и карту страниц, подойдёт семантика и архитектура. После релиза техническую часть можно принять по техническому SEO-аудиту.
Первичные источники
- Google Search Central: crawling and indexing — структура URL, sitemap, canonical, robots и управление доступностью контента для обхода.
- Google Search Central: JavaScript SEO basics — стадии crawl, render, index и ограничения клиентского рендеринга.
- Google Search Central: crawlable links — требования к доступным ссылкам и понятному anchor text.
- Google Search Central: structured data — точная, видимая разметка и отсутствие гарантии расширенного показа.
Частые вопросы
Нужно ли собирать семантику до дизайна?
Да. Не нужно подгонять макет под каждую фразу, но до дизайна должны быть понятны задачи пользователя, типы будущих страниц, связи между ними и коммерческие доказательства. Иначе после релиза придётся менять не тексты, а архитектуру и шаблоны.
Нужен ли отдельный дизайн для AI-поиска?
Не нужен отдельный декоративный дизайн. Нужны понятные человеку страницы: точные сущности, видимые факты и источники, логическая навигация, доступный HTML и отсутствие обещаний, которых компания не может подтвердить. Это полезно и без AI-интерфейсов.
Можно ли заполнить сайт после запуска?
Наполнение можно делать поэтапно, но нельзя откладывать решения о типах страниц, URL, шаблонах, редиректах, метаданных и проверке индексации. Эти основания дешевле согласовать до кода, чем исправлять на уже работающем сайте.