Навіщо потрібен валідний код та як усунути помилки валідації

Валідація є одним з найважливіших аспектів хорошого веб-дизайну. Давайте розглянемо, що це таке і як перевірити HTML-код на валідність. Як приклад візьмемо найпоширенішу систему керування контентом (CMS) – WordPress. Після чого ми поділимося переліком помилок, з якими зіткнулися на практиці і, найголовніше, запропонуємо свої, перевірені, методи їх усунення.

Навіщо потрібна перевірка на валідність сайту

Простіше кажучи, перевірка веб-сторінки дозволить визначити, чи відповідає вона стандартам, розробленим Консорціумом Всесвітньої павутини (W3C). Зазвичай це робиться шляхом перевірки окремих сторінок на валідність за допомогою онлайн-сервісу перевірки W3C.

Подібно до правил граматики різними мовами, є також правила в програмуванні. Перевірка дозволяє побачити, чи відповідає сторінка цим правилам, а у разі наявності помилок та попереджень будуть надані рекомендації щодо їх усунення. Необхідність такої перевірки розглянемо нижче.

На що впливає валідність сайту

Ви коли-небудь замислювалися про те, як браузери «читають» веб-сторінку? У них є «двигуни» для аналізу коду та перетворення його на візуальний вигляд для людей. На жаль, кожен браузер має власний механізм обробки коду, і це може призвести до відображення ваших сторінок по-різному.

Некоректна веб-сторінка може бути прочитана браузерами по-різному. Це призведе до того, що ваші відвідувачі, можливо, навіть не зможуть вірно побачити контент сторінки у своїх браузерах. Валідація надалі дозволить виправити майже всі основні відмінності та робить вашу веб-сторінку доступною для читання майже всіма веб-браузерами (найчастіше винятком стає Internet Explorer старих версій). Звідси і виник термін «кросбраузерна верстка» – тобто верстка, яка однаково сумісна для всіх популярних браузерів.

А як це вплине на SEO? Важливо розуміти, що пошукові роботи люблять семантичні веб-сторінки. Семантична верстка, згідно з даними Вікіпедії, – це підхід до створення веб-сторінок на мові HTML, заснований на використанні HTML тегів відповідно до їхньої семантики (призначенням). Крім того, структурна семантична веб-сторінка дозволяє пошуковим роботам більш точно визначати значимість як окремих елементів веб-сторінки, так і всього тексту в цілому. Як запевняє Google, валідний код ніяк не впливає на ранжування сторінок. Але при цьому наявність помилок у коді здатна негативно вплинути на сканування мікророзмітки та адаптованість під мобільні пристрої.

Матеріал на тему: https://www.seonews.ru/events/google-validnost-html-ne-vliyaet-na-ranzhirovanie/

Отже, якщо у SEO-аудиті ви зустрінете рекомендації щодо усунення помилок, виявлених у процесі валідації, то краще їх виправити, а як це зробити ми вам розповімо.

Інструменти перевірки для вашого сайту

Розуміючи необхідність відсутності помилок валідації на сторінках сайту, розглянемо, як здійснити пошук даних помилок.

Існує безліч безкоштовних сервісів для перевірки сайту, таких як Markup Validation Service W3C, Web Page Analyzer, Browsershots та інші.

Служба перевірки HTML розмітки W3C, ймовірно, є найпростішим і найпопулярнішим інструментом для перевірки валідності веб-сторінки. Використовуючи цей інструмент, ви можете виявити помилки валідації, починаючи від відсутніх атрибутів ALT для ваших IMG-тегів і до розміщення елементів блок-рівня всередині вбудованих елементів (наприклад, <p> всередині <span>).

Ви можете оцінити HTML-код, вказавши адресу своєї веб-сторінки, завантаживши файл HTML або вставивши HTML код безпосередньо.

Сервіс перевірить зазначені вами дані на помилки та сформує звіт з їх переліком та рекомендаціями щодо виправлення.

Умовно помилки та попередження можна розділити на два основних типи: шаблонні (пов’язані з обраною темою та встановленими плагінами) та помилки, допущені при оформленні унікального контенту.

Перевіряючи веб-сторінку вперше, не лякайтеся можливої кількості помилок! Як правило, більшість із них багаторазово повторюються на аналізованій сторінці. А це означає, що якщо прибрати помилку в одному місці шаблону або сторінки, вона зникне і у всіх однотипних.

Звідки беруться помилки

Величезна кількість помилок пов’язана з темою сайту, що використовується, а також встановленими плагінами. Більшість із нас встановлює безкоштовну тему та плагіни, не замислюючись, що в них приховано. У багатьох темах з глибшим вивченням доводиться зіштовхуватися з типовими помилками.

Як виправити помилки, та покращити валідність сайту

Виправити виявлені помилки можна двома способами: звернутися до фахівців, заплативши N-ну суму грошей, або виправити їх самостійно. Розглянемо останній варіант на реальних прикладах і усунемо всі неточності, дотримуючись докладних інструкцій.

Важливо, резервне копіювання!
Перед здійсненням будь-яких змін у вихідному коді сайту необхідно зробити резервне копіювання файлів сайту та бази даних. А потрібно це для того, щоб у разі якщо після проведених маніпуляцій нормальну роботу сайту буде порушено, відновити його.
Редагування файлів шаблону теми.
Редагування вихідних записів можна здійснювати декількома способами: редагування файлів по FTP, через файловий менеджер хостингу або через адміністративну панель WordPress. Ми радимо використовувати останній варіант, так як він є найшвидшим та найпростішим.

1. Warning: The type attribute is unnecessary for JavaScript resources.

Попередження. Атрибут «type» елемента <script> не є обов’язковим для ресурсів JavaScript.

Warning: The type attribute for the style element is not needed and should be omitted.

Попередження. Атрибут «type» для елемента <style> не потрібен і його слід опустити.

Для усунення двох попереджень необхідно видалити атрибут ENGINE=”text/javascript” у всіх тегах <script>, а також type=”text/css” у всіх тегах <style>. На допомогу нам приходить проста функція PHP preg_replace у парі з чудовою можливістю фільтрації даних у WordPress. Код виглядає так:

# видаляємо атрибут type="text/javascript" у всіх тегах <script>, а також type=”text/css” у всіх      тегах <style>
add_filter('style_loader_tag', 'remove_type_attr');
add_filter('script_loader_tag', 'remove_type_attr');
function remove_type_attr($src) {
    return preg_replace( "/type=['\"]text\/(javascript|css)['\"]/", '', $src );
}

Вставити цей код необхідно у файл functions.php теми, що використовується. Для цього авторизуємося в адміністративній панелі WordPress, вибираємо пункт меню «Зовнішній вигляд» -> «Редактор» і праворуч у списку файлів вибираємо потрібний нам файл. Код вставляємо наприкінці файлу. Натискаємо кнопку «Оновити файл».

Додатково видалимо цей атрибут у деяких файлах вашої WordPress теми.

У меню «Зовнішній вигляд» -> «Редактор» вибираємо цікаві для нас файли – index.php, header.php, footer.php. Пошук атрибута будемо здійснювати за допомогою кнопок пошуку Ctrl+F, ввівши в пошуковій панелі text/javascript. Виявивши такий запис замінюємо <script type=”text/javascript”> на <script>, тобто видаляємо атрибут, що не сподобався type=”text/javascript” і не забуваємо натиснути кнопку «Оновити файл». Перевіряємо результат.

2. Error: The center element is obsolete. Use CSS instead.

Помилка. Тег <center> застарів. Використовуйте відповідні стилі CSS.

HTML 5 активно взаємодіє з CSS (мова опису зовнішнього вигляду документа, написаного з використанням HTML), тому заборона на багато тегів і атрибутів, розпочата в HTML 4 на користь стилів, тільки посилилась. Такі теги та атрибути вже не підтримуються деякими браузерами і повинні виключатися з коду. Одним із таких тегів є тег <center>, а також атрибут “frameborder” тега <iframe>. При вирішенні даних помилок нам необхідно буде трохи «почаклувати» над нашою Базою даних сайту.

Для цього необхідно зайти в панель управління вашого хостингу, перейти за посиланням у phpMyAdmin та авторизуватися.

Насамперед експортуємо всю базу даних у якості резервної копії! Для цього натискаємо кнопку «Експорт» на панелі веб-інтерфейсу для адміністрування. Далі вибираємо закладку «SQL» для здійснення SQL запитів до бази даних, у нашому випадку пошук та заміна застарілих тегів та атрибутів. Прописуємо наступні запити:

#пошук та заміна відкриваючого тега <center> на контейнер <div> 
UPDATE wp_posts SET post_content = REPLACE (post_content, '<center>', '<div class="ag_center">');
#пошук та заміна закриваючого тега <center> на контейнер <div> 
UPDATE wp_posts SET post_content = REPLACE (post_content, '</center>', '</div>');
#пошук та заміна атрибута “frameborder” на стильовий клас “ag_border_zero” 
UPDATE wp_posts SET post_content = REPLACE (post_content, 'frameborder="0"', 'class="ag_border_zero"');

Розглянемо докладніше вище представлені SQL запити.

Першим рядком замінюємо застарілий тег на контейнер <div> і одразу задаємо клас “ag_center”. Цей стильовий клас дозволить нам вирівняти вміст контейнера по центру. Для цього заходимо в адмін панель WordPress, вибираємо пункт меню «Зовнішній вигляд» -> «Редактор» -> файл style.css нашої теми. У кінець файлу додаємо наступні рядки коду:

.ag_center {text-align:center;}

.ag_border_zero {border=0;}

Другим рядком SQL запиту замінюємо закриваючий тег </center> на закриваючий </div>. А третім – робимо заміну атрибут frameborder=”0” на клас “ag_border_zero” елементу <iframe>.

SQL запити можна оптимізувати, звівши в один, проте простіше для розуміння та наочності розбити завдання на кілька запитів, як ми це зробили. Вам, звичайно, можуть потрапити інші застарілі теги, які необхідно буде замінити на універсальний тег <div> і перенести пряме призначення в стильовий файл.

Перелік тегів, які більше не підтримуються та мають виключатися з коду:

<applet>, <acronym>, <bgsound>, <dir>, <frame>, <frameset>, <noframe>, <isindex>, <listing>, <xmp>, <nextid>, <noembed>, <plaintext>, <rb>, <strike>, <basefont>, <big>, <blink>, <center>, <font>, <marquee>, <multicol>, <nobr>, <spacer>, <tt>, <u>.

Перевіряємо результат.

3. Error: The width attribute on the th element is obsolete. Use CSS instead.

Помилка. Атрибут “width” елементу <th> застарів. Використовуйте відповідні стилі CSS.

Аналогічно до попередньої помилки, атрибут “width” елементу <th> також є застарілим. Виправити цю помилку можна двома способами – замінити width=”10%” на style=”width:10%;”. Або, щоб не описувати щоразу стиль всередині тега, можна виділити стиль у зовнішню таблицю стилів. Тобто у елемент <th> додаємо class=”width_ten_percent”, а у файл style.css нашої теми .width_ten_percent {width:10%;}. Який спосіб простіше, вибирати вам!

Якщо дана помилка несе масовий характер у статтях вашого проекту, скористаємося пошуком та заміною атрибуту “width” на панелі phpMyAdmin наступним SQL запитом:

#пошук та заміна атрибута “width” на “style=”width:10%;”” UPDATE wp_posts SET post_content = REPLACE (post_content, ‘width=”10%”’, ‘style=”width:10%;”‘);

Або:

#пошук та заміна атрибута “width” на стильовий клас “width_ten_percent” UPDATE wp_posts SET post_content = REPLACE (post_content, ‘width=”10%”’, ‘class=”width_ten_percent”’);

Після цього необхідно додати стильовий клас width_ten_percent у файлі style.css: .width_ten_percent {width:10%;}

Слід зазначити, що при масовій заміні застарілих атрибутів на стильові класи в панелі phpMyAdmin, за наявності вже прописаного класу елемента (наприклад, <img class=»width_twenty_percent» class=»width_ten_percent» />), може виникнути інша помилка — дублювання атрибуту “class”. Подібна ситуація і з атрибутом “style” (наприклад, <img style=”width: 300px” style=”height: 200px”>). Тому потрібно бути впевненим у відсутності раніше зазначеного іншого атрибуту “class” / “style”, або відмовитися від редагування БД SQL запитами на користь ручної перевірки та редагування кожної окремої статті у редакторі адмін панелі WordPress.

Наприклад, розглянемо додавання додаткового класу / властивості атрибуту “style”, дотримуючись стильових правил. Додамо додатковий клас width_ten_percent до вже наявного color_red (class=”color_red”), і отримуємо: class=”color_red width_ten_percent” (перераховуємо імена класів через пробіл). Додамо ширину в 10% до вже наявного. width: 10%; (стильові властивості розділяються між собою крапкою з комою та пробілом).

Також хотілося б відзначити часте помилкове використання атрибута “width” для елемента <tr>, атрибута “height” для елемента <td>.

Періодично перевіряйте новий контент на наявність даних помилок, і у разі потреби повторіть процедуру виправлення.

Перелік атрибутів, які не підтримуються і мають виключатися з коду:

Застарілі атрибути	Елемент
charset, coords, shape, methods, name, rev, urn	<a>
nohref	<area>
alink, bgcolor, link, marginbottom, marginheight, marginleft, marginright, margintop, marginwidth, text, vlink	<body>
clear	<br>
name	<embed>
profile	<head>
version	<html>
longdesc	<iframe>
longdesc, lowsrc, name	<img>
usemap	<input>
charset, methods, rev, target, urn	<link>
scheme	<meta>
name	<option>
archive, classid, code, codebase, codetype, declare, standby	<object>
type, valuetype	<param>
event, for, language	<script>
datapagesize	<table>
abbr, axis	<td> и <th>

Перевіряємо результат.

4. Error: Bad value 300px for attribute width on element img: Expected a digit but saw px instead.

Помилка. Неприйнятне значення “300px” для ширини атрибута в елементі <img>: Очікувалася цифра, але натомість прочитав “px”.

Атрибути елементів є важливою частиною розмітки HTML. Деякі атрибути елементів можуть набувати практично будь-якого значення, інші можуть набувати лише значень певного типу, а треті – набувати значення лише з наперед визначеного набору.

У контексті <img width=”300px” /> атрибутом “width” допускається приймати будь-яке ціле позитивне число. Необхідно встановити допустиме значення для правильної розмітки, а саме 285 без вказівки одиниці вимірювання (px).

Виявлені помилки можуть бути не тільки в записах, налаштуваннях WordPress теми, але й у вмісті HTML коду віджетів сайдбару. У таких випадках для усунення помилки заходимо в меню «Зовнішній вигляд» -> «Віджети» -> Сайдбар зліва (праворуч/підвал) і в налаштуваннях віджету знаходимо помилково вказаний атрибут “width” видаливши одиницю виміру (px).

Додатково трапляється помилкова вказівка параметра атрибута height елемента <img>.

Перевіряємо результат!

5. Error: Dublicate ID id_name.

Використання імені стильового ідентифікатора (id=«ім’я») більше одного разу на одній сторінці.

Стильовий ідентифікатор – унікальне ім’я елемента, яке використовується для зміни його стилю та звернення до нього через скрипти. Ідентифікатор у коді документу має бути у єдиному екземплярі, тобто зустрічатися лише один раз.

6. Имя класса и идентификатора должны обязательно начинаться с латинского символа (A–Z, a–z).

Ім’я класу та ідентифікатор повинні починатися з латинського символу (A-Z, a-z). Може містити цифри (0-9), символ дефісу (-) та підкреслення (_), але не на початку слова. Використання російських чи українських букв у іменах ідентифікатора є неприпустимим.

7. Ошибочное использование тега noindex по синтаксису.

Тег noindex використовується для виключення контенту, який потрібно приховати від пошукової системи Яндекс. Наприклад, дублі елементів навігації. Проте багато хто використовує його неправильно:

<noindex>Текст або код, який потрібно виключити з індексації</noindex>

Для того, щоб зробити код з noindex валідним, рекомендується використовувати таку конструкцію:

<!––noindex––>Текст або код, який слід виключити з індексації <!––/noindex––>

8. Error: No p element in scope but a p end tag seen.

Відсутній відкриваючий або закриваючий тег.

У синтаксисі тегів зазвичай використовуються парні теги для позначення початку та кінця елемента. Закриваючий тег схожий на той, що відкриває, але містить слеш (/) всередині кутових дужок і вказується відразу за дужкою, що відкривається. Якщо ви відкрили тег у документі HTML, його необхідно закрити у відповідному місці. Інакше це може викликати проблеми з коректним відображенням елементу у браузері.

9. Error: Element p not allowed as child of element span in this context. (Suppressing further errors from this subtree.)

Блокові елементи всередині строчних

Відповідно до специфікації блоковий елемент заборонено вставляти всередину рядкового. Наприклад, <span><p>Lorem ipsum…</p></span> не пройде валідацію, правильно вкласти теги навпаки — <p><span>Lorem ipsum…</span></p>.

Найбільш часто використовуваними блоковими елементами є:

<address>, <article>, <aside>, <blockquote>, <dd>, <div>, <dl>, <dt>, <details>, <fieldset>, <figcaption>, <figure>, <footer>, <form>, <h1>-<h6>, <header>, <hr>, <iframe>, <li>, <legend>, <nav>, <noscript>, <ol>, <output>, <optgroup>, <option>, <p>, <pre>, <section>, <summary>, <table>, <ul>

Вбудовані (строчні) елементи:

<a>, <area>, <b>, <bdo>, <bdi>, <cite>, <code>, <dfn>, <del>, <em>, <i>, <img>, <ins>, <kbd>, <label>, <map>, <mark>, <s>, <samp>, <small>, <span>, <strong>, <sub>, <sup>, <time>, <q>, <ruby>, <u>, <var>

10. Error: An img element must have an alt attribute, except under certain conditions. For details, consult guidance on providing text alternatives for images.

Відсутній атрибут alt у зображенні.

Кожне зображення (навіть якщо воно служить для дизайнерських цілей) у документі HTML має мати атрибут “alt” із описом змісту картинки. Цей атрибут індексується пошуковими роботами і використовується для визначення вмісту виявлених картинок. А це, у свою чергу, важливо як для покращення релевантності веб-сторінок, так і для залучення на сайт додаткового трафіку з пошуку по картинках.

Пам’ятка для контент-менеджерів

Для наших контент-менеджерів ми підготували пам’ятку, як правильно оформити веб-сторінку, використовуючи валідний код. Ділимося нею з вами, користуйтесь на здоров’я:

Завершення

Результатом ретельної роботи над помилками ми маємо побачити наступне: Перевірка документа завершена. Будь-яких помилок та попереджень не виявлено («Document checking completed. No errors or warnings to show.»).

Що ви думаєте про важливість валідації? З якими помилками стикалися Ви та як їх вирішували? Додайте до цієї статті свої коментарі!