Проверка на валидность Html сайта

Вокруг проверки на валидность HTML сайта накопилось больше мифов, чем практической пользы. Одни утверждают, что каждая ошибка в отчёте валидатора стоит позиций, другие вообще не открывали validator.w3.org и живут спокойно. Правда посередине и она конкретна: из сотни сообщений валидатора примерно пять действительно ломают страницу, ещё десяток мешают роботам и вспомогательным технологиям, а остальные — стилистические придирки, за которые никто вас не накажет. Задача владельца сайта — научиться отличать первые от последних и не платить разработчику за вылизывание отчёта до зелёной галочки.

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

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

Валидатор сверяет разметку страницы со спецификацией HTML Living Standard. Никакого «мнения о качестве кода» он не выносит: только соответствие формальным правилам — можно ли этот тег вкладывать в тот, обязателен ли атрибут, допустимо ли такое значение, закрыт ли элемент там, где закрытие обязательно.

Технически на validator.w3.org сейчас работает движок Nu Html Checker. Это тот же самый инструмент, что доступен отдельно по адресу validator.w3.org/nu и распространяется как исполняемый файл vnu.jar — последнее пригодится, когда дойдём до массовой проверки.

Ключевая деталь, которую упускают почти все: валидатор запрашивает исходный HTML по URL и разбирает то, что пришло от сервера. Он не выполняет JavaScript. Если у вас часть интерфейса собирается на клиенте, валидатор её не увидит — ни ошибок в ней, ни самой разметки. Для таких проектов проверять нужно не адрес, а итоговый DOM: скопировать содержимое вкладки «Элементы» в инструментах разработчика и вставить в форму проверки прямым текстом.

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

Error, Warning и Info: как читать отчёт

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

Тип сообщения	Что означает	Что с ним делать
Error	Нарушение обязательного правила спецификации: недопустимое вложение, отсутствующий обязательный атрибут, незакрытый элемент	Разобрать каждое. Часть окажется критичной, часть безобидной, но пропускать нельзя
Fatal Error	Разбор документа остановлен: чаще всего сломанная кодировка или недопустимые байты в потоке	Чинить немедленно, остальные проверки до этого бессмысленны
Warning	Формально допустимо, но спорно: устаревшая конструкция, потенциально небезопасный приём	Смотреть выборочно, чинить при плановой доработке шаблона
Info	Замечание о стиле разметки или о том, что проверка чего-то не касалась	Читать один раз для понимания, править не нужно

Отдельно про формулировку «фатальная ошибка», которая гуляет по статьям о валидности. Это не «страница выпадет из индекса», как часто пишут. Fatal Error в терминах валидатора означает, что сам валидатор не смог дочитать документ до конца. Причина почти всегда одна из двух: заявленная кодировка не совпадает с фактической либо в файл попали служебные байты — BOM в неожиданном месте, обрывок бинарных данных, символ из другой кодовой страницы. Браузер в такой ситуации покажет кракозябры или обрежет часть контента, и вот это уже реальная проблема.

Правда о влиянии валидности на позиции

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

Тему разбирал отдельно: «СЕО проверка сайта онлайн».

Влияние валидности косвенное, и оно проявляется через три канала.

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

Помогу с продвижением: продвижение сайта в Яндексе — вывожу сайты в топ Яндекса белыми методами.

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

Если интересно направление с сайтами — базу даю в своём курсе:

8:14

Ошибки, которые действительно ломают страницу

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

Ошибка в разметке	К чему приводит	Приоритет
Незакрытый div или лишний закрывающий тег	Блоки схлопываются друг в друга, контент уезжает в сайдбар, ломается вёрстка на части страниц	Критично
Блочный элемент внутри абзаца или внутри ссылки	Парсер закрывает абзац раньше, разметка разъезжается, ссылка перестаёт охватывать блок	Критично
Дублирующийся атрибут id на странице	Не работают якорные ссылки, скрипты цепляются к первому попавшемуся элементу, ломается связь label и поля формы	Критично
Несовпадение объявленной и фактической кодировки	Кракозябры вместо текста, обрыв разбора документа	Критично
Неэкранированный амперсанд в URL внутри href	Часть GET-параметров теряется, ссылка ведёт не туда	Критично
Отсутствие или дублирование тега title	Заголовок сниппета формируется поисковиком произвольно	Критично
Форма внутри формы	Внутренняя форма не отправляется вообще	Критично
Незакрытые ячейки и строки в таблице	Содержимое соседних блоков втягивается внутрь таблицы	Высокий
Тег script или style внутри тела без нужды	Сдвигает разбор, иногда прячет часть контента от извлечения	Средний
Битая вложенность микроразметки	Пропадают расширенные сниппеты и карточки в выдаче	Высокий

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

Ошибки, на которые не стоит тратить бюджет

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

Смежный материал по теме — «Проверка авторитетности сайта».

Сообщение валидатора	Почему можно отложить
Нестандартные атрибуты фреймворков и аналитики	Игнорируются браузером и роботами, на разбор документа не влияют
Предупреждение о секции без заголовка	Стилистическая рекомендация, на извлечение контента не влияет
Замечания о типе и синтаксисе атрибута type у script	Устаревшая конструкция, работает везде
Слэш перед закрывающей скобкой у одиночных тегов	Наследие XHTML, разбирается корректно
Предупреждения о неизвестных значениях в rel	Неизвестные значения просто пропускаются
Сообщения о разметке внутри шаблонов виджетов сторонних сервисов	Чужой код, править вы его не можете

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

Чем проверять: инструменты и их назначение

Один инструмент задачу не закрывает. Ниже связка, которой пользуюсь я, с указанием, за что отвечает каждый.

Инструмент	Что проверяет	Когда применять
W3C Markup Validation Service	Соответствие разметки спецификации по URL, по загруженному файлу или по вставленному коду	Разовая проверка представителя каждого шаблона
Nu Html Checker в виде vnu.jar	То же самое, но локально и пакетно, с выводом в JSON	Проверка сотен адресов, встраивание в сборку
HTMLHint и подобные линтеры в редакторе	Ошибки прямо во время написания кода, до публикации	Постоянно в работе разработчика
Валидатор структурированных данных Яндекса	Корректность микроразметки и её видимость роботу	После правок карточек товара, отзывов, статей
Проверка URL в панелях вебмастера	Как страница выглядит после отрисовки глазами поисковика	Когда часть контента приходит из JavaScript

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

Как проверить весь сайт, а не одну страницу

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

1. Составить список шаблонов. Главная, раздел каталога, карточка товара, страница услуги, статья блога, страница тегов, результаты внутреннего поиска, страница 404, страница корзины, форма обратной связи. Обычно набирается от восьми до пятнадцати типов.
2. Взять по одному живому адресу каждого типа. Не тестовый, а тот, что реально доступен посетителю.
3. Прогнать список через vnu.jar в пакетном режиме. Инструмент принимает перечень URL и отдаёт отчёт одним файлом. Так вы за один заход видите, какие ошибки общие для всех шаблонов, а какие живут в одном.
4. Отдельно проверить страницы, где контент вводят руками. Статьи и описания товаров, которые редактируют через визуальный редактор, — главный источник незакрытых тегов и вставок из офисных программ. Проверьте десяток свежих материалов.
5. Сравнить исходный HTML с отрисованным. Если сайт активно использует JavaScript, часть проблем видна только в итоговом DOM.

Если нужна помощь по теме — мой курс по SEO.

Отдельный приём для больших каталогов: краулером вроде Netpeak Spider или Screaming Frog собрать со всех страниц количество открывающих и закрывающих тегов основного контейнера через пользовательское извлечение. Страницы, где числа не совпадают, — кандидаты на ручной разбор. Это грубый фильтр, но он находит поломанные карточки в каталоге на десятки тысяч адресов за один обход.

Порядок исправления и приоритеты

Когда отчёт собран, соблазн велик: отдать список разработчику целиком и ждать чистого результата. На практике это дорого и почти всегда бессмысленно. Работающая последовательность выглядит так.

Если нужны детали, смотрите «SEO проверка сайта онлайн».

• Сначала кодировка и обрыв разбора. Пока документ не читается до конца, остальные сообщения недостоверны.
• Затем нарушения структуры. Незакрытые контейнеры, вложенность блоков в абзацы и ссылки, поломанные таблицы. Эти правки делаются в шаблонах и разом снимают ошибку с тысяч страниц.
• Потом дубли идентификаторов и проблемы форм. Здесь страдает функциональность, которую владелец сайта может проверить сам, не читая код.
• Дальше микроразметка. Проверяется отдельным валидатором, чинится точечно, окупается расширенными сниппетами.
• В последнюю очередь косметика. Устаревшие атрибуты, стилистические предупреждения, нестандартные конструкции сторонних скриптов. В плановую доработку, не в срочные задачи.

После каждого блока правок обязателен повторный прогон. Исправление одной структурной ошибки нередко убирает два десятка производных сообщений — потому что валидатор, споткнувшись о незакрытый контейнер, дальше ругается уже на последствия, а не на причины. Разбирать отчёт снизу вверх бесполезно по той же причине.

Частые вопросы про валидность HTML

Выпадет ли страница из индекса из-за ошибок в коде? Из-за формальных ошибок — нет. Из-за поломанной кодировки или структуры, при которой контент не извлекается, страница может остаться в индексе с пустым или бессмысленным содержимым, что по последствиям сравнимо с выпадением.

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

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

Проверяет ли валидатор CSS? Нет, для стилей существует отдельный сервис проверки CSS. Ошибки в стилях на индексацию не влияют вовсе, но могут ломать отображение на мобильных.

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

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

Как часто проверять? После каждого релиза, затрагивающего шаблоны, и раз в квартал планово по списку типов страниц. Между релизами достаточно линтера в редакторе разработчика.

Коротко

• Валидатор сверяет разметку со спецификацией и не выполняет JavaScript — сайты с клиентской отрисовкой проверяются по итоговому DOM, а не по URL.
• Прямого фактора ранжирования «валидность» нет; вред приносят только ошибки, ломающие структуру документа, микроразметку или работу форм.
• Критичны незакрытые контейнеры, блоки внутри абзацев и ссылок, дубли идентификаторов, несовпадение кодировки и неэкранированные амперсанды в адресах.
• Устаревшие атрибуты, нестандартные data-атрибуты и претензии к чужим виджетам исправлять не нужно — это шум в отчёте.
• Проверять надо по одному представителю каждого шаблона плюс свежие страницы, которые редактируют руками; для массового обхода подходит пакетный запуск Nu Html Checker.
• Порядок правок: кодировка, структура, идентификаторы и формы, микроразметка, косметика — с повторным прогоном после каждого блока.

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