SEO techniczne i szybkość sklepu

SEO techniczne i optymalizacja szybkości w Biłgoraju sprowadza się do trzech rzeczy: Google musi mieć dostęp do indeksowania, musi rozumieć strukturę sklepu, a strona musi odpowiadać szybko. Szybkość nie jest osobnym projektem do odłożenia na później — to trzeci filar SEO technicznego, obok robots.txt i sitemap oraz canonicali i przekierowań. Największy problem małych i średnich sklepów to nie brak narzędzi, tylko brak kolejności: poprawki robi się raz na dwa lata, bez zapisanego stanu wyjściowego i bez osoby odpowiedzialnej. Ten tekst porządkuje temat od strony organizacyjnej — co ustalić, kto ma tego pilnować i po czym poznać, że praca idzie w dobrą stronę.

Co dokładnie obejmuje SEO techniczne i szybkość sklepu

SEO techniczne w sklepie internetowym to trzy filary, które trzeba traktować razem. Rozdzielanie ich to najczęstszy błąd organizacyjny — firma optymalizuje obrazy, podczas gdy połowa kategorii ma zostawione meta noindex po testach.

1. Dostępność do indeksowania. Plik robots.txt ma wpuszczać Googlebota na produkty i kategorie, a blokować koszyk, checkout i wewnętrzną wyszukiwarkę. Sprawdź, czy nie blokujesz katalogu /themes/ albo /media/ — zablokowany CSS psuje renderowanie i Google widzi stronę pustą. Sitemap.xml powinna zawierać wyłącznie adresy kanoniczne zwracające kod 200; adresy zwracające 301 w sitemapie to zgubiony sygnał.

2. Zrozumiałość struktury. Canonical self-referencing na produkcie i kategorii, uporządkowane parametry filtrów (?page=, ?orderby=, ?q=), jeden adres dla jednego produktu i przekierowania 301 bez łańcuchów dłuższych niż dwa przeskoki. W PrestaShop ustawiasz to w Preferencje → SEO i URL-e; w WooCommerce pilnujesz, żeby wtyczka SEO nie nadpisywała adresów po zmianie kategorii.

3. Wydajność — Core Web Vitals, TTFB i stabilność serwera, czyli brak błędów 5xx przy skoku ruchu. Dane laboratoryjne (Lighthouse, tryb lab w PageSpeed Insights) pokazują, co da się poprawić. Dane polowe (CrUX, raport Core Web Vitals w Search Console) pokazują, co realnie dostają użytkownicy — i to na nich opiera się ocena. Okno pomiarowe to 28 dni, więc jedna poprawka nie zmieni wyniku z dnia na dzień. Zakres kontroli jest identyczny w każdym mieście: SEO techniczne i optymalizacja szybkości w Krasnobrodzie to ten sam zestaw prac co w Biłgoraju — różni się tylko konkurencja w wynikach lokalnych. Sklep z Biłgoraja konkuruje w SERP-ach z ogólnopolskimi graczami, którzy mają zespoły SEO i budżety reklamowe. Higiena techniczna i szybkość to jeden z niewielu obszarów, na które mniejsza firma ma pełny wpływ — nie wymaga budżetu, tylko decyzji i kolejności.

Filar	Co sprawdzić w pierwszej kolejności	Typowy błąd
Dostępność indeksowania	robots.txt, meta robots, sitemap.xml, raport „Indeksowanie stron” w GSC	noindex pozostawiony po testach lub zablokowane CSS/JS w robots.txt
Struktura	canonicale, adresy URL, przekierowania 301	dwa adresy tego samego produktu bez canonicala
Wydajność	Core Web Vitals, TTFB, kody 5xx	optymalizacja frontendu przy TTFB powyżej 1,5 s

Core Web Vitals — jakie progi musisz osiągnąć w 2025 roku

Progi Core Web Vitals są jednoznaczne. Ocena dotyczy zawsze 75. percentyla dla urządzeń mobilnych — czyli 75% wejść musi zmieścić się w progu, a nie średnia z całego miesiąca. Jeden wolny szablon na telefonie psuje wynik całej grupy URL-i.

INP (Interaction to Next Paint) zastąpił FID w marcu 2024 roku. Jeśli w audycie nadal widzisz FID, audyt jest nieaktualny. INP mierzy pełne opóźnienie reakcji na kliknięcie lub dotknięcie — powyżej 200 ms winnych szukaj w ciężkich skryptach wtyczek, tag managerze z kilkunastoma tagami i nieużywanym kodzie śledzącym.

Poza CWV są progi, których Google nie ogłasza jako czynnika rankingowego, ale które wpływają na UX i crawl budget:

TTFB poniżej 800 ms — powyżej tego serwer nie nadąża i żadna optymalizacja obrazków tego nie ukryje.
Całkowita waga strony poniżej 2 MB na mobile.
Liczba requestów poniżej 60 na mobile.

Jak odróżnić problem z LCP po stronie serwera od problemu z frontendem: w PageSpeed Insights porównaj TTFB z LCP. Jeśli TTFB wynosi 1,2 s, a LCP 3,8 s, problem jest serwerowy — brak cache, wolne zapytania do bazy, przeciążony hosting współdzielony. Jeśli TTFB to 300 ms, a LCP 4 s, szukaj na froncie: nieoptymalizowany obraz hero bez preload i bez atrybutów width/height, plik CSS blokujący render, font wczytywany z zewnętrznego CDN albo lazy-loading włączony na obrazie hero. Pierwszy krok to sprawdzenie, czy hero ma loading="eager" i fetchpriority="high". Definicje i aktualne progi znajdziesz w dokumentacji Web Vitals na web.dev.

Wskaźnik	Dobry	Wymaga poprawy	Słaby
LCP (75. percentyl mobile)	poniżej 2,5 s	2,5–4,0 s	powyżej 4,0 s
INP	poniżej 200 ms	200–500 ms	powyżej 500 ms
CLS	poniżej 0,1	0,1–0,25	powyżej 0,25
TTFB (próg praktyczny)	poniżej 800 ms	800–1800 ms	powyżej 1800 ms

Audyt techniczny w 30 minut — co sprawdzić bezpłatnymi narzędziami

Ten scenariusz zajmuje około 30 minut i nie wymaga płatnych narzędzi. Kolejność ma znaczenie — zaczynasz od danych, które już masz.

Search Console (8 min). Raport „Indeksowanie stron” → grupa „Odkryte – obecnie niezaindeksowane”: zapisz liczbę adresów i dwa–trzy przykłady. Potem „Core Web Vitals” → zanotuj, ile URL-i jest w grupie „Słabe” i czy dominuje problem z LCP czy z CLS.
PageSpeed Insights (5 min). Wklej adres produktu, który daje największy ruch. Porównaj sekcję lab z „Wykryte dane użytkowników”. Jeśli dane polowe się nie pojawiają, URL ma za mały ruch, żeby trafić do CrUX.
Screaming Frog, wersja darmowa do 500 adresów (10 min). Włącz raporty: łańcuchy przekierowań, canonicale, błędy 404. Zapisz liczbę przekierowań w łańcuchu dłuższym niż 2, liczbę duplikatów canonical i adresy z 404.
WebPageTest (5 min). Wybierz lokalizację Warsaw, Poland, profil mobile. Sprawdź pierwsze ładowanie (nowy użytkownik) i drugie (stan po cache).
DevTools → zakładka Sieć (2 min). Wyłącz cache, odśwież stronę, posortuj po Size i po Time. Najcięższy zasób i najdłuższe zapytanie do serwera zapisz z nazwą i czasem — to one najczęściej odpowiadają za LCP.

Na koniec test hostingu: Apache Bench (ab -n 200 -c 10) albo k6 z 10 równoczesnymi użytkownikami na stronę kategorii. Jeśli średni czas odpowiedzi przekracza 1 s albo pojawiają się kody 5xx, problem jest po stronie serwera, nie szablonu. Czas odpowiedzi bazy sprawdzisz w slow query log MySQL — szukaj zapytań powyżej 200 ms.

Wszystkie liczby zapisz w jednym pliku z datą i osobą odpowiedzialną. Bez stanu wyjściowego nie udowodnisz, że poprawki cokolwiek zmieniły — SEO techniczne i optymalizacja szybkości w Frampolu prowadzimy według tej samej listy kontrolnej. Jeśli liczba stron „Odkryte – obecnie niezaindeksowane” rośnie z miesiąca na miesiąc, audyt trzeba powtórzyć.

Krok	Narzędzie	Co zanotować
1	Search Console	liczba URL-i w „Odkryte – obecnie niezaindeksowane”, grupa „Słabe” w raporcie CWV
2	PageSpeed Insights	wynik lab oraz dane polowe, TTFB i LCP dla najważniejszego adresu
3	Screaming Frog (free)	przekierowania 301 z łańcuchem powyżej 2, duplikaty canonical, błędy 404
4	WebPageTest (Warsaw)	najwolniejszy zasób, czas do pierwszego renderu na mobile
5	Apache Bench / k6	średni czas odpowiedzi i kody 5xx przy 10 równoczesnych użytkownikach

Najczęstsze przyczyny wolnego sklepu w PrestaShop i WooCommerce

Z wdrożeń sklepów w Biłgoraju i okolicy wynika, że właściciel szuka przyczyny tam, gdzie jej nie ma — najczęściej w wtyczce do cache. Ranking przyczyn według realnego wpływu na czas odpowiedzi wygląda inaczej:

Hosting i brak OPcache — odpowiada za TTFB na poziomie 1,5–4 s. Potwierdzenie jednym poleceniem: curl -o /dev/null -s -w "%{time_starttransfer}\n" https://twojsklep.pl. Wynik powyżej 0,8 s oznacza, że żadna wtyczka tego nie naprawi.
Nieoptymalizowane obrazy — 2–5 MB na stronę kategorii to standard po zmianie szablonu. DevTools → Network, sortowanie po Size i od razu widać baner 4000 px oraz dziesięć zdjęć po 600 KB.
Brak cache obiektowego (Redis/Memcached) — objaw to 200+ zapytań SQL na stronę kategorii. Query Monitor pokaże liczbę zapytań i czas ich wykonania.
Wtyczki ładujące skrypty globalnie — slider wgrywa CSS i JS także w koszyku i na stronie kontaktu. Sprawdź w DevTools, które pliki ładują się na każdej podstronie.
PrestaShop: brak kompilacji szablonów (Zaawansowane → Wydajność → „Kompilacja szablonów: nigdy nie kompiluj”), pozostawiony tryb debug (_PS_MODE_DEV_ w config/defines.inc.php) wyłączający cache, nieindeksowane klucze obce w bazie, zapytania N+1 w listach produktów.
WooCommerce: page builder ładujący CSS na całym sklepie, brak HPOS przy kilkunastu tysiącach zamówień (zamówienia jako wpisy w wp_posts), nieużywane wtyczki zostawiające tabele, WP-Cron odpalany przez ruch użytkowników zamiast DISABLE_WP_CRON i prawdziwego crona co 5 minut.

Zakres metryk, na które realnie patrzy Google, opisuje Web Vitals na web.dev. Jeśli podejrzewasz warstwę WooCommerce, zacznij od uporządkowania projektu — zobacz, jak wygląda wdrożenie i uporządkowanie WooCommerce, bo część „wolnych” sklepów to skutek dokładania wtyczek bez planu.

Przyczyna	Typowy objaw / wartość	Jak potwierdzić w kilka minut
Wolny hosting, brak OPcache	TTFB 1,5–4 s	curl z time_starttransfer albo phpinfo() i sekcja OPcache
Nieoptymalizowane obrazy	2–5 MB na stronę kategorii	DevTools → Network → sortowanie po Size
Brak Redis/Memcached	200+ zapytań SQL na listę produktów	Query Monitor w WooCommerce, profilowanie SQL w PrestaShop
Wtyczki ładujące skrypty globalnie	te same pliki CSS/JS na wszystkich podstronach	DevTools → Network, filtr po CSS i JS
PrestaShop: brak kompilacji szablonów, tryb debug	każde wejście przelicza szablony	Zaawansowane → Wydajność oraz config/defines.inc.php
WooCommerce: brak HPOS, WP-Cron od ruchu	rosnąca tabela wp_posts, cron nieregularny	WooCommerce → Ustawienia → Zaawansowane, wtyczka WP Crontrol

Optymalizacja krok po kroku — od serwera do frontendu

Kolejność jest ważniejsza niż narzędzia. Optymalizacja CSS, gdy serwer odpowiada po 3 sekundach, to praca w miejscu. Pięć etapów, w tej kolejności:

Infrastruktura (2–4 h). PHP 8.2 lub 8.3, OPcache z opcache.memory_consumption 128–256 MB i opcache.max_accelerated_files powyżej 10 000, Redis lub Memcached, HTTP/2 lub HTTP/3, kompresja Brotli, nagłówki Cache-Control: public, max-age=31536000, immutable dla plików statycznych z hashem w nazwie oraz no-cache dla HTML.
Baza danych (3–8 h). Indeksy na kolumnach filtrowanych i sortowanych, czyszczenie tabel logów, sesji i porzuconych koszyków (w PrestaShop m.in. ps_connections, ps_guest, ps_cart), przebudowa zapytań list produktowych, a przy stałym ruchu — osobny serwer bazy. Strukturę tabel i konfigurację środowiska opisuje dokumentacja dla deweloperów PrestaShop.
Frontend (4–10 h). Konwersja do WebP/AVIF daje 30–60% oszczędności wagi, srcset z realnymi rozmiarami, lazy loading dla wszystkiego poza obrazem LCP, fonty lokalne z font-display: swap.
CSS/JS (4–12 h). Krytyczny CSS inline, odroczenie skryptów niezwiązanych z widokiem, usunięcie nieużywanego CSS. Agregacja — ostrożnie, bo potrafi wysypać moduły płatności i koszyk. Po każdym włączeniu przetestuj pełną ścieżkę zakupu, nie tylko stronę główną.
CDN i cache (2–4 h). Warstwa CDN przed serwerem, cache pełnostronicowy z wykluczeniem koszyka, zamówienia i panelu klienta.

Pułapka numer jeden: włączenie agregacji i wtyczki cache jako pierwszy krok. Efekt to wyższy wynik w PageSpeed i nieprzechodzący checkout. Ten sam porządek prac stosujemy w mniejszych sklepach — np. przy optymalizacji szybkości sklepu w Szczebrzeszynie różni się tylko skala, nie kolejność.

Etap	Zakres	Realny czas wdrożenia
1. Infrastruktura	PHP 8.2/8.3, OPcache, Redis/Memcached, HTTP/2–3, Brotli, nagłówki Cache-Control	2–4 h
2. Baza danych	indeksy, czyszczenie logów i koszyków, zapytania list produktowych, osobny serwer bazy	3–8 h
3. Frontend	WebP/AVIF, srcset, lazy loading poza LCP, fonty lokalne	4–10 h
4. CSS/JS	krytyczny CSS inline, defer, usuwanie nieużywanego CSS, ostrożna agregacja	4–12 h
5. CDN i cache	CDN przed serwerem, cache pełnostronicowy z wykluczeniami	2–4 h

SEO techniczne poza szybkością — indeksowanie, canonicale, dane strukturalne

Sama szybkość nie naprawi problemów z indeksacją. Lista rzeczy do sprawdzenia jest krótka i konkretna:

Sitemap.xml generowana dynamicznie — statyczny plik z 2021 zawiera produkty, których już nie ma, i nie zawiera nowych. W PrestaShop i WooCommerce generuje ją moduł lub wtyczka; wystarczy włączyć i zgłosić adres w Search Console.
robots.txt bez blokowania CSS i JS — Disallow: /wp-content/ lub Disallow: /themes/ to klasyk. Google renderuje stronę i bez arkuszy nie widzi układu ani części treści.
Paginacja z produktami bez noindex — blokada stron 2, 3, 4 odcina linki wewnętrzne do produktów z dalszych pozycji.
404 i 410 — 404 dla adresów błędnych, 410 dla trwale usuniętych produktów.
Łańcuchy przekierowań maksymalnie 1 krok — 301 → 301 → 200 to strata czasu i części sygnałów.
Canonicale na stronach filtrowanych i sortowanych — ?orderby=price, ?filter= generują tysiące adresów z tą samą treścią. To najczęstszy powód duplikatów w sklepie.
Dane strukturalne JSON-LD: Product, Offer, AggregateRating, BreadcrumbList, Organization. Cena w Offer musi zgadzać się z ceną na stronie — rozjazd kończy się utratą wyników rozszerzonych. Listę typów wspieranych przez Google znajdziesz w dokumentacji danych strukturalnych.
Mobile-first: test „Sprawdź zgodność z urządzeniem mobilnym” plus realny test na 360 px — czy koszyk, filtry i płatność są klikalne palcem.
Po wdrożeniu: raport „Strony” w Search Console i porównanie liczby zaindeksowanych URL przed i po. Zmiany rób partiami — inaczej nie wiadomo, co wywołało spadek. Ten sam zestaw ustaleń stosujemy w mniejszych lokalizacjach, np. w SEO technicznym i optymalizacji szybkości w Zwierzyńcu.

Pułapki, które psują wyniki po optymalizacji

Najczęstszy scenariusz: po audycie sklep ma LCP 2,1 s, a trzy tygodnie później 4,3 s. Ktoś „przyspieszył” stronę i coś się rozjechało. Poniżej pięć pułapek, które widzimy najczęściej w sklepach na PrestaShop i WooCommerce.

Lazy loading na obrazie LCP. Wtyczka do optymalizacji dodaje loading="lazy" do wszystkich obrazów — także do banera nad zagięciem. Przeglądarka pobiera go dopiero po sparsowaniu JS. LCP rośnie o 1–2 s bez żadnej korzyści. Poprawka: na obrazie LCP ustawiasz loading="eager" i fetchpriority="high". W PrestaShop to plik szablonu (index.tpl, product.tpl), w WooCommerce szablon produktu lub functions.php.
Cache pełnostronicowy łapiący stan koszyka. Moduł zapisuje HTML dla gościa i oddaje go klientowi, który ma już produkt w koszyku. Objaw: pusty mini-koszyk, cena netto zamiast brutto, powitanie dla niezalogowanego. Test: dodaj produkt do koszyka i odśwież stronę pięć razy w trzech różnych kartach.
Minifikacja i agregacja JS rozbijająca moduły. Zmiana kolejności skryptów wystarczy, żeby płatność online przestała się ładować. Po każdym wdrożeniu przechodzisz pełną ścieżkę zakupu: trzy metody płatności, kalkulację kuriera, eksport zamówienia do ERP. Nie tylko stronę główną i kartę produktu.
Baner cookies i chat bez zarezerwowanego miejsca. Wstrzyknięte po dwóch sekundach przesuwają treść i CLS wychodzi powyżej 0,25 (próg „do poprawy” to 0,1). Rozwiązanie: stały placeholder o zdefiniowanej wysokości albo position: fixed, który nie wpływa na przepływ dokumentu.
CDN bez reguł dla zalogowanych i bez purge. Katalog potrzebuje osobnego cache dla sesji niezalogowanej, a odpowiedzi dla zalogowanych Cache-Control: no-store. Po zmianie ceny lub stanu magazynowego CDN musi dostać purge — inaczej klient kupi po starej cenie.

Progi LCP, INP i CLS bierz z oficjalnego opisu Web Vitals — to jedyne liczby, które warto wpisać do umowy z wykonawcą.

Pułapka	Objaw	Minimalny test
Lazy loading na LCP	LCP wyższe o 1–2 s	DevTools → Elements, sprawdź atrybut na obrazie nad zagięciem
Cache łapiący koszyk	Pusty mini-koszyk, zła cena	Dodaj produkt, odśwież 5× w trzech kartach
Agregacja JS	Płatność lub kurier nie działa	Zamówienie testowe na każdą metodę płatności
Cookies / chat	CLS powyżej 0,25	Lighthouse mobile, zakładka Layout shifts
CDN bez purge	Stara cena lub stan magazynowy	Zmień cenę i sprawdź stronę po 2 minutach

Ile to trwa i ile kosztuje — realne widełki dla MŚP

Widełki, które podajemy sklepom z Biłgoraja i okolic, wyglądają podobnie niezależnie od branży — różni się tylko nakład. Trzy warianty:

Szybki audyt — 4–8 h. Dostajesz listę 15–30 konkretów z priorytetami i szacunkiem zysku w sekundach. Bez wdrożenia. Sensowne, gdy sklep ma już kogoś do wprowadzania zmian.
Optymalizacja techniczna — 20–40 h. Audyt plus wdrożenie szybkości i najprostszych poprawek indeksowania. Zwykle 5–10 dni roboczych rozłożonych na trzy tygodnie, bo część zmian wymaga obserwacji.
Kompleksowe SEO techniczne z wdrożeniem — 40–80 h. Dochodzą canonicale, przekierowania 301, dane strukturalne, praca z indeksem i treścią szablonów.

Na szacunek wpływa pięć rzeczy: liczba produktów (10 000 SKU to inna baza niż 300), liczba szablonów stron, stan bazy (zaśmiecone tabele po odinstalowanych modułach), jakość hostingu (współdzielony kontra VPS z OPcache) oraz liczba integracji — każda płatność, kurier i ERP to osobny punkt do przetestowania.

Czego nie ocenia się po trzech dniach: CrUX publikuje dane po 28 dniach, więc LCP i INP sprawdzasz po tym okresie dla 75. percentyla ruchu mobilnego. Poza tym patrzysz na pozycje na wybrane 20–30 fraz, liczbę błędów w GSC i konwersję. Chwilowy spadek konwersji w pierwszych dniach po zmianach zdarza się często i nie znaczy, że wdrożenie było złe — znaczy, że trzeba ponownie przejść pełną ścieżkę zakupu.

Pracujemy bezpośrednio z deweloperem, który wdraża poprawki. Mniej godzin idzie na przekazywanie kontekstu między pośrednikami, jedna osoba odpowiada za wynik. Podobny zakres dla mniejszego sklepu opisaliśmy przy okazji SEO technicznego i optymalizacji szybkości w Krasnobrodzie.

Pakiet	Nakład	Co obejmuje	Kiedy ma sens
Szybki audyt	4–8 h	Lista poprawek z priorytetami i szacunkiem zysku w sekundach	Gdy zmiany wdraża ktoś po stronie klienta
Optymalizacja techniczna	20–40 h	Audyt i wdrożenie szybkości oraz podstaw indeksowania	Gdy sklep wolno się ładuje, a indeks jest w miarę czysty
SEO techniczne z wdrożeniem	40–80 h	Canonicale, 301, dane strukturalne, praca z indeksem i szablonami	Gdy sklep ma tysiące SKU i wiele integracji

Lista kontrolna przed i po wdrożeniu

Lista do wydrukowania i odklikania w rozmowie z wykonawcą. Punkty oznaczone [WP] mają najwyższy wpływ — szacowany zysk 0,5–2 s albo odblokowanie indeksowania. Od nich zaczynasz.

Przed audytem

Stan wyjściowy zapisany. Kryterium: raport z PageSpeed Insights i WebPageTest (Warszawa, Moto G Power, 4G) zapisany jako PDF lub JSON z datą, plus wersja szablonu i lista aktywnych wtyczek.
Dostęp do GSC i lista fraz. Kryterium: konto z uprawnieniem właściciela lub pełnym, eksport 20–30 fraz z widocznością i pozycją.

Infrastruktura

TTFB poniżej 800 ms [WP]. Pomiar w WebPageTest z lokalizacji Warszawa, trzy przebiegi, bierzesz medianę.
PHP 8.1 lub nowsze i OPcache. Kryterium: opcache.enable=On i hit rate powyżej 95% po tygodniu pracy.
Kopia bazy i plików oraz środowisko staging. Bez tego nie zaczynasz. Kryterium: udany testowy restore w ciągu 60 minut.

Frontend

Obraz LCP bez lazy loadingu [WP, 0,5–2 s]. Kryterium: w kodzie loading="eager" i fetchpriority="high" na obrazie nad zagięciem.
CLS poniżej 0,1 na mobile. Baner cookies i chat mają zarezerwowane miejsce; sprawdzasz w DevTools z throttlingiem 4x CPU.
Fonty hostowane lokalnie, preload dla maksymalnie dwóch plików.

SEO techniczne

robots.txt nie blokuje /modules/, /js/ ani /css/. Kryterium: test na żywo w GSC → inspekcja adresu URL.
Sitemap bez błędów 404 i zgłoszona w GSC.
Canonical na produktach i 301 z URL z parametrami (?orderby=, ?id_lang=).
Dane strukturalne Product, Offer, BreadcrumbList [WP]. Kryterium: brak błędów w Rich Results Test — wymagania opisuje dokumentacja Google o obsługiwanych danych strukturalnych.

Po wdrożeniu

Zamówienie testowe end-to-end. Trzy metody płatności, kalkulacja kuriera, eksport do ERP. Kryterium: zamówienie przechodzi bez ręcznej ingerencji.
CrUX po 28 dniach. Kryterium: LCP poniżej 2,5 s i INP poniżej 200 ms dla 75. percentyla na mobile.
GSC: liczba błędów indeksowania nie wzrosła. Kryterium: brak nowych 404 i błędów serwera w raporcie stron.

Ten sam zestaw kryteriów stosujemy w mniejszych miejscowościach — zobacz, jak wygląda to dla SEO technicznego i optymalizacji szybkości w Zwierzyńcu.

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

Szybkość traktowana jako osobny projekt „na później”, poza zakresem SEO technicznego.

Jak wykryć: W dokumentacji SEO nie ma ani jednego wpisu o Core Web Vitals, a temat wraca dopiero wtedy, gdy spada ruch z Google.

Jak naprawić: Wpisz wydajność do tego samego zakresu co indeksowanie i canonicale. Jeden właściciel tematu, jeden backlog, jedna data przeglądu w kwartale.

Optymalizacja bez zapisanego stanu wyjściowego — nikt nie wie, czy cokolwiek się poprawiło.

Jak wykryć: Na pytanie „jakie było LCP dla mobile przed zmianami?” nie ma odpowiedzi w żadnym pliku ani zrzucie ekranu.

Jak naprawić: Zapisz raport Core Web Vitals w Search Console (zakładka mobile, 75. percentyl) i wyniki PageSpeed Insights dla 5 najważniejszych URL-i. To Twój punkt odniesienia.

Testowanie wyłącznie na desktopie i z biura, na szybkim łączu.

Jak wykryć: Strona „chodzi” na stanowisku właściciela, a raport polowy w Search Console określa większość URL-i jako słabe.

Jak naprawić: Ustaw mierzenie na mobile: PageSpeed Insights w trybie mobilnym i WebPageTest z lokalizacji Warszawa. To bliżej realnego użytkownika niż test lokalny.

Gonienie wyniku 100/100 w PageSpeed Insights zamiast progów Core Web Vitals.

Jak wykryć: Zespół raportuje wynik z laboratorium, a w Search Console nadal setki adresów ze statusem „wymaga poprawy”.

Jak naprawić: Cel ustaw na 75. percentyl dla mobile: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Wynik lab traktuj jako wskazówkę, nie jako KPI.

Nakładanie kolejnych wtyczek cache i minify bezpośrednio na produkcję, bez kopii testowej.

Jak wykryć: Po włączeniu nowej wtyczki koszyk, checkout lub logowanie zachowują się inaczej niż wcześniej.

Jak naprawić: Każdą wtyczkę wydajnościową testuj najpierw na kopii sklepu, a po wdrożeniu na produkcję przejdź całą ścieżkę zakupu od dodania produktu do potwierdzenia zamówienia.

Brak osoby odpowiedzialnej i terminu — zadania z audytu wiszą tygodniami.

Jak wykryć: Nikt nie potrafi powiedzieć, kto ma zamówić lepszy hosting albo kto wgra poprawione obrazy.

Jak naprawić: Przypisz konkretne osoby: zadania techniczne do wykonawcy, decyzje i budżet do właściciela firmy. Ustal datę wdrożenia i datę ponownego pomiaru.

Lista kontrolna do odklikania

robots.txt i noindex — Sprawdź, czy kluczowe kategorie i karty produktów nie są zablokowane. Raz na kwartał oraz po każdej zmianie, która przechodzi ze stagingu na produkcję.
Sitemap w Search Console — Porównaj liczbę URL-i w sitemap z liczbą stron w raporcie „Strony”. Duża rozbieżność oznacza problem z indeksowaniem, nie z treścią.
Raport Core Web Vitals — W Search Console przełącz na mobile i zapisz liczbę URL-i w grupie „wymaga poprawy”. To najważniejsza liczba w całym audycie.
PageSpeed Insights: lab i field — Uruchom dla strony głównej, kategorii z największym ruchem i najpopularniejszego produktu. Sekcja danych polowych jest ważniejsza od wyniku laboratoryjnego.
Screaming Frog w wersji darmowej — Limit 500 URL-i wystarczy na mniejszy sklep. Sprawdź łańcuchy przekierowań, kody odpowiedzi 404 i duplikaty canonicali.
Łańcuchy przekierowań — Wyeliminuj adresy, które przechodzą przez więcej niż 2 przekierowania. Każdy dodatkowy krok wydłuża czas odpowiedzi i rozmywa sygnały.
Duplikaty canonicali — Jeden adres docelowy = jedna strona. Sprawdź, czy filtry, sortowanie i parametry nie generują setek wariantów z tym samym canonicalem lub bez niego.
TTFB na produkcji — Cel: poniżej 800 ms. Mierz na stronie po wyczyszczeniu cache, np. na pierwszym wejściu na kartę produktu.
Waga strony — W DevTools otwórz zakładkę „Sieć” i sprawdź transfer. Cel dla strony kategorii to poniżej 2 MB. Najczęstsza przyczyna przekroczenia to nieskompresowane obrazy.
Liczba requestów — Na mobile cel to poniżej 60 zapytań. Jeśli licznik pokazuje 120 i więcej, poszukaj wtyczek ładujących skrypty i style na całym sklepie.
OPcache i cache obiektowy — Zapytaj hosting, czy OPcache PHP jest włączony. W WooCommerce i PrestaShop rozważ Redis lub Memcached — to zwykle najtańszy zysk w TTFB.
Test obciążenia — Uruchom 10 równoczesnych użytkowników i zmierz czas odpowiedzi bazy. Jeśli TTFB rośnie skokowo, problem jest po stronie serwera, a nie motywu.
Cron i resztki po wtyczkach — WP-Cron odpalany przez ruch odwiedzających potrafi dławić sklep. Sprawdź też, czy po usuniętych wtyczkach nie zostały tabele i zadania w bazie.

Podsumowanie

Szybkość sklepu to trzeci filar SEO technicznego, a nie dodatek do niego — dlatego powinna trafić do tego samego backlogu co indeksowanie i canonicale. Zapisz stan wyjściowy, ustal progi Core Web Vitals w 75. percentylu dla mobile i przypisz jedną osobę do pilnowania tematu. Ten sam schemat pracy stosujemy w sklepach z okolic Biłgoraja, m.in. we Frampolu i Krasnobrodzie. Bez tych trzech elementów kolejna optymalizacja znów zakończy się na liście rzeczy do zrobienia.

Najczęściej zadawane pytania

Czy szybkość strony to część SEO technicznego, czy osobny temat?

To część SEO technicznego — obok dostępu do indeksowania i zrozumiałości struktury. Google ocenia wydajność na podstawie danych polowych, czyli realnych wizyt użytkowników, a nie pojedynczego testu w laboratorium. Dlatego jednorazowe „projekty szybkościowe” raz na dwa lata zwykle nie dają trwałego efektu.

Od czego zacząć, jeśli mam mały budżet?

Od darmowej diagnozy: raport Core Web Vitals w Search Console, PageSpeed Insights i Screaming Frog do 500 URL-i. Dopiero potem wydawaj pieniądze — najczęściej największy zwrot daje hosting, kompresja obrazów i cache, a nie wymiana motywu. Zapisz stan wyjściowy, żeby po miesiącu móc porównać dane polowe.

Czy muszę mieć 100/100 w PageSpeed Insights?

Nie. Wynik laboratoryjny to wskazówka, a nie cel biznesowy. Liczy się 75. percentyl dla mobile: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Realistyczny cel dla sklepu to status „dobry” w raporcie polowym dla większości adresów.

Jak często powtarzać audyt techniczny?

Pełny przegląd raz na kwartał, a szybki rzut oka na Search Console po każdej większej zmianie: nowy motyw, aktualizacja PrestaShop lub WooCommerce, nowa wtyczka. Przy każdej takiej okazji zapisz nowy pomiar TTFB i LCP, żeby wiedzieć, czy było warto.

Czy przeniesienie sklepu na VPS zawsze przyspieszy stronę?

Nie zawsze. Jeśli problemem są obrazy po 3 MB albo kilkadziesiąt wtyczek ładujących skrypty na każdej stronie, szybszy serwer podniesie tylko koszt. Najpierw zmierz TTFB, wagę strony i liczbę zapytań do bazy, a decyzję o hostingu podejmij na podstawie tych liczb.

Kto w firmie powinien pilnować tematu szybkości i SEO technicznego?

Jedna osoba po stronie firmy jako właściciel tematu i jedna po stronie wykonawcy technicznego. Bez tego zadania z audytu rozjeżdżają się między działami i nikt nie czuje się za nie odpowiedzialny. Właściciel pilnuje terminów i budżetu, wykonawca — wdrożeń i ponownych pomiarów.

Jeśli chcesz, żeby ktoś przeszedł z Tobą przez audyt techniczny i wskazał, co poprawić w pierwszej kolejności — napisz do nas. Powiemy wprost, co da się zrobić w Twoim budżecie, a czego robić nie warto.