HTML - popraw semantykę i SEO strony!

Przy bardziej złożonych widokach, na przykład w sklepie internetowym, do

Kiedy

wygrywa z

,

i

Najwięcej błędów widzę wtedy, gdy

jest używany jak uniwersalny kontener. To zły nawyk, bo semantyka HTML przestaje wtedy opisywać znaczenie treści, a zaczyna tylko obsługiwać wygląd. Ja wolę od razu rozdzielić role elementów, bo później łatwiej utrzymać kod i prostsza jest współpraca między frontendem, contentem i SEO technicznym.

Element	Główna rola	Kiedy używam	Czego unikać
	Główna treść dokumentu	Gdy chcesz wskazać centralny obszar strony	Nie używaj go do opakowania całego layoutu
	Tematyczna sekcja treści	Gdy dzielisz zawartość na logiczne bloki	Nie zastępuj nim głównego obszaru strony
	Samodzielna jednostka treści	Gdy element może istnieć niezależnie, np. wpis, komentarz, karta	Nie stosuj go tylko dlatego, że „ładnie brzmi”
	Neutralny kontener	Gdy potrzebujesz wyłącznie opakowania technicznego	Nie licz na znaczenie semantyczne
role="main"	Landmark ARIA	Jako wyjątek, gdy nie możesz użyć	Nie traktuj go jako domyślnego zamiennika

W praktyce najczęściej łączę te elementy w jednym schemacie:

wyznacza główny obszar, wewnątrz niego

opisuje konkretny wpis lub produkt, a

porządkuje powiązane fragmenty treści. Taki układ działa lepiej niż „wszystko w divach”, bo od razu komunikuje intencję kodu. A kiedy semantyka jest już ustawiona, warto sprawdzić, jak wspiera ona dostępność.

Dlaczego ma znaczenie dla dostępności i nawigacji

To właśnie tutaj

pokazuje swoją największą wartość. Dla osoby korzystającej z czytnika ekranu jest to sygnał, że znalazła się w najważniejszej części dokumentu, bez konieczności przedzierania się przez menu, bannery i powtarzalne bloki. Tego nie załatwia sam wygląd strony; potrzebna jest semantyka, którą technologia asystująca potrafi odczytać.

Ja bardzo często dodaję też link „Przejdź do treści głównej” na początku dokumentu. W połączeniu z

pozwala to ominąć powtarzalną nawigację klawiaturą i skraca drogę do sedna strony. To drobny zabieg, ale w praktyce robi dużą różnicę na dłuższych serwisach i w sklepach z rozbudowanym menu.

• czytniki ekranu szybciej znajdują główny obszar;
• użytkownicy klawiatury mogą przeskoczyć powtarzalne elementy;
• struktura dokumentu staje się czytelniejsza przy testach i refaktorze;
• zespoły contentowe łatwiej rozumieją, co jest treścią centralną, a co dodatkiem.

Jeżeli budujesz aplikację jednostronicową, pilnuj jeszcze jednego szczegółu: po zmianie widoku powinien być aktywny tylko jeden logiczny obszar treści. Dwa widoczne elementy pełniące rolę main szybko wprowadzają chaos, szczególnie gdy interfejs przełącza się bez pełnego przeładowania strony. Najczęściej jednak problemy pojawiają się nie w teorii, tylko przy wdrażaniu i refaktorze.

Najczęstsze błędy, które psują sens tego elementu

W mojej praktyce te pomyłki wracają najczęściej, niezależnie od tego, czy pracuję nad blogiem, sklepem czy panelem administracyjnym. Dobra wiadomość jest taka, że większość z nich da się wyłapać jeszcze na etapie przeglądu markup-u, zanim problem trafi do produkcji.

1. Owijanie całego układu w
   - jeśli w środku lądują nagłówek, nawigacja, stopka i treści pomocnicze, semantyka przestaje mieć sens.
2. Umieszczanie wielu widocznych
   na jednej stronie - to częsty błąd w szablonach i komponentach, które były składane niezależnie.
3. Wpychanie do niego elementów globalnych - cookie banner, stały pasek promocyjny czy powtarzalny sidebar zwykle nie są treścią główną.
4. Zastępowanie semantyki zwykłym divem - kod nadal działa wizualnie, ale traci znaczenie dla narzędzi dostępności.
5. Ignorowanie wyjątków - jeśli na stronie główną funkcją jest wyszukiwanie, formularz może być częścią centralnego obszaru, ale tylko dlatego, że faktycznie jest osią strony.

Najlepszy test, jaki stosuję, jest banalny: pytam, czy użytkownik bez wahania wskazałby ten fragment jako najważniejszą treść danej podstrony. Jeśli odpowiedź brzmi „nie”, to zwykle nie powinien tam być

. Takie kryterium szybko prostuje nawet rozbudowane layouty. Kiedy to działa, zostaje już tylko ułożenie prostego wzorca, który można przenosić między projektami.

Najbezpieczniejszy wzorzec, który stosuję w projektach

Gdy potrzebuję prostego i odpornego na błędy układu, idę w schemat: jedna strona, jeden główny obszar treści, reszta jako otoczenie. To działa dobrze w serwisach contentowych, sklepach i aplikacjach, bo oddziela to, co użytkownik ma czytać albo obsługiwać, od elementów wspólnych dla całego interfejsu.

• blog i portal:
  obejmuje wpis lub listing wraz z elementami bezpośrednio związanymi z treścią;
• e-commerce:
  mieści produkt, koszyk albo kategorię, jeśli to one są celem wejścia;
• SaaS i dashboard:
  przejmuje bieżący ekran roboczy, a nie cały shell aplikacji;
• landing page:
  skupia ofertę, argumenty, CTA i sekcje prowadzące do decyzji.

Jeżeli chcesz zapamiętać tylko jedną rzecz, niech będzie prosta:

nie opisuje wyglądu strony, tylko jej sens. Kiedy ten podział jest dobrze ustawiony, kod staje się czytelniejszy, a użytkownik szybciej dociera do tego, po co naprawdę wszedł na stronę.