Навіщо потрібний валідний код і як усунути помилки валідації. Помилки валідації: що це, як перевірити, чи потрібно видаляти, як впливають на SEO Повідомлення про помилки

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

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

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

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

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

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

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

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

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

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

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

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

У цій статті ми розберемося, як можна оптимізувати дизайн програми для запобігання користувальницьких помилок і як створити ефективні повідомлення про помилку у разі, якщо помилки виникають незалежно від того, що вводить користувач. Також, ми розглянемо, як добре оброблена помилка може перетворити невдачу у захоплення. Adobe представив новий додаток для дизайну та проектування Experience Design (Adobe XD), який дозволяє створювати дизайн інтерактивних проектів та станів помилок. Ви можете скачати та спробувати Adobe XD безкоштовно.

Що таке стан помилки?

Стан помилки – це екран, який показується користувачеві, коли щось пішло не так. Це приклад ситуації, коли користувач робить щось, що відрізняється від бажаного стану. Так, як помилки можуть виникати в несподіваних поєднаннях, ці стани можуть включати в себе зовсім різні проблеми: від несумісності операцій користувача (наприклад, некоректне введення даних) до неможливості програми підключитися до сервера або навіть неможливості обробити запит користувача.

Екрани з помилками

Кожна помилка, незалежно від її причини, стає каменем спотикання для користувача на шляху просування UX. На щастя, правильно оформлена помилка може зменшити неприємний ефект.

Профілактика краща за лікування

Якщо ви створюєте програму, ви повинні розуміти, які основні взаємодії користувача з програмою можуть призвести до помилки. Наприклад, зазвичай дуже важко правильно заповнити форму з першої спроби, або неможливо коректно синхронізувати дані, якщо пристрій поганий мережне з'єднання. Ви повинні враховувати такі моменти, щоб мінімізувати можливість виникнення помилок. Іншими словами, краще запобігти можливості помилитися за допомогою показу порад, використання обмежень та гнучкості.

Наприклад, якщо ви даєте людям можливість пошуку та резерву готелів, навіщо залишати доступними дати в минулому та виводити помилку, якщо користувач обирає таку дату?

Як показано на прикладі Booking.com, ви можете просто використати вибір дати, який дозволяє користувачам вибрати лише сьогоднішню дату та дати у майбутньому. Це спонукатиме користувачів вибирати тільки валідні дати.


Вибір дати в Boocking.com. Відображається повний місяць, але дати в минулому недоступні.

Екран помилки для валідації форми

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

  • Правильний час для інформування про помилки (або успішне заповнення)
  • Правильне місце для валідаційного повідомлення
  • Правильний колір повідомлення
  • Зрозуміла мова повідомлення

Правильне час (валідація рядка)

Валідація помилок форми неминуча, і є логічною частиною введення даних (з тих пір, як введення даних користувачем може супроводжуватися помилками). Звичайно, стани, які можуть спричинити помилку, мають бути мінімізовані, але валідацію помилок прибирати не можна. Отже, найважливіше питання: "Як спростити процес відновлення після помилки для користувача?"

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

Валідація має моментально інформувати користувача про коректність даної відповіді відразу після того, як користувач запровадив дані. Головний принцип хорошої валідації говорить: “Говоріть із користувачами! Кажіть їм, що не так! та валідація рядка у режимі реального часу інформує користувачів про коректність введених даних. Такий підхід дозволяє користувачам швидко виправити помилки та не чекати на відображення помилок після натискання кнопки підтвердження.

Однак слід уникати валідації кожного натискання клавіші тому, що в більшості випадків ви не зможете верифікувати дані до того, як користувач закінчить друкувати свою відповідь. Форми, які валідують значення відразу в процесі набору, починають дратувати користувача відразу, як тільки він починає вводити дані.


Google формивідображають помилку імейлу навіть коли ви ще не перестали друкувати.

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


Валідація в Apple Store здійснюється після введення даних.

Михайло Конжевич у своїй статті “Волідація рядка у формах – створення досвіду! досліджував різні валідаційні стратегії та запропонував гібридну стратегію: рання нагорода, пізнє покарання.


Гібрид – рання нагорода, пізнє покарання – підхід

Правильне місце

Орієнтація на користувача – ще один важливий інструмент. Коли ви гадаєте, яке місце вибрати для валідаційного повідомлення, виконайте таку пораду: завжди розміщуйте повідомлення в контексті дії. Якщо ви хочете сказати користувачеві про помилку в конкретному полі, покажіть це поруч. Швидку валідацію найкраще розміщувати праворуч від поля введення або під ним.

Помилки у вигляді реального часу.

Правильний колір (інтуїтивний дизайн)

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

Текст помилки повинен бути зрозумілим та чітко виділятися на тлі програми.

Чітке повідомлення

Типове повідомлення про помилку могло б говорити: "імейл некоректний", без пояснення користувачеві чому імейл некоректний. (Типографіка? Імейл зайнятий іншим користувачем?) Прямолінійні інструкції або гайдлайн можуть зробити все по-іншому. Ви можете побачити на прикладі, як форма інформує користувача про те, що його імейл вже зайнятий. Також з'являється кілька пропозицій (логін або відновлення пароля).

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

  • Повідомлення про критичну помилку.Повідомлення, які говорять про внутрішньої помилкикоду програми або містять текст типу: "відбулася помилка тип 2" - загадкові та відлякують.
Повідомлення про помилку, написане розробником для розробника.
  • Тупикова помилка.Просто тому, що такі повідомлення не надають жодного корисної інформаціїдля користувача.
Екран з помилкою на Spotify говорить: "Відбулася помилка" і не містить варіантів та кроків щодо вирішення проблеми.
  • Повідомлення про невизначену помилку.Такий екран (на прикладі нижче) дає користувачеві стільки інформації, як і попередній. Користувачі гадки не мають, що це означає і що з цим робити.
Програма Buffer містить хороше повідомлення про помилку, але вона не несе жодної інформації для користувача.

Не лякайте користувача помилками. Також не намагайтеся ввести користувача в технічні деталі проблеми. Говоріть про помилку простою та зрозумілою мовою. Для цього постарайтеся не використовувати технічний жаргон і висловлюйте свої думки мовою користувача.

Зробіть ваші повідомлення читабельними та корисними - помилки повинні бути ввічливими, чіткими та повчальними, і містити таку інформацію:

  • Що пішло не так і чому (можливо).
  • Що повинен зробити користувач, щоб виправити помилку?
Програма Remote app пояснює, чому користувачі нічого не бачать і пропонує рішення.

Включайте гумор та зображення у повідомлення про помилки

Повідомлення про помилки – чудова можливість для використання іконок та ілюстрацій тому, що люди краще сприймають візуальну інформацію, ніж просто текст. Але ви можете піти ще далі і додати зображення до вашої програми, що буде корисним для користувачів. Це дозволить персоналізувати вашу програму і пом'якшити ваше повідомлення.

Azendoo використовує ілюстрацію та гумор для того, щоб надихнути користувача вирішити проблему.

Гумор продовжує життя. Небагато гумору ніколи не зашкодить і допоможе пом'якшити сум'яття від помилки. Ви можете знайти безліч прикладів кумедних повідомлень в Littlebigdetails. Ось деякі з моїх коханих:

  • Basecamp: При помилці валідації форми, герой зліва робить здивований вираз обличчя.

  • Трохи нахабне повідомлення про помилку відображається при спробі ввести занадто багато точок під час створення нового облікового запису в Gmail.

Однак, будьте обережнішими з гумором тому, що він може бути не завжди доречним у вашому повідомленні про помилку; це залежить від ступеня брутальності помилки. Наприклад, гумор добре застосовується для простої проблеми валідації, як “404 помилка” (сторінку не знайдено). Але коли користувач витрачає певну кількість часу на перегляд сторінки, на якій написано "Ох!" - Це виглядає недоречно.

Вичерпний чекіст ідеальної сторінки з повідомленням про помилку

Хороші сторінки помилок є рукою допомоги для користувачів і повинні відповідати наступним шести критеріям:

  1. Повідомлення про помилку з'являється динамічно відразу після виявлення помилки. Воно має інформувати користувача про проблему.
  2. Бути безпечним для введених даних. Ваша програма не повинна ламати, видаляти або скасовувати те, що ввів або завантажив користувач у момент виявлення помилки.
  3. Говорити з користувачем однією мовою. Повідомлення має давати чітке розуміння, що пішло негаразд і чому; що користувачеві потрібно зробити для того, щоб виправити помилку?
  4. Не шокуйте користувачів і не вводьте їх у замішання. (Повідомлення не повинно бути сильно зухвалим).
  5. Не втрачайте контроль над системою. (Якщо проблема не критична, користувач повинен мати можливість з рештою програми).
  6. Використовуйте почуття гумору для пом'якшення проблеми.

Рішення для найбільш популярних помилок

404 помилка (сторінка не знайдена)

Основна мета сторінки з 404 помилкою - перенаправити вашого користувача на сторінку, яку він шукав якнайшвидше. Ваша сторінка 404 повинна пропонувати кілька ключових посилань, куди користувач може перейти. Найбезпечніший варіант – це наявність посилання на “головну сторінку” сайту на 404 сторінці. Також, ви можете розмістити "повідомити про проблему" для того, щоб користувач повідомив вас, що сторінка не працює. Але переконайтеся, що перехід на головну сторінку є більш явним переходом і більше виділяється візуально.

Проблема з логіном

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

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

  • Користувач забув своє ім'я на сайті. Якщо ви виявили подібну помилку, ви повинні запропонувати посилання, де користувач може виправити це. Скажіть користувачеві, де він може його отримати (наприклад: “перевірте пошту, ми надіслали вам листа”) або надайте посилання на відновлення імені на сайті.

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

Відхилення кредитної картки

Відхилення кредитної картки може статися з кількох причин: помилка у форматуванні даних (друкарська помилка або брак даних) або картка може бути відхилена через те, що вона прострочена або викрадена. Габріель Томеску у своїй статті "Анатомія форми кредитної картки", запропонував наступну стратегію для обох помилок:

Для першої проблеми, вам слід дотримуватися стандартної валідації рядка та візуальної індикації помилки:

Однак, коли кредитна картавідхиляється платіжною системоюз певної причини зазвичай це виглядає, як викрадення. Вам потрібні чіткі дані від користувача. І навіть після того, вам все одно необхідно повідомити користувача про те, що сталося; повідомлення про помилку має бути гранично зрозумілим.

Проблема зі з'єднанням

Інтернет з'єднання є не скрізь і оффлайн підтримка має бути ключовим аспектом у житті будь-якої сучасної програми. Коли з'єднання обривається, необхідно добре продумати оффлайн UX. Користувачі повинні мати можливість взаємодіяти з якомога більшою частиною вашої програми. Це означає, що програма повинна кешувати контент для хорошого UX оффлайн.

Теги: , , ,

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

Принципи

Завдання дизайнера - зробити так, щоб користувач не припустився помилки і валідація не знадобилася, для цього:

  1. Обмежте вибір свідомо неправильних значень у списку: блокуйте ці значення або не показуйте у списку.
  2. Обмежте введення невідповідних символів. Якщо в полі потрібно вводити лише цифри, і це очевидно користувачеві, ігноруйте введення букв замість того, щоб показати помилку. Використовуйте маски в полях, де відомий формат.
  3. Напишіть підказки для заповнення форми. Наприклад, плейсхолдер у полях введення.

Валідацію на щойно відкритій порожній формі заборонено. Виняток – чернетки, коли користувач вже заповнював цю форму, через якийсь час повернувся до неї, а вона заповнена з помилками.

Види валідації

Існує три види валідацій: миттєва, втрата фокусу і відправлення форми.

Чим раніше інтерфейс повідомляє про помилку, тим краще – користувачеві простіше повернутися та виправити помилку.

Самий швидкий спосібповідомити про помилку – миттєва валідація. Але вона можлива лише у випадках, коли у процесі введення зрозуміло, що значення некоректне. Зазвичай такі помилки пов'язані з неправильною розкладкою клавіатури (кирилиця замість латиниці) або введенням літер у цифрове поле (ІПН, КПП та ін.). Для цих випадків ми використовуємо поля з масками: введення невідповідних символів у них заблоковано. Тому в наших інтерфейсах є лише два види валідації:

  • за втратою фокусу- основний вид валідації
  • з відправлення форми- для тих випадків, коли валідація зі втрати фокусу неможлива.

Валідація за втратою фокусу

Коли використовувати

Як працює

Не валідуйте поля на порожнечу через втрату фокусу - не показуйте помилку якщо поле не заповнене, можливо, користувач повернеться і заповнить поле трохи пізніше. Показувати помилку в таких випадках можна лише після надсилання форми.

Валідація спрацьовує відразу після втрати фокусу, якщо значення у полі заповнено. Якщо знайдено помилку, поле підсвічується червоним. Фокус у це поле автоматично не повертається:

Текст помилки з'являється в тултипі, коли поле отримує наведення або фокус:

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

Червоне підсвічування знімається з поля, коли користувач почав виправляти помилкове значення.

Валідація при відправленні форми

Коли використовувати

Використовуйте цей вид валідації, коли не можна перевірити поля втрати фокуса. Наприклад, для перевірки заповнення обов'язкових полів.

Як працює

Перевірка відбувається після того, як користувач натиснув кнопку відправки даних: усі поля з помилками на формі підсвічуються, сторінка прокручується до першого поля з помилкою, фокус переміщається в це поле, курсор встає в кінець рядка, поряд з полем з'являється тултип із підказкою.

При прокручуванні до першого поля від верхньої межі вікна до помилкового поля залишається відступ 48px-шість модулів.

Блокування кнопки надсилання

У невеликих формах, замість перевірки заповнення обов'язкових полів, можна блокувати кнопку відправлення форми. Використовуйте цю поведінку, коли очевидно, чому кнопка надсилання форми неактивна. Наприклад, на формі входу:

Як тільки заповнені всі обов'язкові поля – кнопка стає активною. Якщо після цього користувач стирає значення в одному з полів - кнопка знову повинна стати не активною.

Повідомлення про помилки

Про помилки можна повідомляти двома способами:

Тултипи

Як працюють

Тултип із підказкою з'являється у двох випадках:

  1. Під час наведення на поле з помилкою.
  2. Коли поле з помилкою отримує фокус.

Якщо значення в полі з помилкою було змінено, втратило фокус, а потім знову опинилося у фокусі - тултип з текстом старої помилки вже не виникає. Це правило однаково працює для всіх типів валідацій: і втратою фокусу, і при відправленні форми.

Тултип за наведенням перекриває тултип по фокусу.


Тултип може з'являтися зверху або праворуч від контролю помилки, так щоб він не перекривав корисну інформацію:


Одноманітність поведінки та зовнішнього вигляду

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

Червоні тексти на сторінці

Як працюють

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

Як тільки користувач почав виправляти значення, червоне підсвічування поля зникає, і колір тексту помилки змінюється на  #333.

Текст помилки пропадає через втрату фокусу і більше не з'являється, якщо поле наново отримує фокус. Це правило однаково працює для всіх типів валідацій: і втратою фокусу, і при відправленні форми.

Виводьте текст помилки праворуч, якщо на формі є місце, а повідомлення коротке. Так форму не доведеться розсувати, щоби показати помилку.

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


На складніших формах виводьте повідомлення про помилку в тултипі.

Валідація залежних полів

Залежні поля - поля, значення яких залежить друг від друга.

Помилки, пов'язані з порушенням залежності полів, ми показуємо після сабміту форми. Наприклад, ІПН і КПП. Якщо користувач вказав ІПН із 10 цифр, а поле з КПП залишив порожнім, після відправлення форми порожнє поле з КПП буде підсвічене.

ІПН може бути двох видів:

Якщо користувач вказав ІПН із 12 цифр, значить організація – індивідуальний підприємець, і в неї немає КПП, значить поле КПП заповнювати не потрібно. І навпаки, якщо заповнено КПП, а ІПН вказаний 12-значний, можливо невірно вказаний ІПН.

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

Якщо під час заповнення залежного поля порушено формат значення, повідомляйте про таку помилку при втраті фокусу. Наприклад, користувач ввів 3 цифри в полі ІПН і прибрав фокус. Таке поле має підсвітитися одразу.

приклад

Є форма з 5 полів:

  • Назва організації- Просте текстове, обов'язкове
  • ІПН- 10 чи 12 цифр, перевірка контрольної сумиза втратою фокусу, обов'язкове
  • КПП- 9 цифр з перевіркою контрольної суми зі втрати фокусу, обов'язкове, якщо ІПН складається з 10 цифр
  • Електронна пошта- адреса пошти, перевірка втрати фокусу по масці [email protected], необов'язкове
  • Телефон- міжнародний формат, перевірка зі втрати фокусу по масці +00000000000, обов'язкова

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

Найбільш популярний і валідатор, що зарекомендував себе, на наш погляд, - validator.w3.org, він сканує сайт на наявність помилок відповідно до прийнятих Консорціумом Всесвітньої павутини стандартів. Даний валідатор має 3 способи перевірки на помилки: ввести URL-адресу конкретної сторінки вашого сайту, завантажити файл сторінки сайту та ввести частину коду сайту, яку необхідно перевірити.

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

Існує функція фільтрації помилок, за допомогою якої ви можете виправляти по черзі конкретні групи помилок, крім цього для кожної помилки надається посилання на стандарти w3c , де можна ознайомитися з причиною появи цієї помилки.

Також є плагіни для браузерів для пошуку помилок на сторінках сайту.

http://users.skynet.be/mgueury/mozilla/ - плагін для Mozilla

https://chrome.google.com/webstore/detail/html-tidy-browser-extensi/- плагін для Chrome

https://addons.opera.com/en/extensions/details/validator/ - плагін для Opera

Після того як сайт перевірили на помилки, постає цілком резонне питання: чи потрібно їх негайно видаляти і чим це може призвести до SEO-просування?

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

Насамперед рекомендую звернути увагу до помилки, пов'язані з контентом, т.к. для пошукових систем даний фактор є важливим при ранжируванні сайтів. Якщо помилок на сторінках сайту досить багато (більше 25), то рекомендується усувати помилки в коді, т.к. сайти з великою кількістю помилок довше завантажуються, а також їх складніше проіндексувати, що може спричинити відсутність частини сторінок сайту в індексі пошукової системи.

Давайте проаналізуємо, скільки помилок є у коді сторінок у великих ресурсів.

ВАТ «РЗ»:

Як ви вже помітили, навіть у сайтів пошукових систем є помилки в коді сторінок, що вкотре підтверджує, що усунення помилок носить швидше рекомендаційний характер, при цьому варто згадати, що не потрібно нехтувати цим фактором і «запускати» ваш сайт. Розвивайте сайт комплексно, всебічно, тоді і результат відповідатиме вашим очікуванням.

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