Programista WordPress w Glasgow

Strona firmy w Glasgow stoi obok formularza onboardingu fintechu nad Clyde, mikrowitryny programu publicznego z dziedzictwem COP26 albo kalendarza festiwalowego agencji kreatywnej w sezonie letnim. To nie jest powód, żeby WordPress udawał core bankingu albo platformę grantową. To powód, żeby motyw, bloki Gutenberg, CPT i wtyczki były napisane tak, jak oczekuje brytyjski dział compliance, redaktor publikujący treść po polsku i zespół IT, który czyta UK GDPR, a nie tylko wynik Lighthouse.

WPPoland buduje ten WordPress z polskiego zespołu seniorów dla firm w Glasgow i w szerszej Szkocji, 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 Glasgow

Glasgow to największe miasto Szkocji i drugie co do wielkości w Wielkiej Brytanii. Nie jest Londynem City ani hubem Manche. Tu liczy się fintech nad Clyde, kreatywna gospodarka, sektor publiczny z dziedzictwem COP26 i korytarz technologiczny wzdłuż rzeki. Inicjatywy takie jak Glasgow City Innovation District i wsparcie Scottish Enterprise wiążą startupy, uczelnie Strathclyde i Glasgow oraz biura firm technologicznych w jeden ekosystem. To nie jest slogan na slajdzie. To realny kontekst briefu: firma w Glasgow często obsługuje partnerów finansowych, beneficjentów programów publicznych albo turystów z całej Europy, a strona musi działać bez osobnej instalacji na każdy kanał.

Glasgow WordPress Meetup spotyka się regularnie w ekosystemie szkockim. 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 w Glasgow często brzmi: „mamy Elementor albo Divi, redakcja w Polsce publikuje landing po angielsku, a dział compliance chce Gutenberg, Git i formularz, który przejdzie audyt UK GDPR”. To jest problem modelu treści i procesu wdrożenia, nie problem szablonu z marketplace.

Typowy projekt, który trafia do seniorów Glasgow, nie brzmi „zróbcie ładną stronę”. Brzmi: odziedziczony motyw z page builderem, portal partnerski fintechu z integracją CRM, formularz beneficjenta programu publicznego zbierający dane osobowe pod UK GDPR, a nowa podstrona pod kampanię klimatyczną powstaje przez kopiowanie landinga z COP26 i ręczne podmienianie dat. To jest dług techniczny, który wychodzi w tygodniu publikacji, nie w audycie SEO.

#Motyw blokowy, motyw klasyczny i własna wtyczka

Nowa budowa w Glasgow 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 fintechu nad Clyde oznacza to stonowaną paletę korporacyjną, czytelny krój bez ozdobników i komponenty, które nie pękają na długich numerach referencyjnych albo nazwach produktów finansowych. Wzorce bloków opisują powtarzalne układy: hero z materiałem produktowym, siatka publikacji, blok specyfikacji z tabelą parametrów, karta beneficjenta programu, 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 fintech i publicznych w Glasgow 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 Glasgow 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ę programu publicznego. 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 beneficjenta, 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 beneficjenta programu, 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 onboardingu, 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 CRM, walidacja formularza KYC, daty ważności dokumentów). Logika biznesowa nie trafia do functions.php motywu, bo functions.php umiera razem z motywem, a firma w Glasgow zmienia partnera brandingowego częściej niż model treści.

Porównanie warstw przy kickoffie:

#Gutenberg, CPT i ACF pod fintech, publiczny i kreatywny

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 Glasgow listy są konkretne: publikacje programów, beneficjenci, wydarzenia festiwalowe, lokalizacje biur (City Centre to nie West End, West End to nie Finnieston), produkty finansowe, 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ę beneficjenta, 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 sezon festiwalowy jako kopia strony z zeszłego roku jest długiem, który wychodzi w lipcu. Obiekt CPT z polami daty, lokalizacji, materiałów i linków do biletów 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 Glasgow 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 premierą programu.

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.

#Glasgow: fintech nad Clyde, COP26 i korytarz technologiczny

Glasgow nie jest Edynburgiem z Park Row ani Birmingham z NEC. Tu liczy się fintech nad Clyde, kreatywna gospodarka, sektor publiczny z dziedzictwem COP26 oraz korytarz technologiczny wzdłuż rzeki. Te cztery osie ustawiają priorytety techniczne dla WordPressa, który ma działać w Glasgow, a nie tylko nosić je w tytule.

#Fintech i usługi finansowe nad Clyde

Szkocki fintech rośnie wokół Glasgow i Edynburga. Barclays ma silną obecność technologiczną w Glasgow. Virgin Money, ClearBank i mniejsze startupy finansowe siedzą w ekosystemie, w którym strona WordPress często nie jest „wizytówką”, tylko kanałem onboardingu, dokumentacją produktu albo panelem partnerskim. Awaria formularza KYC albo wyciek logów z wp-admin to nie problem marketingu. To problem compliance.

Dla WordPressa w fintech w Glasgow wynika z tego prosta rzecz: integracja wtyczki formularza, CRM albo cache obiektowego musi przejść checklistę, która obejmuje ścieżkę, którą audytor naprawdę klika. środowisko testowe z tym samym stosem PHP i tymi samymi wtyczkami płatności w sandbox to minimum, nie luksus. Motyw, który chowa klauzulę zgody w stopce edytowalnej przez każdego redaktora, to incydent compliance, nie „drobny bug CSS”.

#Korytarz technologiczny Clyde i CodeClan

Glasgow City Innovation District i rozwój nabrzeża Clyde tworzą korytarz, w którym siedzą CodeClan, startupy, uczelnie Strathclyde i Glasgow oraz biura firm technologicznych. Scottish Enterprise wspiera cyfrową transformację w regionie. Serwisy w tym klastrze mają inny profil awarii niż typowa strona firmowa: integracje API, webhooki, cache, który trzyma treść partnerską, skoki ruchu po wydarzeniu branżowym.

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

#Dziedzictwo COP26 w serwisach publicznych

COP26 odbyło się w Glasgow w listopadzie 2021, głównie w Scottish Event Campus (SEC). Po konferencji wiele podmiotów publicznych, fundacji i programów klimatycznych zostawiło mikrowitryny, landingi i portale informacyjne na WordPressie. Część z nich dziś jest zaniedbana: przestarzały PHP, wtyczki bez łatek, przekierowania, które prowadzą w pętlę, treści COP26 bez daty „last reviewed”.

Budowa albo refaktoryzacja takiego serwisu to nie rebranding. To najpierw audyt: czy hosting jest w UK, czy kopia się odtwarza, czy formularze zbierają dane zgodnie z UK GDPR, czy accessibility (Public Sector Bodies Accessibility Regulations) nadal przechodzi po ostatniej aktualizacji motywu. Polski zespół, który przejmuje taki serwis, zaczyna od listy napraw i mapy ryzyk, nie od szablonu z marketplace.

#Kreatywna gospodarka i turystyka

Glasgow ma silny sektor kreatywny: festiwale, muzea, agencje, turystyka. Tu WordPress często trzyma kalendarz wydarzeń, rezerwacje i treści wielojęzyczne. Awaria po aktualizacji wtyczki kalendarza albo regresja w WPML boli w sezonie, nie w styczniu. Freeze wdrożeń w oknie sezonowym i środowisko testowe przed premierą festiwalu to decyzja operacyjna, nie preferencja developera.

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

#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. ICO (Information Commissioner’s Office) jest organem nadzorczym. Dla strony WordPress w Glasgow 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 (onboarding klienta, zapytania partnerskie, newslettery, formularze beneficjenta programu) 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 Glasgow 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 onboardingu w piątek przed publikacją”, 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.

Pytanie o hosting UK albo EOG wraca w każdym briefie fintech i publicznym. AWS w Londynie (eu-west-2), Azure UK South, hosting u brytyjskiego providera albo Hetzner w Falkenstein (EOG, ale nie UK) to różne odpowiedzi dla compliance officer. Ashburn albo Hillsboro to Stany i zwykle veto bez Standard Contractual Clauses albo innej podstawy transferu. Rozmowa o hostingu w kickoffie jest merytoryczna, nie wizerunkowa.

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 Glasgow nie jest jednym przepisem. Publiczne instytucje (uniwersytety, NHS, rady miejskie, organy publiczne, podmioty z dziedzictwem COP26) 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 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 onboardingu, nawigacja główna, wyszukiwarka publikacji.
• Deklaracja dostępności (accessibility statement) dla podmiotów publicznych jako szablon z polami, nie jako strona zapomniana w stopce.

Dla fintechu nad Clyde 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 bankingu, ale strona onboardingu musi być użyteczna dla każdego partnera, nie tylko dla użytkownika myszy na szybkim laptopie.

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

Formularze onboardingu i zapytania partnerskie to najczęstszy punkt integracji dla fintechu nad Clyde. W praktyce oznacza to podłączenie WordPressa do CRM albo systemu weryfikacji, walidację pól zgodną z UK GDPR i limitowanie zapytań na endpointach publicznych, żeby formularz nie stał się wektorem spamu w tygodniu publikacji programu.

Dla podmiotów publicznych z dziedzictwem COP26 druga powtarzalna integracja to systemy grantowe albo rejestr beneficjentów: webhooki, mapowanie pól, logi błędów, żeby cichy błąd synchronizacji nie pokazywał nieaktualnych statusów przez tygodnie.

Dla agencji kreatywnych i sektora turystycznego 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 w GBP, integracją z Royal Mail albo DPD i raportowaniem sprzedaży dla zespołu finansowego opisujemy na osobnej stronie WooCommerce programista w Glasgow. 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 Glasgow klient z działem IT i tak zapyta o to na drugim spotkaniu, zwłaszcza jeśli recenzent przychodzi z Innovation District albo z wewnętrznego IT fintechu nad Clyde.

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 Glasgow 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 partnerów. Redakcja klika po stagingu z prawdziwymi wzorcami Gutenberg, nie po localhostcie programisty. Regresja wielojęzyczna, regresja klawiatury i regresja formularza onboardingu 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 publikacją programu.

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

Dla serwisu B2B albo publicznego w Glasgow liczy się czas do pierwszego bajtu z sieci w Szkocji i północnej Anglii, nie tylko z telefonu na tarasie w Londynie. Monitoring z jednego regionu USA kłamie. Punkt pomiaru w UK albo przynajmniej w EOG jest częścią kontraktu operatorskiego, nie dodatkiem.

#Bezpieczeństwo przy stronach z sąsiedztwa fintechu i sektora publicznego

Sąsiedztwo fintechu nad Clyde i podmiotów publicznych po COP26 nie czyni marketingowego WordPressa systemem core bankingu ani platformą grantową. Zespół nie pisze, że strona „spełnia ISO 27001” albo „jest certyfikowana NIS2”. Większość korporacyjnych stron WordPress w Glasgow 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 Glasgow

Dobrze zbudowana strona jest wartościowa tylko wtedy, gdy Twoja grupa docelowa w Glasgow i w szerszej Szkocji 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 Glasgow, spójność NAP (nazwa, adres, telefon) i strony przygotowane pod zapytania regionalne, uwzględniające Edynburg i Central Belt tam, gdzie biznes faktycznie działa w obu miastach.
• 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 Glasgow

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

Czy pracujecie z firmami spoza Glasgow? Tak. Znamy lokalny kontekst (fintech nad Clyde, Glasgow City Innovation District, CodeClan, dziedzictwo COP26, Glasgow WordPress Meetup), ale współpracujemy z klientami w całej Wielkiej Brytanii i za granicą. Wiele firm w Glasgow obsługuje partnerów Edynburgu, Aberdeen 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 Glasgow: testowane aktualizacje, kopie zapasowe, monitoring bezpieczeństwa i wydajności oraz priorytetowe wsparcie z udokumentowanym runbookiem. Szczegóły na stronie opieki, nie w tym briefie programistycznym.

Czym różni się współpraca z WPPoland od lokalnej agencji w Glasgow? 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 Glasgow 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 Glasgow 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 Glasgow

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 sezonem festiwalowym albo publikacją programu publicznego, zacznij od spisania celów, ograniczeń i obecnego stanu projektu. Wycena jest indywidualna i zależy od zakresu prac.