Co składa się na cenę SEO technicznego w Zamościu

Cena SEO technicznego to w praktyce trzy liczby: stawka godzinowa, liczba godzin i koszty stałe. W regionie lubelskim stawka wynosi 120–200 zł netto za godzinę. Freelancer z doświadczeniem w PrestaShop liczy zwykle 150–180 zł, mała agencja 180–200 zł, a osoba ucząca się na sklepie klienta 60–90 zł. W tym ostatnim przypadku prawie zawsze brakuje etapu testów po wdrożeniu, a poprawki po dwóch tygodniach robi już ktoś inny, za wyższą stawkę.

Podział pracy przy typowym sklepie wygląda tak:

• audyt — 4–8 h (przy 500–2000 produktów najczęściej 6 h),
• wdrożenie — 10–40 h,
• testy i raport — 2–5 h.

Rozrzut w części wdrożeniowej bierze się z konkretnego stacku, nie z rozmiaru firmy. Sklep WooCommerce z 800 SKU i trzema wtyczkami od cache zamyka się w 12–16 h. Ten sam katalog w PrestaShop 1.8 z 12 modułami płatnymi potrafi zająć 30–40 h, bo każdy moduł doładowuje własne pliki JS i CSS, a część nadpisuje szablony motywu. Zakres takich prac opisujemy w usłudze SEO techniczne i optymalizacja szybkości w Zamościu.

Poza godzinami dochodzą koszty stałe: płatny moduł cache lub kompresji (200–500 zł/rok), hosting z CDN (30–150 zł/mc) i narzędzie do crawlowania. Screaming Frog jest darmowy do 500 adresów URL, powyżej to kilkaset złotych rocznie. Ahrefs czy Semrush to wydatek rzędu 400–500 zł/mc i przy samym audycie technicznym zwykle nie jest potrzebny.

Dlaczego wycena na oko bez audytu jest ryzykiem dla obu stron? Klient akceptuje 900 zł, dostaje włączony cache i komunikat „powinno być szybciej”, po czym i tak płaci za właściwe wdrożenie. Wykonawca nie wie, czy czeka go 10 czy 40 godzin, więc albo zaniża ofertę i dokłada z własnej kieszeni, albo zawyża i przegrywa. Audyt jest najtańszym ubezpieczeniem kosztorysu i zwykle odliczamy go od późniejszego wdrożenia.

Konkretne widełki cenowe — ile to kosztuje w 2025 roku

Poniższe widełki pochodzą z ofertowania sklepów w Zamościu i powiecie zamojskim w 2025 roku. Kwoty są netto, bez kosztu hostingu i licencji modułów.

Skąd różnica między dolną i górną granicą audytu? WooCommerce to przewidywalny stack: PHP 8.x, jedna wtyczka do cache, kilka wtyczek do płatności i wysyłki — crawl i analiza zajmują 4–6 h. PrestaShop z modułami, wielojęzycznością i tysiącami SKU wymaga przejrzenia override'ów w motywie i sprawdzenia, który moduł generuje najwięcej zapytań do bazy. To 6–8 h i kwota bliżej 2500 zł.

Optymalizacja szybkości 1200–3500 zł to 8–20 h pracy. Jeśli LCP wynosi 6 s, a hosting to serwer współdzielony za 15 zł/mc, samym cache nie da się zrobić sensownego wyniku — trzeba doliczyć 50–150 zł/mc na VPS albo CDN. To koszt po stronie klienta, nie praca wykonawcy, i warto pokazać go w ofercie na pierwszym miejscu, żeby nie wrócił po fakturze. Punkt odniesienia: Google mierzy Core Web Vitals na danych rzeczywistych użytkowników, a nie na wyniku z komputera programisty.

Kompleksowe SEO techniczne 2500–8000 zł obejmuje audyt, wdrożenie i dwa tygodnie testów po zmianach. Górna granica dotyczy sklepów po migracji z innej platformy, z tysiącami adresów do przekierowania. Opieka z SLA to 500–2000 zł/mc: 500 zł oznacza około 2–3 h (aktualizacje, backup, monitoring dostępności), 2000 zł to 8–10 h, reakcja do 4 h w dni robocze i monitoring częstszy niż raz na 5 minut. Podobne stawki stosujemy w projektach dla firm z Hrubieszowa — różnice wynikają z liczby stron i modułów, nie z lokalizacji.

Audyt techniczny: co sprawdzamy i czego szukamy

Dobry audyt to nie PDF na 40 stron, którego nikt nie przeczyta. To arkusz z trzema kolumnami: co jest zepsute, jaki ma priorytet (P0 — blokuje indeksację lub konwersję, P1 — wpływa na szybkość, P2 — porządki) i ile godzin zajmie naprawa. Po wdrożeniu te same punkty wracają jako lista do odhaczenia z datą.

Indeksacja. Zaczynamy od robots.txt i sitemapy. Typowy błąd: plik blokuje /koszyk i /szukaj, ale razem z nimi cały katalog /wp-content/ albo /themes/, przez co Google nie widzi plików CSS i JS. W sitemapie sprawdzamy, czy trafiają tam wyłącznie adresy kanoniczne. Dalej noindex — najczęściej zostaje po stagingu i nikt nie pamięta, gdzie został ustawiony. Potem duplikaty z parametrami: ?orderby=, ?filter=, ?page=. Filtry w WooCommerce i PrestaShop generują setki kombinacji, które trzeba wyłączyć z indeksu (noindex, follow) i spiąć canonicalem.

Core Web Vitals. Pracujemy na danych z CrUX w Search Console (raport „Podstawowe wyniki internetowe”), a nie tylko na Lighthouse. Lighthouse na mocnym laptopie pokaże 90, a telefon klienta w Zamościu na LTE — 30. Definicje metryk i progi opisuje dokumentacja web.dev: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1.

Struktura URL i przekierowania. Po migracji ze starej platformy każdy stary adres musi mieć dokładnie jeden skok 301 do nowego. Łańcuchy a→b→c skracamy do jednego przekierowania. Błędy 404 wyciągamy z logów serwera i z raportu GSC, a nie z losowego klikania. Osobno sprawdzamy strony bez linków wewnętrznych — jeśli nic do nich nie prowadzi, nie zdobędą ruchu.

Dane strukturalne. Product, Offer i BreadcrumbList walidujemy w Rich Results Test i sprawdzamy w GSC, czy raporty nie zgłaszają błędów. Najczęstsze problemy: cena w schema inna niż na stronie, brak informacji o dostępności, cena bez waluty. Ten sam schemat stosujemy przy projektach z SEO technicznego i optymalizacji szybkości w Lublinie.

Optymalizacja szybkości: co daje efekt, a co tylko plik w PageSpeed

PageSpeed Insights pokazuje wynik, ale nie mówi, co go zmieniło. Zlecenie „wpiszcie 100 w PageSpeed” kończy się zwykle włączeniem cache i skróceniem CSS — licznik rośnie, a klient nie widzi różnicy, bo LCP nadal trzyma obraz hero o wadze 1,8 MB. Zakres prac w sklepie z Zamościa opisujemy w artykule o SEO technicznym i optymalizacji szybkości w Zamościu, ale sama kolejność wdrożeń ma większe znaczenie niż liczba optymalizacji.

Kolejność, która działa:

• Obrazy — konwersja JPEG/PNG na WebP lub AVIF. Na katalogu 2000 produktów waga strony spada z ok. 4 MB do 1,1–1,4 MB, a LCP o 0,8–1,5 s. To zwykle 40–50% całego efektu.
• Cache — OPcache, SmartCache w PrestaShop, LiteSpeed Cache lub WP Rocket w WooCommerce. Efekt widać dopiero przy powracających użytkownikach i botach.
• CDN — ma sens, gdy odbiorcy są poza Lubelszczyzną. Dla firmy obsługującej klientów z Zamościa różnica bywa w granicach błędu pomiaru.
• Krytyczny CSS i kolejność skryptów — defer i async potrafią zepsuć koszyk AJAX, więc test na kopii jest obowiązkowy.

W PrestaShop najczęstszy grzech to 30–40 modułów, z których każdy dokłada własny JS w hooku displayFooter — efektem jest 40–60 osobnych żądań na każdej podstronie. W WooCommerce problem jest inny: wtyczki od „related products”, upsellów i dynamicznych cen dokładają zapytania SQL tak długo, że TTFB na hostingu współdzielonym sięga 1,8 s przy 3000 zamówień w bazie.

LCP poprawiają realnie dwie rzeczy: <link rel="preload" as="image" fetchpriority="high"> dla obrazu hero oraz niższy TTFB (PHP-FPM, OPcache, porządek w MySQL). Progi i definicje tych metryk opisuje dokumentacja Web Vitals na web.dev. Reszta to kosmetyka.

PrestaShop czy WooCommerce — różnice w pracochłonności i cenie

Dwie firmy z tym samym problemem — wolno ładującym się sklepem — dostaną różne wyceny, jeśli jedna działa na PrestaShop, a druga na WooCommerce. Nie chodzi o „trudność” platformy, a o liczbę godzin potrzebnych na ten sam efekt.

PrestaShop (typowo 15–30 h): dochodzi praca z szablonem i kompilacją. SmartCache trzeba czyścić po każdej zmianie, a nadpisania siedzą w /themes/twoj-szablon/templates, nie w module — struktura katalogów jest opisana w dokumentacji dla deweloperów PrestaShop. Część modułów płatnych da się zastąpić własnym, lżejszym kodem: 6–12 h pracy, ale bez subskrypcji i bez 200 KB JS w stopce.

WooCommerce (typowo 10–20 h): mniej pracy w warstwie szablonu, więcej w diagnozie konfliktów. Dwa pluginy cache jednocześnie, wtyczka tłumaczeń odpalająca 40 zapytań na stronę, brak indeksów na wp_postmeta przy 20 000 wpisów — to wszystko widać dopiero po wyłączaniu wtyczek po kolei na kopii. Do tego czyszczenie wp_options i transients przez WP-CLI (wp transient delete --all).

Kiedy własny moduł wychodzi taniej: cztery subskrypcje po ok. 30 EUR/mies to około 510 zł miesięcznie, czyli ponad 6000 zł rocznie. Własny moduł w 18 h przy 150 zł/h to 2700 zł netto — zwraca się w 5–6 miesięcy i nie znika, gdy deweloper wtyczki kończy projekt. Podobne różnice w zakresie prac opisaliśmy przy wdrożeniach w regionie, m.in. w materiale o SEO technicznym i optymalizacji szybkości w Lublinie.

Administracja serwerem to osobna pozycja: PHP-FPM, OPcache i tuning MySQL zajmują 1–3 h miesięcznie, a VPS klasy 4 GB kosztuje 40–80 zł/mies. Hosting współdzielony bywa tańszy na fakturze, ale przy TTFB powyżej 1,5 s kosztuje więcej w porzuconych koszykach.

Jak wygląda proces i harmonogram — od zapytania do raportu

Porównywanie wykonawców po samej cenie kończy się źle, jeśli nie wiadomo, co jest w środku wyceny. Poniżej kolejność, którą stosujemy przy zleceniach z Zamościa i okolic — taki sam schemat opisaliśmy dla okolicznych miejscowości we wpisie o SEO technicznym i optymalizacji szybkości w Hrubieszowie.

Krok 1 — rozmowa i dostępy (1 dzień roboczy). Potrzebujemy: dostępu do Google Search Console (weryfikacja przez DNS lub plik), GA4, kopii sklepu albo panelu hostingu, listy wtyczek lub modułów oraz liczby produktów i zamówień w bazie. Bez tego wycena jest zgadywaniem — uczciwy wykonawca nie poda ceny „na telefon”, nie wiedząc, czy sklep ma 8 czy 40 modułów.

Krok 2 — audyt techniczny (3–7 dni, 4–8 h pracy). Dostajesz listę błędów z priorytetem P0/P1/P2, szacunkiem godzin na każdą pozycję i informacją, co daje efekt, a co jest kosmetyką. P0 to rzeczy blokujące indeksację lub LCP, np. noindex na kategorii albo obraz hero bez preloadu.

Krok 3 — wdrożenie na kopii (10–40 h, zwykle 1–3 tygodnie). Każda zmiana idzie najpierw na staging. Pomiar przed/po: PageSpeed Insights, Lighthouse, TTFB z trzech lokalizacji, liczba żądań JS na kluczowych podstronach. Dopiero po akceptacji wdrożenie na produkcję, w oknie o niskim ruchu i z backupem bazy. Zmiany bezpośrednio na produkcji bez kopii to najdroższy błąd w tym procesie.

Krok 4 — raport i przekazanie (2–5 h). Dokument z tabelą przed/po, lista zmian i tego, co zostało na kolejny kwartał. Progi, według których oceniamy wynik, definiuje dokumentacja Core Web Vitals w Google Search Central. Opcjonalnie opieka z SLA: reakcja w 4 h w godzinach pracy, monitoring uptime co minutę, miesięczny przegląd błędów w GSC.

Pułapki w wycenie SEO technicznego — jak je wykryć

Wycena prac technicznych w Zamościu mieści się w widełkach 800–8000 zł netto, więc różnice między ofertami bywają większe niż sam zakres. Poniżej pięć sygnałów, po których poznasz, że kosztorys nie trzyma się kupy.

• Oferta bez dostępu do Search Console i bez pytania o platformę. Kto nie prosi o GSC (i ewentualnie GA4), ten nie zobaczy indeksacji, błędów 404, duplikatów ani wykluczeń — dostaje tylko dane publiczne i wróży. Brak pytania o platformę to ten sam problem: inne wąskie gardła ma PrestaShop, inne WooCommerce, a inne sklep pisany na zamówienie.
• Raport 100/100 w Lighthouse, a w CrUX nadal czerwone pole. Lighthouse mierzy jedno urządzenie, sztuczne łącze i jeden moment. CrUX to realni użytkownicy z 28 dni. Poproś o zrzut z CrUX dla domeny — jeśli LCP albo INP siedzi w czerwonym polu, wynik z labu nic nie znaczy. Zobacz definicje progów Web Vitals.
• Cache włączony, a TTFB bez zmian. Wejdź w DevTools → Network, odśwież stronę i sprawdź nagłówki odpowiedzi: cache-control, age, x-cache, server-timing. Jeśli po „optymalizacji” TTFB nadal przekracza 600 ms, cache obsługuje tylko pliki statyczne, a HTML generuje się od zera przy każdym wejściu.
• Zapłata za „pozycjonowanie” bez prac technicznych. Link building i treści to inna usługa niż naprawa indeksacji, przekierowań i Core Web Vitals. W jednym kosztorysie można je łączyć, ale muszą być rozpisane jako osobne pozycje z liczbą godzin.
• Umowa bez wskazania, kto wdroży poprawki. Audyt bez wdrożenia to dokument w szufladzie. Jeśli wykonawca nie mówi wprost, czy robi poprawki na serwerze i w plikach motywu, czy tylko je opisuje — zapytaj, zanim podpiszesz.

Punktem wyjścia każdej takiej rozmowy powinien być zakres opisany na stronie SEO techniczne i optymalizacja szybkości w Zamościu — z listą prac, a nie z nazwą pakietu.

Kiedy SEO techniczne się nie opłaca — uczciwie o priorytetach

Zdarza się, że klient pyta o pakiet za 5000 zł, a po kwadransie rozmowy widać, że nie ma z czego zrobić zwrotu. Rzetelna wycena to nie tylko kwota — to także informacja, czego teraz nie robić.

• Sklep z 20 produktami i zerowym ruchem. Poprawa LCP z 3,8 s do 1,9 s nic nie da, jeśli nikt nie wchodzi. Najpierw oferta: opisy, zdjęcia, koszt dostawy, minimum 30–40 produktów w kategoriach, których ludzie faktycznie szukają. Dopiero gdy GA4 pokazuje 200–300 wejść miesięcznie, warto gonić milisekundy. Google wprost pisze o treściach tworzonych dla ludzi — wytyczne pomocnych treści to lektura obowiązkowa przed zamawianiem czegokolwiek.
• Brak jakiejkolwiek analityki. Bez GA4 i Search Console nie ustalisz punktu odniesienia i zapłacisz za poprawki, których wpływu nie zmierzysz. Wdrożenie pomiaru to 1–3 h pracy — najtańszy krok w całym procesie. Od niego zaczyna się też praca nad szybkością sklepu, o czym piszemy przy okazji kolejności prac technicznych w sklepie.
• Platforma, którą i tak czeka migracja. PrestaShop 1.6 czy WordPress z 40 wtyczkami — optymalizacja starego szablonu to pieniądze wydane dwa razy. Lepiej zrobić audyt, wpisać poprawki (przekierowania 301, dane strukturalne, obrazy, cache) do zakresu migracji i sprawdzić efekt na nowym środowisku przed przełączeniem DNS.
• Kiedy audyt za 800 zł wygrywa z pakietem za 5000 zł. Jeśli nie wiesz, co boli — indeksacja, duplikaty, szybkość czy dane strukturalne — audyt 4–8 h (800–1500 zł) daje listę priorytetów. Pakiet ma sens, gdy lista istnieje i wiadomo, że wdrożenie zajmie 20–40 h.

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

Lista kontrolna do odklikania

• Dostęp do Google Search Console — Sprawdź przed startem wyceny — bez danych o zapytaniach i indeksacji audyt opiera się tylko na narzędziach zewnętrznych.
• Dane CrUX dla realnych użytkowników — W Search Console raport Core Web Vitals pokazuje wartości z ostatnich 28 dni — porównuj je przed i po wdrożeniu, nie tylko wynik PageSpeed.
• robots.txt i sitemap.xml — Weryfikuj po każdej zmianie konfiguracji serwera lub wtyczki SEO — jeden przypadkowy Disallow blokuje całą sekcję sklepu.
• Znaczniki noindex na stronach z ruchem — Sprawdź listę adresów z GSC pokrywających się ze stronami oznaczonymi noindex — najczęstsza przyczyna nagłego spadku widoczności.
• Duplikaty z parametrami filtrów i sortowania — Testuj adresy typu ?filter=, ?orderby=, ?page= — jeśli zwracają 200 i są indeksowane, kanibalizują kategorię.
• Kanibalizacja fraz między kategoriami i wpisami bloga — Porównaj w GSC adresy, które pojawiają się dla tej samej frazy w ciągu 90 dni.
• Dane strukturalne Product, Offer i BreadcrumbList — Testuj w Rich Results Test po każdej zmianie szablonu produktu; zakres typów obsługiwanych przez Google: https://developers.google.com/search/docs/appearance/structured-data/search-gallery.
• Mapa przekierowań 301 po migracji — Sprawdź, czy każdy stary adres z ruchem ma dokładnie jedno przekierowanie do adresu docelowego, bez łańcuchów.
• Błędy 404 i łańcuchy przekierowań — Monitoruj przez 30 dni po wdrożeniu; łańcuch dłuższy niż dwa przeskoki wydłuża czas odpowiedzi i gubi sygnały linkowe.
• Liczba modułów i wtyczek ładujących JS na każdej podstronie — Policz skrypty w źródle strony kategorii i produktu — w PrestaShop 30+ modułów to typowy wynik.
• Hosting: PHP-FPM, OPcache, wolne zapytania MySQL — Sprawdź wersję PHP, włączony OPcache i czas TTFB na hostingu współdzielonym przed zakupem pakietu optymalizacji.
• Obrazy i LCP — Upewnij się, że pliki są w WebP/AVIF, a główny obraz ma preload — to zwykle największa pojedyncza dźwignia LCP.
• Zakres SLA i czas reakcji — W opiece miesięcznej ustal liczbę godzin, czas reakcji na awarię i kanał zgłoszeń — bez tego 500 zł/mc i 2000 zł/mc wyglądają identycznie na papierze.

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