Вступ: чому теги мають значення

Більшість сайтів, що виглядають однаково для звичайного користувача, виглядають принципово по-різному для Google і для людей із порушеннями зору. Один із ключових чинників цієї різниці — те, якими HTML-тегами розмічений контент.

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

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

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

Частина 1: Що таке семантичний HTML і чим він відрізняється від «звичайного»

Теги, що несуть зміст

HTML у сучасному розумінні — це не просто мова розмітки для браузера. Це словник, кожне слово якого має конкретне значення. Елемент article каже: «тут — самостійний, завершений матеріал». Елемент nav каже: «тут — навігаційні посилання». Елемент h1 каже: «це головний заголовок документа».

Несемантичний підхід — коли замість цих тегів використовується універсальний div або span для всього поспіль. Div не несе жодного змісту. Він просто прямокутник. Два сайти — один зверстаний виключно через div, інший — з правильними семантичними тегами — можуть виглядати ідентично у браузері, але для решти учасників (Google, скрінридерів, парсерів) вони кардинально різні.

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

Коли семантика з'явилась у HTML

До HTML5 (2014 рік широкого поширення) більшість розробників верстали через div і span майже все: шапку, підвал, бічну колонку, блоки контенту. Були лише базові змістові елементи — заголовки h1-h6, абзаци p, списки ul та ol, посилання a, таблиці.

HTML5 ввів цілу групу нових семантичних елементів: header, footer, nav, main, article, section, aside, figure, figcaption, time, mark і ще десятки інших. Кожен із них вирішує конкретну задачу і дає конкретний сигнал усім, хто читає код.

За десять із лишком років після появи HTML5 семантичні теги стали стандартом у якісній верстці. Але реальний стан справ у вебі інший: величезна кількість сайтів — від невеликих візиток до середніх корпоративних ресурсів — досі побудована на div-soup, як розробники жартівливо називають верстку з нескінченною вкладеністю безіменних блоків.

Частина 2: Семантика і SEO — як Google читає вашу сторінку

Як пошуковий робот обходить сторінку

Коли Googlebot відвідує сторінку, він не «бачить» її так, як бачить людина. Він читає HTML-документ — послідовно, зверху вниз. І те, якими тегами позначені різні частини цього документа, напряму впливає на те, як Google розуміє важливість і контекст кожного фрагменту тексту.

Правильний тег h1 — і Google знає: ось головна тема сторінки. Цей текст описує, про що ця сторінка в цілому. Підзаголовки h2 і h3 — ієрархія тем і підтем. Навігаційні посилання в тезі nav — структурні посилання, а не контентні. Основний матеріал у тезі main або article — ось де зосереджений основний контент, якому треба надати найбільшу вагу.

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

Заголовки — найпряміший вплив на SEO

Тег h1 є найважливішим сигналом для Google щодо теми сторінки. Він має бути один на сторінку (Google читає кілька h1 як сигнал плутанини щодо теми), він має містити основний пошуковий запит і він має точно відображати, про що ця сторінка.

Ієрархія h1 → h2 → h3 — це структура документа, і Google використовує її для розуміння відносної важливості різних частин контенту. Сторінка з правильно вибудуваною ієрархією заголовків — це сторінка, де пошуковий алгоритм може без двозначностей визначити головну тему, підтеми і деталі.

Поширена помилка: використання тегів h1-h6 для стилізації тексту (наприклад, h3 для дрібного заголовку в сайдбарі просто тому, що він виглядає потрібного розміру), а не для вираження структури. Це дезорієнтує і Google, і скрінридери. Якщо вам потрібен великий або малий текст — це завдання для CSS, а не для тегу заголовку.

Тег main — де зосереджений основний контент

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

Для Google main є сигналом: ось де концентрується контент, гідний індексування з найвищим пріоритетом. Це особливо важливо для сторінок, де є багато допоміжного контенту (велика навігація, довга бічна колонка з посиланнями) — без чіткого позначення основного контенту пошуковик може неправильно оцінити вагу різних частин сторінки.

Теги article і section — структура довгого контенту

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

Тег section — для тематичних блоків усередині сторінки або article. Розділ «Про компанію», розділ «Наші послуги», розділ «Відгуки клієнтів» на лендингу — section. Відмінність від article: section є частиною цілого і без контексту втрачає змістовність.

Поширена помилка — використовувати section як заміну div «просто щоб не писати div». Section має мати сенс і, як правило, власний заголовок. Якщо блок не можна назвати — це div, а не section.

Тег nav і внутрішнє перелінкування

Елемент nav позначає навігаційні блоки. Не кожен набір посилань є nav — тільки ті, що служать навігацією по сайту або документу. Головне меню — nav. Breadcrumbs (хлібні крихти) — nav. Блок «Читайте також» із посиланнями на статті — скоріше div або aside, ніж nav.

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

Schema.org і мікророзмітка — наступний рівень семантики

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

Schema.org — це словник, розроблений спільно Google, Microsoft, Yahoo і Yandex, що описує сотні типів сутностей: організації, товари, рецепти, заходи, особи, статті, місцеві бізнеси, огляди з оцінками та багато іншого.

Коли ви додаєте на сторінку розмітку Schema.org для товару — Google знає: ось назва, ось ціна, ось наявність, ось рейтинг. І може показати ці дані прямо в результатах пошуку у вигляді так званих rich snippets — збагачених результатів зі зображенням, ціною, рейтингом зірками. Клікабельність таких результатів значно вища за стандартний синій посилання.

Для інтернет-магазину мікророзмітка Product і Offer — обов'язковий елемент SEO-оптимізації, якщо мета — бути помітним у пошуковій видачі. Для локального бізнесу — розмітка LocalBusiness. Для новинного ресурсу — Article. Для сторінки «Питання та відповіді» — FAQPage, що дозволяє розгортати відповіді прямо в результатах пошуку.

Частина 3: Семантика і доступність — коли код визначає, чи зможе людина ним скористатись

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

Коли розробники говорять про «доступність» (accessibility, або a11y у технічному жаргоні), мова не тільки про людей із повною сліпотою. Це широкий спектр:

Люди з порушеннями зору, що використовують скрінридери — програми, що зачитують вміст сторінки вголос. NVDA і JAWS на Windows, VoiceOver на macOS і iOS, TalkBack на Android — найпоширеніші.

Люди з моторними порушеннями, що не можуть використовувати мишу і навігують сайтом виключно через клавіатуру. Клавіша Tab для переходу між елементами, Enter і Space для активації.

Люди з когнітивними особливостями, що потребують чіткої і передбачуваної структури.

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

Статистика каже, що близько 15-20% людей у світі мають якийсь тип інвалідності. Це не маргінальна аудиторія — це кожен шостий або сьомий потенційний відвідувач сайту.

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

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

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

Якщо меню навігації — просто список посилань без тегу nav або атрибуту role="navigation" — скрінридер не знає, що це меню. Він не дасть можливості перестрибнути через нього одразу до основного контенту — а це критично, коли меню велике і сторінку читають вголос.

Якщо форма — набір полів без тегів label, пов'язаних із полями — користувач скрінридера чує «редагувати текст», але не знає, що саме треба вводити: ім'я, email, телефон чи щось інше.

Конкретні семантичні елементи і їх вплив на доступність

Тег button проти div. Нативний button автоматично фокусується при навігації клавіатурою, активується клавішами Enter і Space, має вбудований стан «натиснуто» і оголошується скрінридерами як «кнопка». Div без спеціальних атрибутів — нічого з цього. Щоб зробити div-«кнопку» повністю доступною, потрібно додати role="button", tabindex="0", обробники клавіатурних подій і aria-pressed. Це значно більше роботи, яка до того ж часто виконується не повністю. Простіше і правильніше — одразу використовувати button.

Тег label і форми. Кожне поле форми повинно мати пов'язаний label. Не placeholder всередині поля (він зникає при введенні і не читається скрінридерами як лейбл), а саме label. Правильний зв'язок між label і input через атрибут for або через вкладення — і скрінридер оголосить «Введіть email» перед тим, як читати поле вводу.

Теги table, thead, tbody, th і caption. Якщо таблиця використовується для табличних даних (не для верстки!), правильна семантика дозволяє скрінридерам орієнтуватися: «Стовпець Ціна, рядок 3» замість просто «50». Атрибути scope на тегах th вказують, до рядка чи стовпця відноситься заголовок.

Теги figure і figcaption. Коли зображення йде разом із підписом, обгортка figure чітко пов'язує їх між собою. Скрінридер прочитає і зображення (через alt), і його підпис — в правильному контексті.

Атрибути ARIA — коли семантичних тегів не вистачає

ARIA (Accessible Rich Internet Applications) — набір атрибутів, що додають семантику там, де стандартний HTML не має підходящого елементу або де стандартний елемент з технічних причин не використовується.

Найважливіше правило ARIA: не використовуйте ARIA там, де є нативний HTML-елемент із потрібною семантикою. Використання aria-role="button" на div, коли можна просто написати button — надлишково і часто призводить до помилок. Нативні елементи мають вбудовану підтримку у всіх браузерах і скрінридерах без додаткових зусиль.

ARIA потрібна там, де будуються складні інтерактивні компоненти: модальні вікна, вкладки, акордеони, каруселі, автодоповнення. Наприклад:

Атрибут aria-label дає текстове пояснення елементу, коли видимий текст відсутній або недостатній. Кнопка «X» для закриття модального вікна — просто символ «X», недостатньо зрозумілий поза контекстом. Додати aria-label="Закрити вікно" — і скрінридер оголосить «Закрити вікно, кнопка».

Атрибут aria-expanded для кнопок, що розкривають або згортають вміст. Без нього користувач скрінридера не знатиме, відкрите меню чи закрите.

Атрибут aria-live для областей, що оновлюються динамічно — наприклад, повідомлення про помилку при заповненні форми. Без aria-live скрінридер не помітить зміни і не прочитає повідомлення.

Атрибут aria-current для позначення активного пункту навігації: aria-current="page" повідомляє скрінридеру, що це посилання веде на поточну сторінку.

Навігація клавіатурою і фокус

Для значної частини людей із порушеннями доступності миша недоступна. Вся навігація відбувається через клавіатуру: Tab для переходу вперед між інтерактивними елементами, Shift+Tab назад, Enter і Space для активації, стрілки для переміщення у компонентах.

Щоб це працювало, потрібно: усі інтерактивні елементи (посилання, кнопки, поля форм) мають бути доступні через Tab, порядок фокуса має відповідати логічному порядку читання сторінки, фокус повинен бути видимим — той самий синій або кольоровий обвід навколо елементу, що багато дизайнерів прибирають «бо некрасиво».

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

Skip-links — ще один інструмент навігації клавіатурою. Це посилання, що зазвичай приховані, але стають видимими при фокусуванні через Tab — «Перейти до основного контенту». Вони дозволяють пропустити шапку і навігацію і одразу потрапити на основний контент. Без них користувач скрінридера або клавіатурної навігації змушений «проходити» через всі елементи шапки на кожній сторінці перед тим, як дібратись до потрібного матеріалу.

Частина 4: Конкретні елементи — що де і як використовувати

Структура сторінки: шапка, основний контент, підвал

Типова сторінка сайту має чітку структуру, яку семантичний HTML виражає конкретними елементами.

Тег header — шапка сторінки або розділу. Зазвичай містить логотип, назву сайту, головну навігацію. Якщо header стоїть на рівні body — це шапка всієї сторінки. Якщо всередині article — заголовкова частина цієї статті.

Тег nav — навігаційні блоки. На сторінці може бути кілька nav: головне меню, мобільне меню, breadcrumbs, пагінація. Кожен із них є самостійним nav. Для кращої доступності їх варто розрізняти через aria-label: aria-label="Головне меню", aria-label="Хлібні крихти".

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

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

Тег aside — бічна колонка або блок, пов'язаний із основним контентом, але не є його основною частиною. Блок «Популярні статті» поруч із текстом матеріалу, рекламний блок, додаткова інформація — aside. Скрінридери сприймають aside як допоміжний, не основний контент.

Зображення: атрибут alt і коли він потрібен

Атрибут alt для тегу img — обов'язковий у двох випадках: коли зображення несе змістове навантаження і коли воно є посиланням.

Якщо зображення є важливою частиною контенту — наприклад, фото товару, ілюстрація до статті, графік або схема — alt повинен описувати зміст зображення. Не «image1.jpg» і не «фото», а конкретний опис: «Крісло для офісу із сітчастою спинкою, колір чорний» або «Графік зростання продажів за 2023-2024 роки».

Якщо зображення є декоративним — фонова текстура, розділювач, іконка-прикраса — alt має бути порожнім (alt=""). Порожній alt — це сигнал скрінридеру: пропусти це зображення, воно не несе інформації. Без alt атрибута взагалі скрінридер прочитає ім'я файлу — що часто є марним шумом.

Якщо зображення є кнопкою або посиланням, alt описує дію або призначення: «Перейти на головну сторінку» для логотипу-посилання, «Відкрити меню» для кнопки-іконки.

Списки: ul, ol і dl

Списки — недооцінений семантичний елемент. Пункти меню навігації — семантично список посилань, правильно розміщений у ul всередині nav. Кроки інструкції — ol, бо порядок важливий. Перелік характеристик товару — ul, якщо порядок не важливий.

Тег dl (definition list) — для пар «термін — визначення» або «властивість — значення». Картка товару з характеристиками (вага: 2.5 кг, матеріал: алюміній) — семантично dl з парами dt і dd. На практиці dl використовують рідко, хоча він найточніше виражає такий тип даних.

Навіщо правильні теги для списків? По-перше, скрінридери оголошують: «Список із п'яти елементів» — і користувач розуміє масштаб перед тим, як слухати. По-друге, Google краще розуміє структуровані переліки. По-третє, CSS-стилізація списків значно зручніша через семантичні теги.

Цитати, час і технічний контент

Тег blockquote — для великих цитат з іншого джерела. Атрибут cite вказує джерело URL. Тег q — для коротких цитат усередині абзацу.

Тег time — для дат і часу. Людиночитабельний текст може бути довільним («вчора», «три дні тому», «5 червня 2025»), але атрибут datetime містить машиночитаний формат дати. Це дозволяє пошуковикам і парсерам точно інтерпретувати часові дані незалежно від формату тексту.

Тег address — для контактної інформації, пов'язаної з найближчим article або з document у цілому. Адреса офісу в footer — правильний кейс для address.

Теги code, pre і kbd — для технічного контенту. code — для фрагментів коду всередині тексту, pre+code — для блоків коду зі збереженням форматування, kbd — для клавіш клавіатури.

Частина 5: Практичні наслідки — аудит і виправлення

Як виявити проблеми з семантикою на наявному сайті

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

Lighthouse у Chrome DevTools — вбудований у браузер аудитор, що аналізує сторінку за чотирма напрямами: продуктивність, доступність, SEO і найкращі практики. У розділі Accessibility він конкретно вказує: «Зображення без alt атрибута», «Елементи форми без пов'язаних label», «Кнопки без розпізнавального тексту». Запустити його просто: відкрити DevTools (F12), вкладка Lighthouse, натиснути «Analyze page load».

WAVE (Web Accessibility Evaluation Tool) — браузерне розширення або онлайн-сервіс, що накладає поверх сторінки іконки з помилками і попередженнями доступності. Дуже наочний: бачиш одразу, де проблема і яка.

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

Перевірка скрінридером — найбільш реалістичний тест. Встановити NVDA (Windows, безкоштовно) або використати вбудований VoiceOver (macOS: Command+F5, iOS: потрійне натиснення бічної кнопки) і спробувати пройти весь сайт тільки через клавіатуру і звук. Перші хвилини будуть незвичними, але дуже швидко стає зрозумілим, де є проблеми.

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

Найпоширеніші помилки і як їх виправити

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

Помилка друга: зображення без alt або з непотрібним alt. Масовий alt="image", alt="фото" або взагалі відсутній атрибут — типова картина. Виправлення: переглянути всі зображення, написати змістовний alt для тих, що несуть інформацію, і встановити порожній alt для декоративних.

Помилка третя: прибраний outline на фокусованих елементах. Зазвичай знаходиться в глобальному CSS-стилі у вигляді «*:focus { outline: none }» або «a:focus { outline: 0 }». Виправлення: видалити це правило і замінити на красиво стилізований outline або кольоровий box-shadow.

Помилка четверта: форми без label. Поля форм із лише placeholder замість label. Виправлення: додати теги label і правильно пов'язати їх із полями через атрибут for і id.

Помилка п'ята: інтерактивні елементи на div і span. Кнопки, зроблені через div із onClick; «посилання», зроблені через span зі стилем cursor:pointer. Виправлення: замінити на нативні button і a. Це не просто виправлення доступності — це виправлення правильного підходу до верстки.

Помилка шоста: використання таблиць для верстки. Деякі старі сайти досі верстаються через таблиці — це спадщина 2000-х. Таблиці — для табличних даних, не для розмітки. Скрінридери намагаються читати таблицю як таблицю з рядками і стовпцями даних — і результат для верстки на таблицях катастрофічний.

Доступність і закон — що змінюється

У Євросоюзі з 28 червня 2025 року набрав чинності Акт про доступність (European Accessibility Act, EAA), що поширюється на широкий спектр цифрових продуктів і послуг, включаючи сайти і мобільні додатки компаній, що працюють із споживачами у ЄС.

Це означає, що для будь-якого українського бізнесу, що продає товари або послуги на ринках ЄС, питання доступності перестає бути «приємним бонусом» і стає юридичною вимогою. Базовий стандарт відповідності — WCAG 2.1 на рівні AA.

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

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

Частина 6: Семантика, продуктивність і підтримуваність коду

Чому семантичний HTML полегшує роботу розробника

Правильна семантика — це не тільки про пошуковики і скрінридери. Це ще й про якість коду і зручність його підтримки.

Код, де структура сторінки зрозуміла із самих тегів, — значно легше читати і розуміти. Прийти в новий проект, відкрити шаблон і одразу бачити: ось header, ось nav, ось main, ось article, ось footer — це зрозуміло без жодного коментаря. Прийти в проект, де все — div div div div, — і витратити першу годину тільки на те, щоб зрозуміти, де що.

CSS-селектори для семантичних елементів зрозуміліші і конкретніші. Селектор main article h2 описує саме те, що він описує — заголовок другого рівня всередині статті в основному вмісті. Це значно чіткіше, ніж .content .block .title.

JavaScript-коду теж простіше орієнтуватись у семантично розміченій сторінці. Пошук потрібного елементу через querySelector('main') чи querySelector('nav[aria-label="Головне меню"]') — конкретний і зрозумілий.

Вплив на Core Web Vitals і продуктивність

Core Web Vitals — набір метрик Google, що оцінюють якість досвіду користувача і є фактором ранжування. Один із показників — Cumulative Layout Shift (CLS), зміщення елементів при завантаженні. Правильна семантична структура допомагає уникнути непотрібних перебудов верстки.

Правильне використання тегів для зображень — атрибути width і height або CSS-контейнери з відомими пропорціями — дозволяє браузеру заздалегідь зарезервувати місце під зображення і не зміщувати сторінку при їх завантаженні. Це безпосередньо впливає на CLS.

Семантичний HTML зазвичай чистіший і менший за розміром, ніж нагромадження div з class-атрибутами. Менший HTML — швидше завантаження, швидший рендеринг першого контенту (Largest Contentful Paint — ще один ключовий показник).

Зв'язок між семантикою і CSS-архітектурою

Хороша семантична верстка природно поєднується з сучасними підходами до CSS: BEM, CSS Modules, Utility-first. Але навіть без конкретної методології семантичні теги дають природну точку прив'язки для стилів.

Основний принцип: стилі не повинні компенсувати неправильну семантику. Якщо ви пишете CSS, щоб «зробити div схожим на кнопку» або «зробити span великим, як заголовок» — це сигнал, що семантика неправильна і треба змінити тег, а не додавати стиль.

Навпаки: правильно вибраний тег часто сам по собі вже має потрібний базовий стиль у браузерному CSS (user agent stylesheet). button вже виглядає як кнопка, h1-h6 вже мають розміри і відступи, strong вже жирний. Семантика зменшує обсяг CSS, необхідний для базового відображення.

Частина 7: Семантика для різних типів сайтів

Корпоративний сайт і лендінг

Для корпоративного сайту ключові семантичні завдання: правильна ієрархія заголовків на кожній сторінці, коректна розмітка контактної інформації через address і телефонів через відповідні посилання, навігація через nav із розпізнавальними aria-label, мікророзмітка Organization або LocalBusiness для Google.

Лендінг — окремий кейс. Часто це одна довга сторінка з кількома розділами, кожен із яких — section зі своїм заголовком. Ієрархія заголовків тут особливо важлива: один h1 вгорі (основний оффер), h2 для заголовків розділів (Переваги, Як це працює, Відгуки, Ціни), h3 для підзаголовків усередині розділів. Заклики до дії мають бути нативними button, а не div.

Інтернет-магазин

E-commerce — одна з найбагатших областей для семантики і мікророзмітки. Кожна картка товару — article. Ціна з розміткою Schema.org Product і Offer — rich snippet у пошуковій видачі. Зображення товару з детальним alt — краща індексація в Google Images і контекст для покупців, що використовують скрінридери.

Форма додавання у кошик — правильні label для всіх полів (вибір розміру, кількість), button для кнопки «Додати в кошик» з чітким текстом або aria-label. Форма оплати — найвищі стандарти доступності, бо це фінансова транзакція і будь-яка незрозумілість коштує конверсії.

Breadcrumbs — обов'язкові і для SEO (Google відображає їх у результатах), і для доступності (допомагають орієнтуватись). Правильна верстка breadcrumbs: nav із aria-label="Хлібні крихти", список ol (порядок важливий) і мікророзмітка BreadcrumbList для Google.

Блог і медіа-ресурс

Стаття — article. Дата публікації — time із datetime. Автор — address або відповідна мікророзмітка. Категорії і теги — посилання, добре якщо всередині семантичного блоку з відповідними заголовками.

Для новинного ресурсу мікророзмітка Article або NewsArticle дає можливість потрапити до Google News і отримати rich snippets із датою і автором.

Блок коментарів — section із заголовком «Коментарі», кожен коментар — article з інформацією про автора і datetime.

Висновок: семантика — це інвестиція, що окупається на кількох рівнях одночасно

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

Сайт із правильно побудованою семантикою краще ранжується в пошукових системах — бо передає чіткі сигнали про структуру і важливість контенту. Він доступний для людей із порушеннями зору і моторики — бо допоміжні технології отримують необхідний контекст. Він легше підтримується командою розробників — бо структура зрозуміла з коду без додаткових коментарів. Він відповідає сучасним стандартам, включаючи вимоги European Accessibility Act.

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

Для бізнесу, що замовляє розробку сайту, семантика — один із критеріїв якості, що варто перевіряти. Запитайте підрядника: яку структуру заголовків матиме сторінка? Як розмічена навігація? Чи є мікророзмітка? Як виглядає сайт у скрінридері? Ці питання відрізняють розробника, що верстає «аби виглядало», від того, що будує якісний цифровий продукт.