![\"\"](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/website-checkliste-vor-go-live-qualitaet-statt-pfusch-cover.avif\")
<\/figure>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.<\/p>
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.<\/p>
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<\/a>, 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<\/a>.<\/p> 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.<\/p> 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.<\/p> 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ść.<\/p> 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?<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> Nasza agencja webdesignu<\/a> planuje takie serwisy od koncepcji informacyjnej po wydajną realizację.<\/p> 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.<\/p> 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ą.<\/p> 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.<\/p> 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?<\/p> 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<\/a>.<\/p> Nasza agencja SEO<\/a> traktuje przy tym technikę, intencję wyszukiwania i content jako jeden spójny system.<\/p> 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.<\/p> 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.<\/p> 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ć.<\/p> 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.<\/p> 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ść.<\/p> 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<\/a>.<\/p> 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?<\/p> 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.<\/p> 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<\/a>, a przed go-live chodzi o oczywiste błędy, które teraz da się jeszcze tanio usunąć.<\/p> 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ń.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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.<\/p> 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<\/a>.<\/p>\n
Jeden projekt, cztery prawdy: desktop, notebook, tablet, smartfon<\/h2>
![\"Responsywny](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/responsive-webdesign-bolzakademie-tablet-smartphone-startseite.avif\")
<\/figure>Desktop i notebook: decyduje pierwszy ekran<\/h3>
Tablet: niewygodny środek<\/h3>
Smartfon: nie węższy, lecz inny<\/h3>
Obrazy hero: pół godziny, której nikt nie widzi w ofercie<\/h2>
\n
Test przeglądarek: sam Chrome to jeszcze nie akceptacja<\/h2>
Długie nagłówki i : błąd, który na pewno pojawi się u klienta<\/h2>
![\"Błędne](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/exec-c87f6807-ca83-4308-bb28-8c5279f93b3f.avif\")
<\/figure>![\"Grafika](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/soft-hyphen-long-headlines-mobile.avif\")
<\/figure>Impressum, polityka prywatności, deklaracja dostępności i favicon<\/h2>
Dostępność: sama akceptacja designu nie wystarczy<\/h2>
![\"Audyt](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/barrierefreiheit-wcag-audit-website-bolzakademie-rostock.avif\")
<\/figure>Dane OG: pierwsze wrażenie powstaje często w WhatsAppie<\/h2>
![\"Grafika](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/og-data-link-preview-messenger.avif\")
<\/figure>![\"Sprawdzenie](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/og-image-seo-monitor-mockup-16x9-1-e1784893939736.avif\")
<\/figure>Structured Data: instrukcja obsługi dla maszyn<\/h2>
\n
PageSpeed: 90 to dolna granica, a nie cel<\/h2>
![\"Raport](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/pagespeed-optimierung-ladezeit-website-bolzakademie-rostock.avif\")
<\/figure>Yoast i Seobility: narzędzia znajdują to, co przeoczą oczy<\/h2>
![\"Analiza](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/seo-onpage-optimierung-analyse-website-bolzakademie.avif\")
<\/figure>Formularze i e-maile: wysłanie to jeszcze nie dostarczenie<\/h2>
Mapa przekierowań: planować przed relaunchem, nie improwizować po nim<\/h2>
![\"Diagram:](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/redirect-chains-loops-diagram.avif\")
<\/figure>Aktualizacje, porządki, ścieżka logowania i zdjęcia dowodowe<\/h2>
Tłumaczenia: każdy język to osobna strona internetowa<\/h2>