Я обычно не считаю верстку готовой в тот момент, когда страница впервые совпала с макетом. Это только половина работы. Настоящая проверка начинается позже: когда сайт открывают на телефоне, меняют ширину экрана, вставляют длинный заголовок и нажимают все, что должно нажиматься.
И вот там часто всплывают мелочи, которые на макете не видны: горизонтальная прокрутка, обрезанный текст, слишком маленькая кнопка, форма без понятной ошибки или карточка, которая ломает всю сетку. Поэтому тестирование верстки сайта лучше проводить до публикации, а не после первых жалоб пользователей.
Коротко: чтобы проверить верстку сайта, нужно сравнить страницу с макетом, протестировать мобильную, планшетную и десктопную версии, открыть сайт в разных браузерах, проверить формы, кнопки, ссылки, меню, HTML/CSS и повторно пройти ключевые сценарии после исправления ошибок.
Если верстка делалась на заказ, проверка также помогает понять, насколько результат соответствует договоренностям. Отдельно полезно заранее разобраться, из чего складывается стоимость верстки сайта, потому что адаптивность, тестирование и исправление багов напрямую влияют на объем работ.
Что такое тестирование верстки сайта и зачем оно нужно
Тестирование верстки сайта — это проверка того, как сверстанные страницы выглядят, работают и реагируют на разные условия после разработки. Это не только поиск визуальных багов вроде съехавшего блока. Сюда входит визуальная, техническая и пользовательская проверка.
Для себя я делю проверку верстки на три простых вопроса: страница похожа на макет, она нормально работает на разных устройствах и пользователю удобно с ней взаимодействовать. Если хотя бы один пункт провален, сайт может выглядеть недоработанным даже при сильном дизайне.
Проверка нужна перед запуском новой страницы, после редизайна, после правок в шаблонах, при добавлении новых блоков и перед рекламной кампанией. Даже небольшое изменение CSS может сломать меню, карточку товара, форму заявки или мобильную версию.
| Что проверяется | Зачем это нужно | Пример ошибки |
|---|---|---|
| Внешний вид | Чтобы страница соответствовала макету и выглядела аккуратно | Неверные отступы, разные размеры кнопок, съехавшие блоки |
| Адаптивность | Чтобы сайт был удобен на телефонах, планшетах и десктопах | Горизонтальная прокрутка, мелкий текст, сломанное меню |
| Кроссбраузерность | Чтобы страница корректно отображалась в популярных браузерах | Проблемы со шрифтами, формами, сетками или sticky-элементами |
| Интерактив | Чтобы пользователь мог нажимать, отправлять, открывать и закрывать элементы | Не работает кнопка, форма не показывает ошибку, меню не открывается |
| HTML и CSS | Чтобы разметка была устойчивой и не ломалась после обновлений | Незакрытый тег, конфликт стилей, неправильная вложенность |
Тестирование не гарантирует полное отсутствие багов. Оно снижает риск, помогает поймать критичные ошибки до публикации и делает запуск спокойнее.
Краткий чек-лист проверки верстки сайта перед запуском
Этот чек-лист можно использовать как быструю проверку перед публикацией страницы. Он подходит для лендинга, корпоративного сайта, блога, интернет-магазина и страницы услуги.
- Сравнить страницу с макетом: сетка, отступы, шрифты, цвета, изображения, кнопки.
- Проверить мобильную, планшетную, ноутбучную и широкую версии.
- Открыть страницу в Chrome, Safari, Firefox и Edge.
- Проверить меню, кнопки, ссылки, формы, попапы, вкладки и слайдеры.
- Протестировать длинные заголовки, короткие описания, разные изображения и пустые состояния.
- Убедиться, что нет горизонтальной прокрутки и наложения блоков.
- Проверить HTML/CSS через валидаторы и ошибки в консоли браузера.
- Проверить базовую доступность: alt, label, фокус с клавиатуры, контраст текста.
- Повторить проверку после исправлений.
На практике этот список лучше проходить не один раз. Первый проход показывает явные ошибки, второй — последствия исправлений, третий нужен для финального просмотра перед публикацией.
Что именно нужно проверять в верстке сайта
Проверка верстки сайта начинается с визуального осмотра. Нужно открыть страницу и сравнить ее с макетом: совпадают ли сетка, ширина блоков, отступы, размеры шрифтов, цветовые акценты, расположение кнопок и изображений.
Дальше стоит смотреть не только на “красиво или некрасиво”, а на устойчивость страницы. Верстка должна выдерживать реальные тексты, разные размеры изображений, длинные заголовки, пустые состояния и ошибки в формах.
- Сетка и отступы: блоки не должны прилипать друг к другу, ломать ритм страницы или выпадать из контейнера.
- Текст: заголовки, абзацы и подписи не должны обрезаться, наслаиваться или становиться слишком мелкими.
- Изображения: картинки не должны растягиваться, терять пропорции, закрывать текст или ломать высоту блока.
- Кнопки и ссылки: элементы должны выглядеть кликабельными и вести туда, куда ожидает пользователь.
- Формы: поля, подсказки, ошибки, чекбоксы и кнопка отправки должны работать предсказуемо.
- Интерактивные блоки: меню, попапы, слайдеры, вкладки и аккордеоны нужно проверять отдельно.
Типичный случай из практики: на демо-контенте карточки товаров выглядят идеально, потому что названия короткие, а изображения одинакового размера. Потом менеджер загружает реальный товар с названием на 80–100 символов — и кнопки уже прыгают по высоте, карточки становятся разными, а сетка выглядит так, будто ее никто не проверял.
| Зона | Что проверить | Когда считать проблемой |
|---|---|---|
| Шапка | Логотип, меню, кнопки, поиск, языковые версии | Меню переносится некрасиво, кнопка выпадает, логотип сжимается |
| Первый экран | H1, подзаголовок, CTA, изображение | Текст залезает на картинку или кнопка уходит за экран |
| Карточки | Одинаковая высота, изображения, кнопки, длинные названия | Карточки разной высоты ломают сетку |
| Формы | Поля, маски, ошибки, успешная отправка | Ошибка не видна или поле невозможно заполнить на телефоне |
| Футер | Ссылки, контакты, соцсети, политика, копирайт | Ссылки не работают или текст слишком мелкий |
Краткий вывод: проверять нужно не только соответствие макету, но и поведение страницы в реальных условиях. Хорошая верстка не разваливается, когда контент становится длиннее, экран меньше, а пользователь нажимает не туда, куда “планировалось”.
Проверка адаптивности на разных экранах
Адаптивность показывает, насколько верстка удобна на разных устройствах. Сайт может идеально выглядеть на ноутбуке разработчика, но быть почти непригодным на смартфоне: меню не открывается, таблица выходит за экран, кнопки слишком близко друг к другу.
Проверка адаптивной верстки работает через несколько контрольных ширин. Обычно смотрят мобильные экраны около 360–430 px, планшеты около 768–1024 px, ноутбуки около 1366–1440 px и широкие экраны от 1920 px. Это не жесткие стандарты, а практичные ориентиры.
Особое внимание стоит уделить типовым страницам: главной, карточке товара или услуги, странице статьи, странице контактов, форме заявки, каталогу, корзине или личному кабинету, если они есть. Одна хорошо проверенная главная страница не означает, что вся верстка сайта готова.
- Меню: открывается ли оно на телефоне, удобно ли закрывается, не перекрывает ли важные элементы.
- Карточки: сохраняют ли читабельность, не становятся ли слишком узкими или разными по высоте.
- Таблицы: получают ли горизонтальную прокрутку внутри блока, а не ломают всю страницу.
- Формы: удобно ли нажимать поля и кнопки пальцем.
- CTA-блоки: остается ли главная кнопка заметной на маленьком экране.
Горизонтальная прокрутка — один из самых частых сигналов, что адаптивность сломана. Обычно она появляется из-за фиксированной ширины блока, слишком широкой таблицы, изображения без ограничения по max-width или длинной строки, которая не переносится.
Эмулятор в DevTools полезен, но его недостаточно. Если есть возможность, проверьте страницу хотя бы на одном реальном смартфоне и одном планшете. Реальное устройство покажет проблемы, которые эмулятор может скрыть: неудобный тап, слишком мелкий текст, странное поведение клавиатуры при заполнении формы.
Для более глубокого понимания темы полезно отдельно изучить адаптивную и мобильную верстку сайта: это поможет не просто находить ошибки, а понимать, почему блоки должны перестраиваться именно так.
Кроссбраузерная проверка верстки
Кроссбраузерная проверка нужна потому, что разные браузеры могут по-разному обрабатывать CSS, шрифты, формы, анимации и некоторые свойства интерфейса. Если сайт хорошо выглядит в Chrome, это еще не значит, что он так же корректен в Safari, Firefox или Edge.
Цель не в том, чтобы добиться пиксельной идентичности во всех браузерах. Это почти всегда избыточно. Важнее, чтобы страница оставалась аккуратной, читаемой, функциональной и удобной для пользователя.
| Элемент | Что может отличаться | Как проверять |
|---|---|---|
| Шрифты | Высота строк, сглаживание, переносы | Сравнить заголовки, меню, кнопки, длинные абзацы |
| Формы | Вид полей, select, checkbox, input type | Заполнить форму, вызвать ошибки, проверить отправку |
| CSS-сетки | Поведение grid/flex, перенос карточек | Смотреть карточки, каталоги, блоки преимуществ |
| Sticky/fixed | Фиксированная шапка, плавающие кнопки | Прокрутить страницу на разных экранах |
| Анимации | Задержки, рывки, некорректные переходы | Проверить hover, открытие меню, попапы, слайдеры |
Минимальный набор для ручной проверки — Chrome, Safari, Firefox и Edge. Если аудитория сайта активно использует мобильные устройства, отдельно стоит проверить мобильный Safari на iPhone и Chrome на Android.
Техническая проверка HTML, CSS и интерактивных элементов
Визуально правильная страница может иметь технические ошибки. Например, незакрытый тег, неправильную вложенность, дублирующиеся id, конфликтующие стили или интерактивный элемент без фокуса с клавиатуры.
Техническая проверка верстки сайта нужна, чтобы убедиться: страница не просто “выглядит нормально”, а собрана устойчиво. Это особенно важно для шаблонов, которые будут использоваться много раз: карточек товаров, статей, страниц услуг, блоков FAQ, форм и модальных окон.
- HTML: проверьте грубые ошибки разметки, вложенность тегов, дубли id, корректность заголовков и атрибутов.
- CSS: посмотрите, нет ли конфликтов, неиспользуемых правил, фиксированных размеров там, где нужна гибкость.
- Состояния элементов: hover, focus, active, disabled и error должны быть заметны и понятны.
- Ссылки и кнопки: все кликабельные элементы должны иметь понятное назначение и корректное действие.
- Формы: проверьте обязательные поля, маски, ошибки, успешную отправку и поведение после сбоя.
- Доступность: изображения должны иметь alt, поля — label, фокус должен быть видимым, подписи — читаемыми.
Базовая доступность — не отдельная “дополнительная опция”, а часть нормальной верстки. Если пользователь не может пройти форму с клавиатуры, не видит фокус или не понимает ошибку в поле, проблема уже влияет на качество интерфейса.
Что подтверждено инструментами, а что требует ручной проверки
| Тип проверки | Что можно подтвердить | Что требует ручной оценки |
|---|---|---|
| HTML-валидатор | Ошибки разметки, незакрытые теги, неверные атрибуты | Удобство структуры для пользователя |
| CSS-проверка | Некорректные свойства, синтаксические ошибки | Насколько аккуратно выглядит страница |
| DevTools | Размеры блоков, DOM, примененные стили, адаптивность | Реальное удобство на устройстве |
| Lighthouse/PageSpeed | Часть проблем производительности, доступности и практик | Все визуальные баги и бизнес-логику |
| Ручная проверка | Сценарии пользователя, внешний вид, кликабельность | Требует времени и внимательности |
Вывод простой: автоматические инструменты полезны, но они не заменяют ручную проверку. Валидатор может найти ошибку в HTML, но не поймет, что кнопка визуально теряется, а важный блок выглядит второстепенным.
Инструменты для проверки верстки сайта
Инструменты нужны не для того, чтобы заменить специалиста, а чтобы быстрее находить ошибки. Лучше использовать несколько категорий: браузерные инструменты, валидаторы, сервисы адаптивности, кроссбраузерные платформы, accessibility-инструменты и ручной чек-лист.
| Инструмент | Для чего нужен | Когда использовать |
|---|---|---|
| Chrome DevTools / Firefox Developer Tools | Проверка DOM, CSS, размеров, адаптивности, ошибок в консоли | На каждом этапе проверки верстки |
| W3C Markup Validation Service | Поиск ошибок в HTML-разметке | После основной визуальной проверки |
| W3C CSS Validation Service | Проверка синтаксиса и спорных CSS-правил | Когда есть подозрение на технические ошибки стилей |
| Lighthouse / PageSpeed Insights | Дополнительная проверка производительности, доступности и практик | Перед публикацией и после крупных правок |
| BrowserStack | Проверка сайта в разных браузерах, ОС и устройствах | Для коммерческих проектов и сложных интерфейсов |
| Responsively App | Одновременный просмотр страницы на нескольких размерах экранов | При активной работе над адаптивностью |
| axe DevTools | Автоматическая проверка части accessibility-проблем | Для форм, интерфейсов, сервисов и сложных страниц |
| Ручной чек-лист | Контроль визуальных, UX- и интерактивных проблем | Перед публикацией и после исправлений |
Для технической проверки можно использовать W3C Markup Validation Service. Он не скажет, хорош ли дизайн, но поможет найти ошибки в разметке.
Для дополнительной оценки качества страницы можно использовать PageSpeed Insights. Он полезен как вспомогательный инструмент, но не заменяет ручную проверку верстки, форм, адаптивности и сценариев пользователя.
Если проект небольшой, достаточно DevTools, нескольких реальных устройств, валидаторов и ручного чек-листа. Если сайт крупный, лучше добавить кроссбраузерные сервисы, accessibility-проверку и отдельное QA-тестирование критичных сценариев.
Порядок тестирования верстки перед публикацией
Я бы не начинал проверку с валидаторов. Сначала нужно пройти страницу глазами пользователя, потом проверить устройства и браузеры, а уже после этого добивать технические ошибки. Так тестирование не превращается в хаотичное открывание вкладок и случайный поиск багов.
- Сравните страницу с макетом. Проверьте сетку, отступы, шрифты, цвета, изображения, кнопки и расположение блоков.
- Проверьте ключевые блоки. Шапка, первый экран, карточки, формы, CTA, футер и повторяющиеся компоненты должны работать одинаково аккуратно.
- Протестируйте адаптивность. Посмотрите мобильные, планшетные, ноутбучные и широкие экраны.
- Откройте страницу в разных браузерах. Проверьте Chrome, Safari, Firefox, Edge и мобильные браузеры, если они важны для аудитории.
- Нажмите все интерактивные элементы. Кнопки, ссылки, формы, меню, попапы, вкладки и слайдеры должны реагировать предсказуемо.
- Проверьте реальные данные. Длинные заголовки, короткие описания, пустые блоки и разные изображения часто находят ошибки лучше тестового контента.
- Запустите технические проверки. Используйте валидаторы, DevTools и дополнительные инструменты качества страницы.
- Повторите проверку после исправлений. Исправление одного бага может создать новый, особенно в CSS.
Для простого лендинга такая проверка может занять меньше времени, чем для интернет-магазина или сервиса с личным кабинетом. Чем больше шаблонов и сценариев, тем больше контрольных точек нужно добавить.
| Сценарий | На что смотреть в первую очередь | Риск при слабой проверке |
|---|---|---|
| Лендинг | Первый экран, CTA, формы, мобильная версия | Пользователь не отправит заявку или не увидит главное предложение |
| Интернет-магазин | Карточки товаров, фильтры, корзина, кнопки покупки | Сломается путь от товара до заказа |
| Блог или медиа | Страница статьи, изображения, цитаты, таблицы, навигация | Текст будет неудобно читать, особенно на телефоне |
| Корпоративный сайт | Страницы услуг, контакты, формы, адаптивность | Сайт будет выглядеть недоработанным и снижать доверие |
| Веб-сервис | Интерфейс, состояния элементов, ошибки, доступность | Пользователь не сможет завершить действие |
Проверка верстки хорошо дополняет работу над основными принципами веб-дизайна: если структура, читаемость, адаптивность и CTA продуманы заранее, на этапе тестирования обычно меньше критичных проблем.
Как фиксировать ошибки верстки
Ошибка “съехала верстка” почти бесполезна для исправления. Разработчику нужно понимать, где именно возникает баг, в каких условиях его можно повторить и что должно быть вместо текущего результата.
Хороший баг-репорт по верстке должен быть коротким, но конкретным. Его цель — не описать эмоции, а помочь быстро воспроизвести проблему.
| Поле | Что писать | Пример |
|---|---|---|
| Страница | URL или название страницы | /services/ или “Карточка услуги” |
| Устройство | Модель или тип устройства | iPhone 13, Android-смартфон, ноутбук 1366 px |
| Браузер | Название и версия, если известно | Safari iOS, Chrome Android, Firefox Desktop |
| Ширина экрана | Размер viewport | 390 px, 768 px, 1440 px |
| Что ожидалось | Как элемент должен выглядеть или работать | Кнопка находится под текстом и видна полностью |
| Что произошло | Фактическая ошибка | Кнопка уходит за правый край экрана |
| Доказательство | Скриншот или запись экрана | Скрин с выделенной проблемной зоной |
| Приоритет | Критично, важно, средне или низко | Важно |
Пример нормального описания: “Страница услуги, iPhone 13, Safari, ширина 390 px. В блоке с ценами третья карточка выходит за контейнер, появляется горизонтальная прокрутка. Ожидание: карточки должны идти в одну колонку без прокрутки. Скриншот приложен”.
Такой формат экономит время. Исполнитель сразу понимает, где искать ошибку, а заказчику проще контролировать, что именно исправлено.
Какие ошибки верстки считать критичными
Не все ошибки одинаково опасны. Разница в 2–3 пикселя между макетом и страницей может быть неприятной, но не всегда мешает пользователю. А вот неработающая форма заявки или меню на мобильном экране — уже критичная проблема.
| Приоритет | Что означает | Примеры | Что делать |
|---|---|---|---|
| Критично | Пользователь не может выполнить целевое действие | Не отправляется форма, не открывается меню, кнопка покупки недоступна | Исправлять до публикации |
| Важно | Проблема заметно ухудшает использование страницы | Горизонтальная прокрутка, наложение текста, сломанная карточка | Исправлять до запуска или в ближайшем релизе |
| Средне | Ошибка заметна, но не блокирует сценарий | Неровные отступы, разная высота карточек, слабый hover | Исправлять после критичных и важных багов |
| Низко | Мелкое отличие, почти не влияющее на сценарий | Незначительное отличие анимации, небольшой визуальный сдвиг | Исправлять при финальной полировке |
Приоритет помогает не тратить время на второстепенные детали, пока на странице остаются ошибки, которые мешают заявке, покупке, чтению или навигации.
Чем проверка верстки отличается от полноценного QA сайта
Проверка верстки — это часть тестирования сайта, но не весь QA-процесс. Она отвечает за отображение, адаптивность, интерактивные элементы и техническую аккуратность HTML/CSS. Полное QA шире: там проверяют бизнес-логику, интеграции, роли пользователей, платежи, безопасность и работу серверной части.
| Проверка верстки | Полное QA сайта |
|---|---|
| Сравнение страницы с макетом | Проверка пользовательских сценариев от начала до конца |
| Адаптивность и кроссбраузерность | Интеграции, платежи, авторизация, роли пользователей |
| Кнопки, формы, меню, попапы на уровне интерфейса | Корректность данных, ошибок, уведомлений и бизнес-логики |
| HTML, CSS, базовая доступность | Безопасность, нагрузка, API, база данных, регрессия |
Для лендинга иногда достаточно качественной проверки верстки и форм. Для интернет-магазина, личного кабинета или веб-сервиса одной проверки интерфейса мало — нужно полноценное функциональное тестирование.
Частые ошибки при проверке верстки
Самая частая ошибка — проверять страницу только на одном экране. Если на ноутбуке все выглядит нормально, это еще не значит, что сайт готов. Пользователи могут открывать его на смартфонах, планшетах, старых мониторах и в разных браузерах.
- Проверяют только главную страницу. Внутренние страницы, карточки, статьи и формы часто ломаются отдельно.
- Используют только короткий тестовый текст. Реальные заголовки и описания обычно длиннее и быстрее ломают сетку.
- Не проверяют состояния элементов. Hover, focus, disabled и error часто остаются без внимания.
- Полностью полагаются на автоматические инструменты. Валидатор не видит все визуальные и UX-проблемы.
- Не открывают сайт на реальных устройствах. Эмулятор полезен, но не всегда показывает удобство касаний и поведение клавиатуры.
- Не перепроверяют после исправлений. CSS-правка в одном блоке может повлиять на другой шаблон.
Еще один риск — проверять только “идеальное” состояние страницы. На практике нужно смотреть, что происходит при ошибке формы, пустом списке, длинном названии, отсутствии изображения, медленной загрузке или случайном клике вне попапа.
Краткий вывод: хорошая проверка верстки — это не один просмотр страницы, а последовательный контроль макета, адаптивности, браузеров, интерактива, реального контента и повторной проверки после правок.
FAQ по проверке и тестированию верстки сайта
Что входит в проверку верстки сайта?
В проверку входят соответствие макету, адаптивность, кроссбраузерность, работа кнопок, ссылок, форм, интерактивных блоков, базовая доступность и техническая проверка HTML/CSS.
Можно ли проверить верстку только автоматическими инструментами?
Нет. Автоматические инструменты находят часть технических ошибок, но не заменяют ручной просмотр, проверку реальных сценариев, визуальную оценку и тестирование на устройствах.
Чем проверка верстки отличается от тестирования сайта?
Проверка верстки фокусируется на отображении и поведении интерфейса. Полное тестирование сайта шире: оно включает функциональность, интеграции, безопасность, производительность, платежи, личные кабинеты и другие сценарии.
Когда нужно проводить тестирование верстки?
Перед запуском сайта, после редизайна, после правок шаблонов, после добавления новых блоков, перед рекламными кампаниями и после исправления найденных багов.
Какая ошибка верстки самая критичная?
Та, которая мешает пользователю выполнить целевое действие: отправить форму, нажать кнопку, открыть меню, прочитать текст, выбрать товар или перейти к следующему шагу.
Как понять, что верстка готова к публикации?
Страница соответствует макету, корректно работает на основных экранах и браузерах, не имеет горизонтальной прокрутки, формы и кнопки работают, технические ошибки проверены, а после исправлений проведена повторная проверка.
Нужно ли заказчику самому проверять верстку?
Да. Даже если техническую часть закрывает разработчик или QA-специалист, владельцу проекта стоит самому пройти ключевые сценарии: открыть меню, отправить форму, найти контакты, посмотреть страницы услуг, карточки товаров или другие важные разделы. Заказчик обычно быстрее замечает, что нужный для бизнеса блок выглядит не так или не ведет к целевому действию.
Источники и основа проверки
- Практика frontend-проверки: сравнение с макетом, адаптивность, браузеры, формы, состояния элементов.
- W3C Markup Validation Service — для проверки HTML-разметки.
- W3C CSS Validation Service — для проверки CSS.
- MDN Web Docs — для справки по HTML, CSS, доступности, label, ARIA и поведению элементов.
- PageSpeed Insights и Lighthouse — для дополнительной оценки качества страницы.
Итог простой: верстку стоит проверять не для галочки, а чтобы пользователи не стали вашими бесплатными тестировщиками. Макет, адаптивность, браузеры, формы, HTML/CSS, доступность и повторная проверка после правок — это минимальный набор, который делает запуск сайта спокойнее.