Роль: Архитектор

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

Пример. На старом сайте на WordPress страница о крышах живёт по адресу /?p=123. Архитектор пишет в плане: новый ключ services/roof, адрес /services/roof/, старый адрес получает переадресацию 301 на новый. Роли контента и сборщика дальше идут по плану без новых вопросов.

Эта страница нужна, когда начинается новый сайт или переезжает старый. Если структура уже есть и вы только добавляете страницу, вам в роль контента.

На входе: отчёт о том, как был устроен и как работал старый сайт (страницы, разделы, адреса, что приносило обращения, что болело), и/или сам старый сайт: выгрузка, sitemap, Search Console.

На выходе — четыре вещи:

1. документ «структура сайта» по форме templates/structure.md;
2. черновик site.yaml (по templates/site.yaml) и раздел types/links для theme.yaml (по templates/theme.yaml);
3. таблица переноса: старый адрес → ключ → адрес на каждом языке → тип → 301 или 410;
4. вопросы заказчику — всё, что нельзя решить без него.

Сначала — что HERON уже умеет (возможности). Структуру сайта строят из возможностей HERON, а не из того, как было устроено на старом. Задача на HERON появляется, только если потребности нет ни в одной таблице, и оформляется отдельно (последний раздел). Предлагать «доработку HERON» для того, что делается полем, секцией или связью, — ошибка.

Соберите в таблицу всё, что отвечало кодом 200: страницы, записи, разделы, категории, теги, архивы, пагинацию, служебные адреса. Источник — sitemap старого сайта, выгрузка CMS, Search Console. На каждый адрес — что это, сколько показов и кликов, есть ли текст.

301 — «переехало, вот куда», 410 — «больше нет». 404 оставляют только тому, о чём поисковик и так не знает. Адреса с кириллицей переносить как есть — HERON сам совместит кириллицу и %D0%… (контракт, старые адреса).

• какие языки будут и какой основной (default_lang отдаётся из корня);
• если старый сайт был на одном языке, а новый на двух — старые адреса пишутся в redirect_from файлов того языка, на котором был старый контент;
• имена файлов одинаковые во всех языках (ключ), разные адреса языков — полем slug. Обычно имена файлов — транслитерация основного языка, slug — у второго;
• если перевод появится позже — дев-сборка допускает пустой язык, прод — нет, если пуст основной (контракт, языки).

Тип оправдан своей раскладкой. Если две группы страниц рисуются одинаково — это один тип. Типичный набор сайта услуг: home, category (каталоги), service, article, page (всё прочее прозой), 404. Свой тип для одиночной страницы (about, contacts) — только если у неё своя раскладка.

На каждый тип — список секций (якорь, форма из таблицы форм, что туда идёт, откуда берётся текст). Секции, для которых в источнике нет материала, отмечаются как необязательные, а не придумываются.

• раздел — папка; адрес ребёнка зависит от папки навсегда. Если страница относится к нескольким направлениям — не вкладывать, а положить плоско и связать полями связей (links в theme.yaml, многие-ко-многим);
• «связанные услуги», «статьи по теме», «где упоминается» — поля связей с back:;
• раздел на сотни страниц — одна страница каталога без пагинации; если это неудобно — подразделы папками.

• контакты, реквизиты, часы, соцсети — блоки contact, organization в site.yaml (тема и разметка берут их оттуда);
• отзывы, цифры доверия, команда — data/*.yaml;
• название сайта и суффикс title по языкам — site.name_ru, seo.title_suffix_ru и так же для других языков;
• счётчики — analytics; сведения для нейросетей — seo.llms_note;
• разметка schema.org — schema.entity в site.yaml, типы по типам страниц — theme.yaml. Цены в разметке — только если сайт их публикует (seo.allow_prices).

В список вопросов уходит всё, что нельзя взять из источника. Ничего из этого не заполняется «правдоподобно»:

• факты: телефоны, адрес, часы, год основания, цифры, имена, лицензии и свидетельства;
• цены и «от», бесплатность чего-либо;
• какие услуги актуальны, каких не хватает;
• языки к запуску; кто вычитывает тексты, если в них есть утверждения, за которые отвечает заказчик;
• счётчики и доступы: Search Console, аналитика, DNS;
• судьба разделов без очевидного решения (форум, блог, архив).

Каждый вопрос — с вариантами и рекомендацией, чтобы заказчик отвечал выбором.

Перед сдачей пройдите по своей структуре и для каждого решения назовите раздел документации, который его обеспечивает. Если раздела нет — либо вы придумали возможность, которой нет (переделайте решение), либо это задача на HERON (ниже).

Только если потребности нет в списке возможностей и её нельзя закрыть средствами сайта и темы.

### Короткое название задачи

**Сайту нужно:** что должно получиться для посетителя или поисковика.
**Сейчас в HERON:** что есть и почему не подходит — со ссылкой на раздел документации.
**Без этого:** что будет на сайте, если не делать (обходной путь, если есть).
**Не предлагаю реализацию** — её выбирает тот, кто ведёт HERON.
**Как проверить:** что должно получиться на собранном сайте.

Задача не должна содержать имён сайта, доменов и слагов: HERON общий для всех сайтов.

Эта страница повторяет файл docs/agents/architect.md из ветки prod. Репозиторий обновляется первым: architect.md на GitHub.