Фабрика лендингов на Claude Design + Claude Code: дизайн, статика, SEO, A/B и автодеплой из коробки

Полное руководство для вебмастеров: как собрать систему, которая доводит лендинг от брифа до задеплоенной, индексируемой и измеримой страницы — воспроизводимо, без «как повезёт с промптом» и без ручной возни с мета-тегами.

Зачем это вебмастеру

Если вы зарабатываете на сайтах — арбитраж, лидген, партнёрки, продажа услуг, контент-проекты — лендинги вы пересобираете постоянно. Новая гипотеза — новая посадочная. Новая кампания — ещё одна. Плюс блог, плюс страницы под отдельные ключи. И каждый раз повторяется одна и та же рутина:

• не забыть <title>, meta description и Open Graph;
• прикрутить аналитику и не сломать её при следующей правке;
• не угробить индексацию дублями и неправильными canonical;
• выкатить, проверить превью в соцсетях, проверить скорость.

Любой AI-ассистент заметно ускоряет эту работу. Но если вы просто «промптите с нуля» каждый раз, качество прыгает: сегодня модель аккуратно добавила canonical и JSON-LD, завтра забыла. Результат зависит от того, насколько удачно вы сформулировали запрос именно в этот раз. На потоке из десятков лендингов это превращается в лотерею, а ошибки в SEO-обвязке стоят денег и трафика.

Решение — перестать переизобретать процесс и зафиксировать его как систему. В этом гайде разберём, как построить такую систему на двух инструментах Anthropic, которые отлично дополняют друг друга:

• Claude Design — визуальная фаза: исследуем внешний вид, собираем макет и варианты на канвасе через диалог;
• Claude Code (через механизм skills) — продакшн-фаза: превращаем дизайн в самодостаточный статический HTML по жёсткому контракту, прогоняем валидатором, версионируем, тестируем и деплоим.

К концу статьи у вас будет понимание, как собрать репозиторий-шаблон, набор скиллов, контракт с автопроверкой, CI с автодеплоем по веткам, A/B без клоакинга и журнал изменений. Сначала — польза и архитектура, теория по ходу.

Идея системы: конвейер из двух инструментов

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

1. Бриф. Единый формат входных данных: что за продукт, для кого, оффер, ключевой экран, целевое действие, тон.
2. Визуальная фаза (Claude Design). Из брифа исследуем направление: композиция первого экрана, типографика, цвет, структура блоков. Здесь дёшево перебрать несколько вариантов оформления.
3. Хендофф в Claude Code. Дизайн уходит в код. На этом шаге включается главная защита — контракт статического лендинга.
4. Продакшн-фаза (Claude Code skills). Скиллы наполняют нейтральный скелет контентом по контракту, прогоняют валидатор, фиксируют изменения в журнале.
5. Деплой. CI выкатывает страницу по ветке: прод индексируется, staging и превью — нет.
6. Измерение. Аналитика и A/B на одном URL: смотрим, что реально конвертит.

Ключевая интуиция, которую стоит запомнить сразу: Claude Design отвечает за то, как лендинг выглядит, а Claude Code — за то, что в итоге уезжает на прод. Внешний вид — это исследование, а продакшн-артефакт — это инженерная задача с инвариантами, проверками и пайплайном. Разделив их, вы получаете и красоту, и предсказуемость.

Что такое Claude Code skills

Skill — это папка с файлом SKILL.md (инструкция плюс описание «когда применять») и, опционально, вспомогательными файлами: справочниками, шаблонами, скриптами. Когда вы вызываете скилл по имени, ассистент подхватывает эти инструкции и выполняет задачу строго по ним.

Это способ превратить разовый удачный промпт в воспроизводимый процесс. Не «как повезёт сегодня», а по контракту, с самопроверкой. По сути скилл — это зафиксированная стандартная операционная процедура для ассистента: правила вынесены в файлы, лежат в репозитории рядом с кодом и CI, версионируются в git.

В нашей системе будет пять скиллов:

Скиллы — это «правила и проверки», то, что делает результат предсказуемым. Дизайн в эту схему приходит отдельным инструментом — и здесь на сцену выходит Claude Design.

Что такое Claude Design и какова его роль

Claude Design — продукт Anthropic Labs, запущенный в исследовательском превью в апреле 2026 года и работающий на vision-модели Claude Opus 4.7. Это рабочее пространство с холстом: слева чат, справа канвас. Вы описываете, что нужно, получаете первую версию, а дальше дорабатываете её через сообщения в чате, инлайн-комментарии, прямые правки и слайдеры-регуляторы. Инструмент создаёт визуальные артефакты — прототипы, посадочные страницы, лендинги, дашборды, презентации, one-pager'ы.

Для вебмастера в этой системе важны три его свойства:

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

Во-вторых, он понимает ваш бренд. Claude Design умеет читать репозиторий, чтобы подхватить вашу дизайн-систему, и в командных тарифах автоматически наследует оформление организации. При этом он не редактирует ваш код и не выполняет команды — он работает на холсте, а не в проде. Это ровно то разделение ответственности, которое нам нужно.

В-третьих — и это ключевое для интеграции — у него есть встроенный хендофф в Claude Code. Когда дизайн готов, через меню экспорта Claude Design упаковывает дизайн-намерение в бандл, который Claude Code (локальный агент или веб-версия) подхватывает одной инструкцией. Помимо этого есть экспорт в Canva, PDF, PPTX, standalone-HTML и шеринг по ссылке — но для нашей фабрики лендингов важен именно мост в Claude Code.

Важная оговорка про роли. Claude Design умеет отдавать готовый HTML. Но для SEO-лендинга мы не выкатываем его экспорт «как есть». Дизайн из Claude Design — это источник внешнего вида и структуры, а финальный продакшн-файл всё равно проходит через контракт и валидатор на стороне Claude Code. Так мы получаем красивый макет без потери индексации, скорости и предсказуемости. Почему это так важно — в следующих разделах.

Принципиальные решения, на которых держится система

Это несущая стена всей конструкции. Четыре решения, каждое из которых снимает конкретную боль вебмастера.

Решение №1: лендинг — это статический HTML, а не SPA

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

<div id="root"></div>

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

Поэтому в системе фиксируется жёсткий инвариант: лендинг — самодостаточный статический HTML-файл, контент лежит в разметке, ноль JS на критическом пути. CSS и минимальный vanilla-JS — инлайн. Никакого клиентского рендеринга контента, никаких внешних CSS/JS-блокировщиков.

Что это даёт:

• контент виден без JavaScript → страница индексируется и корректно превьюится;
• страница грузится мгновенно — на критическом пути нет фреймворка;
• деплой тривиален: что в репозитории, то и на проде, без шага сборки.

Этот инвариант — не пожелание, а то, что не имеет права нарушить ни один скилл. Он выносится в отдельную запись архитектурного решения (ADR) и проверяется автоматически.

Именно здесь окупается разделение с Claude Design. Дизайн-инструмент склонен генерировать богатую интерактивную верстку с внешними зависимостями. Это прекрасно для прототипа — и недопустимо для SEO-лендинга. Контракт на стороне Claude Code «приземляет» дизайн в статику.

Решение №2: контракт + валидатор вместо «повезёт с промптом»

Главная проблема генерации через LLM — недетерминированность. Сегодня модель добавит canonical и JSON-LD, завтра забудет. Лечится это не «более длинным промптом», а контрактом и проверкой.

В скилле new-landing три части:

1. landing-contract.md — что обязан содержать любой лендинг: <title> и meta description в разумных пределах, canonical, Open Graph и Twitter Card, JSON-LD, ровно один <h1>, аналитика под guard, и — никаких внешних CSS/JS на критическом пути.
2. landing-skeleton.html — нейтральный скелет, уже соответствующий контракту: системные шрифты, инлайн-стили, полный SEO-блок. Модель наполняет его контентом, а не выдумывает структуру с нуля.
3. check_landing.py — валидатор. Прогоняется по готовому файлу и возвращает ненулевой код, если контракт нарушен.

Кусок проверки инварианта — буквально несколько строк, но именно они ловят самую коварную ошибку:

# никаких внешних CSS/JS на критическом пути — иначе ломается смысл статики

ext_scripts = re.findall(r'<script\b[^>]*\bsrc=', html, re.I)

ext_css = re.findall(r'<link\b[^>]*rel=["\']stylesheet["\']', html, re.I)

if ext_scripts:

err("внешние <script src> на критпути — инвариант: JS инлайн")

if ext_css:

err("внешний <link rel=stylesheet> — инвариант: CSS инлайн")

Показательный момент: если прогнать такой валидатор по типичному «старому» лендингу, он почти наверняка сразу найдёт нарушение — например, render-blocking подгрузку Google Fonts через <link>. Инструмент окупается на первом же запуске, поймав то, что годами делалось руками.

Этот же валидатор — страховка на стыке с Claude Design: что бы ни принёс дизайн-хендофф, на выходе файл либо соответствует контракту, либо CI его не пропустит.

Вход у генератора один — бриф в едином формате. Чтобы собирать его было удобно даже не-разработчику, держите рядом промпт-интервьюер: вставляете его в любую нейросеть, она проводит интервью и отдаёт готовый бриф. Один формат — два входа: либо скилл спрашивает сам, либо бриф приходит снаружи.

Решение №3: ветка = окружение, ветка = превью

Деплой делаем branch-routed через GitHub Actions. Логика максимально простая:

То есть любая ветка автоматически поднимает превью по своему URL. Удобно показать заказчику или партнёру, обкатать гипотезу, не трогая прод. Под капотом — обратный прокси (например, Traefik) перед nginx-контейнерами; превью-папка чистится отдельным workflow, когда ветку удаляют.

Решение №4: индексируется только продакшн

В поиске должен быть только прод. Staging и все превью отдают X-Robots-Tag: noindex на уровне веб-сервера — это надёжнее мета-тега и закрывает разом и staging, и все превью (они в одном контейнере). Иначе вы сами создаёте себе дубли в выдаче и режете собственный трафик.

Пошагово: собираем систему сами

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

Шаг 1. Подготовка

Что понадобится:

• доступ к Claude Code и к Claude Design (последний доступен на тарифах Pro, Max, Team, Enterprise; в Enterprise его включает админ организации);
• репозиторий на GitHub;
• домен и сервер (или хотя бы staging-домен) под автодеплой;
• базовое знание git.

Заведите структуру папок: каталог под скиллы (каждый — отдельная папка со своим SKILL.md), папку с шаблонами (скелет, контракт, валидатор), и конфигурацию CI.

Шаг 2. Единый бриф и промпт-интервьюер

Опишите формат брифа: продукт, аудитория, оффер и УТП, ключевой экран, целевое действие (CTA), обязательные блоки, тон и ограничения по бренду. Рядом положите промпт-интервьюер — текст, который, будучи вставленным в любую нейросеть, проводит мини-интервью и выдаёт бриф в нужном формате. Это позволит запускать процесс даже силами не-технического коллеги.

Шаг 3. Визуальная фаза в Claude Design

Передайте бриф в Claude Design и опишите задачу: посадочная под такой-то оффер, такой-то первый экран, такое-то целевое действие. Получите первую версию на канвасе и доработайте её диалогом:

• сравните 2–3 направления композиции первого экрана;
• отрегулируйте типографику, цвет, плотность блоков комментариями и слайдерами;
• если у вас есть бренд-репозиторий, дайте Claude Design прочитать его, чтобы оформление было «в фирменном стиле».

На этом шаге важно не уходить в продакшн-детали (мета-теги, аналитику, индексацию) — это зона Claude Code. Цель фазы — утвердить внешний вид и структуру.

Шаг 4. Хендофф в Claude Code

Когда макет устраивает, используйте встроенный хендофф: Claude Design упакует дизайн-намерение в бандл, и Claude Code подхватит его одной инструкцией. С этого момента дизайн становится сырьём для продакшн-скилла, а не финальным артефактом. Дальше всем управляет контракт.

Шаг 5. Контракт лендинга (landing-contract.md)

Зафиксируйте чек-лист обязательного и объясните каждый пункт в терминах SEO и шеринга: корректный <title> и meta description в разумных пределах; canonical (особенно критично, когда вы плодите похожие лендинги под кампании); Open Graph и Twitter Card (это напрямую влияет на CTR при шеринге); JSON-LD под тип страницы; ровно один <h1>; аналитика под guard (не грузится без ID); и инвариант «ноль внешних CSS/JS на критпути».

Шаг 6. Нейтральный скелет (landing-skeleton.html)

Сделайте каркас, который уже соответствует контракту: полный SEO-блок, системные шрифты, инлайн-стили, контентные плейсхолдеры ({{TITLE}} и т. п.). Задача скелета — чтобы модель (и пришедший из Claude Design дизайн) наполняли готовую корректную структуру, а не собирали SEO-обвязку заново каждый раз.

Шаг 7. Валидатор (check_landing.py)

Напишите скрипт, который проверяет готовый файл на соответствие контракту и возвращает ненулевой код при нарушении: наличие и длины title/description, единственный <h1>, присутствие canonical/OG/JSON-LD, отсутствие внешних <script src> и <link rel=stylesheet> на критпути. Сделайте прогон валидатора обязательным шагом — модель не считает задачу выполненной, пока валидатор не вернул ноль.

Шаг 8. Скилл new-landing

Свяжите контракт, скелет и валидатор в один SKILL.md. Пропишите, когда скилл применяется, и закрепите самопроверку как финальную ступень. Теперь генерация лендинга — это: взять бриф → взять дизайн из хендоффа → наполнить скелет → прогнать валидатор → получить файл, готовый к деплою.

Шаг 9. Скилл landing-experiment — A/B

Логика: вариант A (control) лежит в HTML, вариант B применяется поверх лёгким скриптом по cookie-сплиту, а сам вариант прокидывается в аналитику как параметр визита. Контент обоих вариантов реальный и доступен роботу.

Здесь Claude Design снова полезен: визуальный вариант B удобно нарисовать на канвасе (другой первый экран, другой CTA-блок), а затем тем же хендоффом приземлить его в код и привести к контракту. То есть дизайн-вариативность — в Claude Design, а корректная техника сплита и измерение — в скилле.

Шаг 10. Скилл landing-journal — память проекта

Встройте аудит-журнал. Каждое значимое действие — создание лендинга, добавление варианта, запуск теста, решение, раскат — пишется append-only в journal.jsonl, плюс git как нижний слой (хеш коммита в каждой записи). История неизменяемая: ошиблись — добавляете корректирующую запись, старые не переписываете. По сути это «чёрный ящик» проекта: когда крутишь много гипотез, легко забыть, что и когда менял и чем закончилось.

Шаг 11. Скилл landing-ads — материалы под рекламу

Скилл генерирует UTM-метки, тексты объявлений и ключи под Яндекс Директ и Google Ads, согласованные с контентом конкретного лендинга. Это закрывает разрыв между посадочной и кампанией, которая на неё льёт.

Шаг 12. Скилл init-landing-system — переносимость

Раз система обезличена, логично уметь ставить её куда угодно. Скилл берёт снимок всей системы и разворачивает в существующий проект, подставляя его домены и контейнеры на место плейсхолдеров. Важная деталь: он подставляет только инфраструктурные плейсхолдеры (домены, имена контейнеров), а контентные плейсхолдеры скелета ({{TITLE}} и т. п.) не трогает — их заполнит new-landing при генерации. И он merge-aware: не перезаписывает существующие файлы без явного флага.

Инфраструктура и деплой

CI на GitHub Actions. Минимальная логика branch-routed деплоя по таблице из решения №3: main → прод, dev → staging, остальные ветки → превью по своему URL.

Прокси и контейнеры. Обратный прокси (Traefik) перед nginx-контейнерами. Превью раздаются из папок вида staging-домен/{branch}. Отдельный workflow удаляет превью-папку, когда ветку удаляют, чтобы не копить мусор.

Индексация на уровне сервера. X-Robots-Tag: noindex для staging и превью настраивается в nginx — надёжнее мета-тега и закрывает все превью одним правилом.

Секреты и DNS. Честно: эту часть заводят руками — GitHub-секреты, DNS-записи, маршруты прокси. Автоматизировать это «из dev-time» нельзя, поэтому держите чек-лист, который скрипт инициализации просто печатает при развёртывании.

SEO-глубина для тех, кто живёт на трафике

• Почему статика выигрывает у тяжёлых конструкторов и громоздких SSG: полный контроль над разметкой и предсказуемая скорость без фреймворка на критпути.
• Canonical при множестве похожих лендингов под кампании — главное оружие против каннибализации и дублей. Когда вы плодите посадочные пачками, именно здесь чаще всего теряется трафик.
• Open Graph и Twitter Card — это не «для галочки», а фактор CTR при любом шеринге: в мессенджерах, соцсетях, чатах партнёров.
• JSON-LD — выбирайте схему под тип страницы; для посадочных это обычно организация/продукт/услуга.
• Core Web Vitals из коробки — прямое следствие инварианта «ноль JS на критпути». Вы получаете хорошие метрики скорости не «оптимизацией постфактум», а самой архитектурой.

И отдельно про роль Claude Design в SEO: дизайн-инструмент думает о красоте, а не о краулере. Поэтому всё, что он отдаёт, обязано пройти через контракт. Это не ограничение, а страховка: вы берёте лучшее из визуального исследования и не платите за это индексацией.

A/B-тесты без клоакинга

A/B-тесты лендингов часто делают на разных URL — и это легко превращается в клоакинг: роботу один контент, людям другой. За это поисковики наказывают. В нашей системе тест идёт на одном URL: вариант A лежит в HTML, вариант B применяется поверх лёгким скриптом по cookie-сплиту, вариант прокидывается в аналитику как параметр визита. Контент реальный и доступен роботу — это не клоакинг.

Два правила, чтобы тесты были осмысленными:

• Один активный тест за раз — иначе вы не разделите эффекты.
• Трафик-гейт — всерьёз делать выводы можно только при достаточном объёме трафика, иначе тест не наберёт статистической значимости и вы будете принимать решения на шуме.

Где Claude Design помогает, а где — Claude Code

Чтобы не путать инструменты, держите в голове разделение ответственности:

Claude Design отвечает за:

• исследование внешнего вида и быстрый перебор направлений;
• композицию первого экрана, типографику, цвет, структуру блоков;
• визуальные варианты для A/B;
• быстрый макет, чтобы показать заказчику до того, как что-то кодить.

Claude Code (skills) отвечает за:

• приземление дизайна в самодостаточный статический HTML;
• соблюдение контракта и автопроверку валидатором;
• версионирование, журнал, CI и деплой;
• технику A/B-сплита и индексацию.

Граница простая: пока речь про «как это выглядит» — вы в Claude Design. Как только речь про «что уезжает на прод и как это измеряется» — вы в Claude Code. Хендофф между ними — это и есть та точка, где красивый прототип превращается в надёжный продакшн-лендинг.

Честно про ограничения

Чтобы это не звучало как реклама, обозначим края системы:

• Серверная часть — ручная. Контейнеры nginx, маршруты прокси, DNS и секреты заводятся самостоятельно; скрипт лишь печатает чек-лист.
• Аналитика — вендорный boilerplate. В скелете лежат стандартные сниппеты Метрики/GA под guard (не грузятся без ID). Это пример интеграции, а не «магия системы».
• Это пока не движок-генератор. Новый лендинг — это скелет плюс наполнение (дизайном и моделью), а не сборка из контент-модели и библиотеки блоков.
• Claude Design в исследовательском превью. У него есть свои шероховатости (например, нюансы с сохранением инлайн-комментариев), и он не заменяет Figma/Canva — это инструмент исследования и прототипа, а не финального продакшна. В нашем конвейере он сознательно стоит до контракта, а не вместо него.
• Сложные интерактивные страницы — за рамками паттерна: система заточена под быстрые SEO-лендинги, а не под веб-приложения.

Куда развивать

• Превратить паттерн в полноценный генератор: контент-модель, библиотека блоков, сборка лендинга из данных, а не только наполнение скелета.
• Подключить CRM и коллтрекинг, чтобы журнал хранил не только действия, но и исход (лиды, продажи).
• Мультиязычность и автоматическая генерация связки «лендинг + рекламные материалы» под каждый рынок.
• Глубже использовать бренд-репозиторий в Claude Design, чтобы все варианты сразу выходили в едином фирменном стиле.

Чек-листы

Контракт лендинга:

• <title> и meta description в разумных пределах
• canonical указывает на каноничный URL
• Open Graph и Twitter Card заполнены
• JSON-LD под тип страницы
• ровно один <h1>
• аналитика под guard (не грузится без ID)
• ноль внешних <script src> и <link rel=stylesheet> на критпути
• валидатор вернул 0

Прежде чем индексировать прод:

• staging и превью отдают X-Robots-Tag: noindex
• на проде нет дублей и конфликтующих canonical
• превью удалённых веток подчищены
• аналитика проверена с реальным ID

FAQ

Нужно ли уметь кодить? Чтобы собрать систему — желательно базовое понимание git, CI и nginx. Чтобы пользоваться готовой — достаточно собрать бриф и пройти визуальную фазу; контракт и проверки берут техническую часть на себя.

Зачем два инструмента, нельзя ли всё в одном? Можно, но хуже. Дизайн-инструмент думает о красоте, а не о краулере; продакшн-скиллы — наоборот. Разделение даёт и красивый результат, и предсказуемую индексацию.

Можно ли выкатывать HTML прямо из Claude Design? Технически он умеет отдавать standalone-HTML, но для SEO-лендинга это рискованно: вы теряете гарантии контракта. Правильный путь — хендофф в Claude Code и прогон через валидатор.

Подойдёт ли для многостраничника? Система заточена под быстрые лендинги. Многостраничные проекты и веб-приложения — другой класс задач.

Чем это лучше конструкторов? Полный контроль над разметкой и скоростью, тривиальный деплой, версионирование и воспроизводимость, плюс A/B без клоакинга и журнал решений.

Как считать конверсию? Через guarded-аналитику в скелете и A/B на одном URL с прокидыванием варианта в параметр визита; трафик-гейт защищает от выводов на шуме.

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

Итог

Главный вывод — не про лендинги, а про формат работы. Два инструмента закрывают две разные задачи: Claude Design кристаллизует визуальное исследование, а Claude Code skills кристаллизуют повторяющийся продакшн-процесс — выносят правила в контракт, добавляют самопроверку и избавляют вас от зависимости от того, как сегодня сформулирован промпт. Хендофф между ними — это мост от красивого прототипа к надёжной, индексируемой, измеримой странице.

Лендинги — просто первый домен, на котором это окупается особенно быстро. Начните с малого: соберите бриф, прогоните визуальную фазу в Claude Design, приземлите результат через new-landing с контрактом и валидатором — и расширяйте систему скиллами по мере того, как растёт поток ваших посадочных.