Dlaczego szybkość i SEO techniczne decydują o sprzedaży w Zamościu

Badania branżowe publikowane przez Google pokazują tę samą zależność: skrócenie czasu ładowania o 0,1 s podnosiło konwersję w sklepach detalicznych o kilka procent, a wydłużenie o sekundę działa w drugą stronę — ruch ten sam, zamówień mniej. Skala różni się w zależności od branży, ale kierunek jest stały: wolniej znaczy mniej zamówień. Najmocniej widać to na telefonach.

Policz to na swoim przykładzie. Sklep z 4 000 sesji miesięcznie i konwersją 1,5% daje 60 zamówień. Jeśli wolne ładowanie strony produktu obniży konwersję o 10%, zostaje 54 zamówienia — przy średniej wartości 200 zł to 1 200 zł mniej miesięcznie i blisko 15 000 zł rocznie. Do tego dochodzi koszyk: klient dodaje produkt, przechodzi do koszyka, a tam dociąga się skrypt płatności i podsumowanie zamówienia. Przy TTFB 1,8 s i LCP 5 s część osób zamyka kartę, bo nie widzi, czy zakup się zapisał. Nie wysyła wtedy żadnego formularza — po prostu wychodzi.

Dla firmy z Zamościa i okolic wynik mobilny w PageSpeed Insights jest ważniejszy niż desktopowy. Znacząca część zapytań lokalnych („naprawa opon Zamość”, „kwiaciarnia Zamość”) to telefony, często na zasięgu LTE, a nie na światłowodzie. Strona z desktopowym 95 i mobilnym 42 jest w praktyce wolna dla większości Twoich klientów. Sprawdź regiony w Hrubieszowie i Lublinie: te same progi, ten sam problem z kompresją obrazów i cache.

Ustaw priorytety tak: najpierw odpowiedź serwera i indeksacja, potem treść i linki. Techniczne SEO to fundament — bez indeksowalnych adresów i szybkiego serwera najlepszy tekst nie zadziała. Kolejność i progi weryfikujesz w dokumentacji Google dotyczącej Core Web Vitals.

Audyt techniczny w 90 minut — od czego zacząć, żeby nie zgadywać

Zanim zapłacisz za audyt, zrób go sam. Całą sekwencję da się zamknąć w 90 minutach, jeśli trzymasz się kolejności narzędzi. Zapisuj każdą liczbę w jednym arkuszu — inaczej po tygodniu nie pamiętasz, co było punktem wyjścia.

0–10 min: Google Search Console. Zakładka „Indeksowanie > Strony”. Sprawdź, ile adresów jest zindeksowanych, a ile wykluczonych, i rozwiń powody: „Odkryto – obecnie nie zindeksowano”, „Zindeksowano, choć zablokowano w pliku robots.txt”, błędy 404, „Alternatywna strona z tagiem kanonicznym”. Osobno „Core Web Vitals” — tam zobaczysz grupy adresów URL z problemami, z podziałem na mobile i desktop. Raport użyteczności mobilnej sprawdź, jeśli jest widoczny w Twojej wersji usługi — Google stopniowo przenosi te dane do innych raportów.

10–30 min: PageSpeed Insights. Nie testuj tylko strony głównej. Wybierz 5 adresów: główna, kategoria, produkt, koszyk, kontakt. Dla każdego zapisz mobilne LCP, INP (lub TBT) i CLS oraz TTFB. Dopiero te 15 liczb pokazuje, gdzie naprawdę boli.

30–75 min: Screaming Frog, wersja darmowa do 500 adresów URL. Skanuj stronę i filtruj: łańcuchy przekierowań 301 → 301, 404 wewnętrzne, duplikaty title i description, strony z noindex, które powinny być indeksowane, adresy z kanonicznym wskazującym na inny URL, strony o rozmiarze HTML powyżej 500 kB. W tej samej wersji sprawdzisz poprawność danych strukturalnych obsługiwanych przez Google.

75–90 min: test indeksacji. Wpisz w Google site:twojadomena.pl i porównaj liczbę wyników z liczbą w Search Console. Potem narzędzie „Sprawdź adres URL” dla trzech stron, które zarabiają najwięcej.

Jak odróżnić problemy? Indeksacja — strona nie pojawia się w wynikach, ma noindex, blokadę w robots.txt albo status „Odkryto, nie zindeksowano”. Szybkość — strona jest w wynikach, ale PSI i CrUX są słabe, a w GA4 widzisz wysokie współczynniki odrzuceń na mobile. Na koniec: lista 10 adresów do naprawy. Kolejność ustal wg ruchu i przychodu, nie wg tego, co najłatwiej poprawić.

Core Web Vitals bez tajemnic: progi, jednostki, mierzenie

Core Web Vitals to trzy metryki z jasnymi progami. LCP (Largest Contentful Paint) mierzy, kiedy widać największy element — zwykle baner albo zdjęcie produktu. Poniżej 2,5 s jest dobrze, 2,5–4 s to „do poprawy”, powyżej 4 s to wynik zły. W przedziale 2,5–4 s wciąż masz szansę na ruch, ale tracisz część osób; powyżej 4 s na telefonie z LTE klient często nie doczeka.

INP (Interaction to Next Paint) poniżej 200 ms jest dobry, 200–500 ms wymaga poprawy, powyżej 500 ms jest zły. Na sklepach INP psuje najczęściej koszyk: przeliczanie podsumowania po każdej zmianie ilości, walidacja kodu pocztowego w JavaScript, filtry fasetowe w PrestaShop (blok warstwowy odpalający zapytania do bazy przy każdym kliknięciu) oraz slajdery na stronie głównej. Winne są też długie zadania powyżej 50 ms i zewnętrzne skrypty czatu czy marketing automation wczytywane w bloku head.

CLS poniżej 0,1 jest dobry, 0,1–0,25 wymaga poprawy, powyżej 0,25 jest zły. Najczęstsze przyczyny: zdjęcia bez atrybutów width i height, baner cookies wstawiany bez zarezerwowanego miejsca i podmiana fontu bez parametru size-adjust.

Ważniejsza różnica: dane laboratoryjne kontra polowe. Lighthouse w PageSpeed Insights to symulacja na jednym, z góry ustalonym urządzeniu. CrUX to 28 dni rzeczywistych wizyt Twoich klientów, raportowane jako 75. percentyl — i to na CrUX patrzy się przy ocenie strony. Laboratorium służy do diagnozy, polowe dane do oceny. TTFB to ukryty winowajca: powyżej 1,8 s w B2B i w sklepie z ciężkim backendem prawie zawsze oznacza problem hostingu — brak OPcache i object cache, shared hosting bez CDN, moduły dociążające każdy request. Pełne definicje i jednostki są w dokumentacji Web Vitals. Jeśli działasz w Skierbieszowie, Narolu czy Bełżcu, progi są identyczne — różni się tylko to, jak wolne łącze ma Twój klient.

Optymalizacja szybkości — kolejność działań z największym zwrotem

Kolejność działań wynika z prostej zasady: najpierw skracamy czas odpowiedzi serwera, potem wszystko inne. Minifikacja CSS bez cache'u to kilka procent zysku — cache serwerowy to często kilkaset milisekund na TTFB. Realna kolejność wygląda tak:

1. Cache po stronie serwera. Zacznij od OPcache w PHP: opcache.enable=1, opcache.memory_consumption=128–256, opcache.max_accelerated_files=10000. Jedno ustawienie w php.ini, zero zmian w kodzie. Dalej object cache — Redis albo Memcached — dla WordPressa (wtyczka Redis Object Cache) i PrestaShop. Na końcu pełny cache stron: LiteSpeed Cache, WP Rocket lub natywny full-page cache PrestaShop. Pułapka: cache pełnostronicowy musi omijać koszyk, logowanie i płatność, inaczej klient zobaczy dane innego użytkownika.
2. Obrazy. Konwersja do WebP lub AVIF, srcset z kilkoma szerokościami, lazy loading. Kluczowy wyjątek: pierwszy, największy obraz (baner, zdjęcie główne produktu) nie może mieć loading="lazy" — ustaw mu fetchpriority="high". Cel: LCP poniżej 2,5 s.
3. Zasoby blokujące renderowanie. Critical CSS inline, defer dla skryptów, async tylko dla niezależnych. Ograniczenie liczby wtyczek i modułów: na typowym sklepie kilkadziesiąt aktywnych rozszerzeń to najczęstsze źródło 1–2 s opóźnienia, którego nie naprawi żadna minifikacja.
4. Hosting i CDN. Jeśli po powyższych krokach TTFB nadal przekracza około 600 ms, problem jest w infrastrukturze. Przejście ze współdzielonego hostingu na VPS albo hosting z LiteSpeed/nginx daje więcej niż kolejny tydzień optymalizacji frontu.

Progi i definicje metryk znajdziesz w dokumentacji Core Web Vitals na web.dev. Ten sam schemat wdrożenia opisaliśmy dla firm z Hrubieszowa i okolic.

SEO techniczne: indeksacja, crawl i dane strukturalne

Szybkość to tylko połowa SEO technicznego. Druga połowa to kontrola nad tym, co Google może zaindeksować — i tu najczęściej „giną” produkty.

Indeksacja. Sprawdź kolejno: robots.txt (wpis Disallow: / zostawiony po etapie budowy potrafi siedzieć miesiącami), meta robots w szablonie oraz ustawienia noindex w panelu sklepu. W PrestaShop noindex i nofollow dla stron filtrów konfiguruje się przy przyjaznych URL-ach; jeśli administrator włączy wykluczenie zbyt szeroko, z indeksu wypadają też karty produktów. Objaw: „produkt zniknął z Google”, a w Search Console rośnie liczba stron wykluczonych.

Duplikaty i canonical. Na sklepie z filtrami jeden produkt ma dziesiątki adresów: ?limit=24, ?orderby=price, ?page=2, parametry trackingowe. Rozwiązanie: canonical wskazujący na wersję bazową, blokada indeksowania stron sortowania i filtrów, spójna paginacja. Paginacja nie powinna być noindex — linki z niej prowadzą do kart produktów.

Mapa strony XML. Ma zawierać wyłącznie adresy zwracające 200 i przeznaczone do indeksacji. Po imporcie produktów, dodaniu kategorii czy zmianie struktury wygeneruj mapę ponownie i zgłoś w Search Console — bez tego Google dowiaduje się o nowych adresach z opóźnieniem.

Dane strukturalne. Product i Offer dają szansę na cenę oraz dostępność w wynikach, BreadcrumbList odtwarza ścieżkę, LocalBusiness opisuje firmę. Listę obsługiwanych typów znajdziesz w dokumentacji danych strukturalnych Google Search Central. Wdrożenie sprawdzasz walidatorem i raportem w Search Console. Podobne audyty prowadzimy dla sklepów z Biłgoraja i Frampola.

Lokalne SEO dla Zamościa i Lubelszczyzny — co dodać ponad standard

Techniczne SEO przekłada się na widoczność lokalną tylko wtedy, gdy dane firmy są spójne w każdym miejscu. Klient z Zamościa i powiatów ościennych szuka zwykle frazą „usługa + miasto”, a Google porównuje sygnały z witryny, z profilu firmy i z katalogów.

Google Business Profile. Nazwa, adres i telefon muszą być identyczne jak w stopce witryny i w danych strukturalnych. Ustal jeden format zapisu — „ul. Przykładowa 1, 22-400 Zamość” — a nie raz z „ul.”, raz bez, raz z kodem pocztowym. Wybierz jedną kategorię główną i kilka dodatkowych, wgraj 10–15 zdjęć (wnętrze, realizacje, zespół) i odświeżaj je co kwartał, dodawaj wpisy z aktualną ofertą. To wpływa na widoczność w lokalnym pakiecie mapy i na liczbę połączeń z profilu.

Schema LocalBusiness. Adres, godziny otwarcia i areaServed w kodzie strony. Dla firmy z Zamościa sensowny zakres to „Zamość i powiat zamojski” albo „województwo lubelskie” — nie cała Polska, bo rozmywa sygnał. Zgodność danych strukturalnych z profilem firmy jest warunkiem, nie dodatkiem.

Strony lokalizacyjne. Podstrona „obsługa Zamość” działa, gdy różni się treścią: konkretne realizacje, terminy dojazdu, koszt, opinie klientów z tego obszaru. Kopia tego samego tekstu z podmienioną nazwą miasta to thin content — mechanizm opisuje dokumentacja treści przyjaznych użytkownikowi.

NAP w katalogach regionalnych i na mapach. Sprawdź, czy numer telefonu i adres są aktualne wszędzie tam, gdzie firma jest wpisana — nieaktualny numer w kilku miejscach obniża zaufanie do całego sygnału lokalnego.

Analogiczny schemat wdrożenia opisaliśmy dla miejscowości regionu: Narol i Bełżec.

Najczęstsze pułapki i jak je wykryć w 5 minut

Większość spadków szybkości nie bierze się z kodu strony, tylko z jednej zmiany zrobionej „przy okazji”: nowy serwer, nowa wtyczka, nowy skrypt marketingowy. Cztery najczęstsze przypadki i sposób sprawdzenia ich w 5 minut:

• Nowy serwer bez włączonego cache. Objaw: TTFB rośnie z 200–300 ms do 1–1,5 s, a PageSpeed Insights spada o 20–30 punktów, choć w kodzie nikt nic nie zmieniał. Sprawdzenie: otwórz DevTools → Network, odśwież stronę dwa razy i zobacz nagłówki odpowiedzi. Przy LiteSpeed szukaj x-litespeed-cache: hit, przy Nginx FastCGI — x-fastcgi-cache: HIT, przy Cloudflare — cf-cache-status: HIT. Drugie odświeżenie bez HIT oznacza, że cache nie działa, nawet jeśli w panelu jest „włączony”.
• Pusta cache po deployu a brakujące nagłówki — to dwie różne rzeczy. Pierwsze żądanie po wdrożeniu zawsze da MISS, drugie powinno dać HIT. Jeśli tak jest, masz tylko brak warm-upu — wystarczy po deployu przejść kilka kluczowych adresów. Jeśli HIT nie pojawia się nigdy, sprawdź Cache-Control: no-store oraz to, czy nie cache’ujesz ruchu zalogowanych klientów (w PrestaShop cookie sesji potrafi zablokować cache dla całego koszyka).
• Dwie wtyczki robiące to samo. Moduł minifikacji + moduł lazy load + motyw, który ma własne ustawienia obrazów. Objaw: ten sam plik JS ładowany dwa razy (widać w zakładce Sources), CLS 0,2–0,3, bo jeden z lazy loaderów usuwa width i height z img.
• Piksele ładowane synchronicznie. GTM, Meta Pixel i czat wstrzyknięte w head bez async. Objaw: INP 300–500 ms, a na mobile konwersja spada o 0,5–1,5 pkt proc. Nagraj 10 s w DevTools → Performance i poszukaj długich zadań powyżej 50 ms z domen trzecich.

Progi, do których warto się odnosić, opisuje dokumentacja Core Web Vitals na web.dev. Jeśli Twoja firma konkuruje o klienta z sąsiedniego powiatu, podobny zestaw sygnałów zebraliśmy w materiale o SEO technicznym i optymalizacji szybkości w Hrubieszowie.

Co zrobić samemu, a co zlecić — widełki i SLA bez ściemy

Podział jest prosty: wszystko, co da się zrobić z panelu, robisz sam. Wszystko, co dotyka plików motywu, bazy danych i konfiguracji serwera — zleć, bo jedna literówka w .htaccess potrafi wyłączyć cały sklep na kilka godzin.

Samodzielnie w 2–3 godziny: włączenie cache strony i przeglądarki (LiteSpeed Cache, WP Rocket, wbudowany cache PrestaShop), konwersja obrazów do WebP i ich kompresja, usunięcie nieużywanych wtyczek i modułów, pozostawienie jednego lazy loadingu zamiast trzech, podpięcie CDN dla plików statycznych, wyłączenie zbędnych modułów na stronie głównej. Efekt w typowym sklepie: LCP z 4–5 s schodzi do 2–2,5 s.

Wymaga dewelopera: modyfikacja szablonu pod CLS i LCP (rezerwacja miejsca na banner, font-display: swap, priorytety ładowania), własny moduł lub wtyczka, migracja serwera wraz z przeniesieniem bazy i DNS, integracje z ERP, kurierami i systemem magazynowym, poprawki na poziomie Nginx lub Apache.

Wycena musi opierać się na liczbie godzin i zakresie, nie na cenniku z sufitu. Stawka za pracę deweloperską w regionie to dziś zwykle 120–200 zł netto za godzinę. Poniżej realne widełki z projektów.

Umowa opieki powinna zawierać cztery rzeczy: czas reakcji (4 h dla awarii sklepu w godzinach pracy, 1 dzień roboczy dla pozostałych zgłoszeń), jasny zakres dyżuru z listą prac wliczonych i płatnych osobno, raport po każdym wdrożeniu (PageSpeed przed i po, przegląd logów błędów, Core Web Vitals z raportu CrUX) oraz zapis o środowisku testowym i kopii zapasowej przed zmianami. Nie podpisuj „pakietu pozycjonowania” bez godzin i zakresu — lepiej ustalić listę zadań na kwartał. Podobne stawki i zakresy opisujemy przy okazji SEO technicznego i optymalizacji szybkości w Biłgoraju.

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

Lista kontrolna do odklikania

• Weryfikacja Search Console — Sprawdź, czy masz dostęp do tej samej wersji domeny, którą widzi Google (z www lub bez), i czy dane napływają z ostatnich 28 dni.
• Raport Strony w GSC — Przejrzyj wykluczenia: „Zeskanowane, ale obecnie niezaindeksowane” oraz „Alternatywna strona z tagiem canonical”. Szukaj tam adresów, które powinny być w indeksie.
• Core Web Vitals w GSC — Sprawdź, jaka część adresów jest w grupach „Do poprawy” i „Słabe” na mobile. Grupą decyzyjną jest mobile, nie desktop.
• Mobile Usability — Zwróć uwagę na ostrzeżenia o elementach zbyt blisko siebie — w sklepie to zwykle warianty produktu, liczba sztuk i przyciski w koszyku.
• PageSpeed Insights na mobile — Uruchom dla strony głównej, jednej kategorii i jednego produktu. Zapisz LCP, INP, CLS oraz TTFB — najlepiej z sekcji danych polowych, jeśli są dostępne.
• TTFB na zimnym cache — Zmierz czas odpowiedzi serwera dla karty produktu po wyczyszczeniu cache. Powyżej ok. 600–800 ms zaczynasz od cache i hostingu, nie od grafik.
• Pierwszy obraz bez lazy loadingu — Sprawdź w kodzie, czy obraz widoczny na starcie ma loading=eager i fetchpriority=high.
• robots.txt — Otwórz /robots.txt i upewnij się, że nie blokujesz katalogów z produktami, obrazkami ani plików potrzebnych do renderowania strony.
• Canonical na listingach — Wejdź na kategorię z filtrem i sortowaniem, sprawdź źródło strony i to, na jaki adres wskazuje canonical.
• Mapa strony XML — Sprawdź datę ostatniego odczytu w GSC i obecność najnowszych produktów. Wróć do tego punktu po każdej większej zmianie asortymentu.
• Dane strukturalne produktu — Sprawdź kartę produktu pod kątem Product, Offer, ceny, dostępności i BreadcrumbList.
• Google Business Profile — Uzupełnij dane firmy, godziny i kategorie oraz sprawdź, czy link do strony prowadzi na wersję, która szybko działa na telefonie.
• Lista 10 URL-i do naprawy — Zamknij audyt listą dziesięciu adresów uszeregowaną według ruchu i przychodu. To plan pracy na najbliższe tygodnie.
• Pomiar po wdrożeniu — Zapisz datę zmian i wróć do Search Console po 28 dniach, żeby porównać dane polowe, a nie tylko wynik z Lighthouse.

Najczęściej zadawane pytania

Źródła i materiały

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