Czym jest SEO techniczne w sklepie internetowym — i gdzie kończy się szybkość

SEO techniczne w sklepie to nie jedna rzecz, którą się „robi”. To pięć warstw, które muszą działać razem. Jeśli którakolwiek jest zepsuta, pozostałe tracą sens.

• Indeksacja i crawl budget — robots.txt, sitemap.xml, dyrektywy noindex, obsługa paginacji, wariantów produktów i parametrów filtrów (?color=, ?sort=, ?page=). Cel: Google ma crawlowac karty produktów, a nie tysiące kombinacji filtrów.
• Architektura URL i nawigacja — struktura kategorii, linkowanie wewnętrzne, breadcrumbs, rel=canonical, przekierowania 301 przy zmianie adresów.
• Dane strukturalne — Product, Offer, AggregateRating, BreadcrumbList. Bez poprawnych cen i dostępności nie ma rich results.
• Core Web Vitals — LCP, INP i CLS liczone na realnych sesjach użytkowników.
• Bezpieczeństwo i stabilność — ważny certyfikat SSL, brak mieszanej treści, brak błędów 5xx, pojedyncze 301 zamiast łańcuchów przekierowań, HTTP/2.

Sześć objawów, że sklep ma problem techniczny: spadek widoczności na frazach długiego ogona (pojedyncze produkty tracą ruch, choć kategoria nie), skoki błędów 5xx w Search Console, produkty wypadające z indeksu, rel=canonical wskazujący na inną kartę niż ta, którą chcesz promować, brak cen w wynikach rich results oraz rosnący współczynnik odrzuceń na mobile.

Rozgraniczenie jest kluczowe. Szybkość bez naprawy indeksacji nie podniesie pozycji: sklep z 12 000 SKU, w którym 4 000 kart ma noindex przez błąd szablonu wariantu, może mieć LCP 1,8 s i nadal nie rosnąć. I odwrotnie — przy poprawnie zaindeksowanym katalogu LCP 4,5 s na telefonie nie zabiera miejsca w indeksie, ale zabiera zamówienia. Dlatego kolejność prac jest zawsze taka sama: najpierw diagnoza indeksacji, potem szybkość, potem dopracowanie. Artykuł zamyka checklista 12 punktów z widełkami godzinowymi, żebyś wiedział, co zlecać najpierw, a co może poczekać. Więcej o tym, jak wygląda taka praca w mniejszych rynkach, piszemy w materiale o SEO technicznym i optymalizacji szybkości w Krasnobrodzie.

Core Web Vitals w liczbach: LCP, INP i CLS — progi, które liczy Google

Google ocenia trzy metryki. Progi są sztywne — nie ma tu miejsca na interpretację.

INP zastąpił FID 12 marca 2024 r. Różnica jest praktyczna: FID mierzył tylko opóźnienie pierwszego wejścia, INP mierzy reakcję na wszystkie interakcje w sesji i bierze pod uwagę najgorszą z nich. Sklep, który miał zielone FID, po zmianie często ląduje w „do poprawy”, bo np. filtr fasetowy blokuje główny wątek na 600 ms przy każdym kliknięciu.

Druga zasada: 75. percentyl. Google nie liczy średniej. Bierze 75% sesji i sprawdza, czy najgorsze 25% mieści się w progu. Innymi słowy, jedna sesja na cztery może być wolna — a strona i tak przechodzi. Jeśli przechodzi jedna na dziesięć, ocena spada.

Skąd dane: raport użyteczności (Core Web Vitals) w Search Console oraz publiczny zbiór CrUX z ostatnich 28 dni. Oba źródła opisuje dokumentacja Web Vitals na web.dev.

W Polsce różnica mobile vs desktop jest odczuwalna: telefon na 4G/LTE z procesorem klasy średniej wypada zwykle 1,5–2× gorzej niż desktop na światłowodzie. Ten sam szablon, ta sama strona, inne wnioski. Dlatego decyzje podejmuj na danych z mobile — desktop służy tylko do debugowania. Jeśli prowadzisz sklep na WooCommerce, sprawdź też, czy motyw nie dubluje zapytań na mobile, zamiast optymalizować desktop — praktykę wdrożeniową opisujemy przy okazji optymalizacji szybkości sklepu w Szczebrzeszynie.

Jak zmierzyć szybkość sklepu — 3 poziomy pomiaru i ich pułapki

Trzy poziomy pomiaru odpowiadają na trzy różne pytania i nie zastępują się nawzajem.

Poziom 1 (lab) — Lighthouse w Chrome DevTools (zakładka Lighthouse) i PageSpeed Insights. Wynik powtarzalny, ale to symulacja w kontrolowanych warunkach, nie doświadczenie klienta. W PageSpeed Insights patrz na dolną sekcję z danymi polowymi, nie na górny wynik.

Poziom 2 (field) — CrUX API i raport Core Web Vitals w Search Console. Prawdziwe sesje, ale dane opóźnione o ok. 28 dni. Świetne do oceny trendu, bezużyteczne do sprawdzenia wdrożenia z poniedziałku.

Poziom 3 (RUM) — biblioteka web-vitals JS (kilka kB po gzipie), wysyłka zdarzeń przez navigator.sendBeacon do własnego endpointu lub do GA4. To jedyny sposób, by zobaczyć wpływ zmian w 24 h i rozbić dane po typie urządzenia albo szablonie strony.

Cztery pułapki: test na niezalogowanym użytkowniku z pustym koszykiem, gdy 40% ruchu to powracający klienci z cache — mierz oba scenariusze; pomiar wyłącznie po podgrzaniu cache — rób dwa przebiegi, zimny start i ciepły cache; throttling 3G/4G w DevTools to nie realne LTE (symulacja Slow 4G to ok. 1,6 Mb/s i 150 ms RTT, a realne LTE w Polsce schodzi często poniżej 60 ms); LCP zgłaszane dla obrazu hero zmienia się po włączeniu lazy-loadingu — sprawdź w panelu Performance, który element jest faktycznie raportowany jako LCP.

Zanim ruszysz z optymalizacją, ustal punkt odniesienia. W projektach e-commerce warto połączyć pomiar z audytem wtyczek i szablonu — tak jak w wdrożeniach i optymalizacji WooCommerce w Biłgoraju. Punktem odniesienia dla progów jest dokumentacja Core Web Vitals w Google Search Central.

Ten sam zestaw testów powtarzamy przy mniejszych sklepach regionalnych, m.in. przy SEO technicznym i optymalizacji szybkości w Józefowie.

Najczęstsze wąskie gardła w PrestaShop i WooCommerce — z liczbami

Zamiast zaczynać od narzędzi, sprawdź siedem miejsc, w których w praktyce ucieka czas. Wszystkie da się zweryfikować bez dostępu do kodu źródłowego.

• Obrazy. Na typowej karcie produktu odpowiadają za 60–80% transferu. Konwersja do WebP/AVIF obniża wagę strony o 30–50%, a LCP o 0,4–0,8 s — pod warunkiem, że pliki mają poprawne wymiary, a nie są skalowane CSS-em z 3000 px.
• Wtyczki w WooCommerce. Każda wtyczka ładowana na froncie to zwykle 30–150 ms PHP i 20–80 KB JS. 20 wtyczek bez audytu potrafi dodać ponad 1 s do TTFB. Test: wyłączasz po kolei wtyczki, które nie muszą działać na froncie, i porównujesz TTFB z 10 pomiarów, nie z jednego.
• CCC w PrestaShop. Zaawansowane → Wydajność, sekcja „Combine, Compress and Cache”. Wyłączone CCC to 2–5 s wolniejsze generowanie strony kategorii. Włącz wszystkie trzy opcje, wyczyść cache i sprawdź, czy motyw oraz moduły nadal się renderują.
• Baza danych. Brak indeksów na tabelach ps_product, ps_category_product i ps_product_attribute daje zapytania trwające 800–2000 ms przy katalogu 5–20 tys. produktów. Sprawdź przez SHOW INDEX FROM ps_product; oraz EXPLAIN na najwolniejszym zapytaniu ze slow query log.
• PHP. Praca na 7.4 zamiast 8.1/8.2 to 15–30% wolniejszy backend i brak wsparcia bezpieczeństwa. Najtańsza poprawka na liście: jedna zmiana w panelu hostingu plus test koszyka i płatności.
• Frontend. 6 i więcej plików CSS oraz 10+ plików JS bez scalenia, fonty bez font-display: swap i bez preload, skrypty render-blocking w <head>.
• Pamięć podręczna. Brak Redis/Memcached dla object cache w WooCommerce i brak cache stron dla gości w PrestaShop.

Zakres opcji wydajnościowych opisuje dokumentacja PrestaShop dla deweloperów. Jeśli po tej liście nadal nie wiesz, co blokuje sklep, warto zacząć od uporządkowania projektu — tak wygląda u nas organizacja wdrożenia i optymalizacji WooCommerce.

Kolejność działań, która daje najszybszy zwrot — playbook na 4 etapy

Kolejność nie jest kwestią preferencji. Jeśli zaczniesz od frontendu, a serwer odpowiada w 900 ms, zmniejszysz plik CSS o 30 KB i nie zobaczysz tego w żadnym raporcie RUM.

Etap 1 — serwer i PHP. Aktualizacja PHP do 8.2, włączenie OPcache, object cache przez Redis/Memcached, HTTP/2 lub HTTP/3, kompresja Brotli. To zwykle 20–40% szybszy backend bez zmian w kodzie aplikacji. Efekt weryfikujesz na TTFB z 10 pomiarów i na slow query log, nie na pojedynczym uruchomieniu PageSpeed Insights.

Etap 2 — obrazy. Konwersja do WebP/AVIF, poprawne wymiary plików wyświetlanych w gridzie, srcset dla mobile, usunięcie lazy-load z obrazu hero — to najczęstszy błąd pogarszający LCP. W PrestaShop sprawdź, czy motyw nie wymusza JPEG-a; w WooCommerce pamiętaj o regeneracji miniatur po zmianie ustawień, inaczej serwer nadal podaje stare pliki.

Etap 3 — cache i CDN. Pełny cache stron dla gości, z wykluczeniem koszyka, checkoutu i zalogowanych. CDN z punktami obecności w Warszawie i Frankfurcie potrafi ściąć TTFB z 800 ms do 120–180 ms.

Etap 4 — frontend. Scalanie i minifikacja CSS/JS, defer dla skryptów niekrytycznych, preload dla fontów, usunięcie nieużywanych wtyczek i skryptów trackerów ładowanych na każdej podstronie.

Zasada porządkująca: nie ruszaj frontendu, dopóki serwer nie odpowiada w mniej niż 300 ms. Inaczej optymalizujesz objaw, a nie przyczynę.

Pułapka: brak reguły wykluczającej cache dla zalogowanych to najczęstsza regresja po wdrożeniu — klient widzi pusty albo cudzy koszyk. Testuj na koncie testowym i na koncie zalogowanego klienta, zanim uznasz wdrożenie za zamknięte.

Jak mierzyć efekt: RUM przed i po zmianie, porównanie 7 dni po wdrożeniu. Pojedynczy test nie jest dowodem. Definicje metryk, na które patrzysz, opisuje web.dev – Web Vitals.

SEO techniczne poza szybkością — 9 kontroli, które zajmują ok. 2 godzin

To warstwa, o której zapomina większość publikacji o szybkości. Dziewięć kontroli poniżej zajmuje około dwóch godzin i często wyjaśnia spadek ruchu lepiej niż kolejny audyt LCP.

• Indeksacja. Wyklucz strony filtrowania (?orderby=, ?price=), parametry sortowania i wewnętrzną wyszukiwarkę — przez noindex lub reguły w robots.txt. Inaczej crawl budget ucieka na tysiące duplikatów.
• Kanibalizacja. Kategoria i podkategoria walczące o tę samą frazę. Sygnał: dwie strony skaczące w wynikach naprzemiennie z tygodnia na tydzień.
• Canonical. Spójność między wersją z www i bez, http i https, ze slashem i bez oraz wielkością liter w URL.
• Kody odpowiedzi. Audyt łańcuchów 301 (więcej niż jedno przekierowanie), 404 generowanych przez filtry, 410 dla trwale usuniętych produktów.
• Dane strukturalne. Product, Offer, AggregateRating, BreadcrumbList, Organization — walidacja w Rich Results Test. Sprawdź, czy cena i dostępność w kodzie zgadzają się z tym, co widzi klient. Listę typów obsługiwanych przez Google znajdziesz w dokumentacji danych strukturalnych Google.
• Sitemap XML. Limit 50 000 URL-i i 50 MB na plik, aktualna data modyfikacji, wykluczenie stron z noindex.
• hreflang. Poprawne pary zwrotne, jeśli sklep ma wersje językowe lub walutowe.
• Wydajność indeksowania. Porównaj liczbę „Wykryta – nie zaindeksowana” z liczbą produktów w katalogu.
• Bezpieczeństwo i stabilność. Certyfikat SSL ważny dłużej niż 30 dni, brak mixed content, monitoring błędów 5xx.

Osobno warto zadbać o architekturę treści lokalnych: konsekwentne linkowanie w obrębie materiałów regionalnych — na przykład SEO techniczne i optymalizacja szybkości w Frampolu, w Zwierzyńcu czy w Szczebrzeszynie — buduje spójny sygnał zamiast rozproszonych wpisów.

Hosting i VPS a szybkość — co ma znaczenie dla sklepu z Lublina i Lubelszczyzny

Zanim zamówisz kolejną wtyczkę do cache, sprawdź, gdzie fizycznie stoi serwer i co dokładnie dostajesz w planie. Dla ruchu z Lublina i wschodniej Polski (Zamość, Chełm, Biała Podlaska, Puławy) centrum danych w Warszawie daje zwykle 10–25 ms RTT mniej niż Frankfurt i 30–60 ms mniej niż lokalizacje w USA. Pojedyncze 20 ms nie wygląda groźnie, ale karta produktu to 60–120 żądań — HTML, CSS, JS, obrazki, font, zapytania do API płatności i kurierów — a każde z nich ma osobny handshake TLS. W praktyce zbiera się z tego kilkaset milisekund na pełnym ładowaniu.

Parametry, które realnie przekładają się na szybkość:

• dysk NVMe — losowy odczyt bazy i plików cache; na SATA SSD import produktów bywa 2–3× wolniejszy,
• LiteSpeed z LSCache albo Nginx + PHP-FPM — pierwsze działa od razu w PrestaShop i WooCommerce, drugie daje kontrolę nad workerami i buforami,
• HTTP/3 i kompresja Brotli — mniejsze pliki statyczne i szybsze wznowienie połączenia na mobilnym LTE,
• dedykowane vCPU i gwarantowane IOPS, a nie „do 8 współdzielonych rdzeni”,
• PHP 8.2/8.3 z OPcache i realnym memory_limit 256–512 MB zamiast 128 MB.

Kiedy shared hosting wystarcza: do ok. 3 000–5 000 wizyt miesięcznie, katalog do kilkuset produktów, brak integracji z ERP, brak importów w tle. Kiedy potrzebny VPS: powyżej 10 000 wizyt, synchronizacja z Subiektem lub WF-Magiem, cykliczne importy CSV, więcej niż 5 000 produktów. Punkt startowy to 4 vCPU / 8 GB RAM / NVMe; przy 20 000+ wizyt i środowisku stagingowym sensowne jest 8 vCPU / 16 GB. Przy wdrożeniach z ERP — takich jak wdrożenia i optymalizacja WooCommerce w Biłgoraju — decyzję o VPS podejmuje się jeszcze przed startem sklepu.

Co monitorować: TTFB, liczbę procesów PHP (pm.max_children), użycie RAM bazy i innodb_buffer_pool_size, błędy 5xx, uptime oraz slow query log. Kiedy hosting to nie problem? Jeśli TTFB wynosi 150 ms, a strona i tak ładuje się 4 s, wąskie gardło masz we froncie: nieskompresowane obrazy, blokujący JS, fonty z zewnętrznego CDN. Wymiana serwera nic wtedy nie da. Web Vitals rozdziela dokładnie te warstwy — warto mieć to rozróżnienie w głowie, zanim zaczniesz rozmowę z hostingiem.

Checklista 12 punktów: audyt SEO technicznego i szybkości do odklikania

Ta checklista jest do przejścia w 45–60 minut i nie wymaga dostępu do serwera — wystarczy przeglądarka, darmowe konto w Search Console i jeden crawler. Podziel ją na dwa bloki: A — szybkość (punkty 1–6), B — indeksacja i technika (7–12). Wyniki zapisuj w arkuszu z datą, żeby po wdrożeniu mieć punkt odniesienia.

W bloku A punkty 1–3 to pomiary, a 4–6 to najczęstsze przyczyny. Dwie pułapki: mierzenie na zalogowanym koncie z wyłączonym cache oraz patrzenie tylko na Lighthouse, czyli dane laboratoryjne. Interesują cię też dane z pola (CrUX w Search Console, PageSpeed Insights) i trzy pomiary o różnych porach dnia.

W bloku B punkt 8, czyli canonical na wariantach, to najczęstsza przyczyna sytuacji, w której sklep ma 6 000 produktów, a w indeksie jest 2 100 adresów. Punkt 9 sprawdzasz w Rich Results Test — wymagane pola znajdziesz w dokumentacji Google o danych strukturalnych obsługiwanych w wyszukiwarce. Punkty 11–12 wymagają logów serwera; jeśli hosting ich nie udostępnia, to sam w sobie jest argument za zmianą planu.

Ten sam zestaw sprawdzamy u klientów regionalnych — zobacz, jak wygląda to w praktyce przy SEO technicznym i optymalizacji szybkości – Szczebrzeszyn. Pełną listę 12 punktów trzymamy też jako checklist_items tego artykułu, żebyś mógł odhaczać je po kolei.

Po wdrożeniu zmian przez dostawcę wróć do tej samej checklisty i porównaj liczby, a nie wrażenia: nie „jest szybciej”, tylko TTFB 780 ms → 190 ms, LCP 3,9 s → 2,2 s, liczba zaindeksowanych URL 2 100 → 5 800.

Ile kosztuje SEO techniczne i optymalizacja szybkości — widełki i model współpracy

Rozliczamy się godzinowo i tak samo podajemy wyceny — bez pakietów, w których nie wiadomo, co jest w środku. Widełki orientacyjne dla sklepu na PrestaShop lub WooCommerce: audyt SEO technicznego i szybkości 8–16 h, wdrożenie poprawek 20–60 h, opieka techniczna 4–8 h miesięcznie. Rozrzut w audycie bierze się głównie z liczby szablonów i szablonów wariantów; rozrzut we wdrożeniu — z liczby wtyczek (30 aktywnych to inny projekt niż 8), stanu bazy i tego, czy zalegają w niej stare wersje produktów i logi.

Co wchodzi w audyt: raport z pomiarami przed (TTFB, LCP, INP, liczba zaindeksowanych URL), lista problemów z priorytetem P0/P1/P2 i szacunkiem godzinowym, plan wdrożenia z kolejnością prac. Co wchodzi we wdrożenie: poprawki po stronie serwera (PHP, FPM, cache), cache obiektowy, kompresja i formaty obrazów, poprawki frontendu, indeksacja (canonical, sitemap, robots, filtry), dane strukturalne.

Model współpracy: pracujesz bezpośrednio z deweloperem, bez pośredników, z ustalonym SLA na czas reakcji. Na koniec dostajesz raport przed/po z danymi z CrUX i z własnego RUM — jak Google czyta te metryki, opisuje dokumentacja Core Web Vitals.

Własne moduły i wtyczki mają sens wtedy, gdy zastępują dwa–trzy płatne rozszerzenia robiące to samo — mniej zależności to mniej aktualizacji i niższy koszt utrzymania. Zakres i stawka nie zależą od tego, czy siedzisz w Lublinie, czy np. w SEO technicznym i optymalizacji szybkości w Zwierzyńcu, czy w SEO technicznym i optymalizacji szybkości – Frampol — różni się tylko harmonogram spotkań.

Czego nie obiecujemy: gwarancji TOP1. Obiecujemy mierzalną poprawę LCP, INP i TTFB oraz uporządkowaną indeksację.

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

Lista kontrolna do odklikania

• Raport Core Web Vitals w Search Console — Otwórz zakładkę Użyteczność, osobno dla mobile i desktop. Sprawdź, czy Google ocenia grupę URL-i jako dobrą i ile masz adresów w kategorii do poprawy.
• Porównanie lab z realnymi danymi — Zestaw wynik z PageSpeed Insights z danymi CrUX z ostatnich 28 dni. Jeśli lab jest zielony, a CrUX czerwony, ufaj CrUX.
• Wdrożenie RUM na własnej analityce — Podłącz bibliotekę web-vitals JS i wysyłaj zdarzenia LCP, INP oraz CLS do własnej analityki. Bez tego nie zobaczysz efektu zmian przed upływem ok. 28 dni.
• Indeksacja produktów i kategorii — Porównaj liczbę zaindeksowanych URL-i z liczbą aktywnych pozycji w katalogu. Sprawdź, czy kluczowe kategorie mają własne, unikalne adresy.
• Canonicale na wariantach i filtrach — Wejdź na produkt z wariantami, na wynik filtrowania i na stronę paginacji. Sprawdź w kodzie, gdzie wskazuje rel=canonical i czy nie prowadzi do strony spoza katalogu.
• Błędy 5xx i przekierowania 301 — W Search Console przejrzyj raport błędów serwera. W logach sprawdź, czy po zmianach w sklepie nie powstały łańcuchy 301 dłuższe niż jedno przekierowanie.
• Dane strukturalne produktu — Sprawdź, czy Google pokazuje ceny i dostępność w wynikach. Jeśli nie, zweryfikuj znaczniki Product i Offer w testerze wyników z danymi strukturalnymi.
• Element LCP na karcie produktu — Ustal, co jest raportowane jako LCP: obraz hero, galeria czy nagłówek. Sprawdź, czy nie jest ładowany leniwie i czy ma ustawiony priorytet.
• Waga i format obrazów — Zważ obraz główny, zdjęcia w galerii i miniatury. Sprawdź, czy sklep serwuje WebP lub AVIF i czy generuje wersje dopasowane do szerokości ekranu.
• Skrypty firm trzecich — Policz, ile zewnętrznych skryptów ładuje się na karcie produktu i koszyka. Każdy z nich to dodatkowy koszt dla INP, zwłaszcza na telefonie klasy średniej.
• Zimny start kontra ciepły cache — Zmierz oba scenariusze po restarcie PHP-FPM i OPcache. Zapisz wyniki, żeby po kolejnym wdrożeniu mieć punkt odniesienia.
• PHP, hosting i konfiguracja cache — Ustal wersję PHP, limity pamięci i typ cache (pełnopage, obiektowy, CDN). To najczęstsze miejsce, w którym szybkość jest ograniczona po stronie infrastruktury.

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