SEO techniczne i optymalizacja szybkości w Józefowie to praca, której klient nie widzi: indeksacja, canonical, przekierowania 301, czas odpowiedzi serwera. Najczęstszy problem, jaki zastajemy w sklepach, nie brzmi „brak treści”, ale „sklep istnieje, a Google pokazuje go daleko albo wcale”. Poniżej masz część organizacyjną: co mierzyć, czym, w jakiej kolejności i jakich błędów nie powtarzać. To samo ujęcie dla sąsiedniej lokalizacji znajdziesz w tekście SEO techniczne i optymalizacja szybkości w Zwierzyńcu, a kwestie sklepowe rozwijamy we wdrożeniach WooCommerce. Kolejne sekcje artykułu rozłożą temat na konkretne wdrożenia.
SEO techniczne to nie „dodatek do treści”, tylko warunek, żeby treść w ogóle mogła zostać pokazana w wynikach. W praktyce rozdzielamy trzy filary, bo każdy naprawia się innymi narzędziami i każdy psuje się inaczej:
Elementy techniczne sprawdzamy zawsze w tej kolejności: robots.txt (czy nie blokuje CSS, JS albo całych katalogów), sitemap.xml (tylko adresy zwracające 200 OK, bez przekierowań i bez noindex), poprawność atrybutu canonical, HTTPS bez mieszanych zasobów, dane strukturalne zgodne z dokumentacją Google, łańcuchy przekierowań 301 sprowadzone do jednego skoku.
Kiedy SEO techniczne działa samo? Gdy blokadą jest wyłącznie dostęp do indeksu – strona ma sensowną treść, ale produkty siedzą pod parametrami filtrowania, noindex został po wdrożeniu testowym, a canonical wskazuje na stronę główną. Wtedy sama naprawa techniczna potrafi odblokować widoczność na mniej konkurencyjnych frazach lokalnych.
Kiedy musi iść w parze z treścią? Załóżmy sklep z Józefowa: opisy produktów są poprawne, kategorie mają teksty, a ruchu organicznego nie ma. Powód bywa prozaiczny – 90% adresów produktów ma canonical na kategorię, a Google indeksuje 12 z 400 stron. Treść była dobra, ale nie miała szansy zostać pokazana. Zasady tworzenia materiałów nastawionych na odbiorcę opisuje dokumentacja [tworzenia treści przyjaznych ludziom](https://developers.google.com/search/docs/fundamentals/creating-helpful-content). Ten sam schemat pracy dla sąsiedniej lokalizacji rozpisaliśmy w tekście [SEO techniczne i optymalizacja szybkości w Zwierzyńcu](https://dropdigital.pl/seo-techniczne-optymalizacja-szybkosci-zwierzyniec).
Core Web Vitals to trzy metryki, które mają twarde progi. Wartości poniżej progu uznaje się za dobre:
Kluczowe rozróżnienie: dane terenowe pochodzą od prawdziwych użytkowników (CrUX, raport Core Web Vitals w Search Console), a laboratoryjne z jednego przebiegu na serwerze testowym (Lighthouse, PageSpeed Insights). Google ocenia witrynę na podstawie danych terenowych, zbieranych w okresie 28 dni.
Druga rzecz, o której się zapomina: ocena liczona jest na 75. percentylu. To znaczy, że próg musi spełniać 75% wizyt – najgorsze 25% nie może wypadać powyżej normy. Wystarczy jeden ciężki szablon kategorii albo skrypt czatu wczytywany na każdej podstronie, żeby ten percentyl przekroczyć, mimo że strona główna wypada świetnie w Lighthouse.
Praktyczny wniosek: nie optymalizuj „średniej”, tylko najgorszy kwartyl. Jeśli LCP kategorii wynosi 1,8 s, a stron produktowych 4,1 s, naprawiasz strony produktowe – bo to one psują wynik całej witryny. Definicje i progi znajdziesz w dokumentacji [Web Vitals](https://web.dev/articles/vitals). Jeśli problem dotyczy sklepu, jego specyfikę (koszyk, warianty, wtyczki) rozwijamy we [wdrożeniach i optymalizacji WooCommerce w Zwierzyńcu](https://dropdigital.pl/wdrozenia-optymalizacja-woocommerce-zwierzyniec).
| Metryka | Próg (dobry wynik) | Co mierzy | Najczęstsza przyczyna problemu |
|---|---|---|---|
| LCP | poniżej 2,5 s | czas wyrenderowania największego elementu w viewporcie | ciężki baner hero, zdjęcia bez kompresji i bez atrybutów width/height, wysoki TTFB |
| INP | poniżej 200 ms | opóźnienie reakcji na interakcje w trakcie całej wizyty | długie zadania JavaScript, nadmiar wtyczek, skrypty zewnętrzne blokujące wątek główny |
| CLS | poniżej 0,1 | przesunięcia układu podczas wczytywania | obrazy i iframe bez wymiarów, wstrzykiwane bannery, fonty bez font-display |
Pomiar bez planu kończy się dyskusją o pojedynczym wyniku. Poniżej zestaw, którym pracujemy, oraz to, czego dane narzędzie nie mówi.
Google Search Console – punkt startowy. Raport Core Web Vitals pokazuje adresy w grupach „wymaga poprawy” i „słabe”, a sekcja Indeksowanie mówi, ile adresów jest wykluczonych i dlaczego (np. „zaindeksowana, choć zablokowana przez robots.txt”, „duplikat bez wybranego canonicala”). Dane terenowe mają opóźnienie około 28 dni, więc nie zobaczysz w nich efektu wczorajszego wdrożenia.
PageSpeed Insights – jeden adres, dwa zbiory danych: terenowe z CrUX i laboratoryjne z Lighthouse. Patrz najpierw na terenowe, laboratoryjne traktuj jako listę zadań.
Lighthouse w Chrome DevTools – audyt lokalny, w trybie incognito, z wyłączonymi rozszerzeniami. Dobre do diagnozy konkretnego szablonu, słabe do oceny całej witryny.
WebPageTest – test z wybranej lokalizacji i profilu sieci, z filmem wczytywania. Pokazuje, co dokładnie opóźnia LCP.
GTmetrix – wybierasz serwer pomiarowy (np. Frankfurt, Londyn). Ma znaczenie: test z USA na polskim hostingu będzie wyglądał gorzej i nie mówi nic o klientach z Józefowa.
Screaming Frog lub Ahrefs Site Audit – pełny crawl: kody odpowiedzi, duplikaty, canonicale, głębokość kliknięcia, crawl budget. Crawl z jednego IP obciąża serwer, więc ustaw throttling i wyklucz koszyk oraz strony wyników wyszukiwania.
Praktyczny krok: wykonaj trzy testy tego samego dnia (rano, w południe, wieczorem) i porównuj medianę, nie pojedynczy wynik. Różnice 200–400 ms między przebiegami na współdzielonym hostingu są normą – dopiero stała powtarzalność problemu jest sygnałem do wdrożenia. Ramy oceny po stronie Google opisuje dokumentacja [Core Web Vitals](https://developers.google.com/search/docs/appearance/core-web-vitals). Ten sam zestaw pomiarowy stosujemy w innych lokalizacjach, m.in. w tekście [SEO techniczne i optymalizacja szybkości – Szczebrzeszyn](https://dropdigital.pl/seo-techniczne-optymalizacja-szybkosci-szczebrzeszyn).
| Narzędzie | Co daje | Na co uważać |
|---|---|---|
| Google Search Console | raport Core Web Vitals, stan indeksowania, przyczyny wykluczeń | dane opóźnione o ok. 28 dni, agregacja urządzeń i grup adresów |
| PageSpeed Insights | dane terenowe z CrUX plus test laboratoryjny | wynik laboratoryjny to jeden przebieg, nie ocena witryny |
| Lighthouse (Chrome DevTools) | audyt lokalny z konkretną listą poprawek | tryb incognito i wyłączone rozszerzenia, inaczej wyniki kłamią |
| WebPageTest | film wczytywania, wybór lokalizacji i profilu sieci | kolejka w darmowym planie, dłuższy czas oczekiwania |
| GTmetrix | pomiar z wybranego serwera (np. Frankfurt) | darmowy plan ma limit testów na godzinę |
| Screaming Frog / Ahrefs Site Audit | crawl całej witryny: kody, duplikaty, canonicale, głębokość | ustaw throttling, by nie obciążyć serwera, i wyklucz koszyk |
Raport „Pokrycie” w Search Console to pierwsze miejsce, w którym widać problem, zanim zauważy go klient. Trzy statusy wracają najczęściej:
W PrestaShop za filtry odpowiada moduł fasetowy: każdy filtr ma ustawienie decydujące o tym, czy jego kombinacje mogą być indeksowane. Domyślne wartości często na to pozwalają, więc przy 40 kolorach i 10 rozmiarach indeks puchnie o tysiące adresów. W WooCommerce podobny efekt dają wtyczki filtrów – jeśli nie mają opcji noindex, trzeba dodać reguły w robots.txt i ustawić canonical na czystą kategorię. Wzorzec jest ten sam: noindex, follow plus canonical do wersji bazowej. Mechanikę filtrów w tym systemie opisuje dokumentacja PrestaShop dla deweloperów.
Sitemap: PrestaShop generuje ją dynamicznie i dzieli na pliki – sprawdź, czy nie zawiera adresów z parametrami i czy limit na plik nie ucina najnowszych produktów. W WooCommerce sitemapką zarządza wtyczka SEO; wyklucz z niej tagi, wewnętrzną wyszukiwarkę i produkty niedostępne. Popupy też mają znaczenie – jeśli okno ładuje treść pod osobnym adresem, tworzy kolejny duplikat. Podobny schemat porządkowania opisujemy w tekście o SEO technicznym i optymalizacji szybkości w Krasnobrodzie.
| Status w GSC | Co oznacza | Pierwszy krok |
|---|---|---|
| Zaindeksowane, ale nie przesłane | Adres w indeksie, brak w sitemapie | Sprawdź, czy nie duplikuje kategorii; dodaj do sitemap albo wycofaj |
| Odkryte – obecnie nieindeksowane | Google zna URL, ale go nie pobrało | Ogranicz parametry, popraw linkowanie wewnętrzne, zmniejsz liczbę adresów |
| Alternatywna strona z tagiem kanonicznym | Parametr wskazuje na wersję bazową | Zablokuj indeksację filtrów, zostaw canonical do czystej kategorii |
Kolejność poniżej to nasza praktyka: od największego zysku do najmniejszego.
Wartości, do których się zbliżamy: LCP poniżej 2,5 s, CLS poniżej 0,1, INP poniżej 200 ms – definicje i progi opisuje web.dev w artykule o Web Vitals. Jeśli sklep stoi na WooCommerce, kolejność tych prac zależy od liczby wtyczek w projekcie – rozkładamy ją we wdrożeniach i optymalizacji WooCommerce w Szczebrzeszynie.
| Metryka | Cel | Typowa przyczyna problemu |
|---|---|---|
| LCP | poniżej 2,5 s | Niezoptymalizowany baner hero, brak cache, wysoki TTFB |
| CLS | poniżej 0,1 | Brak width/height przy obrazach, późno wczytywane fonty |
| INP | poniżej 200 ms | Ciężki JavaScript, konflikt wtyczek |
Dane strukturalne to jedyny sposób, żeby powiedzieć Google wprost, czym jesteś i gdzie działasz. Dla sklepu nastawionego na Józefów i powiat otwocki układ jest zwykle taki:
Uwaga na aggregateRating: dodawaj tylko wtedy, gdy opinie są prawdziwe i widoczne na stronie. Pełną listę typów, które Google obsługuje w wynikach, znajdziesz w dokumentacji Google Search Central poświęconej danym strukturalnym.
Google Business Profile i NAP: nazwa, adres i telefon muszą być identyczne w wizytówce, na stronie i w katalogach branżowych. Telefon w jednym formacie, adres zapisany w ten sam sposób w każdym miejscu. Dane kontaktowe wpisz jako tekst, nie jako grafikę – bot ich nie odczyta. Warto uzupełnić kategorie, godziny i zdjęcia, bo to one decydują o tym, czy wizytówka w ogóle się pokaże.
Strony lokalne nie mogą być kopiuj-wklej. Jeśli masz osobne podstrony dla Józefowa i sąsiednich miejscowości, każda potrzebuje własnego tekstu, innych zdjęć i linkowania do konkretnych usług oraz realizacji. Skopiowany akapit z podmienioną nazwą miasta to najczęstszy powód, dla którego żadna z tych stron nie rankuje. Ten sam zestaw zasad dla innej lokalizacji rozpisujemy w tekście o SEO technicznym i optymalizacji szybkości – Szczebrzeszyn.
Walidacja: Rich Results Test sprawdza, czy Google w ogóle obsługuje dany typ, Schema Markup Validator – poprawność składni. Wyniki wracają też w GSC w sekcji „Ulepszenia”.
Platforma dyktuje kolejność działań. W PrestaShopie pierwszy krok to nie meta tagi, a liczba zapytań SQL na stronie kategorii i produktu. Każdy aktywny moduł dopina własne hooki; moduły od bloga, komentarzy czy bannerów potrafią dorzucić kilkanaście zapytań na każde wejście. Zacznij od wyłączenia tego, czego nie używasz, i zmierz TTFB przed zmianą oraz po niej.
Drugi element to kompilacja szablonów. PrestaShop ma w panelu (Parametry zaawansowane → Wydajność) opcje kompilacji szablonu i cache. W trybie produkcyjnym wyłącz „Wymuś kompilację”, włącz cache szablonów i cache zapytań. Trzeci: baza MySQL — dodaj indeksy do kolumn filtrowanych, wyczyść tabele logów (np. ps_connections, ps_log) i włącz slow query log z long_query_time = 1, żeby zobaczyć, które zapytania realnie jedzą czas. SEO jest wbudowane w edycję produktu (meta title, description, URL), ale danych strukturalnych PrestaShop domyślnie nie generuje — potrzebny moduł. Szczegóły techniczne znajdziesz w dokumentacji dla deweloperów PrestaShop.
W WooCommerce meta tagi robi wtyczka (Rank Math, Yoast), nie sam WooCommerce — to pierwsza różnica. Druga: page builder. Elementor czy WPBakery dokładają własne CSS i JS do każdej podstrony, więc liczba requestów rośnie niezależnie od tego, jak lekki jest szablon. Trzecia: Redis Object Cache, konfigurowany przez wp-config.php i wtyczkę — odciąża bazę przy koszyku i panelu, ale nie zastąpi cache pełnostronicowego.
Wspólne pułapki. Tysiące wariantów: w PrestaShop kombinacje mnożą rekordy w tabelach atrybutów, w WooCommerce każda wariacja to wpis w postmeta. Niewolne query SQL — bez slow query logu zgadujesz. Brak cache dla zalogowanych: cache pełnostronicowy pomija zalogowanych i koszyk, więc klient z kontem dostaje wolne, „zimne” renderowanie.
Naprawiać czy migrować? W audycie patrzymy na cztery liczby: TTFB kategorii, liczbę zapytań SQL, liczbę modułów lub wtyczek i wersję PHP. Jeśli kod jest forkowany i nie ma repozytorium, migracja bywa tańsza niż rzeźbienie w legacy. Praktykę sklepową rozwijamy w materiale o wdrożeniach i optymalizacji WooCommerce w Krasnobrodzie.
| Element | PrestaShop | WooCommerce |
|---|---|---|
| Meta tagi produktu | Wbudowane w edycję produktu | Wtyczka SEO (Yoast, Rank Math) |
| Cache | Cache szablonów i zapytań w Parametrach zaawansowanych | Cache pełnostronicowy + Redis Object Cache |
| Bloat | Nieużywane moduły i hooki | Page buildery dokładające CSS i JS |
| Warianty | Kombinacje w tabelach atrybutów | Wariacje jako wpisy w postmeta |
| Diagnostyka | Slow query log MySQL | Query Monitor + slow query log |
Checklistę traktuj jak listę zadań, nie jak artykuł do przeczytania. Cztery grupy, każda z innym narzędziem.
Indeksacja. Sprawdź robots.txt (jeden plik, bez blokowania CSS i JS), wygeneruj sitemap.xml i wgraj ją w Google Search Console. Przejdź po 20 najważniejszych URL-ach i sprawdź, czy nie mają noindex. Ustaw canonical na wariantach produktów i na paginacji kategorii — wskazuj na wersję główną, nie na adres z parametrem. Z logów serwera wyciągnij 404 i zrób przekierowania 301.
Wydajność. Zmierz TTFB, LCP i CLS — punkt odniesienia i progi opisuje web.dev w materiałach o Web Vitals. Włącz kompresję Brotli, nagłówki cache dla statyków (rok dla plików z hashem), konwertuj obrazy do WebP, dodaj lazy loading poza pierwszym ekranem i usuń nieużywane skrypty.
Dane strukturalne. Product, Offer, BreadcrumbList, a przy firmie stacjonarnej LocalBusiness. Waliduj w testach Google — lista obsługiwanych typów jest w dokumentacji danych strukturalnych Search Central.
Lokalne SEO. Jeden spójny NAP (nazwa, adres, telefon), wizytówka Google, podstrony lokalne z realną treścią, nie kopiuj-wklej z sąsiedniej miejscowości. Tytuły z lokalizacją tylko tam, gdzie mają sens.
Priorytety: w pierwszym tygodniu — noindex, sitemap, TTFB, obrazy, 301. W drugim miesiącu — dane strukturalne, warianty, cache obiektowy, porządki w treści.
Co zrobisz sam: Search Console, PageSpeed Insights, kompresja obrazów, wizytówka Google. Kiedy wzywać zespół: praca w plikach motywu, migracje i indeksy w bazie, konfiguracja Redis, masowe przekierowania. Sąsiednie ujęcie tej samej checklisty znajdziesz w tekście o SEO technicznym i optymalizacji szybkości w Zwierzyńcu.
| Priorytet | Zadania | Kto |
|---|---|---|
| Tydzień 1 | robots.txt, sitemap, noindex, 404 → 301, obrazy, TTFB | Samodzielnie + deweloper przy TTFB |
| Tydzień 2–4 | canonical na wariantach i paginacji, kompresja, nagłówki cache | Deweloper |
| Miesiąc 2 | dane strukturalne, cache obiektowy, porządki w bazie i treści | Deweloper + treść po Twojej stronie |
| Na stałe | monitoring Search Console i Core Web Vitals raz w miesiącu | Samodzielnie, po wdrożeniu |
Audyt techniczny to 2–5 dni roboczych. W tym czasie dostajesz pomiar TTFB, listę zapytań z slow query logu, liczbę requestów, stan indeksacji w Search Console i listę błędów z priorytetami. Nie sprzedajemy audytu jako 40-stronicowego PDF-a bez wniosków.
Wdrożenie poprawek: 2–6 tygodni. Dolna granica to sklep, w którym trzeba poprawić nagłówki, obrazy, przekierowania i cache. Górna — warianty produktów, refaktor modułów, migracja danych i porządki w bazie.
Nie mamy cennika „z sufitu”. Rozliczamy się godzinowo, więc koszt = liczba godzin × stawka, a stawkę potwierdzamy przed startem prac. Orientacyjnie: audyt to kilkanaście do kilkudziesięciu godzin, wdrożenie od kilkudziesięciu do ponad stu godzin przy dużym zakresie. Jeśli audyt zajmie 20 godzin, a poprawki 60, przy stawce 150 zł netto za godzinę mówimy o 3 000 zł netto za audyt i 9 000 zł netto za wdrożenie. To przykład rachunku, nie oferta — Twoje liczby zależą od stanu sklepu, liczby wtyczek i jakości kodu.
Kiedy trwa dłużej: hosting współdzielony bez SSH i bez możliwości zmiany php.ini, legacy kod bez repozytorium, brak dostępu do plików i bazy, brak środowiska testowego. Każdy z tych punktów potrafi dodać tydzień. Dlatego na starcie prosimy o dostępy: FTP lub SFTP, panel hostingu, Search Console i kopię bazy.
Praca bezpośrednio z deweloperem skraca ścieżkę decyzyjną: jedna rozmowa, jedno ustalenie, jedna osoba odpowiada za efekt. Bez pośrednika nie ma też przekłamań w opisie problemu — to, co widzimy w narzędziach, trafia do wyceny bez tłumaczenia na język handlowy. Ten sam model pracy opisujemy przy wdrożeniach WooCommerce w Szczebrzeszynie.
| Etap | Czas | Co dostajesz |
|---|---|---|
| Audyt | 2–5 dni roboczych | Pomiary, lista błędów, priorytety, szacunek godzin |
| Szybkie poprawki | 3–5 dni | Nagłówki, obrazy, przekierowania, indeksacja |
| Wdrożenie pełne | 2–6 tygodni | Refaktor modułów, warianty, cache, baza |
| Monitoring | 1–2 h miesięcznie | Przegląd Search Console i Core Web Vitals |
Ocenianie szybkości po jednym teście Lighthouse na laptopie
Jak wykryć: Wynik 95+ w Lighthouse, a w Search Console raport Core Web Vitals nadal pokazuje adresy w grupie „Do poprawy”.
Jak naprawić: Lighthouse to dane laboratoryjne z jednego urządzenia. Patrz na dane terenowe z CrUX w PageSpeed Insights i w GSC – tam ocena liczona jest z realnych wizyt i to na 75. percentylu.
Lazy loading na obrazie LCP, czyli najczęściej na banerze hero albo zdjęciu głównym produktu
Jak wykryć: W DevTools → Elements sprawdź atrybut loading="lazy" na pierwszym dużym obrazie; w audycie LCP w PageSpeed Insights zobacz, który element jest największy.
Jak naprawić: Usuń loading="lazy" z obrazu widocznego nad zakładką, dodaj fetchpriority="high", a jeśli obraz jest tłem w CSS – wczytaj go preloadem.
Brak width i height na obrazach oraz na banerach wstawianych z szablonu
Jak wykryć: CLS powyżej 0,1 w GSC albo świecenie na czerwono obszarów przesunięcia w DevTools → Rendering → Layout Shift Regions.
Jak naprawić: Ustaw width/height lub aspect-ratio w CSS, żeby przeglądarka zarezerwowała miejsce przed wczytaniem grafiki.
Wpuszczenie filtrów fasetowych do indeksu Google
Jak wykryć: W GSC → Indeksowanie → Strony sprawdź liczbę adresów z parametrami ?orderby=, ?filter=, ?q= i porównaj ją z liczbą produktów w sklepie.
Jak naprawić: Disallow w robots.txt dla parametrów, noindex,follow na stronach wyników filtrowania i canonical do bazowej wersji kategorii.
Canonical wskazujący na inny wariant parametru niż ten, który widzi użytkownik
Jak wykryć: Screaming Frog → kolumna Canonical; osobno raport GSC „Zaindeksowane, ale nie przesłane”, gdzie widać adresy z parametrami.
Jak naprawić: Canonical zawsze na czysty adres kategorii lub produktu, bez parametrów sortowania, filtrowania i śledzenia kampanii.
Zmiana pięciu rzeczy naraz i brak punktu odniesienia
Jak wykryć: Nie masz zapisanych wyników sprzed wdrożenia, więc po miesiącu nie wiesz, co realnie pomogło, a co zaszkodziło.
Jak naprawić: Zrób trzy pomiary tego samego dnia przed zmianami: TTFB, LCP, liczbę zaindeksowanych adresów. Potem zmieniaj jedną rzecz na raz i porównuj.
Zacznij od pomiaru, nie od wtyczki: trzy testy tego samego dnia, raport Core Web Vitals w GSC i lista zaindeksowanych adresów. Potem uporządkuj indeksację (canonical, robots.txt, filtry fasetowe), a dopiero na końcu bierz się za obraz LCP i cache. Każdą zmianę rób pojedynczo i zapisuj wynik, bo inaczej po miesiącu nie będziesz wiedział, co zadziałało. Efektów terenowych nie oceniaj po jednym dniu – dane z CrUX potrzebują kilku tygodni.
Nie. Techniczne SEO usuwa przeszkody: pozwala Google zaindeksować właściwe adresy i szybciej je wyświetlić. Bez opisanych kategorii, sensownych zdjęć i linków z zewnątrz sklep z Józefowa nadal będzie przegrywał z konkurencją z Lublina czy Zamościa. To warunek konieczny, ale niewystarczający.
Spadek LCP w testach laboratoryjnych widzisz od razu po wdrożeniu. Dane terenowe w GSC aktualizują się z opóźnieniem, bo Google liczy je w oknie kilku tygodni – realnie trzeba poczekać kilka tygodni na stabilny obraz. Nie przypisuj potem całej zmiany ruchu jednemu wdrożeniu, bo równolegle działają też inne czynniki.
Google potwierdza, że sygnały związane z doświadczeniem strony są brane pod uwagę jako jeden z wielu czynników, a nie jako przełącznik pozycji. Dokumentacja Google Search Central opisuje to wprost. Skok z 3 s do 2 s nie przeskoczy konkurenta z mocniejszym profilem linków i lepszą treścią.
Nie wyłączaj – klienci ich używają i skracają sobie drogę do produktu. Chodzi o to, żeby nie trafiały do indeksu jako osobne strony: robots.txt, noindex,follow i canonical na wersję bazową kategorii. W PrestaShop dodatkowo sprawdź ustawienia modułu nawigacji fasetowej i generowanie adresów przyjaznych.
Dla sklepu z kilkudziesięcioma produktami i małym ruchem często tak – pod warunkiem że jest OPCache, aktualne PHP i dysk SSD. Gdy rośnie liczba SKU albo dochodzą tysiące wizyt dziennie, shared hosting zaczyna generować TTFB liczone w sekundach. Wtedy VPS z SSD i cache obiektów (np. Redis) daje więcej niż kolejna wtyczka optymalizacyjna.
Od indeksacji i jednego obrazu. Najpierw sprawdź w GSC, czy Google widzi właściwe adresy i czy nie indeksuje filtrów. Potem zajmij się elementem LCP – najczęściej banerem hero lub zdjęciem produktu. Cache, CDN i dane strukturalne zostaw na później, bo bez uporządkowanej indeksacji ich efekt będzie trudny do zmierzenia.
Jeśli chcesz punkt wyjścia dla swojego sklepu, zróbmy audyt techniczny: indeksacja, Core Web Vitals i lista zadań w kolejności od największego wpływu. Napisz do DropDigital i podaj adres strony – odpowiemy, co da się poprawić w pierwszym tygodniu.