Opieka techniczna WordPress w Berlinie

Polski zespół, który utrzymuje WordPressa dla firmy w Berlinie, nie dokłada kolejnego abonamentu auto-update. Utrzymuje serwis, który stoi przy Rosenthaler Platz, w Kreuzbergu albo w biurze przy Spree, na rynku, gdzie awaria landingu przed Berlin Fashion Week albo martwy formularz zapisu na pilota GovTech to temat na rozmowę z compliance i z redakcją, a nie tylko z marketingiem. Ta strona opisuje opiekę techniczną WordPressa właśnie w tym układzie: polski delivery, niemiecki kontekst prawny i operatorski, bez cennika i bez obietnic dostępności w procentach.

Szerszy opis produktu opieki, niezależny od miasta, jest na stronie opieki technicznej WordPress. Tu schodzimy do Berlina: startupy D2C i scale-upy z Mitte, ekosystem GovTech i sektor publiczny, BSI i NIS2, GoBD, MwSt, DATEV, rezydencja danych na Hetznerze, kalendarz freeze i dziennik incydentów, który da się pokazać przy pytaniu audytora. Sklep WooCommerce z checkoutem pod Packstation to osobna ścieżka: programista WooCommerce w Berlinie. Budowa od zera albo przebudowa motywu idzie do programisty WordPress w Berlinie.

#Co oznacza opieka WordPress przy serwisie startupu, dostawcy GovTech albo firmy D2C

Opieka to nie włącz auto-update i miej nadzieję. Dla serwisu scale-upu z Kreuzbergu, dostawcy rozwiązań dla Unit GovTech Berlin albo marki D2C z subskrypcją kawy 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 - drobne zmiany w motywie, nowy formularz, poprawka Core Web Vitals - wisi na tym fundamencie. Bez niego kolejna wtyczka tylko powiększa powierzchnię ataku.

Serwis w Berlinie często zbiera dane i treści, których nie wolno traktować jak bloga agencji. Formularz zapisu na pilota z administracją, panel partnera B2B, landing produktowy przed dropem, logowanie do strefy inwestora: 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ą użytkownik 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 językowe i te same wtyczki formularzy w trybie testowym. Aktualizacja od razu na żywo, bo to tylko patch, jest najkrótszą drogą do martwego landingu w środę przed tygodniem mody albo do formularza, który przestaje zbierać leady w oknie kampanii.

Po wgraniu łatek na kopii testowej idzie checklista, nie wyczucie. Logowanie wp-admin, zapis strony, formularz kontaktowy, cron, poczta wychodząca, webhooki, hreflang. Jeśli serwis ma WooCommerce, koszyk i płatność w sandboxie też wchodzą w checklistę, ale pełna przebudowa checkoutu nie jest tematem tej strony. Dopiero po teście 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.

W Berlinie dochodzi kalendarz zamrożenia, którego nie da się zgadnąć z polskiego sprintu. Berlin Fashion Week w styczniu i lipcu dokłada skoki ruchu do serwisów odzieżowych i eventowych. Dropy D2C w Prenzlauer Berg i Mitte często idą w ten sam tydzień co newsletter founderów. Subskrypcje kawy, pet food i suplementów mają własne okna odnowień, gdy magazyn w Ludwigsfelde albo Großbeeren musi nadążyć za falą zamówień. W tych oknach produkcja nie dostaje drobnej aktualizacji SEO. Dostaje freeze zapisany w runbooku, dyżur na cache i DNS oraz zakaz ruszania WPML, Polylang albo wtyczki formularzy. Łatka bezpieczeństwa, która nie może czekać, idzie przez środowisko testowe w godzinach, nie w nocy przed otwarciem dropu.

#Kopie operacyjne to nie archiwum GoBD

Codzienna kopia WordPressa służy do odtworzenia serwisu po błędzie albo ataku. GoBD, czyli Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff, dotyczy czego innego: ksiąg, dowodów księgowych i możliwości wglądu skarbówki. Kopia w panelu hostingu nie spełnia GoBD sama z siebie. Brakuje niezmienności, kompletności, maszynowej czytelności i dokumentacji procedury.

W praktyce utrzymania rozdziela się 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 podatkowe u klienta, zwykle w DATEV albo w DMS kancelarii w Berlinie albo w okolicach. Wrzucenie tych trzech warstw do jednego katalogu FTP kończy się tym, że po dwóch latach nikt nie wskaże paczki przeznaczonej do DATEV wśród reszty plików.

U dostawcy GovTech albo u scale-upu z danymi B2B dochodzi czwarta oś, której GoBD nie rozwiązuje za zespół. Formularz demo, upload dokumentu RFP, zgoda marketingowa i logowanie do portalu partnera to dane osobowe pod DSGVO, a równolegle część z nich wchodzi w obieg księgowy. Eksport z WordPressa dla Steuerberatera nadal musi dać się włożyć do DATEV. Eksport „dla działu sprzedaży” to osobny plik, osobny rytm, osobna osoba po stronie klienta. Opieka, która wrzuca oba do jednego CSV w nocy, produkuje dwa złe zamknięcia zamiast jednego dobrego.

#WAF, monitoring i dziennik pod BSI i NIS2

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. Niemieckie wdrożenie NIS2 (NIS2UmsuCG, BSIG po nowelizacji z 6 grudnia 2025) dodało rejestrację u BSI przez portal MELDEX; dla podmiotów już w zakresie okno rejestracji zamykało się 6 marca 2026. Berlin jako miasto-państwo nie ma własnej landescyberbehörde dla NIS2: meldunki i rejestracja idą do BSI w Bonn. Agencja WordPress nie składa zgłoszenia naruszenia za klienta. Dostarcza oś czasu, której klient nie musi rekonstruować z pamięci, gdy BSI albo własny DSB poprosi o TOM i o historię łatek.

Serwisy DE/EN w Berlinie, a bywa że jeszcze FR albo PL przy zespole międzynarodowym, wymagają syntetycznego checka, który nie kończy się na stronie głównej po niemiecku. Łapie też /en/, formularz w drugiej locale i PDF Impressum. WAF, który blokuje znaki z pola „Firmenname” jako anomalny payload, jest błędem konfiguracji, nie sukcesem bezpieczeństwa. To wychodzi przy pierwszym teście, nie przy pierwszym zgłoszeniu z biura w Mitte.

#Berlin jako kontekst, nie jako ozdobnik w tytule

Berlin to nie tylko gęsta siatka startupów D2C między Kreuzbergiem a Mitte. To też miasto-państwo, w którym Unit GovTech Berlin łączy administrację z ekosystemem GovTech, a BMDS, Land Berlin i IHK Berlin współpracują przy pilotażu funkcji „Direktauftrag” na Marktplatz Deutschland. Silicon Allee działa dziś jako venture lab Fraunhofer HHI i łączy badania deep tech z komercjalizacją. SIBB Incubator wspiera wczesne zespoły w cyberbezpieczeństwie i wiarygodnej AI. To nie jest tło do sloganu. To jest powód, dla którego WordPress „firmowy” z Berlina częściej niż w mniejszym mieście trzyma strefę partnerów, landing produktowy, formularz RFP albo portal, którego nie wolno zepsuć wtyczką cache w noc przed deadline’em pilota.

Warstwa publiczna jest równie twarda. Senatsverwaltung, bezsenatowe instytucje i dostawcy dla administracji muszą myśleć o dostępności (European Accessibility Act od 28 czerwca 2025), o Impressum, o zgodach i o tym, czy treść po aktualizacji motywu nadal spełnia wymagania WCAG. Unit GovTech Berlin szuka rozwiązań, które da się wdrożyć w pilotażu albo w większym rolloutcie. WordPress w takim projekcie nie jest blogiem. To często front dla formularzy, dokumentów i integracji z systemami wewnętrznymi. Opieka, która traktuje go jak landing agencji, gubi kontekst compliance już na onboardingu.

Startup z biura przy Torstraße albo w Factory Berlin często ma dwa rytmy naraz: codzienną stronę produktową i skoki kampanii przed rundą albo przed tygodniem mody. Oba rytmy kończą się na tym samym serwerze. Jeśli aktualizacja wtyczki SEO psuje hreflang albo robots w tygodniu dropu, koszt jest wyższy niż przy zwykłym blogu. Runbook freeze nie jest luksusem. Jest warunkiem, żeby zespół produktowy mógł skupić się na kampanii, a nie na rollbacku o trzeciej w nocy.

#Operacje specyficzne dla Niemiec

Polski zespół zna WordPressa. Niemiecki klient w Berlinie pyta o coś innego: gdzie leżą dane, jak długo trzymamy logi, kto wystawia fakturę z podatkiem, kto wpuszcza pliki do DATEV, czy strefa partnerów ma osobne zgody. Te pytania trzeba umieć obsłużyć procesem, nie sloganem o zgodności z RODO.

#GoBD i retencja logów, które da się pokazać

GoBD nie czyni z WordPressa programu księgowego. Wyznacza, jak elektroniczne dowody i zapisy mają dać się odtworzyć. Księgi i sprawozdania nadal kręcą się wokół dekady przechowywania (AO par. 147, HGB par. 257). Dla dowodów księgowych Vierte Bürokratieentlastungsgesetz skróciło okres do ośmiu lat; dla instytucji kredytowych to skrócenie weszło od 1 stycznia 2026. Listy handlowe bez statusu dowodu: sześć lat. WordPressowy debug.log rotowany co tydzień tego nie pokrywa.

W opiece ustala się, które zdarzenia są podatkowe albo audytowe, a które są śmieciem diagnostycznym. Zmiana wtyczki płatności, zmiana stawki podatku w sklepie, eksport zamówień, zmiana danych fakturowych: to idzie do dziennika z datą i operatorem. Wpisy PHP Notice z motywu: nie. Klient dostaje opis procedury do swojej Verfahrensdokumentation. Nie dostaje obietnicy, że kopia wtyczki UpdraftPlus jest archiwum skarbowym.

U scale-upu i u dostawcy dla sektora publicznego logi mają jeszcze jedną rolę. Portal demo, strefa partnera, upload materiałów produktowych: to nie jest komentarz pod wpisem. Retencja tych logów idzie z polityką klienta i z umową powierzenia, nie z domyślnym „30 dni bo tak ma hosting”. Runbook zapisuje, co rotujemy, co archiwizujemy i kto u klienta jest właścicielem tej decyzji.

#Hosting, rezydencja i pytanie o Hetzner

Dane osobowe pod RODO/GDPR i dane podatkowe pod GoBD ciągną pytanie: w której jurysdykcji stoi serwer. Hetzner trzyma własne centra w Falkenstein i Norymberdze; tam obowiązuje prawo niemieckie i dostęp na podstawie niemieckiego nakazu. Helsinki to Unia, ale już nie Niemcy. Ashburn albo Hillsboro to Stany. Dla wielu compliance officerów z Mitte albo z Charlottenburga to nie niuans, tylko veto. DSB scale-upu bywa jeszcze ostrzejszy: pyta o DE, zanim zapyta o dzielnicę.

Rozmowa o hostingu w onboardingu jest więc merytoryczna, nie wizerunkowa. Czy produkcja jest w DE? Czy kopia wyjeżdża nocą na bucket w innym regionie? Czy CDN kończy TLS w UE? Utrzymanie WordPressa, które wrzuca wszystko na najtańszy VPS za oceanem, odpada na pierwszym callu z bezpieczeństwem, niezależnie od tego, czy biuro ma widok na Fernsehturm. Berlin ma centra danych w aglomeracji, ale origin WordPressa nadal często stoi u Hetznera w Falkenstein albo Norymberdze. To nie jest wada. To jest jawna decyzja rezydencji, którą trzeba opisać w runbooku, a nie ukrywać za hasłem „hosting w Berlinie”.

#Faktury MwSt jako proces, bez kwot

Ta strona nie publikuje cen WPPoland. Opisuje, jak faktura z podatkiem niemieckim ma wyglądać jako obieg, nie jako cennik. Faktura MwSt potrzebuje kompletnych danych: nazwa i adres, USt-IdNr albo Steuernummer, opis świadczenia, data, stawka, kwota podatku albo adnotacja o odwrotnym obciążeniu przy B2B wewnątrzunijnym, numer faktury w nieprzerwanym ciągu. Strona usługowa albo sklep, który po aktualizacji wtyczki fakturującej gubi NIP albo stawkę, produkuje dokumenty, których księgowość nie przyjmie.

W utrzymaniu pilnuje się, żeby wtyczka faktur, pole podatkowe i PDF nie rozjechały się po patchu. Zespół nie wystawia deklaracji podatkowej za klienta. Nie podaje stawek jako oferty agencji. Pilnuje, żeby proces, który klient uzgodnił ze Steuerberaterem, nadal działał po cyklu aktualizacji.

#DATEV zostaje po stronie klienta

DATEV to ekosystem kancelarii, nie panel WordPressa. Eksport CSV, XML albo PDF plus metadane może wychodzić ze sklepu albo z CRM podpiętego pod WP. Import, księgowanie i archiwum robi kancelaria w DATEV Unternehmen online albo w swoim DMS. Granica jest twarda i zapisana w runbooku: agencja dostarcza kompletny, powtarzalny eksport; klient i doradca wpuszczają go do DATEV. Przejęcie „my wam zaksięgujemy w DATEV” nie wchodzi w zakres opieki WordPress.

Gdy eksport psuje się po aktualizacji wtyczki zamówień, to jest incydent utrzymaniowy. Gdy kancelaria zmienia mapowanie kont, to jest zmiana po stronie klienta. Mieszanie obu ról kończy się mailami, w których nikt nie wie, kto ma poprawić stawkę. Przy grupie z biurem w Mitte i księgowością w innym mieście dochodzi jeszcze prośba o „ten sam plik do drugiej GmbH”. To jest drugi eksport, nie tłumaczenie pierwszego w Excelu o północy.

#RODO, NIS2 i EAA: kto komu raportuje

RODO (GDPR) zostaje ramą danych osobowych: umowa powierzenia, minimalizacja, zgody, 72 godziny na zgłoszenie naruszenia do organu. NIS2UmsuCG weszło w życie 6 grudnia 2025. Podmioty w zakresie, które przekroczyły próg 50 pracowników albo 10 milionów euro obrotu, muszą rejestrować się u BSI i wdrazać środki z par. 30 BSIG. § 38 BSIG obciąża zarząd obowiązkiem zatwierdzenia i nadzoru nad tymi środkami. European Accessibility Act wszedł w życie 28 czerwca 2025; serwis publiczny albo strona B2C, który po aktualizacji motywu gubi kontrast, etykiety formularzy albo focus, wraca jako regresja dostępności, nie jako ticket UX.

Z tego dla WordPressa wynika skromny, konkretny obowiązek. Utrzymanie dostarcza logi, oś czasu i opis zmian. Klient klasyfikuje, czy zdarzenie jest incydentem nadzorczym. Nikt po stronie agencji nie podpisuje się pod „jesteście NIS2-compliant, bo macie WAF”. To byłoby kłamstwo opakowane w produkt. Scale-up z Kreuzbergu i dostawca GovTech i tak przyniosą własną checklistę. Lepiej mieć swoją wcześniej.

#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 formularz, czy wp-admin, czy cała produkcja, czy tylko locale EN, czy tylko landing dropu. Ograniczenie: tryb konserwacji, cofnięcie wtyczki, wyłączenie endpointu, rotacja haseł, twardy WAF. 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 Fashion Week okno bywa szersze niż w zwykłym miesiącu, bo koszt martwego landingu w tygodniu mody 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 BSI albo UODO, dziennik z opieki jest załącznikiem. Brak dziennika oznacza, że compliance składa raport ze zrzutów ekranu i ze wspomnień z Teams.

#Przypadek: aktualizacja wtyczki formularzy w oknie Berlin Fashion Week

Landing kolekcji limitowanej, dwie locale (DE, EN), formularz zapisu na listę oczekujących, cache na Cloudflare, integracja z narzędziem mailowym. W kolejce do produkcji leżała aktualizacja wtyczki formularzy plus drobny patch SEO. Na środowisku testowym, sklonowanym z produkcji, angielski slug po zapisie strony zwracał 404, a hreflang na DE wskazywał martwy URL. Formularz DE działał. Formularz EN gubił pole zgody, bo szablon motywu wołał stary filtr.

Na produkcji ten sam zestaw poszedłby w poniedziałek przed otwarciem tygodnia mody. Zespół marketingu dostałby kolejkę „link z Instagrama nie działa”, a magazyn w Ludwigsfelde dostałby zamówienia na SKU, którego landing już nie zbiera leadów. środowisko testowe zatrzymał promocję. Freeze na tydzień mody został dotrzymany. Motyw dostał poprawkę haka, checklista locale (home, landing, formularz, hreflang) przeszła po evencie, dopiero potem produkcja.

Nie ma tu nazwy firmy, bo to kształt zdarzenia, nie case study z logotypem. Jest mechanizm: najpierw kopia, potem produkcja, a w tygodniu Fashion Week w ogóle nic, chyba że łatka bezpieczeństwa nie może czekać. Ten sam kształt wraca przy wtyczkach cache, przy integracji z CRM, która po patchu gubi webhook, i przy aktualizacji SEO, która nadpisuje robots i wycina landing dropu z indeksu.

#WordPress Meetup Berlin, nie w panelu hostingu

WordPress Meetup Berlin spotyka się regularnie, w 2026 nadal w ostatnią środę miesiąca, w Bezirkszentralbibliothek Frankfurter Allee „Pablo-Neruda-Bibliothek” przy U-Bahn Frankfurter Tor. Grupa ma stronę meetup.com/berlin-wordpress-meetup i miesza tematy dla użytkowników i developerów. Większość spotkań jest po niemiecku, ale część uczestników pracuje po angielsku. To nie jest kanał sprzedaży. To jest miejsce, w którym widać, jak lokalni maintainerzy aktualizują, jak rozmawiają o uprawnieniach i o hostingu.

WP-CLI w utrzymaniu nie jest ozdobą meetupową. 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 przy Frankfurter Allee argument „zrobimy to ręcznie w panelu, bo redakcja czeka na kampanię” brzmi jeszcze gorzej.

Mitte i Kreuzberg pokazują drugą warstwę miasta: zespoły produktowe i marketingowe, które publikują poza europejskim popołudniem albo w oknie dropu. Opieka, która nigdy nie wychodzi poza ticket, gubi ten kontekst i wgrywa wtyczkę cache na produkcję w noc, w której serwis ma wytrzymać skok z newslettera founderów.

#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, ile jest locale, czy Impressum jest twarde. Baseline Lighthouse na stronie głównej, na najważniejszym formularzu i na jednym URL-u EN jeśli istnieje. Lista ryzyk z priorytetem: najpierw to, co psuje odtworzenie i bezpieczeństwo, potem to, co psuje konwersję albo kampanię.

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 scale-upu albo dostawcy GovTech w Berlinie bez kopii testowej nie wchodzi w stały abonament z otwartymi auto-update.

Miesiąc stały: okno aktualizacji poza kalendarzem freeze D2C, 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 (host poza DE, brak 2FA u redakcji, DATEV nadal na ręcznym PDF, freeze na Fashion Week jeszcze nie wpisany). Bez residualnego ryzyka raport jest broszurą.

Przejęcie zaniedbanej 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 Confluence, trzy wtyczki językowe naraz, landing z zeszłego dropu, który nadal jest kanoniczny. 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 i lokalnie programista WordPress w Berlinie. Sklep, checkout, SEPA, DHL Packstation i podatki: programista WooCommerce w Berlinie oraz filar programista WooCommerce. 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 z kampanii D2C

Origin w Niemczech na Hetznerze nie naprawi ciężkiego motywu. HTTP/3, Brotli, AVIF, cache, który nie trzyma prywatnego formularza ani sesji zalogowanego partnera, ograniczenie wtyczek z zapytań SQL na każdej podstronie: to nadal robota utrzymaniowa. Core Web Vitals mierzymy na realnych URL-ach, nie na pustej instalacji. INP psuje się od skryptów czatu, od tag managera, który marketing dodał poza ticketingiem, i od widgetu mapy wgranej jako pełny iframe. Opieka, która nie widzi GTM, będzie gonić optymalizację obrazków nieskończoność.

Dla serwisu D2C liczy się tydzień dropu, nie średnia z kwartału. Monitoring z jednego regionu USA kłamie, gdy kupujący wchodzą z telefonu w U8 między Alexanderplatz a Kottbusser Tor. Punkt pomiaru w DE albo przynajmniej w UE jest częścią kontraktu operatorskiego. Przed Berlin Fashion Week i przed falą subskrypcji 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. Zostawienie dwudziestu starych URL-i „na wszelki wypadek” jest długiem, nie ostrożnością.

#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 i po zmianie zespołu redakcyjnego. 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.

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 Mitte, z Kreuzbergu albo z ekosystemu GovTech i tak przyniesie własną checklistę. Lepiej mieć swoją wcześniej. Dokumentacja hardeningu WordPress, niezależna od miasta, jest w WordPress Developer Handbook. Opieka w Berlinie dodaje do niej kalendarz freeze, pytanie o BSI i NIS2 oraz jawny opis rezydencji na Hetznerze.

#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, locale 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 musi zostać w Niemczech, oraz czy w kalendarzu jest Berlin Fashion Week, drop D2C albo deadline pilota z administracją. Z tego powstaje plan: co naprawiamy zanim w ogóle wejdziemy w miesięczny rytm, a co zostaje w kadencji.

Opieka w Berlinie 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 GoBD, BSI, freeze D2C i procesach podatkowych po stronie klienta, zostajemy przy tym, co ta strona opisuje: środowisko testowe, kopia, WAF, dziennik, kalendarz freeze, rezydencja na Hetznerze i runbook, który da się pokazać audytorowi bez rekonstruowania historii z pamięci.