Programista WooCommerce w Szczecinie

Prowadzisz sklep WooCommerce i sprzedajesz ze Szczecina, do Niemiec po drugiej stronie Odry albo w całej Polsce. Buduję i naprawiam sklepy oparte o WordPress i WooCommerce tak, żeby checkout, płatności, dostawy i faktury działały zgodnie z tym, czego oczekuje polski kupujący, a sklep przetrwał aktualizacje Woo bez grzebania w plikach rdzenia.

Ta strona dotyczy jednej usługi, czyli programowania WooCommerce dla firm ze Szczecina i regionu zachodniopomorskiego. Lokalny kontekst pojawia się tu po to, żeby ustawić priorytety techniczne, a nie żeby udawać znajomość rynku.

#Programista WooCommerce dla sklepów ze Szczecina

Szczecin leży kilkanaście kilometrów od granicy z Niemcami, a port Szczecin-Świnoujście robi z miasta naturalny węzeł handlu i logistyki. To zmienia profil typowego sklepu, z którym pracuję. Sprzedawca z lewobrzeżnego Szczecina równie często wysyła paczkę do Pasewalku czy Berlina, co do Poznania, więc checkout musi obsłużyć równolegle polskiego i niemieckiego kupującego, dwie waluty, dwie logiki podatkowe i dwa zestawy oczekiwań co do płatności.

Konkretne braki, które najczęściej znajduję w istniejących sklepach WooCommerce z regionu:

• Brak BLIK i Przelewy24 jako domyślnych metod, przez co polski kupujący trafia na sam przelew tradycyjny albo kartę i porzuca koszyk. BLIK i P24 (lub PayU, Autopay) powinny być na górze listy, nie na końcu.
• Brak punktów odbioru InPost (Paczkomaty) w checkoucie. Dla zamówień krajowych to dziś domyślny wybór dostawy, a nie opcja dodatkowa.
• Faktura VAT generowana ręcznie albo wtyczką, która nie jest przygotowana na KSeF. Od 1 lutego 2026 obowiązek wystawiania faktur ustrukturyzowanych objął największych podatników, a od 1 kwietnia 2026 pozostałych płatników VAT, więc sklep musi umieć przekazać dane faktury do systemu zewnętrznego z numerem KSeF.
• Sprzedaż do Niemiec rozliczana tak samo jak krajowa, bez progu i procedury OSS dla VAT od sprzedaży wysyłkowej w UE.

#Co realizuję

• Dedykowany checkout: skrócona ścieżka, BLIK i Przelewy24/PayU/Autopay jako pierwsze metody, pole NIP do faktury, walidacja kodu pocztowego pod strefy dostawy
• Integracja punktów odbioru InPost (mapa Paczkomatów koszyku), Paczki Allegro, kurierów DPD i DHL ze strefami i regułami waga/wymiary
• Most do fakturowania: przekazanie zamówienia do systemu księgowego (Subiekt GT/nexo, Comarch, fakturownia.pl) i do KSeF, z numerem KSeF zapisanym przy zamówieniu
• Sprzedaż transgraniczna: druga waluta, ceny brutto zgodne z oczekiwaniem niemieckiego kupującego, obsługa VAT OSS dla wysyłki do UE
• Synchronizacja stanów i ofert z Allegro oraz integracje przez BaseLinker tam, gdzie sklep sprzedaje wielokanałowo
• Rozszerzenia WooCommerce REST API pod headless storefront, aplikację albo system magazynowy, bez modyfikacji rdzenia

#Rynek i zaplecze techniczne w Szczecinie

Szczecin nie jest już tylko stocznią i portem. Działa tu Klaster IT Pomorze Zachodnie skupiający blisko 90 firm z branży, z biurem w Technoparku Pomerania przy ulicy Cyfrowej. Zachodniopomorski Uniwersytet Technologiczny, który w maju 2026 obchodził 80-lecie, oraz Uniwersytet Szczeciński zasilają lokalny rynek programistów i specjalistów e-commerce. Dla sklepu to znaczy tyle, że stos technologiczny nie musi być zachowawczy: znajdziesz tu zespół utrzymujący headless storefront na Astro czy Next.js, a nie tylko klasyczny motyw na PHP.

Z drugiej strony duża część sklepów regionie to firmy handlowe i produkcyjne związane z portem i logistyką, dla których WooCommerce jest dodatkiem do istniejącego systemu ERP albo Subiekta, a nie sercem firmy. Tam priorytetem jest niezawodna synchronizacja stanów i poprawna faktura, nie efektowny frontend. Te dwa profile klienta wymagają innej architektury, więc pierwsze pytanie zawsze brzmi: czym dla Twojej firmy jest ten sklep.

Bliskość granicy ma jeszcze jeden praktyczny skutek. Sklep ze Szczecina, który chce sprzedawać przez Odrę, częściej niż sklep z głębi kraju potrzebuje od pierwszego dnia dwujęzycznego frontendu i niemieckiej ścieżki płatności, a nie dokłada tego po roku. Lepiej zaplanować to w architekturze na starcie niż przebudowywać checkout, gdy zamówienia z Niemiec zaczną przychodzić, bo dokładanie drugiej waluty i strefy OSS do dojrzałego sklepu jest droższe niż uwzględnienie ich w specyfikacji.

#Standardy techniczne

Stos sklepowy to WooCommerce na PHP 8.2 lub nowszym, z object cache na Redis, wyszukiwarką produktów wydzieloną z bazy przy większych katalogach i CDN przed warstwą statyczną. Rozszerzenia idą przez hooki action i filter oraz osobną wtyczkę funkcjonalną, z czytelną granicą między rdzeniem Woo, kodem wtyczki i kodem motywu. Procesy w tle (synchronizacja, e-maile, eksport do KSeF) obsługuje Action Scheduler, żeby checkout nie czekał na zewnętrzne API.

#Jak wygląda współpraca

Pracuję w krótkich iteracjach z demem na koniec każdego etapu, ale kolejność jest stała:

1. Audyt istniejącego sklepu: taksonomia produktów, ścieżka checkoutu, aktywne bramki, strefy dostaw, sposób wystawiania faktur, integracje z księgowością i Allegro, pomiar Lighthouse na najczęściej odwiedzanych stronach produktu i kategorii.
2. Specyfikacja: decyzje architektoniczne, wybór bramek i przewoźników, sposób przekazania danych do KSeF, granica między rdzeniem a kodem własnym, kryteria odbioru. Zatwierdzasz plan, zanim zacznie się kodowanie.
3. Implementacja w gałęziach funkcyjnych, zgodnie ze standardami kodowania WordPress i WooCommerce, z testami na ścieżkach płatności i zamówień.
4. Przegląd na środowisku testowym identycznym z produkcją: testujesz prawdziwy checkout, weryfikujesz integracje, zatwierdzasz do uruchomienia.
5. Wdrożenie i opieka: udokumentowany proces wydania z przetestowaną ścieżką wycofania, a po stabilizacji opcjonalny abonament utrzymaniowy.

#Typowe problemy, z którymi przychodzą sklepy z regionu

• Faktura nie trafia do KSeF albo dane są niekompletne (brak NIP nabywcy, zła stawka). Porządkuję zbieranie NIP w checkoucie i przekazanie zamówienia do systemu wystawiającego fakturę ustrukturyzowaną.
• Wysoki odsetek porzuceń na płatności, bo brakuje BLIK i Paczkomatów. Po dołożeniu obu metod ścieżka skraca się o kilka kroków, a porzucenia spadają.
• Rozjazd stanów magazynowych między sklepem, Allegro i magazynem. Buduję synchronizację z rozwiązywaniem konfliktów i logiem zmian, zwykle przez BaseLinker albo bezpośrednie API.
• Sprzedaż do Niemiec rozliczana błędnie pod VAT, bez progu OSS i bez poprawnych cen brutto. Konfiguruję drugą strefę podatkową i walutę.

#Czego możesz oczekiwać

Zamiast obietnic procentowych podaję mierzalne kryteria, które ustalamy na starcie i sprawdzamy po wdrożeniu: stabilny czas ładowania stron produktu i kategorii w polu Core Web Vitals, kompletna ścieżka koszyk → płatność → zamówienie → faktura → e-mail działająca na każdej aktywnej bramce, poprawne przekazanie faktury do KSeF z zapisanym numerem oraz zgodna z OSS sprzedaż do UE. Co dokładnie mierzymy, zależy od sklepu, dlatego liczby wpisujemy do specyfikacji, a nie do oferty.

#Bezpieczeństwo i obsługę wymagań RODO

Sklep przetwarza dane osobowe i dane płatnicze, więc bezpieczeństwo jest częścią architektury, nie dodatkiem. W praktyce oznacza to: parametryzację zapytań do bazy przeciw SQL injection, escapowanie wyjścia przeciw XSS, weryfikację nonce na formularzach, limitowanie prób na endpointach logowania i koszyka oraz reguły WAF dostrojone do typowych wektorów ataku na WordPress. Pod RODO porządkuję podstawę zbierania danych w checkoucie, retencję zamówień i zgody marketingowe, a płatności przechodzą przez bramkę zgodną z PCI DSS, żeby dane kart nie dotykały Twojego serwera.

#Wydajność i Core Web Vitals

Core Web Vitals wpływają na pozycję w Google i na konwersję, a strony WooCommerce psują je najczęściej na trzech polach: ciężki motyw, fragmenty koszyka blokujące cache oraz nieoptymalizowane zdjęcia produktów. Pracę zaczynam od pomiaru (Lighthouse plus profil WP-CLI i Query Monitor na realnych stronach), żeby znaleźć rzeczywisty bottleneck, zamiast dokładać kolejną wtyczkę cache. Dalej idzie optymalizacja ścieżki krytycznej, obrazy w AVIF/WebP z jawnymi wymiarami przeciw przesunięciom layoutu (CLS), ograniczenie JavaScriptu pod responsywność interakcji (INP) i edge caching tam, gdzie treść jest statyczna. Regresje wyłapuje pomiar w procesie wdrożeniowym.

#Pytania, które zadają firmy ze Szczecina

Czy przygotujecie sklep pod KSeF? Sklep WooCommerce nie wystawia faktur ustrukturyzowanych sam, robi to system księgowy albo dedykowana usługa. Moja rola to poprawne zebranie danych do faktury w checkoucie (w tym NIP) i przekazanie zamówienia do systemu, który wystawia fakturę w KSeF i zwraca jej numer, zapisywany przy zamówieniu. Konkretne narzędzie dobieramy do Twojej księgowości.

Sprzedajemy też do Niemiec, ogarniecie płatności i podatki? Tak. Konfiguruję drugą walutę i strefę podatkową, ceny brutto zgodne z oczekiwaniem niemieckiego kupującego, popularne tam metody (PayPal, karty, przelew), oraz obsługę VAT OSS dla wysyłki wewnątrz UE. Polskim kupującym zostawiam BLIK, Przelewy24 i Paczkomaty.

Czy modyfikujecie rdzeń WooCommerce? Nie. Customizacje idą przez hooki i osobną wtyczkę, żeby sklep przetrwał aktualizacje Woo. Granica między rdzeniem, wtyczką i motywem zapada na etapie architektury i jest opisana w runbooku.

Czy zoptymalizujecie istniejący wolny sklep? Tak, i zaczynam od pomiaru, nie od zgadywania. Profil Lighthouse plus Query Monitor wskazuje, czy problem to motyw, autoload optionów, wolne zapytania wtyczek, czy waga obrazów, i rozwiązuję go u źródła.

Jak wygląda przekazanie projektu? Dostajesz żyjącą dokumentację dla managera sklepu i programisty, runbook dla każdej bramki i integracji oraz sesję przekazania. Sklep może potem trafić do Twojego zespołu albo na opcjonalny abonament opieki.

#Lokalne SEO dla sklepu ze Szczecina

Sklep musi być znaleziony, więc SEO jest częścią architektury od pierwszego szkicu: czyste adresy URL, mapa XML, poprawne canonical i hierarchia nagłówków, dane strukturalne Product, Offer i FAQ na kartach produktu. Dla firmy z fizycznym adresem w Szczecinie dokładam dane LocalBusiness, spójność NAP i Google Business Profile, a dla sprzedaży krajowej i niemieckiej hreflang oraz osobne metadane dla każdej wersji językowej. Treść układam tak, żeby strona kategorii odpowiadała na realne zapytanie zakupowe, a nie była pustą listą produktów.

#Wolny checkout w WooCommerce, diagnoza krok po kroku

Zgłoszenie brzmi zwykle “sklep działa wolno”, ale sam ten opis niczego nie lokalizuje. WooCommerce ma tę właściwość, że strona główna i kategoria potrafią być szybkie, a koszyk i zamówienie wolne, bo to zupełnie inne ścieżki wykonania. Dlatego diagnoza zaczyna się od rozdzielenia czasu odpowiedzi serwera od czasu renderowania w przeglądarce, a dopiero potem przechodzi do konkretnych warstw.

Krok 1: zmierz TTFB osobno dla trzech typów stron. Wystarczy curl -o /dev/null -s z opcją -w i zmienną time_starttransfer, wykonany na stronę produktu, na /koszyk/ i na /zamowienie/, żeby dostać trzy różne liczby. Jeżeli produkt odpowiada w kilkadziesiąt milisekund, a koszyk w sekundę i więcej, problem nie leży w cache stron, tylko w PHP i bazie. Przy sklepie prowadzonym ze Szczecina i sprzedającym za Odrę ten sam pomiar warto powtórzyć z węzła po niemieckiej stronie, bo pomiar z biura pokazuje opóźnienie sieci inne niż to, które widzi kupujący.

Krok 2: sprawdź, co omija cache. WooCommerce ustawia dla koszyka, zamówienia i konta klienta nagłówki oraz stałe wykluczające te widoki z cache, ale to, czy zostaną uszanowane, zależy od warstwy cache i CDN. Do tego dochodzą ciasteczka sesji (wp_woocommerce_session_, woocommerce_items_in_cart). Każde żądanie z takim ciasteczkiem idzie do PHP, więc po dodaniu produktu do koszyka cały ruch użytkownika przestaje być serwowany ze statycznej kopii. Jeśli konfiguracja cache na to nie patrzy, sklep przy większym ruchu potrafi wysycić całą pulę procesów PHP-FPM.

Krok 3: zobacz, ile kosztują fragmenty koszyka. Domyślnie motyw odświeża licznik koszyka wywołaniem wc-ajax=get_refreshed_fragments przy każdym wejściu na stronę. To żądanie z definicji nie jest cache’owane i uruchamia pełny bootstrap WordPressa. Na ciężkiej instalacji dokłada to setki milisekund do każdego widoku produktu. Jeżeli motyw pokazuje tylko liczbę pozycji, licznik można oprzeć na ciasteczku i wyłączyć odświeżanie fragmentów.

Krok 4: policz autoload w tabeli opcji. SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on') pokazuje, ile danych ładuje się przy każdym żądaniu. Warunek musi obejmować wszystkie warianty, bo od WordPressa 6.6 kolumna autoload przyjmuje także wartości on, auto i auto-on, a zapytanie ograniczone do 'yes' pominie opcje zapisane po tej zmianie i zaniży wynik. Sklepy, które przez lata zbierały wtyczki, ciągną tu resztki po odinstalowanych rozszerzeniach i transienty bez wygaśnięcia. To najtańsza do naprawienia pozycja na całej liście.

Krok 5: uruchom Query Monitor na prawdziwej sesji z produktem w koszyku. Interesują mnie dwie rzeczy: wolne zapytania i wywołania zewnętrznych API wykonane w trakcie żądania. Najczęstszą przyczyną jest synchroniczne odpytanie zewnętrznego systemu (kurier, kurs waluty, stan magazynowy z ERP) wpięte w hook, który wykonuje się przy renderowaniu koszyka. Domyślny timeout wp_remote_get to pięć sekund, więc jedno takie wywołanie potrafi unieruchomić szybki sklep, gdy zewnętrzne API zwolni. Rozwiązanie to przeniesienie odpytania do Action Scheduler i buforowanie odpowiedzi.

Krok 6: sprawdź wysyłkę maili. wp_mail działa synchronicznie. Jeżeli wtyczka SMTP wysyła potwierdzenie zamówienia w trakcie żądania, klient czeka na nawiązanie połączenia z serwerem pocztowym, zanim zobaczy stronę podziękowania. Wysyłka powinna trafić do kolejki, a nie do żądania generującego stronę.

Krok 7: obejrzyj kolejkę zadań. Tabela wp_actionscheduler_actions z dziesiątkami tysięcy rekordów stanie oczekiwania oznacza, że coś się nie przetwarza, a WP-Cron uruchamiany przy odsłonach dokłada tę pracę losowym użytkownikom. Poprawna konfiguracja to DISABLE_WP_CRON i systemowy cron po stronie serwera.

Do tego dochodzą dwie zmiany strukturalne: object cache na Redis, żeby opcje i transienty nie wracały do bazy przy każdym żądaniu, oraz HPOS, czyli przechowywanie zamówień w dedykowanych tabelach zamiast w wp_posts i wp_postmeta. Przy sklepie z długą historią zamówień samo to zmienia charakterystykę zapytań w panelu i w raportach. Każdą zmianę wprowadzam pojedynczo i mierzę ponownie, bo inaczej nie wiadomo, co pomogło, a co tylko zamaskowało objaw.

#Przejęcie sklepu po innym wykonawcy

Spora część zleceń to nie nowy sklep, tylko istniejąca instalacja, której dotychczasowy wykonawca przestał obsługiwać. Przejęcie ma stałą kolejność i pierwszy etap nigdy nie polega na zmianie kodu.

Inwentaryzacja dostępów. Spisuję wszystko, co trzyma sklep przy życiu: administrator WordPressa, panel hostingu, SSH i baza, rejestrator domeny i strefa DNS, repozytorium, panele bramek płatniczych (Przelewy24, PayU, Autopay, Stripe), konta kurierskie (InPost, DPD, DHL), system księgowy, konto Allegro lub BaseLinker, Search Console i analityka. Osobno sprawdzam licencje płatnych wtyczek i motywu, bo bywają zarejestrowane na koncie poprzedniego wykonawcy. Wygasła licencja oznacza brak aktualizacji, a przy rozszerzeniach do płatności to bezpośrednie ryzyko bezpieczeństwa, więc ten punkt idzie na początek listy.

Pełna kopia przed czymkolwiek. Zrzut bazy i wp-content, odtworzony i sprawdzony na osobnym środowisku. Dopiero na tej kopii pracuję.

Audyt tego, co faktycznie jest w plikach. wp core verify-checksums i wp plugin verify-checksums pokazują zmodyfikowane pliki rdzenia i wtyczek pobranych z repozytorium wordpress.org. Wtyczek komercyjnych to nie obejmie, więc dla nich pozostaje porównanie z czystą paczką od producenta. Do tego przegląd mu-plugins, drop-inów (object-cache.php, advanced-cache.php, db.php), rozmiaru functions.php motywu potomnego, stałych w wp-config.php, listy zaplanowanych zadań i kont administratorów. To właśnie tutaj najczęściej wychodzą zmiany wprowadzone bezpośrednio w plikach WooCommerce, a to one blokują aktualizacje.

Środowisko testowe z bezpieczną konfiguracją. Kopia produkcji na środowisku testowym musi mieć klucze bramek w trybie testowym i przechwytywanie poczty, inaczej testy przejęcia wyślą maile do prawdziwych klientów albo dotkną prawdziwych transakcji. Kopia bazy zawiera dane osobowe kupujących, więc pod RODO takie środowisko albo ma ograniczony dostęp i tę samą ochronę co produkcja, albo dane zostają poddane pseudonimizacji.

Kod pod kontrolę wersji. Motyw i własne wtyczki trafiają do repozytorium w stanie zastanym, jednym commitem. Od tego momentu każda kolejna zmiana jest widoczna w diffie, co przy przejęciu po kimś innym jest jedyną sensowną podstawą do rozmowy o tym, co się zepsuło i kiedy.

Plan wdrożenia i lista ryzyk na piśmie. Rozdzielam to, co trzeba naprawić od razu (nieaktualne PHP, wygasłe licencje, znane podatności, brak kopii zapasowych), od tego, co idzie do planu prac. Wdrożenie ma okno serwisowe, skrócony TTL w strefie DNS, jeśli zmienia się hosting, przetestowaną ścieżkę wycofania i smoke test pełnej ścieżki zamówienia zaraz po przełączeniu. Przy sklepie wysyłającym do Niemiec do tego testu wchodzi też co najmniej jedno zamówienie na adres zagraniczny, żeby sprawdzić stawkę podatku, koszt wysyłki i treść maili w drugiej wersji językowej. Koszt takiego przejęcia ustalam indywidualnie, bo zależy wprost od tego, co pokaże audyt.

#Rozpocznij projekt

Jeśli chcesz omówić sklep WooCommerce, opisz krótko obecną sytuację, cel biznesowy i ograniczenia: co sprzedajesz, dokąd wysyłasz, jak dziś wystawiasz faktury i gdzie sklep boli. Na tej podstawie sprawdzam konfigurację, wskazuję ryzyka i proponuję praktyczny plan, niezależnie od tego, czy to nowy sklep, migracja do architektury headless, czy stałe wsparcie. Wycena jest indywidualna i zależy od zakresu ustalonego w audycie.