Від простої супи до змістовного маркування: практичний посібник з семантичного HTML

Якщо відкрити інспектор елементів у типовому сучасному веб-додатку, ви часто побачите одну й ту саму картину: глибоку, анонімну купку елементів <div>, кожен з яких ідентифікується лише назвою класу. Сторінка може виглядати ідеально, проте для сканерів екрана, пошукових ботів та наступного розробника в команді вона майже нічого не говорить про зміст. У цьому посібнику пояснюється, у чому це полягає для вас, які семантичні елементи замінюють більшість цих div, як вирішити складні вибори ( <article> чи <section>, посилання чи кнопка), а також як крок за кроком переписати реалістичний компонент.

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

<!-- The modern web's favorite anti-pattern -->
<div class="header">
  <div class="nav-container">
    <div class="nav-item">Home</div>
    <div class="nav-item">About</div>
  </div>
</div>
<div class="main-content">
  <div class="article-title">Stop Using Divs</div>
  <div class="article-body">
    <div class="paragraph">Divs everywhere.</div>
  </div>
</div>
<div class="footer">
  <div class="copyright">© 2026</div>
</div>

Кожен елемент структури в цьому фрагменті знаходиться у назвах класів. Якщо прибрати класи, не залишиться нічого, що могло б показати комп’ютеру чи людині, де закінчується навігація та починається стаття. Такий підхід зазвичай називається „супом з div“, і він є значно поширенішим, ніж слід було б.

Чому HTML перетворився на інструмент для стилізації

У міру того, як фреймворки на кшталт React, Vue, Angular та Svelte почали домінувати у роботі з фронтендом, а CSS з орієнтацією на функціональність ускладнив стилізацію майже до нуля, маркап тихо втратив свою первісну функцію. HTML почав виконувати роль нейтральної основи для прикріплення класів та обробників подій, а не мови для опису контенту. Це є непорозумінням призначення платформи: HTML був створений для передачі значень, а не як движок для формування макетів.

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

Корені компонентів за замовчуванням — div

Архітектура компонентів ділить інтерфейс на невеликі частини, такі як <Button/>, <Card/>, <Navbar/> та <Sidebar/>. Кожному компоненту потрібен кореневий елемент для його JSX, і найзручнішим варіантом є <div>. Якщо розмістити кілька компонентів один всередину іншого, отриманий DOM складатиметься з десяти шарів анонімних обгорток, хоча кожен окремий компонент сам по собі виглядав цілком прийнятно. (Якщо ви працюєте з React, варто пам’ятати, що фрагмент повністю усуває потребу в обгортці, коли не потрібна жодна коробка.)

Класи-функції зосереджують увагу на вигляді

CSS, орієнтований на функціональність, чудово підходить для прискорення роботи, але зосереджує всю увагу на вигляді елемента. Коли маркап виглядає як <div class="flex items-center space-x-4">, постає запитання «як це впорядковано?», а запитання «що це?» ніколи не ставиться. Вибір елемента залишається другорядним.

Пікселі — це лише верхній шар

Найнебезпечнішою звичкою є оцінка вашої роботи за тим, що бачить користувач мишею на великому моніторі. <div> із синім фоном, заокругленими кутами та жирним текстом безумовно виглядає як кнопка. Але під відображеними пікселями знаходиться DOM, дерево доступності, яке браузер надає асистивним технологіям, перегляд документа пошуковими роботами та обробка введення браузером. Для кожного з цих шарів стилізований div все одно залишається просто divом.

Що насправді означає семантичний HTML

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

Універсальні контейнери

Два елементи свідомо є беззмістовними:

• <div> — це універсальний блоковий групувальник.
• <span> — це універсальний інлайн-групувальник.

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

Елементи, які несуть значення

Семантичні елементи вказують на те, що є їхнім вмістом:

• <header> містить вступний контент сторінки чи розділу, часто включаючи навігацію.
• <nav> позначає блок основних посилань для навігації.
• <main> огортає основний, унікальний контент сторінки.
• <article> представляє самодостатню статтю, таку як пост чи новина.
• <section> групує контент навколо однієї теми.
• <aside> містить матеріал, який лише опосередковано пов’язаний з основним контентом, наприклад бічну панель.
• <footer> містить інформацію про закінчення, таку як авторство, авторські права чи юридичні посилання.
• <button> — це інтерактивний елемент керування, який виконує певну дію.

Коли браузер зустрічає елемент <article>, він розуміє, що його вміст може існувати самостійно. Коли він зустрічає елемент <nav>, він розуміє, що ці посилання дозволяють користувачам пересуватися по сайту. Саме на цих знаннях ґрунтується решта цього посібника.

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

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

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

Багато людей використовують Інтернет із скринь-читачами, такими як NVDA, JAWS чи VoiceOver, або навігують виключно за допомогою клавіатури. Скринь-читачі ігнорують ваш CSS. Вони працюють на основі дерева доступності, яке браузер формує з вашого HTML.

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

Landmark Navigation Map:
- Header
- Navigation (3 links)
- Main Content
  - Heading 1: Stop Using Divs
  - Article
- Sidebar (Aside)
- Footer

Користувач може натиснути одну клавішу-скорочення, щоб пропустити десятки посилань на навігацію та потрапити безпосередньо в <main> або перейти прямо до статті. Тепер порівняйте ту саму сторінку, побудовану лише з елементів div:

Landmark Navigation Map:
- Division
  - Division
  - Division
- Division

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

Кнопки також демонструють ту саму проблему, але у меншому масштабі. Ось фальшива кнопка поруч із справжньою:

<!-- BAD: Fake Button -->
<div class="my-button" onclick="submitForm()">Submit</div>

<!-- GOOD: Native Button -->
<button type="submit">Submit</button>

Вбудована кнопка <button> безкоштовно включає:

• Можливість отримання фокусу, тому вона з’являється у порядку Tab.

Активація за допомогою клавіш Enter та Space.

Правильна роль елемента, щоб скринь-читач оголошував щось на кшталт „Submit, button“, і користувач розумів, що це виконує певну дію.

Версія елемента div не може отримати фокус, не реагує на клавіатуру та читається як звичайний текст без жодних підказок про його інтерактивність. Щоб він працював належним чином, знадобляться tabindex="0", role="button", обробники натискань клавіш Enter та Space, стилізація для фокусу та обробка стану вимкнення. Це багато коду для відтворення того, що платформа вже надає бездоганно.

Пошукові системи: чіткіше уявлення про сторінку

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

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

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

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

Код — це спосіб комунікації з іншими розробниками та з самим собою через кілька місяців. Уявіть два варіанти однакового макету. Перший повністю ґрунтується на назвах класів:

<div class="top-bar">
  <div class="logo-box">...</div>
  <div class="menu-list">
    <div class="menu-item"><a href="#">Home</a></div>
    <div class="menu-item"><a href="#">Blog</a></div>
  </div>
</div>
<div class="wrapper">
  <div class="content-box">
    <div class="title-text">My Post</div>
    <div class="body-text">Hello world...</div>
  </div>
  <div class="right-bar">
    <div class="widget">...</div>
  </div>
</div>
<div class="bottom-bar">
  <div class="legal">© 2026</div>
</div>

Другий варіант передає ту саму структуру за допомогою семантичних елементів:

<header>
  <div class="logo">...</div>
  <nav>
    <ul>
      <li><a href="#">Home</a></li>
      <li><a href="#">Blog</a></li>
    </ul>
  </nav>
</header>
<main>
  <article>
    <h1>My Post</h1>
    <p>Hello world...</p>
  </article>
  <aside>
    <div class="widget">...</div>
  </aside>
</main>
<footer>
  <small>© 2026</small>
</footer>

У першій версії потрібно читати кожну назву класу та відновлювати її призначення. Якщо хтось пропустить або неправильно назве клас, структура перетворюється на сукупність ідентичних елементів. У другому варіанті форма сторінки видна з першого погляду: де вона починається (<header>), де знаходиться основний контент (<main>), що є додатковим (<aside>) та де вона закінчується (<footer>). Зауважте, що навігація також стала справжнім списком, що дозволяє програмам для читання екрана повідомляти про кількість елементів у ньому.

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

Продуктивність та вбудована поведінка браузера

Браузерні двигуни, такі як Chromium, Gecko та WebKit, налаштовані під стандартні елементи, які вже мають вбудовані стилі, обробку подій та механізми керування станом. Найяскравішим прикладом є елементи форми – <input type="email"> та <input type="date"> забезпечують користувачам мобільних пристроїв відповідну клавіатуру на екрані чи вбудований вибірник дат, а <details> надає функціональний елемент для розкриття інформації, причому все це без використання стороннього JavaScript.

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

Вирішення складних семантичних виборів

Знати список елементів — це проста частина. Справжня плутанина виникає через кілька пар елементів, які здаються взаємозамінними.

article чи section

Це питання, про яке найбільше сперечаються розробники. Корисний тест: чи можна взяти цей контент зі сторінки, розмістити його на іншому сайті, і він все одно буде цілком зрозумілим? Якщо так, використовуйте <article>. Якщо він зрозумілий лише у своєму поточному контексті, використовуйте <section>.

Хороші кандидати на використання <article>:

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

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

Хороші кандидати на використання <section>:

• Розділ „Про нас“ на головній сторінці.
• Розділ у цифровій книзі.
• Розділ з характеристиками на сторінці призначення.
• Група відгуків клієнтів.

<section> об’єднує контент під одну тему, тому майже завжди він повинен починатися з заголовка від <h2> до <h6>. Якщо ви не можете придумати доцільний заголовок, це, ймовірно, не є розділом, і в такому разі <div> може бути правильним вибором.

Ці два елементи природно взаємопов’язані. Статтю можна розділити на розділи, кожен з яких має власний заголовок:

<!-- Proper Nesting Example -->
<main>
  <!-- Main article describing a topic -->
  <article>
    <h1>Understanding Semantic HTML</h1>
    <p>Introductory paragraph...</p>

    <!-- Sections dividing the article into sub-topics -->
    <section>
      <h2>Why Accessibility Matters</h2>
      <p>Content about accessibility...</p>
    </section>

    <section>
      <h2>SEO Benefits</h2>
      <p>Content about SEO...</p>
    </section>
  </article>
</main>

Посилання чи кнопка

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

• Використовуйте <a> з справжнім значенням href, коли його активація змінює URL або переносить користувача на іншу сторінку чи місце.
• Використовуйте <button>, коли його активація виконує якусь дію на поточній сторінці: надсилає дані, відкриває модальне вікно, перемикає меню чи іншим чином змінює стан.

Обидві види помилок є поширеними, як і способи їх виправлення:

<!-- WRONG: A link styled like a button that triggers JavaScript -->
<a href="#" onclick="openModal()">Open Modal</a>

<!-- WRONG: A button that navigates to a new webpage -->
<button onclick="window.location.href='/about'">About Us</button>

<!-- RIGHT -->
<button type="button" onclick="openModal()">Open Modal</button>
<a href="/about">About Us</a>

Це розрізнення має значення, оскільки програми для читання екрана повідомляють про роль елемента. „Посилання“ створює очікування, що місце буде змінено; „кнопка“ свідчить про те, що тут щось відбудеться. Якщо це зробити неправильно, ці очікування порушуються. Існують також практичні наслідки: посилання з href="#" може перемістити сторінку на початок та не може бути активоване клавішею пробіл, а кнопка для навігації не може відкриватися у новій вкладці чи мати свою адресу скопійованою.

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

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

• Використовуйте один тег <h1> для основної теми сторінки, наприклад назви статті чи назви панелі керування. Специфікація HTML не суворо забороняє використання кількох таких тегів, але один заголовок найвищого рівня є загальноприйнятою практикою та забезпечує найбільш чітку структуру.
• Не пропускайте рівні заголовків. Перехід від <h2> безпосередньо до <h4> через бажання зменшити розмір тексту є рішенням щодо стилю, прикиданим під структуру; замість цього змінюйте розмір шрифту за допомогою CSS.
• Структуруйте матеріал логічно: під заголовком <h1> розміщуються основні розділи з тегами <h2>, кожен з яких має власні підрозділи з тегами <h3>, після чого йде наступний розділ з тегом <h2>.

Також зверніть увагу, що елемент <header> та елементи заголовків — це різні речі. <header> — це частина сторінки; <h1> до <h6> — це заголовки, які формують структуру.

Коли div є правильним інструментом

Усе це не означає, що використання <div> заборонене. У нього є чітке призначення: обгортати контент виключно для формування макету чи стилізації, коли немає семантичного значення. Центрування чогось за допомогою flexbox, створення проміжків у сітці, нанесення градієнтного фону чи використання CSS-анімацій — усе це є вагомими причинами для використання <div> (або <span> для внутрішнього контенту).

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

<!-- PERFECTLY VALID USE OF A DIV -->
<article>
  <h1>Card Title</h1>
  <p>Card description goes here...</p>

  <!-- This div exists purely to align two buttons side-by-side with Flexbox -->
  <div class="button-group flex gap-4 mt-4">
    <button type="button">Save</button>
    <button type="button">Cancel</button>
  </div>
</article>

Елементи <article>, <h1>, <p> та <button> описують зміст; елемент <div> є суто шаром макетування. Ось вся суть у одному реченні: використовуйте семантичні елементи для передачі значення та div-и для макетування. (У реальній сторінці, де ця картка знаходиться всередині більшого документа, її заголовок зазвичай буде <h2> або <h3>, щоб він відповідав структурі сторінки.)

Рефакторинг картки посту блогу, крок за кроком

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

<div class="card">
  <div class="card-image">
    <img src="tech.jpg" alt="Technology background" />
    <div class="badge">Article</div>
  </div>
  <div class="card-content">
    <div class="post-title" onclick="goToPost()">10 Tips for Better Code</div>
    <div class="post-author">By Jane Doe</div>
    <div class="post-date">August 12, 2026</div>
    <div class="post-excerpt">
      Learn how to write cleaner, more maintainable frontend code today...
    </div>
    <div class="card-footer">
      <div class="share-btn" onclick="sharePost()">Share</div>
      <div class="read-more" onclick="goToPost()">Read More</div>
    </div>
  </div>
</div>

Проблеми легко перелічити, як тільки ви почнете їх шукати:

• Зовнішній обгорток — це <div>, хоча картка є самодостатнім елементом контенту, саме для чого і призначений <article>.
• Заголовок є клікабельним div, тому користувачі за допомогою клавіатури не можуть до нього дістатися, а програми для читання екрана не розпізнають, що це заголовок чи посилання.
• Ім’я автора та дата розташовані у загальних контейнерах, які не мають значення, зрозумілого для обробки комп’ютером.
• "Поділитися" та "Прочитати більше" — це фальшиві кнопки, які створюють проблеми з використанням клавіатури та при оголошенні інформації, про які йшлося раніше.

Ось перероблена версія:

<article class="card">
  <figure class="card-image">
    <img src="tech.jpg" alt="Abstract technology grid pattern" />
    <span class="badge">Article</span>
  </figure>

  <div class="card-content">
    <h2>
      <a href="/posts/10-tips-for-better-code">10 Tips for Better Code</a>
    </h2>

    <p class="meta-info">
      Written by <span class="author">Jane Doe</span> on
      <time datetime="2026-08-12">August 12, 2026</time>
    </p>

    <p class="post-excerpt">
      Learn how to write cleaner, more maintainable frontend code today...
    </p>

    <footer class="card-footer">
      <button type="button" onclick="sharePost()" aria-label="Share this article">
        Share
      </button>
      <a href="/posts/10-tips-for-better-code" class="btn-primary">
        Read More
      </a>
    </footer>
  </div>
</article>

Що змінилося та чому це допомагає:

• Обгорток <article> повідомляє технології допомоги та пошукові роботи, що картка є окремим елементом.

Зображення та його позначка групуються в <figure>, а текст альт-тегу тепер описує зображення замість того, щоб надавати загальну позначку.

Заголовок є справжнім <h2>, який містить справжню посилання, тому він з’являється у схемі заголовків, може бути доступний за допомогою клавіші Tab та розкриває свою мету для пошукових ботів.

Дата вказується за допомогою <time datetime="2026-08-12">, що забезпечує скраперам, інструментам перекладу та інтеграціям з календарями однозначне машинно-читабельне значення, незалежно від форматування видимого тексту.

"Поділитися" — це <button>, оскільки воно діє на поточну сторінку, тоді як "Прочитати більше" — це <a>, оскільки воно здійснює переход.

aria-label на кнопці обміну надає користувачам екранних читачів більше інформації про те, що буде поділено. Залишайте видимий текст всередині мітки, як тут („Share“ є частиною „Share this article“), щоб користувачі, які керують за допомогою голосу, все одно могли її активувати, сказавши те, що бачать.

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

Звички, які зберігають семантичність вашого маркування

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

Проведіть автоматизовану перевірку

Розширення браузера, такі як axe DevTools чи WAVE, доступні для Chrome та Firefox, сканують сторінку за кілька секунд та виявляють проблеми, такі як недійсні атрибути ARIA, відсутні типи кнопок, порушений порядок заголовків та інтерактивні елементи без належної семантики. Автоматизовані інструменти виявляють лише частину важливих аспектів, тому сприймайте чистий звіт як вихідну точку, а не доказ доступності.

Спробуйте сторінку без CSS

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

Відкладіть мишу

Спробуйте керувати своїм додатком, використовуючи лише клавіші Tab, Shift + Tab, Enter, Space та стрілки, і перевірте:

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

Якщо ви стикаєтесь із елементом div, який ігнорує клавіші Enter чи Space, замініть його на <button>. Це часто один із найшвидших способів виправлення проблем з доступністю.

Запитайте, що означає вміст, перш ніж писати div

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

• Для навігації використовується <nav>.
• Для бічної панелі — <aside>.
• Для клікабельної дії — <button>.
• Для окремої картки чи запису — <article>.

Основний контент сторінки вимагає використання <main>.

Лише обгортка для макету, яка не має власного значення, вимагає використання <div>.

Те саме стосується й елементів всередині компонентів: кореневий елемент React-компонента є частиною кінцевого документа, тому його також потрібно обирати з усією увагою. Щоб дізнатися більше про відмінності між JSX та справжнім HTML, перегляньте JSX — це не HTML: справжні компроміси застосування маркування компонентів.

Ключові висновки

• Відображені пікселі — це лише один рівень; дерево доступності, пошукові боти та механізми обробки введення в браузері читають ваші елементи, а не стилі.
• Вбудовані елементи, такі як <button>, <a>, <input> та <details>, забезпечують фокус, підтримку клавіатури, ролі та поведінку в мобільних пристроях, що є дуже складним для відтворення вручну.
• Використовуйте <article> для контенту, який існує сам по собі, та <section> для тематичної частини більшого цілого, присвоюючи кожному розділу заголовок.
• Посилання використовуються для навігації, кнопки — для виконання дій; їхнє змішування заплутує користувачів та порушує очікувану поведінку браузера.
• Зберігайте чітку структуру заголовків без пропущених рівнів та використовуйте CSS замість рівнів заголовків для контролю розміру.
• Div залишається правильним вибором для чистого форматування. Фреймворки змінюються кожні кілька років, але ця основа існує вже десятиліттями, і маркап, який чітко визначає значення елементів, приносить користь як користувачам, так і пошуковим системам та вашій команді.