Сайт с ИИ начинается не с просьбы «сделай современный сайт», а с карты страниц и ответов, которые человек должен найти. Для примера возьмём небольшой сайт мастерской керамики: посетителю нужно понять, какие есть занятия, где они проходят и как записаться. Это статический сайт: страницы описывают услугу и ведут к форме связи; аккаунты, личный кабинет и каталог с меняющимися остатками не нужны.
1. Составь структуру до визуального промпта
Сделай простую карту:
| URL | Задача посетителя | Основной блок | Следующее действие |
|---|---|---|---|
/ |
Понять, что предлагает мастерская | описание занятий и кому они подходят | открыть расписание |
/classes/ |
Сравнить занятия | формат, длительность, место, цена от владельца | выбрать занятие |
/contact/ |
Найти адрес и способ связи | адрес, часы ответа, контакты | написать или позвонить |
Проверь, не дублирует ли каждая страница одну и ту же общую фразу. Если на сайте один главный продукт, три почти одинаковых страницы могут запутать больше, чем помочь. Для ранней версии можно оставить одну страницу с якорями, если разделов немного.
Промпт должен передавать структуру и ограничения:
Создай статический сайт мастерской керамики из трёх страниц: главная, занятия, контакты. На каждой странице общая навигация и ссылка на главную. Для занятия показывай только переданные поля: название, описание, адрес/формат, продолжительность и цену. Не выдумывай отзывы, результаты учеников, расписание и цены. Используй временные пометки там, где контент ещё не предоставлен. Сначала предложи дерево файлов и короткий план, не подключай базу, регистрацию, аналитику или оплату.
Такой запрос не гарантирует, что модель соблюдёт каждый пункт. После генерации сверь фактические тексты с исходными данными владельца сайта.
2. Проверь файлы, маршруты и навигацию
Для небольшого сайта важны две разные вещи: структура исходников и реальные адреса страниц. Попроси показать дерево файлов, например:
public/
images/
src/
pages/
components/
styles/
Это пример организации, а не обязательный стандарт. Важно, чтобы человек мог понять, где меняются общая навигация, содержимое страниц и стили. Проверь по дереву, где находятся страницы и общие компоненты; прямой ввод маршрутов и повторную загрузку адреса оставь для приёмки опубликованной версии.
HTML даёт документу структуру: заголовки, абзацы, списки и ссылки должны соответствовать их назначению. MDN отдельно объясняет базовый HTML и структуру содержимого (MDN: structuring content, basic HTML syntax). Это помогает проверять, что ссылка — ссылка, а действие — кнопка, вместо набора визуально похожих блоков.
3. Адаптивность — это проверка контента и поведения
Не проси «сделать адаптивно» и не заканчивай проверку одним скриншотом. Проверь главную, список занятий и контакты на узкой и широкой ширине. Открой меню, нажми каждый CTA, попробуй прокрутить таблицу или карточки, увеличь текст браузера и используй клавиатуру.
MDN описывает responsive design как набор подходов к адаптации layout; CSS media queries позволяют применять стили по характеристикам устройства/viewport (responsive design, media queries). Поэтому сформулируй конкретно: на узком экране навигация не перекрывает заголовок, карточки становятся одной колонкой, длинный адрес не выталкивает страницу по горизонтали.
4. Metadata и доступность
Для каждой страницы задай осмысленный <title>, краткое описание и понятный заголовок H1. Они должны отличать, например, «Занятия мастерской» от «Контакты мастерской». В <head> размещаются metadata документа; MDN объясняет назначение этого раздела и распространённых элементов (MDN: webpage metadata). Google может формировать заголовок результата поиска по нескольким источникам, а сниппет выбирает по содержимому запроса; не обещай, что заданное поле будет показано дословно (title links, snippets).
Проверь, что изображения имеют подходящий альтернативный текст, ссылки различимы вне контекста «нажми сюда», а форма имеет связанные подписи. W3C WAI предлагает отдельные практики для структуры страниц и форм (page structure, forms). Это руководство по проверкам, не заключение о соответствии стандарту.
5. Публикация статического сайта
Сборка должна создать набор статических файлов, а публикация — отдать нужные пути по URL. Cloudflare Pages документирует развёртывание статических файлов, Git-интеграцию и preview deployments как отдельные механизмы; реальная конфигурация конкретного репозитория проверяется в его настройках. О соседнем шаге есть отдельное руководство: развёртывание через Cloudflare Pages.
Единая приёмка опубликованного сайта
Сначала пройди локальную сборку и preview, затем открой фактический адрес публикации. Для каждой страницы введи URL напрямую и обнови её; проверь меню, логотип, изображения и несуществующий путь. На узком экране открой меню, пройди страницу клавиатурой и проверь форму. Если заявка уходит внешнему обработчику, отправь тест без личных данных и подтверди получение у адресата. Локальная страница, preview и успешный deployment проверяют разные части пути: ни один из них сам по себе не доказывает доставку формы или привязку домена.