SEO techniczne i optymalizacja szybkości — co to naprawdę znaczy

SEO techniczne to praca nad tym, jak robot Google odkrywa, rozumie i renderuje Twoje strony. Nie chodzi o treść ani o linki — chodzi o fundament, na którym jedno i drugie może w ogóle zadziałać. W praktyce to cztery obszary, które trzeba rozdzielić, bo każdy ma inne narzędzia i inne objawy awarii.

• Indeksacja — czy Google widzi Twoje adresy: robots.txt, meta robots, znaczniki canonical, sitemap.xml, kody odpowiedzi 200/301/404/5xx, obsługa parametrów filtrowania i paginacji.
• Architektura i linkowanie wewnętrzne — struktura kategorii, liczba kliknięć do produktu, powiązania produkt–kategoria–poradnik, unikalne opisy kategorii, obsługa stron z listami.
• Wydajność (Core Web Vitals) — LCP, INP, CLS oraz TTFB, kompresja Brotli/Gzip, cache przeglądarki i serwera, formaty obrazów WebP/AVIF, kolejność ładowania zasobów.
• Mobile-first — Google indeksuje wersję mobilną. Jeśli filtry, koszyk albo cennik działają tylko na desktopie, dla wyszukiwarki praktycznie nie istnieją.

Granica kompetencji jest ostra i warto ją ustalić w firmie. Deweloper odpowiada za kody odpowiedzi, canonicale, wydajność, dane strukturalne i szablon. Contentowiec — za tytuły, opisy, teksty kategorii i linkowanie wewnętrzne. Link building to trzeci, zupełnie osobny temat. Pusta kategoria z zerem znaków opisu to problem contentowy; SEO techniczne go nie naprawi, choć pokaże go w raporcie indeksowania. Jakość strony w oczach Google opisuje dokumentacja Google Search Central o Core Web Vitals.

Szybkość przekłada się na pieniądze. Każda dodatkowa sekunda ładowania to mierzalny spadek dokończonych koszyków — największy na telefonach i przy słabym zasięgu. Zamiast zgadywać, zacznij od pomiaru i kolejności działań opisanej w materiale SEO techniczne i optymalizacja szybkości w Lublinie.

Core Web Vitals w praktyce — progi, które musisz znać

Google ocenia trzy metryki, liczone na 75. percentylu realnych użytkowników z ostatnich 28 dni. To znaczy: 75% wizyt musi zmieścić się w progu, a nie „średnia” ani Twój telefon w biurze.

Metryka	Próg „dobry”	Co mierzy	Typowa przyczyna w sklepie
LCP	≤ 2,5 s	Czas do wyrenderowania największego elementu	Niekompresowany baner, brak WebP, wolny TTFB, brak cache
INP	≤ 200 ms	Opóźnienie reakcji na interakcję użytkownika	Filtry odświeżające całą listę, ciężkie skrypty, nadmiar wtyczek
CLS	≤ 0,1	Przesuwanie się układu podczas ładowania	Brak wymiarów obrazów, banery zgód, późno wczytywane fonty

Dane dzielą się na polowe i labowe. Polowe to CrUX i raport Core Web Vitals w Search Console — to one wpływają na ocenę, bo pochodzą od prawdziwych użytkowników. Labowe to Lighthouse i PageSpeed Insights: pokazują warunki kontrolowane, przydają się do diagnozy, ale nie są wyrocznią. Rozjazd między nimi to norma, nie błąd.

INP zastąpił FID w marcu 2024 roku i to duża zmiana dla sklepów. FID mierzył tylko opóźnienie przed pierwszym zdarzeniem — praktycznie zawsze wychodził dobrze. INP mierzy całą interakcję: od kliknięcia, przez wykonanie skryptu, po odmalowanie ekranu. Dlatego sklep z filtrami, wyborem rozmiaru i dodaniem do koszyka nagle pokazuje czerwone INP, mimo że nic nie „zepsuło się” w kodzie.

Najczęstsza pułapka: wynik 95 w Lighthouse i jednocześnie czerwone CWV w Search Console. Powód bywa prozaiczny — Lighthouse testuje jeden URL, zwykle stronę główną, na szybkim łączu. Użytkownicy wchodzą na karty produktów i kategorie z telefonów. Mierz to, co widzi Google: definicje i sposoby pomiaru Web Vitals na web.dev.

Audyt techniczny sklepu w 60 minut — narzędzia po kolei

Kolejność ma znaczenie: od danych, które już masz, do tych, które wymagają analizy. Zaplanuj cztery bloki po 15 minut.

• Search Console (15 min) — zakładki „Indeksowanie stron” i „Core Web Vitals”. Zapisz: ile URL-i jest wykluczonych, jakie są powody, czy liczba błędów 5xx rośnie tydzień do tygodnia. Typowe powody: „Odkryto – obecnie niezaindeksowana”, „Zaindeksowana, mimo że zablokowana przez robots.txt”, „Duplikat: Google wybrał inną wersję kanoniczną”.
• PageSpeed Insights (10 min) — testuj stronę główną, jedną kategorię i jeden produkt, w trybie mobilnym. Patrz najpierw na TTFB, potem na LCP.
• Crawl (20 min) — Screaming Frog w darmowym limicie 500 URL-i wystarczy na mniejszy sklep. Włącz renderowanie JavaScript i sprawdź: canonicale na filtrach, duplikaty title, głębokość kliknięcia, wagę plików CSS.
• Logi serwera (15 min) — posortuj po kodzie odpowiedzi i po czasie. Szukaj botów dobijających się do stron z parametrami, wyszukiwarki wewnętrznej i koszyka.

Dziesięć sygnałów alarmowych, które powinny zatrzymać prace nad treścią i kampaniami:

Sygnał	Próg / objaw	Gdzie sprawdzić
TTFB	powyżej 800 ms	PageSpeed Insights, logi
LCP na mobile	powyżej 2,5 s	Search Console
INP	powyżej 200 ms	Search Console
CLS	powyżej 0,1	Search Console
URL-e z parametrami	tysiące w indeksie	Raport indeksowania
Brak canonicali na filtrach	setki adresów	Screaming Frog
Plik CSS motywu	powyżej 300 kB	Screaming Frog, PSI
Brak nagłówka Cache-Control na statyce	brak max-age	curl -I na pliku obrazu
Błędy 5xx	rosnący trend	Search Console, logi
Sitemap	404 lub brak zgłoszonej	Search Console

Logi czytaj filtrem po ścieżce. Jeśli jedna kategoria produktowa zbiera 5 tys. żądań na dobę od botów, a TTFB na niej skacze do 2 s, problemem nie jest treść, tylko brak cache i zbyt szerokie kombinacje filtrów. Porównaj to z tym, jak wygląda audyt SEO technicznego i szybkości w Bełżcu.

Indeksacja i architektura — gdzie sklepy tracą pozycje po cichu

Filtry fasetowe w PrestaShop potrafią wygenerować kilkanaście tysięcy adresów typu /kategoria?q=Kolor-Czerwony/Rozmiar-L. Domyślnie każdy z nich jest osobną stroną z własnym tytułem — dla Google to duplikaty. Masz dwa rozwiązania i nigdy nie stosujesz obu naraz: albo noindex, follow na adresach z parametrami, albo blokada w robots.txt. Pułapka: jeśli zablokujesz URL w robots.txt i jednocześnie wstawisz noindex, robot nie wczyta strony i nie zobaczy dyrektywy — duplikat zostanie w indeksie. Adres bazowy kategorii zostaw indeksowalny, z canonical wskazującym na /kategoria/ bez parametrów.

Duplikaty techniczne to klasyka z większości audytów:

• www i bez www — jedno 301 na poziomie serwera, nie we wtyczce;
• http → https — dokładnie jedno przekierowanie, nie łańcuch http://www → https://www → https://;
• /index.php vs / — w PrestaShop włącz opcję przekierowania do kanonicznego URL, w WordPressie ustaw permalinki bez index.php;
• końcowe slashe — wybierz jedną wersję i trzymaj ją w linkach wewnętrznych oraz sitemapie.

Paginacja nie jest duplikatem, jeśli strona 2 pokazuje inne produkty — zostaw ją indeksowalną z self-canonical, ale wyłącz z indeksu sortowanie (?orderby=) i przełącznik siatka/lista. Produkty niedostępne: jeśli wrócą do oferty, zostaw stronę z kodem 200 i komunikatem; jeśli nie — 301 na kategorię nadrzędną, a przy trwałym wycofaniu 410.

Przekierowania: łańcuch trzech 301 to marnowanie budżetu crawla. Kod 302 stosuj tylko przy zmianach tymczasowych — Google traktuje go inaczej niż 301. Najgorszy wariant to przekierowanie na adres zwracający 404, bo Google zapisuje to jako soft 404 i wywala z indeksu także docelowy URL.

Na koniec: robots.txt blokujący /themes/, /modules/ albo pliki .css i .js. Google renderuje stronę, ale bez stylów widzi inny layout — inaczej ocenia CLS i użyteczność mobilną. Sprawdź to w Search Console: Inspekcja URL → Test na żywo → zrzut ekranu renderowania. Jeśli brakuje stylów, masz odpowiedź. Ten sam zestaw sprawdzeń powtarza się w mniejszych sklepach regionu — zobacz audyt dla sklepów w Biłgoraju i SEO techniczne i szybkość w Bełżcu.

Optymalizacja szybkości — 7 zmian o największym zwrocie

Kolejność ma znaczenie. Najpierw rzeczy, które dotyczą każdej strony i każdego użytkownika.

1. TTFB poniżej 500 ms. Zacznij od serwera, nie od obrazków. PHP 8.1/8.2 zamiast 7.4 to często 20–40% szybsze wykonanie. OPcache włączony, memory_consumption 256 MB, max_accelerated_files 20000, na produkcji validate_timestamps=0. Najtańszy hosting współdzielony, który sam generuje 500 ms opóźnienia, to strata — sensowny VPS to dziś kilkadziesiąt złotych miesięcznie.
2. Full-page cache — gotowy HTML serwowany z pliku lub Redisa. TTFB spada do 100–200 ms. Koszyk, logowanie i checkout muszą omijać cache.
3. Cache obiektowy (Redis/Memcached) to inna warstwa: zapamiętuje wyniki zapytań do bazy. Przy katalogu z tysiącami produktów i filtrami potrzebujesz obu warstw, bo wąskim gardłem staje się baza.
4. Obrazy. WebP jest zwykle 25–35% lżejszy od JPEG przy podobnej jakości, AVIF jeszcze mniej, ale wolniej się koduje. Zawsze podawaj width i height — brak wymiarów to najczęstsza przyczyna CLS. srcset na 2–3 szerokości, lazy loading tylko poniżej pierwszego ekranu, a obraz LCP z loading="eager" i fetchpriority="high".
5. Krytyczny CSS i JS. Style pierwszego ekranu inline (kilkanaście kB), reszta odroczona. W DevTools → Coverage zobaczysz, jaki procent JS nigdy nie został użyty — w rozbudowanych szablonach to często ponad połowa.
6. Skrypty zewnętrzne. Piksel, czat, mapa, widget opinii — każde to osobne żądanie i praca CPU. Trzy do pięciu naraz to praktyczny limit, resztę ładuj po interakcji.
7. Baza danych. Brakujące indeksy, zapytania w pętli, rosnące tabele logów, koszyków i sesji — w PrestaShop potrafią urosnąć do setek MB i spowolnić każdy zapis.

Każdy z tych punktów przekłada się na progi Core Web Vitals: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. CDN pomaga, gdy ruch jest rozproszony geograficznie albo statyki nie da się trzymać blisko użytkownika. Przy sklepie lokalnym z pełnym cache na VPS dokłada przystanek i utrudnia debugowanie, bo cache HTML miesza się z koszykiem. Ten sam schemat wdrożeń opisujemy dla Krasnobrodu i Lublina.

PrestaShop czy WooCommerce — od czego zacząć na Twojej platformie

PrestaShop. Punkt startowy to Zaawansowane → Wydajność. Włącz CCC (Combine, Compress, Cache), cache Smarty, minifikację HTML i przeniesienie JS na koniec strony. Template compilation ustaw na „rekompiluj szablony, gdy pliki się zmienią", a cache Smarty na „tak". Po każdej zmianie modułu czyść cache — inaczej testujesz starą wersję i wyciągasz błędne wnioski. Wbudowany profiler pokaże liczbę zapytań i czas: kategoria z 500 produktami i 40 zapytaniami to sygnał, że kod jest napisany źle. Przejrzyj moduły ładujące własny JS i CSS globalnie — płatności, opinie i „ostatnio oglądane" często ciągną całe biblioteki po to, by zadziałać na jednej podstronie. Szczegóły konfiguracji znajdziesz w dokumentacji dla deweloperów PrestaShop.

WooCommerce. Zacznij od liczby wtyczek — każda dokłada zapytania i pliki. Query Monitor pokaże, ile zapytań generuje strona kategorii; powyżej 100 to punkt wyjścia do porządków. Object cache z Redis (drop-in object-cache.php) odciąża bazę najbardziej. HPOS przenosi zamówienia z postmeta do dedykowanych tabel — przy rosnącej liczbie zamówień to największa pojedyncza zmiana wydajności. Kontroluj wp-cron: wyłącz DISABLE_WP_CRON i ustaw prawdziwy cron systemowy, a wysyłkę maili przenieś do kolejki (Action Scheduler), żeby nie blokowała żądań.

Wspólny wzorzec: 20% przyczyn daje 80% efektu. To, co ładuje się na każdej stronie — nagłówek, motyw, globalne wtyczki, fonty, mini-koszyk — odpowiada za większość problemów. Zajmij się tym najpierw, zanim zaczniesz optymalizować pojedyncze podstrony. Przykłady dla mniejszych wdrożeń zebraliśmy dla Frampola i Józefowa.

Kiedy własny moduł wygrywa? Gdy płatne rozszerzenie robi dwadzieścia rzeczy, z których potrzebujesz jednej, ładuje kilkaset kB JS globalnie i kosztuje abonament. Krótki własny moduł lub mu-plugin bywa lepszy — pod warunkiem, że ktoś go później utrzyma i że nie duplikuje funkcji, które platforma już ma.

Lokalne SEO dla Narola i okolic — dlaczego to inna gra

W Narolu i powiatach ościennych rynek jest na tyle mały, że o widoczności decyduje kilka zapytań, a nie setki. Dlatego lokalne SEO zaczyna się od uporządkowania trzech rzeczy — dopiero potem sens mają poprawki szybkości.

1. Wizytówka Google i spójność NAP. Nazwa, adres i telefon muszą być identyczne w czterech miejscach: wizytówka, stopka strony, podstrona kontakt i dane strukturalne LocalBusiness. „Sp. z o.o.” w jednym miejscu i „spółka z ograniczoną odpowiedzialnością” w drugim to dla Google dwa różne byty. Telefon zapisuj w jednym formacie na całej stronie — także w treści wpisów i w stopce szablonu. Jak zbudować poprawny znacznik, opisuje dokumentacja danych strukturalnych Google Search Central.

2. Frazy lokalne, które realnie mają ruch. Nie zgaduj. Sprawdź w Planerze słów kluczowych Google (bezpłatny, wystarczy konto Ads) wolumen dla zapytań: „sklep internetowy Narol”, „wdrożenie sklepu Tomaszów Lubelski”, „opieka techniczna nad sklepem Lubaczów”. Wolumeny są niskie, ale intencja zakupowa wysoka — jedna konwersja miesięcznie z takiej frazy bywa warta więcej niż tysiąc wyświetleń z frazy ogólnej. Jeśli fraza ma mniej niż 10 wyszukiwań miesięcznie, nie buduj pod nią osobnej podstrony.

3. Strony miast z realnie różną treścią. Podstrony dla Narola, Tomaszowa Lubelskiego i Lubaczowa muszą się różnić nie tylko nazwą miejscowości: inne zdjęcia z realizacji, inny czas dojazdu, inne referencje, inne FAQ. Kopiuj-wklej z podmienionym miastem to najszybszy sposób, żeby Google uznało strony za duplikaty i zostawiło w indeksie jedną.

4. Hosting w Polsce. Serwer w kraju to kilkanaście, nie sto kilkadziesiąt milisekund opóźnienia dla użytkownika z Narola, a dane w UE upraszczają RODO i zawieranie umów powierzenia.

Szersze tło dla sąsiednich rynków znajdziesz w tekstach o SEO technicznym i optymalizacji szybkości w Biłgoraju oraz o SEO technicznym w Krasnobrodzie.

Jak mierzyć efekty i nie oszukiwać się danymi

Po wdrożeniu poprawek najczęstszy błąd to patrzenie na jedno narzędzie i wyciąganie wniosków po dwóch tygodniach. Ustaw cztery KPI i raportuj je raz w miesiącu, zawsze tego samego dnia.

• Pozycje na frazy lokalne — wybierz 5–10 fraz i sprawdzaj je ręcznie lub jednym narzędziem. Search Console pokazuje średnią pozycję dla zapytania, ale przy niskim wolumenie jest zaszumiona i nie odróżni pozycji 4 od 9.
• CTR w Search Console — zakładka Skuteczność, wymiar „Zapytania”. Spadek CTR przy stałych pozycjach oznacza zwykle zmianę intencji zapytania albo lepszy opis w wynikach konkurencji.
• Ruch organiczny — kliknięcia z Search Console plus sesje z GA4, kanał Organic Search.
• Przychód z organic — GA4, raport Sprzedaż z filtrem kanału. To jedyny wskaźnik, który wiąże SEO z pieniędzmi.

Horyzonty. Poprawę szybkości widać w danych polowych po 2–8 tygodniach, bo Chrome UX Report liczy je w 28-dniowym oknie — pierwsze zmiany pojawią się dopiero około czwartego tygodnia po wdrożeniu. Wzrost widoczności to 3–6 miesięcy, a nowa domena potrzebuje dłużej. Zasady pomiaru i progi opisuje dokumentacja web.dev o Web Vitals.

Pułapka: zielone CWV bez wzrostu ruchu. Jeśli LCP i INP są w normie, a kliknięcia stoją, problemem nie była szybkość. Sprawdź raport Indeksowanie stron: komunikat „Wykryta, ale obecnie niezaindeksowana” to sygnał o treści lub duplikacji, nie o wydajności. Wtedy priorytet przestawiasz na treść i linkowanie wewnętrzne.

Szablon raportu może mieć sześć wierszy: kliknięcia i wyświetlenia, pozycje na frazach lokalnych, pięć najszybciej rosnących zapytań, liczba zaindeksowanych adresów, status CWV, konwersje i przychód. Decyzję o zmianie priorytetów podejmij, gdy przez trzy kolejne miesiące kliknięcia spadają przy zielonych CWV.

Ile to kosztuje i jak wygląda współpraca z DropDigital

Pracujemy na godziny i zawsze podajemy wycenę przed startem. Nie ma abonamentu „na wszystko” ani ukrytych pozycji — dostajesz listę zadań z przypisanym czasem i wiesz, za co płacisz.

Audyt techniczny: 6–10 godzin. Obejmuje sprawdzenie indeksacji, mapy strony, kanonicznych, przekierowań, danych strukturalnych, szablonu i pomiaru CWV w danych polowych i laboratoryjnych. Efekt to lista problemów z priorytetami, nie raport na 60 stron.

Wdrożenie poprawek: 15–40 godzin — zależnie od platformy i liczby modułów. Prosta strona na WordPressie z jednym szablonem to dolna granica. PrestaShop z rozbudowanym katalogiem i dziesięcioma modułami zewnętrznymi często wymaga wejścia w kod szablonu i konfigurację cache, co podnosi zakres. Dokumentacja deweloperska PrestaShop to nasz podstawowy punkt odniesienia przy takich pracach.

Opieka po wdrożeniu. Monitoring CWV, alerty o spadkach dostępności, aktualizacje bezpieczeństwa, kontrola indeksacji po każdej zmianie w szablonie. Ustalamy SLA reagowania na awarie — krytyczne (strona nie działa, koszyk nie przyjmuje zamówień) w godzinach, pozostałe w dniach roboczych.

Pracujesz bezpośrednio z deweloperem, który robi audyt i wdrożenie. Nie przekazujemy zlecenia dalej i nie ma pośrednika między Tobą a osobą, która pisze kod. Jeśli nie wiesz, od czego zacząć, pomocny będzie materiał o tym, jak zacząć SEO techniczne i optymalizację szybkości w Lublinie — kolejność działań jest ta sama dla mniejszych rynków.

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

Lista kontrolna do odklikania

• Raport indeksowania w Search Console — Sprawdź liczbę URL-i wykluczonych i powody wykluczenia; czy liczba błędów 5xx rośnie w czasie.
• Raport Core Web Vitals w Search Console — Które grupy adresów mają status „do poprawy” lub „słabe” i czy dotyczą one stron kategorii, czy produktów.
• PageSpeed Insights dla trzech szablonów — Osobno strona główna, kategoria z filtrami i karta produktu — te trzy typy zachowują się inaczej.
• Crawl darmowym limitem Screaming Frog — 500 adresów wystarczy, żeby zobaczyć strukturę: kody odpowiedzi, tytuły, canonicale, głębokość kliknięć.
• Canonical i noindex na filtrach — Sprawdź kilka losowych kombinacji filtrów — czy wskazują tę samą wersję kanoniczną co kategoria bazowa.
• Paginacja i strona 2+ kategorii — Ustal, czy strony paginacji mają własne, unikalne tytuły i czy są indeksowane świadomie, czy przypadkiem.
• Produkty niedostępne — Sprawdź, czy wygaszone produkty zwracają 200 z pustą treścią, czy 404/301 — i czy nie tworzą setek cienkich stron.
• TTFB na kluczowych adresach — Zmierz kilkukrotnie dla strony głównej, kategorii i koszyka; powyżej 800 ms to sygnał do pracy nad serwerem i cache.
• Dostępność CSS i JS w robots.txt — Test na żywo w Search Console pokaże, czy Google pobiera style i skrypty potrzebne do renderu.
• Liczba zewnętrznych skryptów — Policz narzędzia analityczne, czaty i piksele ładowane na każdej stronie — każde to dodatkowy czas i ryzyko dla INP.
• Obraz LCP na karcie produktu — Sprawdź, czy główne zdjęcie nie ma lazy loadingu i czy podane są jego rzeczywiste wymiary.
• Logi serwera z ostatnich 7 dni — Poszukaj adresów bez cache, powtarzanych żądań botów i zapytań do koszyka generujących wysoki czas odpowiedzi.
• Mapa witryny i jej aktualność — Sprawdź, czy sitemap zawiera tylko adresy, które naprawdę chcesz indeksować, i czy nie ma w niej przekierowań.
• Wersja PHP i OPcache — Potwierdź w panelu hostingu, że działa PHP 8.x oraz OPcache — to najtańszy sposób na obniżenie TTFB.

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