SEO techniczne i szybkość strony — co to realnie znaczy dla firmy ze Zwierzyńca

„SEO techniczne” nie jest jedną rzeczą, którą się włącza. To cztery niezależne obszary, każdy z własnym narzędziem pomiarowym i własnym wskaźnikiem. Jeśli zawiedzie jeden, pozostałe trzy nie uratują wyniku.

Filar	Co obejmuje	Czym to zmierzysz
Indeksowalność	robots.txt, meta robots, canonical, sitemap.xml, budżet crawlowania	GSC: raport „Strony” i „Sprawdzenie adresu URL”
Struktura i linkowanie wewnętrzne	Hierarchia kategorii, menu, breadcrumbs, linki kontekstowe, głębokość kliknięć	Crawl wewnętrzny (np. Screaming Frog) + GSC
Szybkość (Core Web Vitals)	LCP, INP, CLS, TTFB, waga zasobów, cache, hosting	PageSpeed Insights, raport Core Web Vitals w GSC
Dane strukturalne	Product, Offer, BreadcrumbList, LocalBusiness	Test wyników z elementami uprzywilejowanymi

Granica jest tu ważna. Technika odpowiada za to, czy Google w ogóle zobaczy Twoją ofertę i jak szybko użytkownik ją dostanie. Nie naprawi jednak tego, że opis produktu jest skopiowany od producenta, że oferta nie różni się od konkurencji albo że nikt nie linkuje do Twojej strony. Google wprost pisze, że liczy się treść tworzona dla ludzi — SEO techniczne to warunek konieczny, ale nie wystarczający.

Punkt odniesienia, który warto mieć z tyłu głowy: w testach sklep z LCP powyżej 4 s notuje ok. 20–25% niższą konwersję niż sklep z LCP do 2,5 s. Przy 200 zamówieniach miesięcznie to 40–50 zamówień różnicy. Policz to na własnych liczbach, zamiast traktować jako straszak.

Kontekst regionalny: klient szukający noclegu, warsztatu czy wypożyczalni kajaków nie zaczyna wyszukiwania od słowa „Zwierzyńca”. Wpisuje „Roztocze”, „Zamość”, „niedaleko Zwierzyńca”. Wizytówka w Mapach Google obsługuje tylko zapytania lokalne i tylko w mapach — nie wygrasz z firmą z Zamościa, która ma szybką stronę i kilkaset zaindeksowanych podstron usługowych. Zakres takich prac opisujemy szerzej w materiale o SEO technicznym i optymalizacji szybkości w Zamościu dla firm.

Dalej znajdziesz trzy kroki: pomiar punktu startowego, progi, których nie warto przekraczać, oraz checklistę 12 punktów do przejścia samodzielnie.

Jak zmierzyć punkt startowy: narzędzia i progi, które mają znaczenie

Punkt startowy mierzysz w dwóch miejscach i oba wyniki są potrzebne.

PageSpeed Insights (PSI) w górnej części pokazuje dane polowe z CrUX — realne pomiary użytkowników Chrome z ostatnich 28 dni, liczone na 75. percentylu. To one przekładają się na ranking. Niżej PSI pokazuje wynik Lighthouse, czyli symulację w laboratorium na sztucznie spowolnionym połączeniu. Różnica 20–30 punktów między tymi dwoma wartościami to norma, nie błąd narzędzia.

Lighthouse w DevTools (F12 → zakładka Lighthouse) służy do diagnozy: wskazuje konkretny plik, który blokuje renderowanie. Nie traktuj jego wyniku jako oceny całej strony — to test jednego urządzenia w jednym momencie.

Uwaga praktyczna dla mniejszych stron: przy kilkuset wizytach miesięcznie PSI może w ogóle nie pokazać danych polowych, bo CrUX wymaga odpowiedniej liczby pomiarów. Wtedy zostają Lighthouse, TTFB z nagłówków serwera oraz raport Core Web Vitals w GSC, jeśli zbierze się próbka. Brak danych polowych nie oznacza, że nie da się mierzyć.

Mierz zawsze na mobile z throttlingiem. Desktopowe 95/100 przy mobilnym 38/100 to typowy obraz sklepu MŚP na PrestaShop z kilkunastoma wtyczkami — a Google indeksuje wersję mobilną.

Metryka	Próg (75. percentyl, mobile)	Pierwszy ruch, gdy próg jest przekroczony
LCP	≤ 2,5 s	Kompresja i format obrazów (WebP/AVIF), zdjęcie główne poza lazy loadingiem, cache i CDN
INP	≤ 200 ms	Audyt JS: slidery, czat, wtyczki, tagi analityczne; opóźnienie ładowania skryptów
CLS	≤ 0,1	Wymiary width/height dla obrazów, miejsce na banner cookies, font-display: swap
TTFB	≤ 0,8 s	Hosting, wersja PHP, OPcache, cache stron, liczba zapytań do bazy

W GSC otwórz dwa raporty: „Core Web Vitals” (ile URL-i w grupach: dobry, wymaga poprawy, słaby) oraz „Strony” (ile zaindeksowanych, ile wykluczonych i z jakiego powodu). Punkt startowy zapisz w arkuszu w kolumnach: data pomiaru, wzorzec URL-a (po 3–5 sztuk: strona główna, kategoria, karta produktu), urządzenie, LCP, INP, CLS, TTFB, liczba zaindeksowanych URL-i. Po 30 dniach powtórz pomiar o podobnej porze dnia i porównaj. Bez zapisanego punktu startowego nie udowodnisz efektu ani sobie, ani właścicielowi firmy.

Checklista audytu technicznego — 12 rzeczy do sprawdzenia jeszcze dziś

Całość zajmuje 60–90 minut i nie wymaga płatnych narzędzi. Przy każdym punkcie podaję miejsce sprawdzenia.

1. robots.txt — otwórz domena.pl/robots.txt. Szukaj wpisów „Disallow: /” oraz blokad parametrów typu „Disallow: /*?”. Disallow wstrzymuje crawlowanie, ale nie usuwa strony z indeksu — do wyrzucenia potrzebny jest noindex albo kod 410.
2. meta robots — sprawdź kod źródłowy kategorii, kart produktów i paginacji. Zostawiony po wdrożeniu noindex to najczęstsza przyczyna nagłego spadku widoczności.
3. canonical — każdy adres powinien wskazywać sam na siebie, w wersji https i z wybranym wariantem www albo bez. Canonical na inną wersję domeny rozmywa sygnały.
4. sitemap.xml — tylko adresy zwracające 200 i przeznaczone do indeksowania. Porównaj jej długość z liczbą URL-i w raporcie „Strony” w GSC.
5. Paginacja — /page/2/ nie może dziedziczyć canonicala strony bazowej kategorii ani być zablokowana w robots.txt. Zostaw ją indeksowalną i linkowaną, ale bez powielonego opisu kategorii.
6. Filtry (?orderby=, ?filter=) — każdy wariant to osobny URL. Ustaw canonical do wersji bazowej kategorii, a gdy filtrów są setki — dodaj noindex, follow.
7. Parametry UTM i sesyjne w indeksie — wklej adres z ?utm_source=... w „Sprawdzenie adresu URL”. Jeśli wróci jako zaindeksowany, popraw linki w newsletterze i kampaniach.
8. Dane strukturalne — Product, Offer, BreadcrumbList i LocalBusiness dla firmy z adresem w Zwierzyńcu. Waliduj w Teście wyników z elementami uprzywilejowanymi; listę obsługiwanych typów znajdziesz w dokumentacji Google o danych strukturalnych.
9. Łańcuchy 301 — przekierowanie A → B → C spłaszcz do A → C. Każdy przeskok to dodatkowe opóźnienie i utrata sygnału.
10. 404 po migracji — w GSC raport „Strony”, filtr „Nie znaleziono (404)”. Każdy stary adres produktu przekieruj 301 na najbliższy odpowiednik.
11. Linki wewnętrzne do przekierowań — crawl wewnętrzny pokaże, które linki w menu i treściach prowadzą do 301. Podmień je na docelowe adresy.
12. hreflang — tylko wtedy, gdy naprawdę istnieje druga wersja językowa. Najczęstszy błąd to hreflang bez drugiej wersji: nic nie daje, a zajmuje czas przy każdej zmianie szablonu.

Priorytet napraw ustal w tej kolejności: blokady indeksowania, potem szybkość, potem duplikaty i przekierowania. Ten sam schemat stosujemy w projektach dla firm z Roztocza — zobacz, jak wygląda to w praktyce przy SEO technicznym i optymalizacji szybkości w Narolu.

Najczęstsze błędy techniczne w sklepach MŚP i jak je wykryć

W polskich wdrożeniach WooCommerce i PrestaShop wracają te same cztery problemy. Każdy ma jednoznaczny objaw i narzędzie pomiaru, więc da się go potwierdzić w kilkanaście minut.

• Grafika po 1,5–3 MB. Pliki PNG/JPEG prosto z aparatu albo z panelu producenta. Konwersja do WebP lub AVIF obniża wagę o 60–80% przy jakości nieodróżnialnej na ekranie. Kategoria z 25 zdjęciami po 2 MB to 50 MB transferu przy jednym wejściu — na telefonie w zasięgu LTE kilka sekund pustego ekranu.
• Nadmiar wtyczek i modułów. WooCommerce z 20+ wtyczkami albo PrestaShop z kilkunastoma modułami bez warstwy cache to rosnące TTFB i dziesiątki dodatkowych zapytań do bazy na każde żądanie.
• Brak cache stron i OPcache. Na hostingu współdzielonym strona generuje się od zera przy każdej odsłonie. Do tego PHP 7.4, gdy dostawca udostępnia 8.2.

Jak to wykryć: uruchom waterfall w WebPageTest (serwer Frankfurt, profil 4G, trzy przebiegi), włącz slow_query_log z long_query_time = 1 i przejrzyj zapytania bez indeksów, a w PrestaShop profiluj hooki — dokumentacja deweloperska opisuje, jak śledzić czas ich wykonania. W WordPressie test w trybie bez wtyczek (Health Check & Troubleshooting) pokaże, ile kosztuje sam szablon, bez dodatków.

Pułapka: optymalizacja „na wyczucie”. Dokładanie skryptów opóźniających bez pomiaru kończy się wzrostem liczby błędów JS, a LCP stoi w miejscu. Zapisuj wynik przed i po każdej zmianie — inaczej nie wiesz, czy cokolwiek się poprawiło.

Optymalizacja szybkości po stronie serwera: hosting, PHP, baza danych

Połowa problemów z szybkością sklepu nie leży w kodzie strony, tylko w infrastrukturze. Różnica jest mierzalna: przeciążony hosting współdzielony oddaje TTFB ok. 1,2 s, a VPS z dyskiem NVMe i sensowną konfiguracją — ok. 0,3 s. Przy kilkunastu podstronach w sesji zakupowej to kilka sekund różnicy dla klienta.

• PHP 8.2 + OPcache — opcache.enable=1, opcache.memory_consumption=256, opcache.max_accelerated_files=20000.
• Cache obiektowy — Redis lub Memcached dla WooCommerce (wtyczka Redis Object Cache), w PrestaShop warstwa cache i wyłączony tryb force compile po wdrożeniu zmian.
• Baza — innodb_buffer_pool_size na poziomie 60–70% dostępnego RAM, indeksy na kolumnach używanych w filtrach i sortowaniu katalogu.
• Transport — HTTP/2 lub HTTP/3, kompresja Brotli, CDN dla plików statycznych, Cache-Control z długim max-age dla assetów z hashem w nazwie.

Kolejki i crony. Importy, synchronizacja z ERP i generowanie faktur nie mogą dziać się w żądaniu użytkownika. W WordPressie wyłącz WP-Cron i ustaw prawdziwy cron co minutę, ciężkie zadania kieruj do Action Scheduler albo kolejki Redis.

Hosting czy VPS? Decydują trzy liczby: liczba produktów, ruch dzienny i liczba integracji. Zakres i sposób wyceny takich prac dla firm w regionie opisujemy w materiale o SEO technicznym i optymalizacji szybkości w Zamościu dla firm.

Optymalizacja szybkości po stronie frontendu: obrazy, CSS, JS i fonty

Kolejność ma znaczenie. Wdrażaj od największego zysku przy najmniejszym ryzyku — inaczej spędzisz tydzień na refaktorze JS, a LCP nadal będzie na czerwono.

1. Obrazy. Konwersja do WebP/AVIF, srcset i sizes na trzy szerokości, stałe width i height w HTML. Bez wymiarów przeglądarka nie rezerwuje miejsca i CLS rośnie przy każdym doczytanym zdjęciu.
2. LCP i nagłówki cache. Obraz hero dostaje rel="preload" i fetchpriority="high", a element powyżej pierwszego ekranu — loading="eager". Lazy-loading hero to najczęstszy błąd, jaki widzę w sklepach: LCP rośnie o 1–2 s.
3. Fonty. Maksymalnie dwie rodziny, format woff2, font-display: swap. preload tylko dla kroju użytego w H1 — każdy dodatkowy plik to osobne żądanie blokujące render.
4. CSS i JS. Critical CSS pierwszego ekranu inline, reszta asynchronicznie. defer dla skryptów sklepu, async tylko dla niezależnych (analityka). Usuwanie nieużywanego kodu z szablonu i wtyczek to etap o największym ryzyku — testuj na kopii staging.

Progi, do których warto dążyć, opisują materiały o Core Web Vitals: LCP do 2,5 s, INP do 200 ms, CLS do 0,1. Dla sklepu w Narolu czy Bełżcu kolejność prac jest identyczna — różni się tylko infrastruktura, co rozpisujemy w przewodniku SEO techniczne i optymalizacja szybkości w Narolu. Mierz na telefonie w testach polowych, nie tylko w Lighthouse — laboratorium zaniża problemy z TTFB.

Lokalne SEO dla Zwierzyńca i okolic: wizytówka, treści, linkowanie wewnętrzne

Wizytówka Google to zwykle pierwszy punkt kontaktu, ale sama nie wystarczy. Ustaw jedną kategorię główną odpowiadającą głównej usłudze (nie „firma usługowa”, jeśli sprzedajesz konkret), maksymalnie 2–3 kategorie dodatkowe. Wpisz realne godziny otwarcia, także dla świąt. Dodaj 10–15 zdjęć: budynek, zespół, realizacje — i dorzucaj 2–3 nowe raz w miesiącu. Opinie zbieraj po każdym zakończonym zleceniu i odpowiadaj na wszystkie w ciągu 48 godzin.

Dane NAP (nazwa, adres, telefon) muszą być identyczne w trzech miejscach: na wizytówce, w stopce strony i w danych strukturalnych LocalBusiness. Numer zapisany raz jako „+48 84 123 45 67”, a raz jako „84 1234567” to dla Google sygnał rozbieżności — najczęstszy błąd, jaki widzimy w audytach firm z powiatu zamojskiego.

Treści lokalne pisz z realnym kontekstem. Nie „działamy w regionie”, tylko „dojazd ze Zwierzyńca do Krasnobrodu zajmuje ok. 20 minut, realizacje prowadzimy w promieniu 40 km: Zwierzyniec, Szczebrzeszyn, Zamość, Krasnobród, Józefów”. Opisz konkretną realizację — co, gdzie, ile trwało, jaki był problem. Bez upychania fraz; zasady pisania pod odbiorcę, a nie pod wyszukiwarkę, opisuje dokumentacja Google o tworzeniu treści dla ludzi.

Pułapka numer jeden: ten sam tekst wklejony na strony dla Zamościa, Hrubieszowa, Narola i Zwierzyńca z podmienioną nazwą miejscowości. Każda z tych stron musi mieć unikalny przykład realizacji, unikalne zdjęcia, inny tytuł i opis meta. Inaczej konkurujesz sam ze sobą i żadna wersja nie rankuje.

Linkowanie wewnętrzne spina całość: z tej strony prowadź do materiału SEO techniczne i optymalizacja szybkości w Zamościu dla firm oraz do omówienia ceny i zakresu prac. Obie strony pogłębiają temat i przejmują ruch, który inaczej wracałby do Google.

Pomiar lokalny: w GSC filtruj zapytania zawierające „zwierzyniec”, „roztocze”, „krasnobród”. W panelu wizytówki śledź wyświetlenia, kliknięcia w trasę dojazdu i połączenia telefoniczne. Te trzy liczby porównuj co miesiąc — to najprostszy dowód, że praca nad widocznością lokalną działa.

Ile to kosztuje, jak wygląda wdrożenie i jak mierzyć efekty

Widełki wynikają z liczby godzin, nie z „pakietów”. Audyt techniczny to 8–16 godzin: crawl do 500 adresów, analiza raportu indeksowania, logi serwera, pomiar Core Web Vitals w PageSpeed Insights i CrUX. Optymalizacja szybkości to 20–60 godzin — sklep na PrestaShop z 300 produktami zamyka się bliżej 20, katalog z 10 000 SKU i filtrami warstwowymi bliżej 60. Opieka miesięczna ustalana w SLA, typowo 4–10 godzin. Stawkę godzinową mnożysz przez zakres — i tak dostajesz orientacyjny koszt.

Etapy są zawsze te same. (1) Audyt i pomiar startowy: zapisz LCP, INP, CLS oraz liczbę zaindeksowanych URL-i, bo bez punktu wyjścia nie udowodnisz efektu po 30 dniach. (2) Lista priorytetów z szacunkiem godzin dla każdej pozycji i kolejnością wdrożenia. (3) Wdrożenie partiami — np. tydzień 1–2 obrazy w WebP/AVIF, cache, CDN; tydzień 3–4 krytyczny CSS, odchudzenie JS, limity PHP-FPM. (4) Ponowny pomiar po 2–4 tygodniach.

KPI do raportowania: LCP/INP/CLS z 75. percentyla, liczba zaindeksowanych URL-i, kliknięcia i pozycje na frazy lokalne oraz udział ruchu z mobile. Progi i definicje metryk znajdziesz w dokumentacji web.dev o Core Web Vitals.

Kiedy opłaca się własny moduł zamiast płatnej wtyczki? Próg jest prosty: gdy roczna subskrypcja przewyższa koszt dedykowanego rozwiązania, a wtyczka i tak nie pokrywa procesu (nietypowa logika dostaw, filtry, integracja z ERP). Wtedy moduł pisany pod PrestaShop zwraca się w 12–18 miesięcy. Punkt wyjścia do wyceny: dokumentacja deweloperska PrestaShop.

Realistyczne oczekiwania: poprawa Core Web Vitals widoczna w GSC po 2–4 tygodniach (dane CrUX liczone są z 28 dni), ruchy pozycji na frazy lokalne po 1–3 miesiącach. Jeśli ktoś obiecuje skok na pierwszą pozycję w tydzień, sprzedaje coś innego niż SEO techniczne. Porównanie zakresów i stawek dla sąsiednich rynków znajdziesz w materiale o SEO technicznym i optymalizacji szybkości w Hrubieszowie.

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

Lista kontrolna do odklikania

• robots.txt — Sprawdź, czy nie blokuje plików CSS/JS i całych katalogów produktowych. Weryfikacja: „Sprawdzenie adresu URL” w Google Search Console — czy testowy URL nie jest zablokowany.
• Meta robots — Przejrzyj szablony i ustawienia sklepu: kluczowe kategorie i karty produktów nie mogą mieć noindex. Weryfikacja w GSC dla 5 najważniejszych adresów.
• Canonical — Każda podstrona powinna wskazywać samą siebie, bez sprzeczności z sitemap.xml. Sprawdzasz to przy okazji audytu duplikatów, najlepiej raz na kwartał.
• sitemap.xml — Powinna zawierać wyłącznie adresy zwracające 200, bez przekierowań i bez noindex. Zweryfikuj w GSC raportem „Mapy witryn”.
• Dane strukturalne — Product, Offer, BreadcrumbList, LocalBusiness — walidacja w teście wyników z elementami uprzywilejowanymi. Sprawdzaj po każdej zmianie szablonu produktu.
• LCP, INP, CLS na 75. percentylu — Progi: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Dane polowe z CrUX w PageSpeed Insights — to najważniejszy pomiar, bo pochodzi od realnych użytkowników.
• TTFB — Cel: ≤ 0,8 s. Mierz na mobile z throttlingiem; wysoki TTFB oznacza problem serwera, cache lub bazy, a nie samych obrazków.
• Pomiar mobilny z throttlingiem — Desktopowe 95/100 przy mobilnym 38/100 to typowy obraz sklepu MŚP. Jeśli różnica przekracza 30–40 punktów, problemem są zasoby blokujące renderowanie, nie sam hosting.
• GSC — raport Core Web Vitals — Sprawdź liczbę adresów w grupach „dobra” i „do poprawy”. Trend miesięczny mówi więcej niż pojedynczy pomiar.
• GSC — raport „Strony” — Porównaj liczbę zaindeksowanych i wykluczonych URL-i. Nagły wzrost wykluczeń najczęściej oznacza problem z canonical, noindex lub błędem serwera.
• Przekierowania i 404 — Wykrywasz crawlerm po każdej migracji i zmianie struktury kategorii; sprawdzasz łańcuchy 301, pętle i stare adresy bez odpowiednika.
• Parametry w indeksie — Sprawdź, czy w wynikach nie siedzą adresy z ?orderby=, ?filter=, UTM i parametrami sesyjnymi. Kontrola raz na kwartał albo po każdej kampanii.
• Zapis wyniku startowego — Data, urządzenie, lista 10–20 reprezentatywnych URL-i i wartości LCP/INP/CLS/TTFB. Bez tego nie porównasz efektu po 30 dniach.

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