Czym jest SEO techniczne i optymalizacja szybkości w sklepie internetowym

SEO techniczne i optymalizacja szybkości to dwie różne prace. SEO techniczne pilnuje dostępu do indeksu i poprawnej struktury: budżetu crawlowania, indeksacji, canonicali, przekierowań, mapy strony i danych strukturalnych. Optymalizacja szybkości zajmuje się czasem odpowiedzi serwera i renderowaniem po stronie klienta — czyli tym, co dzieje się od wysłania żądania do pojawienia się treści na ekranie.

Granica między nimi bywa płynna i to jest najczęstszy powód przepalonego budżetu. Googlebot przy TTFB 3 s indeksuje mniej podstron w jednej sesji, więc wolny serwer staje się problemem SEO. Z kolei canonical wskazujący na /koszyk potrafi wyrzucić z indeksu 200 kart produktów — i żadna kompresja obrazków tego nie naprawi. Dlatego obie prace planuje się razem; zakres pierwszej z nich opisujemy w sekcji SEO techniczne.

Szybki test, czy masz problem — pięć sygnałów:

• Spadek kliknięć i wyświetleń w Search Console bez zmian w treści, cenniku i linkach.
• Odsetek odrzuceń na mobile wyższy od desktopu o 15 p.p. i więcej.
• Dodanie do koszyka trwa dłużej niż sekundę — klient klika drugi raz i dubluje pozycję.
• Google indeksuje URL-e z parametrami filtrów (np. ?q=...&page=3) oraz /koszyk, a nie karty produktów.
• TTFB powyżej 600 ms w PageSpeed Insights lub WebPageTest.

Dwa z tych sygnałów naraz to zwykle nie przypadek, a jedna przyczyna: brak cache, wolne zapytanie SQL albo zewnętrzny skrypt ładowany przed treścią.

Najważniejsze zdanie tego tekstu: szybkość i techniczne SEO są środkiem do konwersji, nie celem samym w sobie. Zielone kółko w Lighthouse przy koszyku porzuconym na etapie płatności nic nie znaczy. Zanim zamówisz optymalizację, ustal, który element blokuje zakup.

Core Web Vitals w 2025: progi LCP, INP i CLS w praktyce sklepu

Progi „dobry” w Core Web Vitals wynoszą: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Nie mierzy się ich jednak na Twoim laptopie ani w pojedynczym teście. Google liczy 75. percentyl realnych wizyt — 75% wizyt musi zmieścić się w progu, a 25% może być gorszych. Osobno dla mobile i desktopu. W sklepie oznacza to, że jeden szybki desktop nic nie zmieni, jeśli trzy czwarte ruchu mobilnego czeka 4 s na banner.

12 marca 2024 INP zastąpił FID. Różnica jest praktyczna: FID mierzył tylko opóźnienie pierwszej reakcji, INP mierzy całą interakcję do momentu, gdy przeglądarka pokaże efekt. W sklepie to konkretnie: dodanie do koszyka, klikanie w filtry, otwarcie mini-koszyka, zmianę wariantu. Jeśli po kliknięciu „Do koszyka” przycisk reaguje po 400 ms, bo w tym czasie wykonuje się skrypt analityczny — INP to pokaże, FID nie.

Dane polowe (raport CrUX, Search Console) to 28 dni realnego ruchu. Dane labowe (Lighthouse) to symulacja na wybranym sprzęcie, bez Twoich użytkowników, cache i rozszerzeń przeglądarki. Rozjazd jest normalny. Zasada: decyzję podejmuj na danych polowych, labowe służą do znalezienia przyczyny.

Gdzie w sklepie najczęściej pada LCP: banner hero w PNG ważący 1,5 MB, slider z 5 slajdami ładowany w całości, zdjęcia produktów bez atrybutów width i height, fonty z Google Fonts bez preconnect i font-display: swap, skrypt czatu wstawiony przed treścią.

Zgłoszenie do dewelopera brzmi: „LCP karty produktu to 4,1 s na mobile (dane polowe CrUX), element LCP to img.hero, plik 1,2 MB PNG”, a nie „strona jest wolna”. Metryki i sposób ich zbierania opisuje dokumentacja Google Search Central – Core Web Vitals.

Jak zmierzyć szybkość sklepu: 6 narzędzi i co z nich wyczytać

Zacznij od PageSpeed Insights, ale wpisz osobno URL karty produktu, kategorii i strony głównej. Wynik dla strony głównej rzadko pokazuje problem sklepu. Patrz najpierw na dane polowe z CrUX (ostatnie 28 dni), dopiero potem na listę „Diagnostyka”. Puste dane polowe oznaczają zbyt mały ruch — wtedy labowe traktuj jako wskazówkę, nie wyrok.

Raport Core Web Vitals w Search Console grupuje adresy po typie: karty produktów, kategorie, strona główna, inne. Jeśli na czerwono są tylko karty produktów, problem siedzi w szablonie product.tpl i tym, co ładuje, a nie w serwerze. Jeśli czerwone jest wszystko, zaczynaj od TTFB, cache i bazy.

Lighthouse w Chrome DevTools uruchamiaj w trybie incognito, na zimnym cache, z profilem Mobile. Te same warunki powtórz w WebPageTest (lokalizacja Frankfurt, urządzenie Moto G4, „First View”) — dostaniesz waterfall z rozbiciem na DNS, TLS, TTFB i pobieranie zasobów. GTmetrix ustaw jako monitoring: ten sam URL raz w tygodniu, porównuj wykres w czasie, nie jeden wynik.

Kluczowa interpretacja: TTFB powyżej ~600 ms to problem serwera, PHP albo bazy — nie grafik. W tym momencie kompresja obrazków nic nie da. Żeby odróżnić brak cache od wolnych zapytań SQL, włącz cache (PrestaShop: Zaawansowane → Wydajność, opcje CCC) i powtórz test. Spadek z 1,2 s do 300 ms oznacza brak cache. Jeśli TTFB zostało na 900 ms, włącz slow query log (long_query_time = 0.5), przejrzyj najdłuższe zapytania i sprawdź indeksy na tabelach ps_product, ps_category_product, ps_orders.

Na koniec Waterfall w DevTools Network: szukaj zasobów blokujących render — CSS w sekcji head, skryptów bez async i defer — oraz zewnętrznych domen (czat, piksele, GA). Każda to dodatkowy DNS i TLS, a skrypt czatu wstawiony przed bannerem potrafi sam odpowiadać za LCP. Kolejność takich wdrożeń opisujemy w materiale SEO techniczne i optymalizacja szybkości w Zamościu dla firm, a definicje metryk znajdziesz na web.dev – Core Web Vitals.

Najczęstsze problemy techniczne w PrestaShop i WooCommerce

Problemy z szybkością wracają w tych samych miejscach. W PrestaShop pierwszy to nadmiar modułów: po 4–5 latach sklep ma ich zwykle 40–60, a część jest podpięta pod hook displayHeader i ładuje się na każdej stronie, także tam, gdzie nie jest potrzebna. Drugi to brak cache obiektowego (Redis albo Memcached). Domyślny cache plikowy w var/cache nie zdejmuje z bazy powtarzalnych zapytań — przy katalogu 5 tys. produktów i 200 sesjach na godzinę baza wykonuje te same kwerendy setki razy. Trzeci to brak indeksów na kolumnach używanych w filtrach (tabele produkt–atrybut, produkt–kategoria); bez nich każde kliknięcie filtra to pełne skanowanie tabeli. Czwarty to kategorie z tysiącami kombinacji atrybutów: 6 atrybutów po 20 wartości daje dziesiątki tysięcy adresów generowanych przez blok fasetowy. Dokumentacja deweloperska PrestaShop opisuje, jak diagnozować własne moduły i hooki: PrestaShop Developer Documentation.

W WooCommerce typowe przyczyny są inne. Wtyczki (filtry, rekomendacje, liczone na żywo produkty powiązane) budują kosztowne zapytania z wieloma JOIN-ami. Przerośnięta tabela wp_options z autoloadem to norma po kilku latach — sprawdzisz to jednym zapytaniem: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes'. Jeśli wynik przekracza 1–2 MB, każda odsłona ładuje to do pamięci. WP-Cron odpalany przy każdym żądaniu (wp-cron.php) dokłada obciążenie przy ruchu i nie wykonuje zadań, gdy ruchu nie ma — lepiej wyłączyć go w wp-config.php i ustawić prawdziwy cron co minutę. Brak object cache przy dużym katalogu daje ten sam efekt co w PrestaShop.

Poza platformą zostają obrazy i zasoby blokujące renderowanie: brak WebP/AVIF, brak srcset dla różnych szerokości ekranu i — najczęstsza przyczyna CLS w sklepach — brak atrybutów width i height. Do tego fonty bez font-display: swap oraz widgety czatu i piksele ładowane synchronicznie. Osobna kategoria to higiena indeksu: łańcuchy przekierowań, ten sam produkt pod kilkoma adresami, a w indeksie koszyk, panel klienta i wyniki wyszukiwania wewnętrznego. Pułapka, która kosztuje najwięcej: dokupienie kolejnej wtyczki do cache, gdy wąskim gardłem jest baza danych. Koszt rośnie, efekt zerowy.

Optymalizacja szybkości krok po kroku: od serwera po frontend

Kolejność ma znaczenie większe niż liczba wdrożonych poprawek. Zacznij od serwera, bo wszystko poniżej jest ograniczone jego czasem odpowiedzi.

Krok 1 — serwer i TTFB. PHP 8.1 lub 8.2 zamiast 7.4, z włączonym OPcache, PHP-FPM z pulą dopasowaną do liczby rdzeni (start np. 2 × rdzenie, potem korekta na podstawie zajętości workerów). Dalej: HTTP/2 albo HTTP/3, kompresja Brotli (z fallbackiem gzip) i CDN dla plików statycznych. Cel: TTFB poniżej 400 ms na typowej stronie kategorii.

Krok 2 — backend. Cache obiektowy (Redis), cache pełnych stron dla niezalogowanych, indeksy na kolumnach filtrowanych, przepisanie 3–5 najcięższych zapytań wykrytych w slow query logu, wyłączenie modułów i wtyczek, które realnie obciążają żądania. Ten krok daje zwykle największy zwrot, a bywa pomijany.

Krok 3 — frontend. Lazy loading poza pierwszym ekranem, preload dla elementu LCP, critical CSS inline, self-hosting fontów z font-display: swap, usunięcie nieużywanego JS i CSS. Tu wchodzą też wymiary obrazów — bez nich CLS się nie poprawi.

Krok 4 — pomiar po każdym kroku. Zapisz w arkuszu datę, TTFB, LCP, CLS, INP dla mobile i desktop z PageSpeed Insights. Bez tego nie wiesz, co zadziałało, a przy sporze z wykonawcą nie masz żadnego dowodu.

Zasada: najpierw TTFB, potem LCP, na końcu CLS i INP. Poprawianie CLS przy serwerze odpowiadającym w 1,5 s to strata czasu — użytkownik i tak czeka. Metryki i progi opisuje web.dev – Web Vitals. Jeśli nie masz zespołu in-house, ten zakres prac realizujemy w ramach wdrożenia optymalizacji szybkości sklepu.

SEO techniczne sklepu: indeksacja, duplikaty i dane strukturalne

Ta część decyduje o tym, czy poprawki szybkości w ogóle zamienią się na wejścia. Zacznij od sitemap.xml i robots.txt. Sitemapę generuj automatycznie i wyklucz z niej koszyk, konto klienta, wyniki wyszukiwania wewnętrznego oraz adresy z parametrami filtrów. Robots.txt powinien blokować śmieciowe ścieżki, ale nie całe katalogi z produktami. Weryfikacja jest prosta: w Search Console sprawdź, czy sitemapa ma status Sukces i czy liczba wykrytych adresów zgadza się z liczbą, którą sam policzysz w sklepie.

Druga rzecz to canonical przy filtrach fasetowych i sortowaniu. Ustal jedną regułę dla całego sklepu i trzymaj się jej: filtr i sortowanie = noindex albo canonical na wersję bazową kategorii, kategoria bez parametrów = canonical na siebie. Najgorszy scenariusz to mieszanka — część widoków indeksowana, część nie, w zależności od tego, jak szablon złożył link. Paginacja i breadcrumbs muszą być linkowalne w HTML, bo odpowiadają za wewnętrzne linkowanie kategorii i podkategorii. Sam rel=next/prev nie wystarczy, jeśli kolejne strony kategorii są generowane wyłącznie JavaScriptem.

Dane strukturalne Product, Offer i BreadcrumbList dają w sklepie realny efekt: cena, dostępność i okruszki w wynikach wyszukiwania. Waliduj je w teście wyników z obrazami i w walidatorze Schema Markup — lista obsługiwanych typów jest w Google Search Central – dane strukturalne. Wymagane pola to nazwa, oferta z ceną i walutą, dostępność; brak ich oznacza ostrzeżenie zamiast wyniku rozszerzonego.

Potem raport Strony w GSC. Szukaj statusu Zaindeksowane, choć nie powinno być i wykluczaj koszyk, konto, wyniki wyszukiwania. Na koniec logi serwera: sprawdź, po co naprawdę chodzi Googlebot. Jeśli połowę żądań generują URL-e z parametrami sortowania, budżet crawlowania pracuje na śmieciach. Szerzej o całym zakresie prac przeczytasz w sekcji SEO techniczne.

Migracja sklepu bez utraty ruchu: co najczęściej zabija pozycje

Migracja to najczęstszy moment, w którym sklep traci ruch. Nie dlatego, że nowa platforma jest gorsza, ale dlatego, że nikt nie zrobił mapy przekierowań i nie przetestował nowej wersji przed startem. Kolejność prac jest zawsze taka sama: inwentaryzacja adresów, mapa 301, testy na kopii, start poza sezonem, monitoring.

Mapa przekierowań 301 w relacji 1:1. Wyeksportuj z Search Console (Indeksowanie → Strony → Eksport) adresy z kliknięciami i wyświetleniami, dodaj adresy z logów serwera (access.log) oraz z crawla, np. darmową wersją Screaming Frog do 500 URL-i. Dla każdego starego adresu przypisz konkretny nowy adres. Reguła „przekieruj cały katalog na stronę główną” to najgorsze możliwe rozwiązanie — Google traktuje takie przekierowania jak soft 404 i wygasza ruch. Produkt usunięty bez następnika zgłaszaj jako 410, nie jako 301 na stronę główną.

Testy na staging przed startem. Na kopii testowej sprawdź cztery rzeczy: te same adresy URL, brak noindex w kodzie i w nagłówku X-Robots-Tag, brak blokady w robots.txt, canonicale wskazujące docelowe adresy. Przetestuj losowo 200 przekierowań i całą sitemapę — każdy adres musi zwracać 200, a nie łańcuch 301 → 301 → 200.

Czego nie przenosić mechanicznie. Nie kopiuj treści, na których Ci nie zależy: pustych opisów z hurtowni, duplikatów, starych tagów bez ruchu. Lepiej je zostawić niż wrzucać do indeksu — Google jasno opisuje, jak odróżnia treści tworzone dla ludzi od zaplecza robionego pod wyszukiwarkę. Nie przenoś też parametrów śledzących i sortowania (?utm_, ?sort=, ?page=) jako osobnych adresów — obsłuż je canonicalem lub wyklucz w robots.txt.

Monitoring po starcie. Search Console nie wysyła alertu o spadku kliknięć, więc potrzebujesz własnego monitoringu: Looker Studio połączone z Search Console API albo narzędzie z alertem mailowym. Najczęstszy błąd organizacyjny to start nowej wersji w środku sezonu sprzedażowego — w listopadzie albo w maju przed sezonem. Przenieś wdrożenie na styczeń lub luty, nawet kosztem dwóch tygodni opóźnienia.

Ile to kosztuje i kiedy warto zlecić zewnętrznie

Widełki poniżej dotyczą typowego sklepu na PrestaShop lub WooCommerce z katalogiem od 500 do 5000 produktów. To nie jest cennik — ostateczna kwota to liczba godzin pomnożona przez stawkę wykonawcy. Chodzi o to, żebyś wiedział, ile pracy realnie stoi za ofertą.

Co wpływa na liczbę godzin. Nie liczba produktów, a liczba unikalnych szablonów stron: inny szablon ma strona główna, kategoria, karta produktu, koszyk, wynik wyszukiwania i strona CMS. Do tego rozmiar katalogu i liczba kombinacji filtrów, liczba integracji (płatności, kurierzy, ERP, magazyn) oraz liczba modułów pisanych pod ten konkretny sklep.

Standardowa wtyczka czy własny moduł. Cache, kompresja obrazów, sitemapa, przekierowania — tu wystarczy dobra wtyczka za kilkaset złotych rocznie. Własny moduł jest potrzebny, gdy: płatność ratalna działa przez API banku bez gotowego modułu dla Twojej wersji PrestaShop, albo filtr na 20 cechach generuje 30 000 adresów kombinacji. W drugim przypadku gotowy moduł filtrowania tworzy dziesiątki tysięcy URL-i zduplikowanych treści — trzeba dopisać canonical i noindex dla kombinacji bez ruchu. Bez tego SEO techniczne zjada efekt optymalizacji szybkości.

Pytania do wykonawcy przed podpisaniem umowy. Ile dokładnie szablonów i URL-i obejmuje zakres? W jakiej formie dostanę raport — lista zmian z pomiarem przed i po, czy zdanie „zoptymalizowane”? Jaki jest czas reakcji na zgłoszenie: 24 godziny czy 5 dni roboczych? Co obejmuje opieka po wdrożeniu: monitoring, poprawki regresji, limit godzin? Czy praca idzie na staging, czy od razu na produkcję, i jak wygląda powrót do poprzedniej wersji? Jeśli wykonawca nie potrafi rozbić oferty na godziny i etapy, prawdopodobnie sam nie wie, co będzie robił.

Plan działania na pierwsze 30 dni: od czego zacząć

Tydzień 1 — pomiar bazowy. Zanim ktokolwiek dotknie serwera, zapisz stan wyjściowy. PageSpeed Insights dla pięciu szablonów: strona główna, kategoria, karta produktu, koszyk, wynik wyszukiwania. Z Search Console pobierz do CSV raport „Strony” (Indeksowanie) i raport „Core Web Vitals” — z datą w nazwie pliku, żeby po miesiącu było z czym porównać. WebPageTest: test z Frankfurtu, profil Moto G4 z throttlingiem 4G, minimum 3 przebiegi. Na koniec kopia zapasowa plików i bazy (mysqldump albo snapshot hostingu) plus zapisana wersja PHP i lista aktywnych modułów.

Tydzień 2 — TTFB. Najpierw serwer, potem frontend. Optymalizacja obrazków przy TTFB 1,5 s to strata czasu. Kolejność: aktualizacja PHP do 8.2 lub 8.3, OPcache (opcache.enable=1, pamięć 128–256 MB, w produkcji validate_timestamps=0 z restartem przy deployu), Redis lub Memcached jako cache obiektowy, przegląd modułów ładujących się na każdej stronie i wyłączenie zbędnych. Cel: TTFB poniżej 600 ms, a na dobrym hostingu poniżej 300 ms.

Tydzień 3 — obrazy, LCP, CLS. Konwersja do WebP lub AVIF, poprawne wymiary width i height w każdym img, srcset z 3–4 szerokościami. Lazy loading dla obrazów poniżej pierwszego ekranu, ale nigdy dla obrazu LCP — ten dostaje preload. Fonty: self-hosting, font-display: swap, preload pliku woff2. CLS: zarezerwuj miejsce pod bannery i moduły wstrzykiwane nad treścią, ustawiając stałą wysokość kontenera.

Tydzień 4 — indeksacja. Sitemapa tylko z produktami, kategoriami i stronami CMS — bez koszyka i konta. Canonicale na paginacji i filtrach, Disallow w robots.txt dla /koszyk, /zamowienie, /moje-konto i parametrów sortowania. Dane strukturalne: Product, Offer, BreadcrumbList — punkt odniesienia masz w dokumentacji Google dotyczącej obsługiwanych typów danych strukturalnych, a walidacja w teście wyników z Google.

Po 30 dniach. Raz w tygodniu sprawdzaj kliknięcia i wyświetlenia w GSC, raz w miesiącu Core Web Vitals z raportu Web Vitals na web.dev — dane są 28-dniowe, więc na trend potrzebujesz 2–3 miesięcy. Porównuj rok do roku, nie tydzień do tygodnia; spadek na kilku frazach to zwykle konkurencja, spadek na wszystkich — problem techniczny. Wskaźnikiem końcowym nie jest zielone kółko w Lighthouse, ale wzrost konwersji i spadek odrzuceń na mobile.

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

Lista kontrolna do odklikania

• Włącz i przeczytaj raport Core Web Vitals w Search Console — Raport grupuje adresy po typie szablonu — od razu widać, czy problem dotyczy kart produktów, kategorii czy całego sklepu. Sprawdzaj po każdej większej zmianie na stronie, nie raz na rok.
• Zapisz 75. percentyl osobno dla mobile i desktop — Dane polowe z CrUX lub Search Console. Mobile prawie zawsze wypada gorzej i to on powinien wyznaczać priorytet prac.
• Zmierz TTFB na zimnym i ciepłym cache — WebPageTest z wybraną lokalizacją, zimny cache. TTFB powyżej około 600 ms oznacza serwer, PHP lub bazę — grafiki nic tu nie zmienią.
• Włącz slow query log na 24–48 godzin — Szukaj zapytań najczęstszych i najdłuższych. Zapytanie powtarzane setki razy na jednym widoku kategorii to gotowy cel optymalizacji.
• Sprawdź, czy filtry i koszyk są w indeksie Google — Raport indeksowania w Search Console plus komenda site: na Twojej domenie. Weryfikuj dwa–trzy tygodnie po zmianach, bo indeks aktualizuje się z opóźnieniem.
• Ustal, który element jest LCP na stronie głównej i w kategorii — Chrome DevTools, panel Performance albo rozszerzenie pokazujące LCP. Zwykle to baner hero albo pierwszy slajd slidera.
• Policz slajdy w sliderze i sprawdź, czy wszystkie ładują się od razu — Slider z pięcioma slajdami, gdzie tylko pierwszy jest widoczny, marnuje pasmo i opóźnia LCP. Pierwszy slajd powinien ładować się priorytetowo, reszta leniwie.
• Sprawdź format i wymiary obrazów nad zgięciem — PNG zamiast WebP lub AVIF, brak atrybutów width i height w kodzie obrazu. Brak wymiarów powoduje przesuwanie treści i psuje CLS.
• Sprawdź, skąd ładowane są fonty — Fonty z zewnętrznego serwera opóźniają pierwsze renderowanie. Sprawdź w DevTools, czy pliki fontów nie blokują wyświetlenia tekstu.
• W PrestaShop sprawdź liczbę aktywnych modułów i cache obiektowy — Każdy moduł wpięty na froncie to dodatkowe zapytania. Sprawdź, czy Redis lub Memcached jest faktycznie włączony, a nie tylko obecny w konfiguracji serwera.
• W PrestaShop sprawdź indeksy na kolumnach używanych w filtrach — Kategorie z tysiącami kombinacji atrybutów generują ogromną liczbę adresów i ciężkie zapytania. Zweryfikuj plan zapytania (EXPLAIN), nie domysły.
• W WooCommerce sprawdź rozmiar tabeli wp_options — Tabela rośnie od wtyczek i danych tymczasowych. Sprawdź liczbę wierszy i obecność wpisów z autoload ustawionym na tak.
• Wyłącz pojedynczo wtyczki podejrzane o ciężkie zapytania — Testuj na kopii sklepu, po jednej wtyczce, mierząc TTFB przed i po. Różnica rzędu setek milisekund wskazuje winowajcę.
• Sprawdź kanoniczne adresy i dane strukturalne na kartach produktów — Jeden produkt dostępny pod kilkoma adresami musi mieć wskazany canonical. Dane strukturalne produktu sprawdź w testerze Google, zanim wejdą na produkcję.

Najczęściej zadawane pytania

Źródła i materiały

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