SEO techniczne i optymalizacja szybkości to fundamenty, na których stoi widoczność w Google — niezależnie od tego, ile tekstów opublikujesz. Jeśli kategoria ma noindex, produktów nie ma w sitemapie, a strona ładuje się 6 sekund na telefonie, żadna kampania treściowa tego nie nadrobi. W tym artykule porządkujemy cztery obszary: indeksację, architekturę i linkowanie wewnętrzne, wydajność (Core Web Vitals) oraz dane strukturalne i canonicale. Pokazujemy też, jak w 60 minut sprawdzić własny sklep bez budżetu i w jakiej kolejności wdrażać poprawki. Piszemy z perspektywy firm z Bydgoszczy i regionu, ale sama procedura nie zależy od miasta — zależy od tego, co faktycznie blokuje roboty i użytkowników.
SEO techniczne to decyzje, które przesądzają, czy Google w ogóle widzi Twoje strony i w jakim stanie je ocenia. Nie jest to pisanie tekstów ani zdobywanie linków. Dzielimy je na cztery obszary, a każdy ma inne objawy i inne narzędzia do sprawdzenia.
noindex wypada z wyników, choć ma 300 wejść miesięcznie z kampanii.SEO techniczne to praca na tych czterech warstwach, nie na treści. Google opisuje wydajność jako jeden z sygnałów branych pod uwagę przy ocenie strony — szczegóły znajdziesz w dokumentacji Core Web Vitals.
Optymalizacja szybkości to proces, nie jednorazowa akcja. Kolejność jest zawsze taka sama: pomiar przed (PageSpeed Insights na mobile, dane z raportu Core Web Vitals w Search Console), wdrożenie zmian, pomiar po na tym samym adresie i tej samej wersji urządzenia, porównanie liczb. Bez pomiaru przed nie odróżnisz poprawy od zwykłego wahnięcia.
Dla małej i średniej firmy SEO techniczne ma sens, gdy sklep już sprzedaje i masz ruch, którego nie wykorzystujesz: kategorie nie pojawiają się w Google, produkty znikają z wyników, telefon ładuje stronę o kilka sekund dłużej niż komputer. Kolejność bywa jednak inna, gdy na mobile nie da się złożyć zamówienia — formularz rozciągnięty na trzy ekrany, koszt dostawy widoczny dopiero przy płatności, brak zdjęć i wymiarów. Wtedy najpierw naprawiasz konwersję, bo szybsza strona z tym samym problemem nadal nie sprzeda. Podobnie, gdy nie masz jeszcze żadnego ruchu — szybkość niczego nie pomnoży przez zero.
Ten przegląd wykonasz sam, bez płatnych narzędzi i bez dostępu do serwera. Zapisz godzinę i trzymaj się kolejności.
twojadomena.pl/robots.txt. Szukaj Disallow: / obejmującego cały sklep oraz blokad katalogów /modules/ i /themes/ — zablokowanie CSS i JS utrudnia ocenę wyglądu strony.?orderby= to sygnał, że filtry nie są zamykane na canonicalu ani w robots.txt.site:twojadomena.pl, a potem site:twojadomena.pl/nazwa-kategorii. Brak kategorii w wynikach przy istniejącej sitemapie to czerwona flaga.meta name="robots", a w DevTools → Network status HTTP i nagłówek X-Robots-Tag. Oczekujesz kodu 200, nie 301, 302 czy 404.Cache-Control: max-age oraz Content-Encoding: br albo gzip.| Sygnał alarmowy | Gdzie go zobaczysz | Pierwszy krok |
|---|---|---|
| noindex na kategorii | kod źródłowy, nagłówek X-Robots-Tag | usunięcie tagu z szablonu kategorii |
| tysiące URL-i z parametrami | sitemap.xml, raport Strony w GSC | canonical i reguły w robots.txt |
| łańcuch przekierowań powyżej 2 skoków | DevTools → Network | poprawa linków wewnętrznych i reguł przekierowań |
| brak kompresji i cache | DevTools → Network → Headers | włączenie Brotli i nagłówków Cache-Control |
W PrestaShop część tych ustawień siedzi w panelu w sekcji wydajności (kompresja, cache, łączenie plików), a sposób ich działania opisuje dokumentacja dla deweloperów PrestaShop. Jeśli chcesz najpierw zrozumieć cały zakres prac, przejrzyj przewodnik po SEO technicznym i optymalizacji szybkości sklepu — dopiero potem zamawiaj wycenę.
Trzy metryki, trzy progi. Wynik poniżej pierwszego progu Google uznaje za dobry.
| Metryka | Dobry wynik | Wymaga poprawy | Zły wynik | Co najczęściej zawodzi |
|---|---|---|---|---|
| LCP | do 2,5 s | 2,5–4,0 s | powyżej 4,0 s | zdjęcie hero bez preload, wysoki TTFB |
| INP | do 200 ms | 200–500 ms | powyżej 500 ms | skrypty firm trzecich, ciężki JavaScript |
| CLS | do 0,1 | 0,1–0,25 | powyżej 0,25 | baner cookie, dynamiczne ceny, podmiana fontu |
Ważniejsze niż same liczby jest źródło danych. Lighthouse i PageSpeed Insights mierzą w warunkach laboratoryjnych: jedno urządzenie, sztucznie spowolniona sieć, jeden przebieg. Dane polowe (CrUX, okno 28 dni, 75. percentyl) pokazują, co realnie spotyka Twoich klientów, i to one trafiają do raportu w Search Console. Praktyczna zasada: diagnozuj w Lighthouse, decyduj na danych polowych. Metryki i sposób ich liczenia opisuje web.dev – Web Vitals.
Najczęstsze przyczyny słabego LCP w sklepach: zdjęcie hero bez rel="preload" i bez fetchpriority="high" (przeglądarka odkrywa je dopiero po CSS), loading="lazy" na pierwszym slajdzie — klasyczny błąd wtyczek do lazy loadingu, brak formatów WebP i AVIF (to samo zdjęcie waży 400 KB zamiast 90 KB) oraz wysoki TTFB: hosting współdzielony bez cache stron i bez OPcache w PHP.
Wysoki CLS pochodzi prawie zawsze z trzech miejsc. Baner cookie wstrzykiwany JavaScriptem po załadowaniu strony przesuwa hero i przyciski w dół. Dynamiczne ceny, stany magazynowe albo koszt dostawy wstawiane bez zarezerwowanego miejsca rozjeżdżają kartę produktu. Zmiana kroju pisma bez font-display: swap i bez dobranego fallbacku powoduje przeskok tekstu. Poprawki są tanie: rezerwuj wysokość kontenera (min-height, aspect-ratio), pokazuj baner jako nakładkę, która nie zmienia układu. INP psują skrypty firm trzecich — piksele, czaty, wtyczki — bo każdy dokłada pracę do głównego wątku. Ten sam zestaw poprawek wdrażamy w sklepach w Bydgoszczy i regionie; podobny zakres prac opisaliśmy dla SEO technicznego i optymalizacji szybkości sklepu w Toruniu.
Typowy wynik audytu sklepu z regionu: 40 kategorii, 8 000 produktów i 190 000 adresów w indeksie Google. Winowajcą prawie zawsze jest nawigacja fasetowa. Sprawdź to w Search Console → Indeksowanie stron → „Zaindeksowane, mimo że nie są”, w darmowym Screaming Frog (limit 500 URL na wersję darmową) albo w logach serwera: jeśli Googlebot odbija 60% wizyt na adresach z parametrami typu ?q=, /filtry/ lub kombinacjami cech, masz problem.
Jak ciąć: zostaw indeksowalne strony z jedną cechą (np. rozmiar), a kombinacje dwóch i więcej blokuj w robots.txt lub oznaczaj noindex, follow. Uwaga na pułapkę: jeśli URL jest zablokowany w robots.txt, Google nie odczyta jego canonicala ani noindex — na jeden typ adresu wybierz jedno narzędzie.
Duplikację na wariantach produktu (?id_product_attribute=...) i parametrach sortowania (?orderby=price_desc) rozwiązuje reguła canonical do wersji bazowej plus wpisy w robots.txt dla sortowania i parametrów sesji. Kanibalizacja kategorii i tagów to najczęściej dwa adresy na ten sam temat: /tag/nike i /buty-do-biegania. Tagi bez ruchu — noindex albo 301 do kategorii.
Paginacja: nie dawaj noindex na stronach 2, 3 i 4. Google przestaje wtedy odkrywać produkty z końca listy, a to właśnie tam leży długi ogon. Puste strony wyników po filtrach (0 produktów) generują soft 404 — jeśli masz ich 3 000, marnujesz budżet indeksowania.
Po migracji platformy sprawdź trzy rzeczy: czy stare adresy zwracają 301 bez łańcuchów (A→B→C to strata), czy nie ma przekierowań 301→301→404 oraz czy wróciły dane strukturalne Product i Offer. Ich brak kosztuje gwiazdki, cenę i dostępność w wynikach. Typowe problemy i kolejność wdrożeń opisujemy szerzej w materiale o SEO technicznym, a analogiczne przypadki z rynku zachodniopomorskiego — w artykule o SEO technicznym i optymalizacji szybkości dla firm ze Szczecina.
| Problem | Jak wykryć | Pierwszy krok |
|---|---|---|
| Nawigacja fasetowa | Search Console: „Zaindeksowane, mimo że nie są” + logi | Disallow/`noindex` dla kombinacji, canonical do kategorii |
| Warianty i sortowanie | Lista URL-i z `?orderby=` w GSC | Canonical do bazowego URL + reguła w robots.txt |
| Tagi = kategoria | Raport Zapytania: dwa URL-e na to samo hasło | 301 do kategorii lub `noindex` na tagach |
| Pusta strona filtrów | Screaming Frog: „0 products found” | 301 do kategorii nadrzędnej, nie 200 |
| Migracja | Kolumnа „Last crawled” w GSC dla starych URL-i | 301 bez łańcuchów + odtworzenie schema |
Kolejność wdrożeń ma większe znaczenie niż narzędzie. Zaczynasz od rzeczy, które dają 1–2 s na telefonie za kilka godzin pracy, kończysz na infrastrukturze.
Poziom 1 (1–2 dni, bez zmiany hostingu). Brotli zamiast gzip (mod_brotli w Apache, brotli on; w nginx), nagłówek Cache-Control: public, max-age=31536000, immutable dla plików z hashem w nazwie, CDN, konwersja JPEG/PNG do WebP lub AVIF, loading="lazy" dla obrazów poniżej pierwszego ekranu. Pułapka: obraz LCP musi mieć fetchpriority="high" i żadnego lazy loadingu — dodanie tam lazy loadingu pogarsza wynik o kilkaset milisekund.
Poziom 2 (3–5 dni, wymaga pracy z konfiguracją). Cache serwerowy pełnych stron dla niezalogowanych, cache obiektowy (Redis/Memcached), łączenie i odraczanie JS przez defer, audyt wtyczek i trackerów. 12 pikseli w tag managerze plus 5 wtyczek marketingowych to realnie 1–1,5 s na telefonie w 4G.
Poziom 3 (1–3 tygodnie, wymaga decyzji budżetowej). Slow query log w MySQL, brakujące indeksy na kolumnach filtrowanych (product_id, category_id), przepisanie zapytań listingu, dostrojenie PHP-FPM: pm.max_children liczone z RAM i średniego zużycia procesu — 8 GB RAM przy 60 MB na proces to około 130 workerów, ale zostaw bufor 20% na bazę i cron. Na końcu VPS z gwarantowanym RAM, nie hosting współdzielony.
Pomiar: ten sam test, ta sama pora dnia, 3 przebiegi, liczy się mediana. Lighthouse w oknie incognito z identycznym throttlingiem, WebPageTest do zrzutu klatkowego. Zapisuj LCP, INP, CLS, TTFB, liczbę zapytań i wagę strony w KB. Definicje progów masz w dokumentacji Web Vitals, a szerszy plan działania — w naszym przewodniku po SEO technicznym i optymalizacji szybkości sklepu.
| Poziom | Zakres | Nakład | Realny efekt |
|---|---|---|---|
| 1 | Brotli, cache przeglądarki, CDN, WebP/AVIF, lazy loading | 1–2 dni | Największy zysk przy małym koszcie |
| 2 | Cache stron i obiektowy, defer JS, usuwanie wtyczek | 3–5 dni | Powtarzalny spadek TTFB |
| 3 | Indeksy, zapytania, PHP-FPM, VPS | 1–3 tygodnie | Stabilność przy ruchu i kampaniach |
PrestaShop. Punkt pierwszy to Zaawansowane parametry → Wydajność: Kompilacja szablonów: nigdy nie kompiluj, włączony cache Smarty i cache katalogu. Włączaj pojedynczo opcje CCC (Combine, Compress, Cache) dla JS i CSS — hurtowo potrafią zepsuć koszyk i modale. Następnie przebuduj indeks wyszukiwania i użyj funkcji dodawania brakujących indeksów. Trzeci element to kolejność i waga modułów na stronie produktu (sekcje displayProductAdditionalInfo, displayProductExtraContent): moduł robiący 5 zapytań na produkt × 30 produktów w kategorii to 150 zapytań na jedno wejście. Dokumentacja deweloperska jest dostępna w PrestaShop Developer Documentation.
WooCommerce. Zacznij od liczby wtyczek — powyżej 25–30 zaczyna się problem, bo każda dorzuca zapytania i skrypty. Sprawdź zapytania do wp_postmeta: przy 50 000 zamówień tabela rośnie do milionów wierszy, a JOIN-y po meta_key bez indeksu to główna przyczyna wolnych listingów. Włącz HPOS (WooCommerce → Ustawienia → Zaawansowane → Funkcje), żeby zamówienia trafiły do dedykowanych tabel. Wyłącz WP-Cron (DISABLE_WP_CRON) i ustaw prawdziwy cron serwera co 5 minut — WP-Cron odpala się przy wizycie i przy małym ruchu zadania się nie wykonują. Dołóż cache obiektowy Redis z plikiem object-cache.php i sprawdź autoload w wp_options (powyżej 1 MB to sygnał do sprzątania).
Własny moduł czy płatne rozszerzenie? Jeśli potrzebujesz jednej funkcji, a rozszerzenie ładuje 4 skrypty na całym froncie i tworzy 30 tabel — własna implementacja na 100–150 linii jest tańsza w utrzymaniu. Jeśli chodzi o płatności, faktury czy integracje kurierskie, nie pisz tego sam: koszt utrzymania i aktualizacji przewyższy licencję. Podobne wdrożenia w sklepach z regionu opisujemy w materiale o SEO technicznym i optymalizacji szybkości sklepu w Toruniu.
| Obszar | PrestaShop | WooCommerce |
|---|---|---|
| Cache | Smarty + cache katalogu | Cache obiektowy Redis |
| Dane w bazie | Indeks wyszukiwania, brakujące indeksy | `wp_postmeta`, HPOS, autoload `wp_options` |
| Zadania w tle | Cron modułów | WP-Cron → cron systemowy co 5 min |
| Front | CCC, kolejność modułów | Liczba wtyczek, defer skryptów |
Nie ma jednej ceny za SEO techniczne, bo nie ma dwóch takich samych sklepów. Uczciwiej jest rozliczać pracę w godzinach. Realne przedziały dla wdrożenia w PrestaShop lub WooCommerce wyglądają tak: audyt techniczny 12–18 godzin, standardowe wdrożenie poprawek 30–60 godzin, optymalizacja głęboka — przebudowa linkowania wewnętrznego i szablonów, konsolidacja duplikatów, praca nad LCP i INP — 80–150 godzin i więcej. Osobno wycenia się migracje. Przeniesienie sklepu, zmiana domeny, przejście na HTTPS i mapa przekierowań 301 to zwykle 10–25 godzin.
Co konkretnie przesuwa liczbę godzin w górę:
Ważne rozróżnienie: jednorazowe wdrożenie kończy się raportem i listą poprawek. Miesięczna opieka techniczna, typowo 4–10 godzin, to pilnowanie indeksacji po aktualizacjach wtyczek i szablonu, przegląd błędów w Search Console, monitoring Core Web Vitals po zmianach treści i wyłapywanie nowych duplikatów, gdy ktoś doda kategorię albo wariant produktu. Bez tego wiele wdrożeń rozjeżdża się w 3–6 miesięcy, bo kolejna aktualizacja przywraca stary skrypt albo blokuje część zasobów w robots.txt. Orientacyjne widełki cenowe SEO technicznego są pochodną tych samych zmiennych: skali sklepu, stanu serwera i zakresu prac. Metodykę wskaźników, które potem raportujemy, opisuje dokumentacja Core Web Vitals w Google Search Central.
| Zakres prac | Typowy czas | Co zawiera |
|---|---|---|
| Audyt techniczny | 12–18 h | Crawling, indeksacja, duplikaty, canonicale, sitemap, robots.txt, analiza Core Web Vitals |
| Standardowe wdrożenie poprawek | 30–60 h | Poprawki meta, canonicali, przekierowań, danych strukturalnych, kompresja obrazów, cache |
| Optymalizacja głęboka | 80–150 h i więcej | Przebudowa linkowania wewnętrznego, konsolidacja duplikatów, refaktor szablonu pod LCP/INP |
| Migracja / zmiana domeny | 10–25 h | Przeniesienie sklepu, HTTPS, mapa 301, weryfikacja po starcie |
| Opieka techniczna (miesięcznie) | 4–10 h | Monitoring indeksacji, kontrola po aktualizacjach, regresje, nowe duplikaty |
Zanim cokolwiek zmienisz, zapisz baseline. Bez niego nie udowodnisz, że wdrożenie cokolwiek dało — ani sobie, ani wykonawcy.
Potem kontrola w trzech punktach. Po 7 dniach: czy nowe adresy wchodzą do indeksu i czy nie pojawiły się błędy 5xx lub 404. Po 30 dniach: liczba zaindeksowanych wartościowych adresów, liczba wpisów „wykryta, ale obecnie niezaindeksowana”, wykres Core Web Vitals dla telefonów. Po 90 dniach: pozycje i ruch — wcześniej dane są zbyt szumiące, bo Google przelicza wskaźniki w oknach 28-dniowych.
Za sukces uznaj: spadek liczby błędów pokrycia o co najmniej połowę, wzrost liczby zaindeksowanych stron docelowych (nie tagów ani stron paginacji), LCP dla głównych szablonów poniżej 2,5 s na telefonie i stabilny albo rosnący ruch organiczny. Kolejność działań i pełny przewodnik po SEO technicznym i optymalizacji szybkości sklepu warto mieć pod ręką, gdy wdrażasz poprawki etapami.
Kiedy wyniki są mylące: sezonowość (listopad–grudzień w e-commerce), duża aktualizacja algorytmu w trakcie pomiaru oraz kampanie płatne, które podbijają ruch brandowy i sztucznie podnoszą ogólne wskaźniki w GA4. Dlatego zawsze rozdzielaj ruch organiczny od płatnego i brandowy od niebrandowego. Definicje i progi wskaźników znajdziesz w dokumentacji Web Vitals na web.dev.
| Kiedy mierzyć | Co sprawdzić | Sygnał, że działa |
|---|---|---|
| Przed zmianami | Core Web Vitals, GA4, Search Console — eksport i zapis daty | Masz punkt odniesienia |
| Po 7 dniach | Indeksowanie nowych adresów, błędy 5xx/404, sitemapa | Brak nowych błędów serwera |
| Po 30 dniach | Liczba zaindeksowanych URL-i, błędy pokrycia, CWV mobile | Mniej błędów, więcej wartościowych adresów w indeksie |
| Po 90 dniach | Pozycje, ruch organiczny niebrandowy, konwersje | Stabilny lub rosnący ruch bez spadków pozycji |
Na rozmowie zadaj cztery pytania i zapisz odpowiedzi. Pierwsze: kto fizycznie wdraża poprawki — osoba, z którą rozmawiam, czy podwykonawca? Jeśli podwykonawca, ustal, kto odpowiada za efekt i testy po wdrożeniu. Drugie: czy dostanę raport „przed i po” z konkretnymi adresami, wartościami LCP, INP i CLS oraz listą zmian w plikach? Bez tego nie zweryfikujesz pracy. Trzecie: co się dzieje po wdrożeniu — ile tygodni wsparcia jest w cenie i co obejmuje: naprawę regresji, poprawki po aktualizacji wtyczek, monitoring indeksacji. Czwarte: kto ma dostęp do Search Console, GA4, panelu hostingu i rejestratora domeny? Zasada jest prosta: dostępy zostają u Ciebie, wykonawca dostaje uprawnienia, nie własność.
Czy brak lokalizacji w Bydgoszczy ma znaczenie? Czasem tak. Przy migracji hostingu, pracach na serwerze klienta, szkoleniu zespołu albo gdy sklep ma nietypową konfigurację i potrzebny jest dzień na miejscu — wtedy dojazd, np. przy zleceniu na SEO techniczne i optymalizację szybkości sklepu w Toruniu, to koszt, który warto wpisać w ofertę. W pozostałych przypadkach: audyt, optymalizacja szablonu, dane strukturalne, kanibalizacja zapytań — praca odbywa się zdalnie i lokalizacja nie zmienia jakości. Ważniejsza jest specjalizacja: czy wykonawca robił już PrestaShop 1.7/8 albo WooCommerce z wielojęzycznością i filtrami.
Czerwone flagi, po których warto zakończyć rozmowę: gwarancja TOP3 na konkretne frazy, brak dostępu do własnego panelu i domeny po zakończeniu współpracy, brak jakiegokolwiek okresu wsparcia po wdrożeniu oraz oferta, w której nie pada ani jedno pytanie o Twój hosting, liczbę wtyczek i liczbę produktów. Zakres usług i przykłady wdrożeń znajdziesz w sekcji SEO techniczne.
| Pytanie na rozmowie | Dobra odpowiedź | Czerwona flaga |
|---|---|---|
| Kto wdraża poprawki? | Konkretna osoba, znany zakres i odpowiedzialność | „Zajmie się tym zespół”, brak nazwiska i zakresu |
| Czy będzie raport przed/po? | Tak, z adresami i wartościami LCP/INP/CLS | Tylko ogólne PDF-y bez liczb |
| Co po wdrożeniu? | Zdefiniowany okres wsparcia i zakres napraw | Wdrożenie i cisza |
| Kto kontroluje dostępy? | Klient — własność paneli i domeny zostaje u niego | Wykonawca zakłada konta na siebie |
Noindex zostawiony na kategorii po migracji albo włączony przypadkiem przez wtyczkę SEO. Sklep wygląda dobrze, ale zniknął z wyników.
Jak wykryć: Sprawdź podgląd kodu strony (Ctrl+U) i poszukaj w sekcji head wpisu meta robots. Dodatkowo w DevTools → Network sprawdź nagłówek X-Robots-Tag w odpowiedzi serwera. Raport pokrycia w Search Console pokaże grupę Wykluczone przez tag noindex.
Jak naprawić: Zdejmij noindex z szablonów kategorii i produktów, ustaw reguły globalnie w wtyczce SEO, a nie per strona. Po zmianie zgłoś kluczowe adresy do ponownego zindeksowania i sprawdź efekt po kilku dniach.
Optymalizacja szybkości bez pomiaru przed zmianami. Po miesiącu pracy nikt nie wie, czy było 4,2 s czy 6 s i czy cokolwiek się poprawiło.
Jak wykryć: Zapytaj wykonawcę o zapisane wyniki sprzed wdrożenia: LCP, INP, CLS, TTFB, rozmiar strony w MB. Brak takich zapisów oznacza, że efektu nie da się zweryfikować.
Jak naprawić: Ustal punkt odniesienia przed pierwszą zmianą: ten sam test, ta sama pora dnia, 3 przebiegi. Zapisuj wyniki w arkuszu razem z datą i opisem wdrożonej zmiany.
Obraz hero na stronie głównej i w kategorii ładowany z atrybutem lazy loading. To najczęstsza przyczyna słabego LCP w sklepach.
Jak wykryć: W DevTools → Network sprawdź, czy główny obraz ma loading=lazy. W PageSpeed Insights zobacz, który element jest wskazywany jako LCP i kiedy się pojawia.
Jak naprawić: Usuń lazy loading z obrazów widocznych od razu po wejściu, dodaj do nich fetchpriority=high i podaj jawne wymiary (szerokość i wysokość), żeby przeglądarka mogła zarezerwować miejsce.
Niekontrolowane filtry i nawigacja fasetowa. Sklep z 300 produktami ma 40 tysięcy adresów w indeksie, w większości pustych lub zdublowanych.
Jak wykryć: Wpisz w Google site:domena.pl inurl:? i przejrzyj wyniki. Sprawdź też w Search Console, ile adresów z parametrami typy ?sort=, ?page=, ?filter= Google faktycznie zaindeksował.
Jak naprawić: Ustal jedną politykę: kombinacje filtrów blokuj w robots.txt, parametr sortowania obsłuż canonicalem do wersji bazowej, puste wyniki filtrowania oznacz noindex. Sprawdź, czy linki do filtrów nie są w stałej nawigacji.
Łańcuchy przekierowań po zmianie platformy. Stary adres prowadzi do adresu pośredniego, ten do kolejnego, a docelowa strona ładuje się dopiero po trzech skokach.
Jak wykryć: Weź kilkanaście starych adresów z raportu pokrycia i z linków przychodzących, a następnie prześledź kolejne nagłówki 3xx narzędziem do sprawdzania przekierowań. Policz, ile skoków dzieli start od celu.
Jak naprawić: Spłaszcz każdy łańcuch do jednego przekierowania 301 prowadzącego bezpośrednio na docelowy adres. Nowy adres powinien zgadzać się z tym, który jest w sitemapie i w linkowaniu wewnętrznym.
Kilka wtyczek cache i optymalizacyjnych włączonych jednocześnie. Efekt jest odwrotny do zamierzonego: konflikty, zdublowane pliki CSS, losowe wyniki TTFB.
Jak wykryć: Porównaj czas odpowiedzi serwera w trzech kolejnych testach. Jeśli TTFB skacze z 300 ms do 1,5 s bez wzrostu ruchu, prawdopodobnie warstwy cache się nakładają. Zajrzyj też do listy aktywnych wtyczek.
Jak naprawić: Zostaw jedną warstwę cache po stronie serwera i jedną po stronie przeglądarki. Wtyczki, które nie mają jasno określonej roli, wyłącz i zmierz różnicę przed ponownym włączeniem.
SEO techniczne to nie treści, a fundamenty: indeksacja, architektura, wydajność i canonicale. Zanim wydasz pieniądze na optymalizację, sprawdź w 60 minut to, co najczęściej blokuje widoczność — noindex, adresy z parametrami i łańcuchy przekierowań. Szybkość traktuj jako proces z pomiarem przed i po, nie jako jednorazową akcję. Zacznij od najtańszych zmian: kompresji, cache, formatów obrazów i usunięcia zbędnych skryptów.
Same fundamenty są identyczne w każdym mieście: indeksacja, architektura, wydajność, canonicale i dane strukturalne. Różnice pojawiają się dopiero na poziomie konkurencji w wynikach lokalnych i tego, jak mocno obsadzone są konkretne frazy w regionie. Nie zaczynaj od optymalizacji pod miasto, jeśli roboty Google nie potrafią poprawnie zaindeksować Twoich kategorii.
Nie. Każda aktualizacja wtyczki, zmiana szablonu, nowy skrypt śledzący czy kampania reklamowa może pogorszyć wynik, który wcześniej udało się wypracować. Dlatego sensowna optymalizacja ma wbudowany pomiar: punkt odniesienia, wdrożenie zmiany i kontrolę po tygodniu oraz po miesiącu. Bez tego wracasz do punktu wyjścia przy pierwszej większej zmianie na stronie.
Zwykle nie jako pierwszy krok. Jeśli użytkownik nie potrafi dodać produktu do koszyka, szybsze ładowanie samo w sobie nie zwiększy sprzedaży. Najpierw napraw ścieżkę zakupową na mobile, potem inwestuj w wydajność i indeksację — inaczej płacisz za ruch, który i tak się rozmywa.
Nie w całości. PageSpeed Insights pokazuje zarówno wynik laboratoryjny, jak i dane od rzeczywistych użytkowników (CrUX), i te dwie wartości często się rozjeżdżają. Wynik laboratoryjny jest przydatny do porównywania zmian, ale to dane polowe decydują o tym, jak Google ocenia doświadczenie strony. Sprawdzaj oba źródła i nie raportuj klientowi wyłącznie ładnej liczby z testu.
Nie, użytkownicy ich potrzebują i zabieranie im filtrów szkodzi sprzedaży. Problemem nie są filtry, a to, że Google indeksuje ich nieskończone kombinacje i traktuje jako osobne, często puste strony. Rozwiązaniem jest kontrola: blokada w robots.txt dla kombinacji parametrów, canonical do wersji bazowej, noindex dla pustych wyników. Jedną regułę stosuj konsekwentnie w całym sklepie.
Zmiany w kodzie widać od razu w testach laboratoryjnych. Dane polowe w Search Console aktualizują się z opóźnieniem liczonym w tygodniach, bo bazują na oknie ostatnich 28 dni. Realistycznie: pierwsze wyraźne przesunięcia w raporcie zobaczysz po dwóch, trzech tygodniach od wdrożenia, pod warunkiem że ruch na stronie jest wystarczający do zebrania próbki.
Nie ma jednej stawki, bo zakres zależy od liczby adresów, platformy, liczby szablonów i tego, czy trzeba naprawiać dane strukturalne. Uczciwa wycena powstaje po krótkim rozpoznaniu: platforma, przybliżona liczba URL-i, stan indeksacji i dostęp do Search Console. Jeśli ktoś podaje cenę przed zajrzeniem w projekt, to zgaduje.
Jeśli chcesz wiedzieć, co konkretnie blokuje Twój sklep, a nie dostać ogólną listę porad — napisz do nas. Przejrzymy indeksację i wydajność, a potem powiemy wprost, co warto naprawić najpierw.