Семантична верстка HTML5: теги та значення для SEO

Дві сторінки можуть виглядати однаково, але мати різну HTML-структуру. На одній розробник використовує заголовки, навігаційні елементи, розділи та посилання за призначенням. На іншій майже весь контент знаходиться всередині універсальних контейнерів div, а деякі елементи імітуються стилями та JavaScript.

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

Семантична верстка HTML5 допомагає розробнику передавати призначення елементів безпосередньо в коді HTML. Такий підхід спрощує підтримку сайту, покращує доступність інтерфейсу та знижує ймовірність деяких технічних помилок, що впливають на SEO.

Розберемо основні семантичні теги HTML, правила їх використання та створення розмітки за макетом. Окремо розглянемо методологію BEM, порівняємо варіанти HTML-коду та покажемо, як перевірити готову сторінку.

Що таке семантична верстка?

Семантична верстка – спосіб створення HTML-сторінок, при якому елементи вибирають відповідно до змісту та призначення вмісту. Заголовок позначають відповідним тегом h1-h6, навігацію поміщають в nav, основний контент – в main, а самостійну публікацію можна оформити через article.

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

Що означає семантика HTML5?

Семантика HTML5 визначає змістову роль елементів документа, яку браузер та інші програми можуть враховувати під час обробки сторінки. Кожен HTML-тег має своє призначення, передбачене стандартом мови розмітки.

Наприклад, p означає абзац, ul – неупорядкований список, nav – область навігації, а button – інтерактивний елемент для виконання дії. Правильно підібрані теги передають структуру вмісту та допомагають зберігати очікувану поведінку інтерфейсу.

При розробці сторінки HTML відповідає за структуру та зміст, CSS керує оформленням, а JavaScript додає необхідну інтерактивну поведінку. Поділ цих завдань спрощує супровід проєкту та дозволяє змінювати дизайн без постійної зміни HTML-розмітки.

Семантичний HTML існує не лише завдяки новим елементам HTML5. Заголовки, абзаци, посилання, списки та таблиці з'явилися значно раніше і також мають певне смислове призначення.

Чим семантичні елементи відрізняються від звичайних HTML-контейнерів?

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

Розглянемо два варіанти позначення основного заголовка сторінки:

<div class="page-title">
  Семантична верстка HTML5
</div>

<h1 class="page-title">
  Семантична верстка HTML5
</h1>

При однакових CSS-стилях обидва елементи можуть виглядати однаково. Однак h1 має семантику заголовка першого рівня та бере участь у структурі документа, тоді як div залишається універсальним контейнером.

Використання div саме по собі не вважається помилкою семантичної верстки. Проблема виникає, коли універсальні контейнери замінюють елементи, для яких HTML уже передбачає відповідну семантику та стандартну поведінку.

Семантичні властивості та семантичні компоненти

Семантичні властивості HTML-елемента пов'язані з його призначенням та правилами використання усередині документа. Наприклад, button підтримує стандартну роботу з клавіатурою, а елемент a з атрибутом href позначає посилання на інший ресурс або фрагмент сторінки.

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

Уявімо картку публікації, яка містить зображення, заголовок, короткий опис та посилання на матеріал. Її можна реалізувати як самостійний article, а перехід на повну публікацію оформити через звичайний елемент a.

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

Основні семантичні теги HTML5

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

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

Вибір конкретного HTML-тегу визначається змістом блоку. При цьому жоден із перелічених елементів не повинен застосовуватися виключно заради передбачуваних переваг у пошуковому ранжируванні.

Структурні теги сторінки

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

Тег nav позначає область навігації та підходить для основних меню, хлібних крихт та інших значущих груп посилань. За наявності кількох навігаційних областей їх бажано розрізняти доступними назвами, наприклад, за допомогою aria-label.

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

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

Різниця між article та section

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

Елемент article підходить для вмісту, який зберігає сенс окремо від решти сторінки. Тег section використовується для тематичного розділу документа та допомагає поділити великий матеріал на логічно пов'язані частини.

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

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

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

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

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

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

Тег section використовується, коли документ містить тематично виділену частину вмісту. Наприклад, у статті про семантичну розмітку окремі розділи можуть присвячуватися HTML-тегам, доступності інтерфейсу та методології BEM.

Зазвичай такий розділ має власний заголовок, що пояснює його зміст. Якщо елемент створюється лише для розташування колонок або застосування CSS-стилів, частіше підходить універсальний контейнер div.

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

Теги для тексту та його логічної структури

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

Заголовки h1–h6 задають рівні розділів, а елемент p позначає окремий абзац. Для маркованих переліків використовують ul разом із li, а для послідовностей, де важливий порядок, застосовують ol.

Теги strong та em передають смислову важливість чи акцент, тоді як b та i використовуються для іншого виду текстового виділення. Візуальне оформлення цих елементів можна змінювати через CSS незалежно від їхньої семантики.

Цитати оформлюють за допомогою blockquote, а табличні дані розміщують в елементах table, thead, tbody, tr, th і td. Використовувати таблиці тільки для створення сітки сторінки не слід, оскільки для розміщення блоків існують CSS Grid та Flexbox.

Семантичні елементи форм та інтерактивних блоків

Посилання, кнопки та поля форм повинні зберігати своє стандартне призначення. Наприклад, елемент a з атрибутом href використовується для переходу, а button підходить для надсилання форми, відкриття меню або виконання іншої дії.

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

Поля форми слід пов'язувати з підписами через label, а тематично пов'язані елементи можна об'єднувати через fieldset і legend. Такий підхід допомагає відвідувачам розуміти призначення полів та взаємодіяти з інтерфейсом через допоміжні технології.

Для навігації кращим є наступний варіант:

<a href="/services/seo/">
  SEO-просування сайту
</a>

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

Як правильно побудувати семантичну структуру HTML-документа?

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

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

Структура HTML5 від header до footer

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

Нижче наведено приклад семантичної структури HTML-документа з основними елементами сторінки:

<!doctype html>
<html lang="uk">
<head>
  <meta charset="utf-8">
  <meta name="viewport"
        content="width=device-width, initial-scale=1">
  <title>Семантична верстка HTML5</title>
</head>
<body>
  <header>
    <nav aria-label="Основна навігація">
      <a href="/">Головна</a>
      <a href="/blog/">Блог</a>
    </nav>
  </header>

  <main>
    <article>
      <header>
        <h1>Семантична верстка HTML5</h1>
        <p>Основні принципи HTML-розмітки</p>
      </header>

      <section>
        <h2>Основні семантичні теги</h2>
        <p>Опис структури документа.</p>
      </section>

      <footer>
        <p>Автор: редакція сайту</p>
      </footer>
    </article>
  </main>

  <footer>
    <p>Інформація про сайт</p>
  </footer>
</body>
</html>

У цьому прикладі використовуються два елементи header і два footer, оскільки одні стосуються всієї сторінки, а інші – до окремої публікації. Таке застосування відповідає їхньому смисловому призначенню.

Ієрархія заголовків H1–H4

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

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

Приклад послідовної структури заголовків:

H1 Семантична верстка HTML5

  H2 Основні семантичні теги

    H3 Структурні елементи

      H4 Елемент article

      H4 Елемент section

    H3 Текстові елементи

  H2 Перевірка HTML-розмітки

    H3 HTML-валідатор

    H3 Перевірка доступності

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

Правильна вкладеність семантичних елементів

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

У разі неправильної вкладеності браузер іноді автоматично виправляє DOM-дерево, через що підсумкова структура відрізняється від вихідного коду. Такі зміни можуть впливати на роботу CSS-селекторів, JavaScript та допоміжних технологій.

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

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

Семантична верстка HTML5 на прикладі сторінки сайту

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

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

Приклад звичайної HTML-розмітки

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

<div class="card">
  <div class="card-title">
    Як працює семантичний HTML
  </div>

  <div class="card-description">
    Основні правила HTML-розмітки.
  </div>

  <div
    class="card-link"
    onclick="location.href='/blog/html/'"
  >
    Читати статтю
  </div>
</div>

Такий код може працювати при використанні миші та увімкненому JavaScript, але створює додаткові проблеми. Заголовок не позначений відповідним HTML-елементом, а перехід не представлений стандартним посиланням.

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

Приклад правильної семантичної верстки

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

<article class="card">
  <h2 class="card-title">
    Як працює семантичний HTML
  </h2>

  <p class="card-description">
    Основні правила HTML-розмітки.
  </p>

  <a
    class="card-link"
    href="/blog/html/"
  >
    Читати статтю
  </a>
</article>

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

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

Порівняння семантичної та несемантичної розмітки

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

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

При порівнянні важливо враховувати конкретний код, а не кількість використаних тегів. Сторінка з великою кількістю section та article може виявитися менш зручною, якщо елементи застосовані без розуміння їхнього призначення.

Створення семантичної розмітки за макетом

Розробка сторінки за макетом починається з аналізу вмісту та поведінки інтерфейсних блоків. У Figma дизайнер показує розташування елементів, розміри, відступи та візуальні стани, але ці властивості не визначають HTML-семантику автоматично.

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

Аналіз візуальних блоків макету

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

Один візуальний контейнер не обов'язково відповідає окремому елементу section, оскільки деякі блоки існують лише для розташування елементів. Наприклад, обгортку двох колонок часто зручно реалізувати через div із CSS Grid.

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

На цьому етапі корисно скласти схему документа та визначити ієрархію заголовків. Така підготовка зменшує кількість виправлень після підключення CSS та JavaScript.

Вибір HTML-елементів для кожного блоку

Після аналізу макета розробник вибирає HTML-теги з урахуванням призначення вмісту. Наприклад, основне меню оформляють через nav, самостійну публікацію – через article, а інтерактивну кнопку – через button.

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

Особливої уваги вимагають картки, які цілком реагують на натискання. Для таких компонентів необхідно вибрати коректну структуру посилань та уникнути неприпустимої вкладеності інтерактивних елементів.

Коли смислова структура підготовлена, розробник додає CSS-класи та необхідні атрибути. При подальшій зміні дизайну призначення більшості HTML-елементів може бути незмінним.

Адаптація розмітки під мобільні пристрої

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

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

Мобільне меню, що розкривається, повинно залишатися доступним з клавіатури, а кнопка відкриття повинна мати зрозумілу назву. У разі зміни стану меню необхідно коректно оновлювати відповідні атрибути доступності.

Правильно підготовлена HTML-структура спрощує роботу з різними екранами та зменшує потребу в дублюванні вмісту. При цьому якість мобільної версії все одно потребує окремої перевірки.

Перевірка готової сторінки після верстки

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

Для сайтів із клієнтським рендерингом потрібно окремо порівнювати вихідний HTML та DOM після виконання JavaScript. Це допомагає виявити проблеми, у яких основний текст з'являється лише після додаткових дій або залежить від помилок завантаження.

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

1. Відкрити сторінку та перевірити наявність основного вмісту в HTML або після очікуваного рендерингу.
2. Перевірити структуру H1–H4 та відповідність заголовків вмісту розділів.
3. Перевірити посилання, кнопки, форми та доступність основних елементів з клавіатури.
4. Знайти помилки вкладеності та перевірити документ через HTML-валідатор.
5. Порівняти мобільну та десктопну версії, включаючи порядок читання та навігацію.

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

Методологія BEM у HTML-верстці

При розробці великих сайтів одна проблема зустрічається особливо часто: CSS-класи починають конфліктувати між компонентами. Назви типу title, item або active можуть використовуватися в різних місцях, через що зміна одного стилю випадково зачіпає інші елементи.

Методологія BEM допомагає організувати код через незалежні блоки, їх елементи та модифікатори. Вона застосовується разом із семантичним HTML і вирішує завдання іменування класів, повторного використання компонентів та супроводу інтерфейсу.

Що таке BEM?

BEM розшифровується як Block, Element, Modifier – блок, елемент та модифікатор. Методологія описує спосіб організації інтерфейсних компонентів та правила іменування класів, завдяки яким призначення кожного CSS-селектора стає зрозумілішим.

Наприклад, клас article-card__title показує, що елемент title відноситься до блоку article-card. Розробнику простіше визначити область дії стилів, знайти компонент у проєкті та внести зміни без випадкового впливу на сусідні блоки.

BEM не вимагає використання спеціальних HTML-тегів і не визначає змісту документа. Один і той самий блок може містити article, h2, p, a та інші семантичні елементи.

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

Три основні складові BEM

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

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

Block – незалежний блок

Block позначає самостійний компонент, який можна використовувати в різних частинах сайту. Наприклад, menu, search-form та article-card можуть існувати незалежно від конкретного шаблону сторінки.

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

Приклад самостійного блоку:

<article class="article-card">
  <h2>Назва публікації</h2>
  <p>Короткий опис матеріалу.</p>
</article>

У цьому випадку article-card визначає компонент, а HTML-тег article передає смисл вмісту. При перенесенні картки в інший розділ сайту її CSS-клас може залишитися незмінним.

Element – частина блоку

Element позначає складову частину блоку, яка логічно належить йому і зазвичай не використовується самостійно. Назва формується через подвійне підкреслення після імені батьківського блоку.

Наприклад, article-card__title позначає заголовок картки, а article-card__description – її опис. Такі назви допомагають відрізняти елементи однакового призначення у різних компонентах.

Приклад:

<article class="article-card">
  <h2 class="article-card__title">
    Семантичний HTML
  </h2>

  <p class="article-card__description">
    Розбір основних HTML-елементів.
  </p>
</article>

За правилами BEM не слід створювати ланцюжки класів виду block__element__subelement. Навіть якщо HTML-елементи вкладені один в одного, їх назви можуть належати до одного вихідного блоку.

Modifier – стан або варіант блоку

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

У класичній нотації BEM модифікатор відокремлюють одинарним підкресленням. Приклад такого класу – article-card_featured, який застосовується разом із основним класом блоку.

<article
  class="article-card article-card_featured"
>
  <h2 class="article-card__title">
    Рекомендована публікація
  </h2>
</article>

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

Приклад HTML-верстки за методологією BEM

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

<article class="article-card">
  <header class="article-card__header">
    <h2 class="article-card__title">
      Семантична верстка HTML5
    </h2>
  </header>

  <p class="article-card__description">
    Основні правила HTML-розмітки
    та організації сторінки.
  </p>

  <a
    class="article-card__link"
    href="/blog/semantic-html/"
  >
    Читати публікацію
  </a>
</article>

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

.article-card {
  display: flex;
  flex-direction: column;
  gap: 1rem;
  padding: 1.5rem;
  background: var(--surface-primary);
  border: 1px solid var(--border-default);
  border-radius: var(--radius-card);
}

.article-card__title {
  margin: 0;
  color: var(--text-primary);
  font-size: 1.5rem;
}

.article-card__description {
  margin: 0;
  color: var(--text-secondary);
  line-height: 1.6;
}

.article-card__link {
  align-self: flex-start;
  color: var(--link-primary);
}

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

Переваги використання BEM

Методологія BEM особливо корисна при розробці сайтів з великою кількістю компонентів, що повторюються. Вона допомагає підтримувати порядок у CSS і полегшує внесення змін, коли над проєктом працюють кілька фахівців.

Основні переваги BEM пов'язані з організацією та передбачуваністю коду:

• Зрозумілі назви класів. За селектором можна визначити приналежність елемента до конкретного компонента і швидше знайти потрібні стилі.
• Менше конфліктів. Класи різних блоків мають власні назви, завдяки чому випадковий перетин CSS-правил стає менш ймовірним.
• Повторне використання. Один компонент можна розміщувати в декількох шаблонах без обов'язкового переписування внутрішньої структури.
• Зручний супровід. Розробник швидше розуміє зв'язки між блоками, елементами та варіантами оформлення.
• Проста зміна станів. Модифікатори допомагають описувати варіанти компонентів без створення безлічі незв'язаних класів.
• Узгоджена командна робота. Загальні правила іменування зменшують кількість неоднозначних рішень під час розробки інтерфейсу.

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

Чим BEM відрізняється від семантичної верстки?

Семантична верстка та BEM застосовуються на різних рівнях розробки інтерфейсу. HTML-елементи позначають зміст вмісту, а методологія BEM допомагає організувати класи та відносини між компонентами.

Різницю зручно розглянути через призначення кожної технології:

Обидва підходи можна використовувати в одному компоненті без конфліктів. Наприклад, самостійна публікація оформляється через article, її заголовок позначається h2, а зовнішній вигляд управляється класами article-card та article-card__title.

Як семантична верстка впливає на SEO?

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

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

Розуміння структури сторінки пошуковими системами

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

Заголовки H1–H6 допомагають описувати тематичну ієрархію матеріалу, а посилання передають інформацію про доступні переходи. При цьому алгоритми Google здатні аналізувати сторінки з різними варіантами HTML і не вимагають обов'язкового використання всіх семантичних елементів.

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

Для пошукової оптимізації важливим є результат усієї реалізації. Якщо основний контент відсутній, закритий від сканування або недоступний за URL-адресою, застосування article або section саме по собі проблему не виправить.

Сканування та індексація контенту

Під час сканування Googlebot отримує сторінку, виявляє посилання та обробляє доступний вміст. Для стандартної навігації бажано використовувати елементи a з коректним атрибутом href, оскільки такий формат підтримує звичний механізм для виявлення URL.

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

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

Однак наявність тексту в HTML ще не означає автоматичного потрапляння сторінки до індексу. Індексація залежить від доступності URL, правил robots, canonical, якості вмісту та інших факторів, які необхідно перевіряти окремо.

Семантична HTML-розмітка та SEO-розмітка

Термін «SEO-розмітка» часто використовується для різних технічних рішень, хоча вони виконують самостійні завдання. Семантичні елементи описують зміст документа, мета-теги передають окремі відомості про сторінку, а структуровані дані надають додаткову машиночитану інформацію.

Наприклад, Schema.org застосовується для опису певних сутностей, таких як статті, організації, товари та хлібні крихти. Дані можуть передаватися через JSON-LD, який зазвичай розміщують в окремому елементі script.

Наявність структурованих даних не скасовує необхідності якісного HTML. Наприклад, розмітка Article не виправить некоректні посилання, а canonical не замінить структуру заголовків та основного вмісту.

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

Зв'язок семантичної верстки з досвідом користувача

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

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

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

Семантична верстка не забезпечує автоматичного покращення Core Web Vitals. Швидкість та стабільність відображення потрібно оцінювати окремо, враховуючи завантаження ресурсів, виконання JavaScript та особливості оформлення.

Провідний SEO-спеціаліст — Геннадій

У своїй роботі я регулярно перевіряю не лише мета-теги та контент, а й те, як сторінка побудована на рівні HTML. Зовні сайт може виглядати бездоганно, проте при перегляді коду виявляються заголовки, оформлені звичайними блоками, посилання без href та нелогічна вкладеність елементів.

Я не розглядаю семантичну верстку як окремий спосіб підвищити позиції в Google. Її завдання – зробити структуру документа коректною та зрозумілою. Коли основний контент, навігація, заголовки та інтерактивні елементи реалізовані правильно, легше проводити SEO-аудит, виявляти технічні помилки та підтримувати сайт за подальшого розвитку.

Семантична розмітка та доступність сайту

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

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

Як семантичний HTML допомагає скринрідерам?

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

Коли заголовки оформлені тегами h1–h6, користувач може переміщатися між ними та отримувати уявлення про вміст сторінки. Аналогічно, nav і main допомагають розрізняти навігаційну область та основну частину документа.

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

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

HTML та ARIA-атрибути

ARIA-атрибути допомагають передавати додаткові відомості про призначення, стан та поведінку інтерфейсних елементів. Наприклад, aria-expanded може показувати стан меню, що розкривається, а aria-label – надавати доступну назву елемента.

Нативні HTML-елементи вже мають певну семантику і стандартні правила взаємодії. Тому звичайний button частіше зручніший, ніж div, якому вручну призначили роль кнопки та додаткову обробку клавіатури.

Неправильне застосування ARIA може погіршити доступність сторінки, навіть якщо розробник додав багато спеціальних атрибутів. Особливо обережно слід використовувати ролі, що змінюють вбудовану семантику елемента.

Перед додаванням ARIA бажано перевірити, чи існує відповідний HTML-тег для конкретного завдання. У багатьох випадках правильного елемента та стандартних атрибутів достатньо для створення зрозумілого інтерфейсу.

Доступні зображення, форми та навігація

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

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

Поля форм повинні мати зрозумілі підписи, пов'язані із відповідними елементами управління. Для цього використовують label, а за потреби об'єднують пов'язані поля в fieldset із загальним заголовком legend.

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

Поширені помилки семантичної верстки

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

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

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

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

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

Однак масова заміна кожного div на section також буде помилкою. Універсальні контейнери підходять для декоративних обгорток, сіток та групування елементів, коли додаткова семантика відсутня.

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

Порушення логіки заголовків

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

Інша проблема виникає, коли заголовки імітуються через div або span, а візуальне оформлення виконується виключно через CSS. За такого підходу смислова ієрархія вмісту може не відповідати структурі HTML.

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

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

Неправильне застосування section, article та nav

Тег section іноді використовують для будь-якої візуальної обгортки, навіть коли блок не утворює самостійної тематичної частини. У таких випадках універсальний контейнер div зазвичай краще відповідає призначенню елемента.

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

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

Щоб виправити таку розмітку, слід визначити зміст кожного блоку та перевірити його відповідність документації HTML. Після зміни тегів необхідно переконатися, що CSS та JavaScript продовжують працювати коректно.

Некоректна розмітка списків, посилань та кнопок

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

Помилки з посиланнями виникають, коли замість a href розробник використовує обробник JavaScript на довільному елементі. Це ускладнює стандартну взаємодію з браузером та може заважати виявленню переходів пошуковими системами.

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

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

Надмірна семантика та недоречні ARIA-атрибути

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

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

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

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

Як перевірити семантичну верстку сайту?

Перевірка семантичної верстки включає аналіз вихідного HTML, DOM-структури після рендерингу та поведінки інтерактивних елементів. Єдиного інструменту, який автоматично оцінює всі ці аспекти, немає.

Тому розробники комбінують HTML-валідатори, інструменти браузера, перевірки доступності та ручне тестування. Для SEO додатково оцінюють доступність основного вмісту та коректність посилань.

Перевірка HTML через Nu Html Checker

Nu Html Checker перевіряє HTML-документи на відповідність багатьом вимогам стандарту та допомагає знаходити помилки синтаксису. Наприклад, він може виявити неприпустиму вкладеність елементів, повторювані ідентифікатори та інші проблеми розмітки.

Для перевірки достатньо відкрити Nu Html Checker, вказати адресу сторінки або вставити код HTML. Після аналізу інструмент покаже повідомлення про помилки та попередження, які потрібно розібрати.

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

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

Перевірка структури через Chrome DevTools

Chrome DevTools допомагає досліджувати підсумкову DOM-структуру сторінки та знаходити проблеми вкладеності елементів. Для відкриття інструментів розробника зазвичай використовують клавішу F12 або пункт контекстного меню браузера.

У вкладці Elements можна перевірити теги, атрибути, CSS-класи та розташування блоків усередині документа. Особливо це корисно для сторінок, структура яких змінюється після виконання JavaScript.

При аналізі слід звернути увагу на основний елемент main, заголовки, навігаційні області та інтерактивні компоненти. Додатково можна перевірити дерево доступності та доступні назви елементів керування.

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

Перевірка доступності через Lighthouse та axe

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

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

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

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

Перевірка сторінки засобами Google Search Console

Google Search Console допомагає перевірити, як Google обробляє конкретну URL-адресу та які відомості доступні про її індексування. Інструмент перевірки URL показує дані про сканування, вибране canonical і доступні результати обробки сторінки.

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

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

Якщо сторінка не індексується, необхідно перевіряти причини комплексно: доступність URL, robots, мета-теги, canonical, внутрішні посилання та якість вмісту. Наявність семантичної розмітки саме собою не усуває проблеми індексування.

Чек-лист правильної семантичної верстки

Перед публікацією сторінки корисно провести підсумкову перевірку основних елементів HTML-документа. Такий чек-лист допомагає виявляти типові помилки та фіксувати вимоги до якості розробки.

Перевіряти бажано як вихідний HTML, так і сторінку після виконання JavaScript. Для мобільної версії додатково оцінюють послідовність елементів та доступність основних дій.

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

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

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

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

Докладніше про роботу з архітектурою та пошуковою семантикою можна дізнатися на сторінці «Семантика та структура сайту».