Przed publikacją nowej strony firmowej sprawdź nie tylko wygląd, ale przede wszystkim działanie kluczowych ścieżek: wersję mobilną, formularze, telefon, SSL, szybkość, indeksację, zgody, cookies, politykę prywatności, analitykę i podstawową dostępność. Jeśli w dniu startu zmieniasz domenę, DNS albo przekierowania, potraktuj konfiguracja domeny jako osobny punkt odbioru, bo błąd w tym miejscu może zablokować stronę, pocztę albo certyfikat.
Najprostsza decyzja jest taka: publikuj, gdy użytkownik może wejść na stronę, zrozumieć ofertę, skontaktować się z firmą, a Ty masz podstawowy pomiar po starcie. Nie trzeba czekać na idealny tekst w każdej sekcji, ale nie warto uruchamiać strony, która nie działa na telefonie, nie wysyła formularza, pokazuje ostrzeżenie SSL albo jest zablokowana przed indeksowaniem.
Przy założeniu strony internetowej najgorszy moment na wykrywanie błędów to pierwszy dzień kampanii, targów albo wysyłki oferty do klientów. Dlatego odbiór strony powinien mieć formę krótkiej listy testów, a nie rozmowy o tym, czy projekt "wygląda nowocześnie".
Werdykt w 30 sekund
- Możesz publikować, jeśli strona działa na mobile i desktopie, formularze dochodzą, HTTPS nie pokazuje ostrzeżeń, a podstawowy pomiar i indeksowalność są ustawione.
- Popraw przed kampanią, jeśli strona jest używalna, ale ma ciężkie obrazy, słabsze teksty, brak części altów albo zbyt ubogie raportowanie zdarzeń.
- Wstrzymaj start, jeśli formularz nie wysyła wiadomości, telefon nie działa na mobile, certyfikat SSL jest błędny, publiczne strony mają
noindexalbo brakuje informacji o przetwarzaniu danych. - Nie oceniaj tylko home page: sprawdź też podstrony usług, kontakt, stopkę, formularz po błędzie, wersję mobilną i pierwsze dane po publikacji.
Co sprawdzić w 30 sekund
Odbiór strony firmowej zacznij od podziału na trzy grupy: elementy blokujące publikację, elementy ważne przed ruchem płatnym oraz elementy do monitorowania po starcie. Dzięki temu nie zatrzymujesz publikacji przez drobiazg, ale też nie wypuszczasz strony, która nie realizuje podstawowego celu.
| Obszar | Co sprawdzić | Decyzja |
|---|---|---|
| RWD i mobile | Menu, CTA, formularz, telefon, czytelność, brak nachodzących sekcji | Blokuje start, jeśli użytkownik na telefonie nie może skontaktować się z firmą |
| Formularze | Test wysłania, walidacja, komunikat, adres odbiorcy, zgody | Blokuje start, jeśli wiadomość nie dochodzi albo użytkownik nie widzi potwierdzenia |
| SSL i adres | HTTPS, przekierowania, jedna wersja z www lub bez www |
Blokuje start, jeśli przeglądarka pokazuje ostrzeżenie lub adresy działają niespójnie |
| Szybkość | Ciężkie obrazy, skrypty, podstawowe Core Web Vitals | Zwykle poprawka przed kampanią, chyba że strona ładuje się tak wolno, że nie da się jej używać |
| Indeksacja | noindex, robots.txt, sitemap, canonicale, kluczowe URL-e |
Blokuje start SEO, jeśli publiczna strona nie może trafić do indeksu |
| Prywatność | Polityka prywatności, cookies, zgody, informacja przy formularzu | Blokuje start, jeśli zbierasz dane bez informacji lub zgody wymaganej dla danego narzędzia |
| Analityka | GA4 lub inne narzędzie, zdarzenia kontaktowe, źródła ruchu | Nie zawsze blokuje stronę, ale blokuje sensowną ocenę efektu |
| Dostępność | Etykiety pól, fokus, kontrast, klawiatura, alt dla ważnych obrazów | Popraw przed startem, jeśli błąd utrudnia kontakt albo odczyt treści |
Ta tabela nie zastępuje audytu technicznego ani konsultacji prawnej. Ma pomóc w praktycznej decyzji: czy strona nadaje się do publikacji, czy trzeba wrócić do wykonawcy z konkretną listą poprawek.
Szybka decyzja: jeśli nie masz czasu na pełny przegląd, wykonaj minimum: otwórz stronę na telefonie, wyślij formularz, kliknij telefon i mail, sprawdź HTTPS, upewnij się, że strona nie ma blokady indeksacji, zobacz politykę prywatności oraz potwierdź, że analityka rejestruje najważniejsze akcje.
RWD i ścieżka użytkownika
RWD nie oznacza tylko tego, że strona "jakoś mieści się" na ekranie telefonu. Strona firmowa musi pozwolić użytkownikowi szybko zrozumieć ofertę i przejść do kontaktu na urządzeniu, z którego realnie korzysta. Jeżeli ważna część zapytań ma przychodzić z mobile, test mobilny nie może być dodatkiem na końcu.
Sprawdź stronę w kilku prostych scenariuszach:
| Scenariusz | Co przetestować | Czerwona flaga |
|---|---|---|
| Pierwsze wejście z telefonu | Czy nagłówek, oferta i CTA są widoczne bez szukania | Hero zajmuje cały ekran, ale nie mówi, czym zajmuje się firma |
| Menu mobilne | Czy da się przejść do oferty, kontaktu i kluczowych podstron | Menu zasłania treść, nie da się go zamknąć albo ma za małe elementy |
| Formularz na mobile | Czy pola są czytelne, klawiatura nie zasłania wysyłki, przycisk jest widoczny | Użytkownik musi przybliżać ekran albo nie widzi komunikatu błędu |
| Telefon i e-mail | Czy numer jest klikalny, a adres e-mail działa jako kontakt | Numer jest obrazkiem, zwykłym tekstem albo znika w sticky menu |
| Stopka | Czy widać dane firmy, dokumenty, kontakt i najważniejsze przejścia | Stopka jest rozjechana lub ma linki, których nie da się kliknąć |
Na desktopie sprawdź też szerokie ekrany. Częsty błąd polega na tym, że projekt wygląda dobrze w jednym rozmiarze, ale na większym monitorze sekcje robią się puste, teksty są zbyt długie w jednej linii, a obrazy tracą proporcje. Na mniejszych laptopach problem bywa odwrotny: sticky nagłówek, pasek cookies i formularz potrafią zasłonić ważną część widoku.
Czerwona flaga: jeżeli strona wygląda dobrze tylko na zrzucie z projektu, ale na telefonie CTA wypada poza ekran, menu się zacina albo formularz jest trudny do uzupełnienia, publikacja jest ryzykowna. To nie jest kosmetyka, tylko problem z pozyskaniem kontaktu.
Praktyczny wniosek: test RWD zalicz dopiero wtedy, gdy użytkownik na telefonie może przejść od wejścia na stronę do kontaktu bez przybliżania, zgadywania i cofania się po kilka razy.
Formularze i kontakt
Formularz kontaktowy jest jednym z najważniejszych elementów odbioru strony. Nie wystarczy zobaczyć go na projekcie. Trzeba wysłać testowe zgłoszenie i sprawdzić całą drogę: walidację pól, komunikat dla użytkownika, wiadomość w skrzynce, oznaczenie źródła oraz ewentualne zdarzenie w analityce.
Test wykonaj z komputera i telefonu. Użyj prawdziwego adresu testowego, uzupełnij pola tak, jak zrobiłby to klient, a potem sprawdź, czy wiadomość dotarła do właściwej osoby. Jeśli firma ma kilka formularzy, nie zakładaj, że działają tak samo. Formularz w stopce, na podstronie kontaktu i przy konkretnej usłudze mogą mieć inne ustawienia.
| Element formularza | Co sprawdzić | Co oznacza problem |
|---|---|---|
| Pola | Czy wymagane są tylko potrzebne dane | Zbyt długi formularz może obniżać liczbę zapytań |
| Walidacja | Czy błędy są widoczne i zrozumiałe | Użytkownik nie wie, co poprawić i rezygnuje |
| Komunikat sukcesu | Czy po wysyłce widać potwierdzenie | Użytkownik klika kilka razy albo dzwoni, bo nie wie, czy wysłał |
| Skrzynka odbiorcza | Czy wiadomość trafia pod właściwy adres | Lead może zginąć mimo poprawnego wyglądu formularza |
| Antyspam | Czy formularz jest zabezpieczony bez utrudniania kontaktu | Zbyt agresywna ochrona blokuje prawdziwych użytkowników |
| Prywatność | Czy przy formularzu jest informacja lub link do polityki | Zbierasz dane bez jasnego kontekstu dla użytkownika |
Przy formularzach nie wysyłaj danych osobowych do narzędzi analitycznych. Analityka może wiedzieć, że formularz został wysłany, z której podstrony i w jakim kontekście. Nie powinna dostawać imienia, nazwiska, telefonu, adresu e-mail ani treści wiadomości.
Osobno sprawdź alternatywne ścieżki kontaktu: kliknięcie telefonu, kliknięcie adresu e-mail, przycisk do wyceny, link do mapy, jeśli jest potrzebny, oraz dane w stopce. Czasem formularz działa, ale numer w nagłówku prowadzi donikąd albo adres e-mail zawiera literówkę. Dla użytkownika to nadal awaria kontaktu.
Decyzja praktyczna: wstrzymaj publikację, jeśli nie masz potwierdzenia, że formularz dochodzi do właściwej skrzynki. Publikacja strony bez działającego kontaktu jest jak otwarcie sklepu z zamkniętymi drzwiami.
Domena, SSL i szybkość
Techniczne sprawdzenie przed publikacją nie musi zaczynać się od pełnego audytu. Najpierw potwierdź trzy rzeczy: strona otwiera się pod właściwym adresem, działa po HTTPS bez ostrzeżeń i ładuje się na tyle sprawnie, żeby użytkownik nie rezygnował przed kontaktem.
Przy adresie sprawdź, czy firma ma jedną główną wersję strony. Wariant z www, bez www, po HTTP i po HTTPS nie powinny żyć jako osobne wersje tej samej witryny. Użytkownik może tego nie nazwać technicznie, ale zobaczy problem: raz działa strona, raz ostrzeżenie, raz stara wersja, raz błąd certyfikatu.
| Test | Co powinno się stać | Kiedy reagować |
|---|---|---|
| HTTP do HTTPS | Użytkownik trafia do bezpiecznej wersji strony | Brak przekierowania albo ostrzeżenie przeglądarki |
www i bez www |
Jedna wersja jest główna, druga przekierowuje | Dwie wersje działają osobno albo pokazują inną treść |
| Certyfikat SSL | Przeglądarka nie pokazuje ostrzeżeń | Certyfikat wygasł, nie pasuje do domeny albo nie objął www |
| Mixed content | Wszystkie zasoby ładują się bez błędów bezpieczeństwa | Obrazy, skrypty lub style nadal idą przez niezabezpieczony adres |
| Poczta w domenie | Publikacja strony nie przerywa działania skrzynek | Zmiana DNS usuwa rekordy poczty lub weryfikacji |
Szybkość potraktuj praktycznie. Na tym etapie nie chodzi o gonienie idealnego wyniku, tylko o wykrycie rzeczy, które realnie psują start: obrazy w zbyt dużym rozmiarze, ciężkie skrypty, opóźnione ładowanie głównej treści, długie oczekiwanie na reakcję strony i widoczne przeskoki układu. Core Web Vitals pomagają nazwać te problemy, ale decyzja powinna wynikać z doświadczenia użytkownika.
Jeśli strona ładuje się wolno tylko przez pojedyncze, zbyt ciężkie zdjęcie w hero, zwykle da się to poprawić przed startem. Jeśli wolne jest całe zaplecze, hosting lub główna aplikacja, publikacja przed kampanią może skończyć się przepaleniem ruchu.
Czerwona flaga: nie startuj z płatną kampanią, jeśli strona ma ostrzeżenie SSL, formularz działa losowo, a pierwsze wejście z telefonu wymaga długiego czekania na główną treść. Najpierw napraw podstawy, dopiero potem kieruj ruch.
Indeksacja po publikacji
Jeśli strona ma być widoczna w Google, sprawdź, czy po publikacji nie została zablokowana przed indeksowaniem. Wersje robocze często mają ustawione noindex, blokady w robots.txt albo dostęp tylko dla zalogowanych. To dobre na etapie pracy, ale po starcie potrafi zatrzymać widoczność całej strony.
Po publikacji warto sprawdzić kluczowe URL-e w Google Search Console: stronę główną, najważniejsze podstrony usług, kontakt oraz sitemap. Nie chodzi o to, że każda nowa podstrona natychmiast pojawi się wysoko w wynikach. Chodzi o to, żeby Google mogło ją pobrać, zrozumieć i z czasem ocenić.
| Element | Co sprawdzić | Uwaga praktyczna |
|---|---|---|
noindex |
Czy publiczne strony nie mają blokady indeksacji | Blokada testowa po publikacji to częsty błąd |
| robots.txt | Czy nie blokuje całej witryny lub ważnych katalogów | Nie każda blokada jest zła, ale musi być świadoma |
| Sitemap | Czy mapa strony istnieje i zawiera właściwe URL-e | Sitemap pomaga wskazać strukturę, ale nie gwarantuje indeksacji |
| Canonicale | Czy kluczowe strony wskazują same siebie lub właściwą wersję | Błędny canonical może przenosić sygnał na zły adres |
| Przekierowania | Czy stare adresy prowadzą do nowych odpowiedników | Ważne przy przebudowie lub zmianie struktury |
| Strony techniczne | Czy podziękowanie po formularzu i panele nie trafiają do indeksu | Nie wszystko powinno być widoczne w Google |
Przy nowej stronie nie oceniaj SEO po jednym dniu. Najpierw sprawdź, czy nie ma blokady technicznej. Dopiero potem patrz na zapytania, kliknięcia, wyświetlenia i podstrony, które zaczynają zbierać dane. Jeżeli strona zastępuje starą witrynę, do listy dochodzi migracja adresów i przekierowania. To osobny punkt ryzyka, bo utrata starych URL-i może osłabić widoczność nawet wtedy, gdy nowa strona wygląda lepiej.
Praktyczny wniosek: indeksacja to nie obietnica pozycji. To warunek wejścia do gry. Jeżeli publiczne podstrony są zablokowane, wyszukiwarka nie ma czego oceniać.
Zgody, cookies i polityka prywatności
Strona firmowa zwykle zbiera dane albo uruchamia narzędzia, które wymagają jasnej informacji dla użytkownika. Formularz kontaktowy, analityka, skrypty marketingowe, osadzone mapy, czat, piksele reklamowe i newsletter nie są neutralnymi dodatkami. Przed publikacją trzeba sprawdzić, czy polityka prywatności i zgody odpowiadają temu, co faktycznie działa na stronie.
To nie jest miejsce na gotowe klauzule prawne. Treść dokumentów powinna wynikać z realnego sposobu działania strony i w razie wątpliwości powinna zostać zweryfikowana prawnie. Na poziomie odbioru możesz jednak sprawdzić, czy nie ma oczywistych braków.
| Obszar | Minimum do sprawdzenia | Czerwona flaga |
|---|---|---|
| Polityka prywatności | Jest dostępna w stopce i opisuje realne formularze oraz narzędzia | Dokument jest pusty, generyczny albo nie pasuje do strony |
| Formularz | Użytkownik wie, kto zbiera dane i po co | Formularz zbiera dane bez informacji przy ścieżce kontaktu |
| Cookies | Użytkownik może zarządzać zgodami tam, gdzie są wymagane | Baner tylko informuje, ale nie pozwala odrzucić lub zmienić zgód |
| Analityka | Skrypty działają zgodnie z wybranym modelem zgód | Analityka ładuje się mimo braku zgody, jeśli zgoda jest wymagana |
| Marketing | Piksele i remarketing są opisane i kontrolowane | Skrypty reklamowe startują bez jasnego komunikatu |
| Dokumenty w stopce | Linki prowadzą do aktualnych treści | Link do polityki prywatności daje błąd lub prowadzi do starej wersji |
Szczególnie uważaj na sytuację, w której strona została technicznie przygotowana szybko, a dokumenty potraktowano jako coś "do dopisania później". Jeśli formularz już zbiera dane, później oznacza za późno. To samo dotyczy cookies analitycznych i marketingowych, jeśli ich działanie zależy od zgody użytkownika.
Decyzja praktyczna: wstrzymaj publikację albo przynajmniej wyłącz zbieranie danych, jeśli nie masz podstawowych informacji o prywatności przy formularzach i w stopce. Przy wątpliwościach prawnych nie dopisuj tekstu na oko, tylko ustal go z osobą odpowiedzialną za zgodność.
Analityka i pierwsze dane
Analityka przed publikacją ma odpowiedzieć na proste pytanie: czy po starcie zobaczysz, skąd przyszli użytkownicy i czy wykonali ważne działania. Nie potrzebujesz od razu dużego dashboardu. Potrzebujesz minimalnego pomiaru, który odróżnia zwykłe wejście od kontaktu.
Na start wystarczy podstawowy zestaw:
| Co mierzyć | Po co | Jak czytać |
|---|---|---|
| Wysłanie formularza | Najmocniejszy sygnał zapytania | Porównuj z wiadomościami w skrzynce |
| Kliknięcie telefonu | Sygnał zamiaru kontaktu z mobile | Nie oznacza jeszcze odbytej rozmowy |
| Kliknięcie e-maila | Sygnał przejścia do kontaktu mailowego | Nie oznacza jeszcze wysłanej wiadomości |
| Kliknięcie głównego CTA | Diagnoza, czy użytkownik idzie w stronę kontaktu | To mikrozdarzenie, nie lead |
| Landing page | Informacja, gdzie użytkownik zaczyna wizytę | Pomaga ocenić ofertę i źródła ruchu |
| Źródło ruchu | Informacja, skąd przyszli użytkownicy | Bez tego nie ocenisz kampanii ani SEO |
Jeżeli używasz GA4, Google Tag Managera albo innego narzędzia, sprawdź zdarzenia w praktyce. Wyślij formularz, kliknij telefon, kliknij e-mail i zobacz, czy system rejestruje właściwe akcje. Nie nazywaj wszystkich kliknięć leadami. Kliknięcie w CTA może tylko otwierać formularz, a kliknięcie telefonu nie dowodzi, że rozmowa się odbyła.
Pierwsze dni po publikacji traktuj jako kontrolę jakości danych, nie jako ostateczną ocenę skuteczności. Jeśli analityka pokazuje zero zapytań, a w skrzynce są wiadomości, problem leży w pomiarze. Jeśli analityka pokazuje wiele wysłanych formularzy, a skrzynka jest pusta, problem może leżeć w momencie odpalania zdarzenia albo w dostarczalności wiadomości.
Jeśli po starcie chcesz pogłębić sam pomiar kontaktu, rozpisz osobno, jak mierzyć zapytania z nowej strony internetowej: formularze, telefony, e-maile, CTA, źródła ruchu i realne leady powinny być czytane razem, a nie jako oderwane wykresy.
Minimalny test analityki
- Wejdź na stronę z telefonu i komputera.
- Kliknij główne CTA, telefon i e-mail.
- Wyślij formularz testowy.
- Sprawdź, czy zdarzenia pojawiają się w narzędziu analitycznym.
- Porównaj dane z realną skrzynką, historią połączeń albo prostym rejestrem leadów.
Praktyczny wniosek: jeśli nie mierzysz formularza, telefonu i źródeł ruchu, po publikacji będziesz zgadywać. Strona może działać albo nie działać, ale bez podstawowych danych trudno będzie odróżnić problem z ruchem od problemu z ofertą, formularzem albo obsługą zapytań.
Podstawowa dostępność
Podstawowa dostępność nie jest dodatkiem tylko dla dużych serwisów. W praktyce chodzi o to, żeby użytkownik mógł przeczytać treść, użyć formularza i przejść przez stronę także wtedy, gdy korzysta z klawiatury, ma słabszy wzrok, używa czytnika ekranu albo po prostu przegląda stronę w trudniejszych warunkach na telefonie.
Na etapie publikacji sprawdź minimum:
| Element | Co sprawdzić | Dlaczego to ważne |
|---|---|---|
| Formularze | Pola mają etykiety, błędy są opisane, fokus jest widoczny | Użytkownik wie, co wpisać i co poprawić |
| Klawiatura | Menu, linki, przyciski i formularz da się obsłużyć bez myszy | Część użytkowników nie korzysta z myszy lub trackpada |
| Kontrast | Tekst i przyciski są czytelne na realnym ekranie | Jasnoszary tekst na białym tle wygląda lekko, ale bywa nieczytelny |
| Linki | Tekst linku mówi, dokąd prowadzi | "Kliknij tutaj" bez kontekstu jest słabe dla użytkownika i technologii wspierających |
| Obrazy | Istotne grafiki mają sensowny alt | Użytkownik rozumie obraz, jeśli go nie widzi |
| Komunikaty | Błędy i potwierdzenia nie polegają tylko na kolorze | Sam czerwony kolor nie wystarczy, jeśli użytkownik nie rozumie problemu |
Nie każdy obraz potrzebuje rozbudowanego opisu. Dekoracyjne tło może mieć pusty alt, a istotne zdjęcie produktu, zespołu, realizacji albo procesu powinno mieć opis, który pomaga zrozumieć kontekst. Podobnie z formularzem: sama podpowiedź wewnątrz pola nie wystarczy. Podpowiedź znika po wpisaniu tekstu, a etykieta powinna zostać zrozumiała.
Czerwona flaga: jeśli nie da się przejść przez menu i formularz klawiaturą, a błędy formularza są widoczne tylko jako czerwone obramowanie, strona może gubić zapytania od realnych użytkowników. To nie jest tylko problem formalny, ale problem użyteczności.
Praktyczny wniosek: podstawowa dostępność zwiększa szansę, że użytkownik faktycznie dotrze do kontaktu. To ten sam cel, który ma RWD, szybkość i dobry formularz.
Końcowa checklista odbioru
Na koniec nie zbieraj uwag w luźnej rozmowie. Zrób prostą tabelę odbioru: test, wynik, decyzja i osoba odpowiedzialna. Dzięki temu wykonawca i firma wiedzą, co blokuje publikację, co jest poprawką przed kampanią, a co może wejść po starcie.
| Test | Wynik, którego szukasz | Decyzja |
|---|---|---|
| Strona na telefonie | Menu, CTA, formularz i telefon działają bez przybliżania | Publikuj, jeśli ścieżka kontaktu jest pełna |
| Strona na desktopie | Układ nie rozjeżdża się, treści są czytelne, linki działają | Publikuj lub dopisz drobne poprawki |
| Formularz | Testowa wiadomość dochodzi do właściwej skrzynki | Wstrzymaj, jeśli nie dochodzi |
| Telefon i e-mail | Linki tel: i mailto: działają w praktyce |
Popraw przed startem ruchu |
| SSL i adres | HTTPS działa, jedna wersja adresu jest główna | Wstrzymaj przy ostrzeżeniach bezpieczeństwa |
| Szybkość | Główna treść ładuje się sprawnie, obrazy nie blokują strony | Popraw przed kampanią, jeśli strona wyraźnie zwalnia |
| Indeksacja | Kluczowe podstrony nie są zablokowane | Wstrzymaj start SEO przy noindex na publicznych stronach |
| Sitemap i robots.txt | Wspierają właściwe URL-e, nie blokują całości | Popraw przed zgłaszaniem strony do Google |
| Polityka prywatności | Jest dostępna i pasuje do formularzy oraz narzędzi | Wstrzymaj, jeśli zbierasz dane bez informacji |
| Cookies i zgody | Użytkownik może podjąć decyzję zgodnie z używanymi skryptami | Popraw przed uruchomieniem analityki lub marketingu |
| Analityka | Formularz, telefon, e-mail i CTA są mierzone | Publikuj, ale zweryfikuj dane po starcie |
| Dostępność | Formularze, fokus, kontrast i linki są używalne | Popraw, jeśli błąd utrudnia kontakt |
Najważniejsze jest oddzielenie błędów krytycznych od zadań rozwojowych. Krytyczne są te, które blokują kontakt, bezpieczeństwo, indeksację, zgodność podstawowych informacji albo pomiar celu strony. Zadania rozwojowe to rzeczy, które poprawiają jakość, ale nie uniemożliwiają pierwszego działania: dopracowanie części tekstów, rozszerzenie analityki, optymalizacja dodatkowych grafik, rozbudowa sekcji albo dodanie kolejnych podstron.
Decyzja końcowa: publikuj stronę, gdy użytkownik może bez przeszkód skorzystać z oferty i kontaktu, a firma ma kontrolę nad adresem, prywatnością i podstawowym pomiarem. Wstrzymaj start, gdy strona wygląda poprawnie, ale nie da się jej bezpiecznie użyć, zmierzyć albo znaleźć w Google.