Audyt strony internetowej w 2026 roku: kompletna checklista SEO, Core Web Vitals, dostępności i bezpieczeństwa

W 2026 roku audyt trzeba prowadzić warstwowo. Google nadal opiera widoczność na technicznych fundamentach i treściach tworzonych dla ludzi, ale wyniki mogą być prezentowane także w funkcjach opartych na AI. Core Web Vitals należy oceniać na danych rzeczywistych, dostępności nie da się potwierdzić samym skanerem, a bezpieczeństwo wymaga czegoś więcej niż obecności certyfikatu SSL.

Ten poradnik prowadzi przez kompletny proces: od indeksowania i SEO, przez LCP, INP i CLS, po WCAG 2.2, nagłówki bezpieczeństwa, formularze, analitykę oraz kolejność wdrażania poprawek.

TL;DR: Zacznij od błędów krytycznych: niedostępności strony, blokady indeksowania, błędnych przekierowań, problemów z HTTPS i podatności. Następnie popraw Core Web Vitals, dostępność głównych ścieżek oraz treści i linkowanie. Wynik 100/100 w jednym narzędziu nie zastępuje danych z Search Console, testów na prawdziwych urządzeniach i ręcznej kontroli.

Standardy, progi i źródła zostały zweryfikowane 23 lipca 2026 roku.

Najważniejsze obszary audytu

Obszar	Co należy sprawdzić	Wynik uznawany za dobry	Priorytet
Indeksowanie	robots.txt, noindex, mapa witryny, canonical, statusy HTTP	ważne strony dostępne i indeksowalne, duplikaty skonsolidowane	krytyczny
SEO i treść	intencja, tytuły, nagłówki, linkowanie, dane strukturalne	każda ważna strona ma jasny cel i unikalną wartość	wysoki
Wydajność	LCP, INP, CLS, TTFB, JavaScript, obrazy, fonty	CWV w zakresie „good” dla 75. percentyla	wysoki
Dostępność	klawiatura, fokus, semantyka, kontrast, formularze, czytniki ekranu	główne ścieżki zgodne z WCAG 2.2 AA	wysoki
Bezpieczeństwo	HTTPS, nagłówki, cookies, zależności, autoryzacja, kopie	brak podatności krytycznych i zbędnej ekspozycji	krytyczny
UX i konwersja	mobile, formularze, nawigacja, błędy, zaufanie	użytkownik kończy kluczowe zadanie bez przeszkód	wysoki
Pomiar	Search Console, analityka, logi, monitoring	dane są kompletne, zgodne z prywatnością i użyteczne	średni

Co naprawdę obejmuje audyt strony?

Kompletny audyt łączy co najmniej sześć perspektyw:

1. Techniczne SEO - czy robot może wejść na stronę, wyrenderować ją, przejść po linkach i wybrać właściwy adres kanoniczny.
2. Jakość treści - czy strona odpowiada na realne pytanie użytkownika, ma logiczną strukturę i nie powiela innych podstron.
3. Wydajność - jak szybko pojawia się główna treść, jak sprawnie strona reaguje i czy układ nie przesuwa się podczas ładowania.
4. Dostępność - czy serwis da się obsłużyć klawiaturą, czytnikiem ekranu, przy powiększeniu i bez polegania wyłącznie na kolorze.
5. Bezpieczeństwo i prywatność - czy komunikacja, sesje, formularze, zależności i dane użytkowników są właściwie chronione.
6. UX i cele biznesowe - czy odwiedzający rozumie ofertę i może wykonać najważniejszą czynność bez zbędnych kroków.

Automatyczne narzędzia są dobrym początkiem, ale nie potrafią ocenić wszystkiego. Lighthouse może wykryć część problemów z wydajnością i dostępnością, lecz nie stwierdzi, czy oferta jest zrozumiała, formularz odpowiada potrzebom klienta albo komunikat błędu pomaga wyjść z problemu.

Zanim rozpoczniesz: ustal zakres i próbkę adresów

Najczęstszy błąd polega na przeskanowaniu wyłącznie strony głównej. W praktyce trzeba sprawdzić reprezentatywne typy podstron:

• stronę główną,
• najważniejszą stronę usługi lub produktu,
• artykuł lub poradnik,
• kategorię albo listing,
• formularz kontaktowy, rejestrację lub checkout,
• stronę wyniku wyszukiwania,
• wersję językową,
• stronę 404 i inne stany błędów,
• podstronę wymagającą logowania, jeśli występuje.

Dla małego serwisu wystarczy próbka kilku lub kilkunastu adresów. W sklepie, portalu lub aplikacji należy badać szablony, a nie losowo wybrane URL-e. Jeśli jeden szablon produktu ma zły canonical albo ładuje ciężki skrypt, problem może dotyczyć tysięcy podstron.

Przed audytem zbierz:

• dostęp do Google Search Console i analityki,
• listę najważniejszych celów biznesowych,
• mapę witryny i główne szablony,
• informacje o zmianach, migracjach i spadkach ruchu,
• dane z monitoringu błędów oraz logi serwera,
• urządzenia i przeglądarki najczęściej używane przez klientów.

1. Audyt technicznego SEO i indeksowania

Sprawdź statusy HTTP i wersje domeny

Każdy ważny adres powinien zwracać prawidłowy status:

• 200 dla działającej strony,
• 301 lub 308 dla trwałego przekierowania,
• 404 albo 410 dla usuniętej treści,
• 5xx tylko jako rzeczywisty błąd serwera, a nie stały stan.

Sprawdź warianty http/https, www/non-www, ukośniki na końcu oraz wielkość liter. Powinny prowadzić do jednej, konsekwentnej wersji. Unikaj łańcuchów przekierowań oraz sytuacji, w której wiele starych adresów trafia na stronę główną bez związku z pierwotną treścią.

Zweryfikuj robots.txt, noindex i dostępność zasobów

Plik robots.txt kontroluje indeksowanie zasobów przez roboty na poziomie pobierania, ale nie jest mechanizmem usuwania strony z wyników wyszukiwania. Zablokowany URL nadal może pojawić się w indeksie, jeśli Google pozna go z innych źródeł. Do wykluczenia strony używa się między innymi noindex, ochrony hasłem albo usunięcia zasobu.

Sprawdź, czy:

• ważne sekcje nie są przypadkowo blokowane,
• środowisko testowe jest zabezpieczone, a nie tylko ukryte w robots.txt,
• Google może pobrać CSS, JavaScript i obrazy potrzebne do renderowania,
• mapa witryny ma prawidłowy adres i zawiera wyłącznie strony kanoniczne,
• metatag noindex nie pozostał po wdrożeniu wersji produkcyjnej.

Oceń canonicale i duplikaty

Adres kanoniczny wskazuje preferowaną wersję powielonej lub bardzo podobnej treści. Google traktuje canonical jako silny sygnał, ale może wybrać inny URL, jeżeli pozostałe sygnały są niespójne.

Kontroluj zgodność:

• rel="canonical",
• przekierowań,
• linków wewnętrznych,
• mapy XML,
• wersji językowych,
• protokołu i hosta.

Canonical powinien zwykle wskazywać działający adres 200, a nie stronę z błędem, przekierowanie lub URL oznaczony noindex.

Sprawdź renderowanie JavaScript

Google przetwarza aplikacje JavaScript w etapach: pobierania, renderowania i indeksowania. Treść generowana po stronie klienta może zostać przetworzona później niż HTML dostępny od razu, dlatego krytyczne informacje i linki nie powinny zależeć od kruchego skryptu.

W aplikacjach SPA i serwisach renderowanych hybrydowo sprawdź:

• HTML widoczny bez wykonania JavaScript,
• linki jako prawdziwe elementy <a href>,
• obsługę kodów statusu,
• metadane generowane dla każdego URL-a,
• zachowanie po bezpośrednim wejściu na podstronę,
• błędy hydracji i nieudane zapytania API,
• możliwość indeksowania paginacji i list przewijanych nieskończenie.

Skontroluj wersje językowe

W serwisie wielojęzycznym każda wersja powinna mieć własny, stabilny URL. Sprawdź:

• poprawne atrybuty hreflang,
• wzajemne wskazania pomiędzy wersjami,
• opcjonalny x-default,
• canonical wskazujący tę samą wersję językową,
• brak automatycznych przekierowań blokujących roboty,
• przetłumaczone tytuły, opisy, treść i elementy nawigacji.

Checklista technicznego SEO

• Ważne adresy zwracają 200.
• Przekierowania są pojedyncze i logiczne.
• Nie ma przypadkowych blokad w robots.txt.
• Produkcja nie zawiera niezamierzonego noindex.
• Mapa XML zawiera wyłącznie kanoniczne URL-e.
• Canonicale, linki i sitemap są spójne.
• JavaScript nie ukrywa krytycznej treści przed robotem.
• Strony 404 zwracają rzeczywisty status 404.
• Wersje językowe mają poprawne hreflang.
• Nie ma masowych duplikatów parametrów i filtrów.

2. Audyt treści i SEO na stronie

Każda podstrona powinna mieć jeden główny cel

Tytuł, H1, lead, treść i wezwanie do działania powinny odpowiadać na tę samą intencję. Jeżeli jedna strona próbuje jednocześnie sprzedawać usługę, definiować podstawowe pojęcia i rankować na kilkanaście niepowiązanych zapytań, zwykle nie robi dobrze żadnej z tych rzeczy.

Sprawdź:

• czy title jest unikalny i opisowy,
• czy główny nagłówek H1 odpowiada zawartości,
• czy opis w wynikach wyszukiwania zachęca do kliknięcia bez przesadnych obietnic,
• czy nagłówki H2 i H3 tworzą logiczną strukturę,
• czy odpowiedź pojawia się wcześnie, a nie po długim wstępie,
• czy artykuł pokazuje doświadczenie, przykłady i źródła,
• czy data aktualizacji odpowiada realnej zmianie treści.

Google rekomenduje treści pomocne, wiarygodne i tworzone przede wszystkim dla ludzi, a nie strony powstające wyłącznie po to, aby manipulować rankingiem.

Linkowanie wewnętrzne powinno tworzyć strukturę

Dobre linkowanie pomaga użytkownikowi przejść do kolejnego kroku i pokazuje wyszukiwarce relacje między tematami. Używaj opisowych anchorów zamiast wielu odnośników „kliknij tutaj”.

W tym artykule naturalnymi punktami przejścia są:

• Kondycja witryny POLPROG,
• Core Web Vitals w praktyce,
• Strategia web,
• Wydajność,
• Bezpieczeństwo,
• Jak zaplanować firmową stronę pozyskującą klientów.

W audytowanym serwisie sprawdź też strony osierocone, czyli takie, do których nie prowadzi żaden wewnętrzny link.

Obrazy, dane strukturalne i Open Graph

Obrazy powinny mieć sensowne nazwy, właściwe wymiary i opis alternatywny wtedy, gdy przekazują informację. Obraz dekoracyjny zwykle powinien mieć pusty alt="". Google obsługuje popularne formaty, w tym JPEG, PNG, WebP, SVG i AVIF.

Warto skontrolować:

• width i height, aby ograniczyć przesunięcia układu,
• srcset i sizes,
• kompresję oraz format,
• lazy loading poza pierwszym ekranem,
• tekst alternatywny,
• dane strukturalne zgodne z widoczną treścią,
• og:title, og:description, og:image i og:url.

Do praktycznej weryfikacji można użyć Konwertera i optymalizatora obrazów oraz Podglądu Open Graph.

SEO w wynikach opartych na AI

Google podkreśla, że dla funkcji AI w wyszukiwarce nadal obowiązują podstawowe praktyki SEO. Nie trzeba dodawać specjalnych plików ani nowych znaczników wyłącznie po to, aby pojawić się w AI Overviews lub AI Mode. Strona musi być dostępna do indeksowania i spełniać zwykłe wymagania wyszukiwarki.

Najbardziej rozsądna strategia to:

• publikowanie jasnych, kompletnych odpowiedzi,
• używanie źródeł i przykładów,
• aktualizowanie informacji, które szybko się zmieniają,
• unikanie masowo generowanych, powtarzalnych tekstów,
• dbanie o semantyczną strukturę i linkowanie,
• monitorowanie ruchu i zapytań w Search Console.

3. Core Web Vitals i wydajność

Aktualne progi

Core Web Vitals obejmują trzy metryki. Ocena powinna być wykonywana na 75. percentylu rzeczywistych wizyt, oddzielnie dla urządzeń mobilnych i komputerów.

Metryka	Co mierzy	Dobry wynik	Wymaga poprawy	Słaby wynik
LCP	czas pojawienia się największego elementu treści	≤ 2,5 s	2,5-4,0 s	> 4,0 s
INP	opóźnienie reakcji na interakcje	≤ 200 ms	200-500 ms	> 500 ms
CLS	stabilność wizualna układu	≤ 0,1	0,1-0,25	> 0,25

Dane terenowe pokazują doświadczenie prawdziwych użytkowników, a dane laboratoryjne pomagają odtworzyć problem. Nie należy ich mieszać. Strona może mieć dobry wynik w lokalnym Lighthouse, ale słaby INP na starszych telefonach użytkowników albo wolne LCP w określonym kraju.

Jak poprawić LCP

Najczęstsze przyczyny słabego LCP:

• wolny serwer lub brak cache,
• obraz hero o zbyt dużej wadze,
• zasób LCP odkrywany dopiero przez JavaScript,
• blokujące CSS i fonty,
• długi łańcuch żądań,
• ciężka logika wykonywana przed renderowaniem.

Działania:

• popraw TTFB i cache,
• serwuj obraz we właściwych wymiarach,
• użyj nowoczesnego formatu i kompresji,
• priorytetyzuj główny zasób,
• nie stosuj lazy loading dla obrazu LCP,
• ogranicz krytyczne CSS i skrypty,
• korzystaj z CDN tam, gdzie rzeczywiście skraca drogę do użytkownika.

Jak poprawić INP

INP pogarszają długie zadania na głównym wątku, nadmiar JavaScript, kosztowne renderowanie komponentów i obsługa zdarzeń wykonująca zbyt wiele pracy.

Sprawdź:

• długość zadań w Performance panel,
• skrypty firm trzecich,
• komponenty renderujące się po każdej zmianie,
• duże listy bez wirtualizacji,
• synchroniczne operacje na pamięci i DOM,
• walidację formularzy i animacje wykonywane podczas interakcji.

Dziel długie zadania, odkładaj pracę niekrytyczną i wysyłaj jak najmniej JavaScript do przeglądarki.

Jak poprawić CLS

Najczęstsze źródła przesunięć:

• obrazy i iframe bez wymiarów,
• reklamy bez zarezerwowanego miejsca,
• banery cookies wstrzykiwane nad treścią,
• późno ładowane fonty,
• komponenty dodawane przed istniejącą zawartością,
• animowanie właściwości wpływających na układ.

Rezerwuj przestrzeń, używaj stabilnych placeholderów i testuj cały przebieg ładowania, a nie tylko końcowy zrzut ekranu.

Nie optymalizuj wyłącznie wyniku Lighthouse

Lighthouse jest testem laboratoryjnym uruchamianym w kontrolowanych warunkach. Dobry proces łączy:

• Search Console i raport Core Web Vitals,
• dane CrUX lub RUM,
• Lighthouse i Performance panel,
• testy na wolniejszym urządzeniu,
• monitoring zmian po wdrożeniu.

4. Audyt dostępności według WCAG 2.2

WCAG 2.2 opisuje kryteria możliwe do testowania automatycznie i ręcznie. Sam skaner nie potwierdzi pełnej zgodności, ponieważ część kryteriów wymaga oceny kontekstu oraz działania interfejsu.

Klawiatura i fokus

Przejdź całą kluczową ścieżkę bez myszy:

• czy każdy element interaktywny jest osiągalny,
• czy kolejność fokusu jest logiczna,
• czy fokus jest wyraźnie widoczny,
• czy modal zatrzymuje fokus wewnątrz i oddaje go po zamknięciu,
• czy nie występuje pułapka klawiaturowa,
• czy istnieje sposób pominięcia powtarzalnej nawigacji.

Semantyka i czytniki ekranu

Sprawdź:

• jeden logiczny H1 i prawidłową hierarchię nagłówków,
• znaczniki header, nav, main, footer,
• prawdziwe przyciski i linki zamiast klikalnych div,
• nazwy dostępne dla ikon,
• komunikaty o zmianach dynamicznych,
• poprawną kolejność odczytu,
• język dokumentu w atrybucie lang.

ARIA powinna uzupełniać semantyczny HTML, a nie zastępować go bez potrzeby.

Formularze i błędy

Każde pole powinno mieć widoczną etykietę oraz programistyczne powiązanie z opisem. Błąd musi wskazywać, co należy poprawić, i nie może być sygnalizowany wyłącznie kolorem.

Przetestuj:

• etykiety i instrukcje,
• pola wymagane,
• autouzupełnianie danych,
• kolejność tabulacji,
• komunikaty błędów,
• podsumowanie błędów po wysłaniu,
• zachowanie przy powiększeniu i na małym ekranie,
• limity czasu i możliwość ich przedłużenia.

Kontrast, powiększenie i ruch

Kontroluj kontrast tekstu, ikon oraz stanów fokusu. Sprawdź stronę przy powiększeniu do 200% i 400%, przy większym rozmiarze tekstu oraz w wąskim widoku. Treść nie powinna wymagać poziomego przewijania poza elementami, dla których jest to uzasadnione.

Animacje powinny respektować prefers-reduced-motion, a automatycznie odtwarzane elementy muszą mieć mechanizm zatrzymania, jeśli wpływają na odbiór treści.

Checklista dostępności

• Całą ścieżkę można obsłużyć klawiaturą.
• Fokus jest widoczny i logiczny.
• Nagłówki oraz landmarki opisują strukturę.
• Przyciski i linki mają zrozumiałe nazwy.
• Formularze mają etykiety i czytelne błędy.
• Kontrast spełnia wymagania WCAG 2.2 AA.
• Treść działa po powiększeniu i reflow.
• Obrazy informacyjne mają odpowiedni tekst alternatywny.
• Ruch można ograniczyć.
• Główne zadania sprawdzono czytnikiem ekranu.

5. Audyt bezpieczeństwa i prywatności

HTTPS to początek, nie koniec

Cała witryna powinna działać przez HTTPS, bez aktywnej zawartości mieszanej. Sprawdź ważność certyfikatu, łańcuch zaufania, obsługiwane protokoły, automatyczne odnawianie i przekierowanie z HTTP. Lighthouse oznacza strony bez HTTPS jako problem bezpieczeństwa, ale nie wykonuje pełnego testu penetracyjnego.

Stan domeny i certyfikatu można zweryfikować w narzędziu DNS i SSL.

Nagłówki bezpieczeństwa

Nagłówki nie naprawią błędnej autoryzacji, ale ograniczają część klas ataków i niebezpiecznych zachowań przeglądarki. OWASP Secure Headers Project utrzymuje aktualne zalecenia i przykłady.

Sprawdź co najmniej:

• Content-Security-Policy,
• Strict-Transport-Security,
• X-Content-Type-Options: nosniff,
• Referrer-Policy,
• Permissions-Policy,
• ochronę przed osadzaniem przez frame-ancestors,
• bezpieczne atrybuty cookies: Secure, HttpOnly i właściwe SameSite.

CSP najlepiej wdrażać etapami, zaczynając od Content-Security-Policy-Report-Only, analizując raporty i dopiero później przechodząc do egzekwowania polityki. Gotową konfigurację trzeba dostosować do rzeczywistych zasobów witryny.

Do szybkiej kontroli użyj Inspektora nagłówków bezpieczeństwa.

OWASP Top 10:2025 jako mapa ryzyka

Aktualne OWASP Top 10:2025 obejmuje między innymi błędy kontroli dostępu, błędną konfigurację, problemy łańcucha dostaw, błędy kryptograficzne, injection, błędy projektowe, uwierzytelnianie, integralność danych, logowanie i obsługę wyjątków.

W audycie sprawdź praktycznie:

• czy użytkownik może odczytać lub zmienić dane innego użytkownika,
• czy panel administracyjny ma dodatkową ochronę,
• czy API weryfikuje uprawnienia po stronie serwera,
• czy zależności i obrazy kontenerów są aktualizowane,
• czy sekrety nie trafiają do repozytorium i kodu klienta,
• czy dane wejściowe są walidowane i kodowane,
• czy sesje wygasają i są unieważniane,
• czy logi nie zawierają haseł, tokenów ani danych wrażliwych,
• czy błędy nie ujawniają stack trace i szczegółów infrastruktury,
• czy istnieją kopie zapasowe i sprawdzony proces odtworzenia.

Dla aplikacji obsługujących logowanie, płatności lub dane klientów warto oprzeć zakres testów na OWASP ASVS, a nie tylko na krótkiej liście nagłówków.

Prywatność i analityka

Skontroluj:

• jakie skrypty uruchamiają się przed zgodą,
• czy formularze zbierają tylko potrzebne dane,
• okres retencji danych,
• dostęp pracowników i dostawców,
• możliwość wycofania zgody,
• tryb Consent Mode, jeśli jest używany,
• logowanie adresów IP i identyfikatorów,
• zgodność polityki prywatności z rzeczywistym działaniem strony.

Nie zakładaj, że baner cookies automatycznie zapewnia zgodność. Najważniejsze jest to, co strona faktycznie ładuje i wysyła.

6. UX, mobile i konwersja

Audyt techniczny może zakończyć się sukcesem, a strona nadal może nie realizować celu. Przejdź najważniejszą ścieżkę jak nowy użytkownik:

• czy w pierwszym ekranie wiadomo, czym zajmuje się firma,
• czy CTA opisuje konkretną czynność,
• czy nawigacja nie wymaga domyślania się,
• czy formularz prosi tylko o potrzebne informacje,
• czy błędy można łatwo naprawić,
• czy numer telefonu i e-mail są klikalne na mobile,
• czy elementy nie nachodzą na siebie,
• czy pop-upy nie zasłaniają treści,
• czy komunikaty sukcesu są jednoznaczne,
• czy strona działa przy wolnym połączeniu i przerwanym żądaniu.

Dodatkowo sprawdź stronę 404, pusty wynik wyszukiwania, brak produktu, niedostępną usługę, wygasłą sesję i błąd płatności. To właśnie stany wyjątkowe często decydują o tym, czy użytkownik wróci.

Jeżeli celem jest pozyskiwanie zapytań, pomocny będzie poradnik Jak zaplanować firmową stronę, która realnie pozyskuje klientów.

7. Pomiar, monitoring i jakość danych

Search Console pokazuje zachowanie strony w wynikach Google, a narzędzie analityczne zachowanie użytkownika po wejściu. Połączenie obu perspektyw pomaga odróżnić problem widoczności od problemu konwersji.

Sprawdź:

• czy usługa Search Console obejmuje właściwy wariant domeny,
• błędy indeksowania i ręczne działania,
• zapytania, strony, kraje i urządzenia,
• zmiany kliknięć oraz wyświetleń po wdrożeniu,
• kompletność zdarzeń analitycznych,
• wykluczenie ruchu wewnętrznego i botów,
• poprawność lejka konwersji,
• alerty błędów JavaScript i serwera,
• monitoring dostępności oraz certyfikatu.

Nie naprawiaj wszystkiego naraz bez punktu odniesienia. Zapisz stan bazowy i wdrażaj grupy zmian, aby wiedzieć, co rzeczywiście poprawiło wynik.

Ile czasu zajmuje audyt?

Poniższe wartości są praktycznymi szacunkami, a nie oficjalnym standardem. Zakres zależy od liczby szablonów, dostępu do danych, technologii i poziomu ryzyka.

Zakres	Orientacyjny czas	Co obejmuje
Szybka kontrola jednego URL-a	15-30 min	status, meta, podstawowe CWV, HTTPS, najważniejsze błędy
Mała strona firmowa	2-6 godz.	próbka podstron, SEO, CWV, dostępność, bezpieczeństwo, UX
Serwis treściowy lub wielojęzyczny	1-3 dni	szablony, indeksowanie, hreflang, linkowanie, dane i priorytety
Sklep internetowy	3-7 dni	kategorie, produkty, filtry, checkout, dane strukturalne, wydajność
Aplikacja webowa	5-10+ dni	role, autoryzacja, przepływy, API, stany błędów, testy ręczne
Audyt bezpieczeństwa wysokiego ryzyka	osobny zakres	model zagrożeń, ASVS, testy aplikacyjne i infrastrukturalne

Koszt rośnie nie z liczbą URL-i, lecz z liczbą różnych zachowań. Tysiąc produktów opartych na jednym szablonie może być prostsze do oceny niż aplikacja z dziesięcioma rolami i wieloma stanami.

Jak ustalać priorytety napraw?

Użyj prostego modelu: wpływ × zasięg × ryzyko ÷ koszt wdrożenia.

P0 - napraw natychmiast

• strona lub kluczowa funkcja nie działa,
• ważne sekcje są zablokowane przed indeksowaniem,
• występuje wyciek danych albo obejście autoryzacji,
• certyfikat wygasł lub pojawia się aktywna mixed content,
• migracja generuje masowe błędy i utratę adresów,
• formularz nie dostarcza zgłoszeń.

P1 - wysoki priorytet

• słabe CWV na najważniejszych szablonach,
• poważne bariery klawiatury i formularzy,
• błędne canonicale albo hreflang,
• nieczytelna oferta i utrudniona konwersja,
• krytyczne zależności bez aktualizacji,
• brak monitoringu istotnych błędów.

P2 - zaplanuj w najbliższym cyklu

• nieunikalne tytuły i słabe linkowanie,
• brakujące alty,
• ciężkie obrazy poza pierwszym ekranem,
• niespójne dane strukturalne,
• niedopracowane strony 404 i stany puste,
• problemy dotyczące mniej popularnych szablonów.

P3 - optymalizacje i rozwój

• dodatkowe dane strukturalne,
• dalsza redukcja wagi,
• eksperymenty z copy i CTA,
• rozbudowa treści,
• porządki w komponentach i dokumentacji.

Plan napraw na 30, 60 i 90 dni

Pierwsze 30 dni

Usuń problemy P0, popraw indeksowanie, przekierowania, HTTPS, formularze i błędy powodujące utratę danych. Ustal pomiar bazowy.

Do 60 dni

Zajmij się najważniejszymi szablonami: Core Web Vitals, klawiatura, formularze, treść, linkowanie i bezpieczeństwo aplikacji. Wdróż monitoring regresji.

Do 90 dni

Dopracuj mniej krytyczne szablony, uporządkuj proces publikacji, dodaj testy automatyczne w CI i zaplanuj cykliczny audyt po większych zmianach.

Kompletna checklista przed zamknięciem audytu

SEO i indeksowanie

• Roboty mogą pobrać ważne strony i zasoby.
• Mapa XML jest aktualna.
• Canonicale, przekierowania i linki są spójne.
• Nie ma przypadkowego noindex.
• Ważne strony mają unikalny tytuł, H1 i treść.
• Linkowanie prowadzi do stron biznesowo istotnych.
• Wersje językowe mają poprawne hreflang.
• Dane strukturalne odpowiadają widocznej treści.
• Metadane Open Graph są kompletne.

Wydajność

• LCP, INP i CLS spełniają progi na danych terenowych.
• Obraz LCP ma właściwy rozmiar i priorytet.
• JavaScript nie blokuje interakcji.
• Obrazy mają wymiary i odpowiedni format.
• Fonty oraz zasoby krytyczne nie powodują opóźnień.
• Wyniki są monitorowane po wdrożeniu.

Dostępność

• Strona działa bez myszy.
• Fokus jest widoczny.
• Semantyka i kolejność nagłówków są logiczne.
• Formularze mają etykiety i użyteczne błędy.
• Kontrast i reflow spełniają WCAG 2.2 AA.
• Interfejs został sprawdzony czytnikiem ekranu.

Bezpieczeństwo i prywatność

• HTTPS działa wszędzie i certyfikat jest monitorowany.
• Cookies sesyjne mają bezpieczne atrybuty.
• Nagłówki są dopasowane do aplikacji.
• Uprawnienia są weryfikowane na serwerze.
• Zależności i sekrety są kontrolowane.
• Logi i alerty umożliwiają reakcję.
• Kopie zapasowe zostały przetestowane.
• Skrypty śledzące respektują zgodę.

UX i biznes

• Oferta jest zrozumiała bez przewijania całej strony.
• CTA prowadzą do właściwego działania.
• Formularze i checkout działają na mobile.
• Stany błędów pomagają użytkownikowi.
• Zdarzenia i konwersje są mierzone poprawnie.
• Każda poprawka ma właściciela, priorytet i termin.

Jak wykorzystać narzędzie Kondycja witryny POLPROG?

Kondycja witryny pozwala rozpocząć audyt od jednego adresu URL i sprawdzić SEO, wydajność, dostępność, bezpieczeństwo oraz dobre praktyki. Testy są wykonywane po stronie serwera, a narzędzie nie wymaga rejestracji.

Najlepszy proces wygląda następująco:

1. Przeskanuj stronę główną oraz każdy ważny szablon.
2. Zapisz błędy krytyczne i powtarzające się wzorce.
3. Potwierdź CWV danymi rzeczywistymi.
4. Wykonaj ręczny test klawiatury, formularzy i głównych ścieżek.
5. Sprawdź oddzielnie nagłówki bezpieczeństwa, DNS i SSL oraz Open Graph.
6. Ułóż backlog według wpływu i ryzyka.
7. Powtórz test po wdrożeniu i monitoruj regresje.

Ostateczny wniosek

Najlepszy audyt strony w 2026 roku nie kończy się dokumentem z setką ostrzeżeń. Kończy się krótką, uporządkowaną listą działań, która rozdziela problemy krytyczne od kosmetycznych, wskazuje właściciela i pozwala sprawdzić wynik po wdrożeniu.

Najpierw upewnij się, że strona jest dostępna, indeksowalna i bezpieczna. Następnie popraw główne ścieżki użytkownika, Core Web Vitals i dostępność. Dopiero później optymalizuj szczegóły. Taka kolejność zwykle daje większą wartość niż pogoń za idealnym wynikiem w pojedynczym skanerze.