После создания сайта и наполнения его всем необходимым, сайт нуждается в проверки на ошибки. Что бы найти ошибки написания в html и css вам поможет валидатор W3 — World Wide Web Consortium, что в переводе: Консорциум Всемирной Паутины. Он находит все ошибки и указывает где они находятся, так же предлагает варианты их устранения.

На самом деле плюсов от этого не много и все они условные, но к сожалению каждый сайт должен иметь минимальное количество ошибок в идеале ни одной. Что бы вы решили нужно ли вам это, вот его плюсы:

• Повысится скорость загрузки страницы, но чуть-чуть, это даже не будет заметно.
• В каждом браузере сайт будет отображаться одинаково.
• Когда добавляют сайт в каталог, обращают внимание на грамотность написания html и css.

Плюсов не много, но исправить ошибки html и css с помощью валидатора W3C стоит!

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

1.Набираем в поле имя вашего сайта полностью.


2.В списке начинаем смотреть где и какая ошибка и что нужно для её устранения.


Как видно на картинки, моя ошибка в ссылке, эту проблему я нашёл в плагине share buttons. Часто приходится копаться во всех файлах, что бы найти ошибку.

3.Добавляем элемент в строку, где была найдена ошибка и проверяете валидатором опять.
Если ошибка исправлена, то это хорошо. Если нет, то придётся искать дальше.

Приветствую! Проверяя один из сайтов на валидность я вдруг обратил внимание на занятное предупреждение…

В переводе на русский язык оно означает примерно следующее:

Новинка — W3C предлагает бета-версию нового сервиса, который предоставит Вам комплексный отчет о проверке сайта. Попробуйте прямо сейчас, чтобы как можно скорее выявить те части сайта, которые требуют особого внимания.

И здесь в голову пришла прекрасная мысль — а почему бы прямо сейчас не сделать небольшой обзор? Так и поступим, встречайте новый сервис W3C Validator Suite!

Validator Suite предоставляет новый вид услуг комплексной оценки качества сайта. Сервис проверяет все страницы сайта и оценивает их соответствие стандартам W3C, а также другим требованиям производительности для веб-ресурсов.

По сути, я уже знакомил своих читателей с такими сервисами, как:

• CSS Validation Service — ;
• MarKup Validation Service — ;
• А также инструментами консорциума.

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

Соответствие сайта стандартам W3C обеспечивает:

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

Если Вы создаете новый сайт или занимаетесь поддержкой текущих проектов, то используйте сервис W3C Validator Suite и проводите периодические проверки. Так Вы будете уверены, что проект соответствует современным стандартам и максимально оптимизирован для просмотра с различных устройств и браузеров.

Сервис очень прост в использовании — достаточно ввести URL, задать необходимые параметры и подтвердить начало проверки:

В настоящий момент Validator Suite объединяет в себе следующие инструменты и возможности:

• HTML валидатор. Используются те же средства, что и в MarKup Validation Service, но результаты представлены в альтернативном, более интуитивно понятном интерфейсе. Включает в себя проверку HTML5.
• CSS валидатор. Также используются стандартные широко известные средства с новым представлением результатов. Включает в себя проверку CSS3.
• Поисковый робот. Он автоматически находит все страницы на сайте, подлежащие проверке, в том числе в XML формате. Не нужно вручную добавлять каждую страницу — достаточно указать главную и запустить проверку, а робот самостоятельно найдет все внутренние страницы.
• Суммарный отчет. Когда все страницы будут проверены Вы увидите суммарный отчет для сайта, в котором предупреждения и ошибки будут сгруппированы.
• Отчет по URL. Отчет об ошибках для каждой страницы. Вы увидите количество ошибок HTML и CSS, а также предупреждений со ссылкой на детализированное описание проблемы.
• Повторные проверки. Вероятно сразу после получения отчета Вы приступите к работе по устранению ошибок. Используя валидатор можно отправлять на проверку отдельные страницы или запросить повторно полную проверку сайта.
• Неограниченное хранение отчетов. Вы можете хранить свои отчеты столько времени, сколько понадобиться до тех пор пока учетная запись активна. В это же время аналогичные сервисы удаляют их через несколько дней.
• Загружаемые отчеты. Есть возможность скачать результаты проверки в формате CSV (формат, совместимый с таблицами MS Excel, OpenOffice и другим программным обеспечением).

Да, к сожалению, проверка сайта этим инструментом не бесплатна. На данный момент представлены два тарифных плана:

С одной стороны имеем хорошо знакомые инструменты, которыми можно воспользоваться вполне бесплатно. С другой — новый дружественный и доступный интерфейс с расширенным функционалом, но платный. Вероятно, премиум поддержка пользователей оказалась не рентабельной и поэтому сервис стал Open Source проектом, который доступен на GitHub .

Еще многое предстоит сделать по расширению возможностей сервиса, в планах по реализации три дополнительных направления:

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

Рекомендую ознакомиться с другими моими обзорами средств анализирования сайта из рубрики Аудит и тестирование. И конечно же жду Ваших отзывов! Как думаете, сервис найдет свое место в нише и будет пользоваться спросом? 🙂

Вы наверняка много раз слышали словосочетание «валидность кода» . А знаете ли вы что это такое? Если да, тогда просмотрите эту статью по диагонали, может все таки что-то интересное найдете. А те кто не знает — читайте полностью. Я расскажу о том, как проверял валидность кода своего блога, как исправлял неправильные теги и многое другое.

Если у вас есть свой сайт или блог, то вы наверняка пишите на нем уникальные статьи, продвигаете его в поисковиках и т.д. Но задумывались ли вы о исходном коде своего сайта? Это так же очень важно, ведь поисковики видят именно исходный код страниц и извлекают из него тексты статей и другие элементы ресурса. Если исходный код будет неправильным и не будет соответствовать стандартам, то роботам будет трудно правильно оценить качество текста и, например, навигации по сайту.
Итак, валидность кода — это соответствие исходного кода сайта нормам и правилам, описанным Консоциумом Всемирной Паутины или сокращенно W3C. Чтобы проверить свой блог на соответствие этим нормам нужно пройти по ссылке: validator.w3.org . Ввести нужный адрес и посмотреть результаты.

Я столкнулся с ошибками в верстке своей темы а так же с ошибками, которые совершил я сам при установке счетчика от liveinternet. На самом деле я знал о них уже давно, просто не придавал этому значения. И вот совсем недавно мне было нечем заняться и я таки решил добиться валидности кода моего блога. Думаю, это не повредит =)

Для начала скажу, что ошибок было 12 штук, но 10 из них относились к одному и тому же тегу, а именно к

Rel="category tag"

Набрав этот тег в гугле я понял, что на русскоязычные сайты надежды нет, ибо ни одного упоминания об этом теге в рунете нет. Ну что же, не проблема, будем искать на англоязычных, благо ничего сложного в этом нет. Итак, почитав темы на wordpress.org я понял, что не у меня одного страдает от этого тега. На одном из буржуйских сайтов нашел как пофиксить, если кому надо, то вот этот код вставляем в файл functions.php:

Add_filter("the_category", "add_nofollow_cat"); function add_nofollow_cat($text) { $text = str_replace("rel="category tag"", "", $text); return $text; }

После этого сразу 10 ошибок исчезло, но осталось еще две. Первую из них было так же легко исправить. Видите кнопки RSS подписки и Твиттера у меня в шапке блога? Они сделаны картинками, но параметр alt я задать забыл. Я писал о том как важен параметр alt у картинок в теме по внутренней оптимизации, а оказывается он вообще обязателен. Вот и его пофиксил. Осталась одна ошибка.

Когда я устанавливал счетчик на сайт, то поместил его в сайдбар (правая колонка с навигацией), так сказать на скорую руку. Предварительно я заключил его в тег center чтобы выровнять. Но, как оказалось, не по феншую это и валидатор ругался, мол убери этот тег и сделай все красиво — div’ами. ОК, дивами так дивами. Я давно хотел убрать счетчик в подвал для красоты, пусть там тусуется. А тут как раз и повод появился этим заняться. Убрал в футер и выровнял с помощью float: right по правому краю, мне даже самому понравилось, а это главное:)

Вот и все, теперь мой сайт полностью соответствует стандартам! Следующая цель — CSS, проверить ее можно все на том же сервисе, ссылку на который я давал в начале статьи.

Игорь . Обновление:Июнь 9, 2012 .

Здравствуйте, друзья! Сегодня очень важная тема на повестке дня: как произвести проверку сайта на ошибки , которая подразумевает проверку валидности (соответствия стандартам) html кода, c помощью сервиса W3C validator .

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

Валидность, то есть соответствие html кода определенным стандартам, задает Международный Консорциум W3C (World Wide Web Consortium). Все интернет-разработчики в большинстве своем обязательно учитывают эти нормы в своих творениях. Согласитесь, без этого в интернет-пространстве, программировании в частности, воцарит хаос и анархия. Кроме контроля HTML кода очень важно осуществить .

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

Очень полезный сервис-подсказка всем вебмастерам в деле проверки и поддержания валидности html - это W3C validator. Для начала перейдем на главную страницу W3C :

Как видите, уже есть разделение по регионам и вы можете просмотреть русскоязычный вариант главной страницы, выбрав в выпадающем меню с правом верхнем углу соответствующий регион и нажав кнопку «GO». К сожалению, результаты проверки валидности html пока возможны только на английском языке, поэтому для того чтобы перейти непосредственно к проверке сайта на ошибки, кликайте по ссылке «HTML and markup validator» в правом нижнем углу:

Для проверки валидности html можно поступить тремя способами:

1. Validate by URI - проверка по URL адресу документа
2. Validate by File Upload - проверка валидности html по загружаемому файлу
3. Validate by Direct Input - можно непосредственно вставить html код и осуществить проверку на валидность.

Для того, чтобы проверить правильность html кода страницы сайта или блога на ошибки, выбираем первый вариант. Затем вводим адрес ресурса в соответствующее поле «Address» и нажимаем «Check» . Вполне возможно, вам откроется следующая картина, в моем случае было именно так первый раз, когда я затеял проверку своего блога с помощью W3C validator:

Вердикт W3C validator неутешителен: невозможно осуществить проверку сайта на ошибки html кода, поскольку был обнаружен недопустимый символ на строке 298. Что же, будем искать этот символ, благо подсказка есть. Если вы пользуетесь Google Chrome ( мануал, описывающий этот браузер), то нажимайте правую кнопку мышки и выбирайте «Просмотр кода страницы» из контекстного меню (либо используйте комбинацию клавиш Ctrl+U), в результате чего откроется страница с HTML кодом на соседней вкладке.

В случае других браузеров: если вы пользователь Internet Explorer ( об Эксплорере статья) выбираете «Просмотр HTML кода» , Mozilla Firefox (об подробнее) - «Исходный код страницы» , Opera ( о том, как скачать, установить, настроить и обновить браузер Опера) - «Исходный код» .

Смотрим, что здесь не устраивает W3C validator. Как видно из скриншота, эта строчка соответствует одному из комментариев, моему ответу на один из комментариев. Здесь мною был случайно использован символ амперсанда &, это отрывок из ”последних комментариев” на главной странице:

Отредактировав это место, снова проверяем сайт на ошибки, используя повторно W3C validator (для исправления я зашел в раздел «Комментарии» админ панели WordPress и заменил & на букву н):

Как видно из вышеприведенного скриншота, на этот раз валидатор смог осуществить проверку и выдал 8 ошибок и 2 предупреждения. Это на самом деле очень мало и с этим вполне можно жить. Многие вполне приличные, пользующиеся доверием Яндекс и Гугл сайты имеют на порядок больше ошибок по валидности html.

Внимание! W3C validator осуществляет проверку валидности только той страницы, адрес которой вы вводите, а не всего сайта. Если введен адрес главной страницы, то получите данные только по этому документу.

Даже главная страница Yandex, если для примера вы решитесь ее проверить, содержит несколько десятков ошибок. Но это и понятно, очень трудно постоянно следить за корректировкой кода, поскольку документы (читай: страницы сайта) постоянно обновляются. Например, мы на блоге WordPress постоянно используем плагины для тех или иных целей, которые также вносят хаос в html код.

Если вы даже ”подчистите” все косяки, все равно могут появиться новые в силу вышеописанных причин. Важно, чтобы этих ошибок не было слишком много. Если, конечно, вы добьетесь полной их ликвидации, то честь вам и хвала. Конечно, для этого необходимо знать хотя бы основы html, чтобы знать алгоритм исправления ошибок сайта в коде.

В последующих публикациях я постараюсь вновь поднять эту тему и более подробно рассказать на примерах, какие конкретно действия предпринять для их ликвидации; чтобы не пропустить свежую информацию, подписывайтесь на обновления блога по RSS . Еще раз напоминаю, что слишком большое количество ошибок в html коде может помешать правильному отображению сайта в различных браузерах. Кроме того, что-то мне подсказывает, что вскоре поисковые системы могут внести коррективы в порядок ранжирования ресурсов и учитывать валидность html кода. В дополнение привожу разъяснения некоторых настроек на странице проверки валидации W3C validator:

• Show Source - показывает исходный код
• Show Outline - отображает строку,содержащую ошибку
• Validate error pages - осуществляет проверку валидности html страницы с ошибкой, например,
• List Messages Sequently - отображает ошибки и предупреждения обычным списком
• Group Error Messages by Type - классифицирует ошибки по определенным признакам
• Clean up Markup with HTML TIdy - выводит правильный код, исправленный программой HTML Tidy. В аннотации указано, что эта программа не входит в состав W3C validator, поэтому они не гарантируют корректность ее работы.

Ну, вот, пожалуй, на сегодня достаточно. Надеюсь, вы уяснили для себя необходимость проверки сайта на ошибки и осуществите проверку валидности html своего сайта с помощью W3C validator.

Желаете получать своевременно свежие актуальные и полезные статьи? Тогда можете подписаться:

Еще статьи по данной теме:

Производит несколько проверок Вашего кода. Основные из них:

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

Вообще, моей наибольшей проблемой валидации является проверка #4 (на посторонние элементы). Я сторонник использования пользовательских атрибутов в HTML тэгах для хранения дополнительных мета-данных, относящихся к определенному элементу. В моем понимании, это, например, добавить атрибут foo, когда у меня есть данные (bar), которые мне надо ассоциировать с определенным элементом. Иногда люди перегружают существующие атрибуты для этих целей только для того, чтобы пройти валидацию, несмотря на то, что атрибут будет использовать не по назначению. Для меня это бессмысленно.

Секрет браузеров заключается в том, что они никогда не проверяют соответствие HTML-кода указанному DTD. Doctype, который Вы указали в документе, переключает парсер браузера в определенный режим, но это не приводит к загрузке doctype и проверке кода на соответствие ему. То есть, парсер браузеров обрабатывает HTML с некоторыми допущениями невалидности, вроде самозакрывающихся тэгов и блочных элементов внутри строковых (я уверен, что есть и другие).

В случае пользовательских атрибутов, все браузеры парсят и распознают синтаксически корректные атрибуты как допустимые. Это делает возможным получить доступ к таким атрибутам через DOM с помощью Javascript. Так почему я должен беспокоиться о валидности? Я буду продолжать использовать свои атрибуты и я очень рад, что HTML5 формализует их.

Лучший пример технологии, которая приводит к невалидному HTML, но имеет огромное значение, - это ARIA . ARIA работает с помощью добавления новых атрибутов в HTML 4. Эти атрибуты предоставляют дополнительное семантическое значение HTML-элементам и браузер способен передать эту семантику вспомогательным устройствам для помощи людям с ограниченными физическими возможностями. Все основные браузеры сейчас поддерживают разметку ARIA. Однако, если Вы будете использовать эти атрибуты, у Вас будет невалидный HTML.

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

Чтобы прояснить мою позицию: я считаю, что проверки #1 и #2 являются очень важными и должны проводиться всегда. Проверку #3 я тоже считаю важной, но не столь, как первые две. Проверка #4 очень сомнительна для меня, так как она задевает пользовательские атрибуты. Я считаю, что, как максимум, пользовательские атрибуты должны быть помечены как предупреждения (а не ошибки) в результатах проверки, чтобы была возможность проверить, не ошибся ли я при вводе названия атрибута. Отметка пользовательских тэгов как ошибок, возможно, хорошая идея, но тоже имеет некоторые проблемы, например, при встраивании содержимого в другой разметке - SVG или MathML.

• валидный HTML не гарантирует accessibility;
• валидный HTML не гарантирует хороший UX (user experience);
• валидный HTML не гарантирует функционирующий сайт;
• валидный HTML не гарантирует корректное отображение сайта.

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

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