Ile kosztuje SEO techniczne i optymalizacja szybkości w Zamościu? Widełki na 2025 rok

Nie ma jednej ceny za SEO techniczne w Zamościu i nie ma tu cennika „z sufitu”. Jest stawka 130–230 zł netto za godzinę i liczba godzin, które trzeba realnie przepracować w Twoim sklepie. Wycena to stawka × godziny, dlatego dwie firmy z podobnym asortymentem dostają czasem oferty różniące się o 200%.

Trzy zakresy, które pokrywają większość zapytań:

• Audyt techniczny: 900–2500 zł netto — sklep do 500 URL. Większy sklep to więcej godzin na samo crawlowanie i czytanie logów.
• Jednorazowe wdrożenie optymalizacji: 1800–7000 zł netto — od kilkunastu do kilkudziesięciu godzin pracy dewelopera.
• Stała opieka techniczna: 700–2600 zł netto miesięcznie — zależnie od zakresu i ustalonego SLA.

Zakres	Widełki netto	Co najczęściej decyduje o kwocie
Audyt techniczny (do 500 URL)	900–2500 zł	liczba URL, dostęp do GSC i logów serwera, liczba integracji
Wdrożenie optymalizacji	1800–7000 zł	liczba szablonów i modułów, hosting, zakres zmian na frontendzie
Stała opieka techniczna	700–2600 zł/mc	SLA i czas reakcji, liczba zmian w miesiącu, zakres monitoringu

Przeliczenie na konkretach: audyt 10 h × 150 zł = 1500 zł netto. Wdrożenie 22 h × 170 zł = 3740 zł netto. Opieka 6 h miesięcznie × 160 zł = 960 zł netto/mc.

PrestaShop a WooCommerce. WooCommerce bywa tańszy na starcie — podstawy (cache, WebP, wycięcie zbędnych skryptów) domyka się w 4–8 h, bo na rynku są gotowe, tanie rozwiązania. Przy skalowaniu role się odwracają: 1500 produktów z wariantami i filtrami wymaga w WooCommerce własnych zapytań i mocniejszego hostingu, więc koszt wdrożenia rośnie i zbliża się do 7000 zł. PrestaShop narzuca strukturę kategorii i wariantów od początku — więcej pracy na wejściu, mniej niespodzianek później.

Kwota zależy przede wszystkim od liczby URL, liczby szablonów i integracji — rozkładamy je w kolejnej sekcji. Aktualny SEO techniczne i optymalizacja szybkości w Zamościu dla firm opisujemy zawsze jako zakres godzinowy, żebyś mógł porównać oferty punkt po punkcie, a nie po cenie końcowej.

Co składa się na wycenę — 7 czynników, które realnie zmieniają koszt

Rozrzut widełek nie jest przypadkowy. Poniżej siedem rzeczy, które przesądzają o liczbie godzin — sprawdź je przed rozmową z wykonawcą, bo na większość masz wpływ.

1. Platforma i stopień jej modyfikacji. Czysta instalacja PrestaShop 8 to inna rozmowa niż sklep z 30 modułami i nadpisanym szablonem. Każdy plik nadpisany w motywie (np. templates/catalog/product.tpl) trzeba obejrzeć ręcznie, a aktualizacja modułu potrafi cofnąć wcześniejsze optymalizacje.

2. Liczba URL. Policz produkty, kategorie, warianty rozmiaru i koloru oraz listingi filtrów typu /sklep?q=rozmiar-42. Filtry generują tysiące kombinacji, których Google nie powinien indeksować. Bez noindex i porządnego canonical bot crawuje je godzinami, a log serwera pokazuje powroty na te same adresy.

3. Hosting. Na shared bez SSH, bez własnego php.ini, bez OPcache i Redis część optymalizacji jest po prostu niewykonalna. Realny efekt: LCP 4,8 s na shared, po przenosinach na VPS z dyskiem NVMe i PHP 8.2 z OPcache — 1,9 s. Same przenosiny to jednak osobna pozycja w wycenie, zwykle 3–5 h.

4. Wtyczki i moduły. Dwa pluginy do cache, dwa do minifikacji, trzy lądujące własnym CSS i JS na każdej podstronie. Diagnostyka: zakładka Coverage w Chrome DevTools plus Query Monitor lub profiler PrestaShop.

5. Integracje z ERP (Subiekt, Comarch), płatnościami i kurierami (InPost, DPD, DHL). Częsty sprawca wolnego startu to skrypt kuriera ładowany synchronicznie w sekcji head. Mierzy się to waterfallem w DevTools i logami błędów API — to nie zgadywanie, to pomiar.

6. Dane strukturalne i szablony. Te same opisy od producenta na wszystkich podstronach, brak canonical, migracja bez przekierowań 301 i setki 404. Punkt odniesienia: obsługiwane przez Google typy danych strukturalnych.

7. Środowisko pracy. Brak stagingu i backupu oznacza, że każda zmiana idzie na produkcję, a testy trwają dłużej. Brak dostępu do logów serwera wydłuża audyt o 2–3 h.

Czynnik	Jak to sprawdzić	Dlaczego zmienia cenę
Platforma i modyfikacje	lista modułów, porównanie szablonu z domyślnym	nadpisane pliki trzeba analizować ręcznie
Liczba URL	Screaming Frog albo licznik w GSC	więcej adresów = dłuższe crawlowanie i audyt
Hosting	test dostępu do SSH, OPcache, Redis, PHP 8.2+	bez dostępu do serwera część prac jest niewykonalna
Wtyczki i moduły	DevTools → Coverage, Query Monitor	konflikty wydłużają diagnozę
Integracje	waterfall, logi API	skrypty blokujące render to częsty sprawca LCP
Dane strukturalne i szablony	raport indeksowania, kontrola canonical	duplikaty i brak 301 generują dodatkową pracę
Środowisko pracy	staging, backup, dostępy	testy na produkcji trwają dłużej i są ryzykowne

Trzy warianty współpracy: audyt, wdrożenie, opieka — co dokładnie kupujesz

To trzy różne produkty, nie stopnie jednego pakietu. Możesz kupić tylko audyt i wdrożyć poprawki własnym deweloperem — to sensowna droga, jeśli masz kogoś na miejscu.

Audyt (900–2500 zł netto). Dostajesz raport z listą problemów, każdy z priorytetem i szacunkiem godzinowym: P1 blokuje indeksację lub LCP, P2 to porządki, P3 odkładamy. W środku: crawl całego serwisu, analiza GSC (raport indeksowania i Core Web Vitals), logi serwera, sprawdzenie canonical, przekierowań i danych strukturalnych. Uwaga na pułapkę: audyt bez dostępu do GSC i logów to lista domysłów.

Wdrożenie (1800–7000 zł netto). Zakres, który realnie zajmuje czas: konwersja obrazów do WebP i poprawne rozmiary, cache serwerowy (OPcache, Redis, ewentualnie Varnish) plus cache aplikacyjny, optymalizacja bazy (indeksy, czyszczenie tabel logów i sesji), ograniczenie zapytań zewnętrznych — self-hosting fontów, lazy loading dla osadzonych filmów, odcięcie skryptów tam, gdzie nie są potrzebne. Cel to poprawa LCP, INP i CLS mierzona na rzeczywistych danych, nie na wyniku jednego testu. Definicje wskaźników: Web Vitals na web.dev. Jeśli działasz też poza Zamościem, np. sprzedajesz w Hrubieszowie, zakres prac dla mniejszego rynku opisujemy osobno w materiale o SEO technicznym i optymalizacji szybkości w Hrubieszowie.

Opieka (700–2600 zł netto/mc). Stały zakres: monitoring dostępności, kontrola Core Web Vitals, aktualizacje modułów z testem na stagingu, przegląd logów błędów, pula 2–4 h prac rozwojowych. SLA ustalamy na piśmie — typowo reakcja do 4 h w godzinach pracy, a awaria sklepu traktowana jest priorytetowo.

Czego w cenie nie ma:

• przebudowy szablonu i nowego layoutu,
• nowych funkcji sklepu (konfigurator, program lojalnościowy),
• migracji na inną platformę,
• tworzenia treści — opisów produktów i tekstów kategorii,
• kampanii Ads i link buildingu.

Kiedy opieka jest zbędna: sklep z 50–100 produktami, bez zmian w kodzie i z stabilnym hostingiem — jednorazowe wdrożenie wystarcza na rok lub dłużej. Kiedy jej brak kosztuje więcej: 1000+ URL, integracje z ERP i kurierami, codzienne zamówienia. Sklep robiący 20 zamówień dziennie po 180 zł traci przy 6-godzinnym przestoju 3–5 zamówień, czyli 540–900 zł, plus czas na odbudowę pozycji.

SEO techniczne a optymalizacja szybkości — co się zazębia, a co kupujesz osobno

Przyspieszenie strony to nie całe SEO techniczne — i odwrotnie. Wspólny mianownik to Core Web Vitals: LCP (czas do wyrenderowania największego elementu), INP (opóźnienie reakcji na klik lub dotyk) i CLS (przesuwanie się układu). Google traktuje je jako jeden z elementów oceny strony, a nie osobny projekt — progi i sposób pomiaru opisuje dokumentacja Web Vitals na web.dev. W praktyce poprawa LCP przez odchudzenie szablonu produktu to ta sama praca, która odblokowuje indeksację: mniej blokującego CSS, mniej zapytań do bazy na listingu kategorii, poprawnie ustawiony cache.

Druga połowa SEO technicznego to blok indeksacyjny i ten styka się z szybkością tylko częściowo:

• robots.txt i sitemap.xml — sitemapa powinna zawierać wyłącznie kanoniczne adresy produktów, bez parametrów sortowania,
• canonical i paginacja — każda strona listingu wskazuje na siebie, nie na stronę pierwszą,
• parametry filtrów i sortowania (?orderby=, ?q=, ?page=) — najczęstsze źródło tysięcy duplikatów w PrestaShop. Rozwiązanie to noindex,follow albo blokada w robots.txt, rzadziej canonical do wersji bazowej,
• dane strukturalne Schema.org: Product z Offer (price, priceCurrency, availability) oraz AggregateRating. Bez tego nie ma rozszerzonych wyników z ceną i gwiazdkami — typy obsługiwane przez Google są wypisane w galerii danych strukturalnych Search Central.

Kiedy połączyć oba zakresy w jedno zlecenie: sklep do około 500 URL, jeden szablon produktu, brak trwającej migracji. Wtedy oba zakresy dotykają tych samych plików motywu i konfiguracji serwera, a rozdzielenie ich między dwie firmy kończy się konfliktem — jedna przyspiesza to, co druga chce przebudować.

Kiedy rozdzielić: katalogi 5000+ URL oraz sklepy w trakcie migracji platformy. Indeksacja czeka tam na decyzje o strukturze adresów, a przyspieszenie na infrastrukturę. Wciśnięcie tego w jedno zlecenie rozmywa priorytety i opóźnia jedno i drugie. Typowy punkt startowy dla firm z regionu opisuje SEO techniczne i optymalizacja szybkości w Zamościu.

Jak wygląda proces krok po kroku i ile trwa

Prace techniczne mają sześć etapów i każdy kończy się konkretnym plikiem albo liczbą. To nie sprint „na wyczucie”.

1. Pomiar „przed” (1–2 dni). Zapisujemy LCP, INP i CLS z PageSpeed Insights (dane laboratoryjne) oraz z raportu Core Web Vitals w Search Console (dane terenowe, okno 28 dni). Do tego: liczba zaindeksowanych URL, liczba adresów w sitemapie, TTFB. Wszystko w jednym arkuszu z datą.
2. Audyt (3–10 dni roboczych dla sklepu do 500 URL; przy 5000+ URL i wielu szablonach dłużej). Wynik: lista problemów z szacunkiem godzin przy każdym punkcie.
3. Priorytetyzacja (1 dzień, wspólnie z klientem). Sortujemy po stosunku efektu do nakładu. Typowa kolejność: konfiguracja serwera i cache, kompresja i format obrazów (WebP/AVIF), usunięcie zbędnych skryptów third-party, uporządkowanie parametrów filtrów.
4. Wdrożenie (2–6 tygodni). PrestaShop 1.7 z kupionym motywem to zwykle 2–3 tygodnie. PrestaShop 8.x z motywem pisanym na zamówienie i kilkoma szablonami kategorii — 4–6 tygodni. Każda zmiana najpierw na staging.
5. Ponowny pomiar (dzień po wdrożeniu plus kontrola po 28 dniach). Te same URL-e, te same narzędzia, osobno mobile i desktop. Dane terenowe potrzebują pełnego okna, dlatego pierwszy odczyt bywa niepełny — progi tych wskaźników wyjaśnia dokumentacja Core Web Vitals w Google Search Central.
6. Stabilizacja (2–4 tygodnie). Monitoring błędów 404 i 500, sprawdzenie indeksacji nowych adresów, potwierdzenie, że cache nie serwuje zalogowanym treści przeznaczonej dla gości.

Na każdym etapie klient dostaje raport, harmonogram z datami i kontakt bezpośrednio z deweloperem, który realizuje zadanie — nie przez trzy warstwy pośredników. Zdarza się, że klient pyta o zakres dla mniejszego miasta; podobny układ prac opisuje SEO techniczne i optymalizacja szybkości w Lublinie.

Pułapki w tanich ofertach — jak je wykryć przed zapłatą

Oferta tańsza o 1500 zł bywa droższa o 5000 zł, jeśli po pół roku trzeba wracać do punktu wyjścia. Poniżej pytania kontrolne — zadaj je przed podpisaniem umowy, nie po pierwszej fakturze.

• „Czy dostanę zapisane wartości LCP, INP, CLS i liczbę zaindeksowanych URL przed startem?” Jeśli wykonawca nie mierzy bazy, nie ma jak udowodnić efektu. Poproś o arkusz z datą i konkretnymi adresami, nie o zrzut ekranu z jednego dnia.
• Agresywny cache bez kontroli serwera. Pełnopage cache włączony globalnie to klasyczny błąd: zalogowany klient B2B widzi ceny detaliczne albo koszyk innej osoby. Test jest prosty — zaloguj się na konto hurtowe, wejdź na kartę produktu i odśwież dwa razy. Sprawdź nagłówek Cache-Control na zalogowanym koncie: powinno być private lub no-store.
• „Wtyczka przyspieszająca” jako cała usługa. Ma sens, gdy problemem są nieskompresowane obrazy i brak cache. Nie pomoże, gdy listing kategorii generuje 400 zapytań do bazy — zamaskuje problem do pierwszego wzrostu ruchu.
• Dokładanie kolejnych wtyczek zamiast jednego własnego modułu. Po pół roku masz 12 wtyczek, konflikty po aktualizacji i 2 MB JavaScriptu więcej niż na starcie. Jeden moduł pisany pod sklep jest tańszy w utrzymaniu niż pięć cudzych.
• Optymalizacja bez dostępu do GSC i logów serwera. Bez Search Console nie wiesz, które adresy mają problem z indeksacją, bez logów nie wiesz, co Google faktycznie pobiera. Zapytaj wprost: „Czy poprosicie o te dostępy w pierwszym tygodniu?”
• Brak przekazania dostępu i dokumentacji po zakończeniu. Powinieneś dostać konto administratora, dostęp do repozytorium, opis zmian i instrukcję odtworzenia konfiguracji. Bez tego zmiana wykonawcy to 2–4 tygodnie płatnego rozpoznania. Te same pytania warto zadać niezależnie od tego, czy szukasz firmy w Zamościu, czy mniejszym mieście — zakres prac opisuje też SEO techniczne i optymalizacja szybkości w Hrubieszowie.

Zrobić samemu czy zlecić? Uczciwa kalkulacja czasu i ryzyka

Zanim wyślesz zapytanie o wycenę, policz godziny. Trzy najczęstsze zadania techniczne w sklepie wyglądają tak: konwersja obrazów do WebP i poprawa ich wymiarów — 3–8 h przy katalogu do 500 zdjęć, konfiguracja cache (LiteSpeed Cache, Nginx FastCGI Cache, Redis Object Cache) na VPS — 4–10 h, poprawa danych strukturalnych Product/Offer/BreadcrumbList — 2–6 h. To czasy osoby, która robi to co tydzień. Jeśli robisz to pierwszy raz, pomnóż przez dwa i dodaj wieczór na testy po wdrożeniu.

Koszt błędu jest większy niż koszt pracy. Źle napisana reguła przekierowań (wszystko na stronę główną albo pętla 301) potrafi wyciąć z indeksu kilkaset adresów naraz. Cache włączony bez wykluczeń dla koszyka i checkoutu pokazuje klientom stare ceny. Efekt: sklep wypada z indeksu na tygodnie, a powrót na pozycje trwa dłużej niż sama poprawka. Przy danych strukturalnych błąd widać szybciej — Google raportuje go w Search Console i wyłącza oznaczenia w wynikach. Listę obsługiwanych typów znajdziesz w dokumentacji Google dotyczącej danych strukturalnych.

• DIY ma sens, gdy: katalog to około 200 produktów, szablon jest prosty (bez modyfikacji rdzenia motywu), a hosting ma panel (cPanel, DirectAdmin) i wsparcie techniczne, które odpowie na pytanie o konfigurację cache.
• DIY kosztuje więcej niż zlecenie, gdy: masz moduły niestandardowe (konfigurator, cenniki B2B), integrację ERP (Subiekt, Comarch, WMS) albo kilka języków i walut. Wtedy każda zmiana w motywie dotyka logiki zamówień, a błąd wychodzi dopiero przy realizacji.

Praktyczna zasada: rób sam to, co da się cofnąć jednym kliknięciem w panelu. Resztę — szczególnie przekierowania, cache i dane strukturalne — zlecaj z backupem i środowiskiem testowym. Zakres takich prac i punkt startowy opisujemy na stronie SEO techniczne i optymalizacja szybkości w Zamościu.

Dlaczego firmy z Zamościa i Lubelszczyzny wybierają lokalnego wykonawcę

Najczęstszy układ wygląda tak: agencja z Warszawy, podwykonawca i dwie warstwy komunikacji. Płacisz wtedy nie tylko za pracę, ale też za obsługę klienta — zwykle 15–25% narzutu, którego nikt nie nazywa po imieniu. Praca bezpośrednio z deweloperem ucina to: jedna osoba robi audyt, wdraża poprawki i odpowiada za efekt. Przy stawce 130–230 zł netto za godzinę każda dodatkowa warstwa to realne pieniądze w budżecie.

Drugi powód jest praktyczny: możliwość spotkania na miejscu. Czasem szybciej jest usiąść z klientem przy jednym ekranie w Zamościu niż wymieniać trzydzieści maili o to, jak wygląda panel hostingu. Po ustaleniu zakresu dalsza praca idzie zdalnie — przez dostęp SSH/SFTP do serwera albo przez kopię na stagingu, jeśli nie chcesz dawać dostępu do produkcji.

Zakres prac i stawka są identyczne niezależnie od tego, czy firma jest z Zamościa, Biłgoraja, Narola czy Tomaszowa Lubelskiego. Nie ma dopłaty za dojazd w wycenie godzinowej ani osobnego cennika dla mniejszych miejscowości. Różni się tylko forma kontaktu — stacjonarnie albo zdalnie.

To samo podejście stosujemy u klientów z Lublina, gdzie sklepy są większe i częściej pracują na VPS, oraz w Hrubieszowie. W obu przypadkach punktem wyjścia jest liczba godzin, nie gotowy pakiet.

Jak przygotować się do wyceny, żeby dostać konkretną kwotę w 24–48 h

Żeby dostać kwotę, a nie widełki od–do, wyślij komplet danych w jednej wiadomości. Wtedy wycena wraca w 24–48 h i nie zjada dwóch tygodni na dopytki.

• Adres strony — produkcja i ewentualny staging.
• Platforma i wersja: PrestaShop 1.7.8 lub 8.1, WooCommerce wraz z wersją WordPressa i PHP.
• Liczba produktów, wariantów, kategorii i szablonów.
• Hosting: dostawca, typ (shared, VPS, dedykowany) i panel.
• Dostawca ERP: Subiekt GT/nexo, Comarch Optima, WF-Mag albo integracja własna.
• Metody płatności i kurierzy: Przelewy24, PayU, InPost, DPD, DHL — każda integracja to osobne miejsce do sprawdzenia.

Do tego dostęp do Google Search Console i Google Analytics 4. Jeśli nie chcesz udostępniać kont, wystarczy zrzut raportów z ostatnich trzech miesięcy. Bez danych o tym, które adresy generują ruch, audyt techniczny zamienia się w zgadywanie.

Napisz też trzy cele biznesowe. Nie „poprawić SEO”, a na przykład: szybsze ładowanie na mobile (LCP poniżej 2,5 s), wejście na wybrane frazy lokalne, wypłaszczenie sezonowych skoków ruchu przed świętami. Cele ustalają kolejność prac — przy ograniczonym budżecie najpierw robi się to, co dotyka pieniędzy.

Oferty porównuj po godzinach razy stawka, nie po kwocie końcowej. 2000 zł przy 15 h to 133 zł/h; 4000 zł przy 25 h to 160 zł/h — ale druga oferta może zawierać monitoring i SLA reakcji. Pytaj wprost: ile godzin, na co, co jest poza zakresem i co się dzieje, gdy poprawka nie przyniesie efektu. Tak samo wyceniamy projekty w Biłgoraju i w Narolu.

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

Lista kontrolna do odklikania

• Liczba URL w indeksie — Otwórz w GSC raport „Indeksowanie stron”. Dla sklepu do 500 URL audyt mieści się w dolnych widełkach 900–2500 zł netto.
• Platforma i stopień jej modyfikacji — Policz moduły w PrestaShop albo wtyczki w WooCommerce i sprawdź, czy szablon był nadpisywany. 30 modułów to inny czas pracy niż czysty sklep.
• Dostęp do serwera — Zapytaj hosting, czy masz SSH, dostęp do cache serwerowego i konfiguracji PHP. Bez tego część optymalizacji jest po prostu niewykonalna.
• Integracje zewnętrzne — Wypisz ERP, bramki płatności i kurierów (InPost, DPD, DHL). Sprawdź w DevTools, ile czasu zabiera każde wywołanie i czy nie blokuje renderowania.
• Core Web Vitals — Sprawdź LCP, INP i CLS w PageSpeed Insights oraz w GSC, osobno dla mobile i desktopu, na kilku reprezentatywnych podstronach.
• Dane strukturalne — Zweryfikuj Product, BreadcrumbList i Organization w narzędziu testowania wyników Google. Sprawdź, czy znaczniki nie dublują się z wtyczką SEO.
• Canonical i duplikaty treści — Sprawdź listingi filtrowane i posortowane — czy mają canonical wskazujący na wersję bazową, czy indeksują się jako osobne strony.
• robots.txt i sitemap.xml — Otwórz oba pliki. Upewnij się, że robots.txt nie blokuje zasobów potrzebnych do wyrenderowania strony, a sitemap zawiera tylko adresy zwracające 200.
• Przekierowania po migracji — Sprawdź 301 dla starych adresów URL. Brak przekierowań to najczęstsza przyczyna spadku ruchu po zmianie platformy lub szablonu.
• Waga obrazów — Sprawdź, czy pliki są w WebP lub AVIF i czy nie ładujecie obrazu w rozmiarze większym niż kontener, w którym się wyświetla.
• Zapytania zewnętrzne — Policz skrypty firm trzecich (czat, analityka, piksele remarketingowe) ładowane na każdej podstronie. Każde z nich to dodatkowe kilkadziesiąt kilobajtów.
• SLA w ofercie opieki — Sprawdź czas reakcji (np. 4 h w godzinach pracy) i to, co dokładnie obejmuje abonament 700–2600 zł netto miesięcznie.
• Lista wyłączeń — Upewnij się, że oferta wprost mówi, iż nie obejmuje przebudowy szablonu, nowych funkcji sklepu, migracji na inną platformę ani tworzenia treści.

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