Co dokładnie oznacza SEO techniczne i optymalizacja szybkości w sklepie?

SEO techniczne to zestaw decyzji, które przesądzają, czy Google w ogóle zobaczy Twoje produkty. W praktyce pięć elementów: crawl – czy bot wchodzi na stronę i czy nie blokuje go robots.txt lub reguła w .htaccess; indeksacja – czy adres trafia do indeksu; renderowanie – czy Google widzi treść doklejaną przez JavaScript; kanibalizacja – czy dwie podstrony nie walczą o tę samą frazę; oraz canonical i sitemap – czy wskazujesz wersję kanoniczną i czy sitemap.xml jest aktualna. Szybkość to osobny obszar, choć częściowo na te elementy wpływa.

Core Web Vitals to trzy metryki liczone z realnych danych użytkowników, nie z jednego testu: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Google ocenia je w 75. percentylu – trzy czwarte wizyt musi mieścić się w progu. Metodykę opisuje dokumentacja Web Vitals na web.dev.

Rozdziel dwie szybkości, bo mieszanie ich kończy się przepalonym budżetem. TTFB to czas, po jakim serwer zwraca pierwszy bajt HTML – zależy od hostingu, PHP, cache i bazy. Renderowanie to czas, po którym przeglądarka zbuduje DOM i pobierze CSS, JavaScript oraz obrazy. Sklep może mieć TTFB 180 ms i LCP 4,6 s, jeśli zdjęcie hero waży 900 kB i nie ma podanych wymiarów. Optymalizacja serwera nic wtedy nie da.

Sklep z Krasnobrodu na frazę „buty trekkingowe męskie” stoi w wynikach obok sklepów z Lublina, Zamościa i Warszawy. Lokalność działa głównie w Mapach Google i zapytaniach typu „sklep w Krasnobrodzie”. Reszta to zwykła rywalizacja o wydajność i czysty indeks. Kolejność działań dla mniejszych miejscowości opisaliśmy przy okazji audytu dla SEO technicznego i optymalizacji szybkości w Zwierzyńcu.

Kolejność ma znaczenie. Jeśli 30% kart produktów nie jest zaindeksowanych, podniesienie LCP z 3,0 do 2,4 s zmieni niewiele – klient nie wejdzie na stronę, której nie ma w wynikach. Najpierw indeksacja, potem szybkość. Wyjątek stanowią kampanie płatne: tam tempo ładowania wpływa na koszt kliknięcia od pierwszego dnia, niezależnie od stanu indeksu.

Od czego zacząć w Krasnobrodzie: 7-punktowy audyt przed wdrożeniem

Audyt robisz przed wdrożeniem, nie po. Poniższą listę przechodzi się w 2–3 dni i nie wymaga zmian w kodzie.

1. Google Search Console. Raport „Szybkość” (Core Web Vitals dla mobile i desktop) oraz sekcja „Indeksowanie stron”: błędy 404, statusy „Wykryta, obecnie nieindeksowana” i „Zaindeksowana, mimo że nie wybrano kanonicznej”. Sprawdź sitemap.xml – 12 000 adresów przy sklepie z 800 produktami oznacza duplikaty z filtrów.
2. PageSpeed Insights i Lighthouse. PSI uruchom osobno dla mobile i desktop na trzech typach adresów: strona główna, kategoria, karta produktu. Lighthouse odpal lokalnie w Chrome bez rozszerzeń i w trybie incognito – traktuj jako uzupełnienie danych polowych.
3. WebPageTest i GTmetrix. Wodospad ładowania, TTFB, kolejność requestów. Ustaw lokalizację Frankfurt, profil 4G, trzy przebiegi. Porównaj „First View” z „Repeat View” – drugi pokazuje, ile realnie daje cache przeglądarki.
4. Logi serwera i zużycie CPU/RAM. To źródło prawdy. access log z $request_time pokaże czas generowania PHP, a nie tylko odczucie z przeglądarki. Szukaj odpowiedzi 5xx, kodów 499 i requestów powyżej 3 s. W panelu hostingu zobacz wykres CPU w godzinach szczytu.
5. Hosting. Shared, VPS czy serwer dedykowany? Sprawdź limity PHP, MySQL i liczbę równoczesnych procesów. Plan shared z limitem 20 procesów PHP padnie, gdy 40 osób trzyma coś w koszyku.
6. Pomiar przed zmianami. Zapisz baseline: LCP, INP, CLS, TTFB i czas pełnego załadowania – z datą, godziną, wersją szablonu i listą wtyczek. Bez tego nie udowodnisz efektu.
7. Priorytetyzacja. Najpierw to, co blokuje indeksację i kampanie płatne: 404 w kategoriach, canonical, wydajność stron kierujących z Google Ads. Dopiero potem drobne optymalizacje, jak kompresja zdjęć na blogu.

Jeśli nie chcesz przechodzić tego samodzielnie, stały zakres czynności zebraliśmy w opisie utrzymania i opieki technicznej sklepów w Krasnobrodzie. Progi przydatne przy punkcie piątym są w tabeli obok, a interpretację pomiarów opisuje dokumentacja Core Web Vitals w Google Search Central.

Core Web Vitals w PrestaShop i WooCommerce – co realnie poprawia LCP, INP i CLS

Każda z trzech metryk poprawia się na innej warstwie, dlatego wrzucanie ich do jednego worka „przyspieszymy stronę” kończy się pracą bez efektu.

LCP. Kompresja do WebP lub AVIF – przy zdjęciach produktowych 1200 px szerokości i 100–150 kB to zdrowy cel. Konwersja istniejącej biblioteki to osobny krok, sam plugin nie odchudzi starych plików. Lazy loading dodawaj tylko poza pierwszym ekranem (loading="lazy"), nigdy na obraz hero. Dla hero ustaw fetchpriority="high" i preload. W PrestaShop slidery potrafią ładować pięć zdjęć hero naraz – zostaw jedno.

INP. Ogranicz JavaScript firm trzecich: każdy czat, heatmapa i pixel to zwykle 100–300 kB i zadania na głównym wątku. Rozbij długie zadania (setTimeout, requestIdleCallback), a niekrytyczne skrypty ładuj z defer lub po zdarzeniu load. W DevTools → Performance sprawdź listę „Long tasks”, w Lighthouse raport „Reduce JavaScript execution time”.

CLS. Zarezerwuj miejsce na obrazy (width/height lub aspect-ratio), banery i pasek cookie. Font: font-display: swap plus preload plików użytych w nagłówku. Reklam i bannerów nie wstawiaj nad treścią bez zdefiniowanej wysokości kontenera.

PrestaShop. Ciężkie moduły zostawiające hooki na każdej podstronie, szablony z czasów 1.6/1.7, brak OPcache (opcache.enable=1, opcache.memory_consumption=128–256 MB) i brak Redis dla cache. Filtry i paginacja generują tysiące adresów z parametrami – dla kombinacji filtrów ustaw canonical na kategorię bazową i noindex. Punkt odniesienia dla zmian w kodzie znajdziesz w dokumentacji PrestaShop dla deweloperów.

WooCommerce. Bloat wtyczek, zapytania meta_query po wp_postmeta bez indeksów, żądanie wc-ajax=get_refreshed_fragments odpalane na każdej stronie oraz niepotrzebne jQuery na podstronach poza sklepem. Typowe problemy i kolejność wdrożenia opisujemy w materiale o wdrożeniach i optymalizacji WooCommerce w Krasnobrodzie. Efekt mierz przed i po w PageSpeed Insights, Lighthouse i WebPageTest – trzy przebiegi, ta sama lokalizacja i profil, do porównania bierz medianę.

Najczęstsze pułapki szybkościowe w małych sklepach (i jak je wykryć)

Najczęstszy powód wolnego TTFB w małych sklepach to shared hosting bez OPcache i bez Redis. PHP parsuje ten sam kod od zera przy każdym żądaniu, a sesje i cache obiektowy trafiają na dysk. Efekt: TTFB 800–2500 ms, gdy w sklepie jest jednocześnie kilka osób. Zanim ktokolwiek dotknie szablonu, wejdź w phpinfo() i sprawdź dwie sekcje: OPcache (czy włączony, czy memory_consumption ma co najmniej 128 MB, czy opcache.validate_timestamps nie wymusza sprawdzania plików przy każdym żądaniu) oraz obecność rozszerzenia redis.

Druga pułapka to wtyczki i moduły robiące to samo. W WooCommerce typowy zestaw to trzy wtyczki cache, dwie minifikujące CSS i dwie od lazy loadingu. W PrestaShop kilka modułów SEO nadpisujących te same meta tagi. Dublowanie funkcji to podwójne zapytania do bazy i konflikty w kolejności wykonywania.

• Zdjęcia produktowe: PNG 2–5 MB zamiast WebP 100–200 KB. W zakładce Network posortuj po Size – jeśli jedno zdjęcie waży więcej niż cały HTML strony, masz problem.
• Brak CDN przy ruchu ogólnopolskim. Serwer w jednej lokalizacji obsługuje klientów z całego kraju, a w sezonie liczba równoczesnych połączeń rośnie kilkukrotnie.
• Skrypty zewnętrzne: czat, piksel reklamowy, mapa, rotator bannerów. Każdy wykonuje się w głównym wątku i potrafi zepsuć INP, choć sam sklep jest poprawnie zbudowany. Więcej o tym progu: Web Vitals na web.dev.

Wykrywanie: Lighthouse daje punkt startowy, ale nie pokazuje rozkładu w czasie. Network w DevTools pokazuje, co realnie się ładuje i w jakiej kolejności. W WordPress dochodzi Query Monitor – widać zapytania, hooki i wtyczkę, która je generuje. W MySQL włącz slow query log z long_query_time = 0,5 s i sprawdź, które zapytania wracają najczęściej.

I pułapka kosztująca najwięcej czasu: cache. Włączenie agresywnego cache ścina czas odpowiedzi o połowę, ale ukrywa problem. Baza, brakujące indeksy i wolny serwer zostają. Test po wdrożeniu cache jest prosty: wyczyść go i zmierz żądanie do niezakeszowanego koszyka lub strony produktu – tam cache zwykle nie działa. To część prac, którą obejmuje miesięczna opieka techniczna nad sklepem.

SEO techniczne: indeksacja, struktura i dane strukturalne dla sklepu

Zacznij od robots.txt i sitemap.xml. W robots.txt sprawdź, czy nie ma przypadkowego Disallow: / lub blokady na /wp-content/, /modules/ czy /js/ – klasyczny efekt „tymczasowej blokady na czas prac”. Sitemapę zgłoś w Google Search Console i patrz nie na liczbę zgłoszonych adresów, ale na raporty „Zaindeksowane” i „Wykluczone”.

Canonicale, paginacja i facety to miejsce, w którym sklepy generują tysiące duplikatów. Kombinacja filtrów (?kolor=czerwony&rozmiar=l&sort=cena) tworzy adresy, które Google może potraktować jako osobne strony. Praktyka: dla pustych i wielokrotnych kombinacji filtrów ustaw noindex, dla głównej strony kategorii zostaw canonical. Google nie używa już rel=next/prev do łączenia paginacji, więc liczy się to, czy kolejne strony mają sensowną treść i nie konkurują z kategorią główną.

Struktura URL: krótka, bez /index.php i bez parametrów sesyjnych. Breadcrumbs na kategorii i produkcie zgodne ze strukturą linków, nie tylko wizualne.

Dane strukturalne: Product, Offer, BreadcrumbList, Organization. Bez nich tracisz szansę na rozszerzone wyniki, a przy błędach w Offer (brak priceCurrency, cena z VAT niezgodna z feedem) fragment bywa oznaczany jako nieprawidłowy. Pełna lista obsługiwanych typów jest w dokumentacji Google dotyczącej danych strukturalnych.

Błędy 404, przekierowania 301 i łańcuchy: przekierowanie A→B→C spowalnia i rozmywa sygnały. Po zmianie platformy przejrzyj stare adresy produktów i kategorii osobno. Warianty produktów i stany magazynowe też wymagają decyzji – każdy wariant jako osobny URL to skok liczby adresów, a „niedostępny” musi zgadzać się z tym, co pokazujesz w Schema.

Kontekst lokalny działa jako uzupełnienie widoczności: sklep z Krasnobrodu bywa porównywany z ofertą z okolic, więc osobne strony wdrożeniowe dla SEO technicznego i optymalizacji szybkości w Zwierzyńcu oraz SEO technicznego i optymalizacji szybkości w Szczebrzeszynie porządkują ruch z sąsiednich miejscowości i linkują do właściwych kategorii.

Koszt i czas: ile trwa optymalizacja szybkości i SEO technicznego w MŚP?

Audyt techniczny to zwykle 20–40 godzin. Wchodzi w to analiza logów, crawl, sprawdzenie Core Web Vitals na realnych urządzeniach, audyt indeksacji i lista zadań z priorytetami. Przy 200 produktach i jednej integracji płatności bliżej 20 godzin, przy 5000 SKU, kilku językach i połączeniu z ERP – bliżej 40.

Wdrożenie optymalizacji: 40–100 godzin dla typowego sklepu PrestaShop lub WooCommerce. Różnicę robi zakres – czy zmieniamy tylko konfigurację (OPcache, Redis, CDN, kompresja obrazów, kolejność skryptów), czy także szablon, zapytania i zbędne moduły. Samo przeniesienie sklepu z shared hostingu na serwer z OPcache i Redis to często kilka godzin pracy, a bywa największą pojedynczą zmianą w TTFB. Zakres takich prac i kolejność wdrożenia opisujemy przy okazji wdrożeń i optymalizacji WooCommerce w Krasnobrodzie.

Miesięczna opieka techniczna: 5–15 godzin. Monitoring dostępności i czasu odpowiedzi, backupy z testem odtworzenia, aktualizacje rdzenia i wtyczek, szybkie poprawki po zmianach w sklepie.

Czynniki podnoszące koszt: własny szablon z modyfikacjami, liczba wtyczek, model B2B (ceny zależne od logowania blokują pełny cache stron), integracje ERP i wielojęzyczność. Własny moduł zamiast płatnej wtyczki ma sens wtedy, gdy wtyczka ma roczną subskrypcję, a wykorzystujesz z niej 20% funkcji – wtedy prosty moduł bywa tańszy w utrzymaniu i lżejszy. Nie ma sensu, gdy potrzebujesz wsparcia zewnętrznego i częstych aktualizacji.

Wycena z liczby godzin jest uczciwsza niż stały cennik bez rozpoznania: dwie strony o podobnej liczbie produktów mogą różnić się dwukrotnie czasem wdrożenia przez jeden stary moduł albo niestandardowy szablon.

Hosting, CDN i serwer w Polsce – na co zwrócić uwagę przy sklepie z Krasnobrodu

Zanim ruszysz motyw i moduły, ustal, na czym sklep faktycznie stoi. PrestaShop: Zaawansowane → Informacje (wersja PHP i MySQL). WordPress: Narzędzia → Zdrowie witryny albo plik phpinfo. Zapisz to z datą – za trzy miesiące nikt nie odtworzy punktu wyjścia z pamięci.

Shared hosting kontra VPS. Shared wystarcza do momentu, w którym zaczyna brakować zasobów. Sygnały, że czas na zmianę: błędy 502 i 504 przy zapisie produktu, przekroczony limit procesów PHP, throttling CPU widoczny w DirectAdmin lub cPanel, TTFB powyżej 800 ms przy pustym koszyku. Wtedy VPS z 4 vCPU, 8 GB RAM i dyskiem NVMe to rozsądny start dla sklepu z 1000–5000 SKU.

• PHP 8.x – 8.2 lub 8.3, nie 7.4. Ustawienia: memory_limit 256–512 MB, max_execution_time 60–120 s, OPcache z pamięcią 128–256 MB, a na produkcji opcache.validate_timestamps = 0.
• Baza – MySQL 8 lub MariaDB 10.6+. InnoDB buffer pool na poziomie 50–70% RAM. Redis przydaje się na sesje i cache obiektowy; PrestaShop obsługuje go przez app/config/parameters.php.
• HTTP/2 lub HTTP/3 i TLS 1.3. Brotli (mod_brotli w Apache, ngx_brotli w Nginx), gzip tylko jako zapas. Cache-Control: pliki z hashem w nazwie – max-age 31536000 i immutable, HTML – no-store.
• CDN – Cloudflare lub Bunny CDN. Bunny ma punkty obecności w Warszawie, co dla polskiego ruchu daje niższe opóźnienia niż trasa do Frankfurtu. Pułapka: nie cache'uj HTML koszyka, zamówienia i panelu klienta.
• Backupy – baza i pliki codziennie, kopia poza serwer, retencja 30 dni, test odtworzenia raz na kwartał. Monitoring uptime co minutę z alertem SMS.

W umowie z administratorem zapisz konkret: dostępność 99,9% (około 43 minut przestoju miesięcznie), czas reakcji do 1 h w godzinach 8–18, RTO 4 h, RPO 24 h. Bez tych liczb „reagujemy szybko” nic nie znaczy, gdy koszyk pada w środku sezonu. Sposób budowy cache i modułów opisuje dokumentacja dla deweloperów PrestaShop.

Checklista wdrożeniowa krok po kroku (do wydruku)

Checklista działa tylko wtedy, gdy zapiszesz stan przed zmianami. Bez baseline nie udowodnisz, że cokolwiek się poprawiło – ani sobie, ani klientowi.

1. Pomiar baseline. PageSpeed Insights dla mobile i desktop (LCP, INP, CLS), TTFB, liczba zaindeksowanych adresów w GSC, błędy w logach z ostatnich 7 dni, lista modułów i wtyczek z wersjami, wersja PHP i bazy. Wszystko do jednego arkusza z datą.
2. Kolejność działań. Serwer → cache → baza → frontend → obrazy → JS → SEO techniczne. Odwrotna kolejność to strata czasu: kompresja obrazków na serwerze z TTFB 1,2 s nic nie da, bo wąskie gardło zostaje tam, gdzie było.
3. Walidacja po każdym etapie. Powtórz PageSpeed, sprawdź GSC, przejrzyj logi, wykonaj testowe zamówienie do końca, z płatnością. Jeden etap – jedna walidacja, nie siedem zmian na raz.
4. Test na kopii. Staging na subdomenie z Basic Auth i noindex, osobna baza i osobny plik konfiguracyjny. Produkcja dopiero, gdy staging przejdzie cały koszyk.
5. 28 dni monitoringu. Raport Core Web Vitals w GSC aktualizuje się z opóźnieniem, a dane z pola (CrUX) to średnia z 28 dni. Wcześniej zobaczysz szum, nie efekt. Podstawy pomiaru opisuje web.dev – Web Vitals.

Ten sam schemat stosujemy dla sąsiednich miejscowości: SEO techniczne i optymalizacja szybkości w Zwierzyńcu oraz SEO techniczne i optymalizacja szybkości w Szczebrzeszynie – różni się ruch i konkurencja, nie kolejność działań.

Kiedy robić to samemu, a kiedy oddać do DropDigital?

Podział wynika z liczby ruchomych części, nie z rozmiaru firmy.

Zrobisz to sam, jeśli masz katalog do około 200–300 produktów, jeden motyw, kilka wtyczek i brak integracji z systemem magazynowym. Realny zakres: kompresja obrazów do WebP, lazy loading, włączenie cache (LiteSpeed Cache lub WP Rocket w WooCommerce, wbudowany cache i CCC w PrestaShop), poprawa robots.txt i mapy XML, podłączenie GSC. Marketingowiec domknie to w kilka dni, bez dostępu do SSH.

Potrzebujesz dewelopera, gdy przenosisz sklep z shared hostingu na VPS, piszesz niestandardowy moduł, baza ma zapytania powyżej 1 s i trzeba przejrzeć slow query log oraz indeksy, albo wdrażasz integracje InPost, DPD i DHL z generowaniem etykiet i aktualizacją statusów po webhookach. To nie są zadania „na wtyczkę z marketplace”.

Opieka po wdrożeniu to nie tylko aktualizacje. Konkretnie: aktualizacje PrestaShop/WooCommerce i wtyczek raz w miesiącu, test na staging przed produkcją, monitoring uptime, backupy z testem odtworzenia, SLA na reakcję. Zakres opisaliśmy w utrzymanie i opieka techniczna sklepów Krasnobród – co obejmuje.

Praca bezpośrednio z deweloperem, bez pośredników, skraca drogę przy awarii. Jedna osoba zna serwer, moduły i historię zmian, więc diagnoza nie zaczyna się od zera. Przy koszyku, który nie działa w piątek wieczorem, to różnica kilku godzin.

Do rozmowy przygotuj: dostęp do GSC (właściciel lub pełne uprawnienia, nie tylko podgląd), dane do hostingu i panelu, SSH lub dane bazy, listę wtyczek z wersjami, wersję PHP i MySQL, dwa–trzy pomiary PageSpeed oraz informację, co ostatnio było zmieniane. To skraca wycenę z tygodnia do jednego dnia.

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

Lista kontrolna do odklikania

• Google Search Console – weryfikacja i raport szybkości — Sprawdź, czy usługa jest podłączona i czy zbiera dane z ostatnich 28 dni. Jeśli nie, to pierwszy krok przed jakąkolwiek optymalizacją.
• Raport indeksowania w GSC — Zobacz, ile adresów jest zaindeksowanych i które są wykluczone. Sprawdź, czy nie ma wykluczeń typu „zaindeksowano, mimo że oznaczono jako noindex” — to typowy efekt pracy kilku wtyczek SEO naraz.
• Błędy 404 i mapy witryny — Przejrzyj błędy 404 z ostatnich 90 dni oraz to, czy sitemap.xml jest zgłoszony i aktualny. Sprawdź, czy robots.txt nie blokuje przypadkiem kategorii albo filtrów.
• PageSpeed Insights – mobile — Zmierz LCP, INP i CLS dla strony głównej, kategorii i karty produktu osobno. Wynik nie jest celem samym w sobie, ale punktem odniesienia.
• PageSpeed Insights i Lighthouse – desktop — Sprawdź, czy problem jest taki sam na desktopie. Inny rozkład problemów oznacza, że część z nich dotyczy obrazów i fontów, a nie logiki aplikacji.
• WebPageTest lub GTmetrix – wodospad ładowania — Ustaw lokalizację serwera w Polsce lub Europie. Sprawdź kolejność requestów, TTFB i to, co ładuje się przed pierwszym renderem.
• Pomiar TTFB przy pustym cache — To test bazowy. Wysoki TTFB przy pustym cache jednoznacznie wskazuje na serwer, PHP lub bazę — i wyklucza winę frontendu.
• Logi serwera i zużycie CPU/RAM — Poproś hosting o logi z okresu szczytowego ruchu. Szukaj wzrostu zużycia przy wejściu Googlebota oraz limitów procesów PHP.
• Slow query log lub Query Monitor — Sprawdź, które zapytania trwają najdłużej i czy brakuje im indeksów. To najczęściej pomijany etap w małych sklepach.
• Limity hostingu: PHP, MySQL, równoczesne połączenia — Ustal wersję PHP, dostępność OPcache, Redis, limit równoczesnych procesów i połączeń MySQL. Jeśli hosting nie podaje tych liczb, to sam w sobie informacja.
• Baseline LCP, INP, CLS, TTFB i czas pełnego załadowania — Zapisz wszystkie wartości z datą, zanim cokolwiek zmienisz. Bez tego każda późniejsza dyskusja o efekcie jest zgadywaniem.
• Lista wtyczek lub modułów z przypisaną funkcją — Dla każdej wtyczki zapisz jedno zdanie: za co odpowiada. Powtarzające się opisy to lista kandydatów do wyłączenia.
• Wpływ skryptów zewnętrznych na INP — Sprawdź w zakładce Network, ile domen zewnętrznych ładuje się na starcie i które z nich są krytyczne dla koszyka.
• Priorytetyzacja: indeksacja i kampanie płatne na pierwszym miejscu — Najpierw napraw to, co blokuje indeksację i płatny ruch (błędy 404, noindex, koszyk, ładowanie produktu). Drobne optymalizacje zostaw na koniec.

Najczęściej zadawane pytania

Źródła i materiały

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