Raport Podstawowe wskaźniki internetowe w Search Console: jak z niego korzystać

Czym jest raport Podstawowe wskaźniki internetowe i skąd bierze dane

Jest to raport w Google Search Console, który ocenia strony Państwa witryny na podstawie danych zebranych od prawdziwych odwiedzających. Podstawowe wskaźniki internetowe, po angielsku Core Web Vitals, to trzy miary: szybkość wczytywania, szybkość reakcji na działanie użytkownika oraz stabilność układu. W pomocy Search Console ten sam raport bywa nazywany raportem dotyczącym Core Web Vitals, więc obie nazwy oznaczają to samo miejsce.

Najważniejsze jest źródło danych. Jak wyjaśnia pomoc Search Console, liczby pochodzą z raportu na temat użytkowania Chrome, w skrócie CrUX, czyli ze zbioru anonimowych informacji o tym, jak strony działały u osób, które je faktycznie odwiedziły. Takie dane Google nazywa danymi zgromadzonymi albo danymi z rzeczywistego użytkowania. Nie jest to więc wynik pojedynczego testu wykonanego na szybkim komputerze w biurze, tylko obraz tego, co dzieje się na telefonach i komputerach klientów, przy ich łączach internetowych.

Z tego samego źródła wynikają dwie cechy raportu, o których łatwo zapomnieć. Po pierwsze, dane obejmują ostatnie 28 dni, więc raport reaguje na zmiany z opóźnieniem. Po drugie, wyniki łączą wejścia ze wszystkich lokalizacji. Pomoc Search Console zaznacza, że wolne połączenia w jednym kraju mogą obniżyć ogólny wynik witryny. Sklep z Poznania, który sprzedaje także za granicę, może mieć słabsze liczby niż wynikałoby to z testów wykonanych w Polsce.

Trzy wskaźniki, na których opiera się raport

Raport korzysta z trzech miar opisanych w serwisie web.dev. LCP, czyli największe wyrenderowanie treści, mówi o szybkości wczytywania: mierzy, po jakim czasie na ekranie pojawia się największy element widocznej części strony. INP, czyli interakcja do kolejnego wyrenderowania, opisuje szybkość reakcji strony na kliknięcie lub dotknięcie. CLS, czyli skumulowane przesunięcie układu, dotyczy stabilności wizualnej, a więc tego, czy elementy strony nie przeskakują w trakcie korzystania z niej.

Każdemu z tych wskaźników poświęciliśmy osobne omówienie: LCP i przyczyny wolnego wyświetlania największego elementu, INP i opóźniona reakcja na kliknięcie oraz CLS i przeskoki układu. Tutaj skupiamy się na samym raporcie: co pokazuje, jak go czytać i jak z niego przejść do naprawy.

Gdzie znaleźć raport i co widać na ekranie przeglądu

Raport znajduje się w Search Console, w menu bocznym usługi, pod nazwą Podstawowe wskaźniki internetowe. Bezpośredni odnośnik do niego podaje też strona pomocy Search Console. Po otwarciu pojawia się ekran przeglądu z dwoma osobnymi wykresami: jednym dla urządzeń mobilnych i jednym dla komputerów.

Podział na dwa rodzaje urządzeń ma znaczenie praktyczne. Status jest ustalany oddzielnie dla telefonów i oddzielnie dla komputerów, więc ta sama podstrona może być oceniona dobrze na komputerze i słabo na telefonie. W firmach usługowych, do których klienci trafiają głównie z telefonu, warto zacząć od wykresu mobilnego. Hydraulik z Łodzi, którego klienci szukają pomocy w nagłej sytuacji, powinien w pierwszej kolejności interesować się właśnie nim.

Przy każdym z dwóch wykresów znajduje się przycisk otwierający raport szczegółowy dla danego rodzaju urządzeń. Dopiero tam widać pełny obraz: wykres z liczbą adresów w poszczególnych statusach dzień po dniu oraz tabele z listą problemów.

Wykres i dwie tabele w raporcie szczegółowym

Wykres w raporcie szczegółowym pokazuje, ile adresów miało danego dnia status słaby, wymagający poprawy lub dobry. Karty nad wykresem pozwalają włączać i wyłączać poszczególne statusy, co ułatwia ocenę, czy liczba słabych adresów rośnie, czy maleje.

Pod wykresem znajduje się tabela zatytułowana „Dlaczego adresy URL nie są uważane za prawidłowe”. Zawiera ona problemy pogrupowane według statusu i rodzaju, na przykład kłopot z LCP w statusie słabym na urządzeniach mobilnych, wraz z małym wykresem trendu i liczbą adresów, których problem dotyczy. Druga tabela, otwierana odnośnikiem do danych o poprawnych adresach, pokazuje grupy stron z dobrymi wynikami.

Komunikat o braku danych

Zdarza się, że raport nie pokazuje niczego poza informacją o braku dostępnych danych. Według pomocy Search Console dzieje się tak w dwóch sytuacjach: gdy usługa została dopiero dodana do Search Console albo gdy w zbiorze CrUX jest zbyt mało danych dla danego rodzaju urządzeń. W nowych usługach publikacja danych może potrwać kilka dni. Mała strona firmowa z niewielkim ruchem, na przykład strona kancelarii z Krakowa, może przez długi czas nie mieć w raporcie żadnych liczb. Nie świadczy to o błędzie konfiguracji. W takiej sytuacji pozostają testy pojedynczych adresów w PageSpeed Insights lub w Lighthouse, o których piszemy dalej.

Statusy słaby, wymaga poprawy i dobry: co oznaczają

Każda grupa adresów otrzymuje jeden z trzech statusów, zależnie od tego, w jakim przedziale mieszczą się jej wskaźniki. W polskiej wersji pomocy Search Console statusy noszą nazwy „Słabej jakości”, „Wymagana poprawa” i „Dobrej jakości”. W rozmowach zwykle skraca się je do określeń słaby, wymaga poprawy i dobry, i tak też będziemy je dalej nazywać.

Progi dla poszczególnych wskaźników podaje pomoc Search Console i są one takie same, jak w dokumentacji narzędzia PageSpeed Insights.

O statusie decyduje najgorszy wskaźnik

Status grupy jest równy statusowi jej najsłabszego wskaźnika. Jeżeli grupa ma dobry LCP i dobry INP, ale CLS mieści się w przedziale słabym, cała grupa zostaje oznaczona jako słaba. Dlatego nie wystarczy poprawić jednej miary: do statusu dobrego potrzebne są dobre wartości wszystkich trzech.

W praktyce oznacza to, że strona, która wczytuje się szybko, może mimo to trafić do grupy słabych adresów. Częsty przypadek to sklep internetowy, w którym zdjęcia wyświetlają się sprawnie, ale baner wczytywany z opóźnieniem przesuwa całą treść w dół. Szybkość jest wtedy w porządku, a o statusie przesądza stabilność układu.

Co oznacza liczba podana przy grupie

Wartość widoczna przy grupie nie jest średnią. Raport podaje 75. percentyl, czyli wartość, w której lub poniżej której mieści się trzy czwarte wyświetleń stron z danej grupy. Jeżeli przy grupie widnieje LCP równy 3,1 sekundy, to trzy na cztery wyświetlenia miały LCP nie dłuższy niż 3,1 sekundy, a pozostałe były wolniejsze.

Takie ujęcie ma swój sens. Serwis web.dev wyjaśnia, że próg jest liczony na 75. percentylu wczytań, osobno dla urządzeń mobilnych i komputerów, a strona spełnia wymagania dopiero wtedy, gdy wszystkie trzy wskaźniki osiągają na tym poziomie wartości docelowe. Chodzi o to, aby dobra ocena oznaczała wygodę większości odwiedzających, także tych ze słabszym telefonem lub wolniejszym łączem, a nie tylko osób z najlepszym sprzętem.

Grupy adresów i przykładowe adresy: jak je rozumieć

Raport nie ocenia każdej podstrony z osobna, tylko łączy adresy w grupy stron, których działanie jest dla użytkownika podobne. W praktyce w jednej grupie znajdują się zwykle podstrony zbudowane w ten sam sposób, na przykład karty produktów albo wpisy blogowe. Założenie jest takie, że strony o podobnej budowie mają podobne kłopoty i wspólną przyczynę, którą da się usunąć jedną poprawką.

To rozwiązanie jest wygodne, ale wymaga ostrożności w odczytywaniu liczb. Wartości LCP, INP i CLS podane przy grupie dotyczą całej grupy, a nie pojedynczego adresu. Pomoc Search Console wprost zastrzega, że raport nie służy do sprawdzania stanu konkretnej podstrony, ponieważ dany adres może odstawać od reszty grupy.

Przykładowe adresy to próbka, a nie pełna lista

Po kliknięciu wiersza w tabeli problemów otwiera się strona szczegółów z tabelą przykładów. Zawiera ona wybrane adresy z danej grupy, ułożone według liczby wyświetleń, od najczęściej odwiedzanych. Według pomocy Search Console tabela mieści do 200 wierszy, a kolumna z wartością wskaźnika nosi nazwę zależną od problemu, na przykład „LCP grupy” albo „CLS grupy”.

Warto zapamiętać trzy ograniczenia tej listy. Raport obejmuje wyłącznie adresy zaindeksowane. Pokazuje wybrane przykłady, a nie wszystkie podstrony z problemem, więc liczba adresów podana przy grupie może być wielokrotnie większa niż liczba przykładów. Dane są ponadto przypisywane do adresu, pod którym strona została rzeczywiście wyświetlona, a nie do adresu kanonicznego. Sklep z filtrowaniem i sortowaniem może więc mieć w raporcie adresy z parametrami, których właściciel nie uważa za osobne podstrony. O samym mechanizmie wskazywania wersji podstawowej piszemy we wpisie o adresie kanonicznym.

Gdy danych jest za mało: grupa źródłowa

Jeżeli dla zwykłej grupy brakuje wystarczającej ilości danych, Search Console sięga po szerszą grupę źródłową, obejmującą wszystkie adresy w obrębie tego samego protokołu, hosta i portu. W uproszczeniu jest to ocena całej witryny pod danym adresem głównym. Jeżeli i tu danych jest zbyt mało, grupa nie zostanie wyświetlona, a adresy bez minimalnej ilości danych o LCP lub CLS są w raporcie pomijane.

Dla małych firm ma to prosty skutek. Strona z kilkunastoma podstronami i umiarkowanym ruchem często ma w raporcie jedną grupę obejmującą całą witrynę. Nie da się wtedy z samego raportu odczytać, czy problem dotyczy strony głównej, oferty, czy formularza kontaktowego. Trzeba to ustalić testami poszczególnych adresów.

Jak przejść od grupy adresów do konkretnej przyczyny

Raport w Search Console odpowiada na pytanie, które strony i który wskaźnik sprawiają kłopot, ale nie mówi, co dokładnie go powoduje. Przyczynę ustala się w kolejnym narzędziu, testując przykładowe adresy z grupy. Pomoc Search Console wskazuje do tego PageSpeed Insights, które podaje szybkość działania strony na telefonach i komputerach oraz podpowiada sposoby poprawy.

1. Ustalenie, który wskaźnik zawodzi

   W tabeli problemów każdy wiersz dotyczy jednego wskaźnika i jednego statusu. Wiersz o kłopocie z INP na urządzeniach mobilnych kieruje prace w zupełnie inną stronę niż wiersz o LCP.

2. Otwarcie strony szczegółów i listy przykładów

   Po kliknięciu wiersza widać grupy adresów z danym problemem oraz przykładowe adresy. Warto zanotować, jakiego rodzaju podstrony się powtarzają: karty produktów, listy kategorii, wpisy, strona główna.

3. Test kilku przykładowych adresów

   Kilka adresów z góry listy, czyli tych z największą liczbą wyświetleń, należy sprawdzić w PageSpeed Insights, osobno dla telefonów i komputerów.

4. Szukanie części wspólnej

   Jeżeli na wszystkich testowanych adresach powtarza się ten sam element, na przykład duże zdjęcie u góry strony albo ten sam skrypt, to najpewniej on jest przyczyną problemu całej grupy.

5. Poprawka w szablonie i ponowny test

   Zmianę wprowadza się w miejscu wspólnym dla całej grupy, a następnie sprawdza zewnętrznym testem, zanim uruchomi się sprawdzenie poprawki w Search Console.

Dwa rodzaje danych w PageSpeed Insights

PageSpeed Insights pokazuje dla jednego adresu dwa zestawy liczb i trzeba je odróżniać. Zgodnie z dokumentacją narzędzia pierwszy zestaw to dane z rzeczywistego użytkowania z ostatnich 28 dni, pochodzące z tego samego zbioru CrUX, z którego korzysta Search Console. Drugi zestaw to dane laboratoryjne z narzędzia Lighthouse, czyli wynik symulowanego wczytania strony w ustalonych warunkach.

Narzędzie najpierw szuka danych z rzeczywistego użytkowania dla konkretnego adresu. Jeżeli ich nie ma, sięga po dane zbiorcze dla całej witryny, a jeżeli i tych jest za mało, nie pokaże ich wcale. Część laboratoryjna jest dostępna zawsze i to ona zawiera listę zaleceń oraz wskazanie elementów, które spowalniają stronę. Szerzej opisujemy to we wpisie o tym, jak czytać raport PageSpeed Insights, a sam audyt w przeglądarce we wpisie o Lighthouse w Chrome.

Dlaczego liczby z testu różnią się od liczb w raporcie

Różnice są czymś zwyczajnym i mają kilka źródeł. Pomoc Search Console podaje dwa: konkretny adres może odstawać od reszty swojej grupy, a ponadto PageSpeed Insights usuwa z adresu wszystkie parametry, podczas gdy raport traktuje adresy z parametrami jako odrębne strony.

Trzecie źródło to różnica między danymi laboratoryjnymi a rzeczywistymi, opisana w serwisie web.dev. Test laboratoryjny wykonuje się na jednym urządzeniu, w jednej sieci i z jednej lokalizacji, natomiast prawdziwi odwiedzający korzystają z bardzo różnego sprzętu. Test nie odtwarza też chwili, w której człowiek faktycznie klika, ani przesunięć układu pojawiających się podczas przewijania. Lighthouse w ogóle nie mierzy INP, ponieważ w teście nie ma działań użytkownika. Według web.dev do ustalania, co jest najpilniejsze, służą dane rzeczywiste, a dane laboratoryjne do szukania przyczyn i sprawdzania zmian przed wdrożeniem.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Od czego zacząć naprawę i komu przekazać raport

Kolejność prac podaje sama pomoc Search Console: najpierw adresy w statusie słabym, potem adresy wymagające poprawy. W obrębie każdego statusu warto zacząć od problemów, które dotyczą największej liczby adresów albo najważniejszych podstron. Dla sklepu będą to zwykle karty produktów i listy kategorii, dla firmy usługowej strona główna i strony poszczególnych usług.

Takie podejście pozwala oszczędzić czas. Jedna poprawka w szablonie karty produktu może zmienić wynik setek adresów naraz, podczas gdy dopracowywanie pojedynczej, rzadko odwiedzanej podstrony niczego w raporcie nie zmieni. Z naszej praktyki wynika, że większość pracy sprowadza się do kilku wspólnych elementów: zdjęcia głównego, czcionek, skryptów zewnętrznych usług oraz miejsc zarezerwowanych na banery i komunikaty.

Pomoc Search Console wymienia też dwie ogólne wskazówki dla osób zajmujących się stroną od strony technicznej: utrzymanie wagi strony wraz z zasobami poniżej 500 KB oraz ograniczenie liczby zasobów do 50. Są to zalecenia kierunkowe. Na wielu współczesnych stronach trudno je spełnić w całości, ale dobrze pokazują, że lżejsza strona z mniejszą liczbą plików ma łatwiejszą drogę do dobrych wyników.

Udostępnianie raportu osobie technicznej

Osobom, które nie zajmują się kodem strony, pomoc Search Console radzi przekazać raport programiście lub osobie odpowiedzialnej za stronę. Służy do tego funkcja udostępniania dostępna na stronie szczegółów problemu. Tworzy ona odnośnik, który daje wgląd wyłącznie w bieżącą stronę problemu, bez dostępu do reszty usługi, i który można później unieważnić. Obok znajduje się funkcja eksportu, która zapisuje dane z wykresu i tabeli do pliku.

Do przekazywanego odnośnika warto dołączyć krótką notatkę: którego wskaźnika dotyczy problem, na jakich urządzeniach występuje, jakie rodzaje podstron powtarzają się wśród przykładów oraz co pokazały testy w PageSpeed Insights. Wykonawca nie musi wtedy zaczynać analizy od początku. Gdy problemów jest wiele i dotyczą różnych obszarów strony, lepszym punktem wyjścia bywa audyt SEO, który porządkuje poprawki według ważności.

Sprawdzenie poprawki: kiedy je uruchomić i ile trwa weryfikacja

Sprawdzenie poprawki uruchamia się dopiero po wdrożeniu zmian na stronie i potwierdzeniu ich zewnętrznym testem, a weryfikacja trwa 28 dni. Na stronie szczegółów problemu znajduje się przycisk rozpoczynający śledzenie, w części materiałów pomocy nazywany też przyciskiem sprawdzenia poprawki. Jego kliknięcie rozpoczyna, jak podaje pomoc Search Console, czterotygodniowy okres monitorowania.

Długość tego okresu wynika z natury danych. Raport opiera się na pomiarach z ostatnich 28 dni, więc dopiero po takim czasie w danych zostają wyłącznie wejścia z okresu po poprawce. Search Console nie wykonuje tu własnego testu i, co pomoc wyraźnie zaznacza, kliknięcie przycisku nie powoduje ponownego indeksowania strony. Narzędzie po prostu obserwuje, czy w napływających danych od użytkowników problem nadal się pojawia.

Zasada rozstrzygnięcia jest prosta i surowa. Problem zostaje uznany za naprawiony, jeżeli w okresie obserwacji nie wystąpił w żadnym adresie. Jeżeli wystąpi choćby w jednym, weryfikacja kończy się niepowodzeniem. Dlatego nie warto uruchamiać jej na próbę ani po naprawieniu tylko części podstron z grupy.

Osobny stan mają też poszczególne adresy. „Oczekuje” oznacza, że Google czeka na wystarczającą ilość danych, „Powodzenie”, że problem w danym adresie już nie występuje, a „Niepowodzenie”, że występuje nadal. Po nieudanej weryfikacji można przejrzeć jej szczegóły, poprawić wskazane adresy i rozpocząć nową weryfikację. Stan „Nie dotyczy” pokazuje przy okazji, że klikanie przycisku nie jest warunkiem poprawy statusu: raport i tak zaktualizuje się sam, gdy dane od użytkowników zaczną być dobre. Weryfikacja daje natomiast wyraźny punkt odniesienia i czytelną informację, które adresy wciąż sprawiają kłopot.

• Poprawka jest wdrożona na wszystkich podstronach grupy, a nie tylko na adresach z listy przykładów.
• Kilka przykładowych adresów zostało ponownie sprawdzonych zewnętrznym testem i wynik się poprawił.
• Zmiana działa zarówno na telefonach, jak i na komputerach, jeżeli problem był widoczny w obu raportach.
• Pamięć podręczna strony została wyczyszczona, tak aby odwiedzający otrzymywali nową wersję.
• Data wdrożenia jest zapisana, aby po czterech tygodniach można było porównać wyniki.

Typowe pomyłki przy czytaniu raportu

Najczęstsza pomyłka to traktowanie raportu jak testu pojedynczej strony i oczekiwanie, że wynik zmieni się nazajutrz po poprawce. Raport pokazuje grupy i dane z czterech tygodni, więc pierwsze oznaki poprawy widać stopniowo, a pełny efekt dopiero po upływie całego okresu. Niecierpliwość prowadzi do wycofywania dobrych zmian, zanim zdążyły się ujawnić w danych.

Druga pomyłka to naprawianie wyłącznie adresów z listy przykładów. Skoro lista jest próbką, ręczne poprawienie kilkunastu podstron niczego nie rozwiązuje, jeżeli przyczyna tkwi w szablonie wspólnym dla tysięcy adresów. Trzecia to patrzenie tylko na ocenę punktową z testu laboratoryjnego. Wysoka ocena w Lighthouse nie oznacza statusu dobrego w raporcie, ponieważ są to dwa różne rodzaje danych, a o statusie decydują pomiary od prawdziwych użytkowników.

Czwarta pomyłka dotyczy oczekiwań wobec pozycji. Google w dokumentacji o podstawowych wskaźnikach internetowych i wynikach wyszukiwania zdecydowanie zaleca dążenie do dobrych wyników, ale w opisie jakości strony zastrzega, że dobre wskaźniki nie gwarantują wysokiej pozycji, a wyszukiwarka stara się pokazywać najtrafniejszą treść nawet wtedy, gdy jakość strony jest słabsza. Status dobry warto więc traktować jako dbałość o wygodę klientów i jeden z wielu elementów pracy nad widocznością, a nie jako samodzielny sposób na wyższe pozycje. Szerzej piszemy o tym we wpisie o czynnikach rankingowych Google.

Kiedy raport wystarczy, a kiedy potrzebna jest pomoc specjalisty

Samodzielnie da się zrobić całą część rozpoznawczą: odczytać statusy, ustalić, który wskaźnik zawodzi, i wskazać rodzaj podstron, których problem dotyczy. Pomoc jest zwykle potrzebna na etapie szukania przyczyny w kodzie i wdrażania zmian, zwłaszcza gdy wymagają one ingerencji w szablon, skrypty lub konfigurację serwera.

Z naszej praktyki wynika, że wsparcie przydaje się w kilku powtarzalnych sytuacjach. Pierwsza to weryfikacja zakończona niepowodzeniem mimo wdrożonych poprawek. Druga to słaby INP, którego nie da się odtworzyć w teście laboratoryjnym i który wymaga analizy skryptów. Trzecia to problemy z LCP wynikające z długiego czasu odpowiedzi serwera, co opisujemy we wpisie o TTFB. Czwarta to duże sklepy, w których każda zmiana szablonu dotyka tysięcy adresów i wymaga ostrożnego wdrożenia. Przegląd metod poprawy wszystkich trzech wskaźników zawiera wpis Core Web Vitals: jak poprawić LCP, INP i CLS, a prace tego rodzaju prowadzimy w ramach usługi SEO techniczne.

Niezależnie od tego, kto wykonuje poprawki, warto zaglądać do raportu po każdej większej zmianie na stronie: nowym szablonie, nowej wtyczce, nowym narzędziu do czatu lub analityki. Każdy z tych elementów może pogorszyć wyniki.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl