Semantyczny HTML (semantic HTML) - co to jest i jak go stosować?

00 / DEFINICJA

Co to jest semantyczny HTML?

Semantyczny HTML (semantic HTML) to sposób tworzenia dokumentu, w którym element zostaje wybrany według znaczenia zawartości i oczekiwanej funkcji. Kod opisuje więc, że fragment jest nagłówkiem, główną treścią, nawigacją, artykułem, listą, tabelą, etykietą pola albo przyciskiem. Wygląd pozostaje zadaniem CSS.

Elementy div i span są semantycznie neutralne. Nadal mają prawidłowe zastosowanie jako kontenery do układu i stylowania, gdy język HTML nie oferuje trafniejszego elementu. Problem zaczyna się przy zastępowaniu nimi elementów, które niosą gotowe znaczenie lub zachowanie.

01 / MECHANIZM

Jak znaczenie elementu HTML trafia do przeglądarki?

Przeglądarka analizuje kod, buduje drzewo DOM i na jego podstawie współtworzy drzewo dostępności. Natywny element przekazuje nazwę roli, właściwości i w wielu przypadkach gotowe zachowanie do interfejsów dostępności używanych przez czytniki ekranu oraz inne technologie asystujące.

Łańcuch interpretacji

Od znacznika w kodzie do dostępnej interakcji

Semantyka działa wtedy, gdy wybrany element odpowiada realnej funkcji widocznej na stronie.

Kod źródłowyAutor wybiera element
Button oznacza działanie, nav ważną nawigację, a h2 nagłówek sekcji. Nazwa klasy CSS nie tworzy równoważnej semantyki.
PrzeglądarkaPowstaje DOM
Parser buduje drzewo elementów, a JavaScript może je później zmienić. Liczy się kod wynikowy widoczny po renderowaniu.
DostępnośćPowstaje Accessibility Tree
Przeglądarka mapuje elementy na role, nazwy, stany i relacje. Część węzłów neutralnych lub dekoracyjnych może zostać pominięta.
Technologia asystującaUżytkownik otrzymuje strukturę
Czytnik ekranu może wyświetlić listę nagłówków, przejść do main, rozpoznać nav i ogłosić button jako przycisk.
InterakcjaNatywne zachowanie obsługuje działanie
Link i button otrzymują fokus oraz oczekiwane operacje klawiatury bez odtwarzania całego kontraktu w JavaScript.

Rezultat

Znaczenie staje się częścią interfejsu dostępnego dla ludzi i maszyn, zamiast pozostawać konwencją ukrytą w nazwie klasy.

Ten mechanizm pokazuje różnicę między <button>Wyślij</button> a <div class="button">Wyślij</div>. Oba elementy mogą wyglądać identycznie po dodaniu CSS. Pierwszy ma jednak natywną rolę, fokus, obsługę Enter i Spacji oraz interfejs programistyczny przycisku. Drugi wymaga osobnego odtworzenia tych cech.

02 / ELEMENTY

Najważniejsze semantyczne znaczniki HTML5 i ich funkcje

Elementy strukturalne opisują granice i rolę większych obszarów dokumentu. Warto wybierać je przez relację między zawartością a stroną, ponieważ położenie wizualne samo nie rozstrzyga, czy blok jest headerem, sekcją, artykułem albo treścią uzupełniającą.

Znaczenie, zastosowanie i granica elementów strukturalnych
Element	Co oznacza?	Typowe użycie	Granica
`<main>`	dominująca, unikalna treść dokumentu	oferta na stronie usługi, treść artykułu, zawartość narzędzia	Widoczny dokument powinien mieć jeden aktywny element main. Nie umieszczaj go wewnątrz article, aside, footer, header ani nav.
`<article>`	samodzielna kompozycja, która zachowuje sens poza stroną	wpis, wiadomość, komentarz, karta produktu lub niezależny widget	Sam wygląd karty nie wystarcza. Zawartość powinna mieć własny temat i nadawać się do osobnego użycia lub dystrybucji.
`<section>`	tematyczna sekcja dokumentu lub aplikacji	zakres usługi, wyniki badania, etap poradnika, grupa funkcji	Sekcja zwykle potrzebuje nagłówka. Kontener używany wyłącznie do siatki albo odstępów pozostaje divem.
`<aside>`	treść pośrednio związana z otoczeniem	dygresja, definicja pomocnicza, sidebar, grupa powiązanych materiałów	Informacja konieczna do udzielenia głównej odpowiedzi nie powinna trafiać do aside.
`<nav>`	ważny blok nawigacji po serwisie albo dokumencie	menu główne, breadcrumbs, spis treści, paginacja	Nie każda grupa linków jest nawigacją. Linki w akapicie ani lista źródeł nie wymagają nav.
`<header>`	treść wprowadzająca dokument lub jego sekcję	tytuł, lead, autor, data, logo lub nawigacja wprowadzająca	Header może wystąpić wiele razy. Nie jest zamiennikiem nagłówków h1–h6.
`<footer>`	informacje końcowe o dokumencie lub najbliższej sekcji	autor, prawa, dane kontaktowe, powiązane dokumenty	Footer może należeć do całej strony albo do article. Jego znaczenie wynika z miejsca zagnieżdżenia.

Semantyka treści i interakcji

Semantic HTML obejmuje znacznie więcej niż siedem popularnych elementów układu. Akapit, lista, tabela, cytat, kod, definicja, formularz i kontrolka również opisują typ danych albo oczekiwane zachowanie.

`<h1>–<h6>`

nagłówek -> nazywa -> zakres następującej treści

Przykład: H2 otwiera sekcję, a H3 jej podproblem

`<figure> + <figcaption>`

podpis -> opisuje relację -> ilustracja, wykres lub listing kodu

Przykład: wykres z podpisem wyjaśniającym wniosek

`<time datetime>`

widoczna data -> otrzymuje -> zapis czytelny maszynowo

Przykład: <time datetime="2026-08-21">21 sierpnia 2026</time>

`<details> + <summary>`

etykieta -> steruje -> natywnym panelem rozwijanym

Przykład: dodatkowe wyjaśnienie albo sekcja pomocnicza

`<button>`

kontrolka -> uruchamia -> działanie na bieżącej stronie

Przykład: wyślij formularz, otwórz dialog, zmień filtr

`<a href>`

odnośnik -> prowadzi -> do adresu lub fragmentu dokumentu

Przykład: przejście do podstrony, pliku lub kotwicy

`<label> + kontrolka`

etykieta -> nazywa -> pole formularza

Przykład: label połączony z input przez for oraz id

Section nie ustala automatycznie poziomu nagłówka

Poziom nagłówka wynika z elementu h1–h6 i powinien odpowiadać poziomowi zagnieżdżenia treści. Samo umieszczenie h2 w kolejnej sekcji nie zamienia go w podsekcję. Komponent przeniesiony głębiej w drzewie musi więc otrzymać właściwy element nagłówka; rozmiar ustawiony w CSS nie zmienia poziomu dostępnego dla czytnika ekranu.

03 / DECYZJA

Article, section czy div - jak wybrać właściwy element?

Wybór zależy od samodzielności i roli fragmentu w konspekcie dokumentu. Article zachowuje sens po niezależnym użyciu, section grupuje część większej wypowiedzi wokół tematu, a div pozostaje neutralnym kontenerem technicznym.

Test trzech pytań

Dobór kontenera według funkcji treści

Jeśli
Czy blok może zostać opublikowany, udostępniony lub wykorzystany osobno i nadal ma sens?
WybierzUżyj article
Przykłady: wpis blogowy, wiadomość, komentarz, recenzja albo niezależna karta produktu.
Jeśli
Czy blok tworzy nazwaną, tematyczną część bieżącego dokumentu i zwykle potrzebuje własnego nagłówka?
WybierzUżyj section
Przykłady: korzyści usługi, metodologia badania, FAQ albo etap poradnika.
Jeśli
Czy kontener służy głównie siatce, stylowaniu, grupowaniu skryptu lub nie pasuje do żadnego elementu o określonym znaczeniu?
WybierzUżyj div
Neutralny element jest właściwy, gdy treść nie tworzy osobnej jednostki semantycznej.

Zagnieżdżenie działa w obie strony. Długi artykuł może zawierać kilka section, a sekcja z aktualnościami może grupować wiele article. Decyzję podejmujesz dla konkretnego poziomu drzewa, nie dla całego typu witryny.

Element aside rozstrzyga inny problem: zależność od głównej treści. Boks jest aside, gdy pozostaje powiązany z otoczeniem, ale jego usunięcie nie odbiera sensu głównej odpowiedzi. Położenie po prawej stronie ekranu nie jest warunkiem.

04 / PRZYKŁAD

Przykład semantycznej struktury strony internetowej

Dobra struktura oddziela globalną nawigację, unikalny main content, samodzielny artykuł, jego sekcje oraz treść uzupełniającą. Poniższy szkielet da się zrozumieć nawet bez klas CSS i bez znajomości tekstu w poszczególnych akapitach.

<!doctype html>
<html lang="pl">
  <head>
    <meta charset="utf-8" />
    <title>Jak wybrać pompę ciepła?</title>
  </head>
  <body>
    <header>
      <a href="/" aria-label="Strona główna firmy">Logo</a>
      <nav aria-label="Główna nawigacja">
        <ul>
          <li><a href="/uslugi">Usługi</a></li>
          <li><a href="/realizacje">Realizacje</a></li>
          <li><a href="/kontakt">Kontakt</a></li>
        </ul>
      </nav>
    </header>

    <main>
      <article>
        <header>
          <h1>Jak wybrać pompę ciepła?</h1>
          <p>Parametry potrzebne przed rozmową z instalatorem.</p>
          <time datetime="2026-08-21">21 sierpnia 2026</time>
        </header>

        <section aria-labelledby="moc">
          <h2 id="moc">Jak dobrać moc urządzenia?</h2>
          <p>Treść głównej odpowiedzi…</p>
        </section>

        <figure>
          <img src="schemat.webp" alt="Przepływ ciepła między gruntem i budynkiem" />
          <figcaption>Schemat obiegu gruntowej pompy ciepła.</figcaption>
        </figure>

        <aside aria-labelledby="slownik">
          <h2 id="slownik">Skrót COP</h2>
          <p>Definicja pomocnicza…</p>
        </aside>

        <footer>
          <p>Autor: Anna Kowalska</p>
        </footer>
      </article>
    </main>

    <footer>
      <p>© 2026 Przykładowa firma</p>
    </footer>
  </body>
</html>

Dwa elementy header i dwa footer opisują różne konteksty. Zewnętrzne należą do dokumentu, a wewnętrzne do article. Main wyznacza dominującą zawartość URL-a. Aside zawiera definicję pomocniczą, którą można pominąć bez przerwania głównego wywodu.

05 / DOSTĘPNOŚĆ

Jak semantic HTML wspiera dostępność strony?

Natywne elementy przekazują technologiom asystującym role, strukturę i zachowanie, które użytkownik może wykorzystać bez wzrokowego odczytywania layoutu. Landmarki ułatwiają przejście do main i nav, nagłówki tworzą konspekt, a formularze oraz kontrolki komunikują swoją funkcję i stan.

Landmarki skracają drogę do informacji

Czytnik ekranu może pozwolić użytkownikowi przechodzić między obszarami main, navigation, banner i contentinfo. Znaczenie header i footer zależy od kontekstu: globalne elementy mogą tworzyć landmarki, a zagnieżdżone w article opisują granice tego artykułu.

Natywny element daje więcej niż sama rola ARIA

role="button" informuje technologię asystującą o roli, lecz nie dodaje automatycznie fokusu, obsługi klawiatury ani natywnego API przycisku. WAI określa rolę jako zobowiązanie autora do zapewnienia oczekiwanego zachowania. Natywny button realizuje większość tego kontraktu w przeglądarce.

Semantyczny kod jest fundamentem, nie pełnym audytem WCAG

Poprawne elementy nie rozstrzygają kontrastu, napisów do wideo, tekstów alternatywnych, komunikatów błędów, kolejności fokusu, powiększenia, ruchu ani zrozumiałości języka. Dostępność wymaga testów automatycznych, ręcznej obsługi klawiaturą i sprawdzenia strony z technologiami asystującymi.

06 / SEO I AI

Czy semantyczny HTML wpływa na SEO i widoczność w AI?

Tak - semantyczny HTML wspiera techniczną jakość SEO przez czytelną strukturę dokumentu i treść dostępną w DOM. W przewodniku SEO dla programistów Google zaleca używanie semantic HTML, gdy jest to możliwe, i wskazuje, że tekst przeznaczony do indeksowania powinien być dostępny w DOM. Dokumentacja nie przedstawia jednak poprawnego doboru elementów jako samodzielnego sygnału rankingowego.

Dla funkcji generatywnych Google podaje ten zakres jeszcze dokładniej. W przewodniku optymalizacji dla funkcji generatywnych stwierdza, że perfekcyjnie semantyczny HTML nie jest wymagany. Priorytetem pozostają dostępność treści dla Google, czytelność dla ludzi oraz struktura możliwa do obsługi przez czytniki ekranu.

Co daje się uzasadnić?

Nagłówki nazywają zakres treści, main wskazuje dominującą zawartość, a tekst dostępny w DOM może zostać przetworzony przez Google. Czytelna struktura zmniejsza niejednoznaczność dokumentu.

Czego nie należy obiecywać?

Samo zastąpienie div przez article nie gwarantuje wzrostu pozycji, featured snippet, rich result ani cytowania w odpowiedzi generatywnej. Google potrafi interpretować wiele niedoskonałych dokumentów.

Co ma wyższy priorytet?

Indeksowalność, dostępność treści w renderowanym DOM, zgodność z intencją, jakość informacji, linki i ogólne doświadczenie strony pozostają osobnymi warunkami.

Semantic HTML a dane strukturalne

Semantyczny element opisuje rolę fragmentu dokumentu, na przykład article, time albo nav. Dane strukturalne klasyfikują encje i ich właściwości za pomocą jawnego słownika, najczęściej schema.org w JSON-LD. <article> nie zastępuje typu Article, a skrypt JSON-LD nie naprawia niesemantycznego formularza. Warstwy powinny opisywać tę samą, widoczną treść. Osobny poradnik pokazuje dobór i wdrożenie danych strukturalnych w SEO.

Semantyczny HTML to jeden z czterech poziomów, z którymi mylone bywa SEO semantyczne - obok mechanizmu wyszukiwania, doboru słownictwa i danych strukturalnych. Pełne rozgraniczenie i trzy filary tej praktyki pokazuje artykuł o tym, czym jest SEO semantyczne.

07 / WDROŻENIE

Jak zachować semantykę w React, CMS i page builderze?

Framework ani system zarządzania treścią nie określa automatycznie znaczenia końcowego dokumentu. O jakości decyduje HTML wyrenderowany w przeglądarce, dlatego komponent o nazwieArticleCard może nadal zwracać zagnieżdżone divy, a pole „nagłówek” w edytorze może być wizualnym paragrafem.

// Nazwa komponentu nie trafia do DOM
function ArticleCard({ title, href }) {
  return (
    <article>
      <h2><a href={href}>{title}</a></h2>
    </article>
  );
}

// Polimorficzny komponent wymaga kontroli kontekstu
function Box({ as: Element = "div", ...props }) {
  return <Element {...props} />;
}

01
Określ kontrakt komponentu
Karta artykułu może zwracać article, nawigacja nav, a przycisk button. Dopuszczalne warianty elementu powinny wynikać z realnych kontekstów użycia.
02
Przekazuj poziom nagłówka świadomie
Reużywalny komponent nie zna automatycznie swojego miejsca w konspekcie strony. API powinno kontrolować element nagłówka albo wymagać nagłówka od rodzica.
03
Sprawdzaj kod po renderowaniu
Inspektor DOM i Accessibility Tree ujawnią dodatkowe wrappery, brakujące landmarki, nieprawidłowe role oraz różnice między serwerowym HTML-em a stanem po hydratacji.
04
Testuj komponent przez rolę i zachowanie
Testing Library, axe i reguły jsx-a11y pomagają wychwycić regresje. Test manualny nadal sprawdza sens treści, kolejność fokusu i zachowanie z czytnikiem ekranu.

Jeśli kluczowa treść powstaje dopiero w JavaScript, poza semantyką trzeba sprawdzić jej dostępność dla crawlera i użytkownika. Ten problem rozwija poradnik o renderowaniu i indeksowaniu stron opartych na JavaScript.

08 / AUDYT

Jak sprawdzić semantyczną strukturę HTML?

Audyt łączy inspekcję renderowanego DOM, drzewa dostępności, nawigacji klawiaturą i sensu widocznej treści. Walidator albo pojedynczy wynik Lighthouse wychwyci część problemów, ale nie rozstrzygnie, czy article rzeczywiście jest samodzielny, a section ma wspólny temat.

Checklista odbioru semantycznego HTML dla programisty i osoby zlecającej stronę
Obszar	Kontrola programisty	Kontrola właściciela lub marketera	Dowód
Główna treść	Czy w renderowanym DOM jest jeden widoczny main i czy zawiera treść właściwą dla bieżącego URL-a?	Czy po pominięciu menu i stopki da się wskazać jedną główną funkcję podstrony?	DOM, Accessibility Tree i widok strony bez CSS
Struktura sekcji	Czy section ma temat i nazwę, article zachowuje samodzielność, a aside jest rzeczywiście uzupełniający?	Czy nagłówki tworzą logiczny spis treści i odpowiadają temu, co użytkownik widzi pod nimi?	lista nagłówków, landmarków i ręczna ocena treści
Nawigacja	Czy ważne bloki linków mają nav i rozróżnialne accessible names, gdy występuje ich kilka?	Czy użytkownik może odróżnić menu główne, breadcrumbs i spis treści?	nawigacja czytnikiem ekranu oraz klawiaturą
Interakcje	Czy działania używają button, przejścia używają a[href], a pola mają etykiety i stany?	Czy formularz, filtry i menu można obsłużyć bez myszy, ze stale widocznym fokusem?	test Tab, Shift+Tab, Enter, Spacja i Escape
Grafiki i dane	Czy obrazy mają właściwe alt, podpis jest powiązany przez figure, a tabela ma nagłówki i caption?	Czy sens grafiki lub tabeli pozostaje dostępny bez polegania wyłącznie na kolorze?	inspekcja HTML i odsłuch czytnikiem ekranu
Kod wynikowy	Czy komponenty React, page builder i JavaScript generują oczekiwane elementy po renderowaniu?	Czy odbiór techniczny obejmuje dostępność, a nie wyłącznie zgodność z makietą?	renderowany DOM, walidator, axe/WAVE i test manualny

PrzykładTest elementu - czy użytkownik może wykonać działanie?

Kontrola zaczyna się od działania użytkownika. Dla polecenia „wyślij formularz” sprawdzamy kolejno: czy przycisk jest widoczny i zrozumiały, czy w DOM znajduje się element button, czy drzewo dostępności przekazuje czytnikowi ekranu rolę i nazwę przycisku, czy klawiatura uruchamia działanie oraz czy strona komunikuje wysłanie formularza albo błąd. Brak jednego z tych etapów może zablokować wykonanie zadania.

Taki priorytet potwierdza WebAIM Million 2026. W automatycznym badaniu miliona stron głównych brak etykiet pól wykryto na 51% stron, puste linki na 46,3%, a puste przyciski na 30,6%. Automatyczny skan nie rozstrzyga pełnej zgodności z WCAG, ale uzasadnia, dlaczego nazwy i funkcje kontrolek sprawdzamy przed dyskusyjnym wyborem section zamiast div.

Minimalny proces testowy

01
Wyłącz CSS albo odczytaj sam konspekt
Sprawdź, czy kolejność i znaczenie treści pozostają zrozumiałe bez wizualnego layoutu.
02
Otwórz Accessibility Tree
Zweryfikuj landmarki, listę nagłówków, nazwy nawigacji, role kontrolek i relacje formularzy.
03
Przejdź stronę klawiaturą
Każde działanie powinno być osiągalne, fokus widoczny, a jego kolejność zgodna z logiką dokumentu.
04
Uruchom walidację i skan automatyczny
HTML Validator, axe, WAVE i Lighthouse pomagają znaleźć błędy składni, nazw, ról, etykiet oraz części reguł dostępności.
05
Potwierdź wynik manualnie
Automat nie oceni pełnego sensu altu, trafności nagłówka, zasadności section ani zrozumiałości komunikatu błędu.

09 / BŁĘDY

Jakie są najczęstsze błędy w semantic HTML?

Najczęstsze błędy to używanie section jako neutralnego kontenera, mylenie header z nagłówkiemh1, nadawanie article każdej karcie, budowanie przycisku z div, powtarzanie natywnych ról przez ARIA oraz traktowanie hierarchii nagłówków jako sposobu na wzrost pozycji.

Kiedy błąd semantyczny staje się poważny?

Błąd ma wysoki priorytet, gdy utrudnia rozpoznanie struktury, nawigację klawiaturą, odczytanie roli i nazwy kontrolki albo wykonanie działania. Wygląd komponentu nie potwierdza jego funkcji, dlatego ocenę trzeba oprzeć na zachowaniu w DOM i drzewie dostępności oraz na skutku dla użytkownika.

Section jako uniwersalny kontener

Objaw: Każdy pas tła, kolumna albo wrapper komponentu staje się section, choć nie ma własnego tematu ani nagłówka.

Naprawa: Zostaw div dla układu i stylowania. Section wybierz dopiero wtedy, gdy fragment tworzy nazwaną część dokumentu.

Header mylony z H1

Objaw: Element header jest traktowany jak pojedynczy tytuł albo nagłówki h1–h6 służą tylko do zmiany wielkości fontu.

Naprawa: Header grupuje wprowadzenie. H1–H6 nazywają kolejne poziomy treści, a ich wygląd kontroluje CSS.

Article dla każdego prostokąta

Objaw: Karty funkcji, ceny i przypadkowe boksy otrzymują article tylko dlatego, że wyglądają jak osobne moduły.

Naprawa: Sprawdź, czy moduł zachowuje znaczenie po przeniesieniu poza bieżącą stronę i czy ma własny temat.

Div udający przycisk

Objaw: Klikalny div dostaje onClick i role=button, ale brakuje fokusu, obsługi Enter i Spacji albo komunikowania stanu.

Naprawa: Użyj natywnego button. ARIA uzupełnia brakującą semantykę; sama rola nie dodaje zachowania kontrolki.

ARIA powtarza lub nadpisuje HTML

Objaw: Nav ma role=navigation, button role=button, a natywne znaczenie elementu zostaje zastąpione inną rolą bez testów.

Naprawa: Zacznij od natywnego elementu. Dodawaj ARIA, gdy potrzebujesz nazwy, stanu lub relacji, której HTML nie wyraża.

Idealna hierarchia jako obietnica SEO

Objaw: Zespół oczekuje wzrostu pozycji po uporządkowaniu tagów albo traktuje drugi H1 jako automatyczną karę.

Naprawa: Utrzymuj jeden opisowy H1 i logiczną hierarchię ze względu na ludzi oraz technologie asystujące. Mierz SEO osobno.

10 / FAQ

Najczęstsze pytania o semantyczny HTML

01Co to jest semantic HTML?

Semantic HTML, po polsku semantyczny HTML, to używanie elementów HTML zgodnie z ich znaczeniem i funkcją. Main oznacza główną treść dokumentu, nav ważny blok nawigacji, article samodzielną kompozycję, a button natywną kontrolkę uruchamiającą działanie.

02Kiedy użyć section, a kiedy article?

Section grupuje część dokumentu wokół jednego tematu i zwykle ma nagłówek. Article opisuje całość, która zachowuje sens po wyjęciu z obecnej strony, na przykład wpis, wiadomość, komentarz albo samodzielną kartę produktu. Article może zawierać section, a section może grupować kilka article.

03Czy div jest błędem w semantycznym HTML?

Nie. Div jest poprawnym, neutralnym kontenerem do układu, stylowania lub grupowania, gdy żaden element semantyczny nie opisuje zawartości. Problem pojawia się wtedy, gdy div zastępuje istniejący element o właściwym znaczeniu lub natywnym zachowaniu, na przykład nav albo button.

04Czy semantyczny HTML poprawia SEO?

Semantyczny HTML wspiera techniczną jakość SEO przez czytelną strukturę dokumentu i treść dostępną w DOM. Google zaleca jego używanie, gdy jest to możliwe, ale nie przedstawia poprawnego doboru elementów jako samodzielnego sygnału rankingowego. Najbardziej przewidywalne korzyści dotyczą dostępności, nawigacji i utrzymania kodu.

05Czy semantic HTML i dane strukturalne schema.org to to samo?

Nie. Elementy HTML opisują rolę fragmentów dokumentu i kontrolek. Dane strukturalne używają słownika, takiego jak schema.org, aby jawnie klasyfikować encje i ich właściwości, na przykład Article, Product, author lub price. Obie warstwy powinny być zgodne z treścią widoczną dla użytkownika.

06Czy section automatycznie ustawia poziom nagłówka?

Nie. Section wyznacza tematyczną część dokumentu, ale poziom nagłówka nadal wynika z użytego elementu h1–h6. Dobierz go jawnie do poziomu zagnieżdżenia: h2 dla głównej sekcji pod H1, h3 dla jej podsekcji i tak dalej. Klasa CSS ani samo umieszczenie nagłówka w section nie zmieniają jego poziomu.

07Czy strona musi mieć jeden H1 i jeden main?

Dla main praktyczną regułą jest jeden widoczny element reprezentujący dominującą treść dokumentu. Jeden opisowy H1 również jest najczytelniejszą konwencją dla typowej podstrony. Google nie traktuje samej liczby ani kolejności nagłówków jako magicznego sygnału rankingowego, ale logiczny konspekt pomaga użytkownikom czytników ekranu.

Autor i konsultant merytoryczny

Piotr Starzyński

Specjalista SEO i analityki działający w branży od 2006 roku. Współzałożyciel i dyrektor ds. SEO i analiz w Up&More. Zajmuje się strategiami widoczności, technicznym SEO, semantyką treści, AI Search oraz projektowaniem pomiaru.

Umów konsultację SEO z Piotrem

Co to jest semantyczny HTML?

Jak znaczenie elementu HTML trafia do przeglądarki?

Najważniejsze semantyczne znaczniki HTML5 i ich funkcje

Semantyka treści i interakcji

<h1>–<h6>

<figure> + <figcaption>

<time datetime>

<details> + <summary>

<button>

<a href>

<label> + kontrolka

Section nie ustala automatycznie poziomu nagłówka

Article, section czy div - jak wybrać właściwy element?

Przykład semantycznej struktury strony internetowej

Jak semantic HTML wspiera dostępność strony?

Landmarki skracają drogę do informacji

Natywny element daje więcej niż sama rola ARIA

Semantyczny kod jest fundamentem, nie pełnym audytem WCAG

Czy semantyczny HTML wpływa na SEO i widoczność w AI?

Co daje się uzasadnić?

Czego nie należy obiecywać?

Co ma wyższy priorytet?

Semantic HTML a dane strukturalne

Jak zachować semantykę w React, CMS i page builderze?

Określ kontrakt komponentu

Przekazuj poziom nagłówka świadomie

Sprawdzaj kod po renderowaniu

Testuj komponent przez rolę i zachowanie

Jak sprawdzić semantyczną strukturę HTML?

Minimalny proces testowy

Wyłącz CSS albo odczytaj sam konspekt

Otwórz Accessibility Tree

Przejdź stronę klawiaturą

Uruchom walidację i skan automatyczny

Potwierdź wynik manualnie

Jakie są najczęstsze błędy w semantic HTML?

Kiedy błąd semantyczny staje się poważny?

Section jako uniwersalny kontener

Header mylony z H1

Article dla każdego prostokąta

Div udający przycisk

ARIA powtarza lub nadpisuje HTML

Idealna hierarchia jako obietnica SEO

Najczęstsze pytania o semantyczny HTML

Trzy różne znaczenia słowa „semantyczny”

Piotr Starzyński

Źródła i dokumentacja

Czy kod Twojej strony opisuje to, co widzi użytkownik?

`<h1>–<h6>`

`<figure> + <figcaption>`

`<time datetime>`

`<details> + <summary>`

`<button>`

`<a href>`

`<label> + kontrolka`