Валідність HTML коду: перевірка і виправлення помилок
Валідація є одним з найбільш важливих аспектів гарного веб-дизайну. Давайте розглянемо, що це таке і як перевірити 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 код безпосередньо.
Служба перевірки HTML розмітки W3C
Сервіс перевірить зазначені вами дані на помилки і сформує звіт з їх переліком та рекомендаціями щодо виправлення.
Умовно помилки і попередження можна розділити на два основних типи: шаблонні (пов'язані з обраною темою і встановленими плагінами) і помилки, допущені при оформленні унікального контенту.
Перевіряючи веб-сторінку в перший раз, не лякайтеся можливого великої кількості помилок! Як правило, більшість з них багаторазово повторюються на аналізованої сторінці. А це означає, що якщо прибрати помилку в одному місці шаблону або сторінки, то вона зникне і у всіх однотипних.
Величезна кількість помилок пов'язано з використовуваної темою сайту, а також встановленими плагінами. Більшість з нас встановлює безкоштовну тему і плагіни, не замислюючись, що в них приховано. У багатьох темах при більш глибокому вивченні доводиться стикатися з типовими помилками.
Виправити виявлені помилки можна двома способами: звернутися до фахівців, заплативши N-ну суму грошей, або виправити їх самостійно. Розглянемо останній варіант на реальних прикладах і усунемо всі неточності, слідуючи докладним інструкціям.
Важливо, резервне копіювання !!!
Перед здійсненням будь-яких змін у вихідному коді сайту необхідно провести резервне копіювання файлів сайту і бази даних. А потрібно це для того, щоб в разі, якщо після проведених маніпуляцій нормальна робота сайту буде порушена, відновити його.
Редагування файлів шаблону теми.
Редагування початкових кодів можна здійснювати декількома способами: редагування файлів по FTP, через файловий менеджер хостингу або через адміністративну панель WordPress. Ми рекомендуємо використовувати останній варіант, тому що він є найшвидшим і простим.
- The attribute is unnecessary for JavaScript resources.
Попередження. Атрибут "type" елемента <script> не є обов'язковим для JavaScript ресурсів.
The attribute for the element is not needed and should be omitted .
Попередження. Атрибут "type" для елемента <style> не потрібен і його слід опустити.
Для усунення даних двох попереджень необхідно видалити атрибут type = "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
Додатково видалимо даний атрибут в деяких файлах вашої WordPress-теми.
В меню "Зовнішній вигляд" -> "Редактор" вибираємо цікавлять нас файли - index.php, header.php, footer.php. Пошук атрибута будемо здійснювати за допомогою гарячих кнопок пошуку Ctrl + F, ввівши в пошуковій панелі text / javascript. Виявивши такий запис замінюємо <script type = "text / javascript"> на <script>, тобто видаляємо не сподобався атрибут type = "text / javascript" і не забуваємо натиснути кнопку "Оновити файл".
Перевіряємо результат.
- The element is obsolete. Use CSS instead.
Помилка. Тег <center> застарів. Використовуйте відповідні CSS стилі.
HTML 5 активно взаємодіє з CSS (мова опису зовнішнього вигляду документа, написаного з використанням HTML), тому заборона на багато теги і атрибути, розпочатий в HTML 4 на користь стилів, тільки посилився. Такого роду теги і атрибути вже не підтримуються деякими браузерами і повинні бути виключені із сфери коду. Одним з таких тегів є тег <center>, а також атрибут "frameborder" тега <iframe>. При вирішенні таких помилок може нам необхідно буде трохи "поворожити" над нашою Базою даних сайту.
Для цього необхідно зайти в панель управління хостингом, перейти за посиланням в phpMyAdmin і авторизуватися.
Панель управління хостингом
Панель управління 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 запити в панелі управління phpMyAdmin
Розглянемо більш докладно вище представлені 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>.
Перевіряємо результат.
- The attribute on the 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% до вже наявного style = "color: red;", в результаті у нас повинно вийти так: style = "color: red; 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>
Перевіряємо результат.
- Bad value for attribute on element img: Expected a digit but saw instead.
Помилка. Неприйнятне значення "300px" для ширини атрибута в елементі <img>: Очікувалася цифра, але замість того прочитав "px".
Атрибути елементів є важливою частиною HTML розмітки. Деякі атрибути елементів можуть приймати практично будь-яке значення, інші можуть приймати тільки значення певного типу, а треті - приймати значення тільки з заздалегідь визначеного набору.
В контексті <img width = "300px" /> атрибутом "width" допускається приймати будь-яке ціле позитивне число. Необхідно встановити допустиме значення для правильної розмітки, а саме 285, без вказівки одиниці виміру (px).
Виявлені помилки можуть перебувати не тільки в записах, налаштуваннях WordPress теми, але і по змісту HTML коду віджетів сайдбара. У таких випадках для усунення помилки заходимо в меню "Зовнішній вигляд" -> "Віджети" -> Сайдбар зліва (справа / підвал) і в налаштуваннях віджета знаходимо помилково зазначений атрибут "width" видаливши одиницю виміру (px).
Редагування вмісту віджетів в адміністративній панелі WordPress
Додатково зустрічається помилкове зазначення параметра атрибуту "height" елемента <img>.
Перевіряємо результат!
- Dublicate ID.
Використання імені стильового ідентифікатора (id = "ім'я") більше одного разу на одній сторінці.
Стильової ідентифікатор - унікальне ім'я елемента, яке використовується для зміни його стилю і звернення до нього через скрипти. Ідентифікатор в коді документа повинен бути в єдиному екземплярі, тобто зустрічатися тільки один раз.
- Ім'я класу і ідентифікатора повинні обов'язково починатися з латинської символу (A-Z, a-z).
Ім'я класу і ідентифікатор повинен обов'язково починатися з латинської символу (A-Z, a-z). Може містити цифри (0-9), символ дефіса (-) і підкреслення (_), але не на початку слова. Використання російських букв в іменах ідентифікатора неприпустимо.
- Помилкове використання тега noindex по синтаксису.
Тег noindex використовується для виключення контенту, який необхідно приховати від пошукової системи Яндекс. Наприклад, дублі елементів навігації. Однак багато хто використовує його невірно:
<Noindex> Текст або код, який потрібно виключити з індексації </ noindex>
Для того, щоб зробити код з noindex дійсним, рекомендується використовувати наступну конструкцію:
<! - noindex -> Текст або код, який потрібно виключити з індексації <! - / noindex ->
- No element in scope but a end tag seen .
Відсутня відкриває або закриває тег.
У синтаксисі тегів зазвичай використовуються парні теги для позначення початку і кінця елемента. Закриває тег схожий на відкриває, але містить слеш (/) всередині кутових дужок і вказується відразу за відкривається дужкою. Якщо ви відкрили тег в HTML документі, його необхідно закрити у відповідному місці. В іншому випадку, це може викликати проблеми з коректним відображенням елемента в браузері.
- Element not allowed as child of element 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>
- An element must have an 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.").
Що ви думаєте про важливість валідації? З якими помилками стикалися Ви і як їх вирішували? Додайте до цієї статті свої коментарі!
Автор статті:
Олександр Рибак
Web-розробник в компанії ApollonGuru. Беру активну участь в розробці коду для впровадження SEO рекомендацій. Улюблена мова програмування: PHP.
Ви коли-небудь замислювалися про те, як браузери "читають" веб-сторінку?
А як же це вплине на SEO?
Що ви думаєте про важливість валідації?
З якими помилками стикалися Ви і як їх вирішували?