Как написать сайт с помощью GPT: пошаговая инструкция

GPT полезен при создании небольшого сайта не как кнопка «сделай красиво», а как исполнитель с понятным контрактом. Вы задаёте цель страницы, исходные данные и ограничения, получаете Site или код, а затем проверяете результат в браузере. Если пропустить последний этап, получится демонстрационный макет, а не рабочая страница.

Сначала выберите результат: Site или код

Для простой страницы есть два маршрута.

ChatGPT Site подходит, если нужен быстро опубликованный одностраничный сайт без отдельной интеграции модели. В ChatGPT пользователь описывает нужный website в Work на вебе либо в Work/Codex в desktop app и при необходимости добавляет @Sites. К запросу можно приложить тексты, файлы, ссылки и ограничения. Функция доступна не каждому аккаунту: влияют план, рабочая область, регион и текущий rollout. Актуальные условия и порядок создания описаны в справке OpenAI по ChatGPT Sites.

Код нужен, если страницу предстоит редактировать вручную, хранить в Git или размещать на своём хостинге. GPT может вернуть HTML, CSS и JavaScript либо React-компонент. Для поддерживаемых HTML и React в ChatGPT может быть доступен Preview, но набор действий зависит от плана, устройства, модели и rollout. Кодовые блоки можно читать, копировать и править — это уже обычный исходный код, а не магическая публикация; правила работы с ними собраны в справке OpenAI о writing blocks и code blocks.

Не смешивайте этот сценарий с OpenAI API. API нужен, когда вы хотите встроить модель в собственное приложение: например, сделать форму, которая отправляет запрос на ваш сервер. Для лендинга с текстом, блоками и кнопкой достаточно Site или сгенерированного кода.

Если для рабочего процесса необходим платный план с подходящими лимитами или функциями, условия стоит проверить отдельно перед оформлением. Например, подписка ChatGPT через Amber Market подключается на аккаунте покупателя; в каталоге доступны варианты на один месяц, но цена, наличие и доступность функций зависят от текущих условий. Сама подписка не гарантирует доступ к Sites в любом регионе.

Как поставить задачу GPT

Плохой запрос выглядит так: «Сделай сайт для сервиса». В нём нет критерия готовности. Модель сама придумает аудиторию, структуру, тексты и даже действие, которое должна выполнять кнопка. Потом спорить с результатом придётся по каждому пункту.

Рабочий промпт передаёт входные данные в том же порядке, в котором вы будете проверять страницу:

Создай одностраничный сайт для [продукт или услуга].

Цель страницы: [какое действие должен выполнить посетитель].
Аудитория: [кто читает страницу и что ему важно].

Блоки:
- hero с коротким обещанием и основной кнопкой;
- преимущества;
- как это работает;
- FAQ;
- финальный CTA.

Исходные данные:
- название: [название];
- описание: [2–4 точных факта];
- ссылка кнопки: [URL или временный placeholder];
- контакты: [если нужны].

Ограничения:
- стиль: [цвета, настроение, референс без копирования];
- адаптивная вёрстка для телефона и десктопа;
- семантический HTML;
- не выдумывай цены, отзывы, характеристики и юридические обещания.

Сначала покажи структуру страницы и список допущений.
Затем создай Site или выдай код в выбранном формате [HTML/CSS/JS или React].
После генерации дай чек-лист проверки ссылок, формы, мобильной версии и текста.

Квадратные скобки здесь заменяются вашими данными. Если у вас есть логотип, таблица характеристик или готовый текст, приложите файл, а не пересказывайте его по памяти. Ссылку на страницу тоже лучше передать явно: иначе GPT может поставить заглушку или придумать адрес.

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

Что проверить в полученном результате

После ответа GPT не переходите сразу к публикации. Сначала откройте Preview или локально запустите код и пройдите страницу как посетитель.

Проверяйте последовательно:

1. Смысл. За несколько секунд понятно, что предлагает страница, кому и какое действие нужно выполнить. Заголовок не должен обещать больше, чем есть в исходных данных.
2. Данные. Название, контакты, цены, условия и характеристики совпадают с переданными материалами. Выдуманный отзыв — не безобидная декоративная деталь, а ложное утверждение.
3. Ссылки и кнопки. Каждая кнопка ведёт в ожидаемое место. У временных # и example.com не должно быть шанса попасть в публикацию.
4. Форма. Поля имеют понятные подписи, обязательность обозначена, ошибка отображается рядом с полем. Если серверной обработки нет, не называйте форму рабочей: HTML-форма без обработчика только собирает видимость интерфейса.
5. Мобильная версия. Проверьте узкий экран: нет ли горизонтального скролла, обрезанного текста, слишком маленьких кнопок и наложения блоков.
6. Интерактивность. Откройте меню, FAQ, модальные окна и другие элементы. Клавиатурой проверьте фокус и возможность добраться до основного действия.
7. Технический результат. В коде проверьте консоль браузера, отсутствие сломанных ресурсов и корректность путей к изображениям. В Site отдельно проверьте опубликованный адрес, а не только режим предпросмотра.

Для Site предпросмотр — это не формальность: перед публикацией нужно посмотреть страницу, запросить исправления и проверить содержимое, ссылки, доступ и интерактивность. После публикации deployment URL становится production URL, поэтому именно его следует открыть в отдельном окне и проверить ещё раз. Действия и ограничения описаны в документации OpenAI по созданию и управлению Sites.

Как просить исправления

Не отправляйте сообщение «сделай лучше». Оно не задаёт точки отказа. Ссылайтесь на конкретный элемент и ожидаемое поведение:

В мобильном Preview на ширине 390 px кнопка в hero выходит за пределы карточки.
Исправь только адаптивные стили этого блока, сохрани текст и порядок секций.
После исправления проверь:
- ширину кнопки на 390 px;
- отсутствие горизонтального скролла;
- читаемость заголовка;
- переход основной кнопки по адресу /contact.
Покажи, что изменилось.

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

Что делать, если Sites недоступен

Отсутствие пункта Sites не означает, что задача остановилась. Проверьте план, рабочую область и доступность функции для аккаунта. Если после этого функция недоступна, попросите GPT выдать HTML/CSS/JavaScript или React-код, откройте Preview, внесите правки и разместите результат на отдельном хостинге. Публикация сайта и интеграция GPT — разные задачи.

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

Если нужно только отредактировать полученный черновик, удобно использовать Canvas для текста и кода. А общий сценарий создания страницы с ChatGPT собран в отдельной инструкции по созданию сайта.

Короткая схема работы

1. Опишите цель, аудиторию, блоки, исходные данные и ограничения.
2. Выберите Site или код, не подменяя этим выбором интеграцию через API.
3. Попросите сначала показать структуру и допущения.
4. Сгенерируйте страницу и проверьте Preview или код.
5. Исправляйте конкретные ошибки с измеримыми критериями.
6. Проверьте ссылки, текст, форму, мобильный экран и интерактивность.
7. Только после этого публикуйте; для Site повторите проверку на production URL.

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