Макет сайта: что это, из чего состоит и как его сделать и принять в 2026 году

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

Ключевые выводы

• Макет, wireframe и prototype — разные артефакты: wireframe показывает структуру, mockup — внешний вид, prototype — поведение.
• Хороший макет включает не только главную, но и внутренние страницы, мобильные версии и служебные состояния: ошибки форм, 404, пустые экраны, меню.
• Работа идёт в порядке: бриф, структура, wireframe, визуальный дизайн, прототип, передача разработчику.
• SEO-специалисту нужно проверить макет до вёрстки: заголовки H1–H3, блоки под текст, эквивалентность мобильной версии, риски для CLS и контраст.
• Готовность макета определяется не красотой, а тем, можно ли по нему сверстать страницу без дополнительных вопросов к дизайнеру.

Что такое макет сайта и чем он отличается от wireframe, прототипа и вёрстки

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

Чтобы не путать артефакты, удобно сравнивать их по задаче, детализации и интерактивности. Определения в таблице опираются на общепринятую UX-терминологию: Nielsen Norman Group описывает wireframe как схематичный набросок раскладки, показывающий структуру и функциональность до визуального дизайна. Формулировки перед публикацией стоит сверить с глоссарием NN/g, поскольку здесь они даны по вторичным пересказам.

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

Отдельно стоит развести два похожих слова. «Мокап» в смысле визуализации логотипа или интерфейса на фотографии устройства — презентационный приём, а не рабочий макет для разработки. Карта сайта в начале проекта — тоже не XML-sitemap для поисковиков: первая описывает структуру разделов для людей и команды, вторая — файл со списком URL для роботов.

Практический вывод: прежде чем согласовывать «макет», выясните, какой артефакт имеется в виду, и закрепите это в ТЗ или брифе. Ориентиром для структуры технического задания иногда называют ГОСТ 34.602-2020, но применимость стандарта к вашему проекту нужно проверять отдельно.

Из чего состоит макет сайта: чек-лист экранов и состояний

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

Ниже — чек-лист для проверки комплектности. Его можно использовать как приложение к ТЗ на дизайн.

• Типы страниц.Главная, страница каталога или раздела, карточка товара или услуги, статья блога, контакты, страницы о компании, корзина и оформление заказа, если они есть.
• Версии экранов.Десктоп, планшет, смартфон. Количество контрольных ширин определяется точками, где макет перестаёт быть удобным, а не конкретными моделями устройств: на этом принципе строится адаптивный дизайн по материалам Яндекс Практикума.
• Общие компоненты.Шапка, подвал, меню, хлебные крошки, формы, кнопки, карточки, модальные окна, пагинация, фильтры.
• Состояния элементов.Обычное, наведение, фокус, нажатие, неактивное, ошибка, успешная отправка.
• Служебные страницы.Страница 404, пустые результаты поиска, пустая корзина, страница после отправки формы.
• Наложения.Cookie-баннер, всплывающие окна, мобильное меню в раскрытом виде.
• Реальный контент.Настоящие заголовки и тексты вместо lorem ipsum, иначе длина строк и высота блоков в вёрстке будут другими.
• Спецификация для разработчика.Отступы, шрифты, цвета, размеры, правила адаптации, экспорт графики.

Если ресурс большой, макет часто дополняют UI-kit или дизайн-системой: библиотекой компонентов, которая сохраняет единый вид при развитии сайта. Для лендинга из нескольких блоков отдельная дизайн-система обычно избыточна, но набор стилей и компонентов всё равно должен быть описан.

Итог раздела: комплектность макета проверяется списком экранов и состояний, а не количеством нарисованных страниц.

Как сделать макет сайта: этапы, результаты и ответственные

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

1. Бриф и цели.Результат: описание аудитории, задач сайта, конкурентов и ограничений. Ответственные: заказчик, маркетолог, менеджер проекта.
2. Структура сайта.Результат: карта разделов и страниц, основные пользовательские сценарии. Ответственные: UX-проектировщик, SEO-специалист, который сверяет структуру с семантическим ядром.
3. Wireframe.Результат: схематичные экраны ключевых страниц без цвета и графики. Условие: к этому моменту должны быть известны хотя бы черновые тексты или их объём.
4. Визуальный дизайн.Результат: mockup страниц с сеткой, типографикой, цветами и компонентами для каждой контрольной ширины экрана. Ответственный: веб-дизайнер.
5. Прототип.Результат: кликабельный сценарий для проверки логики, например покупки или заявки. Этот шаг оправдан для сложных интерфейсов; для простого сайта-визитки его можно заменить просмотром экранов вместе с заказчиком.
6. Передача в вёрстку (handoff).Результат: структурированный файл с компонентами, спецификацией, выгрузкой графики и описанием состояний. Ответственные: дизайнер и верстальщик.

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

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

Шаблон или индивидуальный макет: как выбрать

Выбор между готовым шаблоном и индивидуальным макетом определяется пятью критериями: уникальность, сроки, бюджет, интеграции и масштаб проекта. В конструкторах вроде Tilda, Mottor, Creatium или Setup макет часто сводится к выбору шаблона и настройке блоков. В индивидуальной разработке дизайн проектируется под задачи бизнеса.

Шаблон не освобождает от проверки: в нём тоже нужно убедиться в адаптивности, доступности контраста, структуре заголовков и скорости загрузки. Проверьте лицензию, если берёте макет с площадки готовых решений, например ThemeForest. Dribbble при этом — витрина дизайн-работ и источник референсов, а не гарантированный магазин готовых макетов; условия использования конкретной работы нужно уточнять у автора.

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

Figma и альтернативы: как выбрать инструмент в 2026 году

Figma остаётся самым часто упоминаемым облачным редактором для макетов благодаря совместной работе, компонентам и режиму разработчика. Но для российских команд ключевой вопрос в 2026 году — не функции, а доступность, способ оплаты и условия использования. Эти условия менялись, а подтверждённых актуальных данных на дату написания в материалах нет, поэтому перед выбором инструмента проверьте их на текущий день.

Среди альтернатив источники называют Penpot, Lunacy, Pixso и Sketch, а среди российских решений — «Спектр» (Ростелеком) и «Линию». Статус каждого продукта и возможности импорта файлов .fig нужно проверять отдельно, не полагаясь на устаревшие обзоры.

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

Что SEO-специалисту проверить в макете до вёрстки

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

Особенно внимательно проверяйте мобильную версию. Согласно документации Google Search Central, Google использует для индексирования и ранжирования мобильную версию сайта, поэтому контент на смартфоне должен быть эквивалентен десктопному. На мобильных допустимо менять оформление, например применять аккордеоны и вкладки, но скрытие содержимого на смартфонах рискованно. Google также рекомендует адаптивный дизайн как самый простой для поддержки вариант и не советует отдельные мобильные URL.

Яндекс проверяет адаптивность основного домена и мобильного поддомена и стремится показывать в мобильной выдаче мобильную версию сайта. Формулировки справки Яндекс Вебмастера о мобильных сайтах нужно сверять с текущей версией, поскольку названия разделов могут меняться. Не опирайтесь на старые утверждения о доле мобильного трафика: без свежих данных Яндекса или Mediascope такие цифры нельзя использовать как факт 2026 года.

Core Web Vitals влияют на решения в макете напрямую. По данным web.dev, LCP измеряет скорость загрузки основного содержимого, INP — отзывчивость, CLS — визуальную стабильность. Страница считается прошедшей оценку, если все три показателя соответствуют целевым значениям на 75-м процентиле: LCP не более 2,5 с, INP не более 200 мс, CLS не более 0,1. INP заменил FID в марте 2024 года, но во многих старых русскоязычных статьях по-прежнему упоминается FID. Пороги стоит сверить со страницей web.dev перед публикацией и перед использованием в ТЗ.

Чек-лист SEO-специалиста для макета:

• На каждой странице один понятный H1 и логичная иерархия H2–H3, видимая уже в wireframe.
• Есть место под текст нужного объёма в нужных блоках, а не только короткие подписи к карточкам.
• Мобильная версия содержит тот же основной контент, что и десктопная; аккордеоны и вкладки не прячут важные тексты и ссылки.
• Для изображений, баннеров, видео и рекламных блоков заданы пропорции или зарезервированное место, чтобы снизить риск сдвигов макета (CLS).
• Главное изображение первого экрана не перегружено эффектами, которые усложняют загрузку и влияют на LCP.
• Предусмотрены хлебные крошки, блоки перелинковки, фильтры и пагинация, если они есть в структуре.
• Контраст обычного текста не ниже 4,5:1, крупного — не ниже 3:1 (WCAG 2.2, критерий 1.4.3, уровень AA); для интерактивных элементов проверьте минимальный размер цели по критерию 2.5.8.

Эти пункты не гарантируют рост позиций: ранжирование зависит от множества факторов. Но они снижают риск технических ограничений, которые потом приходится устранять в готовом коде.

Приёмка: что делать, если вёрстка не соответствует макету

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

Чек-лист заказчика при приёмке макета: утверждена структура страниц; нарисованы все типы страниц и версии под смартфон и десктоп; описаны состояния кнопок, форм и меню; использованы реальные тексты или их точный объём; передан исходный файл и спецификация; зафиксировано число итераций правок. Если хотя бы один пункт не выполнен, передача в вёрстку преждевременна.

Когда вёрстка не совпадает с макетом, помогает разбор по схеме «проблема — вероятная причина — проверка — решение».

Если расхождения возникли из-за отсутствия экрана или состояния в макете, это изменение задачи, а не дефект вёрстки. Чётко разделяйте эти случаи в договоре, чтобы не спорить о том, кто оплачивает доработку.

Три типовые структуры страниц для разбора

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

Лендинг одной услуги

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

Интернет-магазин

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

Корпоративный сайт или блог

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

Что утвердить до передачи макета в разработку

Перед передачей в вёрстку заказчику и команде стоит пройти короткий порядок решений. Он помогает убедиться, что макет сайта достаточно проработан и не потребует переделок после старта программирования.

1. Подтвердите значение термина: что именно вы получаете — wireframe, статичный макет или кликабельный прототип.
2. Сверьте комплектность по чек-листу: типы страниц, версии под разные экраны, состояния элементов и служебные страницы.
3. Попросите SEO-специалиста проверить заголовки, места под текст, эквивалентность мобильной версии и резерв места под изображения.
4. Проверьте доступность: контраст и размеры интерактивных элементов по критериям WCAG 2.2.
5. Убедитесь, что исходный файл и спецификация передаются заказчику, а инструмент доступен команде на текущий день.
6. Зафиксируйте в договоре число итераций правок и порядок приёмки вёрстки по макету.

Если все шесть пунктов закрыты, макет можно считать готовым к разработке. Если нет — быстрее и дешевле доработать проект на этом этапе, чем исправлять уже готовую вёрстку.