# Checklista strony internetowej przed go-live: co sprawdzamy, zanim strona może trafić online > URL: https://4eck-media.de/pl/blog/checklista-strony-internetowej-przed-go-live-co-sprawdzamy-zanim-strona-moze-trafic-online/ > Language: pl > Description: Jest taki moment, który zna każdy, kto buduje strony internetowe. Projekt jest „gotowy”. Kolory się zgadzają, zdjęcia leżą jak trzeba, klient zachwycił się designem na spotkaniu, … --- Jest taki moment, który zna każdy, kto buduje strony internetowe. Projekt jest „gotowy”. Kolory się zgadzają, zdjęcia leżą jak trzeba, klient zachwycił się designem na spotkaniu, a na czacie projektowym pada pytanie: „To możemy w tym tygodniu wejść live?”. Wszystko we mnie chce powiedzieć tak. Dokładnie w tym miejscu zaczyna się ta część naszej pracy, o której prawie nikt nie mówi. Bo między „wygląda na gotowe” a „jest gotowe” leży pewna lista. Nasza rosła przez lata i niemal każdy punkt na niej ma swoją historię: obraz hero, który na iPadzie uciął głowę prezesa zarządu. Formularz kontaktowy, który pokazywał zielony komunikat o powodzeniu, a mimo to nie dostarczył ani jednej wiadomości e-mail. Nagłówek, który przez jedno długie niemieckie słowo wychodził poza ekran. Nic z tego nie było widać w projekcie graficznym. Wszystko to było widać na żywo. ![](https://4eck-media.de/wp-content/uploads/2026/07/website-checkliste-vor-go-live-qualitaet-statt-pfusch-cover.avif) Dla klienta strona nie jest w takim momencie gotowa w 95 procentach. Ona jest zepsuta. Klient nie rozróżnia designu, frontendu, hostingu i redakcji treści. Widzi jedną stronę internetową, a każdy błąd nosi logo jego firmy. Dlatego publikujemy tutaj naszą kompletną wewnętrzną checklistę na czas przed go-live. To nie jest tajemna wiedza i właśnie o to chodzi: różnica między profesjonalną stroną internetową a projektem robionym po godzinach rzadko polega na talencie. Polega na dyscyplinie. U nas w agencji nie ma „jakoś to będzie” ani „przecież wygląda dobrze”. Punkt jest odhaczony albo nie jest. Nic pośredniego nie istnieje. Ten artykuł omawia wszystko, co jest sprawdzane przed publikacją. Na czas po niej powstała druga lista i [osobny artykuł o kontrolach po go-live](https://4eck-media.de/pl/blog/checklista-uruchomienia-strony-co-po-go-live-odroznia-jakosc-od-partactwa/), ponieważ strona, która jest online, wcale nie jest jeszcze gotowa. Obie części kontynuują i pogłębiają to, co Matthias rozpoczął w 2023 roku w naszej dużej [checkliście relaunchu dla sklepów internetowych, serwisów rezerwacyjnych i stron korporacyjnych](https://www.tutkit.com/de/blog/203-relaunch-checkliste-fuer-online-shops-buchungs-und-corporate-websites). Gotowe to nie to samo co sprawdzone - Akceptacja designu oznacza: kierunek jest właściwy. Nie oznacza, że każde urządzenie zostało przetestowane. - Test przed go-live ocenia łącznie funkcje, wyświetlanie, technikę i wyszukiwalność. - Przed launchem się przygotowuje; po launchu potwierdza się w rzeczywistych warunkach produkcyjnych. - Każdy punkt kontrolny potrzebuje osoby odpowiedzialnej i weryfikowalnego wyniku. - Jeśli błąd znajduje najpierw klient, kontrola jakości nie została zakończona. ## Jeden projekt, cztery prawdy: desktop, notebook, tablet, smartfon Strony internetowe powstają na dużych, spokojnych monitorach, a używane są na małych, niespokojnych urządzeniach. To podstawowy problem niemal każdego odbioru projektu graficznego. Makieta została pokazana i zaakceptowana na 27 calach. Odwiedzający przychodzi z trzyletnim smartfonem, trzyma go w jednej ręce i ma pół minuty cierpliwości. Dlatego sprawdzamy każdy projekt na czterech klasach urządzeń, i to nie tylko stronę główną. Strony usług, artykuły blogowe, formularze, listy przeglądowe, a w sklepach karta produktu i checkout: każdy szablon ma własne punkty pęknięcia. Kontrola samej strony głównej nie jest sprawdzeniem strony internetowej. Jest sprawdzeniem strony głównej. ![Responsywny webdesign Bolzakademie na tablecie i smartfonie z identyczną stroną główną](https://4eck-media.de/wp-content/uploads/2026/07/responsive-webdesign-bolzakademie-tablet-smartphone-startseite.avif) ### Desktop i notebook: decyduje pierwszy ekran Na dużych monitorach zwracam uwagę na zbyt długie wiersze tekstu, gubiące się treści w ogromnych białych przestrzeniach i kontenery, które bez maksymalnej szerokości rozjeżdżają się na boki. Układ, który przy 1440 pikselach wygląda na wyważony, na wyświetlaczu 27-calowym może się rozpaść. Notebook nie jest przy tym pomniejszonym desktopem. Przy 13 do 15 calach prawdziwym problemem jest wysokość: pasek przeglądarki i system operacyjny zabierają miejsce, a hero, które na monitorze wygląda elegancko, na notebooku zajmuje cały widoczny obszar. Dlatego sprawdzam pierwszy ekran tak jak odwiedzający: czy od razu wiadomo, o co chodzi? Czy najważniejszy przycisk jest dostępny, czy zasłaniają go baner cookie i sticky header? Czy w ogóle widać, że niżej strona się nie kończy? ### Tablet: niewygodny środek Tablety w wielu projektach testowane są na końcu. Desktop jest ważny, mobile jest ważne, a to, co pomiędzy, jakoś się ułoży. Właśnie tam powstają najbrzydsze błędy: tablet jest wystarczająco szeroki, aby aktywować reguły desktopowe, ale zbyt wąski, aby czysto pomieścić ich treści. Dwie kolumny zostają ściśnięte, nawigacja ledwie przestaje mieścić się w jednym wierszu, obrazy tracą swój punkt centralny. Na naszej liście są w tym celu iPad mini i iPad Pro – nie z miłości do marki, lecz dlatego, że potrzebujemy dwóch wyraźnie różnych klas rozmiaru i powtarzalnych warunków testowych. I świadomie obracam urządzenie: iPad Pro w poziomie to niemal notebook. Ten sam iPad w pionie stawia przed hero, tabelami i rzędami kart zupełnie inne zadania. ### Smartfon: nie węższy, lecz inny Na telefonie stronę obsługuje się kciukiem, pod presją czasu, często w drodze. Zwykłe ułożenie układu desktopowego w stos nie wystarczy. Treści muszą zostać uporządkowane według priorytetów, przyciski potrzebują prawdziwych obszarów dotykowych, formularze muszą otwierać właściwą klawiaturę, numery telefonów muszą dać się kliknąć. Jako punkt odniesienia służą nam iPhone 12 i iPhone 14 Pro oraz symulowane viewporty w przeglądarce. Prawdziwe urządzenia pozostają mimo to obowiązkowe, ponieważ żadna symulacja nie odwzorowuje w pełni pasków przeglądarki, zachowania dotyku i realnej wydajności. Jeden jedyny element o stałej szerokości sprawia, że cała strona daje się przesuwać w poziomie. Popup, którego krzyżyk zamknięcia leży poza ekranem, całkowicie blokuje odwiedzającego. A pytanie kontrolne nigdy nie brzmi tylko „czy wszystko jest widoczne?”, lecz: czy to, co ważne, pojawia się wystarczająco wcześnie? Czy da się trafić w link, nie trafiając w sąsiedni? Czy komunikat o błędzie pojawia się przy danym polu, czy gdzieś poza widocznym obszarem? Wiele problemów jakościowych nie jest dość spektakularnych na zgłoszenie błędu. Po prostu generują tarcie, a w analityce widać później tylko gorszy współczynnik konwersji. ## Obrazy hero: pół godziny, której nikt nie widzi w ofercie Kocham naszych projektantów. Naprawdę. Ale obraz na pełną szerokość ekranu jest niemal zawsze kompromisem technicznym i regularnie małą walką. W makiecie hero siedzi idealnie na swojej stałej powierzchni. W przeglądarce ta powierzchnia nie istnieje: jeden odwiedzający trzyma tablet w pionie, kolejny siedzi przed monitorem ultrawide, a obaj mają zobaczyć tę samą twarz, ten sam produkt, tę samą linię we właściwym miejscu. Technicznie rozwiązujemy to za pomocą kilku rozmiarów obrazu: nasz motyw pracuje z sześcioma poziomami układu: bazą mobilną oraz szerokościami od 576, 768, 992, 1200 i 1710 pikseli. Dzięki srcset i sizes przeglądarka wybiera pasujący wariant AVIF, zamiast wszędzie ładować największy oryginał. Tym samym rozmiar pliku jest rozwiązany. Kompozycja obrazu nie: za pomocą object-fit powierzchnia zostaje wypełniona, ale coś zawsze zostaje ucięte. Za pomocą object-position określam, który fragment przetrwa. Działa to tylko wtedy, gdy naprawdę obejrzę motyw w kilku proporcjach. Do tego dochodzi rozmowa, którą prowadzę regularnie: „Przecież przesłaliśmy materiał w wysokiej rozdzielczości”. Chodzi o Full HD. 1920 na 1080 pikseli brzmi imponująco, ale dla obrazu na pełną powierzchnię na dużym wyświetlaczu Retina to po prostu za mało, a jeśli trzeba jeszcze wybrać kadr, na widoczną powierzchnię zostaje jeszcze mniej prawdziwych pikseli. Efektem jest hero, które na notebooku wygląda czysto, a na dużym monitorze miękko. Oczywiście AI potrafi skalować w górę. To ratuje niektóre motywy, ale wymyśla detale: włosy, dłonie, napisy i elewacje to typowe strefy problemowe. Jeśli materiał nie daje rozdzielczości, nie obiecuję magii: wtedy zmieniamy kadr, powierzchnię albo typ hero. To nie jest porażka designu. To uczciwa decyzja. Na jedno jedyne trudne hero łącznie szybko schodzi 30 minut: sprawdzenie pliku, wygenerowanie wariantów, ustawienie punktu centralnego, obrócenie tabletu, test na ultrawide, korekta kontrastu, ponowny eksport. Tego pół godziny nikt później nie widzi. Gdy go zabraknie, widzi je każdy. Nasza zasada dotycząca hero - Hero na pełną szerokość potrzebuje motywu z wystarczającym zapasem, w razie wątpliwości aż do 4K. - Oryginał nie jest ładowany wszędzie: motyw, srcset i AVIF dostarczają pasujące warianty. - Kadr i pozycja obiektu są sprawdzane na urządzeniach mobilnych, tablecie, notebooku, desktopie i ultrawide. - Skalowanie AI jest kontrolowane pod kątem artefaktów i nie jest mylone z rzeczywistą rozdzielczością detali. - Pełna szerokość najlepiej na stronie głównej; podstrony otrzymują bardziej odporny drugi typ hero. ## Test przeglądarek: sam Chrome to jeszcze nie akceptacja Każdy programista ma ulubioną przeglądarkę i najczęściej jest to ta, w której również pracuje. To normalne. Problem zaczyna się wtedy, gdy ta sama przeglądarka jest jednocześnie jedyną kontrolą jakości. Chrome, Firefox, Safari i Edge mówią dziś w dużej mierze tymi samymi standardami, ale nie w każdym szczególe: fonty są renderowane inaczej, pola formularzy wyglądają inaczej, elementy sticky reagują w przypadkach granicznych odmiennie, a Safari pielęgnuje swoje historyczne osobliwości. Dlatego nasza checklista wymienia wyraźnie wszystkie cztery przeglądarki, a sprawdzane są te elementy, które niosą największe ryzyko błędu: nawigacja, rozwijane menu, slidery, wideo, baner cookie, formularze, akordeony, zakładki, okna modalne, elementy sticky, animacje. Safari testujemy na prawdziwym urządzeniu Apple: symulacja w Chromium nie zastąpi silnika WebKit. Typowe znaleziska: font, który się nie ładuje i przesuwa wszystkie łamania wierszy; wideo, które zatrzymuje się z powodu reguł autoodtwarzania; stan fokusu, który znika. Nie próbujemy przy tym obsłużyć każdej wersji przeglądarki z ostatnich dziesięciu lat; przed rozpoczęciem projektu ustalane jest, co jest istotne. Ale zwyczajne nieotwarcie aktualnie rozpowszechnionych przeglądarek nie jest decyzją techniczną. To nadzieja. ## Długie nagłówki i ­: błąd, który na pewno pojawi się u klienta Niemieckie złożenia są dla wąskich ekranów brutalne. „Suchmaschinenoptimierungsstrategie” albo „Barrierefreiheitsstärkungsgesetz” rozsadzają całe układy. Automatyczne dzielenie wyrazów przez CSS pomaga, ale zależy od przeglądarki, języka i słownika. Nie wszędzie jest tak samo niezawodne. Dlatego w krytycznych nagłówkach ręcznie wstawiamy miękkie miejsca podziału: niewidoczny znak ­. Dopóki jest miejsce, nic nie widać. Gdy przeglądarka musi złamać wiersz, dzieli w odpowiednim miejscu i pokazuje łącznik. ![Błędne wyświetlanie długich słów na smartfonie bez ustawionych miękkich łączników](https://4eck-media.de/wp-content/uploads/2026/07/exec-c87f6807-ca83-4308-bb28-8c5279f93b3f.avif) Po co ten wysiłek? Ponieważ ten błąd ma szczególną cechę: nigdy nie pojawia się na moim urządzeniu testowym. Czeka na tego jednego klienta z tą jedną szerokością wyświetlacza i powiększoną czcionką systemową, a potem przychodzi zrzut ekranu z uprzejmym pytaniem, gdzie właściwie patrzyliśmy. Przy długich niemieckich nagłówkach „jakoś się złamie” nie jest metodą testowania. ![Grafika przed i po: długie słowo bez miękkiego miejsca podziału wychodzi poza ekran smartfona, ze znakiem shy łamie się czysto](https://4eck-media.de/wp-content/uploads/2026/07/soft-hyphen-long-headlines-mobile.avif) ## Impressum, polityka prywatności, deklaracja dostępności i favicon Strona internetowa może być znakomita pod względem projektowym i mimo to wystartować w prawnej mgle. Przed go-live Impressum i polityka prywatności muszą być utworzone, podlinkowane i osiągalne z każdej podstrony, a linki nie mogą być zasłonięte akurat przez baner cookie. Należy do tego również strona z deklaracją dostępności, którą tworzymy dla każdego projektu: dokumentuje ona, jaki stan spełnia witryna, i podobnie jak Impressum oraz polityka prywatności należy do stopki. Ważna jest przy tym uczciwość co do zakresu odpowiedzialności: budujemy podstawę techniczną, wprowadzamy dostarczone teksty i sprawdzamy linkowanie. Nie zastępujemy prawnej akceptacji tekstów prawnych. A treść polityki prywatności musi pasować do rzeczywistej strony: analityka, zewnętrzne wideo, mapy, newsletter, captcha: to, co faktycznie jest osadzone, musi być również opisane. Tekst o teoretycznej standardowej stronie nie pomoże, jeśli strona produkcyjna ma inne przepływy danych. No i jest jeszcze favicon, najmniejszy punkt listy i najbardziej niezawodnie zapominany. Gdy go brakuje, karta przeglądarki pokazuje ogólną ikonę albo ikonę środowiska deweloperskiego: nic wtedy nie jest zepsute, ale mimo to wygląda to na niedokończone. Sprawdzam kartę, zakładki i widok mobilny. A motyw musi przetrwać pomniejszenie: subtelny napis przy 16 na 16 pikselach jest już tylko plamką. ## Dostępność: sama akceptacja designu nie wystarczy Dostępność zaczyna się w projekcie graficznym (kontrasty, wielkości czcionek, stany fokusu, logiczna struktura) i wcale się tam nie kończy. W trakcie developmentu i redagowania treści powstają nowe problemy: redaktor wgrywa obraz bez tekstu alternatywnego, nagłówek pomija poziomy, formularz otrzymuje mylącą etykietę. Dlatego przed go-live sprawdzamy jeszcze raz automatycznie (na naszej liście są AccessibilityChecker i AccessScan) i uzupełniamy skanery o ręczne próbki. Skaner potrafi bowiem zmierzyć, czy tekst alternatywny istnieje. Czy sensownie opisuje obraz, tego nie wie. Dlatego sam nawiguję bez myszy przez nawigację, formularze i okna dialogowe, śledzę widoczny fokus, sprawdzam hierarchię nagłówków i celowo wywołuję błędy formularzy: czy komunikat pojawia się przy polu i czy jest zrozumiały? Czy strona pozostaje użyteczna przy powiększeniu i większej czcionce? Od czasu niemieckiej ustawy o wzmocnieniu dostępności (Barrierefreiheitsstärkungsgesetz) z 28 czerwca 2025 roku dla wielu serwisów jest to również kwestia prawna. To, jakie obowiązki obowiązują konkretnie, zależy od przedsiębiorstwa i w razie wątpliwości wymaga wyjaśnienia prawnego. Moje praktyczne podejście jest od tego niezależne: dostępność należy dziś do profesjonalnego tworzenia stron internetowych tak samo jak HTTPS. Nie jest ona zresztą ogólnym czynnikiem rankingowym Google, ale wiele z tego, czego wymaga (czysta struktura, obsługa mobilna, zrozumiałe treści), pomaga jednocześnie wyszukiwarkom i konwersji. Kto chce podejść do tematu poważnie, znajdzie nasze podejście na stronie [dostępne strony internetowe](https://4eck-media.de/pl/kompetencje/dostepnosc-cyfrowa-twoich-stron-internetowych-agencja-webdesignu/). ![Audyt WCAG 2.2 witryny Bolzakademie z wynikiem 90 na 100 punktów i zerem błędów krytycznych](https://4eck-media.de/wp-content/uploads/2026/07/barrierefreiheit-wcag-audit-website-bolzakademie-rostock.avif) ## Dane OG: pierwsze wrażenie powstaje często w WhatsAppie Zanim odwiedzający zobaczy stronę, często widzi jedynie jej podgląd: jako udostępniony link w WhatsAppie, LinkedIn, Slacku czy Teams. Ten podgląd budują dane Open Graph: og:title, og:description i przede wszystkim og:image. Jeśli nie są zadbane, komunikator wyciąga ze strony przypadkowy obraz, ucina tytuł albo nie pokazuje po prostu niczego. Pierwszym wrażeniem z nowej strony jest wtedy szary prostokąt. ![Grafika porównawcza: podgląd linku w komunikatorze bez danych OG jako szary prostokąt, z danymi OG jako karta z obrazem, tytułem i opisem](https://4eck-media.de/wp-content/uploads/2026/07/og-data-link-preview-messenger.avif) Dlatego przed go-live sprawdzam dla każdego szablonu: czy obraz podglądu jest ustawiony, czy ma właściwy rozmiar (1200 na 630 pikseli jako standard), czy pokazuje to, co trzeba, i czy tytuł oraz opis się zgadzają? Po relaunchu szczególnie ważne: adresy URL w danych OG nie mogą już wskazywać na domenę deweloperską. Test jest prosty: wrzucić link do komunikatora albo do narzędzia podglądu i zobaczyć, co naprawdę się pojawia. Trwa to kilka minut, a decyduje o tym, jak wygląda każda udostępniona rekomendacja strony. ![Sprawdzenie OpenGraph witryny Bolzakademie z poprawnie osadzonym obrazem OG](https://4eck-media.de/wp-content/uploads/2026/07/og-image-seo-monitor-mockup-16x9-1-e1784893939736.avif) ## Structured Data: instrukcja obsługi dla maszyn Za pomocą danych strukturalnych opisujemy stronę tak, aby maszyny widziały nie tylko słowa, lecz także zależności: „4eck Media” nie jest wtedy ciągiem znaków, lecz organizacją z adresem, usługami, osobami i ocenami. Rozpowszechnione podejście minimalne (zainstalować wtyczkę SEO, dodać logo, gotowe) tworzy jedynie szkielet. Idziemy wyraźnie dalej i modelujemy rzeczywistą stronę: organizację, założycieli, pracowników, katalogi usług, artykuły z autorem i datą, okruszki nawigacyjne, FAQ. Nie na podstawie wymyślonych danych, lecz takich, które da się udokumentować. Zwłaszcza w otoczeniu wyszukiwania opartego na AI to się opłaca: systemy takie jak ChatGPT, Gemini czy Perplexity muszą jednoznacznie przyporządkować przedsiębiorstwa, osoby i usługi. Dane strukturalne nie gwarantują rekomendacji. Redukują wieloznaczność. Przed go-live waliduję je walidatorem Schema.org, a tam, gdzie Google obsługuje dany typ, testem Rich Results. A potem przychodzi kontrola, której nie wykona żaden walidator: zestawienie z rzeczywistością. Jeśli w stopce widnieje inny numer telefonu niż w znacznikach, kod jest technicznie poprawny i merytorycznie błędny. Znaczniki nie są przy tym jednorazowym kodem dekoracyjnym: gdy zmieniają się adres, zespół lub usługi, warstwa czytelna maszynowo musi za tym nadążyć, w przeciwnym razie zacznie kiedyś produkować szczególnie precyzyjne, ale nieaktualne informacje. Znaczniki: nasze minimum - Modelować nie tylko WebSite i Organization, lecz wszystkie istotne rzeczywiste encje. - Powiązać ze sobą firmę, osoby, usługi, artykuły, nawigację, okruszki nawigacyjne i FAQ. - Oznaczać wyłącznie widoczne, poprawne i udokumentowane informacje. - Sprawdzać JSON-LD walidatorem Schema.org oraz w razie potrzeby testem Rich Results od Google. - Utrzymywać znaczniki przy zmianach tak samo jak widoczne treści. ## PageSpeed: 90 to dolna granica, a nie cel PageSpeed to punkt, przy którym niechętnie negocjuję. Nowa strona startuje u nas w zielonym zakresie: co najmniej 90 punktów w Google PageSpeed Insights, a celem jest 94, 95 i więcej. Nie dlatego, że między 93 a 95 leży inny świat, lecz dlatego, że potrzebujemy zapasu. Po przekazaniu strona żyje dalej: klient kiedyś wgra zdjęcie o wielkości 12 megabajtów, osadzi wideo, doda skrypt marketingowy. Kto startuje dokładnie z 90, po pierwszej nieostrożnej zmianie jest na żółto. Kto startuje z 95, zniesie codzienność. Wersję mobilną i desktopową mierzę osobno, a mobilna jest uczciwszym testem: słabszy procesor, gorsza sieć, większe obrazy. Za wynikiem patrzę na Core Web Vitals: LCP (kiedy widoczny jest największy element? najczęściej jest to właśnie wspomniane wcześniej hero), INP (jak szybko strona reaguje?) i CLS (czy układ skacze podczas ładowania?). Wynik 100 przy zepsutym wyświetlaniu jest bezwartościowy, ale odwrotne zdanie „PageSpeed to przecież tylko narzędzie” u mnie również nie obowiązuje: to narzędzie pokazuje realne ryzyka. Klasyki są prawie zawsze te same: zbyt duże obrazy, blokujący JavaScript, późno ładowane fonty, skrypty firm trzecich. Jak podchodzimy do tego systematycznie, opisujemy na naszej stronie o [optymalizacji PageSpeed](https://4eck-media.de/pl/kompetencje/optymalizacja-pagespeed-mierzalnie-szybsze-strony-internetowe/). ![Raport Google PageSpeed Insights witryny Bolzakademie z oceną czasu ładowania](https://4eck-media.de/wp-content/uploads/2026/07/pagespeed-optimierung-ladezeit-website-bolzakademie-rostock.avif) ## Yoast i Seobility: narzędzia znajdują to, co przeoczą oczy Przed go-live kontrolujemy podstawowe ustawienia Yoast i dodatkowo zlecamy pełne przeskanowanie strony. Używamy do tego Seobility. Crawler odpowiada na pytanie, na które żaden człowiek nie odpowie samym patrzeniem: czy gdzieś jakaś podstrona wypada z szeregu? Przykład z jednego z naszych ostatnich projektów: obszar „Technika i meta” stał na 98 procentach. Brzmi jak gotowe. Brakujące dwa procent to były dwa problematyczne meta description, jedna nieprawidłowość w nagłówkach i trzy brakujące atrybuty alt: dokładnie ta garść konkretnych błędów, dla której ta kontrola istnieje. Wysoki wynik ogólny nie jest powodem, aby zignorować resztę listy. Jest powodem, dla którego reszta listy jest krótka. W Yoast sprawdzam dodatkowo szablony: pojedynczy zadbany artykuł niczego nie dowodzi, jeśli cały niestandardowy typ treści jest przypadkowo ustawiony na noindex albo automatycznie generuje bezużyteczne tytuły. A w crawlu zwracam uwagę na strukturę: ważne podstrony zakopane pięć kliknięć głęboko; teksty linków w rodzaju „więcej”, które nikomu nie mówią, dokąd prowadzą; strony osierocone. Narzędzie mierzy ścieżki. O tym, czy ścieżki mają sens, decyduje człowiek. Kto chce wejść głębiej: dla szerokiego przeglądu jest [audyt SEO](https://4eck-media.de/pl/kompetencje/audyt-seo-twojej-strony-analiza-i-plan-optymalizacji/), a przed go-live chodzi o oczywiste błędy, które teraz da się jeszcze tanio usunąć. ![Analiza Seobility witryny Bolzakademie z wynikiem on-page na poziomie 96 procent](https://4eck-media.de/wp-content/uploads/2026/07/seo-onpage-optimierung-analyse-website-bolzakademie.avif) ## Formularze i e-maile: wysłanie to jeszcze nie dostarczenie Formularz kontaktowy to miejsce, w którym pozornie zdany test jest najbardziej niebezpieczny. Programista go wypełnia, widzi zielony komunikat o powodzeniu, odhaczone. Dowiedzione jest tym samym dokładnie jedno: frontend przyjął zapytanie. Czy e-mail dotarł do właściwej skrzynki, czy potwierdzenie wyszło do nadawcy, czy dane zostały zapisane. To wszystko pozostaje otwarte. Mieliśmy taki przypadek w praktyce: formularz zielony, skrzynka pusta. Klient zauważa coś takiego dopiero wtedy, gdy zaczyna się dziwić, dlaczego od dwóch tygodni nikt nie wysyła zapytań. Dlatego testuję całą drogę: pola obowiązkowe muszą działać, nieprawidłowe dane muszą być zrozumiale wychwytywane, wiadomość musi trafić do przewidzianej skrzynki (nie do spamu), a nazwa nadawcy, temat, Reply-To i wszystkie pola muszą być sensownie sformatowane. Dla niezawodnego dostarczania konfigurujemy ścieżkę SMTP lub poczty transakcyjnej; SPF, DKIM i DMARC leżą częściowo poza WordPressem, ale współdecydują o tym, czy wiadomość zostanie uznana za wiarygodną. Formularze krytyczne dla biznesu testuję z kilku adresów i na telefonie. Ochrona antyspamowa jest przygotowywana, ale nie może blokować prawdziwych ludzi. Dostrajanie następuje po launchu. ## Mapa przekierowań: planować przed relaunchem, nie improwizować po nim Przy nowej domenie bez poprzedniczki ten punkt jest niewielki. Przy relaunchu mapa przekierowań jest jednym z najważniejszych dokumentów projektu: każdy istotny stary adres URL otrzymuje sensowny nowy cel: nie ogólnie stronę główną, lecz najbliższy treściowo odpowiednik. Zbieram stare adresy URL z mapy witryny, analityki, Search Console i crawlu, przyporządkowujemy cele i oznaczamy to, co świadomie znika. Niebezpieczne są łańcuchy i pętle: jeśli A wskazuje na B, a B później na C, powstają zbędne objazdy: lepiej A bezpośrednio na C. Pętla sprawia, że cel staje się całkowicie nieosiągalny. Mapa jest przygotowywana przed go-live; ostatecznie testowana jest na domenie produkcyjnej. Dzięki temu podejmujemy decyzje w spokoju, a nie w momencie, w którym stara strona jest już wyłączona. ![Diagram: łańcuch przekierowań z A przez B do C, bezpośrednie przekierowanie z A do C oraz pętla przekierowań między A i B](https://4eck-media.de/wp-content/uploads/2026/07/redirect-chains-loops-diagram.avif) ## Aktualizacje, porządki, ścieżka logowania i zdjęcia dowodowe Przed go-live doprowadzamy WordPressa, motyw i wtyczki do uzgodnionego, aktualnego stanu, ale nie pięć minut przed końcem pracy i nigdy bez punktu przywracania. Aktualizacje zmieniają kod; łatają luki i równie dobrze mogą wprowadzić nowe konflikty. Czyli: kopia zapasowa, aktualizacja w środowisku deweloperskim, powtórzenie krytycznych testów. Równie ważne jest sprzątanie: wtyczki testowe, importy demo i nieużywane motywy wylatują. Najlepsza liczba wtyczek to nie zero, lecz najmniejsza liczba, która niezawodnie realizuje uzgodnione zadania. Na naszej liście znajduje się ponadto zmiana ścieżki logowania z /wp-login na ścieżkę specyficzną dla projektu. Trzyma to z dala automatyczny szum tła i wyraźnie nie jest koncepcją bezpieczeństwa. Ukryty login z hasłem „admin123” nie jest bezpieczny. Silne hasła, uwierzytelnianie dwuskładnikowe, ograniczona liczba prób logowania i minimalne uprawnienia pozostają właściwym zabezpieczeniem; konta testowe są usuwane przed launchem. A przy każdym relaunchu robimy zrzuty ekranu starej strony: strona główna, ważne podstrony, nawigacja, formularze. Brzmi to jak nostalgia, a jest praktycznym zabezpieczeniem: po przełączeniu stary stan znika, i wtedy zaczyna się dyskusja z pamięci: czy ten tekst wcześniej też tak brzmiał? Czy była ta informacja? Porównanie przed i po odpowiada na takie pytania w kilka sekund. ## Tłumaczenia: każdy język to osobna strona internetowa Przy wielojęzycznej stronie nie wystarczy sprawdzić wersji niemieckiej i zaufać wtyczce tłumaczeniowej. Teksty mają różną długość: zwięzły niemiecki przycisk po francusku robi się szeroki, angielski nagłówek mieści się w jednym wierszu, polski potrzebuje trzech. Menu, formularze, pola SEO i teksty alternatywne mogą mieć w każdym języku własne luki. Dlatego traktuję każdy język jak osobną stronę: nawigacja, przełącznik języków, kluczowe podstrony, formularze, metadane, hreflang. Wystarczy jeden jedyny niemiecki przycisk w angielskiej ścieżce zapytania, aby odwiedzający wiedział: tutaj praca nie została dokończona. I najważniejsza lekcja z naszej własnej praktyki: status „kompletne” w narzędziu do tłumaczeń nie jest dowodem: widzieliśmy pola oznaczone jako przetłumaczone, a mimo to puste. Jak dziś tłumaczymy duże strony internetowe za pomocą XLIFF i AI oraz jak przy tym sami się kontrolujemy, opisujemy w [kompletnym przewodniku po tłumaczeniu WordPressa z AI](https://4eck-media.de/pl/blog/tlumaczenie-wordpressa-z-pomoca-ai-szybko-tanio-i-bez-frustracji-z-wpml-nasz-kompletny-workflow/). ## Jak sprawdzamy: nazwiska, priorytety, dowody Najlepsza checklista nic nie da, jeśli leży obok projektu jako anonimowa tabela. U nas każdy punkt ma nazwisko: kto sprawdza formularze, kto tłumaczenia, kto urządzenia. A punkt zna cztery stany: sprawdzony, błąd znaleziony, poprawiony, sprawdzony ponownie. Błąd nie jest załatwiony dlatego, że ktoś napisał, iż go usunął; poprawka może zepsuć coś nowego w innym miejscu. Dopiero test kontrolny zamyka punkt. Błędy są priorytetyzowane, inaczej ktoś przez trzy godziny poleruje dwupikselowy odstęp, podczas gdy formularz nie wysyła maili: krytyczne jest to, co blokuje kluczową ścieżkę użytkownika. Poważne jest to, co dotyka ważnej klasy urządzeń lub obowiązków prawnych. Reszta jest dokumentowana i planowana. A każde znalezisko potrzebuje użytecznego dowodu: „mobile zepsute” to nie jest informacja. „Przy 390 na 844 pikselach w Safari przycisk cookie leży na przycisku wysyłki” da się odtworzyć i naprawić. Jeszcze dwie zasady, które często nas uratowały. Po pierwsze: kto zbudował daną funkcję, nie odbiera jej sam: budowniczy wie, gdzie trzeba kliknąć, i właśnie dlatego przeocza przeszkody. Dla kluczowych ścieżek obowiązuje zasada czworga oczu. Po drugie: akceptacja klienta nie zastępuje naszej kontroli. Klient akceptuje design i treści; nie jest naszą nieopłacaną kontrolą jakości. Jeśli spędza czas przeznaczony na przegląd na błędach przeglądarkowych, które sami powinniśmy byli znaleźć, zmarnowaliśmy jego uwagę. Jak taka kontrola wygląda w praktyce, pokazuje Matthias na tym filmie: strona zbudowana przez AI, profesjonalnie rozłożona na czynniki pierwsze: 10 błędów w 20 minut. [KI-Website besser als 95 % der Webdesigner? 10 Fehler in 20 Minuten aufgedeckt.](https://www.youtube-nocookie.com/embed/j6MsRVOb2do?feature=oembed) Mój standard przed go-live - Żadne urządzenie nie zostaje odhaczone zdaniem „jakoś to będzie”. - Żaden wynik narzędzia nie zastępuje widocznej i funkcjonalnej kontroli. - PageSpeed startuje na zielono i z zapasem na późniejszą pielęgnację treści. - Znaczniki, dostępność i SEO są częścią developmentu, a nie dekoracją po nim. - Strona wchodzi live dopiero wtedy, gdy potrafię objaśnić wynik również na urządzeniu klienta. ## Kompletna checklista przed go-live w jednym miejscu Zestawienie jest skondensowaną wersją naszej wewnętrznej listy roboczej. W projekcie uzupełniana jest o specyficzne funkcje: strona firmowa nie potrzebuje testu checkoutu, sklep potrzebuje go znacznie więcej. Kopiowanie jest wyraźnie mile widziane. I prosimy przypisać każdemu punktowi nazwisko. Odhaczenie bez osoby odpowiedzialnej to tylko pusta komórka. | Punkt kontrolny | Co konkretnie musi zostać potwierdzone | Typowy skutek braku kontroli | | --- | --- | --- | | Design na desktopie | Odstępy, kontenery, szerokości tekstu, rytm strony i wszystkie szablony | Strona główna wygląda dobrze, podstrony sprawiają wrażenie niedokończonych | | Design na notebooku | Pierwszy widoczny obszar, wysokość hero, sticky header i przyciski | Ważne treści leżą w całości poniżej linii przewijania | | Tablet mały i duży | Orientacja pionowa i pozioma, kolumny, nawigacja, tabele, slidery | Ściśnięte układy pośrednie i ucięte motywy | | Urządzenia mobilne | Obszary dotykowe, kolejność, popupy, formularze i przewijanie w poziomie | Odwiedzający nie mogą obsłużyć kluczowych funkcji | | Obrazy hero | Rozdzielczość, warianty responsywne, kadr, punkt centralny i kontrast | Rozmyte obrazy, artefakty lub zniknięte motywy główne | | Impressum i polityka prywatności | Treści dostarczone, podlinkowane globalnie, uwzględnione usługi techniczne | Ryzyka prawne i ryzyka związane z zaufaniem | | Dostępność | Skaner oraz test klawiatury, fokusu, struktury i powiększenia | Wykluczenie użytkowników, koszty poprawek i możliwe ryzyka prawne | | Favicon | Karta przeglądarki, widok mobilny i odpowiednia redukcja | Serwis sprawia widoczne wrażenie niedokończonego | | Structured Data | Rzeczywiste encje zamodelowane kompletnie, poprawnie i bez sprzeczności | Wyszukiwarki i AI otrzymują niejasne lub błędne sygnały | | PageSpeed mobile | Minimum 90, cel 94-95+, sprawdzone przyczyny i Core Web Vitals | Wolne działanie i brak marginesu na późniejsze treści | | PageSpeed desktop | Osobny pomiar, kontrola zasobów, przesunięć układu i skryptów | Problemy są maskowane przez szybki komputer deweloperski | | Yoast | Indeksowanie, canonical, szablony, title i description | Całe typy treści są błędnie indeksowane | | Seobility | Przeskanowane technika, struktura i treść; ocenione nieprawidłowości | Błędy seryjne i zapomniane podstrony pozostają niewykryte | | Formularze i e-maile | Walidacja, dostarczanie, Reply-To, potwierdzenie i wersja mobilna | Zapytania znikają mimo zielonego komunikatu o powodzeniu | | Mapa przekierowań | Stare adresy URL zebrane i przypisane do sensownych celów | Błędy 404, spadki rankingów i sfrustrowani dotychczasowi użytkownicy | | WordPress i wtyczki | Kontrolowana aktualizacja, testy i usunięcie zbędnych komponentów | Luki bezpieczeństwa i konflikty zaraz po launchu | | Przeglądarki | Chrome, Firefox, Safari i Edge z krytycznymi funkcjami | Błąd trafia dokładnie w użytkowników spoza przeglądarki deweloperskiej | | Logowanie i użytkownicy | Ścieżka, 2FA, hasła, uprawnienia i konta testowe | Zbędna powierzchnia ataku i zbyt szerokie uprawnienia dostępu | | Zrzuty ekranu starej strony | Ważne podstrony i funkcje udokumentowane przed przełączeniem | Na pytania o stan przed i po nie da się już odpowiedzieć | | Tłumaczenia | Każdy język sprawdzony wizualnie, funkcjonalnie i w polach SEO | Mieszanka językowa, zepsute łamania wierszy i niekompletne ścieżki użytkownika | | ­ w nagłówkach | Długie niemieckie słowa opatrzone sensownymi miejscami podziału | Jakiś smartfon na pewno znajdzie żenujące łamanie wiersza | ## Co odróżnia jakość od technicznej fuszerki Techniczna fuszerka rzadko jest spektakularna. Najczęściej jest to hero, które na iPadzie ucina głowę. Zapytanie, które nigdy nie zostało dostarczone. H1, które przez jedno długie słowo wychodzi poza ekran. Każdy pojedynczy błąd da się zbagatelizować. Razem decydują o tym, czy odwiedzający zaufa stronie. Jakość nie oznacza dla mnie bezbłędności po wsze czasy. Jakość oznacza: systematycznie sprawdzać znane ryzyka, dokumentować decyzje i wchodzić live ze stanem, za którym można z czystym sumieniem stanąć. Tę pracę można wykonać samodzielnie. Właśnie dlatego lista znajduje się tutaj w całości. Potrzebne są cierpliwość, prawdziwe urządzenia i gotowość, aby jeszcze raz krytycznie spojrzeć na rzekomo gotową stronę. Kto woli powierzyć to komuś innemu, może [zlecić stworzenie profesjonalnej strony internetowej](https://4eck-media.de/pl/kompetencje/agencja-ui-ux-web-developmentu-4eck-media/) albo skontaktować się z nami w sprawie kontroli technicznej przez [stronę kontaktową 4eck Media](https://4eck-media.de/pl/kontakt/). A gdy strona jest już online? Wtedy zaczyna się druga połowa pracy: zwolnienie indeksowania, nagłówki bezpieczeństwa, kopie zapasowe z testem przywracania, tracking i zgody, przekierowania w rzeczywistych warunkach. Wszystko to znajduje się w drugiej części: [checkliście launchu na czas po go-live](https://4eck-media.de/pl/blog/checklista-uruchomienia-strony-co-po-go-live-odroznia-jakosc-od-partactwa/). Nawiasem mówiąc: przy projektach wielojęzycznych do kontroli jakości należy również tłumaczenie. Jak [tłumaczymy WPML z AI](https://4eck-media.de/pl/blog/tlumaczenie-wordpressa-z-pomoca-ai-szybko-tanio-i-bez-frustracji-z-wpml-nasz-kompletny-workflow/) (szybko, tanio i w sposób dowodliwie kompletny), opisujemy w naszym pełnym artykule o workflow. ## Częste pytania o checklistę strony internetowej przed go-live Co trzeba sprawdzić przed go-live strony internetowej? Co najmniej wyświetlanie na desktopie, notebooku, tablecie i urządzeniach mobilnych, najważniejsze przeglądarki, formularze i dostarczanie e-maili, PageSpeed, dostępność, podstawy SEO, dane strukturalne, strony prawne, wtyczki, przekierowania oraz (przy stronach wielojęzycznych) każdą wersję językową. Do tego dochodzą funkcje specyficzne dla projektu. Jak długo trwa profesjonalne sprawdzenie strony internetowej przed launchem? To zależy od zakresu i funkcji. Małą stronę można sprawdzić w kilka godzin; sklep, portal albo wielojęzyczny relaunch wymaga znacznie więcej czasu. Samo trudne hero na pełną szerokość może przez kadrowanie, warianty responsywne i testy na urządzeniach wygenerować około pół godziny dodatkowej pracy. Czy wystarczy przetestować stronę w Chrome? Nie. Chrome, Firefox, Safari i Edge nadal różnią się w renderowaniu, formularzach oraz poszczególnych funkcjach CSS i JavaScript. Krytyczne komponenty muszą zostać uruchomione w uzgodnionych przeglądarkach docelowych. Safari należy sprawdzić na prawdziwym urządzeniu Apple. Jaki wynik PageSpeed jest dobry przed go-live? Naszą wartością minimalną jest 90, a naszym celem 94 do 95 lub więcej. Dodatkowy zapas tworzy rezerwę, gdy później dochodzą większe obrazy, filmy lub skrypty marketingowe. Poza wynikiem decydujące są przyczyny oraz Core Web Vitals LCP, INP i CLS. Czy dostępność jest bezpośrednim czynnikiem rankingowym Google? Google nie określa dostępności ogólnie jako pojedynczego bezpośredniego czynnika rankingowego. Core Web Vitals są jednak wykorzystywane w systemach rankingowych, a wiele cech dostępnej strony internetowej (użyteczność mobilna, przejrzysta struktura, semantyka i zrozumiałe treści) poprawia jednocześnie użyteczność i możliwość technicznego przetwarzania. Dlaczego dane strukturalne są tak ważne przed launchem? Dane strukturalne opisują w sposób czytelny maszynowo firmy, osoby, usługi, artykuły i ich relacje. Redukuje to wieloznaczność dla wyszukiwarek i systemów AI. Znaczniki nie gwarantują rankingu, powinny być jednak kompletne, poprawne, walidne i spójne z widocznymi informacjami na stronie. Na co dodatkowo zwrócić uwagę przy checkliście relaunchu strony internetowej? Przy relaunchu dochodzą w szczególności eksport starych adresów URL, mapa przekierowań, zestawienie danych z Analytics i Search Console, zrzuty ekranu starej strony oraz sprawdzenie canonicali, mapy witryny, indeksowania i istniejących rankingów. Wizualna i funkcjonalna kontrola przed go-live pozostaje mimo to w pełnym zakresie.