W skrócie: Page experience to zbiór sygnałów, które Google używa do oceny doświadczenia użytkownika na stronie. Core Web Vitals (LCP, INP, CLS) są rdzeniem tego systemu, ale to tylko część większego obrazu. Wyciek Google API z 2024 ujawnił wewnętrzne sygnały NavBoost – goodClicks, badClicks, lastLongestClicks – które potwierdzają, że Google mierzy satysfakcję użytkownika na poziomie każdego kliknięcia. Patenty opisują system SAT-click (dwell time powyżej 30 sekund = satysfakcja) i DSAT (powrót do SERP poniżej 30 sekund = niezadowolenie). W połączeniu z politykami spamowymi Google, page experience tworzy zamknięty system: spam sites z natury mają słabe CWV, krótki dwell time i wysoki bounce rate – co oznacza, że systemy jakości i systemy antyspamowe wzajemnie się wzmacniają.
Ten artykuł jest częścią serii o Google Spam Policies. Page experience nie jest polityką spamową w ścisłym sensie, ale tworzy pomost między systemami antyspamowymi (SpamBrain) a systemami rankingowymi (Core Ranking Systems). Serwis z scaled content abuse z natury ma słabe CWV. Serwis z sekcją kuponową ma krótki dwell time. Te korelacje nie są przypadkowe.
Czym jest page experience w rozumieniu Google?
Google definiuje page experience jako zbiór aspektów, które „core ranking systems” biorą pod uwagę przy ocenie strony. Kluczowe: Google wprost stwierdza, że „nie ma jednego sygnału rankingowego page experience – nasze systemy uwzględniają różnorodne sygnały związane z doświadczeniem użytkownika.”
Page experience obejmuje:
- Core Web Vitals – LCP (Largest Contentful Paint, ładowanie), INP (Interaction to Next Paint, responsywność), CLS (Cumulative Layout Shift, stabilność wizualna)
- HTTPS – bezpieczne połączenie jako sygnał zaufania
- Mobile-friendliness – dostosowanie do urządzeń mobilnych (mobile-first indexing od 2019)
- Intrusive interstitials – wyskakujące okienka i reklamy blokujące dostęp do treści
- Oznaczenie treści reklamowej – wyraźne oddzielenie reklam od treści głównej
John Mueller z Google wielokrotnie podkreślał hierarchię: „Relevance is still by far much more important. Just because your website is faster doesn’t necessarily mean you’ll jump to position number one.” Core Web Vitals działają jako tiebreaker – gdy dwie strony mają porównywalną jakość treści, ta z lepszym doświadczeniem użytkownika wygrywa.
Jak Core Web Vitals wpływają na rankingi – co mówią dane?
Shopify 65%, NavBoost sygnały, speed-to-revenue” class=”wp-image-23719″/>Addy Osmani, inżynier Google Chrome i współtwórca Core Web Vitals, opisał historię systemu w szczegółowej retrospektywie. Kluczowy fakt: w 2024 roku optymalizacja Core Web Vitals zaoszczędziła użytkownikom Chrome szacunkowo 30 000 lat czasu oczekiwania. To potrójny wzrost względem 12 000 lat w 2023. CWV to nie abstrakcja – to mierzalny wpływ na miliony użytkowników.
Dane o wpływie na biznes:
| Firma | Co zoptymalizowano | Efekt | Źródło |
|---|---|---|---|
| Vodafone | LCP poprawa o 31% | +8% wzrost sprzedaży | web.dev case study |
| Deloitte + Google | Poprawa page speed o 0,1 sekundy | +8,4% conversion rate w retail, +9,2% wartość koszyka | Badanie Deloitte |
| CoinStats | LCP fix (Base64 images → src) | +300% URL z „Good” CWV = +300% impressions w Search | DebugBear case study |
| Nuvemshop (180K sklepów) | LCP: 57% → 96% pass rate (+68%) | +8,9% conversion rate, +8,4% cart engagement (mobile organic) | web.dev case study (czerwiec 2026) |
Najświeższy case study pochodzi z czerwca 2026: Nuvemshop, największa platforma e-commerce w Ameryce Łacińskiej (180 000 sklepów), poprawiła LCP pass rate z 57% do 96% – co przełożyło się na +8,9% conversion rate i +8,4% cart engagement na mobile z ruchu organicznego. Co istotne: problem nie leżał w rozmiarze obrazów ani szybkości serwera. Przyczyną było to, że przeglądarka wybierała niewłaściwy element jako LCP z powodu opóźnień CSS transitions na karuzeli. Fix był prosty: usunięcie transitions z pierwszej sekcji, usunięcie lazy loading z obrazów above-the-fold i dodanie fetchpriority=”high”. Trzy zmiany, żadna nie wymagała przebudowy architektury.
Stan rynku w lipcu 2025: tylko 44% stron WordPress na mobile zdaje wszystkie trzy testy CWV. To oznacza, że ponad połowa serwisów na najpopularniejszym CMS-ie daje użytkownikom słabe doświadczenie – i każdy serwis, który poprawi CWV, zyskuje przewagę nad większością konkurencji.
Porównanie CMS pokazuje skalę problemu: WordPress (44% pass rate na mobile) przegrywa z Shopify (65%), Wix (60%) i Squarespace (57%). Ale to nie jest problem platformy – WordPress INP wynosi 85,89% (porównywalny z Wix). Problem leży w LCP i TTFB: tylko 32% stron WordPress ma dobry TTFB (czas odpowiedzi serwera). Przyczyna: tanie shared hosting bez edge caching. Przeniesienie strony z shared hostingu na managed hosting z CDN typowo obniża TTFB z 800-1400ms do 120-250ms – ta jedna zmiana często przenosi LCP z „poor” do „good” bez żadnej innej optymalizacji.
Ciekawy insight z Web Almanac 2025: strony główne (home pages) zdają CWV gorzej niż podstrony – 45% vs 56% na mobile. Różnica 11 punktów procentowych. Strony główne niosą cięższe hero images, więcej dynamicznych elementów i więcej skryptów third-party. Jeśli Twój ogólny pass rate wygląda słabo, audytuj stronę główną osobno – prawdopodobnie ciągnie średnią w dół.
Najnowsze dane (maj 2026): globalny pass rate wynosi 55,9% dla wszystkich trzech metryk (źródło: CrUX, 18,4 miliona originów). LCP jest najtrudniejszą metryką (68,6% pass), CLS najłatwiejszą (81,3%), INP pomiędzy (86,6%). Trend jest pozytywny ale spowalnia: mobile pass rate rósł z 32% w 2021, przez 44% w 2024, do 48% w 2025. Łatwe wygrane się kończą.
Co ujawnił wyciek Google API o sygnałach satysfakcji użytkownika?
W 2024 roku wyciek wewnętrznej dokumentacji Google API (Content API Warehouse) potwierdził istnienie systemu NavBoost – mechanizmu, który Google przez lata oficjalnie minimalizował. Analiza SEO Stack wyjawia kluczowe sygnały:
- goodClicks – kliknięcia, które Google uznaje za „successful user outcome.” Użytkownik kliknął wynik, spędził na stronie znaczący czas i nie wrócił do SERP, żeby kliknąć inny wynik. Innymi słowy: kliknięcie rozwiązało zapytanie
- badClicks – odwrotność. Użytkownik wrócił do wyników wyszukiwania szybko. To jest sygnał pogo-stickingu, który Google przez lata zaprzeczał jako czynnik rankingowy. Wyciek potwierdza, że jest to nazwany, przechowywany atrybut z wartością zmiennoprzecinkową wewnątrz modelu rankingowego
- lastLongestClicks – ostatnie kliknięcie w sesji z najdłuższym dwell time. To prawdopodobnie najcenniejszy sygnał w całym modelu: strona, która konsekwentnie jest ostatnim klikniętym wynikiem z najdłuższym czasem wizyty, to strona, która rozwiązuje zapytanie
- squashed – mechanizm ograniczający wpływ pojedynczych outlierów (np. bot traffic lub nietypowe zachowania). Zapobiega manipulacji click signals
Dlaczego NavBoost jest istotny w kontekście spam policies? Dlatego, że strony spamowe z natury generują słabe sygnały NavBoost. Scaled content (auto-generowane artykuły) ma krótki dwell time – użytkownik widzi niską jakość i wraca do SERP. Doorway pages generują pogo-sticking – użytkownik nie znajduje tego, czego szukał. Sekcje kuponowe mają ekstremalnie krótki dwell time (klik → redirect → wyjście). Systemy jakości i systemy antyspamowe wzajemnie się wzmacniają.
Jak patenty Google opisują system oceny satysfakcji użytkownika?
Patent US10387390 – Satisfaction metrics (SAT-click i DSAT)
Patent US10387390 opisuje system oceny satysfakcji z wyników wyszukiwania. Kluczowe mechanizmy:
- SAT-click – kliknięcie wyniku, po którym dwell time przekracza próg (np. 30 sekund). System interpretuje to jako satysfakcję użytkownika z wyniku
- Time to Success (TTS) – czas potrzebny na znalezienie satysfakcjonującego wyniku. Score 1.0 jeśli SAT-click w ciągu 10 sekund, 0.6 jeśli 10-20 sekund, 0.3 powyżej 20 sekund. Im szybciej użytkownik znajdzie satysfakcjonujący wynik, tym wyższy score
- DSAT signal – sygnał niezadowolenia: kliknięcie wyniku z dwell time poniżej progu (np. 30 sekund) LUB przeformułowanie zapytania po zobaczeniu wyników. Oba wzorce sugerują, że wyniki nie spełniły oczekiwań użytkownika
Patent US9449078 – Evaluating ranking quality via dwell time
Patent US9449078 opisuje modelowanie dystrybucji dwell time jako mieszaniny dwóch gaussowskich rozkładów w skali logarytmicznej: jeden dla „good clicks” (długi dwell time) i jeden dla „bad clicks” (krótki dwell time). System używa algorytmu EM (Expectation-Maximization) do rozdzielenia tych komponentów. Wyniki, które nie są klikane w ogóle, otrzymują prawdopodobieństwo 1.0 bycia „bad click” – brak kliknięcia = strona nie zainteresowała użytkownika.
Bill Slawski w analizie rerankingu stron na podstawie wiarygodności opisał, że Google używa kombinacji sygnałów: dwell time (ile czasu użytkownik spędza na stronie), revisitation patterns (jak często ludzie wracają na stronę) i expert popularity (zachowania użytkowników z potwierdzoną ekspertyzą w danej dziedzinie). Te trzy sygnały razem tworzą obraz „wiarygodności” strony w oczach Google.
Patent US9355095 – Click noise characterization
Patent US9355095 definiuje „dwell time” jako średni czas między dwoma konsekutywnymi akcjami użytkownika (kliknięcie wyniku, powrót do SERP, zamknięcie przeglądarki). System rozróżnia cztery kategorie interakcji: accidental clicks (natychmiastowy powrót), short measurement (użytkownik chciał kliknąć, ale treść nie spełniła oczekiwań), long measurement (użytkownik zaangażowany) i extra-long measurement (użytkownik idle – np. zostawił kartę otwartą). Każda kategoria ma inną wagę w modelu jakości.
Jak LCP, INP i CLS wpływają na sygnały satysfakcji?
Core Web Vitals i sygnały satysfakcji (NavBoost, SAT-click) nie są niezależnymi systemami – tworzą sprzężenie zwrotne:
| CWV metryka | Próg „Good” | Wpływ na satysfakcję | Połączenie ze spamem |
|---|---|---|---|
| LCP (ładowanie) | pod 2,5s | Wolne ładowanie → użytkownik odchodzi zanim zobaczy treść → brak SAT-click, wysoki DSAT | Spam sites z setkami reklam i trackerów mają LCP 6-10s |
| INP (responsywność) | pod 200ms | Lagujący interfejs → frustracja → szybkie wyjście → badClick | Scaled content z overloaded JavaScript, intrusive popups |
| CLS (stabilność) | pod 0,1 | Przesuwające się elementy → misclick → powrót do SERP → pogo-sticking | Agresywne reklamy displayowe wstrzykiwane dynamicznie |
Marzec 2024: Google zastąpił FID (First Input Delay) nową metryką INP (Interaction to Next Paint). FID mierzył tylko pierwszą interakcję na stronie. INP mierzy każdą interakcję w całej sesji i raportuje najgorszą 2-5% interakcji. To oznacza, że strona może mieć doskonały FID (szybka pierwsza reakcja), ale fatalny INP (laguje po załadowaniu JavaScript). Zmiana dotyczy szczególnie skomplikowanych SPA (Single Page Applications) i serwisów z ciężkim JavaScript.
Jak page experience łączy się z politykami spamowymi Google?
Page experience nie jest polityką spamową, ale tworzy sprzężenie zwrotne z systemami antyspamowymi:
- Intrusive interstitials – Google wprost wymienia unikanie interstitials i dialogów jako element page experience. Spamowe serwisy (gambling, payday loans, fake downloads) intensywnie używają wyskakujących okienek. Patent US9031929B1 (site quality score) może obniżyć score całego serwisu, który masowo stosuje intrusive interstitials
- Ads density – Google w Quality Rater Guidelines wymaga, żeby reklamy nie dominowały nad treścią główną (above the fold). Spamowe serwisy z thin affiliate content mają często 70-80% powierzchni strony zajętej przez reklamy
- Pogo-sticking jako sygnał spamu – patent US9449078 modeluje pogo-sticking (szybki powrót do SERP) jako „bad click.” Doorway pages z natury generują pogo-sticking, bo użytkownik nie znajduje treści odpowiadającej zapytaniu. Systemy jakości i antyspamowe mierzą ten sam sygnał
- Dwell time na sekcjach kuponowych – patent US9195944B1 (z artykułu o SRA) mierzy czas wizyty na subdirectory. Sekcje kuponowe mają dwell time 3-5 sekund = ekstremalnie niski score. Page experience i SRA policy mierzą ten sam wskaźnik
Jak CWV wpływa na widoczność w AI Search?
Nowy wymiar page experience w 2026: wpływ na widoczność w AI Overviews i AI Search. Analiza CD Studio z grudnia 2025 wykazała, że strony ze słabym CWV rzadko pojawiają się w odpowiedziach generowanych przez AI. To logiczne: jeśli AI system cytuje stronę, a użytkownik na nią przechodzi i doświadcza wolnego ładowania lub lagującego interfejsu – to negatywne doświadczenie podważa zaufanie do AI odpowiedzi. Google ma motywację, żeby cytować strony, które dostarczają dobre UX.
Dodatkowy insight: strony budowane przez AI website builders (Durable, 10Web, Wix ADI) mają pass rate CWV na poziomie 29% – wobec 42% średniej ogólnej i 61% dla stron kodowanych ręcznie. AI potrafi wygenerować stronę w minuty, ale nie potrafi jeszcze zoptymalizować jej pod CWV. To jest ważne w kontekście scaled content abuse: masowo generowane strony (AI lub template) mają z natury gorsze CWV niż strony budowane z troską o użytkownika.
Jak poprawić page experience – praktyczne kroki?
- Sprawdź CWV w Google Search Console – raport Core Web Vitals pokazuje, które strony nie zdają testów i dlaczego. Zacznij od stron z największym ruchem organicznym
- Zoptymalizuj LCP – najczęstsze przyczyny wolnego LCP: niezoptymalizowane obrazy (użyj WebP/AVIF, lazy loading, CDN), render-blocking CSS/JS (defer, async, critical CSS inline), wolny serwer (TTFB powyżej 800ms)
- Popraw INP – zidentyfikuj długie zadania JavaScript (Chrome DevTools Performance tab), podziel je na mniejsze fragmenty, użyj Web Workers dla ciężkich obliczeń. Szczególnie ważne na stronach z dużą ilością interaktywnych elementów
- Zmniejsz CLS – nadaj wymiary obrazom i reklamom (width/height), nie wstrzykuj dynamicznie elementów above the fold, unikaj fontów powodujących layout shift (font-display: swap + preload)
- Usuń intrusive interstitials – wyskakujące okienka blokujące treść to podwójny problem: pogorszenie CWV (CLS) i bezpośredni sygnał negatywny w page experience. Cookie banners są wyjątkiem, ale powinny być jak najmniej inwazyjne
Źródła i dalsze czytanie
Page experience to jedna z 10 rodzin ryzyka w spam audit checkliście z tabelą progów CWV i mapą patentów.
Google, Understanding page experience – oficjalna dokumentacja page experience signals.
Google, Core Web Vitals and Google Search – oficjalne progi LCP, INP, CLS.
Addy Osmani (Google Chrome), The History of Core Web Vitals – szczegółowa retrospektywa od 2014 do 2025, 30 000 lat zaoszczędzonego czasu.
SEO Stack, NavBoost Unpacked – analiza wycieku Google API: goodClicks, badClicks, lastLongestClicks.
Bill Slawski, How a Search Engine May Rerank Pages Based on Credibility – analiza rerankingu na podstawie dwell time, revisitation patterns i expert popularity.
DebugBear, Are Core Web Vitals a Ranking Factor? – CoinStats case study: +300% Good CWV = +300% impressions.
web.dev, Nuvemshop Case Study (June 2026) – LCP improvement +68%, +8,9% conversion rate na 180K sklepów e-commerce.
Patenty cytowane: US10387390 (satisfaction metrics, SAT-click/DSAT), US9449078 (dwell time ranking quality), US9355095 (click noise characterization).
Czy poprawa Core Web Vitals automatycznie poprawi moje pozycje?
Nie automatycznie. CWV to tiebreaker – gdy dwie strony mają porównywalną jakość treści i autorytetu, ta z lepszym doświadczeniem użytkownika wygrywa. Poprawa CWV z 'poor’ do 'good’ daje zauważalny efekt. Ale dalsze optymalizacje z 'good’ do 'perfect’ prawdopodobnie nie przesuną pozycji. Treść i relevance są nadal najważniejsze.
Czy Lighthouse score wpływa na rankingi?
Nie bezpośrednio. Google nie bierze pod uwagę wyniku Lighthouse przy rankingu. Liczy się CrUX (Chrome User Experience Report) – dane od prawdziwych użytkowników, nie syntetyczne testy. Lighthouse to narzędzie diagnostyczne do identyfikowania problemów, ale wynik w PageSpeed Insights nie przekłada się bezpośrednio na pozycje.
Co to jest NavBoost i skąd wiemy, że istnieje?
NavBoost to wewnętrzny system Google do oceny jakości wyników na podstawie zachowań użytkowników (kliknięcia, dwell time, pogo-sticking). Google przez lata oficjalnie minimalizował znaczenie click signals. Wyciek Content API Warehouse w 2024 roku potwierdził istnienie NavBoost jako nazwanego modelu z konkretnymi atrybutami: goodClicks, badClicks, lastLongestClicks. Wcześniej istnienie NavBoost potwierdzono w dokumentach z procesu antytrustowego DOJ vs Google.
Dlaczego Google zastąpił FID przez INP w 2024?
FID (First Input Delay) mierzył tylko opóźnienie pierwszej interakcji użytkownika ze stroną. Problem: strona mogła mieć doskonały FID (szybka reakcja na pierwsze kliknięcie), ale lagować przy każdej kolejnej interakcji. INP (Interaction to Next Paint) mierzy każdą interakcję w całej sesji i raportuje najgorszą 2-5%. To daje pełniejszy obraz responsywności, szczególnie na stronach z ciężkim JavaScript.
Jak page experience łączy się z politykami spamowymi?
Page experience nie jest polityką spamową, ale tworzy sprzężenie zwrotne z systemami antyspamowymi. Spamowe serwisy z natury mają słabe CWV (wolne ładowanie przez nadmiar reklam i trackerów), krótki dwell time (użytkownicy szybko odchodzą od niskiej jakości treści) i wysoki pogo-sticking rate (doorway pages, thin content). Systemy jakości (CWV, NavBoost) i systemy antyspamowe (SpamBrain) mierzą te same sygnały z różnych perspektyw – co oznacza, że wzajemnie się wzmacniają.

