Programista WordPress w Szczecinie

#Eksport i handel transgraniczny: co strona firmy ze Szczecina musi udźwignąć

Ze Szczecina do Berlina jest 130 km, do przejścia w Kołbaskowie kilkanaście minut jazdy. Dla firm z Pomorza Zachodniego rynek niemieckojęzyczny nie jest odległym kierunkiem ekspansji, tylko sąsiedztwem, w którym zapytanie ofertowe potrafi przyjść w poniedziałek rano po niemiecku i wymagać odpowiedzi jeszcze tego samego dnia. Strona internetowa jest w tym układzie pierwszym dokumentem handlowym, jaki widzi kontrahent z Brandenburgii, Meklemburgii, Danii czy Szwecji.

To przekłada się na konkretne wymagania techniczne, które w projektach czysto krajowych po prostu nie występują:

• Dwa lub trzy pełne języki, nie tłumaczenie automatyczne: wersja niemiecka musi mieć własne adresy URL, własne meta dane i własną strukturę nawigacji, a nie nakładkę tłumaczącą treść w przeglądarce.
• Ceny w walucie odbiorcy: EUR dla Niemiec i Austrii, NOK i DKK dla rynków skandynawskich, z jasnym rozdzieleniem cen netto i brutto, bo niemiecki klient B2C oczekuje ceny końcowej, a B2B netto.
• Rozliczenia zgodne z VAT OSS: właściwa stawka naliczona według kraju konsumenta, poprawny dokument sprzedaży, dane do deklaracji w jednym miejscu.
• Wysyłka za granicę policzona na etapie koszyka: DHL Paket, DPD, GLS, PostNord czy Bring wraz z realnym terminem doręczenia, a nie ogólnikowa informacja o wysyłce zagranicznej.
• Formalności prawne wersji niemieckiej: Impressum, Datenschutzerklärung, Widerrufsbelehrung, obowiązek podania ceny jednostkowej i jednoznaczny przycisk zamówienia z obowiązkiem zapłaty.

Każdy z tych punktów da się obsłużyć wtyczką z rynku. Problem zaczyna się wtedy, gdy trzeba je obsłużyć wszystkie naraz na jednej instalacji: wtyczka wielojęzyczna, wtyczka walutowa, wtyczka podatkowa i wtyczka kurierska zaczynają nadpisywać sobie te same filtry WooCommerce. Efektem jest sklep, w którym cena w koszyku różni się od ceny na karcie produktu, a przyczyna leży w kolejności wykonywania hooków. Rolą programisty jest tu rozstrzygnięcie tych kolizji w kodzie, a nie dokładanie kolejnej wtyczki.

#Rynek zachodniopomorski: port, offshore i Technopark Pomerania

Zespół portowy Szczecin-Świnoujście, Korytarz Bałtycko-Adriatycki i rozwój morskiej energetyki wiatrowej ustawiają profil lokalnych zleceniodawców inaczej niż w miastach o gospodarce usługowej. Znaczącą część zapytań generują tu producenci konstrukcji stalowych, agencje morskie, operatorzy logistyczni, firmy inżynieryjne i spółki obsługujące inwestycje offshore. Obok nich działa środowisko technologiczne skupione wokół Technoparku Pomerania oraz sektor usług dla klientów niemieckich: kliniki, hotele, kancelarie, warsztaty.

Konsekwencja dla warstwy webowej jest praktyczna. Firma produkcyjna potrzebuje katalogu wyrobów z parametrami technicznymi, kartami materiałowymi i certyfikatami do pobrania, a nie bloga. Operator logistyczny potrzebuje modułu statusu ładunku. Klinika obsługująca pacjentów z Niemiec potrzebuje formularza kwalifikacyjnego zgodnego z DSGVO i cennika czytelnego dla kogoś, kto porównuje ofertę z ofertą z Pasewalku. To trzy zupełnie różne projekty, które łączy tylko silnik CMS.

#Wielojęzyczność PL, DE i EN bez spadku wydajności

Wielojęzyczność jest najczęstszym miejscem, w którym szczecińskie serwisy tracą wydajność. Typowa wtyczka tłumacząca dokłada własne zapytania do bazy przy każdym renderowaniu menu, filtra i listy produktów. Przy trzech językach i rozbudowanym katalogu liczba zapytań potrafi wzrosnąć kilkukrotnie.

Nasze podejście do warstwy i18n:

1. Tagi hreflang generowane z jednego źródła prawdy: relacja między wersjami językowymi opisana raz, w strukturze danych, a nie ustawiana ręcznie na każdej podstronie. To eliminuje kanibalizację polskiej i niemieckiej wersji w wynikach wyszukiwania.
2. Przeliczanie walut z buforem: kursy NBP lub EBC pobierane cyklicznie i zapisywane lokalnie, z możliwością zamrożenia stałej ceny w EUR dla rynków, gdzie kontrahent oczekuje stabilnego cennika.
3. Formaty lokalne w formularzach: daty, numery telefonów, kody pocztowe i format adresu dopasowane do standardu niemieckiego i skandynawskiego, łącznie z walidacją po stronie serwera.
4. Czytelna struktura adresów: ścieżki językowe /de/, /en/, /nb/ z zachowaniem tej samej hierarchii kategorii, żeby przekierowania i raportowanie w Search Console dawały się porównywać między rynkami.
5. Tłumaczenia w plikach, nie w bazie: ciągi interfejsu motywu i wtyczek trzymane w plikach .po/.mo, dzięki czemu nie obciążają zapytań przy każdym wyświetleniu strony.

#Rozliczenia, podatki i wysyłka poza granicę Polski

Automatyzacja rozliczeń jest tą częścią projektu eksportowego, w której błąd kosztuje najwięcej, bo ujawnia się dopiero przy zamknięciu miesiąca. Integracje budujemy przez REST API i webhooki, z kolejkowaniem zadań:

• VAT OSS i dokumenty sprzedaży: stawka wyznaczana według kraju odbiorcy i statusu podatkowego, z zapisem podstawy decyzji przy zamówieniu, żeby księgowość mogła odtworzyć rozliczenie po miesiącach.
• Bramki płatności lokalne i międzynarodowe: Klarna (Pay Now, Pay Later, Slice It), PayPal, Stripe, Sofort, Vipps MobilePay, Apple Pay, Google Pay oraz polskie BLIK i Przelewy24.
• Systemy ERP i magazynowe: Comarch ERP Optima, Enova365, Subiekt GT/nexo oraz zagraniczne systemy księgowe (na przykład DATEV) do synchronizacji stanów i dokumentów.
• Spedycja: DHL Paket i Express, DPD, GLS, UPS, PostNord, Bring oraz InPost, z etykietami generowanymi po stronie sklepu.
• CRM i komunikacja posprzedażowa: HubSpot, Salesforce, Klaviyo, ActiveCampaign, z szablonami wiadomości w języku zamówienia.

Integracje pracują asynchronicznie, w kolejkach zadań. Chwilowa niedostępność serwera bankowego lub systemu kurierskiego nie przerywa wtedy ścieżki zakupowej, a nieudane wywołanie trafia do ponownej próby zamiast ginąć w logu.

#Przemysł morski i offshore: katalogi techniczne, certyfikaty, śledzenie ładunku

Dla firm związanych z portem i energetyką morską budujemy moduły, których nie ma w typowym sklepie:

• Katalog wyrobów i konstrukcji z filtrowaniem po parametrach technicznych, normie i materiale, z możliwością pobrania karty katalogowej w PDF.
• Rejestr certyfikatów i dopuszczeń z kontrolą dostępu, gdzie część dokumentacji jest widoczna publicznie, a część dopiero po zalogowaniu kontrahenta.
• Śledzenie ładunków i przesyłek morskich przez API typu Track and Trace oraz dane AIS, żeby klient sprawdzał status jednostki i planowane zawinięcie do Świnoujścia lub Szczecina bezpośrednio na stronie dostawcy usługi.
• Formularz zapytania ofertowego z załącznikami: rysunek techniczny, specyfikacja, zapytanie przetargowe, z walidacją rozmiaru plików i szyfrowanym zapisem poza katalogiem publicznym.

#Jak wygląda typowy projekt dla firmy z Pomorza Zachodniego

Poniżej trzy profile wdrożeń, które powtarzają się w tym regionie. To opisy zakresu i celów inżynierskich przyjmowanych na starcie projektu, nie relacje z konkretnych realizacji.

#Profil pierwszy: producent konstrukcji stalowych dla sektora offshore

Firma realizująca kontrakty dla farm wiatrowych na Bałtyku potrzebuje serwisu w trzech językach z bazą referencji, wykazem certyfikatów i dokumentacją do pobrania. Zakres obejmuje dedykowany motyw FSE, rejestr realizacji z filtrowaniem po typie konstrukcji oraz wersję niemiecką ze wszystkimi obowiązkami informacyjnymi. Cele przyjmowane na starcie: LCP poniżej 1 sekundy na łączu mobilnym, CLS równy zero na kartach realizacji, pełna obsługa katalogu z klawiatury.

#Profil drugi: sklep z wyposażeniem wnętrz sprzedający do Polski, Niemiec i Austrii

Sklep obsługujący trzy rynki mierzy się z rozjazdem cen między kartą produktu a koszykiem oraz z powolnym filtrowaniem katalogu. Zakres prac to przeniesienie zamówień na HPOS, uporządkowanie kolejności filtrów odpowiedzialnych za cenę i podatek, wdrożenie Redis Object Cache oraz konfiguracja VAT OSS i wysyłki DHL Paket. Cele: identyczna cena w każdym punkcie ścieżki zakupowej, czas odpowiedzi filtra katalogu poniżej 300 ms, INP w zielonym zakresie na urządzeniach mobilnych.

#Profil trzeci: kancelaria doradzająca inwestorom z Niemiec

Kancelaria potrzebuje bazy wiedzy prawnej w dwóch językach i systemu umawiania konsultacji. Zakres to motyw FSE z modułem artykułów eksperckich, kalendarz rezerwacji zintegrowany z pocztą zespołu i pełna zgodność z WCAG 2.1 AA. Cele: obsługa całego procesu rezerwacji bez myszy, poprawne odczytanie komunikatów formularza przez NVDA i VoiceOver, brak transferu danych do usług spoza UE.

#Własny motyw blokowy zamiast szablonu z giełdy

Gotowe motywy z giełd szablonów wnoszą do projektu eksportowego problem, którego nie widać na demo: ładują style i skrypty wszystkich wariantów układu, także tych nieużywanych. Przy katalogu technicznym i trzech językach ta nadmiarowość przekłada się bezpośrednio na czas ładowania u odbiorcy w Niemczech.

W projektach dla firm ze Szczecina budujemy motywy blokowe w standardzie Full Site Editing z plikiem theme.json:

• Tylko potrzebny kod: style i skrypty ładowane dla faktycznie użytych bloków, bez balastu wariantów, których nikt nie włączył.
• Zgodność z identyfikacją wizualną: typografia, kolory i siatka opisane w theme.json, więc redaktor nie może przypadkiem wyjść poza system.
• Wzorce synchronizowane: zespół samodzielnie składa nowe podstrony ofertowe i karty realizacji z gotowych modułów, w każdej wersji językowej.
• Aktualizowalność: kod zgodny z WordPress Coding Standards przechodzi kolejne wydania systemu bez ręcznych poprawek.

Zamiast starych bibliotek jQuery używamy nowoczesnego CSS (Grid, Flexbox, custom properties) i modułów JavaScript w standardzie ES6.

#Szybkość widziana z drugiej strony granicy

Ocena szybkości w Google opiera się na realnych pomiarach z przeglądarek użytkowników (Chrome User Experience Report). Dla firmy ze Szczecina istotne jest to, że pomiar dotyczy również odbiorców z Niemiec i Skandynawii, a więc dłuższej drogi sieciowej niż w ruchu krajowym.

Elementy, na których pracujemy:

1. LCP poniżej 1 sekundy: cache po stronie serwera, preload kluczowych fontów, obrazy w AVIF i WebP z jawnie podanymi wymiarami.
2. INP w zielonym zakresie: rozbicie długich zadań JavaScript, odsunięcie skryptów firm trzecich poza ścieżkę interakcji.
3. CLS równy zero: zarezerwowane miejsce dla grafik, banerów i modułów osadzanych.
4. Redis Object Cache: odciążenie MySQL przy rozbudowanych filtrach katalogu i przy trzech wersjach językowych.
5. Dystrybucja brzegowa: węzły Cloudflare w Berlinie, Frankfurcie, Sztokholmie i Warszawie skracające czas odpowiedzi dla odbiorców po drugiej stronie granicy.

#Dostępność cyfrowa według WCAG 2.1 AA i aktu EAA 2025

Europejski akt o dostępności obejmuje serwisy oferujące produkty i usługi konsumentom w Unii, co dotyczy zdecydowanej większości szczecińskich sklepów i firm usługowych sprzedających do Niemiec. Dostępność wdrażamy w kodzie, a nie w nakładce doklejanej skryptem:

• Obsługa z klawiatury: nawigacja, filtry katalogu i formularze zapytań w pełni operowalne bez myszy, z widocznym stanem fokusu.
• Semantyka i etykiety ARIA: komunikaty dynamiczne i stany interfejsu poprawnie odczytywane przez czytniki ekranu.
• Kontrast: współczynnik co najmniej 4.5:1 dla tekstu, sprawdzany na realnych zestawieniach kolorów, nie tylko w palecie.
• Audyt automatyczny i manualny: lintery dostępności w procesie budowania oraz przejście kluczowych ścieżek w NVDA i VoiceOver.

#Ochrona danych po obu stronach granicy: RODO i DSGVO

Niemiecki kontrahent zwraca uwagę na ochronę danych wcześniej niż na ofertę. Standard, który wdrażamy:

1. Consent Mode v2: skrypty analityczne i marketingowe zablokowane do momentu zgody, z zapisem jej treści i daty.
2. Zasoby serwowane lokalnie: fonty i biblioteki z własnego serwera w Unii, bez odwołań do infrastruktury poza EOG.
3. Hardening WordPressa: wyłączona edycja plików w panelu, ochrona wp-config.php, nagłówki CSP i HSTS, ograniczenie prób logowania.
4. Kopie zapasowe poza serwerem produkcyjnym: szyfrowane, codzienne, z okresowym testem odtworzenia, bo backup bez testu odtworzenia jest tylko założeniem.

#Headless z Astro lub Next.js, kiedy naprawdę ma sens

Architektura headless oddziela panel redakcyjny od warstwy prezentacji: WordPress zostaje jako CMS, a frontend budowany jest w Astro lub Next.js i serwowany jako statyczny HTML z sieci CDN. Panel administracyjny znika z publicznej sieci, co zamyka najczęstszy wektor ataku.

Warto o tym myśleć, gdy serwis jest silnie odwiedzany z zagranicy, zawiera dużo treści statycznej i ma zespół gotowy pracować w procesie z osobnym wdrożeniem frontendu. Nie warto, gdy strona zmienia się codziennie, a redakcja oczekuje natychmiastowego podglądu zmian. Ta odpowiedź zależy od zespołu, nie od technologii, i rozstrzygamy ją przed startem projektu, a nie w jego trakcie.

#Migracja ze starego CMS bez utraty pozycji w Google.de

Część zachodniopomorskich firm nadal pracuje na Typo3, Joomli lub bardzo starych instalacjach WordPressa, często z wersją niemiecką dopiętą na osobnej domenie. Migrację prowadzimy etapami:

• Przeniesienie treści: artykuły, aktualności, dokumentacja PDF i galerie z zachowaniem struktury katalogów plików.
• Mapowanie przekierowań 301: pełna lista starych adresów odwzorowana na nowe, osobno dla każdej wersji językowej, bo to właśnie tam ginie najwięcej wypracowanej widoczności.
• Scalenie domen językowych: przeniesienie wersji niemieckiej pod wspólną domenę z poprawnym hreflang, jeśli analiza widoczności to uzasadnia.
• Przejście na edytor blokowy: redakcja pracuje na wzorcach, bez konieczności dotykania HTML.

#Dane strukturalne i widoczność w wyszukiwarkach opartych na AI

Serwis przygotowujemy tak, żeby dawał się cytować generatywnym wyszukiwarkom:

• Schema LocalBusiness i Organization: dane rejestrowe firmy powiązane z encjami Wikidata, obszar obsługi opisany jawnie.
• Schema Service i FAQPage: opisy usług i odpowiedzi na pytania techniczne w każdej wersji językowej, nie tylko polskiej.
• Sygnały E-E-A-T: podpisani autorzy, data weryfikacji treści i odwołania do źródeł branżowych zamiast ogólników.

#Widoczność lokalna w Szczecinie i regionie transgranicznym

Dla usługodawców, klinik, hoteli i firm inżynieryjnych widoczność w wynikach lokalnych i w Mapach Google jest głównym źródłem zapytań:

• Kompletne dane LocalBusiness: adres, obszar obsługi, godziny pracy i powiązania z encjami Wikidata dla Szczecina.
• Zasięg regionalny: Śródmieście, Pogodno, Warszewo, Prawobrzeże, Dąbie, a poza miastem Police, Stargard, Goleniów, Świnoujście i Gryfino jako obszar, z którego realnie przychodzą zapytania.
• Wydajność mobilna: strona otwierana w drodze, często na łączu w rejonie przygranicznym, musi być użyteczna przy słabym zasięgu.

#Granica opłacalności, czyli kiedy gotowy motyw wystarczy

Nie każdy projekt w Szczecinie wymaga własnego kodu, i mówimy to przed wyceną, a nie po niej. Jeżeli firma potrzebuje jednojęzycznej strony informacyjnej z opisem usług, danymi kontaktowymi i formularzem, dobrze dobrany motyw blokowy z pakietem aktualizacji zamyka temat taniej i szybciej niż jakiekolwiek wdrożenie dedykowane. To samo dotyczy sklepu z kilkunastoma produktami sprzedawanymi wyłącznie w kraju.

Rachunek zmienia się w momencie, w którym pojawia się druga waluta, rozliczenie VAT OSS, integracja z ERP albo katalog liczony w tysiącach pozycji. Wtedy koszt obchodzenia ograniczeń gotowego motywu, kolejne wtyczki nadpisujące te same filtry i godziny spędzane na ręcznym poprawianiu danych przewyższają koszt napisania tego fragmentu raz i porządnie. Podobnie działa to przy wydajności: jeżeli słabe wyniki Core Web Vitals obniżają widoczność w Google.de, a strona ma dług technologiczny sięgający kilku lat, kolejna wtyczka optymalizacyjna tylko przesuwa problem. Naszą rolą jest powiedzieć, po której stronie tej granicy stoi Twój projekt.

#Szkolenie zespołu i przekazanie projektu

Po starcie produkcyjnym prowadzimy praktyczne szkolenie dla zespołu, stacjonarnie w Szczecinie lub zdalnie. Zostawiamy nagrania i instrukcje PDF obejmujące pracę na wersjach językowych, dodawanie realizacji przy pomocy wzorców synchronizowanych oraz zarządzanie plikami i dokumentacją techniczną. Szkolenie jest częścią wdrożenia, nie osobnym etapem dokupywanym później.

#Inne lokalizacje na Pomorzu Zachodnim i w Polsce

Obsługujemy firmy w całym regionie oraz na terenie całego kraju:

• Programista WordPress Bydgoszcz
• Programista WordPress Gdynia
• Programista WordPress Toruń
• Programista WordPress Wrocław
• Programista WordPress Poznań
• Programista WordPress Gdańsk

#Współpraca B2B: repozytorium, staging i prawa do kodu

Zasady, na których pracujemy z firmami ze Szczecina:

• Repozytorium Git i środowisko staging: wgląd w postęp prac na każdym etapie, każda zmiana opisana w historii commitów.
• Przeniesienie praw autorskich: klient dostaje udokumentowany kod źródłowy i może kontynuować projekt z dowolnym zespołem.
• Opieka po wdrożeniu: opieka techniczna WordPress w Szczecinie obejmuje aktualizacje, monitoring i reakcję na incydenty.

Skontaktuj się z nami, aby omówić szczegóły Twojego projektu WordPress w Szczecinie.