Programista WordPress w Rzeszowie

Programowanie WordPress dla firm z Rzeszowa i Podkarpacia: dedykowane motywy blokowe, wtyczki, integracje z polskim stosem płatności i logistyki, wielojęzyczne strony pod łańcuch dostaw aerospace oraz utrzymanie. Pracuję bezpośrednio jako senior, bez warstwy pośredniczącej, z kontrolą kodu na każdej gałęzi i pisemnym przekazaniem projektu.

Rzeszów ma własną specyfikę, która realnie wpływa na decyzje techniczne: rdzeń Doliny Lotniczej z Pratt & Whitney Rzeszów na Hetmańskiej, MTU Aero Engines Polska w Jasionce i siecią kilkudziesięciu poddostawców rozsianych po regionie, centrala Asseco Poland w Olchowej, prężna Politechnika Rzeszowska im. Ignacego Łukasiewicza z wydziałem informatyki i wydziałem budowy maszyn i lotnictwa, oraz lotnisko Rzeszów-Jasionka, które od 2022 roku obsługuje też tranzyt na Ukrainę. To nie jest tło marketingowe, to czynniki, które zmieniają wymagania konkretnego wdrożenia WordPressa.

#Programowanie WordPress w realiach Rzeszowa

Poddostawca z części obróbczych pracujący dla Pratt & Whitney, sklep internetowy z biurowca w okolicach al. Powstańców Warszawy obsługujący klientów z Niemiec i Stanów, kancelaria spod ratusza i startup z Podkarpackiego Centrum Innowacji mają zupełnie inne potrzeby od WordPressa. Łączy je jedno: szablonowa strona złożona z kupionego motywu i dwudziestu wtyczek nie wytrzymuje, gdy dochodzą realne integracje, ruch wielojęzyczny i wymogi zgodności wymagane przez OEM-y lotnicze. Tę warstwę buduję jako dedykowany kod, a nie kolejną wtyczkę z katalogu.

#Co realnie buduję

• Dedykowane motywy blokowe na Full Site Editing: theme.json, wzorce bloków, warianty stylów, hierarchia szablonów, którymi redakcja zarządza bez wzywania programisty
• Własne wtyczki na logikę biznesową, która ma przeżyć zmianę motywu: integracje, własne typy treści, endpointy REST, narzędzia w panelu
• Integracje z polskim stosem płatności: BLIK, Przelewy24, PayU, Tpay i Autopay, tak żeby checkout WooCommerce nie tracił klienta na ostatnim kroku
• Wysyłka i logistyka: InPost Paczkomaty z mapą wyboru punktu, wysyłki kurierskie, integracje z BaseLinkerem dla sprzedawców prowadzących równolegle Allegro i własny sklep
• Eksport do księgowości i faktury VAT: spięcie z Subiektem GT, Comarch ERP Optima i enova365, przygotowanie pod obowiązkowy KSeF od lutego 2026 i poprawne dane do JPK_V7
• Wielojęzyczność PL/EN/DE pod łańcuch dostaw lotniczy: WPML lub Polylang, hreflang, osobne slugi i niezależne meta dla każdej wersji językowej, tak żeby dział zakupów u OEM-a w Hartford czy Monachium otwierał stronę w swoim języku

#Dlaczego umiejscowienie w Rzeszowie ma znaczenie technicznie

Większość poważnego ruchu B2B w Rzeszowie nie przychodzi z Allegro ani z kampanii Google Ads w polskiej domenie. Przychodzi z działu zakupów u Sikorsky, w Lockheed Martin, w MTU Aero Engines albo w Pratt & Whitney Canada. Ci ludzie nie czytają po polsku i nie ufają stronie, która wygląda jak automatycznie przetłumaczony folder reklamowy. Strona dla podkarpackiego poddostawcy aerospace musi mieć poprawnie zorganizowaną wersję angielską z osobnymi metadanymi, hreflang, czytelnym katalogiem części z atrybutami technicznymi (normy AS9100, NADCAP, ISO 9001, certyfikaty obróbki termicznej, wymiary w calach i milimetrach), dokumentacją PDF do pobrania i zapytaniem ofertowym zamiast koszyka. Jeśli OEM nie znajdzie tych informacji w ciągu kilku minut na wersji angielskiej, kontakt nie powstanie.

Drugi rynek, który zmienia decyzje techniczne, to Niemcy i Austria. Po skierowaniu ekspansji Doliny Lotniczej także na rynek niemiecki coraz więcej firm z regionu sprzedaje równolegle do DACH-u. Pociąga to konkretne konsekwencje: niemiecka wersja strony musi mieć poprawne Impressum w stopce, informację o prawie odstąpienia (Widerrufsrecht) w sklepach B2C, a w przypadku przetwarzania danych w UE także odrębne podstawy prawne RODO. Polska wersja musi spełniać polski obowiązek informacyjny administratora danych i 72-godzinne okno zgłoszenia naruszenia do UODO. Strona, która tego nie rozróżnia, generuje problemy prawne po obu stronach.

Trzeci czynnik to lokalne pieniądze publiczne. Podkarpackie Centrum Innowacji w Jasionce, Aeropolis Park Naukowo-Technologiczny, Aviation Valley jako stowarzyszenie i regionalne programy z Funduszy Europejskich finansują wiele projektów cyfrowych w regionie. Strony spółek korzystających z dotacji muszą spełniać dostępność WCAG 2.1 AA, mieć obowiązkową stopkę informacyjną o dofinansowaniu, pliki źródłowe gotowe do audytu, deklarację dostępności i mechanizm zgłaszania problemów. To nie jest dodatek - to warunek rozliczenia projektu. Wbudowuję te wymagania w architekturę motywu, nie doklejam je wtyczką trzy dni przed kontrolą.

Czwarty wątek to G2A i okoliczne firmy software’owe. Centrala G2A znajduje się w Rzeszowie od początku, Asseco Poland ma tutaj największą siedzibę w grupie, a wokół funkcjonują dziesiątki spółek SaaS i wykonawców kontraktowych dla rynku amerykańskiego. Trafiają do mnie z konkretnym wzorcem zapotrzebowania: WordPress ma być szybkim frontem contentowym dla bloga, dokumentacji i landing page’y, ale produkt główny działa na osobnym backendzie. To naturalne miejsce na headless WordPress z Astro lub Next.js, REST/GraphQL i wdrożenia na Vercel albo Cloudflare. Tutaj WordPress nie jest monolitem aplikacji, jest CMS-em dla redakcji i marketingu, a backend produktu żyje osobno.

#Skąd biorą się kompetencje na lokalnym rynku

Politechnika Rzeszowska im. Ignacego Łukasiewicza kształci od dekad zarówno informatyków, jak i inżynierów lotnictwa, a Wyższa Szkoła Informatyki i Zarządzania w Rzeszowie produkuje rocznie kolejnych developerów front-endowych i back-endowych. To realny rynek, na którym łatwiej o kompetentnych ludzi do utrzymania niż o porządek w odziedziczonym kodzie. Najczęściej dostaję projekty po kilku takich rękach: motyw nadpisywany bezpośrednio w plikach na produkcji, wtyczki dublujące funkcje, brak środowiska testowego, brak repozytorium git, hasło administratora wpisane w pliku README leżącym na serwerze. Pierwszy krok to uporządkowanie, nie dokładanie kolejnej warstwy.

#Jak prowadzę projekt

Nie ma tu menedżera przekazującego wiadomości ani juniora uczącego się na Twoim sklepie. Osoba, z którą rozmawiasz, pisze kod.

1. Audyt i odkrycie. Przeglądam obecny motyw, wtyczki, integracje, ograniczenia hostingu i dane analityczne. Spisuję dług techniczny, szybkie wygrane i mierzalne kryteria sukcesu, zanim powstanie pierwsza linia kodu.
2. Specyfikacja techniczna. Decyzje architektoniczne, wybór stosu (motyw blokowy czy refaktoryzacja istniejącego, monolit czy headless z osobnym frontem), harmonogram i kryteria odbioru. Plan zatwierdzasz przed startem.
3. Implementacja w gałęziach funkcyjnych. Zgodnie z WordPress Coding Standards: ciągi gotowe do tłumaczeń, dostępne znaczniki, bloki renderowane serwerowo tam, gdzie to ma sens, testy na fragmentach, które tego wymagają, kontrola kodu na każdej gałęzi.
4. QA na środowisku testowym. Pełne rozwiązanie na środowisku testowym identycznym z produkcją: testy regresji, cele Core Web Vitals i skan dostępności. Testujesz na realnej treści i integracjach, zatwierdzasz do startu.
5. Wdrożenie i przekazanie. Udokumentowany proces wydania ze ścieżką wycofania, żyjąca dokumentacja dla redakcji i programistów, sesja przekazania. Projekt trafia do Twojego zespołu albo na opcjonalny abonament opieki.

#Typowe problemy, z którymi przychodzą firmy z Rzeszowa

• Wersja angielska, która odstrasza klienta z Ameryki. Tłumaczenie zrobione w Google Translate, brak hreflang, slugi po polsku w angielskich URL-ach, ceny w złotówkach bez przelicznika. Przebudowuję pod realnego użytkownika z działu zakupów OEM-ie: katalog z atrybutami technicznymi w jednostkach metrycznych i imperialnych, dokumentacja PDF, formularz zapytania ofertowego z prawidłowym mapowaniem do CRM, niezależne metadane.
• Checkout, który gubi klientów. Sklep przyjmuje tylko przelew albo ma rozsypaną kolejność metod płatności. Porządkuję BLIK, Przelewy24, PayU, Autopay i kartę tak, żeby najczęściej wybierane metody były u góry, a wybór Paczkomatu InPost nie wywalał koszyka.
• Sprzedaż na Allegro i we własnym sklepie obok siebie. Stany magazynowe się rozjeżdżają, bo brak jednego źródła prawdy. Spinam WooCommerce z BaseLinkerem i magazynem, żeby zamówienia i stany szły jednym torem.
• Rozliczenie projektu z dotacji w martwym punkcie. Strona z grantu unijnego nie przechodzi audytu dostępności, brakuje deklaracji, kontrast nie działa, nawigacja klawiaturą się sypie. Doprowadzam motyw do WCAG 2.1 AA, dopisuję deklarację dostępności, automatyzuję skan w CI, żeby regresja nie wróciła.
• Faktury i księgowość poza systemem. Zamówienia trzeba ręcznie przepisywać do Subiekta GT albo Comarch ERP Optima, a faktury wystawiać osobno. Spinam WooCommerce z systemem księgowym i przygotowuję dane pod obowiązkowy KSeF (od lutego 2026) oraz JPK_V7, żeby faktura VAT powstawała automatycznie z zamówienia.
• Strona po agencji, która zniknęła. Brak dostępu do kodu, brak dokumentacji, motyw nadpisany w plikach na produkcji, hasło administratora dzielone w mailu sprzed trzech lat. Odzyskuję kontrolę: środowisko testowe, repozytorium, runbook i dopiero wtedy zmiany.

#Bezpieczeństwo i zgodność z prawem

W projektach bezpieczeństwo traktujemy jako zestaw decyzji architektonicznych, a nie uniwersalną obietnicę zgodności. Typowy zakres obejmuje HTTPS z HSTS tam, gdzie pasuje do infrastruktury, nagłówki Content Security Policy ograniczające XSS, skanowanie podatności zależności w CI, uwierzytelnianie dwuskładnikowe dla kont administracyjnych i regularne testowanie kopii zapasowych. Przy stronach przetwarzających dane osobowe przygotowujemy konfigurację zgód, umowy powierzenia i minimalizację danych do weryfikacji z właścicielem procesu. Dla klientów na bieżącej opiece prowadzimy cykliczne przeglądy bezpieczeństwa: testy odtworzenia kopii, audyt dostępów, przegląd aktualizacji i listę ryzyk do decyzji biznesowej.

#Inżynieria wydajności

Core Web Vitals to nie ozdoba, to sygnał rankingowy i realne doświadczenie użytkownika, szczególnie na mobile, gdzie dziś trafia większość ruchu lokalnego. Projekty pod Rzeszów celują powyżej progów Google:

• LCP poniżej 1,5 sekundy dzięki uporządkowanej ścieżce renderowania krytycznego, preloadowanym obrazom hero w AVIF/WebP, cache na brzegu i generowaniu statycznemu tam, gdzie to możliwe
• INP poniżej 100 ms dzięki minimalnej hydracji JavaScript, web workerom do cięższych obliczeń i kontrolowanemu ładowaniu skryptów zewnętrznych
• CLS poniżej 0,05 dzięki jawnym wymiarom obrazów, font-display:swap z dopasowanymi fallbackami i zarezerwowanemu miejscu na treść dynamiczną

Metryki monitoruję ciągle przez Lighthouse CI i dane realnych użytkowników. Regresja uruchamia alert i blokuje wdrożenie.

#Lokalne SEO dla firmy z Rzeszowa

Dobrze zbudowana strona ma wartość tylko wtedy, gdy klient z Rzeszowa i regionu ją znajdzie. Fundament SEO układam już na etapie architektury:

• Techniczny fundament: czyste URL, sitemap XML, robots.txt, canonical, poprawna hierarchia nagłówków i dane strukturalne (LocalBusiness, Organization, Product, Service, FAQ, HowTo)
• Wyszukiwanie lokalne: Google Business Profile, dane strukturalne z adresem w Rzeszowie, spójne NAP i strony docelowe pod zapytania z regionu podkarpackiego, w tym Mielca, Stalowej Woli, Krosna i Jasła
• Rynek eksportowy: dla poddostawców lotniczych sprzedających do USA i Wielkiej Brytanii osobne wersje EN z hreflang, niezależnymi metadanymi i strukturą URL dopasowaną do nawyków wyszukiwawczych działu zakupów OEM-ach

SEO nie jest dodatkiem po starcie, jest częścią decyzji architektonicznych od pierwszego szkicu.

#Pytania, które najczęściej dostaję

Czy możecie zmigrować istniejącą stronę? Tak, z dowolnego CMS do WordPress, z WordPress do headless (Astro/Next.js) i między hostingami. Każda migracja obejmuje mapowanie URL, przekierowania 301 i monitoring SEO przez 90 dni po przeniesieniu.

Co obejmuje opieka? Aktualizacje WordPress, wtyczek i motywów testowane wcześniej na środowisku testowym, codzienne backupy z 30-dniową retencją, monitoring dostępności, skan bezpieczeństwa i godziny deweloperskie na drobne zmiany.

Pracujecie tylko z Rzeszowem? Bazuję na rynku podkarpackim i lokalnej społeczności technicznej skupionej wokół Politechniki Rzeszowskiej i Aviation Valley, ale współpracuję z klientami w całej Polsce i za granicą, zwłaszcza z firmami z łańcucha dostaw aerospace eksportującymi do USA, Wielkiej Brytanii, Niemiec i Francji.

Sklep z motywu czy dedykowany? Decyzja zapada na bazie kosztu i długu, nie tego co ciekawiej się buduje. Nowe projekty zwykle startują z motywem blokowym; odziedziczone częściej potrzebują skoncentrowanej refaktoryzacji niż przepisywania od zera. Wybór dokumentuję jako pisemny kompromis techniczny.

#Wielojęzyczność i lokalizacja serwisu

Wielojęzyczność to najczęstsze miejsce, w którym poprawnie napisany motyw i tak przestaje działać. Firma z Podkarpacia sprzedająca komponenty do OEM-a w USA i równolegle do klienta z DACH-u potrzebuje trzech wersji, które Google traktuje jako trzy osobne, indeksowalne dokumenty, a nie jako jedną stronę z przełącznikiem flag. Poniżej to, co realnie decyduje o wyniku.

WPML kontra Polylang: różnicę widać dopiero w utrzymaniu. WPML trzyma powiązania tłumaczeń we własnych tabelach (icl_translations i pokrewne), więc migracja bazy, klonowanie środowiska testowego i eksport treści wymagają świadomej obsługi tych tabel, a nie samego wp db export. Polylang opiera się na taksonomii języka i relacjach termów, czyli zostaje w standardowych strukturach WordPressa, co upraszcza przenoszenie i debugowanie zapytań, ale przerzuca więcej pracy na programistę: ciągi z motywu trzeba jawnie zarejestrować przez pll_register_string, a tłumaczenie slugów własnych typów treści, taksonomii i pól ACF wymaga wersji Pro. WPML dokłada więcej zapytań do każdego żądania i mocniej reaguje na źle skonfigurowany cache obiektowy, za to moduł String Translation obsługuje ciągi z wtyczek bez pisania kodu. Wybór zapisuję jako decyzję architektoniczną razem z konsekwencją utrzymaniową, bo zmiana wtyczki wielojęzycznej po roku jest w praktyce migracją treści, nie podmianą pluginu.

Tłumaczenie treści to nie to samo co tłumaczenie interfejsu. Wpisy, strony, produkty i pola idą przez WPML albo Polylang. Ciągi tekstowe z wtyczek i motywu (przyciski koszyka, komunikaty walidacji, etykiety w panelu) idą przez gettext, czyli pliki .pot, .po i .mo, i nie zobaczysz ich w edytorze tłumaczeń treści. Warunki są trzy: textdomain musi zgadzać się ze slugiem wtyczki, musi być załadowany przez load_plugin_textdomain na plugins_loaded, a plik .mo musi leżeć w wp-content/languages/plugins/, bo katalog wewnątrz wtyczki kasuje pierwsza aktualizacja. Szablon generuję przez wp i18n make-pot, a dla ciągów z bloków Gutenberga dokładam wp i18n make-json, inaczej edytor pokazuje angielskie etykiety mimo kompletnego .po. Ciągi wypisane w kodzie bez esc_html__ albo _x nie są tłumaczalne w ogóle: wtedy albo filtr gettext, albo patch wysłany do autora, nigdy edycja pliku wtyczki na produkcji.

Daty, liczby i waluty mają być pochodną locale, nie stałą w szablonie. Do formatowania dat używam wp_date, a nie starszego date_i18n, żeby strefa czasowa i tłumaczenie nazw miesięcy pochodziły z ustawień witryny. Format daty i separatory różnią się między wersjami: polska używa przecinka jako separatora dziesiętnego i spacji jako separatora tysięcy, niemiecka przecinka i kropki, angielska kropki i przecinka, więc kwoty przepuszczam przez number_format_i18n i ustawienia WooCommerce, a nie przez ręczne sklejanie ciągu w szablonie. Osobna decyzja to prezentacja podatku: polski sklep B2C pokazuje ceny brutto, niemiecki kontrahent B2B oczekuje netto z adnotacją o VAT, a WooCommerce potrafi to rozróżnić na podstawie lokalizacji klienta dopiero po świadomej konfiguracji. Obsługa wielu walut nie jest funkcją rdzenia WooCommerce: wymaga WooCommerce Multilingual albo dedykowanej warstwy, razem z decyzją, czy kurs jest sztywny, czy pobierany z zewnętrznego źródła.

hreflang i adres kanoniczny: dwa niezależne sygnały, które trzeba ustawić osobno. Każda wersja językowa ma kanoniczny adres wskazujący na samą siebie, nigdy na polski oryginał. Zestaw hreflang musi być wzajemny (jeśli wersja EN wskazuje DE, wersja DE musi wskazywać EN), zbudowany z adresów bezwzględnych, z kodem języka ISO 639-1 i opcjonalnym regionem ISO 3166-1 tam, gdzie treść faktycznie różni się dla de-DE i de-AT, oraz z jednym wpisem x-default dla strony wyboru języka lub rynku głównego. Sygnał podaję jedną metodą: w sekcji head, w mapie witryny albo w nagłówku HTTP, nie w trzech naraz, bo sprzeczne zestawy Google ignoruje w całości.

Najczęstsze przyczyny sytuacji, w której w indeksie zostaje tylko jedna wersja:

• Przełącznik języka zbudowany w JavaScript bez zwykłych odnośników kodzie HTML, więc robot nie ma jak dotrzeć do pozostałych wersji
• Automatyczne przekierowanie po GeoIP lub nagłówku Accept-Language, przez które Googlebot odwiedzający witrynę z adresów USA zawsze dostaje jedną wersję, a pozostałe nigdy nie trafiają do indeksu
• Kanoniczny adres wszystkich wersji ustawiony na polski oryginał, co jest wprost instrukcją deindeksacji tłumaczeń
• Język trzymany w ciasteczku lub sesji zamiast w adresie URL, przez co wszystkie wersje dzielą jeden adres i jedną pozycję w indeksie
• Mapa witryny generowana tylko dla języka domyślnego, często efekt wtyczki SEO nieświadomej warstwy wielojęzycznej
• hreflang wskazujący na adres z przekierowaniem lub z noindex, albo niespójny w kwestii ukośnika na końcu, co unieważnia całą grupę
• Przetłumaczone tylko menu i nagłówki, przy treści zostawionej po polsku, przez co wersja obcojęzyczna nie ma własnej wartości dla użytkownika z tamtego rynku

Sprawdzam wygenerowany kod strony, a nie deklaracje wtyczki: podgląd źródła każdej wersji, weryfikacja zestawu hreflang i adresu kanonicznego w wygenerowanym HTML, pobranie map witryny dla wszystkich języków, a po wdrożeniu kontrola raportu indeksowania w Search Console osobno dla każdej wersji językowej. Dla firm z Rzeszowa pracujących na dwa rynki eksportowe naraz to zwykle różnica między katalogiem części widocznym dla działu zakupów Hartford i Monachium a katalogiem, o którym wie tylko polski Google.

#Inne lokalizacje w Polsce

Podkarpackie projekty często łączą się z Małopolską: opisujemy programowanie WordPress w Krakowie. Na północny wschód sensownym uzupełnieniem jest programowanie WordPress w Białymstoku oraz programowanie WordPress w Kielcach.

#Rozmowa na start

Jeśli firma z Rzeszowa lub regionu potrzebuje programisty WordPress, napisz po niezobowiązującą konsultację. Przejrzę obecną sytuację, integracje i cele, po czym przedstawię uczciwą ocenę zakresu prac. Wycena jest zawsze indywidualna i wynika z realnego zakresu, a nie cennika z półki. Każdy sensowny projekt zaczyna się od jasnej komunikacji i wspólnych oczekiwań co do celów biznesowych, wymagań technicznych i ram czasowych.