Czym naprawdę jest SEO techniczne i optymalizacja szybkości

SEO techniczne to zestaw prac, które odblokowują stronę dla Google — a nie pisanie tekstów. Zakres sprowadza się do trzech filarów i każdy da się zmierzyć:

• Indeksacja — czy Google widzi treść. W Search Console raport „Raporty stron” pokazuje, ile adresów jest zaindeksowanych, a ile odrzuconych i dlaczego (noindex, kanoniczny, 404, przekierowanie).
• Wydajność — czy serwer i strona odpowiadają szybko. Tu wchodzi TTFB serwera, Core Web Vitals, kompresja, cache i liczba zapytań do bazy.
• Struktura — czy linkowanie i dane są zrozumiałe. Hierarchia kategorii, linki wewnętrzne, dane strukturalne produktu i okruszków.

Różnica względem SEO contentowego jest prosta: techniczne usuwa blokady, content i linki zdobywają pozycje. Możesz mieć najlepszy tekst w branży, ale jeśli URL ma noindex albo canonical wskazuje na inny adres, nie wejdzie do wyników.

Priorytety zależą od modelu biznesowego. Sklep ze Szczecina sprzedający do całej Polski pracuje na 3 000–20 000 URL-i (produkty, kategorie, filtry fasetowe), więc walczy o budżet indeksowania i szybkość na telefonie — tam jest zwykle 70–80% ruchu. Firma usługowa działająca lokalnie ma 10–30 podstron: dla niej liczą się profil w Google, spójny NAP, dane LocalBusiness i czas ładowania strony kontaktowej, a nie crawl budget.

Szybkość przekłada się na pieniądze. Badanie Google/SOASTA z 2017 r. na 900 tys. stron mobilnych pokazało, że 53% użytkowników porzuca stronę ładującą się dłużej niż 3 s, a wydłużenie z 1 s do 3 s zwiększa prawdopodobieństwo odrzucenia o 32%. W sklepie dodatkowa sekunda to utrata części koszyka. Pełny zakres prac opisujemy w SEO techniczne, a wdrożenie krok po kroku w sklepie — w przewodniku SEO techniczne i optymalizacja szybkości sklepu — przewodnik.

Core Web Vitals 2025: progi, które trzeba znać

Progi są trzy i dotyczą 75. percentyla realnych wizyt, nie średniej. To ważne: średnia ukrywa problem, gdy połowa użytkowników ma 1 s, a połowa 8 s.

Metryka	Dobry wynik	Próg „słabo”	Co mierzy	Typowa przyczyna w sklepie
LCP	≤ 2,5 s	> 4,0 s	Czas do wyrenderowania największego elementu widoku	Nieskompresowany obraz hero, brak cache, wolny TTFB
INP	≤ 200 ms	> 500 ms	Opóźnienie reakcji na kliknięcie lub dotknięcie	Ciężki JavaScript, dziesiątki wtyczek, długie zadania w tle
CLS	≤ 0,1	> 0,25	Przesunięcia układu w trakcie ładowania	Obrazy i bannery bez zarezerwowanego miejsca, podmiana fontu, pasek cookie

Teraz najczęstsza pomyłka. Lighthouse i PageSpeed Insights w sekcji z wynikiem wydajności to dane laboratoryjne — symulacja na jednym, sztucznie zwolnionym urządzeniu. Pomiar jest powtarzalny, ale nie mówi nic o Twoich klientach. Dane polowe pochodzą z raportu Chrome UX Report i są liczone z 28 dni rzeczywistych wizyt w Chrome. Dlatego wynik 95 w Lighthouse nie da wyższych pozycji, jeśli 30% użytkowników na telefonie ma LCP 5 s — Google patrzy na dane polowe, nie na pojedynczy test. Definicje i progi znajdziesz w dokumentacji web.dev — Core Web Vitals.

Dane polowe sprawdzisz w trzech krokach, bez instalowania czegokolwiek:

1. Search Console → sekcja „Doświadczenie” → raport „Podstawowe wskaźniki internetowe”.
2. Przełącz na „Telefon” i sprawdź grupy URL oznaczone „Wymaga poprawy” lub „Słabe”. Kliknij grupę i otwórz listę przykładowych adresów.
3. Popatrz, po czym Google pogrupowało adresy — jeśli w jednej grupie są tylko URL-e produktów, problem siedzi w szablonie produktu, a nie w całym serwisie.

Gdy zobaczysz „Za mało danych”, strona ma zbyt mały ruch, żeby Chrome UX Report pokazał cokolwiek sensownego. Wtedy mierz samodzielnie albo pracuj na danych z serwera.

Audyt techniczny w 2 godziny — kolejność, która się opłaca

Kolejność jest nienegocjowalna: indeksacja → wydajność → struktura. Optymalizowanie szybkości strony, której Google nie indeksuje, to strata czasu — przyspieszasz adres, który nigdy nie pojawi się w wynikach.

Etap	Czas	Narzędzie	Co sprawdzasz
1. Indeksacja	0–40 min	Search Console → Raporty stron	Liczba zaindeksowanych vs przesłanych URL-i, powody „Nieindeksowania”, adresy z parametrami
2. Crawl i logi	40–60 min	Screaming Frog (darmowy do 500 URL-i), logi serwera	Błędy 4xx/5xx, przekierowania, głębokość kliknięć, jak często Googlebot wchodzi na filtry
3. Wydajność	60–100 min	PageSpeed Insights, raport Core Web Vitals	LCP, INP, CLS w danych polowych, TTFB serwera
4. Struktura	100–120 min	Test wyników z danymi strukturalnymi, ręczny przegląd	Hierarchia kategorii, linkowanie wewnętrzne, dane Product i BreadcrumbList

Najwięcej pieniędzy leży w pierwszym punkcie. W raporcie „Raporty stron” sprawdź sekcję „Zaindeksowane, mimo że nie zostały przesłane”. Jeśli siedzą tam tysiące adresów z ?filter, ?orderby, ?sort, ?page albo strony koszyka i wyszukiwarki wewnętrznej, Googlebot marnuje budżet indeksowania na adresy bez wartości. Naprawa jest tania: Disallow na parametry w robots.txt, noindex na wynikach wyszukiwarki wewnętrznej, kanoniczne na wariantach sortowania. W PrestaShop pilnujesz tego w konfiguracji adresów URL i w module do nawigacji fasetowej; w WooCommerce wyłączasz indeksowanie tagów, archiwów autora, dat i /?s= w ustawieniach SEO.

Skala zmienia priorytety. Przy 50 produktach: uporządkuj sitemapę, kanoniczne i szybkość szablonu produktu oraz kategorii — nie buduj zaawansowanej logiki faset, ryzyko większe niż zysk. Przy 5 000 produktów: podziel sitemapę (limit 50 000 URL-i), ustal paginację, kontroluj filtry, dodaj CDN i cache obiektowy. Jak to wygląda przy mniejszym, lokalnym katalogu, opisaliśmy w materiale o SEO technicznym i optymalizacji szybkości w Hrubieszowie. Po dwóch godzinach powinieneś mieć listę 10–15 zadań z kolejnością i szacunkiem czasu — nie 200 punktów, których nikt nie wdroży.

Najczęstsze przyczyny wolnego sklepu na PrestaShop i WooCommerce

Zanim zapłacisz za optymalizację, sprawdź pięć rzeczy. To przyczyny, które w sklepach na PrestaShop i WooCommerce powtarzają się najczęściej.

• Obrazy w PNG/JPEG bez WebP/AVIF i bez wersji responsywnych. Wejdź w DevTools → Network → filtr Img → posortuj po kolumnie Size. Jeśli kafelek produktu o wymiarach 300 × 300 px ciągnie plik JPG o wadze 450 kB, szablon nie generuje miniatur pod ekran. Sprawdź w źródle strony, czy występują atrybuty srcset i sizes. W PrestaShop odpowiada za to konfiguracja miniatur i formatów obrazów — punkt wyjścia znajdziesz w dokumentacji dla deweloperów PrestaShop. Konwersja do WebP przy zachowaniu oryginału to zwykle 40–70% mniej kilobajtów.
• Za dużo modułów i wtyczek ładujących skrypty globalnie. Moduł podpięty do hooka displayHeader w PrestaShop wypuszcza CSS i JS na każdej podstronie, także tam, gdzie nie jest używany. W Chrome użyj Coverage (Ctrl+Shift+P → Show Coverage): przy 25–30 wtyczkach łatwo zobaczyć 1,5 MB JavaScriptu, z którego 60–70% nie wykonuje się na stronie produktu.
• Skrypty zewnętrzne: piksele, czaty, rekomendacje, mapy. Każda zewnętrzna domena to dodatkowe DNS, TLS i oczekiwanie na odpowiedź. Typowo 200–600 ms na jedno wdrożenie, a bywa ich pięć. W PageSpeed Insights zobaczysz je w sekcji dotyczącej kodu firm trzecich.
• Brak cache serwerowego i obiektowego. Lista 40 produktów bez cache potrafi wygenerować 40+ zapytań do bazy (klasyczny N+1). W WooCommerce sprawdzisz to przez Query Monitor, w PrestaShop przez tryb debugowania profilu.
• Hosting współdzielony jako twardy sufit. Objaw: TTFB skacze z 200 ms do 1500 ms w godzinach szczytu, w logach widać limit procesów. Wtedy kod daje 10–20%, a zmiana środowiska 60–80%.

Serwer i infrastruktura: gdzie tracisz najwięcej

LCP liczy się od pierwszego bajtu. Jeśli TTFB wynosi 800 ms, to nawet perfekcyjnie zoptymalizowany front da LCP w okolicach 2,8–3,2 s — poniżej 2,5 s praktycznie nie zejdziesz. Dlatego TTFB traktuj jako parametr wejściowy, nie jako ciekawostkę. Cel: poniżej 500 ms dobrze, poniżej 800 ms akceptowalnie.

Jak zmierzyć TTFB osobnym narzędziem. W DevTools → Network kliknij request HTML i wejdź w Timing → Waiting for server response. To ta sama wartość, którą pokaże WebPageTest w waterfall jako pierwszy zielony słupek. Uwaga na lokalizację testu: mierzenie z USA serwera postawionego we Frankfurcie doda 100–150 ms samego opóźnienia sieci, którego nie naprawisz kodem.

Serwer czy baza? Jeśli wysokie jest Waiting for server response, a niskie Content Download — problem jest po stronie PHP lub MySQL. Prosty test rozstrzygający: wystaw plik phpinfo() i zmierz jego TTFB. Gdy prosta strona PHP odpowiada w 400 ms, winien jest hosting, nie sklep. Gdy prosta strona jest szybka, a kategoria wolna — to baza. Wtedy włącz slow query log (long_query_time=1) i sprawdź SHOW PROCESSLIST w trakcie skoku ruchu. Jeśli TTFB rośnie liniowo z liczbą produktów na stronie, masz zapytania w pętli.

Co ma być ustawione:

• PHP 8.1 lub nowsze z OPcache (opcache.enable=1, 128–256 MB pamięci),
• PHP-FPM z pulą dopasowaną do RAM (np. pm.max_children=12 przy 8–16 MB na proces, przy 2 GB RAM nie ustawiaj 50),
• MySQL/MariaDB z innodb_buffer_pool_size na poziomie 60–70% RAMu dedykowanego bazie,
• HTTP/2 lub HTTP/3, kompresja Brotli (na tekście daje kilka procent mniej niż gzip),
• CDN dla statyków i plików graficznych.

Zakres prac diagnostycznych opisujemy szerzej w naszym SEO technicznym.

Indeksacja, canonical i struktura — błędy, które kosztują ruch

Duplikaty z filtrów fasetowych i sortowania. Jeden katalog z pięcioma filtrami i trzema opcjami sortowania generuje setki adresów z tym samym zestawem produktów. Najpierw decyzja: czy filtr ma wartość dla użytkownika? Jeśli tak (np. konkretny typ produktu w wąskiej kategorii), zostaw stronę indeksowalną z własnym opisem i canonical wskazującym na siebie. Jeśli nie — ustaw noindex, follow i canonical na kategorię bazową, a w robots.txt zablokuj parametry sortowania typu ?sort= i ?p=. Pamiętaj, że canonical i noindex to wskazówki, nie rozkazy — sam canonical bez uporządkowania linków wewnętrznych nie rozwiąże problemu.

Noindex na koszyku, zamówieniu i wyszukiwaniu wewnętrznym. Adresy typu /koszyk, /zamowienie, /szukaj?q= nie powinny trafiać do indeksu — to typowe strony wyników wewnętrznych bez wartości dla wyszukiwarki. Najczęstszy błąd jest odwrotny: reguła noindex wrzucona globalnie w szablon albo w nagłówku obejmującym cały sklep. Efekt: znikają kategorie, które generowały sprzedaż. Sprawdź to w GSC przez Inspekcję adresu URL na 5–10 reprezentatywnych stronach i porównaj pole „Indeksowanie” z faktycznym znacznikiem w kodzie.

Sitemap XML. Ma być generowana dynamicznie z bazy, z podziałem na plik produktów i plik kategorii (przy dużych sklepach dzielona na partie po 50 tys. adresów), zgłoszona w GSC i podlinkowana w robots.txt linią Sitemap:. Warunek: w sitemapie nie może być adresów z noindex ani przekierowań.

Paginacja i migracje. Linki numerowane muszą być zwykłymi <a href>, a nie zdarzeniami JavaScript. Przy zmianie platformy mapujesz stary adres na nowy jeden do jednego i wstawiasz jedno 301. Łańcuch 302 → 301 → 301 to najczęstszy błąd migracji: każdy przeskok opóźnia odpowiedź i rozmywa sygnał. Wykryjesz go w Screaming Frog (raport łańcuchów przekierowań) albo jednym poleceniem curl -I -L. Zasady budowania treści, które chce indeksować Google, opisuje dokumentacja Google o treściach tworzonych dla ludzi.

Dane strukturalne, które realnie dają widoczność

Dane strukturalne to nie ozdoba strony. W sklepie liczą się dwa typy: Product z Offer oraz BreadcrumbList. Reszta to uzupełnienie, które pomaga, ale nie sprzedaje.

Product + Offer to warunek wejścia do bezpłatnych listingów produktowych. W JSON-LD musisz podać price i priceCurrency, availability (InStock, OutOfStock, PreOrder — zgodne ze stanem magazynowym), sku/gtin/mpn, shippingDetails z kosztem i czasem dostawy oraz hasMerchantReturnPolicy. Bez tego Google nie pokaże Twojej oferty z ceną i kosztem wysyłki w wynikach, a karta produktu w Merchant Center zostanie odrzucona.

AggregateRating dodawaj wyłącznie wtedy, gdy naprawdę zbierasz opinie i są widoczne na stronie. Wpisane na sztywno oceny to najkrótsza droga do ręcznej kary, a nie do gwiazdek w wynikach.

Organization lub LocalBusiness (name, address, telephone, url, logo, sameAs) to uzupełnienie tożsamości marki. Nie zastąpi przemyślanej struktury linków — jeśli kategorie masz posklejane na dziesięciu poziomach, schema tego nie naprawi. Kolejność prac opisujemy w sekcji SEO techniczne.

Walidacja jest dwustopniowa: najpierw test wyników z elementami rozszerzonymi, potem raport danych strukturalnych w Search Console. Ten drugi pokazuje błędy dopiero po ponownym zindeksowaniu — licz na 1–3 dni opóźnienia.

FAQ: od 2023 roku Google pokazuje wyniki rozszerzone FAQ praktycznie tylko dla stron rządowych i medycznych. W sklepie z narzędziami schema FAQ nic nie da. Lepiej wstawić zwykły <h2> z konkretną odpowiedzią na pytanie — użytkownik przeczyta, robot zrozumie.

Pełna lista typów obsługiwanych przez Google: dane strukturalne w dokumentacji Google Search Central.

Ile to kosztuje i od czego zależy cena

Nie ma jednej ceny za SEO techniczne. Jest model godzinowy i widelki, które w Polsce oscylują między 120 a 250 zł netto za godzinę pracy specjalisty. Powyżej tego progu zwykle siedzi agencja z warstwą pośredników, poniżej — freelancer bez dostępu do zaplecza serwerowego.

Typowe zakresy: audyt techniczny to 8–16 godzin (960–4 000 zł netto), pakiet optymalizacji 20–60 godzin (2 400–15 000 zł netto), utrzymanie techniczne to abonament, najczęściej 5–15 godzin miesięcznie.

Co realnie podnosi koszt:

• Liczba szablonów. Sklep na PrestaShop z trzema motywami i osobną wersją mobilną to trzykrotnie więcej pracy przy LCP i CLS niż jeden spójny szablon.
• Integracje z ERP (Subiekt, Comarch, BaseLinker). Część objawów wolnego sklepu siedzi w synchronizacji stanów magazynowych, a nie w kodzie strony — diagnoza zajmuje godziny.
• Moduły niestandardowe. Jeśli trzeba wejść w kod, godziny rosną szybciej niż przy standardowych wtyczkach.
• Migracja platformy, np. z PrestaShop 1.7 na 8.x. To osobny projekt, nie element optymalizacji.
• Brak dostępu do serwera. Każde pytanie przekierowane do hostingu to Twoje 30–60 minut na wymianę maili przy każdym pomiarze.

Praca bezpośrednio z deweloperem, bez pośrednika, skraca projekt o tygodnie. Każdy dodatkowy szczebel to 20–40% budżetu i 3–5 dni przy każdej iteracji pytań. Zanim podpiszesz umowę, poproś o rozbicie wyceny na godziny i zakres — punkt odniesienia do rozmów znajdziesz w zestawieniu stawek za SEO techniczne i optymalizację szybkości.

Plan wdrożenia 30/60/90 dni i KPI, których nie da się oszukać

Harmonogram 30/60/90 dni działa, bo wymusza priorytety i daje punkt kontrolny przy każdej fakturze. Kontekst całego procesu opisujemy w przewodniku SEO techniczne i optymalizacja szybkości sklepu, a poniżej wersja do wdrożenia.

Dni 1–30: indeksacja i najprostsze zwycięstwa na LCP. Audyt w Search Console (raporty Strony i Indeksowanie), przegląd logów serwera, weryfikacja robots.txt i sitemap.xml. Usuń blokady, wygeneruj nową sitemapę, sprawdź, czy filtry w kategoriach nie tworzą tysięcy duplikatów — PrestaShop domyślnie potrafi. Potem obrazy: konwersja do WebP, poprawne wymiary w HTML, kompresja zdjęcia produktowego do 100–150 KB. Cache: pełny cache stron w PrestaShop (CCC plus moduł cache) albo WP Rocket lub LiteSpeed Cache w WooCommerce. Na koniec LCP: preload obrazu z pierwszego ekranu, fetchpriority="high", zdjęcie lazy load z hero usunięte, preconnect do domeny fontów.

Dni 31–60: serwer, baza, skrypty zewnętrzne, dane strukturalne. PHP 8.2 lub 8.3, OPcache włączony, Redis jako cache obiektowy, tuning MySQL/MariaDB pod zapytania katalogu. Skrypty GTM, piksel Meta i czat ładowane z defer albo przez proxy. Schema Product/Offer wdrażasz dopiero, gdy szablony produktów są stabilne.

Dni 61–90: migracje, moduły niestandardowe, utrwalenie. Migracja wersji, przepisanie modułów, miesięczny przegląd CWV wpisany w proces utrzymania. Bez tego punkty wrócą po dwóch aktualizacjach wtyczek.

Progi CWV i sposób ich interpretacji: Web Vitals na web.dev.

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

Lista kontrolna do odklikania

• Indeksacja kluczowych URL-i — Search Console → Raporty stron. Sprawdź, czy strona główna, kategorie i najlepiej sprzedające się produkty mają status „Zaindeksowana”. To zawsze krok pierwszy.
• Marnowanie budżetu indeksowania — Raport „Zaindeksowane, mimo że nie zostały przesłane”. Tysiące URL-i z parametrami filtrów lub sortowania to sygnał do noindex i poprawy linkowania.
• Dane polowe Core Web Vitals — Search Console → Core Web Vitals, dane z 28 dni. Sprawdzaj przed pracami i ponownie po 28 dniach od wdrożenia zmian.
• LCP, INP i CLS na czterech szablonach — Osobno strona główna, kategoria, produkt oraz koszyk lub formularz kontaktowy. Progi: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 dla 75. percentyla.
• TTFB na czystym żądaniu — Pomiar w DevTools → Timing lub przez curl. Wynik powyżej 600–800 ms oznacza problem infrastruktury, którego nie naprawisz zmianą obrazków.
• Format i rozmiar obrazów — DevTools → Network → Img. Sprawdź, czy pliki są w WebP lub AVIF i czy mają warianty responsywne dla mniejszych ekranów.
• Skrypty stron trzecich — Network z filtrem domen zewnętrznych: piksele, czaty, mapy, rekomendacje. Każdy blokujący skrypt dolicz orientacyjnie 200–600 ms.
• Waga i liczba żądań — Typowa podstrona sklepu powinna mieścić się w okolicach 100 żądań i 1,5–2 MB. Wszystko powyżej wymaga uzasadnienia biznesowego.
• Cache serwerowy i obiektowy — Sprawdź nagłówki odpowiedzi (np. X-Cache, cf-cache-status) oraz czy PHP korzysta z OPcache, a aplikacja z Redis lub Memcached.
• Zapytania do bazy na listach — Slow query log lub profiler przy odświeżeniu kategorii. Powtarzalne zapytania w pętli dla każdego produktu to typowy N+1.
• Dane strukturalne — Walidator Google na produkcie, kategorii, artykule i danych firmy. Błędy krytyczne blokują rozszerzone wyniki w wyszukiwaniu.
• Canonical i duplikaty — Sprawdź wersje z parametrami, paginację oraz adresy http/https i z www lub bez. Jeden adres, jedna wersja kanoniczna.
• Wersje PHP i protokołu — PHP 8.1 minimum, HTTP/2 lub HTTP/3, kompresja Brotli. Brak tych elementów to często darmowy zysk, który został na stole.
• Widok mobilny na realnym telefonie — Sprawdź banner cookie, czat i slider na prawdziwym urządzeniu — to najczęstsze źródła wysokiego CLS i opóźnionego INP.

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