SEO techniczne i optymalizacja szybkości w sklepie to praca w konkretnej kolejności: najpierw indeksacja i architektura, na końcu wydajność. Jeśli zaczniesz od wtyczki do cache, możesz przyspieszyć adresy, których Google i tak nie indeksuje. Poniżej znajdziesz część organizacyjną: najczęstsze błędy w prowadzeniu takich prac, checklistę do odhaczenia i odpowiedzi na pytania, które słyszymy od właścicieli sklepów z okolic Szczebrzeszyna. Sam proces planowania rozpisaliśmy w materiale o SEO technicznym i szybkości w Zamościu.
Właściciele sklepów często mówią „mamy SEO” i mają na myśli wtyczkę, w której ktoś wpisał meta title. Praca techniczna dzieli się na trzy warstwy i przestawienie ich kolejności to najdroższy błąd, bo płacisz za szybkość adresów, których Google nie widzi.
Przykład lokalny: sklep z dostawą na Szczebrzeszyn, Zamość i Zwierzyniec. Naturalny odruch to wygenerować kilkanaście podstron „dostawa + miasto”. Efekt jest odwrotny do zamierzonego – powstaje seria stron z jednym akapitem, tym samym opisem i bez linków przychodzących, czyli klasyczny thin content. Lepiej zrobić jedną podstronę „obszar i warunki dostawy” z realnymi danymi: koszt kuriera, czas, próg darmowej dostawy, mapa zasięgu – i wzmocnić ją linkami z kategorii głównej. Ta jedna strona zbiera sygnał z trzech miejscowości, zamiast rozbijać go na kilkanaście słabych adresów. Kolejność planowania takich prac rozpisaliśmy w materiale o SEO technicznym i szybkości w Zamościu – plan działania.
| Objaw | Prawdopodobna warstwa | Gdzie to sprawdzić |
|---|---|---|
| Produkt nie pojawia się w Google | Indeksacja | Search Console → „Sprawdzenie adresu URL”, raport „Strony” |
| Kategoria ma tysiące URL-i przy 300 produktach | Indeksacja / architektura | Raport „Strony” + audyt parametrów filtrów |
| Strona ładuje się 6 s, rosną odrzucenia | Wydajność | Raport „Core Web Vitals”, dane terenowe |
| Po zmianie szablonu spadki pozycji | Indeksacja | Porównanie liczby „Zindeksowane” tydzień do tygodnia |
| Nowy produkt wchodzi do Google po 3 tygodniach | Architektura | Brak linków wewnętrznych / zbyt głębokie zagnieżdżenie |
Zanim cokolwiek optymalizujesz, sprawdź, czy w ogóle masz problem. Trzy progi Core Web Vitals: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Wszystkie trzy liczone dla 75. percentyla wizyt, na danych terenowych z CrUX z ostatnich 28 dni. To nie są liczby z jednego testu na twoim laptopie.
Różnica między danymi laboratoryjnymi a terenowymi jest kluczowa. Lighthouse odpala jednorazowy test na szybkim sprzęcie, bez rozszerzeń, często na dobrym łączu. CrUX to realni klienci – telefon za 800 zł, LTE pod Zwierzyńcem, dwadzieścia otwartych kart. Sklep z zielonym Lighthouse bywa czerwony w CrUX i to jest norma, nie wyjątek. Jeśli raport „Core Web Vitals” w Search Console świeci na czerwono, wierząj jemu, nie własnemu testowi.
Budżet wydajności, który warto sobie wpisać jako limit w projekcie:
Te liczby nie są wyjęte z powietrza – wynikają z tego, jak przeglądarka buduje drzewo renderowania. Metodologię i progi znajdziesz w dokumentacji Web Vitals na web.dev.
| Element wpływający na LCP | Typowy koszt | Szybka naprawa |
|---|---|---|
| Hero image 2,5 MB w JPEG | +1,5–3 s | WebP/AVIF, srcset, preload, wymiary width/height w HTML |
| Font w 4 plikach WOFF2 bez font-display | +0,3–0,8 s | Jeden plik, font-display: swap, preload dla wariantu krytycznego |
| Cena i dostępność wstrzykiwane JS-em po hydracji | +0,5–1,5 s | Render po stronie serwera – cena ma być w HTML |
| Slider z 5 zdjęciami ładowany równolegle | +0,8–2 s | Pierwsze zdjęcie eager, pozostałe loading="lazy" |
| Skrypty analityczne i reklamowe w <head> synchronicznie | +0,3–1 s | defer lub ładowanie po pierwszej interakcji |
Kolejność nie jest przypadkowa. Jeśli zaczniesz od wydajności, a robot nie widzi połowy kategorii, przyspieszasz puste adresy. Idź tak:
price, priceCurrency i availability.Audyt to nie jednorazowa akcja. Przez pierwszy miesiąc po wdrożeniu sprawdzaj GSC raz w tygodniu – to wyłapuje większość regresji. Stały monitoring opisaliśmy w utrzymaniu i opiece technicznej sklepów w Szczebrzeszynie.
W PrestaShop większość strat wydajności siedzi w trzech miejscach: w ustawieniach wydajności, w bazie danych i w modułach zewnętrznych. Panel to 15 minut roboty, więc zaczynasz od niego.
Dalej baza. Sprawdź indeksy na ps_product_lang (id_product, id_lang) oraz ps_category_product (id_category, id_product) – po migracjach z 1.6 albo importach z hurtowni zdarza się, że klucz zniknął. Włącz profilowanie w config/defines.inc.php (_PS_DEBUG_PROFILING_) i policz zapytania na widoku kategorii z 24 produktami. Zdrowy wynik to 60–120 zapytań; 400+ znaczy, że jakiś moduł dociąga dane w pętli.
Wbudowana wyszukiwarka używa wzorca LIKE '%fraza%' i przy katalogu 3–5 tys. produktów skanuje całą tabelę. Indeksem tego nie naprawisz – potrzebny zewnętrzny silnik (Meilisearch, Elasticsearch) albo indeks pełnotekstowy. Domyślne wyszukiwanie zostaw tylko przy katalogu do ok. 1000 produktów.
Na koniec moduły: podwójne doładowanie jQuery, skrypty koszyka ładowane na stronie głównej, konflikty JS po włączeniu CCC. Metoda wykrycia: log wolnych zapytań MySQL (long_query_time = 0.5), panel Performance i wyłączanie modułów po kolei z pomiarem tego samego adresu. Własny moduł opłaca się wtedy, gdy funkcja jest powtarzalna, a roczna subskrypcja wtyczki po dwóch latach przewyższa jednorazowy koszt napisania i utrzymania. Punkt wyjścia do grzebania w kodzie znajdziesz w dokumentacji dla deweloperów PrestaShop.
| Miejsce | Co ustawić / sprawdzić | Wartość docelowa |
|---|---|---|
| Zaawansowane → Wydajność | CCC: Combine, Compress, Cache | wszystkie włączone |
| Zaawansowane → Wydajność | Wymuszaj kompilację szablonu | wyłączone w produkcji |
| Smarty cache | System plików lub Redis/Memcached | Redis powyżej ~1000 wizyt dziennie |
| Baza danych | Indeksy ps_product_lang, ps_category_product | klucze złożone obecne |
| Widok kategorii | Liczba zapytań (profilowanie) | 60–120 zapytań, nie 400+ |
| Wyszukiwarka | Wbudowana vs zewnętrzny silnik | silnik zewnętrzny powyżej 3–5 tys. produktów |
W WooCommerce wąskim gardłem prawie nigdy nie jest sam WordPress, tylko liczba wtyczek i nieindeksowane metadane. Zacznij od policzenia wierszy: wp_posts i wp_postmeta. Katalog 10 tys. produktów generuje zwykle 500 tys. – 1 mln wierszy w postmeta, bo każdy produkt trzyma tam cenę, stan, atrybuty i warianty.
Sortowanie po cenie to klasyczna pułapka. Jeśli sklep sortuje przez ORDER BY meta_value z kluczem _price, a nie działa tabela wc_product_meta_lookup, MySQL skanuje całą postmeta przy każdym kliknięciu „sortuj od najtańszych”. Sprawdź, czy lookup table jest wypełniona i czy wtyczki jej nie omijają.
HPOS (High-Performance Order Storage) przenosi zamówienia z wp_posts do tabel wc_orders i wc_order_addresses. Efekt: krótsze zapytania na liście zamówień w panelu i mniejszy wp_posts. Warunek – wszystkie wtyczki muszą być zgodne z HPOS; przed włączeniem zrób kopię i test na stagingu.
Action Scheduler: zajrzyj do wp_actionscheduler_actions i policz zadania ze statusem pending po terminie. Kilkadziesiąt tysięcy zaległych akcji (np. od nieudanej synchronizacji z hurtownią) obciąża każdy request. Wyczyść po ustaleniu przyczyny, nie w ciemno.
Transienty i wp_options: sprawdź sumę wartości z autoload = yes. Przekroczenie ok. 1 MB oznacza, że WordPress ładuje ten balast przy każdym żądaniu. Page buildery dokładają drugie tyle – ich CSS i JS potrafią ładować się globalnie, także na stronach, które ich nie używają.
Kolejność pracy: 1) autoload w wp_options, 2) Query Monitor na widoku kategorii i karty produktu, 3) liczba aktywnych wtyczek, 4) HPOS i Action Scheduler. New Relic lub Blackfire włącz, gdy Query Monitor pokaże problem, którego nie umiesz przypisać do konkretnego hooka. Jak ułożyć całe wdrożenie, opisaliśmy w materiale o organizacji wdrożeń i optymalizacji WooCommerce.
| Narzędzie | Co pokazuje | Na co patrzeć w pierwszej kolejności |
|---|---|---|
| Query Monitor | Zapytania, hooki, duplikaty | zapytania powyżej 50 ms i te samy powtarzane 100+ razy |
| Slow query log MySQL | Zapytania wolniejsze niż próg | skany pełnej tabeli na wp_postmeta i wp_options |
| Blackfire / New Relic | Profil całego requestu | czas w hookach wtyczek, nie w jądrze WordPress |
| Panel HPOS | Zgodność wtyczek | wtyczki oznaczone jako niezgodne przed migracją |
Dla zapytania „szczebrzeszyn” sama szybkość nie wystarczy. Zapytania lokalne rozstrzygają się w Local Pack, a tam wchodzi się przez profil Google Business Profile. Jeśli masz sklep stacjonarny albo punkt wydawania, brak GBP oznacza brak widoczności na mapie – nawet przy perfekcyjnym LCP.
W profilu ustal jedną kategorię główną (np. „sklep odzieżowy”, „sklep z elektroniką”) i maksymalnie 2–3 dodatkowe. Wpisz obszar obsługi, godziny zgodne z tym, co na stronie, i wgraj 10–20 realnych zdjęć – nie stocki. Dodaj produkty, jeśli faktycznie je sprzedajesz.
Potem spójność NAP. Ustal jeden format telefonu i wklejaj go identycznie: na stronie (stopka, kontakt, dane strukturalne), w GBP, w katalogach i portalach regionalnych. Typowy błąd: na stronie numer z prefiksem 84, w GBP zapis +48, a w katalogu jeszcze inny układ cyfr. Formalnie to ten sam numer, ale rozjeżdża dopasowanie, a część klientów dzwoni pod zły.
Treści lokalne mają sens tylko wtedy, gdy niosą informację. Podaj miejscowości i kody pocztowe, które obsługujesz (dla Szczebrzeszyna to 22-460, obok Zwierzyniec, Tereszpol, Zamość – wpisz własne, zweryfikowane), wymień punkty odbioru InPost i DPD, z których realnie wysyłasz, oraz czas dostawy na trasie Zamość–Szczebrzeszyn–Zwierzyniec. Nie znasz czasu? Policz go z ostatnich 50 wysyłek, nie zgaduj.
Czego nie robić: masowego generowania 50 podstron „sklep + miasto”. Identyczna treść z podmienioną nazwą konkuruje sama ze sobą i rozmywa sygnały. Lepiej jedna rzetelna strona o dostawie i płatności.
Na koniec dane strukturalne: Store/LocalBusiness z adresem, areaServed i godzinami otwarcia. Najczęstsze błędy to adres tylko w jednej wersji językowej i areaServed wpisane jako zwykły tekst zamiast typu miejsca. Wszystko sprawdzisz w Teście wyników zrozumiałych – lista obsługiwanych typów danych strukturalnych jest dobrym punktem startu. Jeśli nie chcesz pilnować tego samodzielnie, wchodzi w to utrzymanie i opieka techniczna sklepów.
| Kanał | Co wpisać | Typowy błąd |
|---|---|---|
| Strona (stopka, kontakt) | Nazwa, adres, telefon w jednym formacie | inny zapis numeru niż w GBP |
| Google Business Profile | Kategoria główna, obszar obsługi, godziny | obszar obsługi sprzeczny z adresem |
| Katalogi i portale regionalne | Ten sam NAP, ten sam format | stary numer lub adres po przeprowadzce |
| Dane strukturalne | Store/LocalBusiness, areaServed, openingHours | areaServed jako zwykły tekst |
Zacznij od rozdzielenia danych laboratoryjnych od terenowych. Tylko te drugie opisują realnych klientów, pierwsze służą do diagnozy i porównań „przed/po”.
KPI, które warto wpisać do ustaleń z wykonawcą: liczba zaindeksowanych adresów, TTFB, LCP na 75. percentylu (cel poniżej 2,5 s), pozycja na wybrane frazy lokalne, współczynnik konwersji i przychód z ruchu organicznego.
| Etap | Dni | Zakres prac | Co odczytujesz na koniec |
|---|---|---|---|
| Indeksacja i architektura | 1–30 | Poprawki w robots.txt, kanibalizacja, przekierowania 301, mapa strony, parametry fasetowe | Liczba zaindeksowanych adresów, liczba błędów 404 i 5xx |
| Wydajność i frontend | 31–60 | Obrazy, krytyczny CSS, kolejność ładowania skryptów, konfiguracja cache | TTFB, LCP 75. percentyl, liczba żądań na stronę |
| Treści lokalne i dane strukturalne | 61–90 | Opisy kategorii, dane strukturalne produktów i firmy, linki lokalne | Pozycje na frazy lokalne, CTR, konwersja z ruchu organicznego |
Większość „przyspieszeń” z poradników to zmiany, które albo nic nie dają, albo psują coś, czego nie widać w Lighthouse.
loading="lazy", przeglądarka odkłada jego pobranie i LCP rośnie. Sprawdzenie: DevTools → Elements, wyszukaj loading="lazy"; w zakładce Performance zaznacz marker LCP i zobacz, który element go wyznacza. Baner hero i logo zostaw bez lazy-loadingu.application/ld+json z tym samym typem, dwa odwołania do sitemap w robots.txt, różne nagłówki X-Cache w odpowiedzi.Każdą z tych zmian weryfikuj po kolei, na jednej kopii sklepu – nie wdrażaj pięciu rzeczy naraz, bo nie ustalisz, która zaszkodziła.
| Pułapka | Objaw | Jak sprawdzić |
|---|---|---|
| Lazy-loading na LCP | LCP nie spada po optymalizacji obrazów | Marker LCP w DevTools, atrybut loading w Elements |
| Cache koszyka | Losowe puste koszyki | Test w incognito z dodanym produktem |
| Podwójny cache | Niespójne nagłówki, stara treść | Dwa różne X-Cache w tej samej odpowiedzi |
| Podwójne dane strukturalne | Błędy w raporcie wyników rozszerzonych | Dwa bloki ld+json z tym samym typem |
Realne widełki, które możesz wpisać do budżetu: audyt techniczny 6–12 h, wdrożenie poprawek wydajności 12–40 h. Górna granica dotyczy sklepów z własnymi modułami, szablonem po modyfikacjach i integracją ERP. Dolna – katalogu na standardowym szablonie bez zmian w kodzie. Pracę rozliczamy godzinowo, a stawkę podajemy przed startem, żeby po fakturze nie było dyskusji o zakresie.
Opieka techniczna to monitoring Core Web Vitals i dostępności sklepu, aktualizacje rdzenia i modułów, kopie zapasowe oraz jasne SLA na czas reakcji – od kilkuset złotych miesięcznie. Przy sklepie, który zarabia, brak aktualizacji bezpieczeństwa jest droższy niż abonament.
Kiedy robić samemu: katalog poniżej 500 produktów, brak zmian w szablonie, standardowe moduły, dostęp do panelu hostingu. Kiedy oddać: własne moduły, migracja sklepu, integracja z ERP lub magazynem, problemy z wydajnością po stronie serwera (bazy danych, PHP-FPM, limity I/O).
Zanim cokolwiek zlecasz, sprawdź kolejność prac – najpierw indeksacja i architektura, na końcu wydajność. Rozpisaliśmy to w planie działania dla Zamościa, który możesz przełożyć na własny sklep.
Zacznij od bezpłatnej wstępnej analizy: 15 minut na podstawie adresu sklepu i danych z Search Console. Zwykle po tym jednym spotkaniu wiadomo, czy problemem jest indeksacja, szablon, czy hosting.
| Zakres | Czas | Kiedy zrobisz sam | Kiedy potrzebny deweloper |
|---|---|---|---|
| Audyt techniczny | 6–12 h | Sklep do 500 produktów, standardowy szablon | Własne moduły, integracje |
| Wdrożenie poprawek wydajności | 12–40 h | Zmiany w ustawieniach cache, obrazach | Krytyczny CSS, zmiany w szablonie, baza danych |
| Opieka techniczna | abonament miesięczny | Ręczne kopie i aktualizacje raz w miesiącu | Monitoring CWV, SLA na reakcję |
Zaczynanie od przyspieszania strony, zanim uporządkowana jest indeksacja.
Jak wykryć: W raporcie Strony w Search Console widać setki lub tysiące adresów ze statusem „Odkryte, obecnie niezaindeksowane” albo „Zindeksowane, ale zablokowane przez robots.txt”, a pierwsze prace i tak dotyczą cache oraz kompresji obrazów.
Jak naprawić: Odwróć kolejność: robots.txt i meta robots, sitemap.xml, canonical, statusy 301/404, struktura URL — dopiero potem wydajność. Przyspieszanie adresów, których Google nie widzi, nie daje efektu.
Ocena szybkości na podstawie jednego testu Lighthouse.
Jak wykryć: Raport Lighthouse pokazuje zielone oceny, a w Search Console sekcja Core Web Vitals ma adresy na czerwono.
Jak naprawić: Porównuj dane terenowe: 75. percentyl LCP, INP i CLS z ostatnich 28 dni. Lighthouse traktuj jako narzędzie diagnostyczne do znalezienia przyczyny, nie jako ocenę końcową.
Brak właściciela zadania i jednego miejsca z listą prac.
Jak wykryć: Ustalenia z audytu są w mailu, w notatkach ze spotkania i w głowie programisty. Po dwóch tygodniach nikt nie potrafi powiedzieć, co zostało zrobione, a co nie.
Jak naprawić: Jedna tablica zadań z priorytetem (P0 blokuje indeksację, P1 wpływa na sprzedaż, P2 porządki), przypisaną osobą i datą. Bez tego audyt kończy się dokumentem, nie zmianami.
Wdrażanie poprawek wprost na produkcji, bez kopii i środowiska testowego.
Jak wykryć: Pliki szablonu są edytowane przez FTP na działającym sklepie, nie ma stagingu, brak kopii przed zmianą.
Jak naprawić: Postaw staging z kopią bazy i plików, testuj na nim, a na produkcję wchodź w oknie poza szczytem zamówień i zawsze z kopią.
Mierzenie tylko strony głównej.
Jak wykryć: W projekcie jest jeden adres testowy — zwykle strona główna — a kategoria, karta produktu, koszyk i checkout nie są nigdzie monitorowane.
Jak naprawić: Mierz po jednym reprezentatywnym adresie z każdego szablonu. Kategoria i karta produktu generują sprzedaż i to tam najczęściej leży problem z LCP.
Brak zapisu stanu przed zmianami.
Jak wykryć: Po wdrożeniu nikt nie potrafi pokazać, jak wyglądały dane przed — nie ma eksportu z Search Console ani zrzutu danych terenowych.
Jak naprawić: Przed startem zapisz eksport raportu Strony i Core Web Vitals z GSC, listę adresów z sitemap.xml, zrzut danych CrUX z 28 dni oraz kopię robots.txt i .htaccess.
Techniczne SEO w sklepie wygrywa się kolejnością, nie narzędziami. Najpierw indeksacja, potem architektura, na końcu wydajność — a każda zmiana ma punkt startowy, właściciela i sposób pomiaru. Jeśli któregoś z tych trzech elementów brakuje, nawet poprawnie wykonane poprawki trudno przypisać do wyniku. Zacznij od checklisty powyżej i jednego sprintu z jasno określonym zakresem.
Od blokad indeksacji, nie od szybkości. Sprawdź robots.txt, meta robots, sitemap.xml i canonical, a potem zajrzyj do raportu Strony w Search Console. Dopiero gdy wiesz, co Google widzi, sens ma praca nad architekturą i wydajnością.
Nie. Lighthouse mierzy warunki laboratoryjne, na jednym urządzeniu i w jednej chwili. Ocena opiera się na danych terenowych z 75. percentyla z ostatnich 28 dni, dlatego sklep może mieć zielony Lighthouse i czerwone Core Web Vitals. Podstawy znajdziesz w dokumentacji Web Vitals oraz w opisie Core Web Vitals w Google Search Central.
Nie ma jednej liczby, która pasowałaby do każdego sklepu — zakres zależy od liczby szablonów, modułów i długu technicznego. Zamiast pytać o termin całości, podziel pracę na sprinty i po każdym sprawdź jedną metrykę. Pierwszy sprint warto poświęcić wyłącznie na blokady indeksacji, bo tam efekty widać najszybciej.
Jedna osoba po stronie firmy: właściciel sklepu albo osoba odpowiedzialna za e-commerce. Nie musi sama robić poprawek, ale musi decydować o priorytetach i odbierać efekty. Jeśli decyzje podejmuje pięć osób, prace zatrzymują się na etapie ustaleń.
Użyj Testu wyników zrozumiałych w Search Console i porównaj wynik z listą typów obsługiwanych przez Google. Najczęściej wypadają cena, waluta i dostępność, bo generuje je szablon lub moduł, a nie treść wpisana ręcznie. Listę obsługiwanych typów znajdziesz w dokumentacji danych strukturalnych Google.
Po każdej zmianie, która dotyka szablonu, modułów, cache albo serwera, oraz przy każdej migracji. Pomiędzy nimi wystarczy stały monitoring: raport Strony i Core Web Vitals raz w tygodniu. Stały nadzór opisujemy w usłudze utrzymania i opieki technicznej sklepów.
Nie ma jednej liczby, od której wbudowana wyszukiwarka przestaje wystarczać. Decyduje czas odpowiedzi i jakość trafień, a nie sam rozmiar katalogu. Zmierz oba parametry na własnych danych, zanim wydasz budżet na zewnętrzne rozwiązanie — punktem wyjścia jest dokumentacja PrestaShop dla deweloperów.
Jeśli wolisz zacząć od rozmowy niż od listy zadań, napisz do nas — powiemy, co w Twoim sklepie sprawdzilibyśmy w pierwszej kolejności. Prowadzimy też stałą opiekę techniczną nad sklepami z okolic Szczebrzeszyna i Zamościa.