Jakie są podstawowe zasady tworzenia stron internetowych?

12 zasad tworzenia stron internetowych, które decydują o konwersji i widoczności w Google

Zasady tworzenia stron internetowych sprowadzają się do dwunastu reguł: jasny cel strony, responsywność mobile-first, szybkość ładowania, intuicyjna nawigacja, czytelna typografia, hierarchia wizualna, spójność stylu, skuteczne CTA, optymalizacja SEO, bezpieczeństwo, dostępność cyfrowa i testowanie przed publikacją. Po dziesięciu latach tworzenia stron widzę wyraźny wzorzec: projekty, które działają, opierają się na tych samych fundamentach. Nie decyduje o tym kreatywność ani budżet, tylko konsekwentne stosowanie tych reguł na każdym etapie.

1. Jasny cel strony – witryna realizuje jedną mierzalną akcję: zapytanie, telefon, zakup lub pobranie pliku. Bez tego każda kolejna decyzja projektowa to strzał w ciemno.
2. Responsywność i mobile-first – zaczynam od najmniejszego ekranu i dopiero potem skaluję układ w górę. Google indeksuje wszystkie witryny w trybie mobile-first, więc wersja mobilna jest tą ocenianą.
3. Szybkość ładowania strony – próg to LCP poniżej 2,5 sekundy według dokumentacji Core Web Vitals. Powyżej 4 sekund Google klasyfikuje wynik jako słaby.
4. Intuicyjna nawigacja – menu główne ograniczam do pięciu, maksymalnie siedmiu pozycji. Etykieta „Usługi” działa lepiej niż „Co robimy”, bo nie wymaga interpretacji.
5. Czytelna typografia – minimum 16 px na urządzeniach mobilnych, interlinia 1,5-1,6. Poniżej tych wartości tekst wymaga wysiłku, a użytkownik go pomija.
6. Hierarchia wizualna – rozmiar i grubość prowadzą wzrok od nagłówka do przycisku. Sam kolor hierarchii nie tworzy, bo nie działa dla części odbiorców.
7. Spójność stylu – trzy kolory, dwa kroje pisma, powtarzalny rytm sekcji. Użytkownik przestaje wtedy uczyć się interfejsu i zaczyna czytać treść.
8. Skuteczne CTA i formularze kontaktowe – przycisk nazywa akcję, formularz ma trzy pola. Każde dodatkowe pole to kolejna decyzja do podjęcia.
9. Optymalizacja SEO – jeden H1 na podstronę, unikalne meta tagi, logiczna struktura URL i linkowanie wewnętrzne. Bez tego wyszukiwarka nie rozumie hierarchii witryny.
10. Bezpieczeństwo – certyfikat SSL, aktualne wersje CMS i wtyczek, kopie zapasowe poza serwerem produkcyjnym.
11. Dostępność cyfrowa – zgodność z WCAG 2.2 na poziomie AA. Od 28 czerwca 2025 roku dla wielu usług cyfrowych w Unii Europejskiej to obowiązek prawny, a nie rekomendacja.
12. Testowanie przed publikacją – trzy przeglądarki, fizyczne urządzenia, wysłanie każdego formularza. Jedno niedziałające pole potrafi blokować zapytania tygodniami.

Te dwanaście reguł nie jest jednak równoważne kosztowo i tak je traktuję przy planowaniu budżetu. Zasady 1, 2, 4 i 9 zapadają przed powstaniem pierwszej makiety, a ich późniejsza zmiana oznacza przebudowę projektu. Zasady 5, 6, 7 i 8 poprawiam na działającej stronie w kilka godzin. Zasady 3, 10, 11 i 12 to praca ciągła, która nie kończy się w dniu publikacji. Przy ograniczonym budżecie przenoszę środki na pierwszą grupę, bo tylko tam błąd kosztuje naprawdę dużo. Warto też sprawdzić, które elementy strony internetowej są dziś naprawdę niezbędne, zanim rozbudujesz zakres projektu.

Od czego zacząć projekt strony: cel biznesowy i brief w 7 punktach

Projekt strony zaczynam od określenia jednej mierzalnej akcji, którą użytkownik ma wykonać, i jednej metryki, po której poznamy, że witryna działa. Dopiero potem powstaje mapa podstron, makieta i projekt graficzny. Kolejność odwrotna – najpierw grafika, potem cel – jest w moim doświadczeniu najczęstszą przyczyną serii poprawek wizualnych, które nie zmieniają wyniku biznesowego.

Brief zamyka ten etap i powinien mieścić się na dwóch stronach. Siedem punktów wystarczy:

1. Cel główny – jedna akcja i jedna liczba, na przykład piętnaście zapytań ofertowych miesięcznie. Bez liczby cel pozostaje deklaracją.
2. Grupa docelowa – kto podejmuje decyzję zakupową i jakie ma obiekcje przed kontaktem. To określa treść, nie tylko wygląd.
3. Zakres podstron – lista z podziałem na strony ofertowe, blogowe i systemowe. Zakres wpływa na wycenę bardziej niż jakikolwiek inny punkt.
4. Konkurencja – trzy witryny do analizy wraz z uzasadnieniem wyboru. „Podoba mi się” to za mało, potrzebne jest wskazanie konkretnego rozwiązania.
5. Materiały – logo w wektorze, zdjęcia, teksty, dostępy do domeny i hostingu. Brak materiałów jest najczęstszą przyczyną opóźnień.
6. Integracje – CRM, system rezerwacji, płatności, newsletter. Każda integracja dodana po wdrożeniu kosztuje więcej niż zaplanowana wcześniej.
7. Terminy i budżet – data startu, data publikacji, widełki kwotowe.

Brief bez punktu pierwszego jest tylko listą życzeń. Używam prostego testu: jeśli klient nie potrafi dokończyć zdania „ta strona ma sprawić, że…” jedną akcją i jedną liczbą, cel nie został jeszcze ustalony. W takiej sytuacji nie ma sensu zaczynać projektu graficznego, bo nie da się ocenić, czy jest dobry. Praktyczne rozwinięcie tego etapu opisuję w osobnym materiale o etapach tworzenia strony internetowej, a układ sekcji planuję na makiecie strony internetowej przed projektem graficznym.

Sprawdź także wpis: Cechy dobrej strony internetowej

Jakie progi techniczne musi spełnić strona internetowa w 2026 roku

Strona internetowa powinna spełniać progi Core Web Vitals opublikowane przez Google: LCP poniżej 2,5 sekundy, INP poniżej 200 milisekund i CLS poniżej 0,1. Do tego dochodzą wymagania dostępności z WCAG 2.2 na poziomie AA oraz podstawowe parametry typograficzne. Poniższa tabela zbiera wartości, które sprawdzam w każdym projekcie, wraz ze źródłem każdego progu.

Parametr	Próg docelowy	Wartość słaba	Źródło i narzędzie
LCP – Largest Contentful Paint	≤ 2,5 s	> 4,0 s	Core Web Vitals, Google; PageSpeed Insights
INP – Interaction to Next Paint	≤ 200 ms	> 500 ms	Core Web Vitals, Google; PageSpeed Insights
CLS – Cumulative Layout Shift	≤ 0,1	> 0,25	Core Web Vitals, Google; PageSpeed Insights
Kontrast tekstu do tła	≥ 4,5:1	< 4,5:1	WCAG 2.2, kryterium 1.4.3; WebAIM Contrast Checker
Kontrast dużego tekstu (≥ 24 px)	≥ 3:1	< 3:1	WCAG 2.2, kryterium 1.4.3
Obszar dotykowy elementu	≥ 24 × 24 px (AA)	< 24 × 24 px	WCAG 2.2, kryterium 2.5.8
Zalecany obszar dotykowy	48 × 48 dp	–	Material Design, Google
Rozmiar fontu na mobile	≥ 16 px	< 14 px	Konwencja typograficzna; DevTools
Interlinia tekstu głównego	1,5-1,6	< 1,3	WCAG 2.2, kryterium 1.4.12

Jest jednak różnica, której PageSpeed Insights nie tłumaczy wprost, a która zmienia interpretację wyniku. Narzędzie pokazuje dwa zestawy danych: wynik laboratoryjny z Lighthouse, generowany w symulowanych warunkach, oraz dane terenowe z raportu Chrome User Experience Report, zbierane od realnych użytkowników Chrome. To drugie źródło decyduje o ocenie w Search Console. Strona może mieć wynik Lighthouse 95 i jednocześnie nie przechodzić progów w danych terenowych, bo realni odbiorcy korzystają ze słabszych urządzeń i wolniejszego łącza.

Jeśli wynik laboratoryjny i terenowy się rozjeżdżają, optymalizuję pod dane terenowe. Wynik Lighthouse poprawia się szybciej, ale to raport CrUX Google faktycznie bierze pod uwagę. Dane terenowe potrzebują 28 dni na aktualizację, więc efekt zmian widać dopiero po miesiącu – planuję poprawki z tym wyprzedzeniem, zamiast codziennie odświeżać wynik.

Osobno traktuję czas odpowiedzi serwera, który nie jest metryką Core Web Vitals, ale bezpośrednio ogranicza LCP. W każdym projekcie sprawdzam TTFB i jeśli przekracza 200 ms, rekomenduję zmianę infrastruktury. Jeśli serwer odpowiada po sekundzie, żadna optymalizacja obrazów nie zbije LCP poniżej progu. Techniczne sposoby przyspieszenia opisuję w przewodniku po przyspieszaniu strony na WordPress.

Jaka powinna być szerokość i rozdzielczość strony internetowej?

Szerokość kontenera treści na stronie internetowej mieści się zwykle w przedziale 1140-1280 px, niezależnie od rozdzielczości monitora, a na urządzeniach mobilnych treść zajmuje pełną szerokość ekranu z marginesami bocznymi. Projekt obsługuje przy tym pięć punktów granicznych, w których układ się zmienia.

Breakpoint	Szerokość ekranu	Urządzenie	Zachowanie układu
XS	360-430 px	Smartfon	Jedna kolumna, menu zwinięte
SM	576-767 px	Duży smartfon, tablet pionowo	Jedna kolumna, większe odstępy
MD	768-1023 px	Tablet	Dwie kolumny
LG	1024-1279 px	Laptop	Pełne menu poziome
XL	≥ 1280 px	Monitor	Kontener 1140-1280 px, marginesy boczne

Warto rozróżnić dwa pojęcia, które klienci często mylą. Breakpoint to szerokość ekranu, przy której zmienia się układ. Szerokość kontenera to maksymalna szerokość samej treści. Na monitorze 2560 px kontener nadal ma 1200 px, a reszta to marginesy – i to jest poprawne zachowanie, nie błąd projektowy.

Powód ograniczenia szerokości nie leży w rozdzielczości ekranu, tylko w długości linii tekstu. Matthew Butterick w „Practical Typography” zaleca 45-90 znaków w wierszu jako zakres komfortowy do czytania. Przy szerokości 1200 px i foncie 18 px linia mieści się w tym przedziale. Rozciągnięcie treści na pełną szerokość monitora daje linie po 150 znaków, przy których oko gubi początek następnego wiersza.

Powyższe wartości traktuję jako punkt wyjścia, nie regułę. Rozkład rozdzielczości dla polskiego rynku publikuje StatCounter, ale ważniejsze są dane z konkretnej witryny – raport rozdzielczości ekranu w Google Analytics 4 pokazuje, z czego faktycznie korzystają Twoi odbiorcy. W projektach B2B udział ruchu desktopowego bywa znacznie wyższy niż średnia rynkowa, więc kopiowanie cudzych breakpointów prowadzi do optymalizacji pod urządzenia, których nikt u Ciebie nie używa. Sposoby sprawdzenia tych danych opisuję w materiale o tym, jak sprawdzić ruch na stronie, a samą technikę wdrożenia – w poradniku o tym, jak zrobić responsywną stronę.

Typografia i hierarchia wizualna: jakie rozmiary, interlinia i kontrast zapewniają czytelność

Czytelność zapewnia font o rozmiarze minimum 16 px na urządzeniach mobilnych i 18 px na desktopie, interlinia 1,5-1,6 oraz kontrast tekstu do tła co najmniej 4,5:1, wymagany przez WCAG 2.2 na poziomie AA. Hierarchię buduję rozmiarem i grubością nagłówków, nie kolorem. Na ekranie telefonu użytkownik skanuje, nie czyta, więc H1 musi być wyraźnie większy od H2, a H2 od treści.

W każdym projekcie ograniczam się do dwóch krojów pisma – jeden dla nagłówków, jeden dla treści. To nie jest kwestia gustu. Każdy dodatkowy krój to kolejny plik do pobrania, który opóźnia renderowanie tekstu i wpływa na LCP. Trzy kroje w trzech grubościach oznaczają dziewięć plików fontów na starcie.

Najczęstszy błąd w tym obszarze dotyczy kontrastu. Jasnoszary tekst na białym tle wygląda w projekcie graficznym elegancko, ale zwykle nie przechodzi progu 4,5:1. Raport WebAIM Million, analizujący strony główne witryn pod kątem zgodności z WCAG, od lat wskazuje zbyt niski kontrast tekstu jako jeden z najczęściej wykrywanych błędów. Weryfikacja zajmuje kilkanaście sekund w narzędziu WebAIM Contrast Checker, więc nie ma powodu, żeby ten błąd trafiał na produkcję.

Jest też kryterium, o którym większość projektów zapomina. WCAG 2.2 w punkcie 1.4.12 wymaga, żeby treść nie ginęła, gdy użytkownik samodzielnie zwiększy interlinię do 1,5-krotności rozmiaru fontu, odstęp między akapitami do dwukrotności, odstęp między literami do 0,12 em, a między słowami do 0,16 em. W praktyce oznacza to jedno: kontenery tekstowe nie mogą mieć sztywnej wysokości. Jeśli przycisk lub karta mają ustawioną stałą wysokość w pikselach, tekst przy zwiększonych odstępach zostanie ucięty. Sprawdzam to, wklejając w konsoli przeglądarki style testowe z powyższymi wartościami.

Hierarchię opieram na rozmiarze i grubości, a nie na kolorze, z dwóch powodów. Kolor nie jest odróżnialny dla części użytkowników z zaburzeniami widzenia barw, a dodatkowo sam musi spełniać próg kontrastu, więc paleta szybko się kurczy. Dobór palety opisuję w osobnym materiale o tym, jak dobrać kolorystykę strony internetowej.

Jak zaprojektować przycisk CTA i formularz kontaktowy, żeby strona generowała zapytania

Przycisk CTA powinien nazywać konkretną akcję, kontrastować z paletą strony i być widoczny bez przewijania, a formularz kontaktowy ograniczać się do trzech pól: imienia, adresu e-mail i treści wiadomości. W moich projektach piszę „wyślij wycenę” albo „zamów rozmowę”, nigdy „kliknij tutaj” ani „dowiedz się więcej”. Etykieta ma mówić, co się stanie po kliknięciu.

W jednym projekcie e-commerce, nad którym pracowałem, liczba zapytań podwoiła się po jednej zmianie – przeniesieniu przycisku CTA z dolnej części strony nad linię pierwszego ekranu. Nie zmieniliśmy wtedy ani treści, ani grafiki. Zanim zaczniesz przebudowywać stronę, sprawdź najpierw, gdzie w ogóle znajduje się Twoje główne wezwanie do działania.

Mechanizm stojący za krótkim formularzem jest prostszy, niż sugerują poradniki o konwersji. Każde pole to osobna decyzja: czy podać numer telefonu, czy wpisać nazwę firmy, czy wybrać budżet z listy. Badania Baymard Institute nad użytecznością formularzy konsekwentnie wskazują liczbę i zbędność pól jako jedną z głównych przyczyn porzuceń. Pole, które nie jest potrzebne do przygotowania odpowiedzi, zbieram później – w rozmowie, nie w formularzu.

Na urządzeniach mobilnych o skuteczności formularza decydują detale, których użytkownik nie zauważa świadomie:

• Typ pola – type="email" wyświetla klawiaturę ze znakiem @, type="tel" otwiera klawiaturę numeryczną. Bez tego użytkownik przełącza układy klawiatury ręcznie.
• Atrybut autocomplete – pozwala przeglądarce uzupełnić dane zapisane w profilu. WCAG 2.2 wymaga tego w kryterium 1.3.5 dla pól zbierających dane o użytkowniku.
• Etykieta zamiast placeholdera – tekst w polu znika po kliknięciu, więc użytkownik przestaje wiedzieć, co wpisuje. Etykieta nad polem zostaje widoczna.
• Komunikat po wysłaniu – brak potwierdzenia sprawia, że część osób wysyła formularz drugi raz albo uznaje, że nie zadziałał.

Kolor przycisku dobieram jako kontrastowy do głównej palety, nie jako jej element. Jeśli projekt opiera się na tonach niebieskich, przycisk CTA jest pomarańczowy lub zielony. Kolejny odcień niebieskiego zlewa się z tłem, choć w makiecie wygląda spójnie. Techniczne wdrożenie opisuję w instrukcji, jak dodać formularz kontaktowy na stronę.

Które zasady projektowania stron realnie wpływają na pozycję w Google

Spośród dwunastu zasad na pozycję w wynikach wyszukiwania wpływają bezpośrednio cztery: responsywność, Core Web Vitals, HTTPS oraz struktura treści i linkowania wewnętrznego. Pozostałe działają pośrednio – poprawiają zachowanie użytkowników i konwersję, ale Google nie potwierdził ich jako czynników rankingowych. To rozróżnienie ma znaczenie praktyczne, bo pozwala nie wydawać budżetu SEO na rzeczy, które SEO nie są.

Zasada	Wpływ na ranking	Podstawa
Responsywność, wersja mobilna	Bezpośredni	Google indeksuje wszystkie witryny w trybie mobile-first
Core Web Vitals	Bezpośredni, ale słabszy niż trafność treści	Element sygnałów page experience wg Google Search Central
HTTPS i certyfikat SSL	Bezpośredni, lekki	Google potwierdził HTTPS jako sygnał rankingowy
Struktura nagłówków, URL, linkowanie wewnętrzne	Bezpośredni	Wpływa na indeksowanie i rozumienie hierarchii witryny
Dostępność cyfrowa (WCAG)	Pośredni	Semantyczny kod i alt-teksty ułatwiają interpretację treści
Typografia, hierarchia wizualna, spójność stylu	Pośredni	Wpływ na zachowanie użytkownika, brak potwierdzonego sygnału
Projekt CTA i formularzy	Brak	Wpływa na konwersję, nie na pozycję
Animacje, mikrointerakcje	Brak, może szkodzić	Obciążają INP, jeśli blokują wątek główny

Google w dokumentacji Search Central wyjaśnia przy tym, że nie istnieje jeden zbiorczy „sygnał page experience”, a doświadczenie użytkownika oceniane jest przez zestaw powiązanych czynników. Mój wniosek praktyczny jest taki: strona z doskonałymi Core Web Vitals i słabą treścią nie wyprzedzi strony z gorszymi wynikami technicznymi i lepszą odpowiedzią na zapytanie. Wydajność rozstrzyga między stronami o podobnej trafności, a nie zastępuje trafności.

Dlatego optymalizację techniczną traktuję jako warunek konieczny, a nie wystarczający. Jeśli witryna nie pojawia się w wynikach mimo poprawnych parametrów, przyczyna leży zwykle w indeksowaniu albo w dopasowaniu treści do intencji – te scenariusze opisuję w materiale o tym, dlaczego strona nie jest widoczna w Google. Sposób planowania hierarchii podstron pokazuję z kolei w artykule o tym, jak zaprojektować strukturę strony internetowej.

Które zasady projektowania stron straciły aktualność i w co nie warto już inwestować

Część reguł powtarzanych w poradnikach o projektowaniu stron przestała obowiązywać, a niektóre nigdy nie miały potwierdzenia w badaniach. Poniższe zestawienie porządkuje, co się zmieniło i co robię zamiast.

Dawna zasada	Status w 2026 roku	Co robić zamiast
Zasada trzech kliknięć	Nigdy nie potwierdzona badaniami	Mierzyć, czy ścieżka jest zrozumiała, nie ile ma kroków
Wszystko ważne nad linią pierwszego ekranu	Zdezaktualizowana	Traktować pierwszy ekran jako odpowiedź „gdzie jestem”, resztę rozłożyć niżej
Dane strukturalne FAQPage i HowTo dla rich results	Google mocno ograniczył ich wyświetlanie w 2023 roku	Wdrażać Article i BreadcrumbList, FAQ pisać dla czytelnika
Optymalizacja pod FID	Metryka zastąpiona przez INP w marcu 2024	Mierzyć INP i ograniczać długie zadania JavaScript
Osobna wersja mobilna w subdomenie	Relikt sprzed indeksowania mobile-first	Jedna responsywna witryna pod jednym adresem
Dostępność jako dobra praktyka	Obowiązek prawny w UE od 28 czerwca 2025	Traktować WCAG 2.2 AA jako wymóg, nie opcję

Dwa punkty wymagają komentarza. Zasada trzech kliknięć weszła do obiegu jako reguła projektowa, choć test przeprowadzony przez User Interface Engineering nie wykazał zależności między liczbą kliknięć a skutecznością odnalezienia informacji. Użytkownicy rezygnują nie po trzecim kliknięciu, tylko wtedy, gdy przestają rozumieć, dokąd prowadzi kolejny krok. Sama liczba kroków jest więc wskaźnikiem zastępczym – wygodnym, ale mylącym.

Zmiana statusu dostępności cyfrowej to moim zdaniem najbardziej niedoceniana różnica między rokiem 2023 a dziś. European Accessibility Act, czyli dyrektywa 2019/882, obowiązuje od 28 czerwca 2025 roku i obejmuje szeroki katalog usług cyfrowych świadczonych konsumentom w Unii Europejskiej. W Polsce wdrożono ją ustawą o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług. Zakres obowiązku zależy od rodzaju działalności i wielkości firmy, więc warto sprawdzić go dla konkretnego przypadku – praktyczne wymagania opisuję w materiale o dostosowaniu strony internetowej do potrzeb osób niepełnosprawnych.

Jeśli Twoja witryna powstała przed 2023 rokiem, prawdopodobnie zawiera co najmniej dwie pozycje z powyższej tabeli. Zakres i sens takich prac porządkuję w artykule o modernizacji strony internetowej.

7 błędów, które najczęściej łamią zasady tworzenia stron i jak je wykryć

Najczęstsze błędy, które widzę przy audytach, nie wynikają z braku wiedzy, tylko z pominięcia weryfikacji. Poniższa tabela zestawia siedem powtarzalnych problemów wraz ze skutkiem i konkretnym sposobem sprawdzenia ich na własnej stronie.

Błąd	Skutek	Jak wykryć
Grafiki bez kompresji, w formacie PNG lub JPG	LCP powyżej progu, wolne ładowanie na mobile	PageSpeed Insights, sekcja z możliwościami optymalizacji
Brak wymiarów obrazów i osadzonych ramek w kodzie	Przeskakiwanie układu, wysoki CLS	PageSpeed Insights, diagnostyka CLS
Przycisk CTA dopiero w stopce	Użytkownik nie znajduje ścieżki do kontaktu	Mapa kliknięć i nagrania sesji
Menu odwzorowujące strukturę firmy, nie potrzeby odbiorcy	Wydłużona ścieżka do oferty	Screaming Frog, raport głębokości podstron
Ten sam meta title na wielu podstronach	Konkurowanie własnych podstron o tę samą frazę	Google Search Console, raport skuteczności z podziałem na strony
Nieaktualizowane wtyczki i motyw	Podatność na znane luki bezpieczeństwa	Panel WordPress, bazy podatności wtyczek
Brak obsługi klawiaturą i widocznego fokusu	Niezgodność z WCAG 2.2 AA	Ręczne przejście klawiszem Tab przez całą stronę

Zwracam uwagę na jedną prawidłowość. Pięć z siedmiu powyższych błędów wykrywa się darmowym narzędziem w kilka minut, a mimo to trafiają one na produkcję, bo nikt nie uruchomił testu po wdrożeniu. Automatyczne skanery dostępności, takie jak axe DevTools, wykrywają część naruszeń WCAG, ale nie ocenią, czy komunikat błędu w formularzu jest zrozumiały ani czy kolejność fokusu ma sens. Dlatego przechodzę całą stronę klawiszem Tab ręcznie i sprawdzam, czy fokus jest widoczny na każdym przycisku i linku. Zajmuje to trzy minuty i wyłapuje to, czego skaner nie zobaczy.

Dwa błędy z tabeli mają charakter operacyjny, nie projektowy – dotyczą tego, co dzieje się po publikacji. Aktualizuję WordPress, wtyczki i motywy w ciągu 48 godzin od nowego wydania, a kopie zapasowe ustawiam na cykl dzienny z przechowywaniem ostatnich 30 wersji poza serwerem produkcyjnym. Regularne aktualizacje strony na WordPress i działająca kopia zapasowa strony internetowej nie poprawią konwersji, ale są jedyną rzeczą, która ratuje witrynę po udanym ataku.

Kiedy standardowe zasady nie obowiązują: landing page, one page i sklep internetowy

Trzy typy witryn świadomie łamią część zasad opisanych wyżej i w ich przypadku uważam to za decyzję poprawną. Landing page rezygnuje z nawigacji, one page spłaszcza hierarchię treści, a sklep internetowy nie zmieści procesu zakupowego w trzech polach formularza. Poniżej konkretne odstępstwa i ich uzasadnienie.

• Landing page kampanijny – usuwam menu główne celowo, żeby użytkownik nie miał gdzie odejść przed wykonaniem akcji. Zasada intuicyjnej nawigacji ustępuje tu zasadzie jednej ścieżki, a jedynym wyjściem jest przycisk CTA.
• Strona one page – cała treść mieści się na jednym adresie, więc nie da się zbudować hierarchii podstron ani rozdzielić fraz kluczowych między osobne URL-e. To akceptowalne przy jednej usłudze i jednej grupie odbiorców, ale ogranicza rozwój witryny w wyszukiwarce.
• Sklep internetowy – mega menu z kilkudziesięcioma linkami jest tu uzasadnione, bo kategorie produktowe muszą być dostępne z każdego miejsca. Na stronie firmowej z dziesięcioma podstronami to samo rozwiązanie jest przerostem formy.
• Serwis wewnętrzny lub panel klienta – nie konkuruje w wyszukiwarce, więc zasady SEO tracą zastosowanie. Priorytetem stają się dostępność i szybkość działania przy powtarzalnych operacjach.

Zasada, od której nie robię wyjątków, jest tylko jedna: dostępność cyfrowa. Ograniczenia prawne wynikające z European Accessibility Act nie zależą od typu witryny, tylko od rodzaju świadczonej usługi. Landing page kampanijny podlega tym samym wymaganiom co rozbudowany serwis.

Przed wyborem formatu radzę porównać, co dany typ witryny umożliwia w perspektywie dwóch lat. Strona one page zamówiona „na start” bywa najdroższym rozwiązaniem, jeśli po roku trzeba ją przebudować na serwis wielopodstronowy. Zestawienie formatów zawiera artykuł o rodzajach stron internetowych.

Jak sprawdzić, czy wykonawca zastosował zasady tworzenia stron: checklista odbioru

Odbiór strony sprowadza się do dwunastu punktów, które klient może zweryfikować samodzielnie, bez wiedzy technicznej i przed zapłatą ostatniej faktury. Wszystkie wymagają wyłącznie przeglądarki i dwóch darmowych narzędzi: PageSpeed Insights oraz Google Search Console. To ta sama lista, którą przechodzę przed publikacją własnych projektów.

1. Core Web Vitals na mobile – sprawdź trzy podstrony w PageSpeed Insights: główną, ofertę i kontakt. Progi to LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1.
2. Wyświetlanie na fizycznym telefonie – otwórz stronę na własnym urządzeniu, nie w emulatorze. Emulatory nie wyłapują problemów z opóźnieniem dotyku ani z renderowaniem fontów.
3. Formularze – wyślij każdy formularz kilka razy i sprawdź, czy wiadomość doszła oraz czy pojawiło się potwierdzenie na stronie.
4. Wyświetlanie w trzech przeglądarkach – Chrome, Safari i Firefox, osobno w wersji desktopowej i mobilnej.
5. Certyfikat SSL – adres zaczyna się od https, przeglądarka nie wyświetla ostrzeżenia.
6. Unikalne meta tagi – poproś o listę tytułów i opisów wszystkich podstron. Duplikaty są tu najczęstszym uchybieniem.
7. Jeden H1 na podstronę – sprawdzisz to wtyczką do podglądu nagłówków albo w kodzie źródłowym.
8. Teksty alternatywne obrazów – wyrywkowo, na trzech podstronach.
9. Obsługa klawiaturą – przejdź całą stronę klawiszem Tab. Fokus musi być widoczny na każdym linku i przycisku.
10. Kontrast tekstu – sprawdź główny tekst i etykiety w WebAIM Contrast Checker, próg to 4,5:1.
11. Sitemap XML, robots.txt i brak błędów 404 – mapa witryny zgłoszona w Google Search Console, robots.txt nie blokuje zasobów potrzebnych do renderowania, raport ze skanu linków wewnętrznych bez błędów.
12. Dostępy i kopia zapasowa – dostęp administratora do CMS, panelu hostingu i domeny po Twojej stronie oraz działający harmonogram kopii.

Punkt dwunasty bywa pomijany, a decyduje o tym, czy strona rzeczywiście należy do Ciebie. Domena zarejestrowana na wykonawcę, hosting na jego koncie i brak dostępu administratora sprawiają, że każda przyszła zmiana wymaga jego zgody. To kwestia do ustalenia w umowie, nie w dniu odbioru.

Jeśli miałbym wskazać trzy rzeczy do sprawdzenia przed zapłatą końcową, wybrałbym: wysłanie formularza z potwierdzeniem odbioru wiadomości, wynik Core Web Vitals na urządzeniu mobilnym oraz komplet dostępów do domeny, hostingu i CMS. Dwa pierwsze błędy kosztują utracone zapytania, trzeci potrafi zablokować rozwój witryny na lata.

Ta checklista nie zastępuje pełnej analizy technicznej – pokazuje jedynie, czy podstawy zostały dopilnowane. Szerszy zakres weryfikacji opisuję w materiale o tym, jak przeprowadzić audyt strony internetowej, a kryteria wyboru samego wykonawcy – w artykule o tym, jak wybrać wykonawcę strony internetowej. Jeśli wolisz, żeby te dwanaście punktów było spełnione od pierwszego dnia, zamiast weryfikować je po fakcie, tym właśnie różni się tworzenie stron internetowych dla firm prowadzone według checklisty od projektu robionego „na oko”.