Как написать ТЗ на сайт через ChatGPT

Техническое задание на сайт часто начинают писать слишком поздно. Уже выбрали исполнителя, уже обсудили цену, уже «примерно всё понятно», уже хочется быстрее стартовать. А потом начинается любимое: «а мы думали, это входит», «а можно ещё вот это», «а почему форма такая», «а где блог», «а почему это не редактируется из админки». В этот момент выясняется, что вместо ТЗ было общее ощущение будущего сайта.

ChatGPT может сильно помочь с подготовкой ТЗ. Не потому что он волшебно понимает ваш бизнес, а потому что хорошо структурирует хаос. Ему можно отдать вводные, список пожеланий, примеры сайтов, услуги, черновые мысли, и он поможет превратить это в нормальный документ: структура страниц, блоки, функционал, требования к админке, SEO, адаптивность, формы, контент и вопросы к исполнителю.

Если ТЗ собирается не за один подход и к нему нужно регулярно возвращаться с файлами, вводными и отдельными обсуждениями, для такой работы удобно использовать Projects в ChatGPT как рабочую контент-систему.

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

Но есть важная граница. ChatGPT не должен принимать решения вместо владельца сайта. Он может задать правильные вопросы, собрать шаблон, предложить варианты, подсветить пробелы. Но если вы сами не понимаете, зачем сайту блог, нужна ли мультиязычность, какие услуги главные, какие заявки важны и кто будет обновлять контент, нейросеть просто красиво оформит неопределённость. А красиво оформленная неопределённость всё равно остаётся неопределённостью.

Когда это использовать

Использовать ChatGPT для ТЗ стоит на этапе подготовки к созданию сайта, редизайну, переносу на WordPress, разработке лендинга, сайта услуг, каталога, блога или личного сайта специалиста. Особенно если в голове уже есть много разрозненных мыслей, но нет структуры.

Например, вы знаете, что нужен сайт услуг, но не уверены, какие страницы делать. Или есть Figma-макет, но непонятно, как описать его для верстальщика и WordPress-разработчика. Или нужно собрать вводные для подрядчика, чтобы не объяснять всё голосом в переписке десять раз. Вот здесь ChatGPT полезен.

Он помогает не только владельцу сайта, но и специалисту. Можно быстрее подготовить список вопросов к клиенту, структуру будущего сайта, таблицу страниц, блоки для каждой страницы, SEO-требования, сценарии форм и даже требования к редактированию через админку WordPress.

Использовать AI особенно удобно, когда сайт ещё не начался. Потому что на этом этапе ошибка дешевле. Можно поменять структуру, убрать лишнее, добавить нужный раздел, уточнить роли страниц, продумать контент и функционал. После старта разработки такие изменения уже дороже, дольше и обычно сопровождаются фразой «ну это же маленькая правка». Маленькая, конечно. Просто затрагивает полсайта.

Если задача начинается именно со структуры будущего проекта, полезно сначала разобрать подход через материал ChatGPT для структуры сайта, а уже потом переходить к полноценному ТЗ.

Принцип работы

Главный принцип простой: ChatGPT нужно давать не просьбу, а контекст. Плохой запрос звучит так: «напиши ТЗ на сайт». В ответ вы получите универсальный документ, который подойдёт кому угодно и поэтому толком не подойдёт никому.

Хороший запрос содержит: кто вы, какой сайт нужен, для кого он создаётся, какие задачи должен решать, какие страницы нужны, какой функционал ожидается, кто будет пользоваться админкой, какие материалы уже есть, какие ограничения важны, какой формат результата нужен.

ТЗ на сайт через ChatGPT лучше собирать не одним промптом, а этапами. Сначала вводные. Потом структура. Потом страницы. Потом функционал. Потом админка. Потом SEO. Потом вопросы к заказчику или исполнителю. Потом финальная сборка документа. Так меньше риска получить красивую простыню, где всё звучит правильно, но половина требований не привязана к реальному проекту.

Этап	Что дать ChatGPT	Что получить на выходе
Вводные	Тип бизнеса, цель сайта, аудитория, услуги	Краткое описание проекта и список уточняющих вопросов
Структура	Какие разделы нужны, какие услуги главные	Карта сайта и логика навигации
Страницы	Список страниц, задачи каждой страницы	Блоки, контент и CTA для каждой страницы
Функционал	Формы, фильтры, поиск, каталог, блог, интеграции	Список функций и требований к ним
WordPress	Что должно редактироваться в админке	Требования к ACF, типам записей, шаблонам
SEO	Ключевые страницы, мета, URL, микроразметка	SEO-требования и технические ограничения
Финал	Все собранные материалы	Готовый черновик ТЗ для проверки человеком

Важно просить ChatGPT не только писать, но и задавать вопросы. Хорошее ТЗ часто начинается не с ответа, а с уточнений. Если модель сразу уверенно выдаёт документ без вопросов, это может выглядеть продуктивно, но в реальности она просто заполняет пустоты своими предположениями.

Готовые шаблоны или промпты

Ниже можно брать готовые промпты и адаптировать под свой проект. Лучше использовать их по порядку, а не одним огромным запросом.

Промпт 1. Собрать вводные для ТЗ

Ты помогаешь подготовить техническое задание на сайт.

Проект:
[кратко опиши бизнес или проект]

Тип сайта:
[сайт услуг / лендинг / интернет-магазин / каталог / блог / личный сайт / корпоративный сайт]

Цель сайта:
[получать заявки / презентовать услуги / продавать товары / собирать лиды / показать портфолио / объяснить проект]

Аудитория:
[кто будет заходить на сайт]

Что уже есть:
[логотип, тексты, старый сайт, Figma-макет, фотографии, домен, хостинг, брендбук]

Что нужно получить:
Составь список вопросов, которые нужно уточнить перед написанием ТЗ. Раздели вопросы по блокам: бизнес, аудитория, структура, страницы, функционал, дизайн, контент, SEO, WordPress, интеграции, сроки.

Промпт 2. Сформировать структуру сайта

На основе вводных ниже предложи структуру сайта.

Вводные:
[вставь описание бизнеса, услуг, аудитории и целей]

Нужно:
1. Предложить карту сайта.
2. Разделить страницы на обязательные и дополнительные.
3. Объяснить задачу каждой страницы.
4. Предложить главное действие пользователя на каждой странице.
5. Указать, какие страницы важны для SEO.

Формат ответа:
таблица с колонками: страница, задача, аудитория, CTA, SEO-важность, комментарий.

Промпт 3. Описать страницу услуги

Помоги описать страницу услуги для ТЗ.

Услуга:
[название услуги]

Целевая аудитория:
[кто покупает услугу]

Задача страницы:
[что должен понять пользователь и какое действие сделать]

Составь структуру страницы:
1. Первый экран.
2. Краткое объяснение услуги.
3. Что входит.
4. Кому подходит.
5. Кому не подходит.
6. Этапы работы.
7. Что нужно от клиента.
8. FAQ.
9. CTA.

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

Промпт 4. Описать требования к WordPress

Составь требования к WordPress-разработке для сайта.

Тип сайта:
[тип сайта]

Страницы и разделы:
[список страниц]

Нужно описать:
1. Какие типы записей нужны.
2. Какие поля должны редактироваться через админку.
3. Где нужны ACF-поля.
4. Какие элементы должны быть в меню.
5. Какие формы нужны.
6. Какие данные должны приходить на почту.
7. Какие блоки должны быть повторяемыми.
8. Какие страницы должны иметь отдельные шаблоны.

Формат:
таблица: раздел, что редактируется, где используется, комментарий для разработчика.

Промпт 5. Подготовить ТЗ по Figma-макету

У меня есть Figma-макет сайта. Помоги подготовить ТЗ для верстки и переноса на WordPress.

Контекст:
[кратко опиши сайт, страницы, особенности макета]

Нужно:
1. Составить список страниц для верстки.
2. Описать повторяющиеся компоненты.
3. Указать, какие блоки должны редактироваться из WordPress.
4. Составить список адаптивных состояний.
5. Описать требования к формам, меню, попапам, слайдерам и интерактивным элементам.
6. Составить вопросы к дизайнеру или заказчику, если в макете не хватает данных.

Формат:
структурированное ТЗ с таблицами.

Если задача связана именно с ускорением связки Figma и WordPress, можно дополнительно использовать подход из статьи Figma макет в WordPress быстрее с AI.

Промпт 6. Финальная сборка ТЗ

Собери финальное ТЗ на сайт на основе всех данных ниже.

Данные:
[вставь структуру, страницы, функционал, требования к WordPress, SEO и дизайну]

Сделай документ в структуре:
1. Описание проекта.
2. Цели сайта.
3. Аудитория.
4. Структура сайта.
5. Описание страниц.
6. Функциональные требования.
7. Требования к WordPress и админке.
8. Требования к дизайну и адаптивности.
9. Требования к SEO.
10. Формы и уведомления.
11. Интеграции.
12. Что предоставляет заказчик.
13. Что должно быть на выходе.
14. Открытые вопросы.

Пиши конкретно, без воды и общих фраз. Если данных не хватает, добавь отдельный блок «Что нужно уточнить».

Шаблон готового ТЗ

Техническое задание на сайт

1. Описание проекта
Название проекта:
Сфера:
Краткое описание:
Главная цель сайта:

2. Аудитория
Кто будет заходить на сайт:
Какие задачи у пользователя:
Какие вопросы или сомнения нужно закрыть:

3. Структура сайта
Главная:
Услуги:
О компании:
Портфолио:
Блог:
Контакты:
Дополнительные страницы:

4. Описание ключевых страниц
Для каждой страницы:
цель страницы
основные блоки
главный CTA
что должно редактироваться в админке
SEO-задача страницы

5. Функционал
Формы:
Поиск:
Фильтры:
Модальные окна:
Интеграции:
Уведомления:
Личный кабинет если нужен:

6. WordPress и админка
Типы записей:
ACF-поля:
Меню:
Повторяемые блоки:
Редактируемые элементы:
Права пользователей:

7. SEO
URL-структура:
Title и Description:
H1:
Микроразметка:
Sitemap:
Robots.txt:
Canonical:
Хлебные крошки:

8. Адаптивность
Десктоп:
Планшет:
Мобильная версия:
Особые состояния блоков:

9. Технические требования
Скорость:
Безопасность:
Кэширование:
Форматы изображений:
Совместимость с браузерами:

10. Материалы от заказчика
Логотип:
Тексты:
Фото:
Доступы:
Ссылки на примеры:
Юридическая информация:

11. Результат работ
Что должно быть передано:
Что проверяется перед запуском:
Какие доступы остаются у заказчика:

12. Открытые вопросы
[список того, что нужно уточнить]

Как адаптировать под себя

Готовый шаблон не нужно использовать как бетонную плиту. Его нужно адаптировать под тип сайта. Для лендинга достаточно меньше страниц, но больше внимания к офферу, первому экрану, формам и CTA. Для сайта услуг важны структура услуг, страницы под направления, FAQ, портфолио, отзывы и внутренние ссылки. Для каталога важны карточки, фильтры, категории, атрибуты, поиск и админка.

Если сайт будет на WordPress, отдельно опишите, что должно редактироваться без разработчика. Это критично. Заказчик часто говорит «хочу всё редактировать», но на практике ему нужно редактировать не всё, а конкретные элементы: заголовки, тексты, изображения, карточки, цены, преимущества, FAQ, этапы, контакты, ссылки, SEO-поля. Чем точнее это описано, тем меньше хаоса потом.

Если сайт делается по макету, добавьте требования к состояниям. Что происходит при наведении? Как выглядит ошибка формы? Как выглядит успешная отправка? Что делать, если в карточке длинный заголовок? Как блок ведёт себя на мобильном? Есть ли пустые состояния? Дизайн это не только красивая картинка в Figma, а ещё куча реальных ситуаций, которые обычно всплывают после запуска.

Если сайт должен продвигаться в поиске, добавьте SEO-блок. Не просто «сделать SEO». Нужно указать URL-структуру, мета-поля, шаблоны title, хлебные крошки, sitemap, robots.txt, canonical, микроразметку, заголовки, посадочные страницы и требования к скорости. Фраза «нужно SEO» в ТЗ примерно так же полезна, как «нужно красиво» в дизайне.

Для удобства можно использовать короткую таблицу проверки перед отправкой ТЗ исполнителю.

Что проверить в ТЗ	Хорошо	Плохо
Цель сайта	Получать заявки на конкретные услуги	Сделать современный сайт
Структура	Есть список страниц и задача каждой	Просто «главная и остальные разделы»
Функционал	Описаны формы, уведомления, фильтры	«Форма обратной связи как обычно»
WordPress	Указано, что редактируется в админке	«Чтобы всё можно было менять»
Контент	Понятно, кто даёт тексты и фото	«Потом разберёмся»
SEO	Есть URL, мета, sitemap, schema, скорость	«Нужно оптимизировать»
Адаптивность	Описаны мобильные состояния	«Чтобы нормально смотрелось»

Типовые ошибки

Первая ошибка — просить ChatGPT написать ТЗ без вводных. Он напишет. Он вообще редко обижается на плохие задачи. Но результат будет слишком общим: красивые разделы, стандартные требования, немного SEO, немного адаптивности, немного безопасности. Проблема в том, что такое ТЗ не помогает принимать решения.

Вторая ошибка — воспринимать ответ ChatGPT как финальный документ. Это черновик. Его нужно проверить, сократить, уточнить, адаптировать под проект, убрать лишнее и добавить то, что модель не знает. Особенно если речь о WordPress, ACF, интеграциях, нестандартных шаблонах или сложной структуре.

Третья ошибка — не отделять желания от требований. «Хочется красиво», «нравится как у конкурента», «можно добавить блог», «может быть личный кабинет» — это не одно и то же. В ТЗ важно разделять обязательное, желательное и возможное позже. Иначе проект раздувается ещё до старта.

Четвёртая ошибка — не описывать контент. Кто пишет тексты? Кто готовит фото? Есть ли логотип? Нужны ли обложки? Кто заполняет услуги? Будут ли статьи? Если это не указать, в конце разработки внезапно окажется, что сайт есть, а контента нет. Очень современно: интерфейс для пустоты.

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

Шестая ошибка — не фиксировать ограничения. Бюджет, сроки, техническая база, хостинг, готовые материалы, необходимость переноса старого контента, SEO-риски, текущие URL — всё это влияет на ТЗ. Если ограничения не указать, они всё равно появятся. Просто позже и громче.

Седьмая ошибка — смешивать ТЗ и договор. ТЗ описывает, что нужно сделать. Договор фиксирует условия, оплату, сроки, ответственность и порядок приёмки. Это связанные документы, но не одно и то же.

После проверки ТЗ его уже можно использовать для оценки объёма и старта проекта. Если нужно заказать разработку сайта по ТЗ, такой документ помогает заранее согласовать страницы, функционал, WordPress-админку, адаптивные состояния, SEO-требования и границы работ — то есть уменьшает количество решений, которые иначе пришлось бы принимать уже в процессе разработки.