Narzędzie poniżej pobiera publiczną wersję jednego adresu i mówi, co z niej wynika. Nie loguje się, nie skanuje sieci i nie zgaduje. Czyta to samo, co przeglądarka Twojego gościa: kod odpowiedzi po przekierowaniach, nagłówki, HTML i te zasoby, które ten HTML każe pobrać przed pierwszym malowaniem. Te zasoby naprawdę pobiera i waży, zamiast szacować.
Sprawdzenie strony
Sprawdź, co Twoja strona pokazuje publicznie
Podaj adres strony, którą prowadzisz. Pobieramy ją tak, jak zrobiłaby to przeglądarka, i pokazujemy, co z niej wynika, razem z tym, co dokładnie odczytaliśmy.
Co sprawdzamy
Nagłówki odpowiedzi, czas do pierwszego bajtu, tytuł i opis, kanoniczny adres, nagłówki treści, dane strukturalne, obrazy, robots.txt i mapę witryny, a przy WordPressie także to, co o zainstalowanych wtyczkach da się odczytać ze źródła strony. Dodatkowo pobieramy zasoby blokujące pierwsze wyrenderowanie i sumujemy ich rzeczywistą wagę.
Czego nie sprawdziliśmy
- panel administracyjny i cokolwiek za logowaniem
- baza danych, jej rozmiar i stan
- kopie zapasowe, ich istnienie i możliwość odtworzenia
- porównanie wersji wtyczek z bazą znanych podatności
- to, jak strona zachowuje się dla zalogowanego użytkownika
- inne podstrony niż ten jeden podany adres
Co właściwie mierzy to sprawdzenie
Pierwsza warstwa to własne żądania HTTP z brzegu Cloudflare: czas do pierwszego bajtu, kod odpowiedzi po przejściu przekierowań, nagłówki bezpieczeństwa, nagłówki cache i kompresja. Druga to sam HTML, z którego da się odczytać tytuł, opis, kanoniczny adres, liczbę nagłówków pierwszego poziomu, bloki JSON-LD, atrybut języka i sposób podania obrazów.
Trzecia warstwa to waga startu strony i to ona zwykle robi największe wrażenie na właścicielu. Narzędzie zbiera z sekcji head wszystkie arkusze stylów i wszystkie skrypty bez atrybutu defer, czyli dokładnie to, co przeglądarka musi pobrać, zanim cokolwiek narysuje. Potem pobiera je i podaje realną liczbę kilobajtów, osobno dla CSS i dla JavaScriptu, wraz z czasem najwolniejszego z nich i listą obcych domen, z których przychodzą.
Dla WordPressa dochodzi kilka rzeczy publicznych z założenia, a bywających zaskoczeniem. Ścieżki do plików wtyczek i motywów zdradzają, co masz zainstalowane i w jakiej wersji, bo numer wersji zwykle siedzi w adresie pliku CSS. Punkt końcowy REST z listą użytkowników odpowiada bez logowania, jeśli nikt go nie zamknął. Plik xmlrpc.php często nadal odpowiada, choć w większości instalacji nie jest do niczego potrzebny.
Dlaczego nie ma tu wyniku w skali do stu
To nie jest uproszczenie ani brak budżetu na zewnętrzne API. Punktacja jest modelem, a model trzeba potem przetłumaczyć z powrotem na pracę. Właściciel strony, który dostaje czterdzieści siedem na sto, wie dokładnie tyle, co przed sprawdzeniem. Właściciel, który czyta “dziewiętnaście żądań blokuje pierwsze malowanie, ważą razem 1,4 MB, jedenaście z nich pochodzi z dwóch obcych domen, najwolniejsze wraca po 880 ms”, ma już listę zadań i wie, od czego zacząć.
Ta warstwa ma też sufit i trzeba go nazwać. Mierzymy wagę i czas odpowiedzi, a nie doświadczenie Twoich użytkowników. To nie jest pomiar Core Web Vitals i nie zastępuje go. Dane pola zbiera Google od realnych odwiedzających przez dwadzieścia osiem dni i masz je za darmo we własnej Search Console, w raporcie podstawowych wskaźników internetowych. Jeśli chcesz wiedzieć, jak Twoja strona zachowuje się na telefonie w Radomiu przy słabym zasięgu, to jest jedyne miejsce, które Ci odpowie. Nasze liczby mówią, co konkretnie w kodzie strony ten wynik psuje.
Czego to sprawdzenie nie widzi
Lista rzeczy poza zasięgiem jest krótka i warto ją znać, zanim uznasz wynik za pełny obraz. Narzędzie nie wchodzi do panelu administracyjnego, więc nie wie nic o kontach, rolach ani o tym, kto ostatnio logował się z nieznanego adresu. Nie widzi bazy danych, więc nie powie, czy tabele puchną od porzuconych transientów. Nie sprawdza kopii zapasowych, bo kopie z definicji nie są publiczne. Nie porównuje wykrytych wersji wtyczek z bazą podatności, więc odczytana wersja to fakt, a nie ocena ryzyka. I sprawdza dokładnie ten jeden adres, który podałeś, nie cały serwis.
Osobna sprawa to widok zalogowanego użytkownika. WordPress serwuje zalogowanym zupełnie inny zestaw zapytań i zwykle wyłącza dla nich cache strony. Sklep, który dla gościa odpowiada w kilkaset milisekund, dla zalogowanego klienta z pełnym koszykiem potrafi odpowiadać kilka razy wolniej. Tego sprawdzenie z zewnątrz nie pokaże i żadne narzędzie bez dostępu do konta tego nie pokaże.
Jak czytać poszczególne klasy znalezisk
Znaleziska wysokiego poziomu to rzeczy, które kosztują pieniądze albo bezpieczeństwo od razu. Brak HTTPS na docelowym adresie, znacznik noindex na stronie, która ma się indeksować, otwarty punkt końcowy z listą użytkowników, brak czterech z pięciu nagłówków bezpieczeństwa, wolny pierwszy bajt. Tu trafia też ciężki start: piętnaście żądań blokujących albo ponad pół megabajta przed pierwszym malowaniem. Każde z nich ma jedno konkretne rozwiązanie, zwykle w konfiguracji serwera albo we wtyczce, którą już masz.
Znaleziska średniego poziomu opisują stan, który da się utrzymać przez rok bez awarii, ale który powoli oddaje przewagę. Brak cache na HTML, zasoby blokujące serwowane bez kompresji, fonty ładowane z serwerów Google zamiast z własnej domeny, brakujący opis meta, brak bloku danych strukturalnych, obrazy bez wymiarów, brak mapy witryny. Właściciel strony o stabilnym ruchu może je spokojnie zaplanować na najbliższy przegląd. Właściciel sklepu w sezonie powinien wziąć z tej listy kompresję, cache i obrazy, bo to one przekładają się na koszyk najszybciej.
Znaleziska niskiego poziomu to głównie ślady, jakie zostawia po sobie stos technologiczny: numer wersji WordPressa w meta generatorze, nazwa i wersja serwera w nagłówku, wiele nagłówków pierwszego poziomu na jednej stronie, krótki czas życia cache na plikach statycznych, obrazy bez leniwego ładowania. Nic z tego nie przewróci serwisu. Warto je posprzątać przy okazji innej pracy, nie zamiast niej.
Osobno stoją potwierdzenia. Gdy narzędzie pisze, że nagłówki bezpieczeństwa są w komplecie, że HTML wraca z cache, że dane strukturalne są obecne i że start strony jest lekki, to nie jest wypełniacz. To odpowiedź na pytanie, które właściciel strony zadaje najczęściej: czy poprzednia ekipa zrobiła robotę.
Kiedy uczciwa odpowiedź brzmi: nic nie trzeba robić
Zdarza się to częściej, niż sugeruje rynek narzędzi diagnostycznych. Strona firmowa na dobrym hostingu, z aktualnym WordPressem, kompletem nagłówków, sensownym cache i lekkim startem, nie potrzebuje żadnej naszej usługi. Jeśli raport pokazuje wyłącznie znaleziska niskiego poziomu i potwierdzenia, to jest właśnie ten przypadek. Zamknij kartę i wróć za pół roku.
Jest też stan pośredni, w którym najrozsądniejsze jest odłożenie decyzji. Jeśli tydzień temu zmieniałeś motyw albo hosting, nasze liczby opisują już nową wersję, ale raport w Search Console przez kolejny miesiąc będzie jeszcze pokazywał starą. Nie zamawiaj niczego na podstawie dwóch źródeł, które opisują dwa różne serwisy. Poczekaj, aż okno się przesunie.
I trzeci przypadek: znalezisko realne, ale nie Twoje. Brakujący nagłówek bezpieczeństwa, brak kompresji albo brak cache na HTML to często ustawienie po stronie hostingu, nie strony. Wtedy jedna wiadomość do wsparcia technicznego hostingu załatwia sprawę taniej niż jakikolwiek projekt.
Co robimy z adresem, który podasz
Pobieramy publiczne strony pod wskazanym adresem, nie logujemy się nigdzie i nie przechowujemy niczego poza anonimowym licznikiem uruchomień. Raport nie trafia do żadnej listy mailingowej, bo nie prosimy o adres e-mail. Jeśli klikniesz przycisk kontaktu, formularz wypełni się adresem strony i trzema najpoważniejszymi znaleziskami, a Ty zobaczysz całą treść przed wysłaniem.
Co dalej, jeśli raport pokazał coś realnego
Powtarzające się znaleziska średniego poziomu to zwykle brak stałej opieki, nie pojedynczy błąd, i wtedy odpowiedzią jest utrzymanie stron WordPress. Ciężki start i wolny pierwszy bajt prowadzą do przyspieszania WordPressa. Otwarty punkt końcowy z użytkownikami, odpowiadający xmlrpc.php i brak nagłówków to materiał na audyt bezpieczeństwa WordPress, bo tych trzech rzeczy nie da się sensownie naprawiać osobno.
