Czym jest SEO techniczne i optymalizacja szybkości w praktyce sklepu

W sklepie internetowym trzeba rozdzielić trzy obszary, bo najczęściej się je miesza i płaci za to podwójnie.

• SEO techniczne — to, co widzi robot Google: adresy URL, przekierowania 301, tagi canonical, mapa witryny XML, dane strukturalne typu Product, Offer, BreadcrumbList oraz jedno spójne adresowanie dla każdego wariantu produktu.
• Optymalizacja szybkości — to, co widzi klient: waga zasobów, liczba żądań, czas odpowiedzi serwera (TTFB), kompresja Brotli, obrazy w WebP lub AVIF, cache przeglądarki.
• SEO treściowe — opisy kategorii, poradniki, teksty na kartach. Działa dopiero wtedy, gdy dwa pierwsze obszary są uporządkowane.

Google podaje trzy twarde progi: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Na karcie produktu LCP to zwykle zdjęcie główne albo nagłówek. Jeśli slider wyświetla plik PNG o wadze 1,8 MB, sam ten element zjada cały budżet, zanim wczyta się cokolwiek innego. INP poniżej 200 ms oznacza, że po dotknięciu „Dodaj do koszyka” strona reaguje od razu, a nie po doładowaniu skryptu koszyka. CLS poniżej 0,1 to brak przeskakiwania treści, gdy wczyta się banner promocyjny albo niestandardowa czcionka — inaczej klient na telefonie trafia palcem w zły przycisk. Wszystkie trzy progi mierzy się na telefonie, bo Google indeksuje w trybie mobile-first. Wersja desktopowa jest tylko dodatkiem.

Punkt odniesienia jest więc jeden: telefon klienta z kartą produktu na ekranie. Jeśli prowadzisz sklep w większym mieście, kolejność prac wygląda podobnie — zobacz SEO techniczne i optymalizacja szybkości w Lublinie. Sam sposób pomiaru wskaźników i ich definicje opisuje dokumentacja Web Vitals. Objawy po stronie technicznej widać też w Search Console: wpis „Duplikat, Google wybrał inną wersję kanoniczną” oznacza, że robot uznał Twoją kartę produktu za kopię innego adresu i w wynikach pokazuje ten drugi.

Dlaczego szybkość waży więcej w małym sklepie niż w sieciówce

W sieciówce wolna strona to problem wizerunkowy. W sklepie działającym w Bełżcu i okolicach to strata, którą widać w porzuconych koszykach jeszcze tego samego dnia.

Liczby są znane od lat i nadal aktualne. W badaniu Google i SOASTA z 2017 roku wydłużenie ładowania z 1 s do 3 s zwiększało prawdopodobieństwo porzucenia strony o 32%, z 1 s do 5 s — o 90%, a z 1 s do 10 s — o 123%. Akamai podawał z kolei, że każde dodatkowe 100 ms opóźnienia to około 7% mniej konwersji. Różnica między 2 s a 5 s nie jest więc kosmetyczna — to inny sklep z punktu widzenia klienta, który stoi na przystanku w Zwierzyńcu i ma jedną kreskę zasięgu.

Drugi mechanizm jest mniej oczywisty: budżet indeksowania. Google przydziela crawlerowi ograniczoną liczbę żądań dla domeny. Sklep z 600 produktami i 4500 wygenerowanymi adresami (filtry, sortowania, warianty) marnuje część tego limitu na strony, które nigdy nie powinny trafić do indeksu. Każdy wolny URL odpowiadający w 3 s zamiast 300 ms zabiera miejsce adresom, które faktycznie sprzedają.

Do oceny doświadczenia użytkownika Google używa danych polowych z Chrome UX Report, czyli pomiarów z realnych urządzeń, a nie z laboratorium. W PageSpeed Insights zobaczysz dwie sekcje: dane z ostatnich 28 dni i wynik laboratoryjny. Jeśli domena ma mały ruch, dane polowe mogą być niedostępne — wtedy liczy się to, co pokazuje laboratorium, i ten sam zestaw zobaczysz w raporcie Core Web Vitals w Search Console. Po szczegóły zajrzyj do dokumentacji Google Search Central o Core Web Vitals.

Do tego dochodzi sezonowość Roztocza: lipiec, sierpień i weekendy majowe to szczyty ruchu. Wtedy sklep obsługuje najwięcej klientów, a wolne ładowanie boli najbardziej. Jeśli prowadzisz sprzedaż w sąsiedniej gminie, ta sama mechanika dotyczy SEO technicznego i szybkości w Zwierzyńcu.

Audyt techniczny w 90 minut: co sprawdzić najpierw

Ten audyt zrobisz sam w 90 minut, bez płatnych narzędzi. Kolejność ma znaczenie, bo pozwala odsiać rzeczy pilne od kosmetycznych.

0–20 min: PageSpeed Insights i Lighthouse. Wpisz adres karty produktu, nie strony głównej — ona prawie zawsze wypada lepiej. W PageSpeed Insights zostaw zakładkę mobilną i czytaj „Wykryte problemy”, a nie sam wynik 0–100. Potem otwórz Chrome DevTools → zakładka Lighthouse, ustaw urządzenie Mobile i throttling „Symulowane wolne 4G”. Zapisz LCP, Total Blocking Time i CLS.

20–45 min: Search Console. Raport „Core Web Vitals” — sprawdź osobno grupę mobilną i desktopową, bo adresy z problemami mogą się nie pokrywać. Następnie „Indeksowanie stron” i powody wykluczenia: szukaj wpisów „Duplikat, Google wybrał inną wersję kanoniczną”, „Zeskanowane, ale obecnie niezaindeksowane” oraz „Wykryto, ale nie zaindeksowano”. Na końcu „Mapy witryny” — czy liczba przesłanych adresów zgadza się z wykrytymi.

45–90 min: crawl. Darmowy Screaming Frog ma limit 500 adresów, więc przed startem wyklucz w robots.txt koszyk, zamówienie i wyszukiwarkę wewnętrzną, żeby nie zjadały limitu. Z eksportu wypisz: kody 404, soft 404 (strona zwraca 200, ale w treści jest „nie znaleziono”), łańcuchy 301 → 301 → 200, brakujące i zdublowane tytuły oraz opisy, adresy bez tagu canonical.

W polskich sklepach najczęściej znajdziesz trzy rzeczy: adresy filtrów (…?q=, layered navigation w PrestaShop) traktowane jako osobne strony, warianty produktu bez canonicala wskazującego na produkt główny oraz ten sam produkt stojący w kilku kategoriach, czyli zdublowane karty produktu. Wyniki zapisz w jednej tabeli i sortuj po priorytecie:

Core Web Vitals w PrestaShop i WooCommerce — gdzie realnie tracisz sekundy

LCP rzadko bierze się z całego sklepu — zwykle to jeden obraz i jeden font. W sklepach, które dostajemy do audytu, elementem LCP jest najczęściej slider na stronie głównej albo pierwsze zdjęcie na karcie produktu. Jeśli nie ma atrybutu fetchpriority=high i nie jest w formacie WebP lub AVIF, samo to dodaje 0,8–1,5 s na łączu mobilnym. Zacznij od DevTools → Performance i ustal, który element jest LCP, zamiast zgadywać.

Fonty: każdy plik WOFF2 ładowany z zewnętrznego CDN to dodatkowe zapytanie DNS, TLS i RTT. Efekt: tekst pojawia się 300–600 ms później. Rozwiązanie to self-hosting fontu, rel=preload dla pliku widocznego nad zagięciem, font-display: swap i fallback z size-adjust, żeby podmiana nie przesuwała tekstu. Same progi i sposób pomiaru znajdziesz w dokumentacji Core Web Vitals na web.dev.

INP psuje się wtedy, gdy główny wątek przeglądarki jest zajęty. W PrestaShop każdy moduł, a w WooCommerce każda wtyczka doładowuje własny JavaScript — suwaki, popupy, czat, GA4, piksel Meta, heatmapy. Zanim zaczniesz optymalizować, policz: DevTools → Coverage pokaże, ile KB JS nie jest w ogóle używane na danej stronie. W sklepach, z którymi pracowaliśmy, schodziło z tego 40–60% kodu.

CLS to najczęściej brak width i height (lub aspect-ratio) przy obrazach oraz baner cookie wstrzykiwany JavaScriptem po załadowaniu strony. Baner obecny w HTML od pierwszego renderu — nawet jeśli wizualnie pojawia się po sekundzie — nie przesuwa layoutu.

Konkret do wdrożenia: WebP/AVIF, srcset z szerokościami 400/800/1200/1600 px, loading=lazy na wszystkim poza obrazem LCP. Uwaga: wtyczki WordPressa potrafią dodać lazy loading także do hero — trzeba je wykluczyć. W PrestaShop rozmiary obrazów ustawia się w Katalog → Obrazy i po zmianie trzeba je odtworzyć, inaczej sklep nadal serwuje stare pliki.

Jak odróżnić wtyczkę winną od niewinnej: kopia staging, ten sam test (PageSpeed w trybie telefonu), wyłączanie po 5 wtyczek i pomiar. Różnica poniżej 50 ms w LCP oznacza, że nie warto się nią zajmować. Podobne audyty robiliśmy dla sklepów z Krasnobrodu i okolic.

Cache, hosting i serwer: kiedy VPS wychodzi taniej niż tani hosting

TTFB jest częścią LCP, o której zapomina większość poradników. LCP to czas oczekiwania na pierwszy bajt plus pobranie obrazu i render. Jeśli TTFB wynosi 1,2 s, na resztę zostaje 1,3 s — i choćbyś miał najlepiej skompresowane zdjęcia, w próg 2,5 s nie wejdziesz. Orientacyjnie TTFB poniżej 0,8 s to dobry punkt startu; nie jest to osobna metryka rankingowa, ale bezpośrednio wpływa na LCP.

Co podnosi TTFB: brak cache strony (każde wejście generuje HTML od zera), wolne zapytania do bazy (brak indeksów, tysiące wariantów produktów), przeładowany hosting współdzielony, na którym obok Ciebie stoi kilkaset stron.

• PrestaShop: cache Smarty i cache klas w katalogu /var/cache/prod, ustawienia w Zaawansowane → Wydajność (CCC). Cache włączaj tylko na produkcji — na kopii testowej wyłącza się go, żeby widzieć zmiany na bieżąco. Po każdym wdrożeniu katalog cache trzeba odtworzyć. Szczegóły konfiguracji opisuje dokumentacja deweloperska PrestaShop.
• WooCommerce: cache stron (WP Rocket, LiteSpeed Cache) plus cache obiektowy — Redis lub Memcached przez plik object-cache.php i stałe w wp-config.php. Dla zalogowanych klientów cache strony nie działa, dlatego karty produktów i kategorie najbardziej zyskują właśnie na cache obiektowym.
• PHP 8.x i OPcache: opcache.enable=1, memory_consumption 128–256 MB, max_accelerated_files ustawione powyżej liczby plików w instalacji. Kompresja Brotli zamiast gzip daje 10–15% oszczędności na tekście, HTTP/2 lub HTTP/3 ma sens zwłaszcza przy dużej liczbie plików.

Sygnały, że czas na VPS: TTFB rośnie dwukrotnie między 18:00 a 21:00, hosting pokazuje limity procesów (nproc lub EP w CloudLinux), nie masz dostępu do php.ini, Redisa, OPcache ani logów wolnych zapytań. Ale uwaga: sama zmiana hostingu nie naprawi 4-megabajtowych zdjęć i dziesięciu skryptów zewnętrznych. VPS z 1 vCPU i 1 GB RAM bez konfiguracji bywa wolniejszy niż dobry hosting współdzielony. Kolejność jest zawsze ta sama: najpierw obrazy i skrypty, potem serwer. Podobne przejścia prowadziliśmy dla firm z Biłgoraja oraz Lublina.

Indeksowanie i struktura: mapy strony, canonicale, filtry, paginacja

Mapa strony XML to punkt wyjścia, nie formalność. W PrestaShop generuje ją moduł (w nowszych wersjach wbudowany), w WooCommerce — Yoast lub Rank Math (sitemap_index.xml). Sprawdź dwie rzeczy: czy w mapie nie ma adresów z parametrami i czy liczba URL-i zgadza się z liczbą stron, które faktycznie chcesz mieć w indeksie. Zgłoś mapę w Search Console → Mapy witryny i wróć do niej po dwóch tygodniach.

robots.txt: najczęstszy błąd, jaki widzimy, to Disallow: /modules/, /themes/, /wp-content/ albo /wp-includes/ skopiowane z poradnika. Blokujesz wtedy CSS i JS — Google renderuje stronę bez stylów i widzi coś innego niż klient. Sprawdź w Search Console → test robots.txt oraz w narzędziu sprawdzania adresu URL, czy nie ma zablokowanych zasobów.

Canonicale: produkt z wariantami nie powinien mieć osobnego canonicala dla każdej kombinacji — wskazujesz główny adres produktu. Parametry kampanii (utm_*, gclid, fbclid) nie tworzą nowych stron: canonical prowadzi do wersji bez parametrów.

Filtry fasetowe: każda kombinacja filtrów to nowy URL. Przy 20 atrybutach robią się z tego tysiące adresów, które zjadają budżet indeksowania. Dla filtrów bez popytu stosuj noindex, follow — a nie Disallow w robots.txt, bo wtedy Google w ogóle nie zobaczy znacznika noindex. Dla filtrów, które ludzie faktycznie wpisują w Google, buduje się osobną stronę lądową z własnym opisem.

Paginacja: canonical każdej podstrony wskazuje samą siebie. Wskazanie wszystkich na stronę pierwszą to najczęstszy błąd — dalsze strony przestają być traktowane jako wartościowa zawartość.

Dane strukturalne: Product z Offer (price, priceCurrency, availability), BreadcrumbList i Organization. Pełną listę typów obsługiwanych przez Google znajdziesz w galerii danych strukturalnych. Typowy błąd to cena w znaczniku niezgodna z ceną po promocji. Porównania takich wdrożeń opisujemy przy sklepach ze Zwierzyńca i Józefowa.

Jak sprawdzić, czy strona jest faktycznie zaindeksowana: wpisz w Google site:twojadomena.pl nazwa-produktu, a w Search Console użyj sprawdzania adresu URL — komunikat „Adres URL jest w Google” z datą to fakt, „Zgłoszono” to tylko kolejka. Raport Indeksowanie → Strony pokaże różnicę między „Zaindeksowano” a „Odkryto – obecnie nieindeksowano”.

SEO lokalne dla Bełżca i okolic: technika plus widoczność w mapach

Wizytówka w Google to dla sklepu w Bełżcu często pierwszy kontakt z klientem — jeszcze przed wejściem na stronę. Ustawienia, które realnie ważą na widoczności:

• Kategoria główna — dopasowana do tego, co faktycznie sprzedajesz, nie do tego, co brzmi dumnie. „Sklep z narzędziami” i „Firma budowlana” kierują ruch do zupełnie innych zapytań.
• Adres lub obszar działania — jeśli klient nie przyjeżdża do punktu, wyłącz adres i wskaż obszar: Bełżec i sąsiednie gminy. Jeśli punkt istnieje, wpisz adres identyczny jak w stopce i w danych strukturalnych.
• Godziny — z podziałem na sezon, jeśli w wakacje pracujecie inaczej. Rozjazd godzin między wizytówką a stroną to najczęstszy błąd, jaki widzimy w małych sklepach.
• Zdjęcia — 10–15 realnych: elewacja, wejście, wnętrze, produkt w użyciu. Stocki nie zwiększają liczby połączeń ani tras.
• NAP — nazwa, adres i telefon zapisane znak w znak tak samo na stronie, w wizytówce i w katalogach. „ul.” i „ul” to dwa różne rekordy, podobnie „+48 84…” i „84…”.

Adres, godziny i telefon warto dodatkowo opisać w danych strukturalnych obsługiwanych przez Google — typ LocalBusiness dla firmy, Product z ceną i dostępnością dla kart produktów. Google potrafi pokazać je bezpośrednio w wynikach.

Drugi element to strony lokalne. Nie robimy osobnego adresu dla każdej wsi w gminie — powstają wtedy powielone teksty, które Google traktuje jak jeden dokument. Strona lokalna ma sens, gdy masz dla niej co najmniej cztery konkretne treści: punkt odbioru lub czas dojazdu, zdjęcia z miejsca, zakres obsługi i realne pytania klientów. Zapytanie z nazwą miejscowości łączymy z produktem, nie z samym SEO: inna jest intencja pod „… Józefów”, a inna pod „… Krasnobród”, i tę różnicę widać w treści, nie w podmienionej nazwie. Do istniejących materiałów linkujemy wewnętrznie — teksty o SEO technicznym i optymalizacji szybkości w Biłgoraju oraz o Józefowie mają inne przykłady i nie warto ich dublować.

Trzeci filar to szybkość. Klient w Bełżcu szuka z telefonu, w terenie, często na jednym–dwóch kreskach zasięgu. W takich warunkach LCP zależy przede wszystkim od wagi obrazka w pierwszym ekranie i liczby skryptów w sekcji head. Progi są znane: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Każde 100 kB w obrazie hero to odczuwalne opóźnienie na wolnym łączu.

Jak mierzyć efekty i po jakim czasie ich oczekiwać

Punkt wyjścia jest jeden: zapisz stan na dziś. Bez zrzutu danych z Search Console po dwóch miesiącach nie odróżnisz realnej poprawy od sezonu.

Co obserwować w Search Console:

• Skuteczność — wyświetlenia, kliknięcia, CTR, średnia pozycja. Patrz na całą witrynę i na grupę adresów URL (filtr „Strony” + dopasowanie do wzorca), np. tylko karty produktów.
• Indeksowanie → Strony — ile adresów jest zaindeksowanych, ile wykluczonych i z jakiego powodu. Po wdrożeniu wzrost liczby adresów ze statusem „Wykryta — obecnie niezaindeksowana” to zwykle kolejka, nie błąd.
• Core Web Vitals — osobno raport mobilny; sprawdzaj, ile URL-i trafiło do grup „do poprawy” i „słabe”.
• Dane strukturalne — błędy Product, Offer i LocalBusiness po każdej zmianie w szablonie.
• Mapy witryn — czy sitemap jest pobierana i ile adresów Google widzi w środku.

Terminy. Pierwsze efekty techniczne — spadek liczby błędów indeksowania, wejście nowych adresów do indeksu, krótszy czas odpowiedzi serwera — widać zwykle po 2–4 tygodniach. Ruch i pozycje ruszają po 4–12 tygodniach, a przy zapytaniach z realną konkurencją 3–6 miesięcy to norma, nie porażka. Osobne materiały pokazują ten sam mechanizm na innych rynkach: Frampol i Krasnobród.

Sezon. Tydzień do tygodnia nie mówi nic, bo na Roztoczu wakacyjny weekend potrafi dać kilkukrotnie więcej wejść niż środowy wtorek w listopadzie. Porównuj rok do roku, te same tygodnie i te same zapytania — inaczej „spadek o 30%” po wakacjach wygląda jak katastrofa, choć jest powrotem do normalności.

Ostatnia pułapka: wynik z narzędzia to nie dane terenowe. Lighthouse i PageSpeed Insights mierzą w laboratorium, na jednym urządzeniu, z zimnym cache. Raport w Search Console i dane CrUX pokazują 28-dniowe wyniki od prawdziwych użytkowników — a ci mają wtyczki, starsze telefony i słabsze łącze. Rozbieżność 20–30 punktów między labem a terenem jest normalna. Kieruj się terenem: zasady Core Web Vitals w wynikach wyszukiwania. Jeśli po wdrożeniu poprawiasz lab, a teren stoi w miejscu, sprawdź, czy nowe szablony i cache nie działają tylko dla zalogowanych.

Ile to kosztuje i jak pracujemy przy takich wdrożeniach

Nie publikujemy sztywnego cennika, bo zakres zależy od stanu sklepu — ale widełki godzinowe podajemy, żebyś wiedział, z czym się mierzysz. Stawka jest ustalana przed startem i nie zmienia się w trakcie prac.

• Audyt techniczny — 8–16 h. Crawl (np. Screaming Frog), analiza logów serwera, jeśli hosting je udostępnia, przegląd Search Console, PageSpeed dla 5–10 szablonów, kontrola indeksu, danych strukturalnych i przekierowań. Efekt: lista zadań z priorytetem i szacunkiem godzin na każde.
• Wdrożenie poprawek — 16–40 h. Typowy zakres: przekierowania i kanibalizacja adresów, poprawki w motywie child, obrazy w WebP/AVIF z srcset, krytyczny CSS, moduły dla PrestaShop, poprawki w .htaccess i konfiguracji cache.
• Monitoring i opieka — 2–4 h miesięcznie. Kolejne wdrożenia wyceniamy tak samo: najpierw godziny i zakres, potem decyzja.

Własne moduły zamiast kolejnych wtyczek. Płatna wtyczka za 25 zł miesięcznie to 300 zł rocznie, a w małym sklepie zwykle zbiera się ich dwie–trzy. Moduł pisany pod konkretny problem to 3–6 h pracy, jednorazowo, bez subskrypcji i bez zależności od zewnętrznego autora. Warunek: moduł robi jedną rzecz i nie dubluje mechanizmów, które PrestaShop ma w rdzeniu. Zanim napiszemy nowy, sprawdzamy dokumentację deweloperską PrestaShop, czy odpowiedni hook już nie istnieje.

Opieka po wdrożeniu. W zakresie: aktualizacje PrestaShop, modułów i wersji PHP, kopie zapasowe (baza codziennie, pliki tygodniowo, raz na kwartał test odtworzenia na środowisku testowym), monitoring dostępności co minutę z alertem SMS oraz jasne SLA — reakcja do 4 h w dni robocze, naprawa awarii krytycznej do 24 h. Zlecenie prowadzi deweloper, który je wdraża; nie ma pośrednika, który przekazuje zadanie dalej i wraca z pytaniami po trzech dniach. Jeśli sklep działa poza Bełżcem — wdrożenia dla Lublina i regionu albo mniejsze sklepy w Zwierzyńcu — schemat pracy jest taki sam.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• PageSpeed Insights w trybie mobilnym — Uruchom dla strony głównej, jednej kategorii i dwóch lub trzech kart produktów. Zapisz LCP, INP i CLS osobno dla danych laboratoryjnych i terenowych.
• Raport Core Web Vitals w Search Console — Sprawdź grupy wymagające poprawy i słabe, z podziałem na typ urządzenia. Zwróć uwagę na to, których szablonów dotyczą problemy.
• Raport indeksowania stron — Porównaj liczbę zaindeksowanych adresów URL z liczbą pozycji w mapie witryny. Przejrzyj główne przyczyny wykluczenia.
• Mapa witryny — Sprawdź, czy zawiera wyłącznie kanoniczne adresy URL zwracające kod 200, czy nie trafiły tam adresy z parametrami i czy data ostatniej modyfikacji jest aktualna.
• Crawl do 500 adresów URL — Użyj darmowego crawlera albo ograniczonego planu płatnego. Na start wystarczy strona główna, kategorie, produkty i kilka stron informacyjnych.
• Kody 404 i soft 404 — Sprawdź, czy błędne adresy zwracają właściwy kod, a nie stronę z kodem 200 i pustą treścią. Ustal, które wymagają przekierowania, a które usunięcia.
• Łańcuchy przekierowań — Każdy adres powinien przechodzić maksymalnie przez jedno przekierowanie do celu. Dłuższe łańcuchy wydłużają czas odpowiedzi i rozmywają sygnały.
• Brakujące i zdublowane tytuły oraz opisy — Szukaj duplikatów na wariantach produktów, stronach paginacji i adresach z filtrami. Sprawdź długość i unikalność na najważniejszych stronach.
• Canonical na wariantach i w paginacji — Sprawdź, czy warianty prowadzą do wersji głównej produktu, a kolejne strony listingu nie kanonikalizują się do pierwszej.
• Dane strukturalne — Sprawdź znaczniki Product, Offer i BreadcrumbList w walidatorze Google. Błędy w cenie lub dostępności potrafią wyłączyć rozszerzone wyniki.
• Waga strony i liczba żądań — Zmierzyć w narzędziach deweloperskich przeglądarki: liczba żądań, rozmiar JavaScriptu i CSS, najcięższe zasoby na karcie produktu.
• Zdjęcia: format, wymiary, srcset — Sprawdź, czy obrazy są w WebP lub AVIF, mają podane width i height oraz czy srcset obsługuje różne szerokości ekranu.
• Cache i nagłówki odpowiedzi — Sprawdź czas odpowiedzi serwera dla karty produktu oraz nagłówki Cache-Control dla zasobów statycznych. Powtórz test dwa razy, żeby odróżnić zimny cache od ciepłego.
• Test modułów i wtyczek na staging — Wyłączaj po jednym module lub wtyczce i po każdej zmianie mierz ten sam zestaw wskaźników. Różnica poniżej kilku procent oznacza, że winowajcą jest inny element.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• web.dev – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów