Шаблон брифа на разработку сайта для фаундеров

Сборка сайта уходит в сторону, когда kickoff — это Loom, Figma-moodboard и надежда, что у всех одно определение «done». Фаундеры чувствуют это первыми. Вы платите за сайт, который должен выигрывать лиды, объяснять продукт или закрывать раунд, а вместо этого получаете бесконечную полировку не тех страниц.

Бриф на разработку сайта — короткий документ, который это чинит. Он фиксирует, что вы строите, для кого, что входит и не входит в scope, кто владеет какими аккаунтами и как вы примете работу. Это руководство даёт готовый к копированию шаблон брифа плюс причину существования каждого блока — чтобы забрифовать фрилансера, агентство или внутреннего билдера без повторного открытия тех же дыр mid-sprint.

Почему бриф бьёт расплывчатый kickoff-звонок

Kickoff-звонки полезны для тона и доверия. Они ужасны как единственный источник правды. Люди помнят разные предложения. Slack-треды хоронят то единственное решение, которое имело значение. Через три недели кто-то спрашивает, входило ли SEO блога, и никто не может указать на ответ, который был записан.

Бриф вынуждает жёсткие вопросы рано, когда смена направления дёшева. Он также защищает билдера. Ясный scope — как хорошие фрилансеры честно котируют и как вы сравниваете котировки без театра «яблоки с апельсинами».

Clipboard-бриф стоит между kickoff-звонком и календарём сборки, чтобы решения оставались записанными.

Главный вывод: Если решение не в брифе или поправке к нему — считайте его нерешённым. Одно это правило предотвращает большинство драк «я думал, мы договорились».

Цели и как вы узнаете, что сайт сработал

Начните с outcomes, не с числа страниц. «Нам нужен маркетинговый сайт» — категория. «Нам нужны квалифицированные demo-заявки от Series A SaaS-байеров в US и EU» — цель. Пишите максимум две–три цели. Больше обычно значит, что вы смешиваете brand-сайт, product app и content engine в одно расплывчатое желание.

Для каждой цели добавьте success signal, который можно наблюдать в первые 30–90 дней после запуска. Примеры, которые работают в брифе:

• Завершения demo-формы в неделю (baseline vs целевой диапазон)
• Time-to-first-useful-page для нового посетителя (главная → pricing или docs)
• Органические impressions по определённому кластеру фраз, когда Search Console подключён
• Тикеты поддержки, которые прекращаются, потому что FAQ или docs-страница теперь отвечает

Не ставьте «rank #1 по нашему category keyword» как success signal, если у вас ещё нет плана контента и ссылок. Позиции — outcome многих систем. Бриф может задать SEO-ожидания (см. ниже). Он не должен обещать позиции.

Цели сидят выше списков страниц. Каждая цель привязана к сигналу, который можно проверить после запуска.

Аудитория, первичные jobs и возражения

Большинство брифов пропускают аудиторию или вставляют персону из pitch deck. Билдерам нужно острее. Кто приходит, какую job пытается закончить и что заставит уйти?

Пишите максимум три короткие заметки об аудитории. Для каждой ответьте:

1. Что они только что искали, кликали или откуда пришли по рефералу?
2. Какое решение пытаются принять на этом визите?
3. Какое доказательство снизит риск (логотипы клиентов, ясность цен, security-страница, история фаундера)?

Если продаёте и байерам, и юзерам — скажите, какой сайт для кого. Product-сайт фаундера, пытающийся конвертировать end users и CFO на одной главной, обычно размывает обоих.

Каждая заметка об аудитории парит job-to-be-done с доказательством, снижающим bounce.

Sitemap, страницы и критичные flows

Здесь расплывчатые проекты становятся shippable. Перечислите страницы, нужные в v1, затем flows, которые должны работать end to end. Список страниц без flows — как контактные формы уезжают сломанными и как «book a demo» становится mailto, который никто не тестировал на мобильном.

Предлагаемая форма для брифа:

• Must-ship страницы. Home, продукт или услуги, pricing (или как вы продаёте), about, contact или demo, legal-страницы, которые реально нужны.
• Should-ship, если бюджет позволяет. Кейсы, индекс блога, careers, integrations, status-страница.
• Явно позже. Всё, что соблазн изобрести mid-build (customer portal, полный docs-сайт, community forum).

Затем перечислите flows как нумерованные пути, не фичи:

1. Посетитель попадает на home → pricing → demo-форма → thank-you → email-нотификация в sales.
2. Посетитель попадает на страницу услуги → связанный кейс → contact.
3. Возвращающийся посетитель бьёт старый URL → редирект на новый путь (заглушка карты редиректов).

Если уже есть живой сайт, приложите текущий инвентарь URL и пометьте keep / merge / kill. Редизайны, игнорирующие старую карту URL, создают SEO- и bookmark-ущерб, который выглядит как «новый сайт убил трафик», когда бриф никогда не просил редиректы.

Боксы страниц и стрелки flows в одном разделе, чтобы «done» включал путь, а не только layout.

SEO-ожидания, которые стоит записать

Фаундеры часто говорят «нам нужно SEO» так же, как «нам нужен брендинг». Билдеры слышат либо полную контент-программу, либо базовую техническую гигиену. Положите ожидание в бриф, чтобы котировки совпадали с реальностью.

Практический SEO-блок для сборки маркетингового сайта обычно покрывает:

• Технический baseline. HTTPS, разумная структура URL, XML-sitemap, robots.txt, не блокирующий денежные страницы, canonical на основных шаблонах, crawlable HTML для основного контента.
• On-page для согласованных шаблонов. Уникальные titles и H1, meta descriptions, которые можно править позже, внутренние ссылки между хабами и денежными страницами.
• Аналитика и Search Console. Кто создаёт свойства, чей Google-аккаунт ими владеет, и что билдер получает доступ только по необходимости.
• Производство контента. Скажите, включает ли запуск N статей, миграцию старых постов или ничего. «Блог сделаем позже» — нормально, когда записано.
• Редиректы. Обязательны при замене существующего домена или структуры путей.

Чего SEO-блок не должен делать — гарантировать позиции, трафик или фиксированную позицию к дате. Собственный гайд Google по созданию полезного контента — про полезность и доверие, не про обещания вендора. Ваш бриф может требовать сайт, который обходим и ясен. Он не может купить слот в SERP.

Технический baseline, on-page шаблоны, владение Search Console и редиректы — в одном честном SEO-разделе.

Частая ошибка: Просить «полное SEO» без бюджета на контент и без карты редиректов, затем винить тему, когда органика падает после редизайна.

Вехи, ревью и владельцы решений

Вехи превращают бриф в календарь, вокруг которого люди могут планировать. Держите их немногочисленными и конкретными. Типичная форма маркетингового сайта:

1. Бриф зафиксирован. Вы и билдер подписываете scope, страницы, SEO-ожидания и out of scope.
2. Структура и вайрфреймы. Information architecture и ключевые шаблоны согласованы до визуальной полировки.
3. Дизайн основных шаблонов. Home плюс одна внутренняя денежная страница до дизайна каждой страницы.
4. Сборка и drop контента. Копирайт и ассеты приходят в заявленную дату, иначе таймлайн съезжает по определению.
5. Staging-ревью. Функциональный и контентный QA против acceptance-списка.
6. Запуск и handoff. DNS, аналитика, доступ к repo и документация, как определено во владении.

Назовите decision owner для дизайна, копирайта и технического go-live. Комитеты, которые все «апрувят» и никто не решает, сожгут ваш таймлайн. Если вы фаундер — напишите своё имя для финального call по бренду и messaging и назовите, кто может апрувить staging-баги день за днём.

У каждой вехи — окно даты и один именованный владелец call, который разблокирует следующий шаг.

Владение аккаунтами, доменами и кодом

Этот раздел спасает отношения. До того как кто-то начнёт, запишите, кто владеет:

• Регистратором домена и DNS
• Аккаунтом хостинга или платформы (Vercel, Netlify, Cloudflare Pages, WP Engine и т.д.)
• Git-репозиторием
• CMS (если есть)
• Google Analytics / GA4 и Google Search Console
• Отправкой email для форм (Resend, Formspree, ваш ESP)
• Сторонними скриптами (чат, ads, A/B-инструменты)
• Дизайн-файлами (Figma)

Дефолтное правило, которое работает для большинства фаундеров: компания владеет каждым продакшен-аккаунтом. Билдер получает invited collaborator access, не личное владение доменом или repo. Если фрилансер настаивает держать домен «до финальной оплаты» — это флаг переговоров, не стандартная практика.

Также запишите, что происходит на handoff: админ-приглашения переданы, личные аккаунты билдера сняты, deploy keys ротированы при необходимости и короткий README, как отгрузить изменение.

Company-owned аккаунты с доступом билдера, не production-ключи, принадлежащие билдеру.

Предупреждение: Не оставляйте Search Console или домен под личным Gmail подрядчика после запуска. Когда отношения заканчиваются, восстановление становится уродливым.

Out of scope (раздел, который защищает всех)

Out of scope — не враждебность. Это как держать котировку честной. Перечислите работу, которую вы не покупаете в этом engagement, даже если она звучит связанной.

Частые пункты для брифа маркетингового сайта:

• Кастомное веб-приложение или logged-in product UI
• Ongoing-написание контента сверх согласованного числа статей
• Линкбилдинг или outreach
• Настройка и управление платной рекламой
• Brand identity с нуля (логотип, полные гайдлайны), если не процитировано
• Производство фото или видео
• Мультиязычное расширение сверх перечисленных локалей
• Миграции email-листов, CRM-пайплайнов или биллинг-систем
• SLA-backed uptime сверх дефолта хоста

Если что-то может появиться позже — положите под «кандидаты phase 2» вместо того, чтобы контрабандой тащить в v1 устно. Билдеры, кивающие бесконечному scope, либо недосдают, либо шлют change orders. Фаундеры, отказывающиеся писать out of scope, обычно открывают его как сюрприз-инвойсы.

Пункты out of scope сидят за забором v1, чтобы котировки оставались сравнимыми, а change orders — намеренными.

Acceptance criteria, которые говорят, когда сайт готов

Acceptance — чеклист, которым пользуетесь на staging до переключения DNS. Без него «done» становится вкусом. С ним вкус всё ещё важен для дизайна, но ship-blocking проблемы объективны.

Пишите acceptance как pass/fail утверждения, привязанные к брифу:

• Каждая must-ship страница достижима из основной навигации или согласованного пути sitemap.
• Каждый перечисленный flow завершается на десктопе и mid-size телефоне (форма отправляется, thank-you показывается, нотификация приходит).
• Редиректы из согласованной карты возвращают корректный destination.
• Titles и H1 существуют для основных шаблонов и совпадают с согласованным copy deck.
• Аналитика стреляет на ключевых событиях, которые вы перечислили (form submit, outbound calendar click).
• Legal-страницы, связанные в футере, присутствуют, если требуются для вашего рынка.
• Битые ссылки и console errors на основных шаблонах очищены или явно waived.
• Доступы к repo, хостингу и аналитике совпадают с разделом владения.

Дизайн-полировка может иметь отдельный список «known follow-ups». Не держите запуск в заложниках у пиксельных дебатов, которых не было в брифе, и не пропускайте сломанные flows, потому что главная хорошо выглядит.

Pass/fail строки acceptance превращают staging-ревью в ship-решение вместо спора о вкусе.

Разбор сценария: фаундер B2B SaaS брифует v1

Maya ведёт Series A workflow-инструмент. Ей нужен публичный сайт до partner-анонса через шесть недель. Её соблазняет попросить «современный сайт как Linear, плюс блог, плюс тизер customer portal».

Она заполняет бриф вместо этого:

• Цели. Partner-ready история продукта; demo-заявки от mid-market ops leads; Search Console подключён с редиректами со старых путей Webflow.
• Аудитория. Ops-менеджеры, оценивающие инструменты в этом квартале; партнёры, проверяющие credibility интеграций.
• Must-ship страницы. Home, product, integrations, pricing, security, about, demo, privacy, terms. Индекс блога только с тремя мигрированными постами.
• Flows. Demo-форма в HubSpot; security-страница связана из футера и footnote pricing.
• SEO. Технический baseline, редиректы с 14 старых URL, без нового content retainer в v1.
• Out of scope. UI customer portal, пак кастомных иллюстраций, ads, ongoing-производство блога.
• Владение. Cloudflare и GitHub компании; билдер как collaborator; Maya владеет GA4 и Search Console.
• Acceptance. Flows протестированы на staging; spot-checks редиректов; форма попадает в правильный пайплайн HubSpot.

Котировка, которую она получает, сравнима у двух фрилансеров, потому что оба прайсят один и тот же забор. Когда на третьей неделе кто-то предлагает мок портала, она указывает на out of scope и планирует phase 2 вместо того, чтобы сорвать partner-дату.

Бриф Maya огораживает partner-ready страницы и редиректы и паркует портал в phase 2.

Шаблон брифа на разработку сайта для копирования

Используйте как рабочий документ. Удаляйте подсказки в скобках по мере заполнения ответов.

1. Снимок проекта

• Рабочее название / имя компании:
• Основной домен (текущий и целевой):
• Целевое окно запуска:
• Decision owner (финальный call по scope и go-live):
• Day-to-day контакт:

2. Цели и success signals

• Цель 1 + как измерим за 30–90 дней:
• Цель 2 + как измерим:
• Цель 3 (опционально):
• Что этот сайт не должен решать:

3. Аудитория и jobs

Для максимум трёх аудиторий:

• Кто они:
• Job на этом визите:
• Доказательство, снижающее риск:
• Primary CTA, который хотим от них:

4. Бренд и ограничения

• Существующие brand assets (логотип, цвета, шрифты, Figma):
• Заметки о тоне (максимум три прилагательных плюс одно «избегать»):
• Конкуренты или reference-сайты (что брать структурно, не копировать):
• Заметки по accessibility или compliance (цель WCAG, отрасли, регионы):
• Языки / локали в v1:

5. Sitemap и flows

• Must-ship страницы:
• Should-ship, если бюджет позволяет:
• Явно позже / phase 2:
• Критичные flows (нумерованные):
• Приложен инвентарь существующих URL? (да/нет + ссылка):
• Владелец карты редиректов:

6. Контент и ассеты

• Кто пишет копирайт:
• Дата freeze копирайта для шаблонов запуска:
• Источники изображений / видео:
• Цитаты клиентов или логотипы, одобренные к использованию:
• Требуемые legal-страницы:

7. SEO и измерение

• Требуется технический SEO baseline? (да/нет)
• On-page для каких шаблонов:
• Блог / контент в v1 (число или нет):
• Нужны редиректы? (да/нет)
• Инструменты аналитики и список событий:
• Владельцы аккаунтов Search Console и аналитики:

8. Предпочтения стека (опционально)

• Предпочтительный фреймворк или CMS (или «билдер рекомендует»):
• Предпочтение хостинга:
• Destination формы / CRM:
• То, за что уже платим и что нужно переиспользовать:

9. Вехи

Веха	Целевое окно	Владелец	Exit criteria
Бриф зафиксирован
IA / вайрфреймы
Дизайн основных шаблонов
Сборка + drop контента
Staging acceptance
Запуск + handoff

10. Владение

Ассет	Company owner account	Уровень доступа билдера	Заметка handoff
Domain / DNS
Hosting
Git repo
CMS
Analytics
Search Console
Forms / ESP
Design files

11. Out of scope

• Перечислите пункты, не входящие в эту котировку:
• Кандидаты phase 2 (опционально):

12. Acceptance criteria

• Чеклист pass/fail утверждений для staging:
• Known follow-ups, разрешённые после запуска (non-blocking):
• Имена и дата sign-off:

13. Коммерческие заметки (коротко)

• Fixed fee или time-and-materials:
• Что триггерит change order:
• Окно поддержки после запуска (дни bugfix, если есть):

Это usable-шаблон. Всё выше него существует, чтобы вы заполняли эти поля с намерением, а не пустыми заголовками.

Передача брифа без потери сюжета

Отправьте бриф до просьбы о финальной котировке. Пройдите его раз live, если билдер для вас новый, затем заморозьте версию (дата в имени файла или история версий общего документа). Изменения после freeze становятся amendments. Звучит формально для пятистраничного сайта. Это как не платить дважды за ту же неделю работы.

Когда сравниваете вендоров, скорьте их против одного брифа. Спросите, где они не согласны с вашим out of scope или SEO-блоком. Несогласие рано полезно. Тишина, превращающаяся в «SEO подразумевалось» позже, — нет.

После запуска заархивируйте бриф с handoff README. Следующему подрядчику не должен понадобиться сеанс с вашей Slack-историей.

Датированная версия брифа идёт от фаундера к билдеру до финальной котировки, затем архивируется с заметками handoff.

Часто задаваемые вопросы

Какой длины должен быть бриф на разработку сайта?

Двух–пяти страниц достаточно для большинства маркетинговых сайтов. Если нужен роман — вероятно, специфицируете product application. Держите бриф коротким и прикладывайте инвентари (URL, редиректы, copy decks) вместо того, чтобы впихивать каждую строку в нарратив.

Можно ли использовать этот бриф для Webflow, WordPress и кастомного кода?

Да. Бриф намеренно stack-agnostic. Положите предпочтения в раздел стека, если есть. Если нет — попросите билдера рекомендовать стек под ваше владение и нужды обновлений, затем запишите этот выбор обратно в бриф до старта сборки.

Что если я ещё не знаю sitemap?

Скажите так и сделайте discovery платной вехой с ясным exit: предложенный sitemap и flows, которые вы апрувите до визуального дизайна. Не притворяйтесь уверенностью, которой нет. Фейковые sitemap создают переработку.

Должны ли SEO и разработка быть отдельными брифами?

Для небольшого маркетингового сайта один бриф с честным SEO-блоком обычно лучше. Если покупаете большую контент-программу, technical SEO remediation или международную работу с hreflang — это могут быть отдельные statements of work, связанные из этого брифа, чтобы владение оставалось ясным.

Кто должен писать бриф — фаундер или агентство?

Фаундер (или человек, владеющий outcomes) должен писать цели, аудиторию, out of scope и владение. Хороший билдер может помочь отточить sitemap, flows и язык acceptance. Если агентство пишет весь бриф в одиночку — читайте его как их sales-документ, пока не отредактируете цели своими словами.

Что относится к change order?

Всё, что добавляет страницы, flows, интеграции, локали или объём контента сверх зафиксированного брифа, или переносит пункт phase 2 в v1. Taste-правки внутри апрувнутого шаблона обычно нет. Если неуверены — спросите «меняет ли это acceptance checklist?» Если да — это разговор о change order.

Закройте цикл, прежде чем покупать часы

Ясный бриф не сделает слабого билдера сильным. Он сделает сильных билдеров быстрее, котировки сравнимыми, а день запуска скучным в тех смыслах, которые вы хотите. Заполните шаблон, заморозьте версию и относитесь к amendments как к норме, когда бизнес узнаёт что-то новое.

Если нужна помощь превратить черновой бриф в scoped сборку маркетингового сайта (страницы, SEO baseline, владение и acceptance включены), напишите через контактную форму.