Как проверить вёрстку до приёмки, не умея верстать

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

Что именно мы проверяем, когда проверяем вёрстку?

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

Поэтому проверка делится на две половины. Первая отвечает на вопрос, совпадает ли страница с тем, что вы утвердили. Вторая касается того, что происходит там, где макет молчит. Заказчики обычно делают первую и пропускают вторую, хотя именно во второй ломается то, что видят клиенты.

Если вы принимаете сайт целиком, вёрстка составляет только часть приёмки. Скорость, индексация, формы и доступы разобраны в статье про приёмку сайта у подрядчика, здесь речь только о том, как свёрстана страница.

Должна ли вёрстка совпадать с макетом до пикселя?

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

Удобно разделить расхождения на три группы.

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

Как сравнить вёрстку с макетом, не имея программ дизайнера?

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

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

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

Что происходит между нарисованными ширинами?

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

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

Телефон проверяется отдельно, на настоящем устройстве. Про то, что эмулятор в браузере не показывает, есть разбор о том, как посмотреть сайт на телефоне. На телефоне заодно проверьте кнопки пальцем. По рекомендации web.dev нажимаемый элемент должен быть не меньше примерно 48 пикселей, а между соседними нужно около 8. Пальцем пиксели не измерить, поэтому на деле смотрите, попадаете ли вы с первого раза и не задеваете ли соседнюю кнопку.

Как понять, что текст — это текст, а не картинка?

Нажмите на странице Ctrl+A (на Mac Cmd+A). Браузер выделит весь текст. Невыделенный заголовок или абзац почти наверняка нарисован картинкой; кнопки и меню бывают невыделяемыми и так, на них не смотрите. Частая находка: заголовок первого экрана, вшитый в фотографию. Такой текст не прочитает поисковик, да и поправить его ваш менеджер без дизайнера уже не сможет.

Второй приём: Ctrl+F. Найдите на странице слово, которое точно есть в заголовке. Не нашлось, значит браузер его не видит как текст.

Заодно увеличьте масштаб страницы до 200 % (Ctrl и колесо мыши, назад Ctrl+0). Нормальная вёрстка перестраивается: колонки становятся уже или уходят друг под друга. Плохая обрезает текст или накладывает его на соседние блоки.

Что будет, когда вы впишете настоящие тексты?

Макет рисуют на удобных текстах: заголовок в три слова, имя «Анна», цена из четырёх цифр. Живой контент длиннее. Название услуги занимает две строки, а адрес приходит с корпусом и строением.

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

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

Прыгает ли страница, пока грузится?

Вы начинаете читать, и текст уезжает вниз, потому что сверху догрузилась картинка. Или тянетесь к кнопке, а на её место выезжает баннер. Это называется сдвигом макета, и у него есть мерило: показатель CLS (накопленный сдвиг макета). По web.dev хороший результат — 0,1 и меньше.

Две самые частые причины web.dev называет прямо: картинки без заданных ширины и высоты и подмена шрифта во время загрузки. Обе на совести вёрстки.

Увидеть прыжки глазом, кстати, проще всего на телефоне через мобильный интернет: откройте страницу и не трогайте экран. Число покажет аудит Lighthouse. В Chrome нажмите F12, откройте вкладку Lighthouse и запустите проверку, в отчёте будет строка Cumulative Layout Shift. Цифра из одного прогона на вашем компьютере служит ориентиром: web.dev советует мерить по реальным посещениям, и это делается после запуска.

Можно ли пройти сайт без мыши?

Положите мышь в сторону, откройте сайт в Chrome или Яндекс Браузере и нажимайте Tab. В Safari на Mac клавиша Tab по умолчанию прыгает только по полям форм, и там легко принять настройку браузера за ошибку вёрстки. Фокус, то есть элемент, который сейчас принимает ввод с клавиатуры, должен переходить по ссылкам, кнопкам и полям формы по порядку, а вокруг текущего элемента должна быть видна рамка. Shift+Tab ведёт назад.

Если рамки нет, её почти наверняка убрали в вёрстке, потому что она «портила вид». Web.dev прямо пишет, что видимый индикатор фокуса критически важен: без него человек не понимает, где находится на странице. Убедитесь, что до формы заявки можно дойти и отправить её одной клавиатурой.

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

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

Герман Садуртдинов

Хватает ли контраста, чтобы текст читался?

Светло-серый текст на бежевом фоне красиво смотрится на мониторе дизайнера и плохо читается на телефоне в солнечный день. У контраста есть мерило: по web.dev минимум для обычного текста составляет 4,5 к 1, для повышенного уровня доступности нужно 7 к 1.

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

Заодно в том же отчёте видно картинки без альтернативного текста, ведь Lighthouse проверяет и его. Атрибут alt Google называет самым важным для описания изображения, и набивать его ключевыми словами там же не советуют.

Какие состояния элементов должны быть сделаны?

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

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

Как записать замечание, чтобы его не оспорили?

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

Например: «Главная, блок „Услуги“, окно шириной около 900 пикселей, Chrome на Windows. Третья карточка переносится на новую строку и становится уже двух других, скриншот 3. В макете три карточки одной ширины в ряд, макет страница 2». Ширину окна видно в режиме устройства: F12, затем Ctrl+Shift+M, размер пишется над страницей.

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

Где заканчивается то, что заказчик проверит сам?

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

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

Частые вопросы

Читайте также

Сайт и подрядчик Хостинг: на кого оформлять и как забрать при разрыве (2026) Разбор · 12 мин Сайт и подрядчик Оплата сайта по этапам: аванс, транши и что фиксировать (2026) Разбор · 11 мин Сайт и подрядчик Акт выполненных работ по сайту: что подписывать (2026) Разбор · 11 мин Сайт и подрядчик На кого оформлять домен и почему это важно (2026) Разбор · 12 мин Сайт и подрядчик Как посмотреть сайт на телефоне: проверка адаптивности для заказчика (2026) Инструкция · 10 мин Сайт и подрядчик SSL-сертификат: зачем нужен и кто его продлевает (2026) Разбор · 10 мин

Герман Садуртдинов — дизайнер, основатель студии V3 Creative. Пишу о том, как дизайн влияет на деньги, а не на вкус.

Об авторе · ← Все статьи