Как проверить HTML-код страницы и исправить ошибки

Проверка структуры HTML-страницы через увеличительное стекло
Страница может выглядеть нормально и при этом содержать сломанную вложенность, дубли id или поле формы без подписи. Я проверяю HTML валидатором, а затем смотрю итоговый DOM в браузере: эти проверки дополняют друг друга.
14.10.2026 · 8 мин чтения

Что именно проверяет HTML-валидатор

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

Зачем проверять код владельцу сайта

  1. Чтобы блоки и формы предсказуемо работали в разных браузерах и на телефоне.
  2. Чтобы заголовки, основной контент и навигация имели понятную структуру.
  3. Чтобы скринридер связывал подписи с полями и озвучивал изображения по alt.
  4. Чтобы разработчик не тратил время на последствия незакрытого тега в соседнем блоке.
  5. Чтобы поисковый робот получал тот же основной контент, который видит посетитель.
Валидный HTML сам по себе не поднимает страницу в поиске. Это техническая гигиена: она убирает неоднозначность и помогает другим проверкам. Можно иметь безошибочный, но бесполезный сайт; можно ранжироваться с предупреждениями. Моя задача — исправить ошибки, которые влияют на отображение, доступность и понимание страницы.
Смысловая структура страницы из шапки, навигации, основного блока и подвала
Хорошая разметка отражает смысл и иерархию страницы, а не только её внешний вид.

Минимальный каркас страницы

ЭлементРольЧто проверить
<!DOCTYPE html>Включает современный режим HTMLСтоит первой строкой
htmlКорень документаЕсть lang="ru" для русской страницы
headСлужебные данныеЕсть charset, title, viewport и description
bodyВидимое содержимоеОдин элемент на документ
header и navШапка и основная навигацияРоли соответствуют содержимому
mainУникальный основной контентОбычно один на странице
h1–h6Иерархия заголовковУровни отражают вложенность разделов
imgИзображениеЕсть src, размеры и подходящий alt
form, label, inputФорма и поляlabel связан с id, у поля есть name и корректный type
footerПодвал страницы или разделаНе подменяет основной контент
Семантические теги не запрещают div. Я использую div как нейтральную обёртку, когда у блока нет отдельной смысловой роли. Но меню лучше обозначить nav, уникальную часть страницы — main, самостоятельный материал — article. Так структура остаётся понятной без чтения всех классов.

Как проверить страницу через W3C

  1. Открываю validator.w3.org или современный Nu Html Checker.
  2. Для опубликованной страницы указываю полный URL. Для черновика загружаю файл или вставляю полный код.
  3. Запускаю проверку и сохраняю исходный список сообщений.
  4. Сначала исправляю первую структурную ошибку, затем запускаю проверку заново.
  5. После чистого результата проверяю страницу визуально и прохожу ключевой сценарий: меню, форма, кнопка, модальное окно.
Почему начинаю с первой ошибки: один незакрытый тег способен породить десятки последующих сообщений. Если чинить список снизу вверх, легко править следствие. После каждого структурного исправления набор ошибок меняется, иногда сразу сокращаясь.
Документы проходят автоматическую проверку HTML-разметки
Валидатор находит формальные ошибки, но приоритет каждой из них определяю по влиянию на страницу.

Как читать сообщения валидатора

Error означает нарушение правил, warning — риск или рекомендацию, info — пояснение. Я смотрю не только номер строки, но и ближайший родительский элемент. После шаблонизации исходная строка может быть далеко от места, где ошибка появилась в компоненте.
  1. End tag seen, but there were open elements — перед закрывающим тегом остался незакрытый элемент.
  2. Element is not allowed as child — элемент вложен в неподходящего родителя, например div напрямую внутрь ul.
  3. Duplicate ID — одинаковый id встречается несколько раз; ссылки, скрипты и подписи могут выбрать не тот элемент.
  4. Attribute not allowed — атрибут устарел, написан с ошибкой или не подходит этому тегу.
  5. Bad value — значение имеет неверный формат, например пробел в id или некорректный URL.
  6. No p element in scope — абзац был автоматически закрыт из-за вложенного блочного элемента.

Исходный HTML и итоговый DOM

Команда «Просмотреть код страницы» показывает ответ сервера. Вкладка Elements в DevTools показывает DOM после исправлений браузера и выполнения JavaScript. На статической странице они близки. В приложении JavaScript различия могут быть большими, поэтому я проверяю оба варианта.
Если текст появляется только после скрипта, валидатор по URL может не увидеть итоговую структуру. Тогда проверяю серверный HTML отдельно, а отрендеренный DOM — средствами браузера и тестами доступности. В Console параллельно ищу ошибки JavaScript: валидный HTML не оживит кнопку, если обработчик упал.

Типичные ошибки разметки

  1. Незакрытый div, a, p или li меняет границы соседних блоков.
  2. Список содержит элементы кроме li на первом уровне.
  3. Кнопка вложена в ссылку или один интерактивный элемент вложен в другой.
  4. Одинаковый id скопирован вместе с карточкой или формой.
  5. У изображения нет alt и размеров, из-за чего страница скачет при загрузке.
  6. У input нет name, поэтому значение не отправляется, либо нет связанного label.
  7. В head несколько title или meta description записан не через meta name="description".
  8. Заголовки выбраны по размеру, а не по иерархии материала.
Ошибочная и исправленная вложенность элементов HTML
Чаще всего проблема не в редком теге, а в простой вложенности и повторяющихся элементах.

Что валидатор не заменяет

После HTML я отдельно проверяю CSS, JavaScript, доступность, микроразметку и скорость. Для микроразметки подходят инструменты Яндекс Вебмастера и валидаторы Schema.org; общий HTML-валидатор показывает синтаксис, но не подтверждает право на расширенный результат в поиске.
Автоматическая проверка доступности находит пустой alt, отсутствие подписи и часть проблем контраста, но не понимает качество текста ссылки или удобство формы. Поэтому прохожу страницу клавиатурой, проверяю видимый фокус и читаю названия элементов в дереве доступности.

Рабочий порядок после правок

  1. Форматирую код Prettier или штатным инструментом редактора.
  2. Запускаю локальный линтер до публикации.
  3. Проверяю готовый URL валидатором W3C.
  4. Смотрю Console и Network в DevTools.
  5. Проверяю телефон, клавиатуру и отправку формы.
  6. Исправляю собственный шаблон в первую очередь; предупреждения чужого виджета оцениваю отдельно.
  7. Повторяю проверку после крупных изменений компонентов.
Цель не в красивом значке «без ошибок», а в предсказуемой странице. Если я понимаю каждое оставшееся предупреждение и оно не ломает структуру, доступность или сценарий посетителя, проверка выполнила свою задачу.
SEO

Проверю разметку страницы

Найду ошибки структуры, заголовков, форм и элементов, которые браузер вынужден исправлять сам.
SEO-специалист и автор материала
Читайте также