HTML i CSS — co widzicie, kiedy otwieracie kod swojej strony

Ten tekst nie nauczy Was pisać stron. Jest po to, żeby słowa padające w ofertach i w rozmowach z wykonawcą przestały być hasłami, a zaczęły być rzeczami, o które da się zapytać.

HTML, CSS, semantyka, kod źródłowy, struktura nagłówków — wszystkie oznaczają coś konkretnego, a część z nich wprost przekłada się na to, ile zapłacicie za zmiany za rok.

Trzy warstwy, z których zbudowana jest każda strona

Każda strona internetowa — niezależnie od tego, na czym stoi — składa się z trzech warstw, które robią trzy różne rzeczy.

HTML to treść i jej struktura. Mówi, co jest nagłówkiem, co akapitem, co listą, a co odnośnikiem. Nie mówi, jak to ma wyglądać — mówi, czym to jest. To jest warstwa, którą czyta wyszukiwarka i czytnik ekranu osoby niewidomej.

CSS to wygląd. Kolory, odstępy, kroje pisma, siatka, zachowanie na małym ekranie. Ta sama treść w HTML może wyglądać zupełnie inaczej w zależności od CSS — i to jest cała idea rozdzielenia tych dwóch warstw.

JavaScript to zachowanie. Wszystko, co dzieje się po wczytaniu strony: reakcja na kliknięcie, filtrowanie, kalkulator, formularz wysyłany bez przeładowania. Rozkładamy to osobno, przy wyborze technologii frontendowej.

Podział ma praktyczną konsekwencję: każda z tych warstw to inna rozmowa z wykonawcą, a pierwsza z nich jest w większości Waszą decyzją, nie jego.

Jak zobaczyć kod własnej strony — i dwie rzeczy, które sprawdzicie sami

Nie trzeba umieć czytać kodu, żeby sprawdzić w nim dwie rzeczy, które decydują o tym, czy strona jest widoczna w wyszukiwarce.

Otwórzcie kod źródłowy. W przeglądarce, na swojej stronie: prawy przycisk myszy i „Pokaż źródło strony" albo skrót Ctrl+U (na Macu Option+Cmd+U). Otworzy się zakładka z tekstem — to jest dokładnie to, co serwer wysłał przeglądarce i co pobiera robot wyszukiwarki. Nie mylcie tego z „Zbadaj element", które pokazuje stan po uruchomieniu skryptów, czyli obraz, którego robot przy pierwszym przejściu nie widzi.

Sprawdzenie pierwsze: czy jest tam Wasza treść. Wciśnijcie Ctrl+F i poszukajcie dowolnego zdania ze swojej strony. Jeśli się znajduje — treść jest w pierwszej odpowiedzi i wyszukiwarka ma co indeksować od razu. Jeśli plik ma kilkanaście linijek i same odwołania do skryptów, treść powstaje dopiero w przeglądarce, a to opóźnia indeksację o dni albo tygodnie. Mechanizm, który za tym stoi, opisujemy przy Next.js i Reakcie.

Sprawdzenie drugie: czy strona ma opisy dla wyszukiwarki. W tym samym widoku poszukajcie <title> i meta name="description". Pierwszy to tytuł, który Google wyświetla w wynikach; drugi to opis pod nim. Jeśli title jest na wszystkich podstronach taki sam, brzmi „Strona główna" albo w ogóle go nie ma — płacicie za stronę, która w wynikach wyszukiwania przedstawia się byle jak. To jest pięć sekund pracy i jedna z najczęstszych rzeczy, jakie zastajemy przy audytach.

Obie te rzeczy warto sprawdzić także na kilku podstronach, nie tylko na głównej — bo problem zwykle zaczyna się od drugiej.

Dlaczego nagłówki to nie jest kwestia wielkości liter

To jest najczęstsze nieporozumienie na styku warstw i zarazem najdroższe w skutkach.

Nagłówki — H1, H2, H3 — nie są stylami tekstu. Są szkieletem dokumentu. H1 to tytuł książki, H2 to tytuły rozdziałów, H3 to podrozdziały wewnątrz nich. Wyszukiwarka czyta tę hierarchię, żeby zrozumieć, o czym jest strona i która część odpowiada na jakie pytanie.

Co się psuje, gdy używa się ich do wyglądu. Ktoś chce, żeby fragment był mniejszy i pogrubiony, więc wpisuje go jako H3. Z punktu widzenia struktury właśnie ogłosił, że zaczyna się nowy podrozdział — którego nie ma. Przy kilkunastu takich miejscach strona ma szkielet, który nie odpowiada niczemu.

Kto na tym traci najbardziej. Nie Google — osoba korzystająca z czytnika ekranu. Takie osoby nawigują po stronie skacząc między nagłówkami, dokładnie tak, jak Wy przewijacie wzrokiem. Lista nagłówków jest dla nich spisem treści. Jeśli w tym spisie treści są pozycje, które nie zaczynają żadnej sekcji, poruszanie się po stronie robi się zgadywanką.

Zasada jest prosta i warto ją przekazać osobie redagującej treść: nagłówek mówi, czym jest ten tekst. Jeśli chodzi Wam o to, żeby był mniejszy albo pogrubiony — to jest zadanie dla CSS, nie dla znacznika. Ta sama zasada obowiązuje przy wymaganiach dostępności cyfrowej, które rozkładamy osobno w tekście o WCAG.

Semantyka, czyli reszta rzeczy, które mówią „czym to jest"

Nagłówki są najbardziej widocznym przykładem, ale ta sama zasada dotyczy kilku innych miejsc — i w każdym z nich pomyłka kosztuje tak samo.

Lista, która nie jest listą. Punkty rozdzielone myślnikami w akapicie wyglądają jak lista i nią nie są. Czytnik ekranu nie powie „lista, pięć pozycji", tylko przeczyta jeden długi akapit z myślnikami w środku. Wyszukiwarka też widzi wtedy ciągły tekst, a nie wyliczenie.

Przycisk, który jest odnośnikiem, i odnośnik, który jest przyciskiem. Różnica nie jest kosmetyczna: odnośnik prowadzi w inne miejsce, przycisk coś wykonuje. Element zrobiony „nie tak" bywa nieosiągalny z klawiatury, co dla części użytkowników oznacza, że po prostu nie działa.

Opis alternatywny obrazu. To jedno pole przy zdjęciu, które opisuje, co na nim jest. Czyta je czytnik ekranu i wyszukiwarka grafik, a widzi je każdy, komu obraz się nie wczytał. To jest pole, którego nie wypełni za Was wykonawca — bo tylko Wy wiecie, czy na zdjęciu jest „zespół" czy „nasza hala produkcyjna w Gliwicach".

Język strony. Jedna informacja w kodzie mówiąca, że strona jest po polsku. Bez niej syntezator mowy potrafi czytać polski tekst z angielską wymową — brzmi to dokładnie tak źle, jak sobie wyobrażacie.

Wszystkie cztery rzeczy mają wspólny mianownik: kosztują zero, jeśli zrobi się je od razu, i są żmudną poprawką, jeśli trzeba je nanieść na gotowej stronie. Warto je mieć w umowie jako wymaganie, a nie w zgłoszeniu po odbiorze.

Dlaczego zmiana koloru przycisku raz kosztuje pięć minut, a raz tydzień

Tu CSS przestaje być tematem technicznym, a staje się pozycją w Waszym budżecie.

Wersja tania. Dobrze napisany CSS trzyma decyzje wizualne w jednym miejscu, jako nazwane wartości: kolor główny, kolor akcentu, rozmiar tekstu, odstęp. Wszystkie przyciski, nagłówki i ramki odwołują się do tych nazw, zamiast powtarzać konkretną wartość. Zmiana koloru marki to wtedy jedna edycja w jednym pliku.

Wersja droga. Kolor wpisany „na sztywno" w każdym miejscu, w którym się pojawia — w stu miejscach w kodzie, plus w kilkunastu wtyczkach, plus w treści wpisanej przez redakcję. Zmiana wymaga znalezienia wszystkich wystąpień, poprawienia każdego i sprawdzenia, czy nic nie zostało pominięte. Tygodnie tu nie biorą się ze złożoności, tylko z liczby miejsc.

Jak to wygląda u nas. Ten serwis ma 164 nazwane wartości — kolory, rozmiary tekstu, odstępy, warianty jasny i ciemny — zdefiniowane w jednym pliku, w 315 deklaracjach obsługujących różne motywy (policzone 11 września 2026). Zmiana koloru akcentu w całym serwisie, razem z trybem ciemnym, to jedna linijka.

Pytanie, które warto zadać przy odbiorze strony: „gdzie są zdefiniowane kolory i kroje pisma i ile miejsc trzeba zmienić, żeby zmienić kolor marki". Odpowiedź „w jednym pliku, w zmiennych" znaczy, że płacicie za kod, który da się utrzymywać. Odpowiedź wymijająca zwykle znaczy, że każda przyszła zmiana będzie wyceniana od nowa.

To samo dotyczy krojów pisma, odstępów i punktów, w których układ przełamuje się na telefonie. Jakość CSS nie jest widoczna na ekranie — jest widoczna na fakturze za drugą zmianę.

Co się dzieje, gdy strona trafia na telefon

Responsywność bywa w ofertach jednym punktem, jakby była przełącznikiem. Nie jest — to jest zestaw decyzji o tym, co się dzieje z układem, gdy ekran robi się węższy, i część z tych decyzji należy do Was.

Na dużym ekranie trzy kolumny stoją obok siebie. Na telefonie muszą stanąć jedna pod drugą — i wtedy zapada pytanie, w jakiej kolejności. To nie jest pytanie techniczne: na telefonie użytkownik zobaczy najpierw to, co postawicie na górze, a reszty może nie doczytać. Ta sama uwaga dotyczy tabel, które na wąskim ekranie albo się zwijają, albo przewijają w bok, albo przestają być czytelne.

Trzy rzeczy, które warto sprawdzić samemu na własnym telefonie, zanim odbierzecie stronę:

• Czy da się wykonać najważniejszą czynność jednym kciukiem — znaleźć ofertę, otworzyć formularz, wysłać.
• Czy coś ucieka poza ekran w bok. Jeśli strona przesuwa się na boki, gdzieś jest element szerszy niż ekran; to jest błąd, nie cecha.
• Czy tekst jest czytelny bez powiększania i czy przyciski da się trafić palcem, a nie tylko kursorem.

To są te same sprawdzenia, które robimy przy audytach — i wypadają gorzej niż wszyscy zakładają, bo stronę projektuje się na monitorze, a ogląda na telefonie.

Co z tego jest Waszą decyzją, a co wykonawcy

Podział, który proponujemy klientom i który u nas działa:

Wasze: teksty i to, co nimi jest — co jest tytułem strony, co nagłówkiem sekcji, co zwykłym akapitem. Opisy alternatywne obrazów, bo tylko Wy wiecie, co jest na zdjęciu i po co ono tam stoi. Tytuły i opisy dla wyszukiwarki, bo to jest komunikat marketingowy, a nie ustawienie techniczne.

Wspólne: hierarchia treści na stronie i to, które informacje są najważniejsze — wykonawca podpowiada, jak to wyrazić, ale kolejność wynika z tego, co sprzedajecie.

Wykonawcy: wszystko, co pod spodem — jak kod jest zorganizowany, gdzie siedzą zmienne, jak strona zachowuje się na wolnym łączu, jak działają skrypty.

Granica jest w jednym miejscu: jeśli decyzja dotyczy znaczenia treści, jest Wasza; jeśli dotyczy sposobu jej wykonania, jest jego. Większość sporów przy odbiorze strony bierze się z tego, że ktoś przekroczył tę linię w którąś stronę.

Czego nie musicie umieć

Nie musicie umieć pisać HTML-a, żeby zamówić dobrą stronę — tak jak nie wylewacie sami fundamentów pod własne biuro. Musicie umieć zadać cztery pytania i sprawdzić dwie rzeczy w kodzie źródłowym, co zajmuje łącznie kilka minut.

Jeśli mimo to chcecie spróbować sami — bo testujecie pomysł, bo lubicie rozumieć rzeczy od środka albo bo strona ma być hobbystyczna — mamy na to osobny tekst: jak zrobić prostą stronę w HTML. To jest inna droga i nie udajemy, że nie istnieje.

Pięć słów z ofert, przetłumaczonych

Semantyczny HTML — kod, w którym znaczniki opisują, czym treść jest, a nie jak wygląda. To, o czym jest cały ten tekst.

Walidacja — sprawdzenie, czy kod jest poprawnie zbudowany. Przydatne, ale samo w sobie nie mówi nic o jakości strony: można mieć kod bezbłędny formalnie i bezużyteczny w praktyce.

Punkt przełamania (breakpoint) — szerokość ekranu, przy której układ się zmienia. Im ich mniej i im lepiej dobrane, tym mniej miejsc, w których strona wygląda dziwnie.

System projektowy (design system) — zbiór nazwanych decyzji wizualnych, o którym mowa wyżej: kolory, odstępy, kroje pisma w jednym miejscu. W ofercie oznacza, że wykonawca zamierza pisać kod, który da się utrzymywać.

Minifikacja — usunięcie z plików wszystkiego, co jest tam dla człowieka, a nie dla przeglądarki. Standard, nie przewaga; jeśli ktoś wpisuje to jako osobną korzyść, warto zapytać, co jeszcze jest w tej ofercie standardem.

Cztery pytania do wykonawcy

1. Czy treść jest w kodzie strony przy pierwszej odpowiedzi serwera? Odpowiedź sprawdzicie sami, Ctrl+U.
2. Czy każda podstrona ma własny tytuł i opis dla wyszukiwarki? To samo miejsce, Ctrl+F.
3. Czy nagłówki opisują strukturę treści, czy tylko wielkość liter? Pytanie, które osobie redagującej treść oszczędza późniejszej poprawki wszystkiego naraz.
4. Gdzie zdefiniowane są kolory i kroje pisma? Jedno miejsce czy sto — to jest cena każdej przyszłej zmiany wizualnej.

Skąd te liczby

• 164 nazwane wartości w 315 deklaracjach — policzone w pliku stylów globalnych tego serwisu 11 września 2026.
• Wolumeny fraz — Keyword Planner, Polska, pull z 11 września 2026: html co to 720, css co to 320, struktura strony internetowej 90, semantyka html 90, kod źródłowy strony 70.
• Czego tu świadomie nie ma — listy znaczników HTML. Rodzina znaczniki html ma razem około 1 240 wyszukań miesięcznie, ale jest ściągą dla osoby piszącej kod, a nie dla firmy zamawiającej stronę; obsłużenie jej znaczyłoby napisanie dokumentacji, która istnieje i jest lepsza.