Migracja Next.js / Astro w Monachium

Monachium jest trzecim pod względem liczby ludności miastem Niemiec: według polskiej Wikipedii pod koniec 2019 r. mieszkało tu niemal 1,5 mln osób, a aglomeracja liczy 2,6 mln. Miasto lokował w 1158 r. Henryk Lew. Dziś mają tu siedzibę Federalny Trybunał Finansowy, centrala Towarzystwa Maxa Plancka i Munich Re, największe na świecie towarzystwo reasekuracyjne. Działają tu zakłady Siemensa i produkcja samochodów BMW. Z punktu widzenia strony internetowej wynika z tego jedna rzecz: odbiorcą oferty bywa dział zakupów albo dział prawny, który czyta ją po niemiecku, sprawdza dwa razy i wraca do niej po kilku miesiącach. Taki czytelnik zauważy każdy adres, który przestał działać.

Prowadzę migracje z WordPressa, Joomli, Drupala i starszych aplikacji do Astro albo Next.js dla polskich firm obsługujących klientów z Monachium oraz dla zespołów, które mają tam biuro lub przedstawiciela. Inwentarz adresów, przekierowania, wdrożenie i kontrolę w Search Console robi jedna osoba, czyli ja. Opisuję poniżej, jak wygląda ta praca i które polskie przepisy sprawdzam przed przełączeniem domeny. Jeśli oferta jest kierowana wprost do niemieckich klientów, w osobnej sekcji wskazuję, co dochodzi z prawa niemieckiego.

#Kto w Bawarii czyta stronę firmy z Polski

Wikipedia opisuje Monachium jako główny ośrodek gospodarczy, kulturalny i naukowy południa Niemiec. Uniwersytet Ludwika i Maksymiliana sięga tradycjami 1472 r., a uniwersytet techniczny powstał w 1868 r. jako politechnika. Dla firmy usługowej albo producenta oznacza to dwa typy odbiorców. Pierwszy to inżynier lub analityk, który szuka szczegółów technicznych i pobiera dokumentację w PDF. Drugi to osoba zatwierdzająca dostawcę, która sprawdza stopkę, dane rejestrowe i politykę prywatności, zanim ktokolwiek zadzwoni.

w Monachium działa też duża społeczność polska. Wikipedia wymienia Konsulat Generalny RP, Centrum Kultury Polskiej, klub Polonia Monachium oraz pismo Polonik Monachijski. Dla usług kierowanych do Polaków mieszkających w Bawarii, takich jak biuro rachunkowe, kancelaria, tłumaczenia albo szkoła językowa, pierwszą wersją strony bywa polska, a niemiecka powstaje obok. Układ adresów, który to obsłuży bez konfliktu, planuję przed migracją, a nie po niej.

Zespół, który odbierze projekt po zakończeniu prac, często ma już wewnętrzne doświadczenie z JavaScriptem i TypeScriptem. W takim układzie Astro lub Next.js nie tworzy zależności od jednej agencji. Jeżeli nikogo takiego nie ma, ustalam utrzymanie zewnętrzne przed pierwszą linijką kodu.

#Kiedy migracja ma sens, a kiedy wystarczy poprawka w obecnym systemie

Migracja ma sens, gdy problem leży w architekturze, a nie w konfiguracji. Jeśli strona jest wolna, bo ma piętnaście wtyczek i brak cache, najpierw porządkuję obecny system. To tańsze od przepisywania frontendu i daje wynik w kilka dni. Migrację proponuję w czterech sytuacjach:

• serwer składa każdą podstronę z bazy przy każdym wejściu, a treść zmienia się raz w tygodniu,
• każda aktualizacja wtyczek wymaga ręcznego testu, bo nie ma środowiska testowego,
• redakcja chce zostać przy znajomym panelu, a frontend ma żyć w repozytorium z historią zmian,
• strona ma moduły interaktywne, na przykład konfigurator, panel klienta albo wyszukiwarkę z filtrami, które w starym CMS-ie są doklejone wtyczką.

Relaunch w obecnym CMS-ie jest lepszym wyborem, gdy backend jest aktualny, a kłopot ogranicza się do ciężkiego motywu albo chaotycznej nawigacji. Audyt kończy się pisemną rekomendacją z uzasadnieniem. Jeśli wystarczy naprawa, nie dokładam headless tylko po to, żeby użyć Astro. Technologia ma obniżyć koszt zmian i ryzyko działania, a nie stworzyć nowy projekt utrzymaniowy.

#Mapa adresów i przekierowania 301 w siedmiu krokach

1. Inwentaryzacja. Łączę trzy źródła: crawl serwisu, eksport z Google Search Console i logi serwera. Crawl pokazuje strony osiągalne z linków wewnętrznych. Search Console pokazuje adresy znane wyszukiwarce. Logi ujawniają wejścia z dokumentów PDF, newsletterów i zakładek. Duplikaty usuwam dopiero po zapisaniu, skąd pochodzi każdy adres. Dodaję istniejące przekierowania z .htaccess albo wtyczki, bo łańcuchy 301 sprzed lat pękają zwykle dopiero po migracji.

2. Mapa URL. Każdy stary adres dostaje w arkuszu jedną z trzech decyzji: zostaje bez zmian, przekierowanie 301 na konkretny nowy adres albo świadome 410. Zmianę sluga zapisuję jako osobną decyzję z uzasadnieniem, żeby generator stron niczego nie przestawił po cichu. Hurtowego przekierowania na stronę główną nie robię, bo Google traktuje je jak miękki błąd 404.

3. Model treści. Wpisy, strony, produkty, kategorie i pola własne, na przykład z ACF, przenoszę do kolekcji z jawnym schematem. W Astro to kolekcje walidowane schematem, w Next.js zwykle headless CMS albo pliki MDX. Schemat wyłapuje braki już przy budowaniu: puste opisy meta, brakujące teksty alternatywne, zdjęcia bez wymiarów.

4. Dane strukturalne i metadane. Tytuły, opisy, canonical, Open Graph i JSON-LD (Organization, LocalBusiness, Product, BreadcrumbList) generuję z frontmattera zamiast wklejać ręcznie. Porównuję stary i nowy HTML dla tych samych adresów, zanim cokolwiek trafi na domenę.

5. Hreflang. Każda para wersji językowych dostaje wzajemne odnośniki oraz x-default. Brak wzajemności to częsty błąd po migracjach wielojęzycznych, bo wtyczka tłumaczeniowa robiła to za redakcję i nikt nie pamięta, że to działało.

6. Środowisko testowe i przełączenie. Nowa strona stoi na osobnym adresie z noindex. Skrypt odpytuje każdy stary adres z mapy i sprawdza, czy kończy na właściwym celu jednym przeskokiem. Małe serwisy przełączam w całości, większe sekcjami: najpierw blog, potem oferta, na końcu formularze i integracje.

7. Search Console po starcie. Wysyłam nową mapę witryny i obserwuję raport indeksowania, błędy 404 oraz strony wykluczone przez canonical. Pozycje dla najważniejszych fraz porównuję z okresem sprzed przełączenia, a nie z poprzednim tygodniem, bo wahania po migracji są normalne.

Szczegóły techniczne i porównanie podejść opisuję na stronie o migracji do Astro i Next.js.

#Polska i niemiecka wersja strony

Wersja polska i niemiecka powinny mieć osobne, stabilne adresy. Najprościej utrzymać je w katalogach językowych jednej domeny, na przykład /pl/ i /de/. Osobne domeny krajowe mają sens, gdy firma prowadzi dwie spółki albo dwa niezależne zespoły sprzedaży, bo każda domena zbiera własne linki i wymaga osobnej pracy.

Google przyjmuje w hreflang kody języka z ISO 639-1, opcjonalnie z regionem z ISO 3166-1, i wymaga, żeby każda wersja wskazywała siebie oraz wszystkie pozostałe. Jeśli dwie strony nie odsyłają do siebie nawzajem, adnotacje są ignorowane. Dla strony, która mówi do Niemiec, zwykle wystarcza de, a region de-DE dodaję tylko wtedy, gdy mam powód odróżnić ofertę od wersji dla Austrii lub Szwajcarii. Wartość x-default wskazuje stronę wyboru języka albo wersję, którą Google ma pokazać użytkownikom spoza zdefiniowanych rynków.

Po migracji hreflang i canonical muszą prowadzić do nowych adresów, a nie do przekierowanych starych. Sprawdzam to skryptem na zbudowanym HTML, bo oglądanie kilku stron w przeglądarce takich błędów nie pokazuje. Osobny temat to tłumaczenia. Tekst po niemiecku powinien napisać albo sprawdzić ktoś, kto zna branżowe słownictwo odbiorcy, ponieważ automatyczny przekład kosztuje wiarygodność u czytelnika, który ocenia dostawcę po języku oferty.

#Astro czy Next.js dla serwisu pod rynek bawarski

Decyzja zależy od tego, co strona robi, a nie od branży. Astro wybieram dla stron, które w większości są treścią: strona firmowa, oferta usług, blog, dokumentacja produktu, katalog. Generuje HTML podczas budowania i dołącza JavaScript tylko do elementów, które go potrzebują. Dla producenta z dużym katalogiem PDF oznacza to szybkie strony bez serwera aplikacyjnego w ścieżce każdego wejścia. Więcej o tym podejściu piszę na stronie programista Astro.

Next.js wybieram, gdy strona ma logowanie, panel klienta, ceny zależne od zalogowanego użytkownika albo dane zmieniające się co minutę. Wtedy renderowanie po stronie serwera jest uzasadnione, ale rośnie koszt utrzymania, a hosting staje się osobną decyzją architektoniczną. W większym serwisie oba rozwiązania mogą działać pod jedną domeną: Astro dla witryny i publikacji, Next.js dla portalu pod wybraną ścieżką.

Gdy treść ma zostać w WordPressie, a zmienić się ma tylko frontend, opisuję to na stronie o headless CMS. Rekomendację zapisuję w zakresie prac razem z uzasadnieniem i tym, co odrzuciłem. Za rok ktoś w twojej firmie zapyta, dlaczego tak, a nie inaczej, i odpowiedź powinna być w repozytorium.

#Polskie przepisy przy migracji strony

Dla firmy z siedzibą w Polsce punktem odniesienia jest prawo polskie i unijne. Przebudowa frontendu to najtańszy moment na uporządkowanie obowiązków, bo zmiana hostingu i integracji i tak wymusza ich ponowne podłączenie. Sprawdzam trzy obszary.

RODO. Formularz kontaktowy, analityka, CRM, narzędzie do umawiania spotkań i logi infrastruktury mogą przetwarzać dane osobowe. Rozporządzenie (UE) 2016/679 wymaga w art. 28 umowy z podmiotem przetwarzającym, a w art. 30 rejestru czynności przetwarzania. Migracja zmienia listę dostawców, więc przygotowuję aktualne zestawienie: kto przetwarza jakie dane, gdzie i na jakiej podstawie wskazanej przez klienta. Organem nadzorczym w Polsce jest Prezes Urzędu Ochrony Danych Osobowych. Interpretację prawną zatwierdza doradca klienta, a zespół techniczny dostarcza dokumentację przepływów i dowody testów.

Pliki cookie i skrypty. Art. 399 Prawa komunikacji elektronicznej dopuszcza przechowywanie informacji w urządzeniu końcowym lub dostęp do nich po uprzednim jednoznacznym poinformowaniu użytkownika o celu i po jego zgodzie. W WordPressie wtyczka zgód często blokowała skrypty automatycznie. W Astro albo Next.js blokadę trzeba zaprogramować, więc analityka, piksele reklamowe i osadzone mapy ładują się dopiero po zgodzie. Sprawdzam to w narzędziach przeglądarki na czystym profilu, zanim przełączę domenę.

Dostępność. Ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze obejmuje w art. 3 ust. 2 handel elektroniczny. Art. 4 pkt 1 wyłącza usługi oferowane przez mikroprzedsiębiorców. Jeśli sklep lub serwis sprzedażowy podlega ustawie, nowe szablony od początku dostają poprawną strukturę nagłówków, etykiety formularzy, kontrast i obsługę z klawiatury. Nie jestem prawnikiem, więc zakres obowiązków konkretnej firmy potwierdza jej doradca.

#Gdy oferta jest kierowana do klientów Niemczech

Polski usługodawca, który kieruje ofertę do niemieckich klientów, podlega dodatkowo przepisom państwa odbiorcy. W praktyce chodzi o dane usługodawcy w Impressum (§ 5 Digitale-Dienste-Gesetz), zgodę na zapis informacji na urządzeniu użytkownika (§ 25 TDDDG) oraz niemiecką ustawę o dostępności BFSG, która obejmuje usługi handlu elektronicznego kierowane do konsumentów. Dla firm prywatnych w Bawarii nadzór nad ochroną danych sprawuje Bayerisches Landesamt für Datenschutzaufsicht z siedzibą w Ansbach.

Te przepisy opisuję szerzej na niemieckiej wersji tej strony, a tutaj zapisuję tylko tyle: w zakresie prac pojawia się punkt do potwierdzenia z niemieckim doradcą. Link do Impressum musi być w stopce każdego szablonu, także na stronie 404 i na podstronach kampanii zbudowanych osobno. Reszta zależy od tego, czy sprzedajesz konsumentom i jakiej wielkości jest firma.

#Trzy wzorce projektów dla rynku bawarskiego

Poniższe wzorce są scenariuszami zbudowanymi z powtarzalnych problemów, a nie opisami klientów WPPoland.

#Dostawca komponentów z katalogiem i kartami technicznymi

Firma produkcyjna z Polski sprzedaje podzespoły zakładom w Bawarii. Katalog ma kilkaset pozycji, karty techniczne leżą w PDF, a formularz zapytania ofertowego łączy się z CRM-em. Inżynierowie klienta linkują do konkretnych plików od lat. Mapa URL rozdziela trwałe strony produktów od sezonowych landingów kampanii, a pliki PDF dostają status równorzędny ze stronami. Astro obsługuje katalog i wersję niemiecką, a zapytania ofertowe idą przez endpoint z walidacją i potwierdzeniem dostarczenia. Odbiór obejmuje dostępność każdego pliku, zgodność liczby produktów po imporcie oraz test wysyłki zapytania z telefonu.

#Software house lub agencja z portfolio dla klientów DACH

Zespół prowadzi stronę z ofertą, opisami zrealizowanych projektów i blogiem technicznym w WordPressie z builderem. Strona wolno ładuje się na telefonie, a wersja niemiecka powstała jako kopia stron bez hreflang. Migracja zaczyna się od modelu treści dla opisów projektów: klient (jeśli wolno go nazwać), zakres, technologie, wynik. Wersje językowe dostają wspólne identyfikatory, z których powstają odnośniki hreflang. Blog zostaje w WordPressie jako headless CMS, a Astro buduje ofertę i archiwum. Przełączenie robię w dwóch etapach: najpierw blog, który ma najwięcej linków zewnętrznych, potem oferta. Odbiór opiera się na porównaniu Core Web Vitals dla typowych szablonów.

#Usługi dla Polonii w Bawarii

Biuro rachunkowe, kancelaria lub szkoła językowa obsługuje Polaków mieszkających w Monachium i okolicach. Strona ma wersję polską jako główną, a niemiecką jako dodatkową dla instytucji i pracodawców. Najczęstszy problem to formularz kontaktowy i kalendarz rezerwacji spięte wtyczkami, które po migracji przestają działać bez komunikatu. Test obejmuje prawdziwą wysyłkę formularza, potwierdzenie na adres odbiorcy i obsługę zgody. Adresy z linkami z katalogów polonijnych i portali ogłoszeniowych zachowują dotychczasową ścieżkę, a gdy treść została połączona, stary adres dostaje jedno przekierowanie na najbliższy odpowiednik.

#Co najczęściej psuje się przy migracji i jak to sprawdzam

• Zgubione adresy. Stare adresy z parametrami, paginacją albo wersjami do druku wypadają z mapy. Sprawdzam je na liście z logów serwera i z Search Console, a nie tylko z crawla.
• Podwójna treść. Stara i nowa strona są dostępne jednocześnie, bo środowisko testowe nie miało noindex. Sprawdzam nagłówki i meta robots na stagingu, zanim ktokolwiek dostanie link.
• Błędny canonical. Porównuję wyrenderowany <link rel="canonical"> na próbce adresów po przełączeniu. Canonical wskazujący na staging to klasyczny błąd, który kosztuje tygodnie.
• Wielkość liter i ukośnik na końcu adresu. Dla serwera to inny URL. Test przekierowań bierze obie formy z logów.
• Formularze bez dostarczenia. Wysyłam testowe zgłoszenie z każdego formularza i sprawdzam, czy dotarło, zanim stary system zostanie wyłączony.
• Obrazy ze starego katalogu uploadów. Przepisuję ścieżki skryptem i sprawdzam, czy żaden plik nie zwraca 404.
• Treść widoczna dopiero po wykonaniu JavaScriptu. Czytam surowy HTML, bo to on trafia do robota przy pierwszym pobraniu strony.

#Przełączenie, okno pomiarowe i plan powrotu

Wdrożenie zaczynam od pomiaru stanu wyjściowego: Core Web Vitals z danych rzeczywistych, czas odpowiedzi, skuteczność formularzy, ruch organiczny i poziom indeksacji. Wyniki przypisuję do typów stron i urządzeń, ponieważ średnia dla domeny ukrywa wolny formularz mobilny. Według web.dev progiem dobrego wyniku jest LCP do 2,5 s, INP do 200 ms i CLS do 0,1 dla co najmniej 75% wizyt, więc te wartości traktuję jako cel odbioru.

Przed przełączeniem zapisuję kryteria powrotu. Mogą nimi być niedostępny formularz kontaktowy, błąd w ścieżce zamówienia, utrata zgłoszeń, nieoczekiwane blokowanie indeksacji albo awaria integracji krytycznej. Każde kryterium ma osobę decyzyjną. Poprzedni system pozostaje gotowy przez uzgodnione okno pomiarowe, a zmianę DNS lub routingu ćwiczę wcześniej na środowisku przedprodukcyjnym. Jeśli nowy system zapisuje dane, plan opisuje, jak zabezpieczyć rekordy utworzone po przełączeniu.

Google podaje, że przeniesienie większości stron małej lub średniej witryny trwa kilka tygodni, a przekierowania warto utrzymywać co najmniej rok. W tym czasie co kilka dni sprawdzam raport indeksowania, błędy 404 w logach i zapytania tracące wyświetlenia. Spadek na jednej grupie stron zwykle oznacza brakujące przekierowanie albo zgubiony hreflang i naprawiam to w pierwszej kolejności. Po spełnieniu kryteriów odbioru archiwizuję stary system: kod, bazę, pliki i instrukcję odtworzenia, a nie sam eksport treści.

#Praca zdalna z zespołem w Monachium

Monachium i Polska leżą w tej samej strefie czasowej, więc warsztaty, przegląd mapy adresów i dyżur w dniu przełączenia odbywają się w godzinach wspólnych dla obu zespołów. Decyzje zapisuję pisemnie w jednym rejestrze, a pytania wymagające odpowiedzi biznesowej trafiają do jednej osoby po stronie klienta. WPPoland działa w modelu near-shore wewnątrz UE: Polska jest bazą dostarczania usługi dla klientów z kraju i z innych państw członkowskich.

Dostęp wykonawcy do środowisk klienta zapisuję w dokumentacji dostępu i w umowie powierzenia. Stosuję najmniejsze potrzebne uprawnienia, konta imienne i uwierzytelnianie wieloskładnikowe. Po zakończeniu prac przekazuję repozytorium, konfigurację środowisk bez sekretów, mapę przekierowań, procedurę publikacji i cofnięcia oraz listę obowiązków utrzymaniowych. Sekrety trafiają do menedżera wskazanego przez klienta.

#Jak zacząć

Wyślij adres obecnej strony, nazwę CMS-a z wersją, informację o źródłach ruchu oraz listę integracji: formularze, CRM, rezerwacje, płatności. Napisz też, czy strona sprzedaje konsumentom i które wersje językowe mają zostać. Odpowiadam pisemnym zakresem: liczba adresów do zmapowania, rekomendacja Astro albo Next.js z uzasadnieniem, lista elementów prawnych do potwierdzenia z doradcą i plan przełączenia. Wycena wynika z tego zakresu.