Programista WordPress w Barcelonie

Strona firmy w Barcelonie stoi obok landinga kampanijnego pod Mobile World Congress, formularza demo scale-upu z 22@, sklepu WooCommerce z checkoutem Bizum albo portalu B2B z integracją HubSpot i wersjami ES/CA/EN. To nie jest powód, żeby WordPress udawał ERP albo platformę eventową. To powód, żeby motyw, bloki Gutenberg, CPT i wtyczki były napisane tak, jak oczekuje hiszpański dział compliance, redaktor publikujący treść po katalońsku i zespół IT, który czyta RODO oraz wytyczne AEPD, a nie tylko wynik Lighthouse.

WPPoland buduje ten WordPress z polskiego zespołu seniorów dla firm w Barcelonie i w szerszej Katalonii, które mają siedzibę, oddział albo klientów Hiszpanii. Zakres to programowanie WordPress: motyw blokowy albo klasyczny, własne wtyczki, Gutenberg, CPT, ACF albo natywne bloki, integracje REST i przegląd kodu na Git. Sklep WooCommerce, abonament opieki i kontakt są osobnymi tematami, z linkami na końcu.

#Programowanie WordPress dla firm w Barcelonie

Barcelona to stolica Katalonii i jeden z najważniejszych ośrodków tech i kreatywnych w Europie Południowej. Nie jest Madrytem administracyjnym ani Sewillą turystyczną. Tu liczy się dzielnica 22@ w Poblenou, klastry SaaS i scale-upów wzdłuż Rambla de Poblenou, ekosystem e-commerce od Eixample po Born oraz warstwa cyfrowa dla firm, które obsługują rynek hiszpański i międzynarodowy. Inicjatywy takie jak kampusy UPC i Pompeu Fabra, siedziby marek takich jak Glovo (Yellow Park) i setki startupów międzynarodowych wiążą biura technologiczne w jeden ekosystem. To nie jest slogan na slajdzie. To realny kontekst briefu: firma w Barcelonie często obsługuje partnerów z całej Europy, landingi pod Mobile World Congress albo sklep B2C z płatnością Bizum, a strona musi działać bez osobnej instalacji na każdy kanał.

WordPress Barcelona spotyka się regularnie w ekosystemie katalońskim (grupa na Meetup.com i lokalne spotkania w Poblenou oraz w 22@). To nie jest powód, żeby w copy wstawiać nazwę meetupu jako ozdobnik. To sygnał, że lokalna społeczność zna WordPress Coding Standards, debatuje o Gutenbergie i widzi różnicę między motywem blokowym a page builderem, który generuje shortcode’y w treści. Brief od klienta w Barcelonie często brzmi: „mamy Elementor albo Divi, redakcja publikuje landing po hiszpańsku i katalońsku, a dział compliance chce Gutenberg, Git i formularz, który przejdzie audyt AEPD”. To jest problem modelu treści i procesu wdrożenia, nie problem szablonu z marketplace.

Typowy projekt, który trafia do seniorów Barcelonie, nie brzmi „zróbcie ładną stronę”. Brzmi: odziedziczony motyw z page builderem, portal partnerski SaaS z integracją CRM, formularz demo zbierający dane osobowe pod RODO, a nowa podstrona pod kampanię MWC powstaje przez kopiowanie landinga z zeszłego roku i ręczne podmienianie dat. To jest dług techniczny, który wychodzi w tygodniu Mobile World Congress, nie w audycie SEO.

#Motyw blokowy, motyw klasyczny i własna wtyczka

Nowa budowa w Barcelonie startuje od decyzji, która później kosztuje miesiącami: czy prezentacja żyje w motywie blokowym z theme.json, czy w klasycznych szablonach PHP, i co idzie do wtyczki. Ta decyzja jest zapisywana przed pierwszym commitem.

#theme.json, wzorce i granica motywu

Motyw blokowy trzyma tokeny: paletę, skalę typografii, odstępy, szerokości treści. Dla scale-upu z 22@ oznacza to stonowaną paletę korporacyjną, czytelny krój bez ozdobników i komponenty, które nie pękają na długich nazwach produktów SaaS albo numerach NIF w formularzach. Wzorce bloków opisują powtarzalne układy: hero z materiałem produktowym, siatka case study, blok specyfikacji z tabelą parametrów, karta wydarzenia, stopka z política de privacidad zgodną z RODO.

Pełna edycja witryny (FSE) ma sens, gdy zespół redakcyjny naprawdę ma dostać kontrolę nad nagłówkiem i stopką. W praktyce wiele firm SaaS i e-commerce w Barcelonie tej kontroli nie chce: nagłówek jest elementem brandu i compliance, a nie placem zabaw. Wtedy motyw blokowy zostaje, ale szablony części (header, footer) są zablokowane, a redakcja pracuje w obrębie wzorców i własnych bloków. To kompromis, nie półśrodek.

Każdy własny blok dostaje block.json, kategorię, ikonę i atrybuty ze schematem. Tam, gdzie treść ma trafić do wyszukiwarki i do RSS, render idzie po stronie serwera. React w edytorze służy do InspectorControls i podglądu, nie do tego, żeby front był aplikacją SPA udającą WordPressa. Handbook na developer.wordpress.org jest źródłem kontraktu API, nie slajdem ze szkolenia.

#Kiedy klasyczny motyw PHP zostaje

Odziedziczone instalacje w Barcelonie często mają pięć, siedem lat: child theme na komercyjnym szkielecie, ACF wklejone w page.php, shortcode’y w treściach, jQuery z epoki przed blokami, osobna kopia strony pod każdą edycję Mobile World Congress. Przepisanie tego na FSE „bo tak wypada w 2026” jest droższe niż naprawa hierarchii szablonów, wyciągnięcie logiki do wtyczki i dokładanie Gutenberg tylko tam, gdzie redakcja naprawdę składa nowe landingi.

Klasyczny motyw zostaje, gdy:

• logika warunkowa siedzi w szablonach (inne menu dla partnera, inne dla prasy, inne dla inwestora) i przeniesienie jej do theme.json nic nie upraszcza;
• zespół redakcyjny publikuje setki stron w klasycznym edytorze i szkolenie z FSE byłoby większym ryzykiem niż dług;
• child theme jest cienki, a problemem są wtyczki i autoload, nie sam silnik szablonów.

Nawet wtedy nowe klocki idą jako bloki, nie jako kolejne shortcode’y. Shortcode w treści z 2019 roku zostaje do migracji. Nowy kod go nie dokłada.

#Funkcja do wtyczki, wygląd do motywu

Granica jest prosta i zapisana w runbooku. Motyw umie pokazać. Wtyczka umie wiedzieć. CPT produktu, kolejka do CRM, endpoint REST dla portalu partnerskiego, rola „redaktor publikacji” bez publish_pages na produkcji publicznej: to wtyczka. Kolory, siatka, wzorzec hero: to motyw. Jeśli po zmianie motywu znika katalog publikacji albo formularz demo, architektura była zła.

Własna wtyczka ma własny prefix, autoload PSR-4, plik główny z nagłówkiem Plugin Name i wersją semver oraz testy tam, gdzie logika liczy (mapowanie pól do HubSpot, walidacja formularza z NIF, daty ważności oferty). Logika biznesowa nie trafia do functions.php motywu, bo functions.php umiera razem z motywem, a firma w Barcelonie zmienia partnera brandingowego częściej niż model treści.

Porównanie warstw przy kickoffie:

#Gutenberg, CPT i ACF pod SaaS, e-commerce i B2B

Gutenberg bez modelu treści kończy się tym, że każda podstrona jest unikalnym kolażem bloków i nikt nie potrafi zrobić listy. W Barcelonie listy są konkretne: publikacje produktowe, case study, wydarzenia eventowe, lokalizacje biur (Eixample to nie Poblenou, Poblenou to nie Gràcia), oferty pracy, landingi kampanii. To są obiekty, nie „kolejne strony w drzewie”.

#Własne typy treści zamiast kopiowanych landingów

CPT rejestrujemy z własnymi capabilities, nie z mapowaniem na post. Redaktor publikacji ma edytować kartę case study, a nie kasować wtyczek. Archiwum CPT dostaje szablon albo wzorzec zapytań. Pojedynczy obiekt ma szablon, który nie pozwala rozpychać layoutu poza ustalony układ. Taksonomie są osobne: kategoria publikacji (raport, komunikat, case study) nie miesza się z tagami bloga.

ACF ma tu miejsce, ale nie jako substytut bloków. Pola ACF na CPT sprawdzają się przy danych, które są polami, nie layoutem: numer referencyjny produktu, data ważności dokumentu, plik PDF regulaminu, flaga „dostępne tylko dla partnerów”. Layout strony publikacji albo artykułu składa Gutenberg. Mieszanie ACF Flexible Content z pełnym edytorem bloków na tym samym obiekcie kończy się dwoma źródłami prawdy i redaktorem, który nie wie, gdzie kliknąć.

Gdzie ACF jest zbędne, atrybuty bloku w block.json wystarczą. Blok „specyfikacja produktu” nie potrzebuje grupy pól na każdej stronie. Potrzebuje atrybutów i ewentualnie InnerBlocks na opis. Mniej wtyczek w panelu to mniej powierzchni ataku i mniej konfliktów z wtyczkami consent i cache.

Landing pod Mobile World Congress jako kopia strony z zeszłego roku jest długiem, który wychodzi w lutym. Obiekt CPT z polami daty, lokalizacji, materiałów i linków do rejestracji przeżywa edycję 2027 bez kopiowania drzewa. Szablon czyta obiekt. Redaktor zmienia datę, nie HTML.

#Bloki serwerowe zamiast shortcode’ów

Shortcode w treści to dług, który widać dopiero przy migracji. Nowy kod w Barcelonie idzie jako blok z renderem serwerowym: znaczniki semantyczne, atrybuty w komentarzu bloku, możliwość filtrowania wyjścia. Blok listy publikacji czyta CPT, cache’uje zapytanie transjentem z jawnym TTL i invalidacją przy save_post, a nie przy każdym requeście w szczycie ruchu przed otwarciem Fira Gran Via.

przegląd kodu bloku sprawdza trzy rzeczy, zanim gałąź wpadnie do main: czy blok działa po wyłączeniu JS w podglądzie frontu, czy atrybuty mają typy i defaulty, czy nie ładuje całego builda edytora na froncie. Gutenberg, który dokłada megabajt Reacta do strony specyfikacji produktu, nie przejdzie review.

#Barcelona: 22@, Mobile World Congress i ekosystem scale-upów

Barcelona nie jest Walencją ani Saragossą. Tu liczy się dzielnica 22@ w Poblenou, Mobile World Congress w Fira Gran Via, równoległe wydarzenie 4YFN oraz ekosystem e-commerce i designu od Eixample po Born. Te cztery osie ustawiają priorytety techniczne dla WordPressa, który ma działać w Barcelonie, a nie tylko nosić to w tytule.

#22@ i ekosystem scale-upów Poblenou

Dzielnica 22@ w Poblenou to barceloński hub technologiczny zbudowany na dawnych terenach przemysłowych Sant Martí. Ponad 1 500 firm z sektora tech, mediów i designu, kampusy UPC i Pompeu Fabra, siedziby takich marek jak Glovo (Yellow Park) i setki startupów międzynarodowych. WordPress trzyma landingi produktowe, formularze demo, blogi techniczne i strony employer branding dla firm z łańcucha dostaw i dla zespołów, które właśnie zamknęły rundę seed.

Awaria po aktualizacji wtyczki formularza albo regresja w tłumaczeniach ES/CA/EN boli w tygodniu audytu dostawcy albo przed demo dla partnera, nie w sierpniu. Dla developmentu wynika z tego prosta rzecz: aktualizacja wtyczki cache, integracji z HubSpot albo WPML musi przejść checklistę, która obejmuje formularz demo z polami NIF i panel partnera z mapą lokalizacji. środowisko testowe z tym samym stosem PHP i tymi samymi wtyczkami w sandbox to minimum, nie luksus. Dyrektor operacyjny z biura w 22@ nie akceptuje argumentu „strona główna działa”, kiedy formularz zgłoszeniowy zwraca 500 po aktualizacji wtyczki sesji.

Development, który testuje tylko stronę główną, tego nie widzi. Development z runbookiem z listą endpointów, webhooków i ścieżki demo widzi. Barcelona nie wymaga DC w samym mieście. Wymaga, żeby origin i kopia miały sensowną jurysdykcję w UE i żeby wycofanie zmian był zapisany przed wdrożeniem.

#Mobile World Congress i zamrożenie wdrożeń

Mobile World Congress (MWC) w Barcelonie to jeden z największych eventów tech na świecie. Co roku w lutym Fira de Gran Via i okolice przyjmują ponad 100 000 uczestników, setki startupów i falę mediów branżowych. Równolegle 4YFN zbiera founderów i inwestorów pierwszym tygodniu kongresu. W tym oknie agencje, SaaS-y i marki z Barcelony uruchamiają landingi kampanijne, formularze leadów i integracje z CRM. Awaria strony w środku tygodnia MWC to nie „bug do backlogu”. To utracone leady i reputacja u partnerów, którzy mają pełny kalendarz spotkań na cały tydzień.

Runbook developmentu dla klientów Barcelonie ma wpisane zamrożenie wdrożeń produkcyjnych na okno Mobile World Congress i 4YFN, zwykle od tygodnia przed kongresem do tygodnia po jego zakończeniu. Aktualizacje krytyczne bezpieczeństwa przechodzą przez środowisko testowe i okno nocne, reszta czeka. To nie preferencja developera. To decyzja operacyjna uzgodniona z klientem przed sezonem eventowym. Kto robi „drobny patch cache” w poniedziałek otwarcia MWC, uczy się tego na własnej skórze, kiedy serwis nie wytrzymuje skoku ruchu z telefonów uczestników przy Fira Gran Via.

Landing pod MWC jako kopia strony z zeszłego roku jest długiem, który wychodzi w lutym. Obiekt CPT z polami daty, lokalizacji i materiałów przeżywa edycję 2027 bez kopiowania drzewa. Szablon czyta obiekt. Redaktor zmienia datę, nie HTML.

#E-commerce, Redsys i Bizum

Sklep kataloński zbiera Bizum, kartę przez Redsys, czasem przelew. Webhooki bramki i status zamówienia muszą przeżyć aktualizację WooCommerce. W Barcelonie do Stripe dochodzi Redsys i Bizum - metody, których klienci oczekują w kasie, nie ciekawostka z ulotki. Aktualizacja wtyczki płatności, która na produkcji nadpisze mapowanie callbacków, zostawia magazyn z ręcznym klejeniem statusów zamówień.

Przykład z audytu: zamówienie opłacone przez Bizum, a w panelu WooCommerce wciąż „oczekujące na płatność”, bo callback nie dotarł po patchu wtyczki. To nie jest błąd UX. To incydent operacyjny, który w lutym, w tygodniu Mobile World Congress, kosztuje więcej niż w styczniu. Pełny brief checkoutu, IVA i integracji magazynowych opisuje programista WooCommerce w Barcelonie.

#RODO, AEPD i hosting w UE

Po stronie hiszpańskiej klient pyta o coś innego niż polski zespół domyślnie zakłada: gdzie leżą dane, czy serwer jest w Unii Europejskiej, jak długo trzymamy logi, kto jest administratorem danych, czy mamy Data Processing Agreement. Te pytania trzeba umieć obsłużyć procesem, nie sloganem o „zgodności z RODO”.

#RODO i hiszpańska AEPD

Hiszpania stosuje RODO (GDPR) oraz krajową ustawę organiczną o ochronie danych osobowych i gwarantowaniu praw cyfrowych (LOPDGDD). Organ nadzorczy to Agencia Española de Protección de Datos (AEPD). Dla WordPressa w Barcelonie wynika z tego konkretny zakres developmentu: lista podprocesorów (host, CDN, poczta, analityka), umowa powierzenia tam, gdzie agencja przetwarza dane, procedura naruszenia w 72 godziny, minimalizacja danych w formularzach, política de privacidad zgodna z art. 13 RODO.

Development nie zastępuje DPO klienta. Dostarcza konfigurację techniczną, którą właściciel może opisać w dokumentacji. Nikt po stronie agencji nie podpisuje się pod „jesteście zgodni z RODO, bo macie WAF”. AEPD publikuje wytyczne na aepd.es; runbook projektu powinien być z nimi zgodny co do tego, co agencja dokumentuje, a co zostaje po stronie administratora danych.

Co wpisujemy w brief i w kod:

• Formularze zbierające dane osobowe (onboarding klienta, zapytania partnerskie, newslettery, formularze demo MWC) dostają jawną podstawę prawną, checkbox zgody tam, gdzie consent jest wymagany, i minimalizację pól.
• Wtyczki consent (Complianz, Cookiebot, Iubenda) konfigurujemy tak, żeby skrypty marketingowe nie ładowały się przed akceptacją. To jest decyzja w motywie i w kolejności enqueue, nie ticket opieki po pierwszym raporcie AEPD.
• Polityka prywatności i cookie policy są szablonami z polami, nie blokami, które redaktor może usunąć z drzewa.
• Integracje z CRM (HubSpot, Salesforce, Pipedrive) dostają dokumentację przepływu danych: co trafia do systemu zewnętrznego, jak długo, kto jest administratorem.

#Hosting w UE

Dane osobowe pod RODO ciągną pytanie: w której jurysdykcji stoi serwer. AWS w Irlandii (eu-west-1), OVH we Francji, Hetzner w Niemczech, Arsys albo Raiola w Hiszpanii, Scaleway w Paryżu to różne odpowiedzi dla compliance officer, ale wszystkie mieszczą się w UE. Ashburn albo Hillsboro to Stany i zwykle veto bez Standard Contractual Clauses albo innej podstawy transferu.

Pytanie „czy hosting jest w Barcelonie” wraca rzadziej niż „czy w UE”. Odpowiedź operacyjna jest dwuczęściowa. Jurysdykcja: UE, kopia nie wyjeżdża nocą na bucket w regionie US bez uzgodnienia. Latencja: origin w Madrycie albo Frankfurt plus CDN z terminałem TLS w UE zwykle wystarcza dla użytkowników Katalonii. Barcelona ma centra danych w aglomeracji, ale origin WordPressa nadal często stoi u dostawcy z regionem madryckim albo frankfurckim. To nie jest wada. To jest jawna decyzja rezydencji, którą trzeba opisać w runbooku.

#Dostępność: European Accessibility Act i sektor prywatny

Dostępność w Barcelonie nie jest jednym przepisem. Sektor publiczny podlega dyrektywie 2016/2102 o dostępności stron podmiotów publicznych, wdrożonej w prawie krajowym. Sektor prywatny obejmuje z kolei European Accessibility Act (dyrektywa 2019/882), obowiązujący od 28 czerwca 2025 dla wskazanych usług, w tym e-commerce, z wyłączeniem mikroprzedsiębiorstw poniżej 10 osób i 2 mln euro obrotu. Obie ścieżki prowadzą do WCAG 2.1 AA, a niedostępna strona usługowa to ryzyko prawne i wizerunkowe, nie „nice to have”.

Co konkretnie robi zespół w kodzie:

• Semantyczne znaczniki HTML, poprawna hierarchia nagłówków, etykiety formularzy powiązane z polami przez for/id, komunikaty błędów czytelne dla czytników ekranu.
• Kontrast kolorów zgodny z WCAG 2.1 AA, focus widoczny na wszystkich interaktywnych elementach, nawigacja klawiaturą przez menu i modale.
• Obrazy z sensownymi atrybutami alt, PDF z regulaminami mają tekst alternatywny albo HTML-ową wersję tam, gdzie materiał jest publikowany na stronie publicznej.
• Skan axe-core w CI plus ręczna ścieżka klawiatury na kluczowych szablonach: formularz demo, nawigacja główna, wyszukiwarka publikacji.

Dla scale-upu z 22@ dostępność ma też wymiar produktowy: materiały produktowe czytelne dla każdego odbiorcy, tabele specyfikacji, które da się obsłużyć klawiaturą, formularze, które nie wymagają myszy. WordPress nie zastępuje systemu core produktu, ale strona onboardingu musi być użyteczna dla każdego partnera.

#Integracje, które się powtarzają w Barcelonie

Formularze demo i zapytania partnerskie to najczęstszy punkt integracji dla SaaS z 22@. W praktyce oznacza to podłączenie WordPressa do CRM albo systemu weryfikacji, walidację pól zgodną z RODO i limitowanie zapytań na endpointach publicznych, żeby formularz nie stał się wektorem spamu w tygodniu Mobile World Congress.

Dla e-commerce druga powtarzalna integracja to Redsys, Bizum i Stripe: webhooki, mapowanie pól, logi błędów, żeby cichy błąd synchronizacji nie pokazywał nieaktualnych statusów zamówień przez tygodnie.

Dla agencji kreatywnych i studiów designu trzecia integracja to często połączenie z kalendarzem wydarzeń, embed materiałów prasowych, synchronizacja z newsletterem. Każda integracja dostaje dokumentację webhooków, matrycę błędów i test end-to-end na środowisku testowym przed wdrożeniem na produkcję.

Sklepy WooCommerce z checkoutem, integracją z Correos Express, SEUR albo GLS i raportowaniem sprzedaży dla zespołu finansowego opisujemy na osobnej stronie programista WooCommerce w Barcelonie. Programowanie motywu sklepu, wtyczek checkoutu i integracji magazynowych to ten sam stos techniczny, ale inny brief niż strona firmowa B2B.

#Git, środowisko testowe i przegląd kodu

To jest warstwa, która odróżnia seniorskie prace WordPress od „wgrania ZIP-a na FTP”. W Barcelonie klient z działem IT i tak zapyta o to na drugim spotkaniu, zwłaszcza jeśli recenzent przychodzi z 22@ albo z wewnętrznego IT scale-upu.

Repozytorium trzyma motyw i własne wtyczki. Wtyczki z katalogu WordPress.org i Core nie żyją jako skopiowane foldery w Gicie, chyba że jest twardy powód (fork, łatka, air-gap). Gałąź funkcyjna na jedną zmianę: nowy blok, nowy CPT, poprawka a11y. Pull request ma opis, ekrany albo nagranie z edytora, i checklistę: i18n, dostępność, brak sekretów, czy blok nie psuje klasycznego szablonu jeśli jeszcze żyje.

przegląd kodu robi senior, który nie pisał tej gałęzi. Review czyta WordPress Coding Standards (PHPCS, sniffs WordPress-Core), ale też czyta intencję: czy CPT nie powinien być wtyczką, czy ACF nie dubluje atrybutów bloku, czy hook nie wisi na init bez potrzeby. Komentarz w PR jest po angielsku albo po polsku, zależnie od recenzenta po stronie klienta; hiszpańskie IT w Barcelonie zwykle woli angielski w diffie.

Środowisko testowe jest kopią produkcji z zanonimizowanymi danymi. WP-CLI search-replace na URL, osobne klucze, wyłączone crony, które wysyłają maile do prawdziwych partnerów. Redakcja klika po stagingu z prawdziwymi wzorcami Gutenberg, nie po localhostcie programisty. Regresja wielojęzyczna ES/CA/EN, regresja klawiatury i regresja formularza demo dzieją się tutaj. Promocja na produkcję jest udokumentowanym krokiem: tag albo merge do main, build zasobów, cache warmup, ścieżka wycofania (poprzedni tag). Zespół nie wgrywa „na szybko” jednego pliku PHP przez SFTP, bo potem nikt nie odtworzy, co stało na produkcji w piątek przed otwarciem MWC.

WP-CLI jest narzędziem operacyjnym: flush transients, wp scaffold, import CPT, sprawdzanie autoload. Nie zastępuje testów. Tam, gdzie wtyczka liczy (daty, mapowanie, walidacja), idzie PHPUnit. Bloki z nietrywialnym UI dostają test w edytorze na stagingu.

Budżet wydajności jest częścią odbioru, nie osobnym projektem. Lighthouse i Core Web Vitals na szablonach, które naprawdę istnieją: archiwum CPT, single publikacji, strona z wzorcem hero. Obrazy w AVIF/WebP przez proces budowania, CSS motywu bez importu całego uniwersum bloków, JS edytora nie na froncie. Redis i obiektowy cache mają sens, gdy transjenty i zapytania CPT to pokazują.

Dla serwisu B2B albo e-commerce w Barcelonie liczy się czas do pierwszego bajtu z sieci w Katalonii i Europie Środkowej, nie tylko z telefonu przy Plaça de Catalunya. Monitoring z jednego regionu USA kłamie. Punkt pomiaru w UE jest częścią kontraktu operatorskiego, nie dodatkiem.

#Profile projektów Barcelonie: cele techniczne na piśmie

Nie prezentujemy anonimowych case study z okrągłymi liczbami niemożliwymi do zweryfikowania. Zamiast tego opisujemy trzy profile projektów, które powtarzają się na rynku barcelońskim, i cele techniczne, które uzgadniamy na piśmie przed pierwszą linią kodu.

#Profil 1: scale-up technologiczny w 22@ (Poblenou)

Typowy projekt: firma software B2B potrzebuje strony korporacyjnej w trzech językach (kataloński, hiszpański, angielski) zintegrowanej z HubSpot i skierowanej na pozyskiwanie leadów.

Zakres pracy:

• Motyw FSE na zamówienie z Synced Patterns dla zespołu marketingu.
• Formularze asynchroniczne połączone z HubSpot CRM przez webhooki po stronie serwera.
• Prawidłowa struktura hreflang zweryfikowana dla trzech wersji językowych.

Cele techniczne w umowie: wynik PageSpeed Mobile powyżej 90 na stronach pozyskiwania leadów, LCP poniżej 1 sekundy na mobile w danych CrUX po uruchomieniu, formularze ładujące się bez blokowania renderowania.

#Profil 2: marka kosmetyczna w Gràcia

Typowy projekt: sklep wielojęzyczny traci zamówienia w procesie zakupu podczas kampanii promocyjnych.

Zakres pracy:

• WooCommerce Blocks Checkout z Bizum exprés.
• Optymalizacja bazy MySQL i cache obiektowy Redis.
• Testy obciążeniowe przed każdą ważną kampanią sezonową.

Cele techniczne w umowie: proces zakupu poniżej 20 sekund na mobile w stagingu przed wdrożeniem, stabilność checkoutu pod symulowanym szczytem ruchu, monitoring porzuconych koszyków.

#Profil 3: kancelaria i doradztwo w Eixample

Typowy projekt: portal doradztwa podatkowego i prawnego z bazą wiedzy liczącą setki artykułów potrzebuje czystej migracji i szybkiej wyszukiwarki wewnętrznej.

Zakres pracy:

• Migracja do WordPress FSE z zoptymalizowanym wyszukiwaniem full-text.
• Dostępność WCAG 2.1 AA i RODO z Consent Mode v2.
• Pełna mapa przekierowań 301, żeby nie stracić pozycji podczas migracji.

Cele techniczne w umowie: audyt dostępności Lighthouse bez wykrywalnych błędów, wyniki wyszukiwania wewnętrznego poniżej 300 ms na całym archiwum, zachowanie ruchu organicznego zweryfikowane w Search Console po migracji.

#Bezpieczeństwo przy stronach z sąsiedztwa SaaS i e-commerce

Sąsiedztwo scale-upów z 22@ i sklepów z checkoutem Redsys nie czyni marketingowego WordPressa systemem core bankingu ani platformą płatniczą. Zespół nie pisze, że strona „spełnia ISO 27001” albo „jest certyfikowana NIS2”. WordPress ma dostarczyć inwentarz, ślad dostępu i dyscyplinę Git, które klient wkleja do własnej dokumentacji.

Postawa, którą da się utrzymać w kodzie i procesie:

• Sekretów nie ma w Git. Klucze, hasła bazy i tokeny CRM idą przez zmienne środowiska albo poza repo.
• Konta administracyjne mają 2FA. Redaktorzy nie dostają install_plugins na produkcji.
• XML-RPC zostaje wyłączony, jeśli nie ma uzasadnionego klienta. File editor w panelu też.
• Nagłówki: HTTPS, HSTS tam gdzie certyfikat i CDN na to pozwalają, CSP dopasowane do realnych skryptów.
• Zależności: Composer albo zapisane wersje wtyczek, skan CVE w CI, aktualizacje na stagingu przed produkcją.
• Kopie i odtworzenie: backup bez przetestowanego restore to ozdoba. Test odtworzenia na stagingu jest w runbooku.

Szerszy audyt bezpieczeństwa opisuje audyt bezpieczeństwa WordPress.

#Lokalne SEO i widoczność cyfrowa w Barcelonie

Dobrze zbudowana strona jest wartościowa tylko wtedy, gdy Twoja grupa docelowa w Barcelonie i w szerszej Katalonii może ją znaleźć. Nasze projekty programowania WordPress obejmują fundamentalną architekturę SEO od pierwszego szkicu:

• Fundamenty techniczne SEO. Czyste struktury URL, mapy strony XML, konfiguracja robots.txt, tagi canonical i prawidłowa hierarchia nagłówków. Implementujemy dane strukturalne Schema.org: LocalBusiness, Organization, Product, Service, FAQ i HowTo tam, gdzie mają sens.
• Optymalizacja wyszukiwania lokalnego. Integracja z Google Business Profile, lokalne dane strukturalne z adresem w Barcelonie, spójność NAP (nazwa, adres, telefon) i strony przygotowane pod zapytania regionalne, uwzględniające Poblenou, Eixample, Sant Martí i L’Hospitalet de Llobregat tam, gdzie biznes faktycznie działa w aglomeracji.
• Core Web Vitals jako sygnały rankingowe. Google używa metryk doświadczenia strony w ocenie page experience. Budżety wydajnościowe ustalamy na starcie projektu i weryfikujemy je na danych terenowych z raportu CrUX, nie tylko w pomiarze laboratoryjnym.
• Architektura treści. Układamy strony filarowe, artykuły pomocnicze i linkowanie wewnętrzne tak, żeby użytkownik szybko trafiał do właściwego tematu, a wyszukiwarka jasno rozumiała zakres kompetencji firmy.

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

#Pytania, które zadają nam firmy w Barcelonie

Czy możecie zmigrować naszą istniejącą stronę? Tak. Obsługujemy migracje z dowolnego CMS do WordPress, z WordPress do architektury headless (Astro/Next.js) i między dostawcami hostingu. Każda migracja obejmuje mapowanie URL, implementację przekierowań 301 i monitoring SEO przez 90 dni po migracji, z uwzględnieniem kalendarza Mobile World Congress albo kampanii, żeby migracja nie wypadła w oknie krytycznym.

Czy pracujecie z firmami spoza Barcelony? Tak. Znamy lokalny kontekst (22@, Mobile World Congress, 4YFN, Redsys, Bizum, AEPD, WordPress Barcelona Meetup), ale współpracujemy z klientami w całej Hiszpanii i za granicą. Wiele firm w Barcelonie obsługuje partnerów Madrycie, Walencji i całej Europie bez osobnej strony na każde miasto.

Jak obsługujecie strony wielojęzyczne? Implementujemy wielojęzyczność przez WPML dla tradycyjnego WordPress lub natywny routing i18n dla buildów headless z Astro lub Next.js. Każda wersja językowa dostaje prawidłowe tagi hreflang, zlokalizowane slugi URL i niezależne meta dane SEO. Dla firm obsługujących rynek kataloński, hiszpański i międzynarodowy konfiguracja locale ES/CA/EN wymaga osobnej decyzji architektonicznej.

Co obejmuje bieżące wsparcie? Po zakończeniu budowy projekt może przejść na dedykowaną opiekę techniczną WordPress w Barcelonie: testowane aktualizacje, kopie zapasowe, monitoring bezpieczeństwa i wydajności oraz priorytetowe wsparcie z udokumentowanym runbookiem i zamrożeniem wdrożeń w oknie MWC. Szczegóły na stronie opieki, nie w tym briefie programistycznym.

Czym różni się współpraca z WPPoland od lokalnej agencji w Barcelonie? Przede wszystkim doświadczeniem w WordPress od 2007 roku, własnym zapleczem technicznym na Astro i headless WordPress oraz pracą na jasnych założeniach: zakres, etapy i odpowiedzialność są opisane przed wdrożeniem. Wycena jest indywidualna i zależy od zakresu, nie z gotowego cennika.

#Powiązane usługi

Jeśli Twoja firma prowadzi już sklep online albo planuje go zbudować, mamy dedykowaną stronę o tworzeniu sklepów WooCommerce w Barcelonie z checkoutem Redsys, Bizum i przygotowaniem pod RODO oraz AEPD. Pillar bez miasta: programista WooCommerce. Jeśli obecna strona działa i potrzebuje tylko stałej opieki, testowanych aktualizacji i monitoringu, zobacz opiekę techniczną WordPress w Barcelonie albo pillar utrzymanie stron WordPress - obie strony opisują ten sam stos techniczny z perspektywy operacyjnej, nie programistycznej.

Pełny zakres prac programistycznych WordPress (motywy, wtyczki, Gutenberg, refaktoryzacje) opisuje strona programista WordPress. Jeśli chcesz omówić brief, wyślij krótki opis obecnej sytuacji przez formularz kontaktowy.

#Rozpocznij swój projekt w Barcelonie

Jeśli chcesz omówić programowanie WordPress, wyślij krótki opis obecnej sytuacji, celu biznesowego i ograniczeń technicznych. Na tej podstawie sprawdzamy konfigurację, wskazujemy ryzyka i proponujemy praktyczny plan działania.

Jeśli planujesz nową budowę, migrację do Gutenberg albo refaktoryzację odziedziczonego motywu przed Mobile World Congress albo kampanią sezonową, zacznij od spisania celów, ograniczeń i obecnego stanu projektu. Wycena jest indywidualna i zależy od zakresu prac.