Semantic HTML dla SEO

TL;DR — Semantic HTML oznacza używanie tagów, które opisują, czym jest treść — <article>, <nav>, <main>, <header> — zamiast owijania wszystkiego w zwykłe <div>. Pomaga wyszukiwarkom i czytnikom ekranu zrozumieć stronę, ale nie jest czynnikiem rankingowym. Użycie <article> nie sprawi, że strona zajmie wyższą pozycję. Ta sama zasada dotyczy elementów poza landmarkami: <a href> do linków, <button> do działań, <table> do danych tabelarycznych i prawdziwego tekstu alternatywnego obrazów. Użyj właściwego tagu do właściwego zadania, a będziesz mieć za sobą większość pracy.

Czym jest semantic HTML

Każda część strony internetowej jest zbudowana z elementów HTML. Semantic HTML oznacza po prostu wybór elementu pasującego do tego, czym treść rzeczywiście jest, zamiast używania do wszystkiego ogólnego wrappera.

Porównaj te dwie wersje tej samej struktury strony:

<!-- Non-semantic: "div soup" -->
<div class="top"> ... </div>
<div class="menu"> ... </div>
<div class="content"> ... </div>
<div class="sidebar"> ... </div>
<div class="bottom"> ... </div>

<!-- Semantic: the tags describe the roles -->
<header> ... </header>
<nav> ... </nav>
<main> ... </main>
<aside> ... </aside>
<footer> ... </footer>

Obie mogą wyglądać identycznie na ekranie — za stylowanie odpowiada CSS. Różnica polega na tym, że druga wersja mówi maszynie (wyszukiwarce, czytnikowi ekranu, crawlerowi AI), która część jest nawigacją, główną treścią i paskiem bocznym. Pierwsza wersja każe wszystkim zgadywać.

Elementy, których rzeczywiście będziesz używać

• <header> — treść wprowadzająca u góry strony (albo u góry sekcji).
• <nav> — blok linków nawigacyjnych.
• <main> — główna, unikalna treść strony. Jeden na stronę.
• <article> — samodzielny fragment, który mógłby istnieć niezależnie (wpis na blogu, karta produktu, komentarz).
• <section> — tematyczna grupa treści z własnym nagłówkiem.
• <aside> — treść poboczna względem głównej (pasek boczny, wyróżniona informacja).
• <footer> — treść zamykająca (prawa autorskie, dodatkowe linki).

Ta sama zasada „używaj właściwego tagu” działa także poniżej poziomu układu strony: <a href> służy do linków, <button> do działań na stronie, <table> do prawdziwych danych tabelarycznych, a obrazom należy nadawać celowy tekst alt. Fałszywe linki zbudowane ze stylizowanych <div> to najczęstszy błąd dostępności — pełną listę znajdziesz na karcie Advanced.

Co większość osób robi źle

Owijanie treści w <article> nie poprawia pozycji w wynikach. John Mueller z Google powiedział, że element <article> ma “no particular effect” (tłumaczenie) „nie ma szczególnego wpływu” na wyszukiwarkę Google, a semantic HTML to “not a magical multiplier.” (tłumaczenie) „nie jest magicznym mnożnikiem.” Semantic HTML pomaga wyszukiwarkom zrozumieć stronę — po prostu nie jest dźwignią podnoszącą ranking.

Wartość jest realna, ale nie ma postaci „punktów rankingowych”. Czysty markup semantyczny ułatwia wyszukiwarkom odróżnienie głównej treści od boilerplate’u (menu, stopek, reklam), sprawia, że strona działa poprawnie dla osób używających czytników ekranu, i ułatwia jej odczyt narzędziom AI. To dobre powody, by go stosować — żaden z nich nie brzmi jednak „to czynnik rankingowy”.

Jeszcze jedna pułapka: Semantic HTML to nie to samo co „Semantic SEO”. Semantic HTML dotyczy struktury markupu. Semantic SEO dotyczy tematów i encji w treści. To to samo słowo, ale dwie zupełnie różne rzeczy.

Chcesz poznać pełny obraz — co sygnalizuje każdy element, co naprawdę mówią Google i Bing, jak to pasuje do ekstrakcji głównej treści oraz jak wygląda lista kontrolna modernizacji? Przejdź na kartę Advanced.

TL;DR — Semantic HTML używa elementów zgodnie z ich zamierzonym znaczeniem strukturalnym (<main>, <article>, <section>, <nav>, <header>, <aside>), aby markup komunikował, czym jest treść, a nie jak wygląda. Nie jest czynnikiem rankingowym — Mueller mówi: “not a magical multiplier,” (tłumaczenie) „nie jest magicznym mnożnikiem”, a <article> ma “no particular effect.” (tłumaczenie) „nie ma szczególnego wpływu.” Jego rolą jest ograniczanie niejednoznaczności: adnotacja centerpiece Google oddziela główną treść od boilerplate’u za pomocą NLP niezależnie od tego, czy markup jest semantyczny, ale czysta semantyka czyni to zadanie bardziej niezawodnym. Fabrice Canel z Binga ujmuje sprawę mocniej — “an advantage in SEO” (tłumaczenie) „przewaga w SEO” — a tę różnicę warto zachować. Przewodnik Google mówi, że większość internetu nie jest poprawnym HTML-em, więc Google rzadko opiera się na semantyce specyfikacji. Właściwe użycie jest ważniejsze od samej obecności: jeden <main>, <article> dla samodzielnej treści, <section> dla tematycznej grupy z nagłówkiem — nie jako zamiennik <div>. Ta sama zasada obejmuje <a href> kontra <button> (nawigacja kontra działanie), prawdziwe <table> dla danych tabelarycznych, celowy tekst alternatywny obrazów oraz <details>/<summary> dla elementów rozwijanych. Nie polegaj na zagnieżdżaniu <section>, by sugerować poziom nagłówka; stary algorytm konspektu dokumentu nigdy nie został zaimplementowany, a specyfikacja nie definiuje już zarysów w ten sposób. Nie myl semantic HTML z Semantic SEO.

Czym semantic HTML rzeczywiście jest

Semantic HTML polega na wybieraniu elementów HTML zgodnie ze znaczeniem strukturalnym, które mają przekazywać, zamiast używania do wszystkiego <div> i <span>. Elementy <article>, <section>, <nav>, <header>, <main>, <aside> i <footer> deklarują określoną rolę. Markup opisuje, czym jest fragment strony, a CSS decyduje o jego wyglądzie. Przewodnik stylistyczny Google ujmuje tę zasadę najprościej: “Use HTML elements for the purposes that they were designed for.” (tłumaczenie) „Używaj elementów HTML zgodnie z ich przeznaczeniem.” Przeczytaj źródło.

Jedna rzecz często wprawia ludzi w zakłopotanie: nazwa klasy nie tworzy semantyki. Nazwanie <div> class="article" lub class="main-nav" nie nadaje mu modelu treści elementu <article> ani niejawnej roli nawigacyjnej elementu <nav> — dla przeglądarki, czytnika ekranu i crawlera nadal jest to ogólny <div>. Semantyka tkwi w wybranym elemencie, a nie w sposobie jego stylowania lub etykietowania.

Ten artykuł dotyczy konkretnie semantycznych elementów. Szerszy obraz — „jak Google parsuje HTML, hierarchię nagłówków i poprawność kodu” — należy do centrum HTML SEO, pod którym znajduje się ta strona. Zamiast omawiać te kwestie ponownie, odsyłam do centrum.

Czy semantic HTML rzeczywiście pomaga w SEO?

Krótka odpowiedź: pomaga w zrozumieniu, nie jest czynnikiem rankingowym, a obie wyszukiwarki ujmują to trochę inaczej. Oto uczciwa wersja.

Co mówi Google

Stanowisko Google, powtarzane przez Johna Muellera, jest jasne: semantic HTML warto stosować, ale nie jest ono dźwignią rankingową. Jak podał Search Engine Journal, Mueller powiedział “Semantic HTML does help to understand a page. However, it’s not a magical multiplier for making a website rank higher,” (tłumaczenie) „Semantic HTML pomaga zrozumieć stronę, ale nie jest magicznym mnożnikiem podnoszącym pozycję witryny” — przeczytaj omówienie. Osobno powiedział: “Please use semantic HTML. It’s not a ranking factor, but it can help our systems to understand your content better.” (tłumaczenie) „Proszę, używaj semantic HTML. Nie wpływa ono na ranking, ale może ułatwić naszym systemom zrozumienie treści.” To samo źródło.

W odniesieniu do elementu <article> — tego, o który pyta się najczęściej — Mueller odpowiedział w sesji Office Hours wprost: element <article> “does not have any particular effect in Google Search,” (tłumaczenie) „nie ma żadnego szczególnego wpływu na wyszukiwarkę Google” — przeczytaj omówienie. Dodał też właściwy powód jego stosowania: “Sometimes there are accessibility or semantic reasons to use a specific kind of markup, so don’t only focus on SEO.” (tłumaczenie) „Czasem określony rodzaj markupu warto zastosować ze względów dostępności lub semantyki, więc nie skupiaj się wyłącznie na SEO.” To samo źródło.

Google wyraźnie mówi również, że nie zależy od idealnej semantyki. SEO Starter Guide zauważa: “Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn’t matter if you’re using them out of order. The web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.” (tłumaczenie) „Uporządkowanie nagłówków semantycznie jest znakomite dla czytników ekranu, lecz ich kolejność nie ma znaczenia dla wyszukiwarki Google. Internet zwykle nie jest poprawnym HTML-em, więc Google Search rzadko może opierać się na znaczeniach semantycznych ukrytych w specyfikacji HTML.” Przejdź do cytatu. To ważne doprecyzowanie, nie sprzeczność: semantic HTML pomaga, lecz nie wymaga perfekcji i nie jest punktowanym sygnałem.

Jak pomaga Google znaleźć główną treść

Oto mechanizm, dzięki któremu semantic HTML jest użyteczne mimo że nie stanowi czynnika rankingowego. Zanim Google określi temat strony, musi oddzielić jej główną treść od boilerplate’u — nawigacji, nagłówka, stopki, pasków bocznych i reklam. Martin Splitt opisał ten mechanizm: “We have a thing called the Centerpiece Annotation, for instance, and there’s a few other annotations that we have where we look at the semantic content.” (tłumaczenie) „Mamy na przykład adnotację Centerpiece oraz kilka innych adnotacji, w których analizujemy treść semantyczną.”. Google rozpoznaje temat przez przetwarzanie języka naturalnego, a nie nazwy tagów: “This looks like from all the natural language processing that we did on this entire text content here that we got, it looks like this is primarily about topic A, dog food.” (tłumaczenie) „Z całego przetwarzania języka naturalnego wykonanego na tej treści wynika, że dotyczy ona przede wszystkim tematu A — karmy dla psów.”. Pozostałe fragmenty otrzymują inną wagę: “We figure out what looks like boilerplate and then, that gets weighted differently as well.” (tłumaczenie) „Ustalamy, co wygląda na boilerplate, a następnie nadajemy temu inną wagę.”.

Najważniejsze: ta ekstrakcja działa niezależnie od tego, czy markup jest semantyczny. Google potrafi rozplątać stronę zbudowaną wyłącznie z <div>. Zapytany wprost, czy semantic HTML5 pomaga, Splitt odpowiedział “It does help us, but it’s not the only thing that we look for. Yes.” (tłumaczenie) „Tak, pomaga nam, ale nie jest jedyną rzeczą, którą bierzemy pod uwagę.”. Semantic HTML nie podnosi więc wyniku; ogranicza zgadywanie na etapie, który Google i tak wykonuje. Jest sygnałem pewności i efektywności, a nie sygnałem rankingowym. Poprawny markup semantyczny nie gwarantuje też określonej prezentacji w wyszukiwarce — reguły kwalifikacji do wyników rozszerzonych stanowią osobną warstwę.

Co mówi Bing (i dlaczego się różni)

Bing ujmuje tę kwestię mocniej niż Google i warto zachować tę różnicę zamiast ją zacierać. Fabrice Canel z Microsoftu powiedział, że strony z poprawnie wdrożonym semantic HTML5 mają “an advantage in SEO” (tłumaczenie) „przewagę w SEO” w porównaniu z tymi, które go nie mają. To mocniejsze stwierdzenie niż sformułowanie Google o pomocy w zrozumieniu strony. Obie wyszukiwarki zgadzają się, że semantyka pomaga mechanicznie, lecz używają innych słów. Żadna nie opisuje jej jednak jako punktowanego czynnika rankingowego na wzór linków lub trafności.

Najważniejsze elementy semantyczne i ich poprawne użycie

Sama obecność nie jest celem — liczy się poprawne użycie. Najczęstszy błąd polega na rozrzucaniu tagów semantycznych jak ozdób albo zamianie <div> na <section> bez refleksji nad znaczeniem każdego elementu.

<header> i <footer>

<header> zawiera treść wprowadzającą, a <footer> treść zamykającą — i oba elementy są kontekstowe. Na poziomie dokumentu <header> jest banerem witryny, a <footer> jej stopką. Mogą jednak również zagnieżdżać się wewnątrz <article> lub <section>, aby oznaczyć własny wstęp i zakończenie tego bloku (tytuł i autora artykułu w <header>, jego tagi w <footer>). Możesz mieć ich wiele; upewnij się tylko, że każdy obejmuje treść wprowadzającą lub zamykającą swojego kontekstu, a nie przypadkowe pudełka.

<nav>

<nav> służy głównym blokom linków nawigacyjnych — głównemu menu, ścieżce okruszków lub spisowi treści na stronie. Nie jest przeznaczony dla każdej grupy linków (lista powiązanych wpisów w treści nie musi być <nav>). Owijanie każdego skupiska linków w <nav> rozmywa sygnał; zachowaj ten element dla prawdziwej nawigacji.

<main>

<main> obejmuje główną, unikalną treść strony — tę część, która nie powtarza się w całej witrynie. Zasada, na której wiele osób się potyka: na stronie powinien być dokładnie jeden <main>, a nie może on znajdować się wewnątrz <article>, <aside>, <header>, <footer> ani <nav>. To najwyraźniejszy sygnał, jaki możesz przekazać: „to jest treść, która ma tutaj znaczenie”.

<article> a <section> (różnica, którą prawie wszyscy mylą)

Oto rozróżnienie, które trzeba uchwycić:

• <article> służy samodzielnej, niezależnie dystrybuowalnej treści — takiej, która nadal miałaby sens po wyjęciu ze strony i umieszczeniu w kanale. Wpis na blogu, wiadomość, karta produktu, wpis na forum, pojedynczy komentarz użytkownika. Jeśli może być syndykowany samodzielnie, jest <article>.
• <section> to tematyczna grupa treści, która powinna mieć własny nagłówek. Blok „Recenzje”, blok „Specyfikacje”, rozdział. Test jest prosty: jeśli treść nie ma sensu z nagłówkiem, prawdopodobnie nie jest <section> — a jeśli używasz go tylko po to, by podpiąć CSS, powinien to być <div>.

<section> nie jest ogólnym wrapperem. Gdy potrzebujesz zaczepu do stylowania bez znaczenia semantycznego, użyj <div> — dokładnie do tego służy. Sięganie po <section>, bo „wydaje się bardziej nowoczesny”, to najczęstsze niewłaściwe użycie tego elementu.

<aside>

<aside> oznacza treść poboczną względem otaczającej treści — pasek boczny, cytat wyróżniony, pole powiązanych linków lub blok reklam. Sygnalizuje: „to jest powiązane, ale nie stanowi głównego wątku”, czyli dokładnie rozróżnienie boilerplate’u i głównej treści, które Google i tak próbuje ustalić. Nie używaj go tylko dlatego, że coś znajduje się wizualnie z boku; stosuj go, gdy treść jest rzeczywiście drugorzędna.

Poprawne role landmarków (i mit o zarysie dokumentu)

Każdy element landmarku mapuje się na konkretną niejawną rolę ARIA, którą technologie asystujące odczytują bezpośrednio — to ta sama obliczona struktura, po której porusza się użytkownik niewidzący, więc warto znać rzeczywiste mapowanie zamiast zgadywać:

Warto odrzucić jeden popularny przesąd: zagnieżdżenie <section> nie nadaje jego nagłówkom niejawnie niższej rangi. Wczesny HTML5 definiował document outline algorithm, który obliczałby efektywny poziom nagłówka na podstawie głębokości zagnieżdżenia w elementach sekcjonujących — zagnieżdżony <h1> mógłby teoretycznie „zachowywać się jak” <h2>. Żadna przeglądarka ani czytnik ekranu nigdy nie zaimplementowały tego algorytmu, a specyfikacja WHATWG porzuciła go na rzecz znacznie prostszego ujęcia: zarys to po prostu wszystkie nagłówki dokumentu w kolejności drzewa. Zapisuj poziomy <h1>–<h6> jawnie i w kolejności, w której chcesz, by były odczytywane — głębokość zagnieżdżenia nie wykona tej pracy za ciebie.

Linki kontra przyciski — test działanie kontra nawigacja

To nie jest element landmarku, ale najczęstszy błąd semantyczny w sieci: używanie stylizowanego <div> lub <span> (albo <button>) tam, gdzie powinien być <a href>, lub odwrotnie. Specyfikacja WHATWG jest konkretna — <a> z atrybutem href to natywny mechanizm hiperłącza, a element <button> to opisany etykietą interaktywny element sterujący uruchamiający działanie. Test jest prosty: czy element zabiera użytkownika do czegoś (nowego adresu URL, nowej strony, fragmentu)? Użyj <a href>. Czy wykonuje coś na bieżącej stronie (wysyła formularz, otwiera modal, przełącza ustawienie)? Użyj <button>. Stylowanie jednego tak, by wyglądał jak drugi, nie zmienia jego natywnej natury — <div> z obsługą kliknięcia nie ma ani natywnej obsługi klawiatury, ani właściwej roli dostępności, chyba że samodzielnie odtworzysz to wszystko za pomocą role, tabindex i obsługi klawiszy. Po prostu użyj właściwego elementu.

Tabele służą danym tabelarycznym, nie układowi

Jeśli treść rzeczywiście ma wiersze i kolumny — tabelę porównawczą, siatkę cenową, zbiór danych — użyj prawdziwego <table>, a nie siatki stylizowanych <div>. Specyfikacja tabel WHATWG definiuje rzeczywisty model danych: <caption> nadaje tabeli nazwę, a komórki nagłówkowe <th> (z scope) ustanawiają relacje wiersz/kolumna, dzięki którym technologie asystujące mogą ogłosić „cena, 49 USD”, zamiast odczytywać po prostu ścianę liczb. Siatka zbudowana z <div>, która tylko wygląda jak tabela, nie przenosi tych danych o relacjach — dobrze wygląda, ale nie jest poprawnie odczytywana. Nie używaj też <table> do układu strony; to starsze nadużycie, które ta praktyka zastąpiła.

Tekst alternatywny zależy od przeznaczenia obrazu

<img> potrzebuje atrybutu alt, ale wymagania specyfikacji WHATWG zależą od przeznaczenia, a nie są uniwersalne: zdjęcie produktu wymaga opisu tego, co przedstawia; obraz czysto dekoracyjny powinien otrzymać alt="" (pusty, a nie pominięty), aby technologia asystująca go pominęła zamiast ogłaszać nazwę pliku; obraz będący również linkiem potrzebuje tekstu alternatywnego opisującego miejsce docelowe lub działanie linku, a nie tylko obraz. Nie stosuj domyślnie upakowanego słowami kluczowymi tekstu alt na każdym obrazie „dla SEO” — to niewłaściwy test. Właściwe pytanie brzmi: co użytkownik czytnika ekranu musi wiedzieć, a czego inaczej by nie zauważył?

Natywne widgety rozwijane: <details> i <summary>

W przypadku treści typu „kliknij, aby rozwinąć” — FAQ, kart specyfikacji czy tekstu ze spoilerem — para <details>/<summary> jest natywnym widgetem rozwijanym: <summary> to zawsze widoczna etykieta, a treść wewnątrz <details> pokazuje się lub ukrywa zależnie od stanu open elementu, bez JavaScriptu. Para ma wbudowaną obsługę klawiatury i właściwą semantykę dostępności — użycie akordeonu z własnego <div> i JavaScriptu oznacza ponowne implementowanie zachowania, które przeglądarka już zapewnia. Przed wdrożeniem przetestuj ją jednak w rzeczywistych docelowych przeglądarkach i czytnikach ekranu — sposób renderowania oraz ujawniania w drzewie dostępności dla <details>/<summary> historycznie różnił się zależnie od kombinacji przeglądarki i technologii asystującej, więc nie zakładaj zgodności, której nie sprawdziłeś.

Popularne mity o semantic HTML i SEO

1. „Owinięcie treści w <article> poprawia pozycje.” Nie — Mueller mówi, że element <article> “does not have any particular effect in Google Search.” (tłumaczenie) „nie ma żadnego szczególnego wpływu na wyszukiwarkę Google”. Przeczytaj źródło.
2. „Semantic HTML jest czynnikiem rankingowym.” Nie — nie jest “not a magical multiplier” (tłumaczenie) „magicznym mnożnikiem” (źródło), a Mueller dodaje: “It’s not a ranking factor, but it can help our systems to understand your content better.” (tłumaczenie) „Nie jest sygnałem rankingowym, lecz może ułatwić naszym systemom lepsze rozumienie Twojej zawartości.” To samo źródło.
3. „Google wymaga poprawnego, ściśle semantycznego HTML-u.” Nie — według Starter Guide większość sieci nie jest poprawnym HTML-em, a Google “can rarely depend on semantic meanings hidden in the HTML specification.” (tłumaczenie) „rzadko może polegać na znaczeniach semantycznych ukrytych w specyfikacji HTML”. Przejdź do cytatu.
4. „Kolejność nagłówków musi być idealna dla SEO.” Czytniki ekranu jej potrzebują, ale ranking Google nie. Szersze omówienie hierarchii nagłówków należy do centrum HTML SEO; tutaj wystarcza ten skrót.
5. „Semantic HTML i Semantic SEO to to samo.” Nie — jedno oznacza strukturę markupu, drugie strategię treści opartą na tematach i encjach.
6. „Dane strukturalne czynią semantic HTML zbędnym.” Nie — te rozwiązania się uzupełniają. Semantic HTML daje danym strukturalnym wiarygodną podstawę, lecz ich nie zastępuje, a JSON-LD nie naprawia zupy z divów. Wprowadzenie Google do danych strukturalnych wyjaśnia też, że obsługiwany markup nie gwarantuje wyniku rozszerzonego.
7. „Zagnieżdżenie <section> nadaje nagłówkom niejawną niższą rangę.” Nie — to pozostałość po starym document outline algorithm HTML5. Żadna przeglądarka ani czytnik ekranu go nie zaimplementowały, a specyfikacja HTML WHATWG nie definiuje już zarysu w ten sposób. Stosuj jawne, poprawnie uporządkowane <h1>–<h6> niezależnie od głębokości zagnieżdżenia <section>/<article>.

Semantic HTML a Semantic SEO — nie myl tych pojęć

Ponieważ mają wspólne słowo, są stale mylone, co zaśmieca wyniki wyszukiwania dla obu tematów:

• Semantic HTML = markup — elementy używane do strukturyzowania strony.
• Semantic SEO = strategia treści — budowanie autorytetu tematycznego wokół encji i powiązanych pojęć (coś, co należy do filarów AI Search i contentu, nie tutaj).

Jeśli trafiłeś tutaj z zapytania „semantic SEO” i oczekiwałeś modelowania tematów, chodzi o inny artykuł. Ten dotyczy wyłącznie elementów.

Semantic HTML i crawlery AI/LLM

W tym miejscu semantic HTML po cichu staje się bardziej istotne, ale zaznaczam, że to opinia branżowa, a nie twierdzenie wyszukiwarki. Wiele crawlerów LLM i silników odpowiedzi AI nie renderuje JavaScriptu — parsują dostarczony im HTML. Czysty markup semantyczny jest dla nich łatwiejszy do obsługi niż głęboko zagnieżdżona zupa z <div>. Barry Adams ujmuje to tak: “It’s much simpler for ChatGPT to parse a few dozen semantic HTML tags rather than several hundred (or even thousand) nested <div> tags,” (tłumaczenie) „ChatGPT znacznie łatwiej analizuje kilkadziesiąt semantycznych tagów HTML niż kilkaset, a nawet kilka tysięcy, zagnieżdżonych tagów <div>”, a szerzej: “Semantic HTML markup on your webpages can help machine systems better understand your content and its value.” (tłumaczenie) „Markup semantic HTML na stronach może pomóc systemom maszynowym lepiej zrozumieć treść i jej wartość.”. Jono Alderson przedstawia podobny argument: witryna to “an interface. An API. A dataset,” (tłumaczenie) „interfejs, API i zbiór danych”, a nie tylko doświadczenie wizualne. Jego zdanie podsumowuje sens poprawnego użycia: “If everything is a <div> or a <span>, then nothing is meaningful.” (tłumaczenie) „Jeśli wszystko jest <div> albo <span>, nic nie ma znaczenia.”. Traktuj to jako kierunkowy powód utrzymywania czystego markupu, nie obietnicę Google ani Binga.

Jak audytować i modernizować istniejące strony

Większość prawdziwych witryn już jest „zupą divów” i nie przebudujesz ich przez noc. Pragmatyczna kolejność modernizacji:

• Najpierw ustanów landmarki. Upewnij się, że istnieje dokładnie jeden <main>, dokumentowy <header>, <footer> oraz <nav> dla głównego menu. Te elementy wykonują najwięcej pracy zarówno przy ekstrakcji głównej treści, jak i dostępności.
• Zamień samodzielne bloki na <article>. Wpisy blogowe, karty produktów, komentarze — wszystko, co mogłoby istnieć niezależnie w kanale.
• Zamień prawdziwe grupy tematyczne na <section> — ale tylko tam, gdzie istnieje prawdziwy nagłówek. Jeśli go nie ma, pozostaw <div>.
• Przenieś paski boczne i pola powiązanej treści do <aside>.
• Napraw fałszywe linki i przyciski. Stylizowany <div> z obsługą kliknięcia powinien stać się <a href> (jeśli nawiguje) lub <button> (jeśli wykonuje działanie na stronie) — zwykle jest to pojedyncza poprawka o największej wartości dla użytkowników klawiatury i czytników ekranu.
• Zamień przypominające tabele siatki <div> na prawdziwe <table>, gdy treść jest rzeczywiście tabelaryczna, z <caption> i <th> dla komórek nagłówkowych.
• Nie konwertuj przesadnie. <div> użyty wyłącznie jako zaczep stylowania/układu jest poprawny. Nie wszystko potrzebuje elementu semantycznego; wymuszanie go jest własnym błędem.
• Weryfikuj, nie zakładaj. Sprawdź drzewo dostępności w DevTools przeglądarki — pokazuje role landmarków, które tworzy Twój markup, czyli tę samą strukturę, którą odczytują maszyny.

Jak to pasuje do centrum HTML SEO

Ten artykuł jest szczegółowym opracowaniem w ramach nadrzędnego centrum HTML SEO, które obejmuje szersze pytanie o to, jak wyszukiwarki parsują i wykorzystują HTML — hierarchię nagłówków, poprawność HTML oraz to, jak wyrozumiałe parsery radzą sobie z niechlujnym markupem. Celowo ograniczyłem tę stronę do samych elementów semantycznych, a te tematy pozostawiłem centrum i artykułom siostrzanym. Semantic HTML łączy się też bezpośrednio z danymi strukturalnymi: markup daje Twojemu schematowi godną zaufania podstawę, a oba rozwiązania wykonują uzupełniające się zadania.

FAQ

Czy semantic HTML pomaga w SEO, czy służy tylko dostępności? Jednemu i drugiemu — pomaga wyszukiwarkom identyfikować główną treść i jest niezbędny dla dostępności. Nie jest jednak czynnikiem rankingowym.

Czy użycie tagu <article> poprawia pozycje? Nie. Mueller mówi, że element “does not have any particular effect in Google Search.” (tłumaczenie) „nie ma żadnego szczególnego wpływu na wyszukiwarkę Google”. Przeczytaj omówienie.

Jaka jest różnica między <article> a <section>? <article> to samodzielna treść, która mogłaby istnieć niezależnie w kanale; <section> to tematyczna grupa z własnym nagłówkiem. Żaden z nich nie jest zamiennikiem <div>.

Czy na stronie mogę mieć więcej niż jeden element <main>? Nie — jeden <main> na stronę.

Czy Google wymaga poprawnego HTML-u, aby strona zajmowała wysoką pozycję? Nie — większość sieci nie jest poprawnym HTML-em, a Google “can rarely depend on semantic meanings hidden in the HTML specification.” (tłumaczenie) „rzadko może polegać na znaczeniach semantycznych ukrytych w specyfikacji HTML”. Przejdź do cytatu.

Czy semantic HTML to to samo co semantic SEO? Nie — jedno jest mark-upem, a drugie strategią treści wokół tematów i encji.

Czy dla klikalnego elementu użyć <a>, czy <button>? To zależy od działania. Jeśli nawiguje do adresu URL lub fragmentu, użyj <a href>. Jeśli wykonuje działanie na bieżącej stronie (wysyła, przełącza, otwiera modal), użyj <button>. Nie udawaj jednego drugim za pomocą stylizowanego <div> i obsługi kliknięcia.

Czy zagnieżdżenie <section> zmienia poziom nagłówka, którego powinienem użyć? Nie. Stary document outline algorithm HTML5 — który obliczałby niejawną rangę nagłówka na podstawie zagnieżdżenia sekcji — nie został zaimplementowany przez żadną przeglądarkę ani czytnik ekranu, a obecna specyfikacja nie definiuje zarysów w ten sposób. Używaj jawnych, poprawnie uporządkowanych <h1>–<h6> niezależnie od głębokości zagnieżdżenia.

Czy poprawny semantic HTML lub dane strukturalne gwarantują wynik rozszerzony? Nie. Własna dokumentacja Google dotycząca danych strukturalnych mówi, że obsługiwany markup nie gwarantuje konkretnej prezentacji w wyszukiwarce — kwalifikacja do funkcji jest niezależna od tego, czy markup jest technicznie poprawny.

Podsumowanie AI

Skrót wersji Advanced:

• Semantic HTML oznacza używanie elementów zgodnie z ich przeznaczeniem (<main>, <article>, <section>, <nav>, <header>, <aside>, <footer>), tak aby markup mówił, czym jest treść. O wyglądzie decyduje CSS.
• Nie jest czynnikiem rankingowym. Mueller określa je jako “not a magical multiplier” (tłumaczenie) „nie magiczny mnożnik”; element <article> ma “no particular effect” (tłumaczenie) „żadnego szczególnego wpływu” na wyszukiwarkę Google. Stosuj go dla dostępności i jasności, nie dla punktów rankingowych.
• Pomaga w ekstrakcji głównej treści. Adnotacja centerpiece Google oddziela główną treść od boilerplate’u za pomocą NLP niezależnie od markupu (Splitt), więc działa także na zupie divów — semantic markup tylko ogranicza zgadywanie. Splitt mówi: “It does help us, but it’s not the only thing that we look for.” (tłumaczenie) „Pomaga nam, lecz nie jest jedyną rzeczą, którą analizujemy.”
• Google nie wymaga poprawnego HTML-u. Przewodnik wskazuje, że większość sieci nie jest poprawna, dlatego Google “can rarely depend on semantic meanings hidden in the HTML specification.” (tłumaczenie) „rzadko może opierać się na znaczeniach semantycznych ukrytych w specyfikacji HTML.”
• Bing ujmuje to mocniej. Fabrice Canel mówi, że semantic HTML5 daje “an advantage in SEO.” (tłumaczenie) „przewagę w SEO.” Sformułowanie Binga jest mocniejsze niż Google, lecz żadna wyszukiwarka nie nazywa tego punktowanym czynnikiem rankingowym.
• Poprawne użycie jest ważniejsze od obecności: jeden <main>; <article> oznacza samodzielną treść; <section> grupę tematyczną z nagłówkiem, nie zamiennik <div>; <nav> tylko główną nawigację; <aside> treść poboczną.
• Elementy landmarków mapują się na konkretne niejawne role ARIA (<header>→banner, <nav>→navigation, <main>→main, <aside>→complementary, <footer>→contentinfo — tylko na poziomie dokumentu; wewnątrz sekcji nie są landmarkami). <section> jest landmarkiem (region) tylko wtedy, gdy ma dostępną nazwę; <article> nie jest landmarkiem.
• Mit algorytmu konspektu dokumentu: zagnieżdżenie <section> nie nadaje jego nagłówkom niejawnie niższej rangi. Algorytmu nigdy nie wdrożyła żadna przeglądarka ani czytnik ekranu, a specyfikacja WHATWG nie definiuje już zarysów w ten sposób — zapisuj jawne poziomy <h1>–<h6>.
• Poza landmarkami: <a href> służy nawigacji, a <button> działaniom na stronie; prawdziwe <table> (z <caption>/<th>) służą danym tabelarycznym, nie siatkom <div>; tekst alt obrazów dobieraj do celu (alt="" dla dekoracji); <details>/<summary> to natywne elementy rozwijane — przed wdrożeniem testuj renderowanie w przeglądarkach i technologiach asystujących.
• Wątek AI/LLM (opinia branżowa): crawlery LLM często nie renderują JS, więc czysty semantic HTML jest łatwiejszy do parsowania niż zagnieżdżone <div> (Adams, Alderson).
• Nie myl tego z Semantic SEO (strategią encji i tematów) — to samo słowo, inna rzecz. Dane strukturalne uzupełniają semantic HTML, nie zastępują go, a żadne z nich nie gwarantuje wyniku rozszerzonego ani poprawy pozycji.

Oficjalna dokumentacja

Dokumentacja źródłowa i wskazówki stylistyczne od wyszukiwarek oraz organizacji ustanawiających standardy.

Google

• Przewodnik dla początkujących dotyczący SEO — sekcja o sprawach, na których nie warto się skupiać, w tym zastrzeżenie dotyczące kolejności nagłówków i znaczeń semantycznych.
• Przewodnik stylistyczny dokumentacji Google dla deweloperów — HTML i tagowanie semantyczne — zasada “Use HTML elements for the purposes that they were designed for.” (tłumaczenie) „Używaj elementów HTML zgodnie z ich przeznaczeniem.”
• web.dev — Nauka HTML: semantic HTML — moduł edukacyjny Google o elementach landmarków i ich rolach dostępności.

Standardy i materiały referencyjne

• MDN — semantyka (słownik) — kanoniczna definicja elementów semantycznych i niesemantycznych wrapperów.
• Standard HTML WHATWG — sekcje — definicje <article>, <section>, <nav>, <aside>, <header>, <footer>, modele treści i obecna, niealgorytmiczna definicja zarysu dokumentu.
• Standard HTML WHATWG — linki — element <a> i semantyka hiperłączy.
• Standard HTML WHATWG — element button — semantyka natywnego interaktywnego elementu sterującego.
• Standard HTML WHATWG — dane tabelaryczne — semantyka <table>, <caption>, komórek nagłówkowych i relacji danych.
• Standard HTML WHATWG — obrazy — wymagania dotyczące tekstu alternatywnego <img> zależnie od celu i kontekstu.
• Standard HTML WHATWG — elementy details i summary — natywny element rozwijany.
• MDN — dokumentacja ról ARIA — niejawne mapowania ról landmarków dla elementów sekcjonujących.
• W3C WAI — samouczek struktury strony — sposób, w jaki natywne regiony i nagłówki wspierają nawigację technologii asystujących.

Bing / Microsoft

• Kalicube — tagi semantyczne HTML5 (Fabrice Canel) — źródło stanowiska Canela o “advantage in SEO” (tłumaczenie) „przewadze w SEO” wynikającej z semantic HTML5.

Cytaty ze źródła

Wypowiedzi Google i Binga z podaniem autorów. Tam, gdzie pozwala na to strona źródłowa, każdy link jest głębokim odnośnikiem przenoszącym bezpośrednio do cytowanego fragmentu.

Google — nie jest czynnikiem rankingowym (John Mueller)

• “Semantic HTML does help to understand a page. However, it’s not a magical multiplier for making a website rank higher.” (tłumaczenie) „Semantic HTML pomaga zrozumieć stronę, ale nie jest magicznym mnożnikiem podnoszącym pozycję witryny.” — John Mueller, Google, za pośrednictwem Search Engine Journal. Przeczytaj omówienie
• “Please use semantic HTML. It’s not a ranking factor, but it can help our systems to understand your content better.” (tłumaczenie) „Używaj semantic HTML. Nie jest czynnikiem rankingowym, ale może pomóc naszym systemom lepiej zrozumieć Twoją treść.” — John Mueller, Google, to samo źródło. Przeczytaj omówienie

Google — konkretnie element <article> (John Mueller)

• “The <article> HTML element does not have any particular effect in Google Search.” (tłumaczenie) „Element HTML <article> nie ma żadnego szczególnego wpływu na wyszukiwarkę Google.” — John Mueller, Google SEO Office Hours, za pośrednictwem Search Engine Journal. Przeczytaj omówienie
• “Sometimes there are accessibility or semantic reasons to use a specific kind of markup, so don’t only focus on SEO.” (tłumaczenie) „Czasem określony rodzaj markupu warto zastosować ze względów dostępności lub semantyki, więc nie skupiaj się wyłącznie na SEO.” — John Mueller, Google SEO Office Hours, to samo źródło. Przeczytaj omówienie

Google — ekstrakcja głównej treści (Martin Splitt)

• “We have a thing called the Centerpiece Annotation, for instance, and there’s a few other annotations that we have where we look at the semantic content.” (tłumaczenie) „Mamy na przykład adnotację Centerpiece oraz kilka innych adnotacji, w których analizujemy treść semantyczną.” — Martin Splitt, Google, za pośrednictwem Search Engine Journal. Przeczytaj omówienie
• “We figure out what looks like boilerplate and then, that gets weighted differently as well.” (tłumaczenie) „Ustalamy, co wygląda na boilerplate, a następnie nadajemy temu inną wagę.” — Martin Splitt, to samo źródło. Przeczytaj omówienie
• “It does help us, but it’s not the only thing that we look for. Yes.” (tłumaczenie) „Tak, pomaga nam, ale nie jest jedyną rzeczą, którą bierzemy pod uwagę.” — Martin Splitt, odpowiadając bezpośrednio na pytanie, czy semantic HTML5 pomaga Google. Przejdź do cytatu

Google — nie polega na semantyce zgodnej z poprawnym HTML/specyfikacją (SEO Starter Guide)

• “Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn’t matter if you’re using them out of order. The web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.” (tłumaczenie) „Semantyczna kolejność nagłówków jest bardzo ważna dla czytników ekranu, ale z perspektywy wyszukiwarki Google ich kolejność nie ma znaczenia. Sieć jako całość nie jest poprawnym HTML-em, dlatego Google Search rzadko może polegać na znaczeniach semantycznych ukrytych w specyfikacji HTML.” — przewodnik Google dla początkujących dotyczący SEO. Przejdź do cytatu

Google — używaj elementów zgodnie z ich przeznaczeniem (Style Guide)

• “Use HTML elements for the purposes that they were designed for.” (tłumaczenie) „Używaj elementów HTML zgodnie z ich przeznaczeniem.” — przewodnik stylistyczny dokumentacji Google dla deweloperów. Przeczytaj źródło

Bing / Microsoft (Fabrice Canel)

• Fabrice Canel z Microsoft Bing powiedział, że strony z poprawnie wdrożonym semantic HTML5 mają przewagę w SEO nad tymi, które go nie mają — Bing ujmuje to mocniej niż Google („pomaga w zrozumieniu”), choć nadal nie opisuje tego jako punktowanego czynnika rankingowego. Parafraza, nie cytat dosłowny: informacja pochodzi z cytowania wtórnego (Kalicube), a nie pobranego źródła pierwotnego Binga — przed potraktowaniem jej jako cytatu bezpośredniego potwierdź dokładne brzmienie w oryginale. Przeczytaj źródło

Którego elementu potrzebuje ten blok?

Pytanie article-vs-section-vs-div (i pozostałe wybory landmarków) oznacza prawdziwe rozgałęzienie, a nie preferencję stylistyczną. Na każdym etapie odpowiadaj uczciwie — test zawsze brzmi „co ta treść rzeczywiście robi?”, a nie „co wygląda nowocześniej?”.

Czego nie robić

To rzeczywiste błędy wskazywane przez powyższe mity — przy każdym wyjaśniam, dlaczego jest zły, i co zrobić zamiast tego.

• Owijanie treści w <article> w oczekiwaniu na wzrost pozycji. Dlaczego to błąd: Mueller powiedział, że element “does not have any particular effect in Google Search.” (tłumaczenie) „nie ma żadnego szczególnego wpływu na wyszukiwarkę Google”. Przeczytaj omówienie. Co zrobić zamiast: używać <article>, gdy treść jest rzeczywiście samodzielna i mogłaby istnieć niezależnie w kanale — dla dostępności i jasności, nie jako dźwigni SEO.

• Traktowanie semantic HTML jako punktowanego czynnika rankingowego. Dlaczego to błąd: nie jest ono “not a magical multiplier” (tłumaczenie) „magicznym mnożnikiem” (źródło) i nie ma tu punktowanego sygnału, za którym warto gonić. Co zrobić zamiast: traktować tę pracę jako inwestycję w zrozumienie strony i dostępność, nie jako projekt z oczekiwanym wzrostem pozycji.

• Obsesyjne dążenie do idealnej kolejności nagłówków lub ścisłej poprawności dla Google. Dlaczego to błąd: przewodnik Google mówi, że “the web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.” (tłumaczenie) „sieć jako całość nie jest poprawnym HTML-em, dlatego Google Search rzadko może polegać na znaczeniach semantycznych ukrytych w specyfikacji HTML”. Co zrobić zamiast: poprawiać kolejność nagłówków i zgodność dla czytników ekranu oraz użytkowników — tam ma to rzeczywiste znaczenie — nie dlatego, że Google przyznaje za to punkty.

• Używanie <section> jako zamiennika <div>, bo „wydaje się bardziej nowoczesny”. Dlaczego to błąd: <section> bez nagłówka nie jest tematyczną grupą, tylko ozdobą — to najczęstsze niewłaściwe użycie tego elementu. Co zrobić zamiast: jeśli blok nie ma sensu z własnym nagłówkiem, użyj <div>.

• Mylenie Semantic HTML z Semantic SEO. Dlaczego to błąd: jedno to struktura markupu, drugie to strategia treści wokół tematów i encji — ich połączenie oznacza optymalizowanie niewłaściwej rzeczy pod kątem rzeczywistego celu. Co zrobić zamiast: trzymaj te pojęcia osobno; ten artykuł dotyczy wyłącznie elementów.

• Pomijanie semantic HTML, bo dane strukturalne już istnieją. Dlaczego to błąd: JSON-LD nie naprawia zupy divów, a dane strukturalne nie zastępują struktury markupu. Co zrobić zamiast: używać obu — dane strukturalne leżą na semantycznym fundamencie, ale go nie zastępują. Żadne z nich nie gwarantuje też wyniku rozszerzonego — to osobna kwestia kwalifikacji, niezależna od poprawności markupu.

• Zagnieżdżanie elementów <section>, aby nagłówki „zachowywały się jak” niższy poziom. Dlaczego to błąd: opiera się to na starym document outline algorithm HTML5, którego nie zaimplementowała żadna przeglądarka ani czytnik ekranu i którego obecna specyfikacja WHATWG już tak nie definiuje. Co zrobić zamiast: zapisywać jawne, poprawnie uporządkowane poziomy <h1>–<h6> — nie pozwalać, by głębokość zagnieżdżenia zastępowała zamierzony poziom nagłówka.

• Używanie <div> z obsługą kliknięcia zamiast <a href> lub <button>. Dlaczego to błąd: tracisz natywną obsługę klawiatury i właściwą rolę dostępności, chyba że ręcznie odtworzysz oba elementy za pomocą role, tabindex i obsługi klawiszy. Co zrobić zamiast: używaj <a href> gdy działanie prowadzi gdzieś dalej, a <button>, gdy wykonuje coś na bieżącej stronie — otrzymasz natywne zachowanie za darmo.

Elementy landmarków w skrócie

Siedem elementów omawianych w tym artykule, ich rzeczywiste przeznaczenie oraz wzorzec nadużycia, którego należy unikać.

Szybka zasada: jeśli blok może być samodzielnie syndykowany, jest <article>; jeśli potrzebuje nagłówka, by mieć sens, jest <section>; jeśli nie spełnia żadnego z tych warunków, jest <div>.

Poza landmarkami: elementy interaktywne i dane

Prompty do modernizacji HTML

Gotowe do skopiowania prompty do zadania omawianego w tym artykule: znajdowania zupy divów i zamiany jej na poprawny markup semantyczny. Wklej HTML strony (źródło strony, nie wyrenderowany DOM) do asystenta AI, używając jednego z nich.

Wskaż zupę divów i zaproponuj zamienniki

Here is the HTML for one of my pages. Identify every <div> or <span> that is standing
in for a semantic landmark, and suggest the correct replacement element from this list:
header, nav, main, article, section, aside, footer. For each suggestion, explain which
test it passes (e.g. "this could stand alone in a feed, so it's an <article>" or "this
has its own heading and one theme, so it's a <section>"). Flag any block that should
stay a <div> because it's purely a styling/layout hook.

[paste HTML here]

Sprawdź błędy strukturalne landmarków

Review this page's HTML for these specific structural mistakes: more than one <main>
element, a <main> nested inside <article>/<aside>/<header>/<footer>/<nav>, a <nav>
wrapping something that isn't major navigation, or a <section> with no heading. List
each problem found with the line/snippet and the fix.

[paste HTML here]

Ustal kolejność modernizacji

Given this page's HTML, tell me which landmark to fix first for the biggest
accessibility and main-content-extraction benefit: establishing <main>/<header>/
<footer>/<nav>, converting self-contained blocks to <article>, converting themed
groups to <section>, or moving sidebars to <aside>. Order the fixes and say what
"done" looks like for each.

[paste HTML here]

Landmarki odpowiadają zamierzonej strukturze

Test do wykonania: otwórz drzewo dostępności w DevTools przeglądarki (Chrome/Edge: DevTools → Elements → Accessibility) na zmodernizowanej stronie. Oczekiwany wynik: wymienione role landmarków (banner, navigation, main, complementary, contentinfo) odpowiadają elementom semantycznym, które rzeczywiście zapisano — jeden landmark main/„main”, jeden banner itd. Interpretacja niepowodzenia: brakująca lub zduplikowana rola landmarku oznacza, że markup nie utworzył zamierzonej struktury (np. pojawił się drugi <main> albo <div>, który powinien zostać zmieniony). Okno monitorowania: natychmiast — sprawdź zaraz po wdrożeniu modernizacji. Wyzwalacz wycofania: więcej niż jeden landmark main/„main” albo landmark zagnieżdżony tam, gdzie nie powinien (np. main wewnątrz article), oznacza konieczność wycofania zmiany i ponownego sprawdzenia markupu.

Dokładnie jeden <main> na stronę

Test do wykonania: grep -o "<main" page.html | wc -l na wyrenderowanym HTML-u (lub źródle strony), ewentualnie wyszukaj <main w panelu Elements DevTools. Oczekiwany wynik: dokładnie jedno dopasowanie. Interpretacja niepowodzenia: zero dopasowań oznacza brak landmarku głównej treści; więcej niż jedno oznacza, że „najwyraźniejszy sygnał” dotyczący głównej treści jest teraz niejednoznaczny. Okno monitorowania: natychmiast, w momencie wdrożenia. Wyzwalacz wycofania: każda liczba inna niż dokładnie jeden.

Crawlery nierenderujące nadal widzą strukturę

Test do wykonania: pobierz stronę zwykłym klientem HTTP (curl lub „view page source”, nie wyrenderowanym DOM-em) i potwierdź, że elementy semantyczne są w surowej odpowiedzi, a nie zostały wstrzyknięte później przez JavaScript. Oczekiwany wynik: <header>, <nav>, <main>, <article>/<section>, <aside> i <footer> pojawiają się w początkowym ładunku HTML. Interpretacja niepowodzenia: jeśli tagi semantyczne pojawiają się dopiero po wykonaniu JS, crawlery, które nie renderują JavaScriptu (zgodnie z punktem o crawlerach AI/LLM), w ogóle nie zobaczą tej struktury. Okno monitorowania: natychmiast — sprawdzaj ponownie za każdym razem, gdy szablon lub framework JS zmieni sposób renderowania strony. Wyzwalacz wycofania: landmarki semantyczne są obecne w wyrenderowanym DOM-ie, ale nie ma ich w surowej odpowiedzi HTML.

Poziomy nagłówków są jawne, a nie dziedziczone z zagnieżdżenia

Test do wykonania: w drzewie dostępności DevTools przeglądarki (lub w rozszerzeniu sprawdzającym zarys) wypisz poziomy nagłówków w kolejności dokumentu i porównaj je z rzeczywistymi tagami <h1>–<h6> w źródle, niezależnie od tego, jak głęboko każdy nagłówek znajduje się wewnątrz zagnieżdżonych elementów <section>/<article>. Oczekiwany wynik: zgłoszony poziom każdego nagłówka odpowiada jego literalnemu tagowi (<h2> zgłasza poziom 2 niezależnie od liczby sekcji, w których jest zagnieżdżony) — nie ma niejawnego obniżenia przez zagnieżdżenie. Interpretacja niepowodzenia: jeśli szablon lub biblioteka komponentów zakłada, że zagnieżdżanie <section> „automatycznie” obniży rangę nagłówka, założenie jest błędne — stary document outline algorithm nigdy nie został zaimplementowany, a obecna specyfikacja nie oblicza zarysów w ten sposób. Popraw rzeczywiste tagi nagłówków. Okno monitorowania: natychmiast oraz za każdym razem, gdy nowy szablon lub wzorzec komponentu wprowadza zagnieżdżone sekcje. Wyzwalacz wycofania: wyrenderowany lub ogłoszony poziom nagłówka nie odpowiada jego literalnemu tagowi <h1>–<h6>.

Fałszywe linki i przyciski są dostępne z klawiatury

Test do wykonania: przejdź po stronie wyłącznie klawiaturą za pomocą Tab i spróbuj aktywować każdy klikalny element klawiszem Enter/Spacja; osobno sprawdź w drzewie dostępności, jaką rolę zgłasza każdy klikalny element. Oczekiwany wynik: elementy nawigujące zgłaszają link (natywne <a href>), elementy wykonujące działanie na stronie zgłaszają button (natywne <button>), a oba typy można osiągnąć i aktywować klawiaturą bez dodatkowego kodu role/tabindex/obsługi klawiszy. Interpretacja niepowodzenia: <div> lub <span> z obsługą kliknięcia, którego nie można osiągnąć klawiaturą albo który zgłasza ogólną rolę zamiast link/button, trzeba zmienić na element natywny, a nie łatać ARIA. Okno monitorowania: natychmiast — sprawdzaj ponownie po każdej zmianie biblioteki komponentów lub systemu projektowego dotyczącej elementów interaktywnych. Wyzwalacz wycofania: dowolnego klikalnego kontrolera nie można osiągnąć ani aktywować wyłącznie klawiaturą.

Sprawdź się: Semantic HTML

Pięć krótkich pytań o semantic HTML i o to, co robi (a czego nie robi) dla SEO. Wybierz odpowiedź na każde pytanie, a następnie sprawdź wynik.

Dziennik zmian