Programista WordPress w Birmingham

Strona firmowa w Birmingham stoi obok hali produkcyjnej w Solihull, biura dostawcy w Jewellery Quarter albo stoiska na NEC w oknie targowym. To nie jest powód, żeby WordPress udawał system MES albo platformę streamingową. To powód, żeby motyw, bloki Gutenberg, CPT i wtyczki były napisane tak, jak oczekuje brytyjski dział zakupów, redaktor publikujący katalog części po polsku i zespół compliance, który czyta UK GDPR, a nie tylko wynik Lighthouse.

WPPoland buduje ten WordPress z polskiego zespołu seniorów dla firm w Birmingham i w szerszych Midlands, które mają siedzibę, oddział albo klientów Wielkiej Brytanii. 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 Birmingham

Birmingham nie jest Manchesterem i nie jest Leeds. Manchester ma MediaCityUK, produkcję medialną i korytarz Oxford Road. Leeds ma Park Row, Channel 4 i Leeds Digital Festival. Birmingham ma coś innego: serce produkcji zaawansowanej w UK, łańcuch dostaw automotive i aerospace w West Midlands oraz infrastrukturę, która zmienia mapę miasta na dekady. Inicjatywa Midlands Engine wiąże Birmingham z Coventry, Wolverhampton, Derby i Nottingham w jedną narrację rozwoju przemysłowego. To nie jest slogan na slajdzie. To realny kontekst briefu: firma z Birmingham często obsługuje dystrybutorów całej Europie, a strona musi działać dla odbiorcy w Niemczech albo Polsce bez osobnej instalacji na każdy kraj.

Innovation Birmingham w Aston Science Park to węzeł, w którym spotykają się startupy technologiczne, spin-offy uniwersyteckie i firmy produkcyjne szukające cyfryzacji. WordPress Birmingham Meetup zbiera developerów i agencje pracujące na WordPressie w regionie. 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 Gutenbergu i widzi różnicę między motywem blokowym a page builderem, który generuje shortcode’y w treści. Brief od klienta z Birmingham często brzmi: „mamy Divi albo Elementor, redakcja w Polsce publikuje katalog po angielsku, a dział IT chce Gutenberg, Git i integrację z ERP”. To jest problem modelu treści i procesu wdrożenia, nie problem szablonu z marketplace.

Typowy projekt, który trafia do seniorów Birmingham, nie brzmi „zróbcie ładną stronę”. Brzmi: odziedziczony motyw z page builderem, katalog produktów kopiowany co roku przed targami w NEC, formularz dystrybutorski zbierający dane osobowe pod UK GDPR, a nowa podstrona pod linię produktową powstaje przez kopiowanie strony z zeszłego roku i ręczne podmienianie numerów katalogowych. To jest dług techniczny, który wychodzi w tygodniu targowym, nie w audycie SEO.

#Motyw blokowy, motyw klasyczny i własna wtyczka

Nowa budowa w Birmingham 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 producenta z West Midlands oznacza to stonowaną paletę korporacyjną, czytelny krój bez ozdobników i komponenty, które nie pękają na długich numerach katalogowych albo nazwach norm ISO. Wzorce bloków opisują powtarzalne układy: hero z materiałem technicznym, siatka produktów z filtrem, blok specyfikacji z tabelą parametrów, karta certyfikatu, stopka z polityką prywatności zgodną z UK GDPR.

Pełna edycja witryny (FSE) ma sens, gdy zespół redakcyjny naprawdę ma dostać kontrolę nad nagłówkiem i stopką. W praktyce wiele firm produkcyjnych w Birmingham 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 Birmingham 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ę targów NEC. 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 dystrybutora, inne dla klienta końcowego, inne dla prasy) 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 dystrybutorskiego, rola „redaktor katalogu” bez publish_pages na produkcji publicznej: to wtyczka. Kolory, siatka, wzorzec hero: to motyw. Jeśli po zmianie motywu znika katalog produktów, 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 ERP, walidacja formularza dystrybutorskiego, daty ważności certyfikatów). Logika biznesowa nie trafia do functions.php motywu, bo functions.php umiera razem z motywem, a firma z Birmingham zmienia partnera brandingowego częściej niż model treści.

Porównanie warstw przy kickoffie:

#Gutenberg, CPT i ACF pod produkcję 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 Birmingham listy są konkretne: produkty, linie produktowe, certyfikaty, lokalizacje biur (Jewellery Quarter to nie Solihull, Solihull to nie Digbeth), publikacje techniczne, oferty pracy, stoiska targowe. 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 katalogu ma edytować kartę produktu, 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 produktu (komponent, system, usługa) 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 katalogowy, norma ISO, data ważności certyfikatu, plik PDF datasheet, flaga „dostępne tylko dla dystrybutorów”. Layout strony produktu 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 techniczna” 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 targi w NEC jako kopia strony z zeszłego roku jest długiem, który wychodzi w tygodniu wystaw. Obiekt CPT z polami stoiska, daty, numeru hali i materiałów przeżywa edycję 2027 bez kopiowania drzewa. Szablon czyta obiekt. Redaktor zmienia numer stoiska, nie HTML.

#Bloki serwerowe zamiast shortcode’ów

Shortcode w treści to dług, który widać dopiero przy migracji. Nowy kod w Birmingham idzie jako blok z renderem serwerowym: znaczniki semantyczne, atrybuty w komentarzu bloku, możliwość filtrowania wyjścia. Blok listy produktów 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 targami.

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.

#Birmingham: produkcja, HS2 i Midlands Engine

Birmingham nie jest klastrem mediów jak MediaCityUK w Manchesterze i nie jest ośrodkiem finansowym jak Leeds z Park Row. Tu liczy się produkcja zaawansowana, łańcuch dostaw automotive i aerospace oraz infrastruktura, która zmienia miasto na dekady. Te trzy osie ustawiają priorytety techniczne dla WordPressa, który ma działać w Birmingham, a nie tylko nosić je w tytule.

#Produkcja zaawansowana i łańcuch dostaw

West Midlands to największy klaster produkcji zaawansowanej w UK. Wokół Solihull, Coventry i hali produkcyjnej Jaguar Land Rover siedzą setki dostawców tier 1, tier 2 i tier 3, firmy aerospace, producentów komponentów i integratorów systemów. Dla WordPressa wynika z tego prosta rzecz: strona B2B producenta komponentów musi pokazać certyfikaty, specyfikacje, numery katalogowe i formularz zapytania dystrybutorskiego. Awaria formularza leadowego albo nieaktualny datasheet boli w łańcuchu dostaw, nie w „UX”.

Strona producenta wymaga materiałów technicznych, które nie mogą zniknąć po zmianie motywu. Certyfikaty ISO muszą być widoczne z datą ważności. Link do dokumentacji musi prowadzić do właściwego pliku PDF. Motyw, który chowa certyfikat w stopce edytowalnej przez każdego redaktora, to incydent compliance, nie „drobny bug CSS”. Dlatego certyfikaty i privacy notice idą do szablonów z polami, nie do bloków, które redaktor może przypadkiem usunąć.

#HS2: Curzon Street i kalendarz infrastrukturalny

HS2 to największy projekt infrastrukturalny w UK, łączący Birmingham z Londynem przez linię o prędkości do 360 km/h. Nowa stacja Curzon Street w centrum Birmingham zmieni dostępność miasta i generuje inwestycje wokół węzła. Dla firm w Birmingham to nie jest temat transportowy na stronie WordPress. To kalendarz: okna budowlane, zmiany w dostępności biur, kampanie employer branding pod rekrutację do nowego kampusu. Freeze wdrożeń w oknie krytycznym jest częścią runbooku, nie superstycją.

Firma z biurem przy Digbeth albo w Jewellery Quarter, która planuje relokację bliżej Curzon Street, potrzebuje strony, która przeżyje zmianę adresu, mapy Google Business Profile i NAP bez ręcznego grzebania w HTML. CPT lokalizacji z polami adresu, współrzędnych i godzin otwarcia rozwiązuje to lepiej niż kopia strony kontaktowej.

#NEC: targi, ruch i freeze wdrożeń

National Exhibition Centre (NEC) w Solihull to największe centrum targowe w UK. Tysiące wystawców z Midlands i całej Europy co roku publikują landingi pod stoiska, zaproszenia i materiały prasowe. W oknie targowym ruch na stronie rośnie, newslettery idą w tysiącach, a każda zmiana na produkcji jest ryzykiem. Dlatego w runbooku zapisujemy freeze wdrożeń: w tygodniu targów nie idą aktualizacje wtyczek, nie idą nowe bloki, nie idą zmiany w motywie. środowisko testowe dostaje zmiany, produkcja czeka do poniedziałku po zamknięciu hali.

To jest proces Git: gałąź czeka na merge, tag czeka na deploy, a redakcja ma checklistę publikacji (szkic, future, purge, URL newslettera, privacy notice w stopce). Bez tego freeze wygląda jak „nic nie robimy”, a z nim wygląda jak plan, który przeżył tydzień targów NEC i nie wymaga post-mortem w poniedziałek rano.

#Midlands Engine i wielojęzyczność

Midlands Engine wiąże Birmingham z Coventry, Derby, Leicester, Nottingham i Wolverhampton w jedną strategię rozwoju gospodarczego. Firmy stąd obsługują klientów całej Europie, a Birmingham jest jednym z najbardziej wielokulturowych miast w UK. Dla WordPressa to oznacza więcej pytań o wielojęzyczność, hreflang i locale redaktora pracującego po polsku przy froncie po angielsku. Polylang albo WPML dokładamy dopiero gdy naprawdę są dwa (albo trzy) języki na froncie. Sam panel w EN i treści w PL da się ogarnąć rolami i locale użytkownika, bez pełnego stacku wielojęzycznego.

#UK GDPR, cookies i formularze w brytyjskim kontekście

Po Brexicie Wielka Brytania zachowała własną wersję RODO, powszechnie nazywaną UK GDPR, oraz Data Protection Act 2018. Dla strony WordPress w Birmingham to nie jest abstrakcyjny paragraf prawny. To decyzje w formularzach, w wtyczkach consent, w polityce prywatności i w logach audytowych.

Co wpisujemy w brief i w kod:

• Formularze zbierające dane osobowe (zapytania dystrybutorskie, newslettery, formularze rekrutacyjne, zapytania B2B) dostają jawną podstawę prawną, checkbox zgody tam, gdzie consent jest wymagany, i minimalizację pól. Pola, których nie potrzebujesz do celu formularza, nie istnieją.
• Wtyczki consent (CookieYes, Complianz, podobne) 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 ICO.
• Polityka prywatności i cookie policy są szablonami z polami, nie blokami, które redaktor może usunąć z drzewa. w Birmingham te strony są elementem compliance, nie stopką marketingową.
• Integracje z CRM (HubSpot, Salesforce, Pipedrive) dostają dokumentację przepływu danych: co trafia do systemu zewnętrznego, jak długo, kto jest administratorem. Umowy powierzenia przetwarzania (DPA) to decyzja klienta, ale konfiguracja WordPressa musi umożliwiać realizację tej decyzji.
• Logi audytowe dla formularzy i zmian w panelu admina pomagają przy incydentach. Jeśli ktoś pyta „kto zmienił ustawienia formularza dystrybutorskiego w piątek przed targami”, odpowiedź nie może być „nie wiemy”.

Dla firm z klientami w UE dodatkowo: reprezentant w UE (jeśli wymagany), standardowe klauzule umowne, ocena wpływu na ochronę danych (DPIA) przy nowych formularzach zbierających dane wrażliwe. Zespół nie obiecuje „zgodności UK GDPR” bez właściciela procesu po stronie klienta. Obiecuje konfigurację techniczną, którą właściciel może opisać w dokumentacji.

Dla sklepów WooCommerce w GBP (bez podawania kwot w copy) integracja z bramką płatniczą obsługującą funty brytyjskie, VAT i faktury zgodne z brytyjskim prawem podatkowym to osobny brief na stronie WooCommerce programista. Ta strona trzyma się programowania WordPress, nie checkoutu.

#Dostępność: Public Sector Bodies Regulations i sektor prywatny

Dostępność w Birmingham nie jest jednym przepisem. Publiczne instytucje (uniwersytety, NHS, rady miejskie, organy publiczne) podlegają Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, które wymagają WCAG 2.1 AA (z perspektywą przejścia na WCAG 2.2). Sektor prywatny nie ma identycznego obowiązku prawnego, ale Equality Act 2010 tworzy kontekst, w którym 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.2 AA, focus widoczny na wszystkich interaktywnych elementach, nawigacja klawiaturą przez menu i modale.
• Obrazy z sensownymi atrybutami alt, PDF z datasheets mają tekst alternatywny albo HTML-ową wersję specyfikacji tam, gdzie materiał jest publikowany na stronie publicznej.
• Skan axe-core w CI plus ręczna ścieżka klawiatury na kluczowych szablonach: formularz dystrybutorski, nawigacja główna, wyszukiwarka katalogu.
• Deklaracja dostępności (accessibility statement) dla podmiotów publicznych jako szablon z polami, nie jako strona zapomniana w stopce.

Dla producentów z West Midlands dostępność ma też wymiar produktowy: materiały techniczne 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 CAD, ale strona katalogowa produktu musi być użyteczna dla każdego dystrybutora, nie tylko dla użytkownika myszy na szybkim laptopie.

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

Formularze dystrybutorskie i zapytania B2B to najczęstszy punkt integracji dla producentów z Midlands. W praktyce oznacza to podłączenie WordPressa do CRM albo systemu zamówień, walidację pól zgodną z UK GDPR i limitowanie zapytań na endpointach publicznych, żeby formularz nie stał się wektorem spamu w tygodniu targowym.

Dla firm produkcyjnych z West Midlands druga powtarzalna integracja to ERP albo system magazynowy: SAP, Microsoft Dynamics, Odoo albo własny system z webhookami, mapowaniem pól produktu i logami błędów, żeby cichy błąd synchronizacji nie pokazywał nieaktualnych stanów magazynowych przez tygodnie.

Dla wystawców z NEC trzecia integracja to często połączenie z kalendarzem targów, 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 w GBP, integracją z Royal Mail albo DPD i raportowaniem sprzedaży dla zespołu finansowego opisujemy na osobnej stronie WooCommerce programista w Birmingham. 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 Birmingham klient z działem IT i tak zapyta o to na drugim spotkaniu, zwłaszcza jeśli recenzent przychodzi z Innovation Birmingham albo z wewnętrznego IT firmy z Solihull.

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; brytyjskie IT w Birmingham zwykle woli angielski w diffie i angielski w dokumentacji redakcyjnej.

Ś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 dystrybutorów. Redakcja klika po stagingu z prawdziwymi wzorcami Gutenberg, nie po localhostcie programisty. Regresja wielojęzyczna, regresja klawiatury i regresja katalogu produktów 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 targami w NEC.

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, bo jsdom nie złapie, że InspectorControls zasłania przycisk Save w angielskim locale.

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 produktu, 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ą, nie gdy „tak się robi przy firmach produkcyjnych”.

Dla serwisu B2B albo katalogowego w Birmingham liczy się czas do pierwszego bajtu z sieci w Midlands, nie tylko z telefonu na tarasie. Monitoring z jednego regionu USA kłamie. Punkt pomiaru w UK albo przynajmniej w Europie jest częścią kontraktu operatorskiego, nie dodatkiem.

#Bezpieczeństwo przy stronach z sąsiedztwa produkcji

Sąsiedztwo hali produkcyjnej i dostawców tier 1 nie czyni marketingowego WordPressa systemem MES ani platformą ERP. Zespół nie pisze, że strona „spełnia ISO 27001” albo „jest certyfikowana NIS2”. Większość korporacyjnych stron WordPress w Birmingham nie jest samodzielnym podmiotem tych reżimów. Część stoi obok organizacji, które są. Wtedy 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, bez udawania audytu:

• Sekretów nie ma w Git. Klucze, hasła bazy i tokeny CRM idą przez zmienne środowiska albo poza repo. wp-config.php w historii Gita z hasłem to incydent, nie „drobiazg na później”.
• Konta administracyjne mają 2FA. Redaktorzy PL nie dostają install_plugins na produkcji. Rola jest cięta do tego, czego wymaga Gutenberg.
• 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 (consent, tag manager, czcionki), nie skopiowane z bloga.
• 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.
• Logi: kto zalogował się do wp-admin, skąd poszła zmiana wtyczki. Retencja uzgodniona z UK GDPR, nie „trzymamy wszystko wiecznie”.

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

#Lokalne SEO i widoczność cyfrowa w Birmingham

Dobrze zbudowana strona jest wartościowa tylko wtedy, gdy Twoja grupa docelowa w Birmingham i w szerszych Midlands 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 Birmingham, spójność NAP (nazwa, adres, telefon) i strony przygotowane pod zapytania regionalne, uwzględniające Midlands Engine i sąsiednie ośrodki tam, gdzie biznes faktycznie działa w Coventry albo Wolverhampton.
• 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 Birmingham

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 targów albo kampanii, żeby migracja nie wypadła w oknie krytycznym.

Czy pracujecie z firmami spoza Birmingham? Tak. Znamy lokalny kontekst (produkcja zaawansowana w Midlands, HS2 Curzon Street, Innovation Birmingham, NEC, WordPress Meetup Birmingham), ale współpracujemy z klientami w całej Wielkiej Brytanii i za granicą. Wiele firm z Birmingham obsługuje dystrybutorów Coventry, Derby, Leicester 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 brytyjski i europejski po Brexicie konfiguracja locale i hreflang wymaga osobnej decyzji architektonicznej.

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

Czym różni się współpraca z WPPoland od lokalnej agencji w Birmingham? 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 Birmingham z checkoutem w GBP, integracją z brytyjskimi kurierami i przygotowaniem pod UK GDPR. 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 Birmingham 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 Birmingham

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 targami w NEC albo kampanią B2B w Midlands, zacznij od spisania celów, ograniczeń i obecnego stanu projektu. Wycena jest indywidualna i zależy od zakresu prac.