Wspieramy społeczność WordPress w Newcastle
Nie jesteśmy tylko zdalną agencją. Jesteśmy aktywną częścią ekosystemu. Wierzymy w Open Source i wnosimy wkład w społeczność, która napędza ponad 40% sieci (W3Techs).
Programista WordPress & WooCommerce w Newcastle
W Newcastle, gdzie konkurencja jest wysoka, szybkość strony to Twój najważniejszy atut SEO. Nasz stack Astro + Headless WP gwarantuje wyniki, które zostawiają konkurencję w tyle.
Dla firm w Newcastle obsługujących sektor Lokalne MŚP i firmy korporacyjne, bezpieczeństwo danych jest priorytetem. Architektura Headless wirtualnie eliminuje najczęstsze wektory ataków na WordPressa.
Polski zespół, który utrzymuje WordPressa dla firmy w Newcastle, nie dokłada „jeszcze jednego abonamentu aktualizacji”. Utrzymuje serwis, który stoi obok biura software house’u przy Quayside, landingiem pod publikację modułu produktowego, sklepem WooCommerce z checkoutem w GBP przez Stripe albo PayPal oraz formularzami B2B z integracją CRM, na rynku North East, gdzie awaria formularza partnerskiego przed kampanią rekrutacyjną albo martwy checkout po aktualizacji wtyczki to temat na rozmowę z działem compliance i z dyrektorem operacyjnym, a nie tylko z marketingiem. Ta strona opisuje opiekę techniczną WordPressa właśnie w tym układzie: polski delivery, brytyjski kontekst Tyne and Wear, bez cennika i bez obietnic dostępności w procentach.
Szerszy opis produktu opieki, niezależny od miasta, jest na stronie utrzymania stron WordPress. Tu schodzimy do Newcastle: Newcastle Digital Hub, ekosystem software wokół Sage, UK GDPR oraz dziennik incydentów, który da się pokazać przy audycie ICO. Sklep WooCommerce z checkoutem pod rynek brytyjski to osobna ścieżka: programista WooCommerce w Newcastle. Budowa od zera albo przebudowa motywu idzie do programisty WordPress w Newcastle. Filary niezależne od miasta: programista WordPress i programista WooCommerce.
Co oznacza opieka WordPress przy serwisie software, B2B albo sklepowym w Newcastle
Opieka to nie „włącz auto-update i miej nadzieję”. Dla portalu partnerskiego dostawcy offshore, katalogu produktowego firmy z North East, sklepu B2B z integracją ERP albo strony biura technologicznego w aglomeracji Newcastle utrzymanie ma cztery twarde elementy: aktualizacje na kopii testowej, kopie zapasowe, które da się odtworzyć, WAF z sensownymi regułami oraz dziennik incydentów, który przeżyje pytanie audytora. Reszta - drobna zmiana w motywie, nowy formularz zgłoszeniowy, poprawka Core Web Vitals na stronie z mapą biur - wisi na tym fundamencie. Bez niego kolejna wtyczka tylko powiększa powierzchnię ataku.
Serwis w Newcastle często zbiera dane, których nie wolno traktować jak treści bloga. Formularz zapytania partnerskiego z numerem VAT registration number, kalkulator wysyłki Royal Mail albo DPD, panel partnera handlowego z listą certyfikatów, logowanie do strefy agenta: każdy z tych ekranów po aktualizacji wtyczki potrafi się rozsypać ciszej niż strona główna. Dlatego regresja nie kończy się na „strona się ładuje”. Kończy się na ścieżce, którą partner, dystrybutor albo dział zakupów Sunderland naprawdę klika.
Aktualizacje wyłącznie przez środowisko testowe
Rdzeń WordPress, wtyczki i motyw idą najpierw na środowisko testowe. środowisko testowe ma ten sam stos PHP, ten sam obiekt cache jeśli produkcja go ma, te same wtyczki płatności albo katalogu w trybie sandbox. Aktualizacja „od razu na żywo, bo to tylko patch” jest najkrótszą drogą do martwego checkoutu w piątek przed publikacją modułu produktowego albo do formularza partnerskiego, który przestaje zbierać leady w oknie kampanii B2B w Newcastle.
Po wgraniu łatek na kopii testowej idzie checklista, nie wyczucie. Logowanie wp-admin, zapis strony, formularz kontaktowy, koszyk i płatność jeśli jest WooCommerce, cron, poczta wychodząca, webhooki CRM, purge cache po publikacji oferty partnerskiej. Dopiero po tym produkcja. Ścieżka wycofania jest zapisana zanim ktokolwiek naciśnie deploy: która kopia, który tag, kto ma dostęp do hostingu. Jeśli tego nie ma na piśmie, to nie ma rollbacku, tylko improwizacja.
Kopie operacyjne to nie archiwum compliance
Codzienna kopia WordPressa służy do odtworzenia serwisu po błędzie albo ataku. Archiwum compliance dotyczy czego innego: rejestrów przetwarzania, dowodów audytowych i możliwości wglądu organu nadzorczego. Kopia w panelu hostingu nie spełnia wymogów archiwum sama z siebie. Brakuje niezmienności, kompletności i dokumentacji procedury.
W praktyce utrzymania rozdzielamy trzy warstwy. Pierwsza: kopia operacyjna strony i bazy, z retencją zapisaną w runbooku, testem odtworzenia, nie tylko „backup job zielony”. Druga: logi zmian i incydentów, które pokazują kto, kiedy i co wgrał. Trzecia: archiwum compliance u klienta, zwykle w DMS albo u doradcy prawnego w Newcastle albo w Londynie. Gdy wszystko leży razem na FTP, po dwóch latach pierwsze pytanie audytora zostaje bez odpowiedzi.
WAF, monitoring i dziennik pod audyt
WAF (mod_security, Cloudflare WAF albo reguły u hostera) odcina typowe skany i wstrzyknięcia, zanim dotrą do PHP. To nie zastępuje aktualizacji. To kupuje czas. Skan malware i kontrola integralności plików łapie to, co WAF przepuścił albo co weszło skradzionym hasłem. Dwuskładnikowe logowanie do wp-admin i ograniczenie liczby kont z uprawnieniem administratora są tańsze niż forensics po kradzieży sesji.
Dziennik incydentów jest równie ważny jak sama tama. Zapis: czas wykrycia, czas ograniczenia, czas przywrócenia, przyczyna, lista zmienionych plików i wtyczek, kto był powiadomiony. Dla właściciela biura przy Quayside, dostawcy z łańcucha offshore w North East albo sklepu B2B w aglomeracji Newcastle ten plik jest surowcem do zgłoszenia. Agencja WordPress nie składa raportu do ICO za klienta. Dostarcza oś czasu, której klient nie musi rekonstruować z pamięci.
Newcastle jako kontekst North East, nie jako ozdobnik w tytule
Newcastle upon Tyne nie jest Londynem i nie jest Manchesterem. To największe miasto North East England, z Quayside nad Tyne, dwoma silnymi uniwersytetami (Newcastle University i Northumbria University), ekosystemem software wokół firmy Sage oraz Newcastle Digital Hub jako etykietą klastra cyfrowego w regionie. Inicjatywa North East Combined Authority wiąże Newcastle z Gateshead, Sunderland, Durham i resztą regionu w jedną narrację rozwoju. To nie jest slogan na slajdzie. To realny kontekst briefu: firma w Newcastle często obsługuje partnerów całej UK i w Europie, a serwis musi działać po aktualizacji wtyczki, nie tylko w dniu audytu SEO.
Newcastle Digital Hub i Digital Union
Newcastle Digital Hub to nazwa, którą region używa dla klastra firm technologicznych, coworkingów przy Quayside i biur software w centrum miasta. Digital Union to sieć członkowska spinająca software house’y, agencje kreatywne i firmy szukające cyfryzacji w North East. Spotkania społeczności WordPress w regionie (wydarzenia w Ouseburn Valley, w coworkingach przy Quayside i w Gateshead) zbierają developerów pracujących na WordPressie w Tyne and Wear. 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 Newcastle często brzmi: mamy Divi albo Elementor, redakcja publikuje katalog po angielsku, a dział IT chce Git, środowisko testowe i integrację z HubSpot. Opieka, która nie rozumie tego kontekstu, aktualizuje wtyczki bez regresji na formularzu partnerskim. Dyrektor operacyjny z biura w Gateshead nie akceptuje argumentu „strona główna działa”, kiedy formularz zgłoszeniowy zwraca 500 po aktualizacji wtyczki sesji.
Sage i ekosystem software w North East
Sage Group, jeden z największych brytyjskich dostawców oprogramowania księgowego i ERP, ma siedzibę korporacyjną w Newcastle. Wokół niej siedzą setki mniejszych firm software, integratorów i dostawców usług IT. Dla WordPressa w Newcastle wynika z tego prosta rzecz: strona B2B dostawcy modułu albo integratora musi pokazać dokumentację produktu, studia przypadków, formularz demo i ścieżkę onboardingu partnera. Awaria formularza demo albo nieaktualny changelog boli w łańcuchu sprzedaży, nie w „UX”.
Strona software house’u wymaga materiałów technicznych, które nie mogą zniknąć po zmianie motywu. Link do dokumentacji API musi prowadzić do właściwej wersji. Motyw, który chowa changelog w stopce edytowalnej przez każdego redaktora, to incydent operacyjny, nie „drobny bug CSS”. Opieka pilnuje, żeby aktualizacja wtyczki nie psuła szablonów z polami, nie bloków, które redaktor może przypadkiem usunąć.
Quayside, Ouseburn i kalendarz publikacji regionalnej
Quayside nad Tyne to jeden z najbardziej rozpoznawalnych rejonów Newcastle, z biurami, coworkingami i studiami kreatywnymi. Ouseburn Valley łączy sektor kreatywny z technologią: agencje, studia, festiwale. Baltic Centre for Contemporary Art po stronie Gateshead to punkt orientacyjny dla turystyki i eventów, nie dla software Sage - te dwie „Sage” nie wolno mieszać w briefie utrzymania.
Dla firm w Newcastle to nie jest temat historyczny na stronie WordPress. To kalendarz: okna publikacji komunikatów produktowych, kampanie rekrutacyjne pod nowy kampus uniwersytecki, landingi pod wydarzenia Digital Union. Freeze wdrożeń w oknie krytycznym jest częścią runbooku opieki, nie superstycją. Firma z biurem w centrum Newcastle, która planuje relokację bliżej Quayside, potrzebuje serwisu, który przeżyje zmianę adresu, mapy Google Business Profile i NAP bez ręcznego grzebania w HTML.
Offshore, Port of Tyne i łańcuch dostaw North East
North East ma silny profil offshore i renewable energy. Port of Tyne obsługuje łańcuch dostaw dla offshore wind, w tym projekty w Morzu Północnym. Dostawcy komponentów, firmy serwisowe i podwykonawcy często mają strony WordPress z katalogiem usług, certyfikatami i formularzem zapytania ofertowego. Awaria formularza leadowego albo nieaktualny datasheet boli wtedy, kiedy tender ma deadline, a nie w styczniu.
Strona dostawcy wymaga certyfikatów widocznych z datą ważności. Link do dokumentacji HSE musi prowadzić do właściwego pliku PDF. Opieka pilnuje, żeby aktualizacja wtyczki cache albo page buildera nie psuła szablonów z polami certyfikacyjnymi.
Uniwersytety i spin-offy technologiczne
Newcastle University i Northumbria University wypuszczają spin-offy z programów komercjalizacji badań i z National Innovation Centre for Data. WordPress w takich firmach często trzyma warstwę marketingową, dokumentację produktu, blog techniczny albo portal inwestorski. Wzorce się powtarzają: szybki time-to-market na landingach, potem żądanie spójnego design systemu, potem integracja z HubSpot albo Pipedrive, potem wielojęzyczność, gdy pierwszy kontrakt wychodzi poza UK. Opieka techniczna w Newcastle musi rozumieć, że aktualizacja wtyczki page buildera w takim środowisku to nie „drobny patch”, tylko ryzyko dla całego procesu redakcyjnego.
Operacje specyficzne dla UK
Polski zespół zna WordPressa. Brytyjski klient pyta o coś innego: UK GDPR, cookie consent, Public Sector Bodies Accessibility Regulations, kto jest administratorem danych, czy mamy Data Processing Agreement. Te pytania trzeba umieć obsłużyć procesem, nie sloganem o „zgodności z RODO”.
UK GDPR i Data Protection Act 2018
Po Brexicie Wielka Brytania zachowała własną wersję RODO, powszechnie nazywaną UK GDPR, oraz Data Protection Act 2018. Organ nadzorczy to Information Commissioner’s Office (ICO). Dla WordPressa w Newcastle wynika z tego konkretny zakres utrzymania: lista podprocesorów (host, CDN, poczta, analityka), umowa powierzenia tam, gdzie agencja przetwarza dane, procedura naruszenia w 72 godziny, minimalizacja danych w formularzach, polityka prywatności zgodna z art. 13 UK GDPR.
Utrzymanie nie zastępuje DPO klienta. Dostarcza logi, oś czasu i opis zmian po incydencie. Klient klasyfikuje, czy zdarzenie wymaga zgłoszenia do ICO. Nikt po stronie agencji nie podpisuje się pod „jesteście zgodni z UK GDPR, bo macie WAF”. Przy incydencie z danymi osobowymi art. 33 UK GDPR daje administratorowi 72 godziny na zgłoszenie do ICO, o ile naruszenie może wiązać się z ryzykiem dla praw osób. Dlatego dziennik z opieki musi mieć datę pierwszej wiedzy, nie datę „kiedy developer wrócił z urlopu”.
Co wpisujemy w runbook utrzymania:
- Formularze zbierające dane osobowe (zapytania partnerskie, newslettery, formularze rekrutacyjne) dostają jawną podstawę prawną, checkbox zgody tam, gdzie consent jest wymagany, i minimalizację pól.
- Wtyczki consent (CookieYes, Complianz, podobne) konfigurujemy tak, żeby skrypty marketingowe nie ładowały się przed akceptacją. Kwartalny przegląd bannera i tagów na kluczowych szablonach jest częścią opieki, nie dodatkiem SEO.
- 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.
Dostępność: Public Sector Bodies Regulations i sektor prywatny
Dostępność w Newcastle nie jest jednym przepisem. Publiczne instytucje (uniwersytety, NHS, rady miejskie) 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.
Opieka nie zastępuje audytora dostępności. Pilnuje, żeby aktualizacja motywu albo wtyczki nie psuła etykiet formularzy, kontrastu, focusu klawiatury i hierarchii nagłówków. Skan axe-core w cyklu kwartalnym plus ręczna ścieżka klawiatury na formularzu partnerskim i nawigacji głównej to minimum, nie certyfikat na stronie.
Checkout WooCommerce, którego nie wolno łatać w ciemno
Sklep w Newcastle zbiera GBP przez Stripe albo PayPal, czasem fakturę B2B z polem VAT registration number. Webhooki bramki i status zamówienia muszą przeżyć aktualizację WooCommerce. Aktualizacja wtyczki płatności, która na produkcji nadpisuje mapowanie callbacków, zostawia magazyn w Sunderland z ręcznym klejeniem statusów zamówień. Dlatego te wtyczki nigdy nie idą w tym samym oknie co „drobna aktualizacja SEO”.
Przykład z audytu: zamówienie opłacone przez PayPal, 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 tygodniu publikacji produktowej kosztuje więcej niż w zwykłym miesiącu. Szczegóły checkoutu, Royal Mail, DPD i HPOS opisuje programista WooCommerce w Newcastle. Opieka pilnuje, żeby aktualizacja nie psuła webhooków i rezerwacji stanu.
Reakcja na incydent bez pustych procentów
Obietnica dostępności zapisana procentem na stronie city to ozdobnik, nie kontrakt. Dostępność wynika z hostingu, DNS, CDN, wtyczek i ludzi. Opieka opisuje procedurę, nie talizman.
Wykrycie: monitoring syntetyczny plus alert z WAF albo z hosta. Triage: czy to treść, czy płatność PayPal, czy wp-admin, czy cała produkcja, czy wyciek oferty przed kampanią. Ograniczenie: tryb konserwacji, cofnięcie wtyczki, wyłączenie endpointu, rotacja haseł, twardy WAF, purge cache. Odtworzenie z kopii, jeśli pliki są spalone. Dokumentacja osi czasu. Post-mortem z przyczyną i z działaniem, które ma nie powtórzyć się za miesiąc.
Czas pierwszej odpowiedzi zapisujemy w umowie. W dniach roboczych priorytet zwykle zamyka się w oknie godzin, nie dni. Dyżur poza tym oknem jest wtedy, gdy umowa go obejmuje. Przy freeze przed publikacją produktową okno bywa szersze niż w zwykłym miesiącu, bo koszt martwego landingu w tygodniu szczytu jest wyższy niż koszt dyżuru. Ta strona nie sprzedaje uniwersalnego SLA w tabelce. Sprzedaje porządek: widać, kto wszedł, co zmienił, kiedy serwis wrócił.
Jeśli klient musi złożyć zgłoszenie do ICO albo do wewnętrznego audytu, dziennik z opieki jest załącznikiem. Brak dziennika oznacza, że compliance składa raport ze zrzutów ekranu i ze wspomnień z WhatsAppa.
Przypadek: aktualizacja cache położyłaby formularze leadowe przed publikacją produktową, środowisko testowe to zatrzymał
Serwis dostawcy modułu software z North East na WordPressie, landing kampanii pod publikację nowej wersji produktu, formularz zapytania partnerskiego z polem VAT registration number, treść zaplanowana na wtorek 8:00, tydzień przed ogłoszeniem na wydarzeniu Digital Union. W kolejce do produkcji leżała aktualizacja wtyczki cache obiektowego plus patch SEO, „drobny, na żywo, bo to tylko object cache”.
Na środowisku testowym, sklonowanym z produkcji razem z Redisem i z ofertami w stanie „szkic”, publikacja o 8:00 serwowała ceny z poprzedniego sezonu. Przyczyna: zmiana klucza cache po patchu, stary fragment w motywie wołał get_post bez sprawdzenia statusu future, CDN trzymał HTML bez Cache-Control dla zalogowanego redaktora. Na produkcji ten sam zestaw poszedłby w niedzielę wieczorem. Oferta wyszłaby przed terminem, formularz zbierałby dane bez zaktualizowanej polityki prywatności, a wtorkowy ruch z newslettera do partnerów trafiłby w 404 po panicznym cofnięciu wpisu.
środowisko testowe zatrzymał promocję. wycofanie zmian na kopii testowej potwierdził, że sama wtyczka SEO jest niewinna, gdy motyw nie woła szkicu po kluczu bez statusu. Motyw dostał poprawkę, checklista publikacji (szkic, future, formularz, purge, URL w newsletterze, cookie banner) przeszła, dopiero potem produkcja. Nie ma tu nazwy firmy, bo to kształt zdarzenia, nie case study z logotypem. Jest mechanizm: najpierw kopia, potem produkcja. Bez kopii zostałby post-mortem i rozmowa z prawnikiem o wycieku.
Ten sam kształt wraca przy wtyczkach płatności Stripe, przy formularzu demo, który po aktualizacji gubi stawkę VAT, i przy „drobnej” aktualizacji SEO, która nadpisuje robots i wycina panel partnera z indeksu. Newcastle nie wybacza tego ciszej niż inny rynek. Wygląda to gorzej, bo obok siedzi ktoś, kto pyta o UK GDPR, o tydzień publikacji produktowej albo o slot w kalendarzu kampanii B2B w North East.
Digital Union i praktyka, której nie widać w panelu hostingu
Digital Union organizuje wydarzenia i programy wspierające firmy technologiczne w North East. To nie jest kanał sprzedaży. To jest miejsce, w którym widać, jak lokalni maintainerzy aktualizują, jak rozmawiają o uprawnieniach i o hoście. Opieka, która nigdy nie wychodzi poza ticket, gubi ten kontekst: w Newcastle część zespołów i tak siedzi po stronie software albo dostawców offshore i usłyszy te same pytania na wydarzeniach przy Quayside albo w Ouseburn.
WP-CLI w utrzymaniu nie jest ozdobą konferencyjną. To sposób, żeby aktualizację, różnicę wtyczek i eksport listy użytkowników zrobić powtarzalnie, z logiem, bez klików wp-admin na produkcji. Po sesji o bezpieczeństwie w społeczności argument „zrobimy to ręcznie w panelu” brzmi jeszcze gorzej.
Freeze aktualizacji przed publikacją produktową albo przed kampanią employer brandingową to nie fanaberia. To zapis w runbooku: w oknie od X do Y żadna wtyczka nie idzie na produkcję bez zgody klienta. Dostawca software, który ogłasza nowy moduł w piątek wieczorem, nie chce słyszeć, że „właśnie aktualizowaliśmy cache i teraz sprawdzamy”.
Miesięczny rytm, onboarding i przejęcie bałaganu
Onboarding to audyt, nie kick-off z prezentacją. Inwentaryzacja wtyczek, wersja PHP, cron, poczta, SSL, WAF, czy kopia w ogóle się odtwarza, gdzie stoi serwer, kto ma dostęp SFTP i do wp-admin, czy są konta-widma po agencji, która zniknęła. Baseline Lighthouse na stronie głównej i na najważniejszym formularzu partnerskim, checkoucie albo panelu partnera. Lista ryzyk z priorytetem: najpierw to, co psuje odtworzenie i bezpieczeństwo, potem to, co psuje konwersję albo publikację.
Pierwszy cykl aktualizacji na stagingu jest częścią onboardingu, nie „bonusem w miesiącu drugim”. Jeśli stagingu nie ma, jego postawienie jest pracą startową. Serwis software albo B2B w Newcastle bez kopii testowej nie wchodzi w stały abonament z otwartymi auto-update.
Miesiąc stały: okno aktualizacji poza freeze przed kampanią produktową, skan, przegląd logów WAF, test odtworzenia kopii w uzgodnionym cyklu, krótki raport. Raport ma metryki (uptime z monitoringu, błędy 5xx, czas odpowiedzi, lista wgranych wersji), decyzje (wtyczka X zostaje, wtyczka Y do wymiany) i residualne ryzyko (brak 2FA u redakcji, brak umowy powierzenia, cache bez reguły dla future, freeze przed publikacją produktową jeszcze nie wpisany). Bez residualnego ryzyka raport jest broszurą.
Przejęcie zaniedzanej instalacji zaczyna się od tej samej listy, tylko dłuższej. Stary PHP, wtyczka page buildera bez łatek, kopia tylko na tym samym dysku co produkcja, hasło admin we wpisie w Notion, checkout z trzema wtyczkami podatkowymi naraz, Redis, który trzyma szkice ofert przed publikacją. Pierwszy miesiąc to remediacja. Stała opieka zaczyna się, gdy da się bezpiecznie wgrać łatki.
Budowa od zera albo przebudowa motywu to już inna usługa: programista WordPress w Newcastle. Sklep, checkout, Stripe, PayPal i VAT: programista WooCommerce w Newcastle. Opieka nie udaje, że jest projektem wdrożeniowym. Gdy w utrzymaniu wychodzi, że motyw trzeba napisać od nowa, to idzie jako osobne zlecenie, na piśmie.
Wydajność przy skoku ruchu i użytkownikach z aglomeracji Newcastle
Origin w UK nie naprawi ciężkiego motywu z galeriami produktowymi. HTTP/3, Brotli, AVIF, lazy load, który nie psuje LCP hero, cache, który nie trzyma prywatnego koszyka ani nieopublikowanej oferty przed kampanią, ograniczenie wtyczek z zapytań SQL na każdej podstronie: to nadal robota utrzymaniowa. Core Web Vitals mierzymy na realnych URL-ach z formularzami partnerskimi, nie na pustej instalacji. INP psuje się od skryptów czatu, od widgetu mapy i od tag managera, który marketing dodał poza ticketingiem. Opieka, która nie widzi GTM, będzie gonić „optymalizację obrazków” w nieskończoność.
Dla serwisu B2B w Newcastle liczy się czas do pierwszego bajtu z sieci korporacyjnej w Gateshead, Sunderland albo przy A1(M), nie tylko z telefonu w centrum miasta. Monitoring z jednego regionu USA kłamie. Punkt pomiaru w UK albo przynajmniej w Europie jest częścią kontraktu operatorskiego, nie dodatkiem. Strona z pełnoekranowymi zdjęciami produktowych umiera na LCP od nieoszczędnych JPEG-ów szybciej niż od „słabego hostingu”. Przed publikacją produktową idzie osobny przegląd cache, limitów PHP i CDN; po evencie idzie ścinka landingów, które mają zostać jako archiwum, i tych, które mają dostać 301.
Bezpieczeństwo jako lista decyzji, nie jako plakietka
HTTPS z HSTS tam, gdzie infrastruktura to uniesie. Nagłówki ograniczające XSS. 2FA. Minimum kont administratorskich. Zakaz wtyczek „nulled”. Zakaz edytora plików wp-admin na produkcji. Rotacja haseł po odejściu freelancerów. Test odtworzenia kopii, bo kopia, której nikt nie odtwarzał, jest plikiem. Przy danych osobowych: umowa powierzenia, lista podprocesorów (host, CDN, poczta, analityka), procedura naruszenia pod UK GDPR.
To nie jest certyfikat ISO sprzedawany z abonamentem. To jest lista, którą da się odhaczyć przy onboardingowym audycie i wrócić do niej co kwartał. Klient z biura przy Quayside, z hali w Port of Tyne albo ze sklepu B2B w aglomeracji i tak przyniesie własną checklistę. Lepiej mieć swoją wcześniej.
Kiedy ta strona, a kiedy programista WordPress albo WooCommerce
Ta strona zostaje przy utrzymaniu: aktualizacje, kopie, monitoring, WAF, dziennik, drobne poprawki w ramach umowy. Motyw od zera, Gutenberg, CPT, refaktoryzacja page buildera albo integracja ERP to programista WordPress w Newcastle. Checkout w GBP, Royal Mail, DPD, HPOS i webhooki Stripe to programista WooCommerce w Newcastle. Newcastle Digital Hub i Digital Union tłumaczą, skąd biorą się serwisy B2B z formularzami partnerskimi i freeze przed publikacją produktowych. Nie tłumaczą, czemu webhook Stripe bez idempotencji zostawia zamówienie w pending po Black Friday.
Jak zaczynamy, bez zaliczek w procentach na stronie
Zakres, godziny reakcji i cena są indywidualne i lądują w umowie przed startem. Na tej stronie nie ma podziału płatności na transze procentowe i nie ma tabeli pakietów. Krótki opis serwisu, stacku, hostingu i tego, czy jest środowisko testowe, wystarczy, żeby zaproponować audyt onboardingu.
Kontakt: formularz. W zgłoszeniu przydaje się lokalizacja hostingu, lista wtyczek albo dostęp do stagingu, informacja czy serwis ma formularze pod UK GDPR, czy jest WooCommerce z Stripe albo PayPal, oraz które daty publikacji produktowej albo kampanii B2B blokują wydanie. Z tego powstaje plan: co naprawiamy zanim w ogóle wejdziemy w miesięczny rytm, a co zostaje w kadencji.
Opieka w Newcastle ma sens, gdy serwis już niesie biznes i trzeba go nie zepsuć. Gdy trzeba go dopiero zbudować, wracamy do developmentu. Gdy trzeba go utrzymać przy formularzach B2B, checkoutcie w GBP i UK GDPR pod ICO, zostajemy przy tym, co ta strona opisuje: środowisko testowe, kopia, WAF, dziennik, compliance po stronie klienta i runbook, który da się pokazać audytorowi bez rekonstruowania historii z pamięci.
Mapa w Newcastle i okolic
Obsługujemy klientów w Newcastle i pobliskich miejscowościach.
Ta strona zawiera informacje przygotowane specjalnie dla Newcastle.
Polski zespół, który utrzymuje WordPressa dla firmy w Newcastle, nie dokłada „jeszcze jednego abonamentu aktualizacji”. Utrzymuje serwis, który stoi obok biura software house’u przy Quayside, landingiem pod publikację modułu produktowego, sklepem WooCommerce z checkoutem w GBP przez Stripe albo PayPal oraz formularzami B2B z integracją CRM, na rynku North East, gdzie awaria formularza partnerskiego przed kampanią rekrutacyjną albo martwy checkout po aktualizacji wtyczki to temat na rozmowę z działem compliance i z dyrektorem operacyjnym, a nie tylko z marketingiem. Ta strona opisuje opiekę techniczną WordPressa właśnie w tym układzie: polski delivery, brytyjski kontekst Tyne and Wear, bez cennika i bez obietnic dostępności w procentach.
Szerszy opis produktu opieki, niezależny od miasta, jest na stronie utrzymania stron WordPress. Tu schodzimy do Newcastle: Newcastle Digital Hub, ekosystem software wokół Sage, UK GDPR oraz dziennik incydentów, który da się pokazać przy audycie ICO. Sklep WooCommerce z checkoutem pod rynek brytyjski to osobna ścieżka: programista WooCommerce w Newcastle. Budowa od zera albo przebudowa motywu idzie do programisty WordPress w Newcastle. Filary niezależne od miasta: programista WordPress i programista WooCommerce.
Co oznacza opieka WordPress przy serwisie software, B2B albo sklepowym w Newcastle
Opieka to nie „włącz auto-update i miej nadzieję”. Dla portalu partnerskiego dostawcy offshore, katalogu produktowego firmy z North East, sklepu B2B z integracją ERP albo strony biura technologicznego w aglomeracji Newcastle utrzymanie ma cztery twarde elementy: aktualizacje na kopii testowej, kopie zapasowe, które da się odtworzyć, WAF z sensownymi regułami oraz dziennik incydentów, który przeżyje pytanie audytora. Reszta - drobna zmiana w motywie, nowy formularz zgłoszeniowy, poprawka Core Web Vitals na stronie z mapą biur - wisi na tym fundamencie. Bez niego kolejna wtyczka tylko powiększa powierzchnię ataku.
Serwis w Newcastle często zbiera dane, których nie wolno traktować jak treści bloga. Formularz zapytania partnerskiego z numerem VAT registration number, kalkulator wysyłki Royal Mail albo DPD, panel partnera handlowego z listą certyfikatów, logowanie do strefy agenta: każdy z tych ekranów po aktualizacji wtyczki potrafi się rozsypać ciszej niż strona główna. Dlatego regresja nie kończy się na „strona się ładuje”. Kończy się na ścieżce, którą partner, dystrybutor albo dział zakupów Sunderland naprawdę klika.
Aktualizacje wyłącznie przez środowisko testowe
Rdzeń WordPress, wtyczki i motyw idą najpierw na środowisko testowe. środowisko testowe ma ten sam stos PHP, ten sam obiekt cache jeśli produkcja go ma, te same wtyczki płatności albo katalogu w trybie sandbox. Aktualizacja „od razu na żywo, bo to tylko patch” jest najkrótszą drogą do martwego checkoutu w piątek przed publikacją modułu produktowego albo do formularza partnerskiego, który przestaje zbierać leady w oknie kampanii B2B w Newcastle.
Po wgraniu łatek na kopii testowej idzie checklista, nie wyczucie. Logowanie wp-admin, zapis strony, formularz kontaktowy, koszyk i płatność jeśli jest WooCommerce, cron, poczta wychodząca, webhooki CRM, purge cache po publikacji oferty partnerskiej. Dopiero po tym produkcja. Ścieżka wycofania jest zapisana zanim ktokolwiek naciśnie deploy: która kopia, który tag, kto ma dostęp do hostingu. Jeśli tego nie ma na piśmie, to nie ma rollbacku, tylko improwizacja.
Kopie operacyjne to nie archiwum compliance
Codzienna kopia WordPressa służy do odtworzenia serwisu po błędzie albo ataku. Archiwum compliance dotyczy czego innego: rejestrów przetwarzania, dowodów audytowych i możliwości wglądu organu nadzorczego. Kopia w panelu hostingu nie spełnia wymogów archiwum sama z siebie. Brakuje niezmienności, kompletności i dokumentacji procedury.
W praktyce utrzymania rozdzielamy trzy warstwy. Pierwsza: kopia operacyjna strony i bazy, z retencją zapisaną w runbooku, testem odtworzenia, nie tylko „backup job zielony”. Druga: logi zmian i incydentów, które pokazują kto, kiedy i co wgrał. Trzecia: archiwum compliance u klienta, zwykle w DMS albo u doradcy prawnego w Newcastle albo w Londynie. Gdy wszystko leży razem na FTP, po dwóch latach pierwsze pytanie audytora zostaje bez odpowiedzi.
WAF, monitoring i dziennik pod audyt
WAF (mod_security, Cloudflare WAF albo reguły u hostera) odcina typowe skany i wstrzyknięcia, zanim dotrą do PHP. To nie zastępuje aktualizacji. To kupuje czas. Skan malware i kontrola integralności plików łapie to, co WAF przepuścił albo co weszło skradzionym hasłem. Dwuskładnikowe logowanie do wp-admin i ograniczenie liczby kont z uprawnieniem administratora są tańsze niż forensics po kradzieży sesji.
Dziennik incydentów jest równie ważny jak sama tama. Zapis: czas wykrycia, czas ograniczenia, czas przywrócenia, przyczyna, lista zmienionych plików i wtyczek, kto był powiadomiony. Dla właściciela biura przy Quayside, dostawcy z łańcucha offshore w North East albo sklepu B2B w aglomeracji Newcastle ten plik jest surowcem do zgłoszenia. Agencja WordPress nie składa raportu do ICO za klienta. Dostarcza oś czasu, której klient nie musi rekonstruować z pamięci.
Newcastle jako kontekst North East, nie jako ozdobnik w tytule
Newcastle upon Tyne nie jest Londynem i nie jest Manchesterem. To największe miasto North East England, z Quayside nad Tyne, dwoma silnymi uniwersytetami (Newcastle University i Northumbria University), ekosystemem software wokół firmy Sage oraz Newcastle Digital Hub jako etykietą klastra cyfrowego w regionie. Inicjatywa North East Combined Authority wiąże Newcastle z Gateshead, Sunderland, Durham i resztą regionu w jedną narrację rozwoju. To nie jest slogan na slajdzie. To realny kontekst briefu: firma w Newcastle często obsługuje partnerów całej UK i w Europie, a serwis musi działać po aktualizacji wtyczki, nie tylko w dniu audytu SEO.
Newcastle Digital Hub i Digital Union
Newcastle Digital Hub to nazwa, którą region używa dla klastra firm technologicznych, coworkingów przy Quayside i biur software w centrum miasta. Digital Union to sieć członkowska spinająca software house’y, agencje kreatywne i firmy szukające cyfryzacji w North East. Spotkania społeczności WordPress w regionie (wydarzenia w Ouseburn Valley, w coworkingach przy Quayside i w Gateshead) zbierają developerów pracujących na WordPressie w Tyne and Wear. 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 Newcastle często brzmi: mamy Divi albo Elementor, redakcja publikuje katalog po angielsku, a dział IT chce Git, środowisko testowe i integrację z HubSpot. Opieka, która nie rozumie tego kontekstu, aktualizuje wtyczki bez regresji na formularzu partnerskim. Dyrektor operacyjny z biura w Gateshead nie akceptuje argumentu „strona główna działa”, kiedy formularz zgłoszeniowy zwraca 500 po aktualizacji wtyczki sesji.
Sage i ekosystem software w North East
Sage Group, jeden z największych brytyjskich dostawców oprogramowania księgowego i ERP, ma siedzibę korporacyjną w Newcastle. Wokół niej siedzą setki mniejszych firm software, integratorów i dostawców usług IT. Dla WordPressa w Newcastle wynika z tego prosta rzecz: strona B2B dostawcy modułu albo integratora musi pokazać dokumentację produktu, studia przypadków, formularz demo i ścieżkę onboardingu partnera. Awaria formularza demo albo nieaktualny changelog boli w łańcuchu sprzedaży, nie w „UX”.
Strona software house’u wymaga materiałów technicznych, które nie mogą zniknąć po zmianie motywu. Link do dokumentacji API musi prowadzić do właściwej wersji. Motyw, który chowa changelog w stopce edytowalnej przez każdego redaktora, to incydent operacyjny, nie „drobny bug CSS”. Opieka pilnuje, żeby aktualizacja wtyczki nie psuła szablonów z polami, nie bloków, które redaktor może przypadkiem usunąć.
Quayside, Ouseburn i kalendarz publikacji regionalnej
Quayside nad Tyne to jeden z najbardziej rozpoznawalnych rejonów Newcastle, z biurami, coworkingami i studiami kreatywnymi. Ouseburn Valley łączy sektor kreatywny z technologią: agencje, studia, festiwale. Baltic Centre for Contemporary Art po stronie Gateshead to punkt orientacyjny dla turystyki i eventów, nie dla software Sage - te dwie „Sage” nie wolno mieszać w briefie utrzymania.
Dla firm w Newcastle to nie jest temat historyczny na stronie WordPress. To kalendarz: okna publikacji komunikatów produktowych, kampanie rekrutacyjne pod nowy kampus uniwersytecki, landingi pod wydarzenia Digital Union. Freeze wdrożeń w oknie krytycznym jest częścią runbooku opieki, nie superstycją. Firma z biurem w centrum Newcastle, która planuje relokację bliżej Quayside, potrzebuje serwisu, który przeżyje zmianę adresu, mapy Google Business Profile i NAP bez ręcznego grzebania w HTML.
Offshore, Port of Tyne i łańcuch dostaw North East
North East ma silny profil offshore i renewable energy. Port of Tyne obsługuje łańcuch dostaw dla offshore wind, w tym projekty w Morzu Północnym. Dostawcy komponentów, firmy serwisowe i podwykonawcy często mają strony WordPress z katalogiem usług, certyfikatami i formularzem zapytania ofertowego. Awaria formularza leadowego albo nieaktualny datasheet boli wtedy, kiedy tender ma deadline, a nie w styczniu.
Strona dostawcy wymaga certyfikatów widocznych z datą ważności. Link do dokumentacji HSE musi prowadzić do właściwego pliku PDF. Opieka pilnuje, żeby aktualizacja wtyczki cache albo page buildera nie psuła szablonów z polami certyfikacyjnymi.
Uniwersytety i spin-offy technologiczne
Newcastle University i Northumbria University wypuszczają spin-offy z programów komercjalizacji badań i z National Innovation Centre for Data. WordPress w takich firmach często trzyma warstwę marketingową, dokumentację produktu, blog techniczny albo portal inwestorski. Wzorce się powtarzają: szybki time-to-market na landingach, potem żądanie spójnego design systemu, potem integracja z HubSpot albo Pipedrive, potem wielojęzyczność, gdy pierwszy kontrakt wychodzi poza UK. Opieka techniczna w Newcastle musi rozumieć, że aktualizacja wtyczki page buildera w takim środowisku to nie „drobny patch”, tylko ryzyko dla całego procesu redakcyjnego.
Operacje specyficzne dla UK
Polski zespół zna WordPressa. Brytyjski klient pyta o coś innego: UK GDPR, cookie consent, Public Sector Bodies Accessibility Regulations, kto jest administratorem danych, czy mamy Data Processing Agreement. Te pytania trzeba umieć obsłużyć procesem, nie sloganem o „zgodności z RODO”.
UK GDPR i Data Protection Act 2018
Po Brexicie Wielka Brytania zachowała własną wersję RODO, powszechnie nazywaną UK GDPR, oraz Data Protection Act 2018. Organ nadzorczy to Information Commissioner’s Office (ICO). Dla WordPressa w Newcastle wynika z tego konkretny zakres utrzymania: lista podprocesorów (host, CDN, poczta, analityka), umowa powierzenia tam, gdzie agencja przetwarza dane, procedura naruszenia w 72 godziny, minimalizacja danych w formularzach, polityka prywatności zgodna z art. 13 UK GDPR.
Utrzymanie nie zastępuje DPO klienta. Dostarcza logi, oś czasu i opis zmian po incydencie. Klient klasyfikuje, czy zdarzenie wymaga zgłoszenia do ICO. Nikt po stronie agencji nie podpisuje się pod „jesteście zgodni z UK GDPR, bo macie WAF”. Przy incydencie z danymi osobowymi art. 33 UK GDPR daje administratorowi 72 godziny na zgłoszenie do ICO, o ile naruszenie może wiązać się z ryzykiem dla praw osób. Dlatego dziennik z opieki musi mieć datę pierwszej wiedzy, nie datę „kiedy developer wrócił z urlopu”.
Co wpisujemy w runbook utrzymania:
- Formularze zbierające dane osobowe (zapytania partnerskie, newslettery, formularze rekrutacyjne) dostają jawną podstawę prawną, checkbox zgody tam, gdzie consent jest wymagany, i minimalizację pól.
- Wtyczki consent (CookieYes, Complianz, podobne) konfigurujemy tak, żeby skrypty marketingowe nie ładowały się przed akceptacją. Kwartalny przegląd bannera i tagów na kluczowych szablonach jest częścią opieki, nie dodatkiem SEO.
- 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.
Dostępność: Public Sector Bodies Regulations i sektor prywatny
Dostępność w Newcastle nie jest jednym przepisem. Publiczne instytucje (uniwersytety, NHS, rady miejskie) 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.
Opieka nie zastępuje audytora dostępności. Pilnuje, żeby aktualizacja motywu albo wtyczki nie psuła etykiet formularzy, kontrastu, focusu klawiatury i hierarchii nagłówków. Skan axe-core w cyklu kwartalnym plus ręczna ścieżka klawiatury na formularzu partnerskim i nawigacji głównej to minimum, nie certyfikat na stronie.
Checkout WooCommerce, którego nie wolno łatać w ciemno
Sklep w Newcastle zbiera GBP przez Stripe albo PayPal, czasem fakturę B2B z polem VAT registration number. Webhooki bramki i status zamówienia muszą przeżyć aktualizację WooCommerce. Aktualizacja wtyczki płatności, która na produkcji nadpisuje mapowanie callbacków, zostawia magazyn w Sunderland z ręcznym klejeniem statusów zamówień. Dlatego te wtyczki nigdy nie idą w tym samym oknie co „drobna aktualizacja SEO”.
Przykład z audytu: zamówienie opłacone przez PayPal, 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 tygodniu publikacji produktowej kosztuje więcej niż w zwykłym miesiącu. Szczegóły checkoutu, Royal Mail, DPD i HPOS opisuje programista WooCommerce w Newcastle. Opieka pilnuje, żeby aktualizacja nie psuła webhooków i rezerwacji stanu.
Reakcja na incydent bez pustych procentów
Obietnica dostępności zapisana procentem na stronie city to ozdobnik, nie kontrakt. Dostępność wynika z hostingu, DNS, CDN, wtyczek i ludzi. Opieka opisuje procedurę, nie talizman.
Wykrycie: monitoring syntetyczny plus alert z WAF albo z hosta. Triage: czy to treść, czy płatność PayPal, czy wp-admin, czy cała produkcja, czy wyciek oferty przed kampanią. Ograniczenie: tryb konserwacji, cofnięcie wtyczki, wyłączenie endpointu, rotacja haseł, twardy WAF, purge cache. Odtworzenie z kopii, jeśli pliki są spalone. Dokumentacja osi czasu. Post-mortem z przyczyną i z działaniem, które ma nie powtórzyć się za miesiąc.
Czas pierwszej odpowiedzi zapisujemy w umowie. W dniach roboczych priorytet zwykle zamyka się w oknie godzin, nie dni. Dyżur poza tym oknem jest wtedy, gdy umowa go obejmuje. Przy freeze przed publikacją produktową okno bywa szersze niż w zwykłym miesiącu, bo koszt martwego landingu w tygodniu szczytu jest wyższy niż koszt dyżuru. Ta strona nie sprzedaje uniwersalnego SLA w tabelce. Sprzedaje porządek: widać, kto wszedł, co zmienił, kiedy serwis wrócił.
Jeśli klient musi złożyć zgłoszenie do ICO albo do wewnętrznego audytu, dziennik z opieki jest załącznikiem. Brak dziennika oznacza, że compliance składa raport ze zrzutów ekranu i ze wspomnień z WhatsAppa.
Przypadek: aktualizacja cache położyłaby formularze leadowe przed publikacją produktową, środowisko testowe to zatrzymał
Serwis dostawcy modułu software z North East na WordPressie, landing kampanii pod publikację nowej wersji produktu, formularz zapytania partnerskiego z polem VAT registration number, treść zaplanowana na wtorek 8:00, tydzień przed ogłoszeniem na wydarzeniu Digital Union. W kolejce do produkcji leżała aktualizacja wtyczki cache obiektowego plus patch SEO, „drobny, na żywo, bo to tylko object cache”.
Na środowisku testowym, sklonowanym z produkcji razem z Redisem i z ofertami w stanie „szkic”, publikacja o 8:00 serwowała ceny z poprzedniego sezonu. Przyczyna: zmiana klucza cache po patchu, stary fragment w motywie wołał get_post bez sprawdzenia statusu future, CDN trzymał HTML bez Cache-Control dla zalogowanego redaktora. Na produkcji ten sam zestaw poszedłby w niedzielę wieczorem. Oferta wyszłaby przed terminem, formularz zbierałby dane bez zaktualizowanej polityki prywatności, a wtorkowy ruch z newslettera do partnerów trafiłby w 404 po panicznym cofnięciu wpisu.
środowisko testowe zatrzymał promocję. wycofanie zmian na kopii testowej potwierdził, że sama wtyczka SEO jest niewinna, gdy motyw nie woła szkicu po kluczu bez statusu. Motyw dostał poprawkę, checklista publikacji (szkic, future, formularz, purge, URL w newsletterze, cookie banner) przeszła, dopiero potem produkcja. Nie ma tu nazwy firmy, bo to kształt zdarzenia, nie case study z logotypem. Jest mechanizm: najpierw kopia, potem produkcja. Bez kopii zostałby post-mortem i rozmowa z prawnikiem o wycieku.
Ten sam kształt wraca przy wtyczkach płatności Stripe, przy formularzu demo, który po aktualizacji gubi stawkę VAT, i przy „drobnej” aktualizacji SEO, która nadpisuje robots i wycina panel partnera z indeksu. Newcastle nie wybacza tego ciszej niż inny rynek. Wygląda to gorzej, bo obok siedzi ktoś, kto pyta o UK GDPR, o tydzień publikacji produktowej albo o slot w kalendarzu kampanii B2B w North East.
Digital Union i praktyka, której nie widać w panelu hostingu
Digital Union organizuje wydarzenia i programy wspierające firmy technologiczne w North East. To nie jest kanał sprzedaży. To jest miejsce, w którym widać, jak lokalni maintainerzy aktualizują, jak rozmawiają o uprawnieniach i o hoście. Opieka, która nigdy nie wychodzi poza ticket, gubi ten kontekst: w Newcastle część zespołów i tak siedzi po stronie software albo dostawców offshore i usłyszy te same pytania na wydarzeniach przy Quayside albo w Ouseburn.
WP-CLI w utrzymaniu nie jest ozdobą konferencyjną. To sposób, żeby aktualizację, różnicę wtyczek i eksport listy użytkowników zrobić powtarzalnie, z logiem, bez klików wp-admin na produkcji. Po sesji o bezpieczeństwie w społeczności argument „zrobimy to ręcznie w panelu” brzmi jeszcze gorzej.
Freeze aktualizacji przed publikacją produktową albo przed kampanią employer brandingową to nie fanaberia. To zapis w runbooku: w oknie od X do Y żadna wtyczka nie idzie na produkcję bez zgody klienta. Dostawca software, który ogłasza nowy moduł w piątek wieczorem, nie chce słyszeć, że „właśnie aktualizowaliśmy cache i teraz sprawdzamy”.
Miesięczny rytm, onboarding i przejęcie bałaganu
Onboarding to audyt, nie kick-off z prezentacją. Inwentaryzacja wtyczek, wersja PHP, cron, poczta, SSL, WAF, czy kopia w ogóle się odtwarza, gdzie stoi serwer, kto ma dostęp SFTP i do wp-admin, czy są konta-widma po agencji, która zniknęła. Baseline Lighthouse na stronie głównej i na najważniejszym formularzu partnerskim, checkoucie albo panelu partnera. Lista ryzyk z priorytetem: najpierw to, co psuje odtworzenie i bezpieczeństwo, potem to, co psuje konwersję albo publikację.
Pierwszy cykl aktualizacji na stagingu jest częścią onboardingu, nie „bonusem w miesiącu drugim”. Jeśli stagingu nie ma, jego postawienie jest pracą startową. Serwis software albo B2B w Newcastle bez kopii testowej nie wchodzi w stały abonament z otwartymi auto-update.
Miesiąc stały: okno aktualizacji poza freeze przed kampanią produktową, skan, przegląd logów WAF, test odtworzenia kopii w uzgodnionym cyklu, krótki raport. Raport ma metryki (uptime z monitoringu, błędy 5xx, czas odpowiedzi, lista wgranych wersji), decyzje (wtyczka X zostaje, wtyczka Y do wymiany) i residualne ryzyko (brak 2FA u redakcji, brak umowy powierzenia, cache bez reguły dla future, freeze przed publikacją produktową jeszcze nie wpisany). Bez residualnego ryzyka raport jest broszurą.
Przejęcie zaniedzanej instalacji zaczyna się od tej samej listy, tylko dłuższej. Stary PHP, wtyczka page buildera bez łatek, kopia tylko na tym samym dysku co produkcja, hasło admin we wpisie w Notion, checkout z trzema wtyczkami podatkowymi naraz, Redis, który trzyma szkice ofert przed publikacją. Pierwszy miesiąc to remediacja. Stała opieka zaczyna się, gdy da się bezpiecznie wgrać łatki.
Budowa od zera albo przebudowa motywu to już inna usługa: programista WordPress w Newcastle. Sklep, checkout, Stripe, PayPal i VAT: programista WooCommerce w Newcastle. Opieka nie udaje, że jest projektem wdrożeniowym. Gdy w utrzymaniu wychodzi, że motyw trzeba napisać od nowa, to idzie jako osobne zlecenie, na piśmie.
Wydajność przy skoku ruchu i użytkownikach z aglomeracji Newcastle
Origin w UK nie naprawi ciężkiego motywu z galeriami produktowymi. HTTP/3, Brotli, AVIF, lazy load, który nie psuje LCP hero, cache, który nie trzyma prywatnego koszyka ani nieopublikowanej oferty przed kampanią, ograniczenie wtyczek z zapytań SQL na każdej podstronie: to nadal robota utrzymaniowa. Core Web Vitals mierzymy na realnych URL-ach z formularzami partnerskimi, nie na pustej instalacji. INP psuje się od skryptów czatu, od widgetu mapy i od tag managera, który marketing dodał poza ticketingiem. Opieka, która nie widzi GTM, będzie gonić „optymalizację obrazków” w nieskończoność.
Dla serwisu B2B w Newcastle liczy się czas do pierwszego bajtu z sieci korporacyjnej w Gateshead, Sunderland albo przy A1(M), nie tylko z telefonu w centrum miasta. Monitoring z jednego regionu USA kłamie. Punkt pomiaru w UK albo przynajmniej w Europie jest częścią kontraktu operatorskiego, nie dodatkiem. Strona z pełnoekranowymi zdjęciami produktowych umiera na LCP od nieoszczędnych JPEG-ów szybciej niż od „słabego hostingu”. Przed publikacją produktową idzie osobny przegląd cache, limitów PHP i CDN; po evencie idzie ścinka landingów, które mają zostać jako archiwum, i tych, które mają dostać 301.
Bezpieczeństwo jako lista decyzji, nie jako plakietka
HTTPS z HSTS tam, gdzie infrastruktura to uniesie. Nagłówki ograniczające XSS. 2FA. Minimum kont administratorskich. Zakaz wtyczek „nulled”. Zakaz edytora plików wp-admin na produkcji. Rotacja haseł po odejściu freelancerów. Test odtworzenia kopii, bo kopia, której nikt nie odtwarzał, jest plikiem. Przy danych osobowych: umowa powierzenia, lista podprocesorów (host, CDN, poczta, analityka), procedura naruszenia pod UK GDPR.
To nie jest certyfikat ISO sprzedawany z abonamentem. To jest lista, którą da się odhaczyć przy onboardingowym audycie i wrócić do niej co kwartał. Klient z biura przy Quayside, z hali w Port of Tyne albo ze sklepu B2B w aglomeracji i tak przyniesie własną checklistę. Lepiej mieć swoją wcześniej.
Kiedy ta strona, a kiedy programista WordPress albo WooCommerce
Ta strona zostaje przy utrzymaniu: aktualizacje, kopie, monitoring, WAF, dziennik, drobne poprawki w ramach umowy. Motyw od zera, Gutenberg, CPT, refaktoryzacja page buildera albo integracja ERP to programista WordPress w Newcastle. Checkout w GBP, Royal Mail, DPD, HPOS i webhooki Stripe to programista WooCommerce w Newcastle. Newcastle Digital Hub i Digital Union tłumaczą, skąd biorą się serwisy B2B z formularzami partnerskimi i freeze przed publikacją produktowych. Nie tłumaczą, czemu webhook Stripe bez idempotencji zostawia zamówienie w pending po Black Friday.
Jak zaczynamy, bez zaliczek w procentach na stronie
Zakres, godziny reakcji i cena są indywidualne i lądują w umowie przed startem. Na tej stronie nie ma podziału płatności na transze procentowe i nie ma tabeli pakietów. Krótki opis serwisu, stacku, hostingu i tego, czy jest środowisko testowe, wystarczy, żeby zaproponować audyt onboardingu.
Kontakt: formularz. W zgłoszeniu przydaje się lokalizacja hostingu, lista wtyczek albo dostęp do stagingu, informacja czy serwis ma formularze pod UK GDPR, czy jest WooCommerce z Stripe albo PayPal, oraz które daty publikacji produktowej albo kampanii B2B blokują wydanie. Z tego powstaje plan: co naprawiamy zanim w ogóle wejdziemy w miesięczny rytm, a co zostaje w kadencji.
Opieka w Newcastle ma sens, gdy serwis już niesie biznes i trzeba go nie zepsuć. Gdy trzeba go dopiero zbudować, wracamy do developmentu. Gdy trzeba go utrzymać przy formularzach B2B, checkoutcie w GBP i UK GDPR pod ICO, zostajemy przy tym, co ta strona opisuje: środowisko testowe, kopia, WAF, dziennik, compliance po stronie klienta i runbook, który da się pokazać audytorowi bez rekonstruowania historii z pamięci.
Projekty WordPress zrealizowane w Newcastle i Wielka Brytania
Zobacz wybrane realizacje, które wspierają biznes naszych klientów.
zafriko.pl - Projekt WordPress | WPPoland
Zafriko.pl to projekt w moim portfolio programisty WordPress, który rozwijałem jako platformę społeczności...
Airhelp - Projekt WordPress | WPPoland
AirHelp powstało w 2013 roku jako start-up, by stać się globalnym liderem w obronie praw pasażerów lotniczych, pomagając ponad 13 milionom osób zrozumieć ich...
alextg.pl - Projekt WordPress | WPPoland
Witaj na alextg.pl, stronie, która jest dowodem na to, jak WordPress może wspierać firmy pomagające klientom w uzyskaniu finansowania. Jako programista Word...
Wsparcie techniczne WordPress w Newcastle
Przewodniki metodyczne (SEO, GEO, compliance)
Te materiały opisują, jak pracujemy nad cytowaniami w modelach językowych, modernizacją WooCommerce B2B oraz odpornością operacyjną pod NIS2 i przetargi - niezależnie od miasta realizacji.
Zobacz też w innych miastach Wielkiej Brytanii
Co wyróżnia w Newcastle
Lokalna ekspertyza: - Stała opieka WordPress dla firm w Newcastle i w North East: testowane aktualizacje, kopie operacyjne, WAF i dziennik incydentów pod UK GDPR - Runbook uwzględnia freeze przed publikacją produktową, kalendarz Digital Union oraz formularze B2B i checkout WooCommerce w GBP - Aktualizacje rdzenia, wtyczek i motywów wyłącznie przez środowisko testowe z udokumentowaną ścieżką wycofania Nasz zespół rozumie specyfikę rynku w Newcastle i dostosowuje rozwiązania do lokalnych potrzeb biznesowych. W praktyce oznacza to nacisk na Core Web Vitals, lokalny intent oraz architekturę informacji dopasowaną do rynku w Newcastle.
Potrzebujesz usługi: Opieka techniczna WordPress w Newcastle?
Porozmawiajmy o tym, jak możemy wprowadzić Twoją stronę na wyższy poziom wydajności.
Umów bezpłatną konsultację w NewcastleFAQ - Opieka techniczna WordPress w Newcastle
Czy możecie przejąć stronę zaniedbaną lub już mającą problemy?
Tak. Audyt wyłania krytyczne luki: stary PHP, wtyczki bez łatek, kopia której nie da się odtworzyć, malware, formularz B2B albo checkout Stripe, który pada po aktualizacji, page builder generujący shortcode'y w treści. Lista napraw idzie przed stałą opieką. Pierwszy miesiąc odziedziczonej instalacji to zwykle więcej remediacji niż samego rytmu utrzymania.
Czy opieka jest realizowana zdalnie?
Tak. Kanał jest pisemny, z miesięcznym raportem statusu. Rozmowa wchodzi wtedy, gdy trzeba odblokować decyzję albo omówić incydent. Polski zespół utrzymujący serwis w Newcastle pracuje w strefie czasowej pokrywającej się z UK, więc okno dni roboczych pokrywa się z oknem klienta lepiej niż przy utrzymaniu transatlantyckim. Dyżur w oknie freeze przed kampanią B2B albo publikacją produktową zapisuje się w runbooku, a nie zgaduje w czacie w tygodniu szczytu.
Technologie i Specjalizacje - w Newcastle
Specjalizujemy się w:
Wspominamy o:
Sprawdź inne usługi WordPress i bazę wiedzy
Wzmocnij swój biznes dzięki profesjonalnemu wsparciu technicznemu w kluczowych obszarach ekosystemu WordPress.
Audyt CrUX i atrybucja LCP, INP, CLS per template.
Core Web Vitals, cache i szybki frontend.
Stabilność, aktualizacje i wsparcie po wdrożeniu.
Migracja do Astro, Next.js i headless WordPress.
Headless WordPress, Sanity, Strapi i Contentful z Astro lub Next.js.
Audyt, hardening i ochrona przed incydentami.
Powiązane kategorie
Artykuły wspierające temat

Jak zoptymalizować Interaction to Next Paint (INP) na stronach WordPress. Praktyczne poprawki najnowszej metryki Core Web Vitals wpływającej bezpośrednio na pozycje w Google.

Pole kontra lab, LCP, INP i CLS dla WordPressa w 2026. Zielone LCP Google to nadal 2,5 s w CrUX. 100/100 w Lighthouse to cel laboratoryjny. Consent, Cookiebot, widgety kasowe, cache HTML.

Porównanie najlepszych wtyczek do optymalizacji obrazów w WordPress, konfiguracja dostarczania WebP/AVIF, ekstrakcja critical CSS i ustawienie LiteSpeed Cache dla maksymalnych wyników PageSpeed.