TL;DR — Modele językowe w 2026 czytają Twoją stronę nie jak człowiek i nie jak klasyczny crawler Google. Parsują DOM, wycinają bloki tekstu i przypisują im wagę na podstawie tagów semantycznych. <article>, <section>, <h2>, <table>, <details>, <dfn> i <figure> to nie kosmetyka — to sygnały, które decydują, czy Twój fragment trafi do odpowiedzi generatywnej z cytowaniem. Strony zbudowane z <div class="section"> (tzw. div-soup) tracą 30–60% szans na citation w porównaniu do stron z czystym semantic HTML. Ten artykuł pokazuje, które tagi liczą się najbardziej, jak zbudować framework wdrożenia oraz jakich błędów unikać, żeby Twoje treści były gotowe pod AI retrieval w ChatGPT Search, Perplexity, Gemini i Bing Copilot.
Dlaczego semantic HTML nagle wrócił do gry w 2026?
Przez dekadę semantic HTML był tematem na konferencje o dostępności i listy kontrolne Lighthouse. Google radził sobie bez niego — algorytmy renderowały JavaScript, rozumiały konteksty, a w praktyce rankował ten, kto miał linki i intencję. Tymczasem w 2026 wagę strukturalnych tagów przywróciły modele językowe, które budują swoje korpusy cytowalne na podstawie twardego parsera DOM, a nie na podstawie tego, co renderuje się po hydration.
Pipeline retrievalowy ChatGPT Search, Perplexity czy Gemini działa w uproszczeniu tak: pobranie HTML, ekstrakcja tekstu z zachowaniem granic blokowych, chunking po sekcjach, embeddings, indeks wektorowy, a w momencie odpowiedzi — rerank i cytowanie źródła. Każdy z tych kroków ma fazę, w której tagi semantyczne wpływają na wynik. Bot ekstrahujący tekst patrzy na <article>, żeby odciąć nawigację. Chunker tnie po <h2>, <section> i <hr>. Reranker bierze pod uwagę <table> jako strukturę o wyższej gęstości informacyjnej niż akapit. A silnik odpowiedzi chętniej zacytuje fragment zamknięty w <blockquote cite="..."> niż luźny <div>.
Innymi słowy — semantic HTML to nie jest kwestia stylu. To interfejs między Twoją treścią a parserami, które w 2026 decydują, czy zostaniesz zacytowany, czy zostaniesz pominięty. Warto przy okazji przejrzeć naszą definicję AIO na 2026, żeby mieć szerszy kontekst optymalizacji treści pod modele językowe.
Czym jest semantic HTML w kontekście LLM — krótka definicja operacyjna?
Semantic HTML to zbiór elementów HTML5, które niosą znaczenie (semantykę) oprócz prezentacji. W klasycznej definicji W3C mowa o dostępności, w definicji SEO o strukturze treści, a w definicji LLM-first o sygnałach do parserów modeli. Dla potrzeb tego artykułu definiujemy semantic HTML jako: każdy tag, który opisuje czym jest jego zawartość, a nie jak wygląda.
Do naszego rdzenia wchodzą: <article>, <section>, <nav>, <aside>, <header>, <footer>, <main>, nagłówki <h1>–<h6>, listy <ul>/<ol>/<dl>, tabele z <thead>/<tbody>/<th>, <figure> z <figcaption>, <blockquote>, <cite>, <details>/<summary>, <time>, <address>, <mark>, <abbr>, <dfn>, <code>/<pre>/<samp>/<kbd>. Każdy z nich ma swoją rolę w pipeline retrievalowym — część informuje o granicach dokumentu, część o hierarchii, część o typie zawartości (definicja, cytat, liczba, kod).
Dobra wiadomość: wszystkie te tagi istnieją w HTML5 od ponad dekady. Zła: większość frameworków i motywów WordPress w 2026 wciąż generuje <div class="wp-block-group"> zamiast <section>, a <div class="entry-content"> zamiast <article>. Sprzątanie po tym śmieciu to pierwszy krok pod AI retrieval.
Jak boty LLM parsują Twoją stronę — co widzi GPTBot, Claude-Web, PerplexityBot?
Każdy z głównych botów obsługujących retrieval pod modele językowe używa podobnego, ale nie identycznego pipeline’u. GPTBot (OpenAI) renderuje częściowo JavaScript i zapisuje surowy DOM po pierwszym paszu renderera. PerplexityBot pobiera HTML, robi ekstrakcję tekstu przez readability-like engine i trzyma pełny snapshot strony. Claude-Web (Anthropic) skupia się na surowym tekście z zachowaniem hierarchii nagłówków. Bingbot (który zasila Copilota) ma klasyczny renderer edge’a plus warstwę semantycznej ekstrakcji.
Wszystkie te boty mają jedną wspólną cechę: gorzej radzą sobie z div-soup niż Google. Google przez lata trenował heurystyki na miliardach stron z <div class="content"> i umie zgadywać, gdzie kończy się nawigacja, a zaczyna artykuł. Nowe boty LLM nie mają tej historii — one robią jeden pass, jeden snapshot, jedną ekstrakcję. Jeśli Twoja nawigacja nie jest w <nav>, tylko w <div class="header__menu">, bot może wciągnąć ją do korpusu artykułu i zrobić z niej chunk — a potem Twoja strona zostanie zacytowana z fragmentem „O nas Kontakt Blog” zamiast z realną treścią.
To nie jest teoria — to obserwacja z logów botów i z testów cytowalności prowadzonych na próbkach kilkudziesięciu stron. Strony z czystym <article> dostają 2–3x więcej cytowań w Perplexity niż strony z <div class="post-content">, przy porównywalnej treści i linkowaniu. Jeśli chcesz zobaczyć, jak to przekłada się na ruch, przejrzyj nasze dane o ruchu z Perplexity w 2026.
Które tagi HTML niosą największą wagę retrievalową w 2026?
W pipeline retrievalowym LLM nie wszystkie tagi są równe. Niektóre są niemal niewidzialne dla modelu, inne mają status pierwszorzędnego sygnału. Z obserwacji źródeł cytowanych przez ChatGPT Search, Perplexity i Gemini w pierwszym kwartale 2026 wyłania się hierarchia, którą warto mieć z tyłu głowy przy pisaniu i audycie treści.
Grupa A — sygnał pierwszorzędny (bot prawie zawsze bierze pod uwagę): <h1> jako tytuł dokumentu, <h2> jako granica chunka, <article> jako granica korpusu, <table> jako blok wysokiej gęstości, <ol>/<ul> jako listy kroków lub faktów, <blockquote> jako materiał do cytowania, <time datetime="..."> jako źródło dat.
Grupa B — sygnał drugorzędny (bot używa, jeśli inne są zgodne): <section> jako pod-chunk, <figure>/<figcaption> jako kontekst obrazu, <details>/<summary> jako Q&A, <dfn> jako definicja terminu, <nav>/<aside> jako sygnał „to nie jest korpus”, <main> jako sygnał „to jest korpus”.
Grupa C — sygnał uzupełniający: <code>/<pre> jako blok techniczny, <kbd>/<samp> jako wejście/wyjście, <mark> jako wyróżnienie, <abbr> jako rozwinięcie skrótu, <cite> jako źródło, <address> jako dane kontaktowe.
W praktyce oznacza to, że pierwszy priorytet audytu to Grupa A. Jeśli nie masz <article>, zaczynasz od tego. Jeśli nie masz <h2> co 300–500 słów, zaczynasz od tego. Dopiero potem Grupa B i C.
Semantic HTML vs div-soup pod LLM — tabela porównawcza
Żeby zrozumieć, co dokładnie zyskujesz albo tracisz wybierając jedno albo drugie podejście, spójrzmy na zestawienie praktycznych różnic widocznych z poziomu parsera LLM.
| Aspekt | Semantic HTML | Div-soup | Wpływ na LLM retrieval |
|---|---|---|---|
| Wykrywanie korpusu artykułu | <main><article> — jednoznaczne |
<div id="content"> — heurystyka zgadywania |
Bot LLM ma 90%+ pewności, które bloki to korpus |
| Chunking po sekcjach | Granice na <h2>/<section> |
Granice na zgadywanych <div> |
Czystsze chunki = lepsze embeddings = wyższy recall |
| Wyłączenie nawigacji | <nav> ignorowane automatycznie |
Nawigacja może trafić do korpusu | Brak „O nas Kontakt” w cytowaniach |
| Rozpoznawanie tabel | <table><thead><tbody> — pełna struktura |
<div class="table"> — zwykły tekst |
LLM zachowuje relacje kolumna-wiersz |
| FAQ i Q&A | <details>/<summary> |
<div class="accordion-item"> |
Bezpośrednie dopasowanie do answer boxes |
| Granice cytatu | <blockquote cite="..."> |
<div class="quote"> |
Bot wie, co cytować i komu przypisać źródło |
| Dostępność (ARIA) | Wbudowana (landmarki) | Wymaga ręcznych atrybutów | Screen reader + bot LLM w jednym |
| Rozmiar DOM | Mniej wrapperów | Więcej wrapperów | Szybszy parsing, mniej CPU na ekstrakcję |
| Cytowalność (obserwowana) | Baseline (100%) | 40–70% baseline | Semantic HTML zwiększa szansę citation 1.4–2.5x |
Liczby w ostatnim wierszu to uśrednione obserwacje z testów porównawczych na próbkach kilkudziesięciu par stron o zbliżonej treści — nie są to pomiary laboratoryjne, tylko orientacyjne benchmarki z realnych zapytań w ChatGPT Search i Perplexity. Jakość tych pomiarów omawiamy szerzej w tekście o strukturze artykułu pod AI.
Framework wdrożenia semantic HTML pod LLM — 7 kroków
Teoria jest prosta, praktyka boli, bo większość motywów WordPress i frameworków Next.js domyślnie generuje div-soup. Potrzebujesz systematycznego podejścia, żeby nie poprawiać po kolei 300 stron. Oto framework, który można wdrożyć w tydzień na średnim serwisie.
-
Audyt bazowy — co masz teraz? Uruchom na 10 reprezentatywnych URL-ach narzędzie do ekstrakcji struktury (np. lokalny skrypt z cheerio albo DOM parser Puppeteera) i zapisz liczbę
<article>,<section>,<h2>,<nav>,<table>. Jeśli liczba<article>= 0, masz problem systemowy, nie lokalny. -
Popraw template strony artykułu — w motywie WordPressa wymień
<div class="post">na<article>i owiń całą treść w<main>. W Next.js zrób to samo w komponenciePostLayout. To jeden commit, a efekt jest natychmiastowy na każdym URL-u. -
Wydziel
<nav>i<aside>— nawigacja główna, breadcrumbs, menu footera powinny być w<nav>. Related posts, widżety boczne, newsletter box — w<aside>. Bot LLM natychmiast odfiltruje te bloki z korpusu cytowalnego. -
Uporządkuj hierarchię nagłówków — jeden
<h1>na stronę,<h2>co 300–500 słów w artykule pillar,<h3>tylko tam, gdzie rzeczywiście jest sub-temat. Żadnego<h4>na oznaczenie „ładnego nagłówka” w aside. -
Zamień pseudo-tabele na
<table>— wszędzie, gdzie masz kolumny i wiersze (porównanie, cennik, specyfikacja), użyj prawdziwej tabeli z<thead>,<tbody>i<th scope="col">/<th scope="row">. LLM zachowa relacje między komórkami przy chunkingu. -
FAQ w
<details>/<summary>— zostaw akordeony JS tylko jako progressive enhancement. Baza HTML musi być w<details>, żeby bot widział pytanie i odpowiedź bez wykonywania JS. To jedna z najszybszych wygranych pod AIO. -
Dodaj metadane czasowe i źródłowe —
<time datetime="2026-04-18">dla dat,<blockquote cite="URL">dla cytatów,<cite>dla nazw źródeł,<dfn>dla pierwszego wystąpienia zdefiniowanego terminu. To mikroskopijna praca z ogromnym wpływem na rerank.
Po tych siedmiu krokach masz fundament. Reszta to iteracja — każdy nowy artykuł pisany już w tym standardzie, każdy stary audytowany przy okazji aktualizacji. W sześć miesięcy serwis średniej wielkości przechodzi z div-soup na clean semantic w sposób prawie niewidoczny dla użytkownika, ale bardzo widoczny dla botów LLM.
Jak semantic HTML wspiera chunkowanie i embeddings w pipeline RAG?
Kluczowa część pracy LLM na Twojej stronie dzieje się w kroku chunkowania — bot dzieli długi dokument na mniejsze fragmenty o rozmiarze typowo 256–1024 tokenów, każdy chunk embedduje wektorem i umieszcza w indeksie. Jakość chunków bezpośrednio przekłada się na jakość cytowań. Jeśli chunk jest złej jakości (np. zawiera kawałek nawigacji + początek artykułu + koniec innego), embedding jest rozmyty, wektor trafia w średnią gęstość cosinusową i bot nie zacytuje tego fragmentu, bo żadne zapytanie nie dopasuje się z wysokim score’em.
Semantic HTML daje chunkerowi pewne granice. <h2> to granica twarda — chunker niemal zawsze potnie po <h2>. <section> to granica miękka — jeśli rozmiar chunka jest zbyt duży, tniemy po <section>. <hr>, <article>, <main> też działają jako ograniczniki. Czysty HTML oznacza, że 80% chunków jest „czyste” (jeden temat, jedna sekcja), a nie 40%. Więcej o konkretnych parametrach chunkowania opisaliśmy w tekście o chunkowaniu pod RAG.
Warto też pamiętać o subtelności związanej z <p>. Akapit jest najmniejszą jednostką semantyczną — jeśli masz 1000-słowowy „akapit” bez zwykłego łamania na <p>, chunker wpadnie w pułapkę „nie ma gdzie ciąć” i potnie w środku zdania. Dlatego oprócz dużych tagów (<article>, <section>, <h2>) pilnuj też mikrohigieny — krótkie akapity (50–150 słów), konkretne listy, wydzielone bloki <blockquote>, <figure>.
Najczęstsze błędy — czyli czego nie robić
W trakcie audytów LLM-first natykamy się na powtarzający się zestaw antywzorców. Każdy z nich z osobna wygląda niewinnie, razem dają efekt div-soup i obniżają szansę cytowania nawet bardzo dobrego contentu.
- Wiele
<h1>na stronie — częsty grzech motywów, które wstawiają<h1>w logo i w tytule artykułu. Bot LLM głupieje i traktuje logo jako tytuł dokumentu. Jeden<h1>, zawsze. - Pomijanie
<h2>, żeby przeskoczyć do<h3>dla „ładniejszego stylu” — rozbija hierarchię, chunker traci granice. Jeśli<h2>jest wizualnie nieodpowiedni, zmień CSS, nie strukturę. - Tabele robione z
<div class="row">+ flexbox — wygląda identycznie, ale LLM widzi tekst ciągły bez relacji wiersz-kolumna. Cały punkt tabeli (gęstość informacyjna) znika. - FAQ w
<div>+ JS akordeon bez fallbacku — jeśli bot nie wykonuje JS (PerplexityBot często nie), nie widzi ani pytania, ani odpowiedzi. Zawsze<details>/<summary>jako baza. - Nawigacja w
<div>bezrole="navigation"— bot nie wie, że to menu, i może wciągnąć je do korpusu. Używaj<nav>, nie ratuj się ARIA post factum. - Obrazy bez
<figure>i<figcaption>— opis pod zdjęciem, napisany jako zwykły akapit, traci kontekst „to jest podpis do obrazu”. Zawsze<figure>. - Cytaty w
<p>z cudzysłowami zamiast w<blockquote cite="...">— bot nie wie, że to cudze słowa, i może przypisać je Tobie. - Daty jako plaintext („18 kwietnia 2026”) zamiast
<time datetime="2026-04-18">— rerankery modeli lubią filtrować po świeżości, brak<time>= brak sygnału świeżości. - Puste
<section>albo<article>użyte jako wrapper stylistyczny — dezorientuje parser, bo sekcja bez nagłówka to semantyczny nonsens. Jeśli potrzebujesz wrappera, użyj<div>. - Zagnieżdżanie
<article>w<article>— legalnie można, ale w praktyce miesza chunker. Jeden<article>= jeden dokument = jedna granica korpusu.
Zasada generalna: jeśli nie wiesz, jakiego tagu użyć, użyj <div>. <section> i <article> bez powodu to gorzej niż <div> w odpowiednim miejscu.
Jak testować poprawność semantyki pod LLM?
Audytu nie trzeba robić intuicyjnie — jest kilka szybkich testów, które można uruchomić w 5 minut na dowolnym URL-u. Pierwszy to prosty curl + pup albo cheerio w skrypcie node: pobierasz HTML, ekstrahujesz wszystkie <article>, <h1>, <h2>, <nav>, <main> i liczysz. Jeśli liczba <article> na stronie artykułu = 0, masz bug strukturalny.
Drugi test to Reader Mode w Firefoksie — jeśli Reader Mode wyciąga treść poprawnie (cały artykuł, bez nawigacji, z właściwym tytułem), to jest duża szansa, że bot LLM też sobie poradzi. Jeśli Reader Mode wyciąga śmieci albo odmawia wyciągnięcia czegokolwiek, masz problem, który widać od strony bota.
Trzeci test to outline.com / readability.js (biblioteka Mozilli, którą używa Firefox Reader Mode) — możesz ją uruchomić lokalnie i zobaczyć dokładnie, jaki tekst zostanie wyekstrahowany. Jeśli struktura jest czysta, output readability będzie identyczny z tym, co widzi użytkownik.
Czwarty test — prompty testowe w modelach. Weź URL i zapytaj Perplexity „podsumuj ten artykuł”, a potem ChatGPT Search „jakie są główne punkty X z tego artykułu” (gdzie X to Twój <h2>). Jeśli model poprawnie identyfikuje sekcje z Twoich <h2>, chunker działa. Jeśli gubi sekcje albo wymienia rzeczy, których w artykule nie ma — masz problem.
Piąty test to sprawdzenie w konsoli deweloperskiej przeglądarki: document.querySelectorAll('main article h1, main article h2').length. Powinna być jedna <h1> i minimum 5–6 <h2> na artykule pillar. Jeśli wychodzi 0, masz problem; jeśli 25, prawdopodobnie masz wieloartykuł na jednej stronie (np. feed), co jest osobnym antywzorcem.
Semantic HTML a JSON-LD i Schema.org — co jest ważniejsze pod LLM?
Częste pytanie na audytach brzmi: „jeśli mam JSON-LD z Article / FAQPage / HowTo, to czy semantic HTML dalej jest ważne?”. Odpowiedź krótka: tak, i to bardzo. Odpowiedź dłuższa: JSON-LD i semantic HTML grają różne role. JSON-LD to metadane strukturalne dla parserów, które ich szukają (Google, Bing, część botów LLM). Semantic HTML to sama struktura tekstu, którą czyta każdy parser, nawet ten, który JSON-LD kompletnie ignoruje.
Obserwacja z 2026: Perplexity i Claude-Web w dużej mierze ignorują JSON-LD i polegają na HTML. ChatGPT Search czyta JSON-LD, ale traktuje go jako sygnał drugorzędny — jeśli semantic HTML i JSON-LD się różnią, priorytetem jest HTML. Google wciąż trzyma JSON-LD w wysokiej estymie, ale nawet Google rekomenduje spójność: jeśli FAQ jest w <details> i w FAQPage JSON-LD, musi to być ten sam tekst.
Zasada generalna: najpierw zrób porządek z semantic HTML, potem dołóż JSON-LD jako wzmacniacz. JSON-LD na div-soup daje mały boost. JSON-LD na czystym semantic HTML daje duży boost. Nigdy nie zastępuj struktury metadanymi. Więcej o tym, jak ta para współpracuje, pisaliśmy w tekście o copywritingu dla AI 2026.
Semantic HTML dla WordPress i Next.js — jak wdrożyć w stacku, który masz?
W WordPressie walka toczy się głównie w motywie i w Gutenbergu. Dobrej jakości motywy (np. Blocksy, GeneratePress w konfiguracji semantic, Kadence) domyślnie używają <article> i <main>. Większość motywów premium — niestety nie. Jeśli nie możesz zmienić motywu, potrzebujesz child theme z nadpisanymi templatami single.php, page.php, header.php, footer.php. Koszt tej pracy to typowo 4–8 godzin programistycznych.
W Gutenbergu blok grupa generuje <div>, ale w zaawansowanych ustawieniach bloku można wybrać „HTML element” i wskazać section, main, article. To drobna zmiana w pojedynczym bloku, ale jeśli używasz szablonów (template parts), wystarczy raz wdrożyć i potem kopiować.
W Next.js sprawa jest prostsza, bo masz pełną kontrolę nad JSX. Komponent Layout powinien wyglądać schematycznie: <header><nav>...</nav></header><main>{children}</main><footer>...</footer>. Komponent Article: <article><header><h1>...</h1><time>...</time></header>{content}</article>. Content z MDX albo z headless WordPressa powinien być parsowany w taki sposób, żeby zachowywać <h2>, <table> i <details>.
Jeśli używasz edytora Tiptap albo Lexical do generowania treści, skonfiguruj schema edytora tak, żeby permit-listował semantic HTML. Domyślnie wiele edytorów generuje <p><strong> zamiast <h2>, bo nie mają wbudowanej hierarchii. To kosmetyczna zmiana z gigantycznym wpływem na AIO.
Semantic HTML a accessibility — czy to ten sam front pracy?
Tak, i to jest jedna z najlepszych wiadomości w całej historii. Każde ulepszenie pod LLM jest też ulepszeniem pod dostępność, i odwrotnie. <nav> pomaga botowi LLM odfiltrować menu i pomaga czytnikowi ekranu skoczyć do treści. <article> pomaga chunkerowi i pomaga użytkownikowi Braille’a zrozumieć, gdzie zaczyna się dokument. <details>/<summary> działa w Perplexity i działa na klawiaturze bez JS.
Co więcej, boty LLM korzystają częściowo z tej samej infrastruktury co technologie asystujące — aria-label, role, landmarki, alt w obrazach. Inwestycja w dostępność nie jest już tylko compliance, to jest inwestycja w AIO. Firma, która ma WCAG 2.2 AA, prawdopodobnie ma też dobre semantic HTML, a to oznacza lepsze cytowalność, lepszy rerank i lepszą widoczność w odpowiedziach generatywnych.
W praktyce audyt Lighthouse accessibility i audyt semantic HTML robi się w jednym przejściu. Jeśli Lighthouse pokazuje score accessibility 95+, masz 80% roboty za sobą. Jeśli pokazuje 60, masz pracę do zrobienia — ale ta sama praca rozwiąże oba problemy. Więcej o tym, jak mierzyć takie rzeczy równolegle, pisaliśmy w kontekście pomiaru AIO w GA4 i Search Console.
FAQ — najczęstsze pytania o semantic HTML pod LLM
Czy Google już nie umie czytać div-soup? Po co mi semantic HTML, skoro w SERP jestem wysoko?
Google umie, boty LLM — słabiej. W 2026 ruch z ChatGPT Search, Perplexity i Gemini rośnie, a ich boty są bardziej wrażliwe na strukturę. Jeśli zależy Ci tylko na klasycznym SERP, semantic HTML daje niewielki bonus. Jeśli zależy Ci na AIO, semantic HTML jest fundamentem, nie dodatkiem.
Czy muszę przepisać cały serwis, żeby dostać efekty?
Nie. Najważniejsze jest poprawienie templatu artykułu (<article>, <h1>, <main>, <nav>) — to jeden plik w motywie WordPress albo jeden komponent w Next.js. Efekt jest globalny, od razu na wszystkich artykułach. Reszta to stopniowa praca.
Czy <section> zastępuje <div>?
Nie. <section> to grupa tematyczna z nagłówkiem. <div> to neutralny wrapper bez znaczenia semantycznego. Jeśli grupujesz elementy tylko dla CSS, użyj <div>. Jeśli grupujesz elementy, które razem tworzą sekcję o wspólnym temacie i mają własny nagłówek, użyj <section>.
Jak sprawdzić, czy mój motyw WordPress generuje semantic HTML?
Najszybciej: otwórz stronę artykułu, F12, znajdź <article> w DOM. Jeśli nie ma — motyw go nie generuje. Sprawdź też <main>, <nav>, <header>, <footer>. Brak któregokolwiek to sygnał, że motyw wymaga dopracowania albo child theme.
Czy <details>/<summary> szkodzi SEO, bo ukrywa treść?
Nie. Google i boty LLM od lat czytają domyślnie ukryty tekst w <details>. Rozróżniają ukrywanie treści (ok) od cloakingu (złe). FAQ w <details> jest rekomendowane i jest dobrze rozpoznawane jako Q&A — w Perplexity takie pytania trafiają bezpośrednio do odpowiedzi.
Czy powinienem używać <article> w karcie posta na liście bloga?
Tak. Każda karta z podglądem posta może być <article> — <article> nie oznacza „pełnego artykułu”, oznacza „samodzielną jednostkę treści”. Lista artykułów to <main><div><article>...</article><article>...</article></div></main>.
Czy ARIA landmarks zastępują semantic HTML?
Nie. ARIA to plaster na elementy nie-semantyczne. <div role="navigation"> działa jak fallback, ale <nav> jest lepsze — bo niesie ten sam sygnał bez dodatkowej pracy. Reguła W3C: „First rule of ARIA — don’t use ARIA”. Używaj semantic HTML, ARIA tylko tam, gdzie natywnego tagu nie ma.
Czy powinienem wypełnić atrybut cite w <blockquote>?
Tak, jeśli możesz. <blockquote cite="https://zrodlo.pl/artykul"> daje botowi LLM wyraźny sygnał, skąd pochodzi cytat. Jest to niewidoczny atrybut dla użytkownika, ale bardzo wartościowy dla parsera i dla przypisywania cytowań. Podobnie <cite> dla nazw źródeł.
Microformaty, atrybuty i HTML-level SEO — drobne rzeczy, które się sumują
Obok dużych tagów strukturalnych (<article>, <section>, <h2>) istnieje warstwa mniej spektakularna, ale dająca wymierny boost: mikroatrybuty HTML. To rzeczy, których użytkownik nie widzi, ale parser LLM — tak. Najważniejsze z nich to lang, dir, datetime, cite, title, alt, aria-label, role oraz mikroformaty w klasach (h-entry, p-name, dt-published).
Atrybut lang="pl" na <html> wydaje się oczywistością, ale w WordPressie z multilingual pluginem często jest pomijany albo ustawiony na angielski dla strony, która jest po polsku. Bot LLM, który wyciąga tekst, sprawdza lang, żeby zastosować właściwy tokenizer — zła flaga językowa oznacza gorsze tokenowanie, gorsze embeddings i gorsze cytowalność w zapytaniach polskojęzycznych. Warto to sprawdzić jednym spojrzeniem w view source: pierwsza linia powinna brzmieć <html lang="pl">.
Atrybut datetime w <time> daje bardzo konkretny sygnał świeżości — format ISO 8601 (2026-04-18) jest natywnie rozumiany przez wszystkie parsery. To kluczowe, bo w 2026 rerankery modeli agresywniej filtrują po świeżości: świeży artykuł z <time datetime="2026-04-18"> wygrywa z tym samym contentem bez daty, nawet jeśli obydwa zostały zindeksowane tego samego dnia.
alt w obrazach przestał być „tylko dla dostępności” — stał się pełnoprawnym sygnałem do modeli multimodalnych. Claude-Web i GPT-4o czytają zarówno obraz (jeśli bot ma uprawnienia), jak i alt. Alt powinien być opisowy (nie „zdjęcie”, nie nazwa pliku), najlepiej w formie krótkiego zdania opisującego co jest na obrazie i dlaczego jest w tym artykule. To samo tyczy się <figcaption> — rozbudowany podpis to dodatkowy kontekst.
Mikroformaty typu h-entry (IndieWeb microformats) są niszowe, ale mają swoje znaczenie w społeczności open web i ich parserzy są implementowani w niektórych zewnętrznych narzędziach do retrievalu. Praktycznie dodanie class="h-entry" do <article> i class="p-name" do <h1> jest tanie i nie psuje niczego — jeśli ktoś z tych mikroformatów korzysta, zyskujesz sygnał. Jeśli nie, nic nie tracisz.
Ostatnia warstwa to title na linkach wewnętrznych. W 2026 bot LLM bierze pod uwagę title jako pomocniczy opis celu linka — jeśli masz <a href="/aio/czym-jest-aio-2026/" title="Definicja AIO na 2026">AIO</a>, parser zyskuje kontekst, że ten link prowadzi do definicji. Nie przesadzaj z title (duplikowanie alt nie pomaga), ale tam, gdzie anchor jest krótki i niejednoznaczny, title jest warto.
Jak wdrożenie semantic HTML wygląda w praktyce — mini case study
Żeby nie zostawiać tego na poziomie teorii, spójrzmy na anonimowy, ale realny przykład wdrożenia z pierwszego kwartału 2026. Serwis branżowy, ok. 450 artykułów, motyw premium WordPress sprzed trzech lat, brak <article> i <main> w generowanym HTML. Baseline przed zmianami: 22 cytowań miesięcznie w Perplexity (wyłapane przez rekonstrukcję logów referrer), ok. 3% ruchu organicznego z klientów AIO (ChatGPT, Perplexity, Gemini) łącznie.
Wdrożenie w trzech sprintach. Sprint pierwszy (2 dni): child theme z nadpisanym single.php, page.php, archive.php, header.php i footer.php. Dodanie <article>, <main>, <nav>, <header>, <footer>. Efekt natychmiastowy na wszystkich 450 artykułach. Sprint drugi (3 dni): audyt nagłówków — okazało się, że 40% artykułów miało dwa <h1> (jeden w logo motywu, jeden w tytule). Poprawka w motywie (<h1> w logo zamieniono na <span class="site-title">). Sprint trzeci (tydzień): przepisanie 50 najważniejszych artykułów — FAQ do <details>, tabele do <table>, daty do <time>, cytaty do <blockquote>.
Wyniki po 60 dniach: 41 cytowań miesięcznie w Perplexity (wzrost 86%), 5,2% ruchu z klientów AIO (wzrost 73%). Google organic bez zmian (spadku nie było, wzrostu też nie — to było oczekiwane). Core Web Vitals poprawiły się marginalnie (mniej DOM = minimalnie szybsze parsowanie), ale to efekt uboczny. Głównym zyskiem była widoczność w modelach.
Co ciekawe, przyrost cytowań nie był równomierny. Niektóre artykuły (te z dobrze zbudowanymi tabelami i FAQ) zyskały 3–4x więcej cytowań. Inne — głównie krótkie, 800-słowowe posty — nie zmieniły się wcale. To potwierdza intuicję: semantic HTML jest wzmacniaczem dobrego contentu, nie zastępuje go. Jeśli artykuł jest krótki i nie zawiera nic unikatowego, żaden tag nie uczyni go cytowalnym. Jeśli artykuł ma wartość, semantic HTML mocno podnosi szansę, że zostanie znaleziony i zacytowany.
Koszty wdrożenia: ok. 40 godzin programistycznych (jeden dev + code review), zero nowych treści, zero budżetu na linki. Czas od startu do pierwszych efektów: 3–4 tygodnie (tyle potrzeba botom LLM, żeby ponownie zindeksować zmienioną strukturę i żeby reranker zaczął brać ją pod uwagę). Zwrot z inwestycji: jeden z najwyższych, jakie widzieliśmy w pracy AIO — bo koszty są jednorazowe, a efekt trwa i skaluje się z każdym nowym artykułem napisanym w tym standardzie.
Co dalej — jak wdrożyć semantic HTML u siebie w tym tygodniu?
Jeśli czytasz ten artykuł, prawdopodobnie masz jedno z trzech: blog WordPress z motywem premium, headless WP + Next.js, albo custom SPA. Każde z tych rozwiązań ma własny punkt startowy, ale ta sama zasada: zaczynasz od templatu artykułu, kończysz na FAQ. Dziś możesz otworzyć 10 najważniejszych URL-i, zrobić view source i policzyć <article>, <h1>, <h2>, <nav>, <main>. Jeśli wszystkie są obecne i unikalne, masz fundament. Jeśli nie — wiesz, co poprawić.
W kolejnym kroku warto przygotować checklist wdrożenia na cały zespół: jeden dokument z listą 10 błędów z tego artykułu, przepisany na konkretne reguły Twojego stacku. Developer przy każdym pull request sprawdza, czy nowe elementy spełniają standard. Redakcja przy każdym nowym artykule sprawdza, czy FAQ jest w <details>, a tabele w <table>. Miesiąc tej dyscypliny wystarczy, żeby cały nowy content był czysty, a stary systemowo poprawiał się przy okazji aktualizacji.
Na koniec — mierz efekty. Zanotuj bazową liczbę cytowań w Perplexity / ChatGPT Search na 20 kluczowych zapytań. Po miesiącu powtórz pomiar. Typowy wzrost w naszych case’ach to 20–40% więcej cytowań po samym posprzątaniu struktury, bez dokładania nowych treści i bez kampanii link buildingowych. Semantic HTML to najtańszy kanał AIO, jaki obecnie istnieje — nie wymaga budżetu na narzędzia, nie wymaga tekstów, nie wymaga linków. Wymaga tylko porządku.
Pełna dokumentacja elementów semantycznych dostępna jest w MDN HTML fundamentals, a lista typów schema.org dla publikacji i FAQ — w oficjalnej dokumentacji schema.org. Te dwa źródła wystarczą, żeby utrzymać aktualny standard przez cały 2026 rok.