Migracja Next.js / Astro we Frankfurcie nad Menem

Frankfurt nad Menem to piąte pod względem liczby ludności miasto Niemiec. Wikipedia podaje ponad 775 tys. mieszkańców pod koniec 2024 roku i metropolię liczącą około 6 mln osób. To jedna z najważniejszych metropolii finansowych świata oraz centrum wystawiennicze i handlowe, z ruchliwym węzłem kolejowym i największym lotniskiem w Niemczech. Dla firm z tego miasta strona internetowa często łączy ofertę usług, materiały dla inwestorów albo partnerów oraz formularze leadów, które muszą działać po niemiecku i spełniać niemieckie obowiązki prawne. Jeśli taki serwis stoi na starym WordPressie, Joomli czy Drupalu i każda aktualizacja wtyczek przed targami jest ryzykiem, przeniesienie go do Astro albo Next.js obniża koszt utrzymania i liczbę miejsc, które da się zaatakować. Prowadzę takie migracje sam, od spisu adresów po kontrolę w Search Console.

#Skąd we Frankfurcie bierze się kalendarz ruchu i co to zmienia w harmonogramie

Frankfurt łączy ciągły ruch finansowy z kalendarzem targów Messe Frankfurt. W okresach dużych imprez wystawienniczych rosną zapytania o hotele, logistykę, usługi dla wystawców i lokalne oferty B2B. Wikipedia podkreśla też międzynarodowy charakter miasta: ponad 40% obywateli to migranci lub osoby o pochodzeniu imigranckim, a aglomerację zamieszkuje ponad 170 narodowości. Stąd częste strony dwujęzyczne de/en i treści skierowane do klientów z wielu krajów.

Dla strony firmowej wynika z tego kilka konkretów. Ruch nie rozkłada się równo przez rok. Migracja nie powinna wystartować w środku największego tygodnia targowego ani tuż przed uruchomieniem kampanii sprzedażowej, bo Google potrzebuje kilku tygodni na przetworzenie nowych adresów, a redakcja potrzebuje spokoju na poprawki po starcie.

W praktyce ustalam z klientem trzy daty: zamrożenie treści, przełączenie i koniec okna pomiarowego. Wszystkie trzy mają się zmieścić w okresie z najmniejszym ruchem zapytań. Które to tygodnie, pokazują dane z Search Console i z CRM za poprzedni rok.

#Czy moja strona we Frankfurcie w ogóle potrzebuje migracji?

Nie zawsze. Jeśli strona jest wolna przez jedną ciężką wtyczkę, brak cache albo przeładowany motyw, naprawiam to w obecnym CMS-ie w kilka dni i nie wyceniam przepisywania serwisu. Migracja ma sens, gdy problem siedzi w architekturze: każda podstrona składana z bazy danych, kilkadziesiąt wtyczek do pilnowania co tydzień, panel, którego redakcja boi się przed sezonem targowym.

Astro generuje HTML z plików albo z API podczas budowania, więc na produkcji nie ma PHP ani bazy danych dostępnej z zewnątrz. Dobrze pasuje do stron firmowych, ofert usług, blogów i dokumentacji. Next.js wybieram, gdy strona ma logowanie, portal klienta, ceny zależne od użytkownika albo dane liczone na żądanie.

#Jak zaplanować migrację, żeby nie trafiła w szczyt Messe?

Google podaje w dokumentacji o przenoszeniu witryny, że przy małej lub średniej stronie przeniesienie większości adresów trwa kilka tygodni. W tym czasie pozycje mogą się wahać. Dla firmy, która zarabia na ruchu wokół targów, wniosek jest prosty: start ustalam tak, żeby te tygodnie wypadły przed szczytem, a nie w jego środku.

Duże serwisy przenoszę sekcjami. Najpierw blog albo baza wiedzy, potem strony ofertowe, na końcu formularze i integracje. Reverse proxy kieruje każdą ścieżkę do starego albo nowego systemu. Małe strony przełączam jednorazowo, poza godzinami największego ruchu.

#Jak buduję mapę adresów i przekierowania 301?

Mapa adresów to arkusz, w którym każdy stary URL ma przypisany nowy. Listę źródłową zbieram z miejsc, które wskazuje Google: z map witryny, listy w CMS-ie, logów serwera, analityki i raportu linków Search Console, łącznie z adresami obrazów i plików PDF. We Frankfurcie szczególnie ważne bywają linki z katalogów branżowych, stron partnerskich i materiałów po targach.

1. Każdy stary adres dostaje stałe przekierowanie po stronie serwera, 301 albo 308, prosto na stronę o tej samej treści, bez łańcuchów.
2. Nie kieruję setek starych wpisów na stronę główną. Google traktuje to jako mylące i może uznać takie przekierowania za soft 404.
3. Każdą zmianę sluga zapisuję w arkuszu jako osobną decyzję uzgodnioną z tobą.

Przed startem skrypt przechodzi po wszystkich starych adresach na środowisku testowym i sprawdza kod odpowiedzi oraz adres końcowy. Dostajesz wynik jako plik.

#Co z wersją niemiecką, angielską i innymi językami?

Strona firmy z Frankfurtu ma zwykle wersję niemiecką, a przy klientach międzynarodowych także angielską. W WordPressie języki trzyma najczęściej wtyczka typu WPML lub Polylang. Przy migracji wyciągam powiązania tłumaczeń do modelu treści.

Z nich powstają adnotacje hreflang. Google przyjmuje kod języka z ISO 639-1, opcjonalnie z regionem, i wymaga, żeby każda wersja wskazywała siebie i wszystkie pozostałe. Dodaję x-default dla przełącznika języka. Po starcie hreflang musi wskazywać nowe adresy, nie przekierowane stare. Sprawdzam to na zbudowanym HTML.

#Jak przenoszę treści, pola i dane strukturalne?

Wpisy, strony, kategorie i pola własne zamieniam na typowane kolekcje treści. W Astro to pliki Markdown albo MDX ze schematem, który odrzuca wpis bez tytułu, opisu czy daty. Jeśli redakcja chce zostać w znanym panelu, WordPress pracuje dalej jako headless CMS, a frontend pobiera treści przez REST API albo GraphQL.

Dane strukturalne Schema.org (Organization, LocalBusiness, Product, Article, BreadcrumbList) przenoszę razem z treścią i porównuję stary i nowy JSON-LD dla tych samych podstron. Tytuły, opisy meta, nagłówki H1 i teksty alternatywne obrazów przechodzą jeden do jednego, chyba że zmianę zapiszemy w arkuszu.

#Jakie niemieckie przepisy musi spełnić nowa strona?

§ 5 Digitale-Dienste-Gesetz (DDG) wymaga Impressum: dane usługodawcy łatwo rozpoznawalne, bezpośrednio osiągalne i stale dostępne. Link musi być w stopce każdego szablonu, także na 404 i landingach.

§ 25 TDDDG uzależnia zapis lub odczyt informacji w urządzeniu użytkownika od zgody, z wyjątkiem informacji bezwzględnie koniecznych. Na nowym frontendzie skrypty analityczne i marketingowe ładują się dopiero po zgodzie. Sprawdzam to na czystym profilu przeglądarki.

BFSG obejmuje m.in. handel elektroniczny i usługi bankowe świadczone konsumentom po 28 czerwca 2025 r. W mieście z dużym sektorem finansowym ten punkt dotyczy wielu serwisów. Czy twoja usługa podlega ustawie, ocenia prawnik. Ja pilnuję struktury nagłówków, etykiet formularzy, kontrastu i obsługi z klawiatury.

Nadzór nad ochroną danych w Hesji sprawuje Hessischer Beauftragter für Datenschutz und Informationsfreiheit (HBDI). Jeśli nowa architektura zmienia, gdzie przetwarzane są dane, aktualizuję listę podmiotów przetwarzających dla polityki prywatności, a treść polityki zostawiam prawnikowi klienta.

#Gdzie hostować nową stronę i co z danymi w UE?

HTML z Astro można serwować z CDN, a części dynamiczne z funkcji serwerowych. Next.js z renderowaniem na serwerze potrzebuje środowiska Node.js albo platformy, która je obsługuje. Przy firmach, które muszą trzymać dane osobowe w UE, region dla bazy i funkcji formularzy ustalam przed migracją.

We Frankfurcie działa DE-CIX, duży punkt wymiany ruchu internetowego. Bliskość węzła nie zastępuje jednak sprawdzenia regionu i umowy powierzenia u konkretnego dostawcy. Sam HTML bez danych osobowych może być dystrybuowany globalnie, ale formularze, logi i analityka wymagają osobnej mapy.

#Co najczęściej psuje się przy migracji i jak to wyłapuję?

• Łańcuchy przekierowań ze starych 301. Spłaszczam je do jednego skoku.
• Wielkość liter i ukośnik na końcu adresu. Test obejmuje obie formy z logów.
• Obrazy ze ścieżkami do starego katalogu uploadów.
• Formularze bez podłączonej wysyłki.
• Zgubione Impressum albo baner zgód.

W dniu startu uruchamiam skrypt przekierowań na produkcji, zgłaszam nową mapę witryny w Search Console i poprawiam linki wewnętrzne. Przez kolejne tygodnie czytam raport indeksowania, błędy 404 i zapytania tracące wyświetlenia.

#Trzy scenariusze projektowe z Frankfurtu

Poniższe scenariusze składam z cech miasta opisanych w Wikipedii i z problemów, które powtarzają się przy migracjach. Nie są opisami konkretnych klientów WPPoland.

#Firma usługowa wokół Messe

Firma logistyczna, agencja eventowa albo dostawca usług dla wystawców ma stronę oferty, landingi sezonowe i formularze zapytań. Stary WordPress składa każdą podstronę z bazy przy każdym wejściu, a landingi z poprzednich edycji targów nadal zbierają linki z katalogów wystawców. Zaczynam od mapy landingów targowych i trwałych stron usług. Astro buduje treści, a formularze testuję przed szczytem Messe. Przełączenie planuję poza największymi imprezami. Odbiór obejmuje działanie formularza na telefonie, poprawność hreflang de/en oraz porównanie LCP na typowej stronie oferty przed i po zmianie.

#Serwis finansowy lub B2B z portalem klienta

Firma z sektora finansowego albo usług dla przedsiębiorstw ma stronę marketingową i obszar zalogowany. Wikipedia podkreśla rolę Frankfurtu jako centrum finansowego z siedzibami instytucji europejskich i krajowych, więc takie serwisy często łączą Impressum, rozbudowaną politykę prywatności i obowiązki BFSG dla usług bankowych świadczonych konsumentom. Dzielę trasy: Astro na ofertę i publikacje, Next.js na portal wymagający sesji. Odbiór obejmuje Impressum w każdym szablonie, zgodę na cookies przed załadowaniem analityki, test logowania i dostępność formularzy na telefonie. Panel nie publikuję w Search Console jako stronę marketingową: dostaje noindex albo ochronę uwierzytelnieniem.

#Strona produktowa z PDF i katalogiem partnerów

Dystrybutor albo producent ma katalog, karty PDF i listę partnerów. Linki zewnętrzne wskazują na konkretne pliki, często z materiałów po targach. Mapa 301 rozdziela trwałe karty od wygasłych kampanii. Nie kieruję wygasłych landingów na stronę główną. Testy obejmują dostępność PDF, formularze RFQ, zgodność liczby pozycji po imporcie oraz to, czy canonical wskazuje produkcyjny adres, a nie staging.

#Polska firma, niemieccy klienci: trzy warstwy przepisów

Jeśli firma ma siedzibę w Polsce, a strona jest kierowana do klientów we Frankfurcie, spotykają się trzy zestawy zasad. Nie rozstrzygam pierwszeństwa. Przygotowuję materiał dla prawnika klienta.

• RODO i UODO. Dla administratora z siedzibą w Polsce organem nadzorczym jest Prezes UODO, a w Hesji sprawy odbiorców prowadzi HBDI. Spisuję procesorów i lokalizacje danych przed przełączeniem.
• Prawo komunikacji elektronicznej. Art. 399 PKE reguluje zgodę na zapis i odczyt informacji w urządzeniu końcowym. Nowy frontend startuje bez skryptów starych wtyczek.
• DDG i TDDDG. Impressum i zgoda na cookies, opisane wyżej.

Dostępność: od 28 czerwca 2025 r. obowiązuje polska ustawa z 26 kwietnia 2024 r. o dostępności niektórych produktów i usług. Niemiecki BFSG wdraża tę samą dyrektywę 2019/882. Nowy frontend to najtańszy moment na poprawę kontrastu, nagłówków i obsługi z klawiatury.

#Praca zdalna z Polski bez straty czasu na różnicę stref

Polska i Hesja leżą w tej samej strefie czasowej. Dokumentację piszę po polsku, a zespół we Frankfurcie dostaje streszczenie decyzji po niemiecku, jeśli tak pracuje. Teksty niemieckie zatwierdza osoba, dla której jest to język ojczysty. Dostęp do środowisk ograniczam do kont imiennych z MFA. Sekrety zostają u klienta.

#Kiedy nie migrować strony z Frankfurtu

Nie rekomenduję migracji, gdy wystarczy naprawa jednego szablonu przy aktualnych wtyczkach. Nie rekomenduję jej też na kilka tygodni przed największymi targami, jeśli firma zarabia głównie wtedy. Inwentarz i nowy frontend można przygotować wcześniej, a przełączenie przesunąć.

Migracja nie naprawi nieaktualnej oferty ani braku właściciela treści. Jeżeli po odbiorze nikt nie zajmie się zależnościami i monitoringiem, uzgadniam utrzymanie albo wskazuję właściciela przed startem.

#WordPress jako panel redakcji albo pełna zmiana modelu treści

Headless nie musi oznaczać wymiany panelu. WordPress może dalej przechowywać treści, użytkowników redakcyjnych, wersje robocze i pola własne. Astro lub Next.js pobiera dane przez REST API albo WPGraphQL i odpowiada za prezentację. To częsty wybór we Frankfurcie, gdy marketing i compliance piszą po niemiecku w znanym panelu, a zespół techniczny chce mieć front w repozytorium.

Najpierw opisuję model treści. Tytuł, lead, sekcje, relacje, pliki PDF i metadane SEO muszą mieć jawne pola zamiast zależności od starego buildera. Bloki wymagają kontraktu: dane obowiązkowe, warianty, zachowanie bez obrazu. Podczas prac dotychczasowa witryna nadal publikuje. Nowy frontend buduje się równolegle, a webhook uruchamia wersję testową po zmianie treści. Przed przełączeniem wykonuję synchronizację i ustalam krótkie okno ograniczonej publikacji tylko wtedy, gdy wymaga tego źródło danych.

Jeśli treści zmieniają się rzadko i zespół pracuje z Gitem, przenoszę je do plików Markdown w repozytorium. Tę decyzję zapisuję przed startem, bo od niej zależy zakres importów i utrzymanie.

#Okno pomiarowe i warunki powrotu

Przed przełączeniem mierzę stan wyjściowy: Core Web Vitals z danych rzeczywistych, czas odpowiedzi, liczbę błędów, skuteczność formularzy, ruch organiczny i poziom indeksacji. Wyniki przypisuję do typów stron, urządzeń i wersji językowych. Jedna średnia dla domeny ukryłaby wolny formularz mobilny albo problemy tylko w archiwum publikacji.

We Frankfurcie uwzględniam kalendarz Messe. Porównanie okresów Search Console robię względem analogicznych tygodni, nie względem poprzedniego miesiąca kalendarzowego. Firmy z płaskim kalendarzem B2B też sprawdzam pod kątem kampanii i wydarzeń branżowych.

Warunki powrotu zapisuję przed startem i przypisuję osobę decyzyjną. Mogą nimi być: niedostępny formularz, błąd logowania, przypadkowy noindex na stronach marketingowych, lawina 404 na adresach z ruchem albo awaria integracji krytycznej. Poprzedni system zostaje gotowy przez ustalone okno. 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. Po spełnieniu kryteriów odbioru archiwizuję kod, bazę, pliki i konfigurację z instrukcją odtworzenia, nie sam eksport treści.

#Co zostaje u ciebie po migracji?

Repozytorium, opis zmiennych środowiskowych, pipeline, arkusz przekierowań i instrukcja publikacji. Kod nie jest zamknięty w moim koncie. Szczegóły procesu opisuję na stronie o migracji do Next.js i Astro, a pracę z WordPressem jako źródłem treści na stronie programista headless CMS.

#Jak zacząć?

Wyślij mi adres obecnej strony, nazwę i wersję CMS-a, listę wersji językowych, listę integracji (formularze, CRM, płatności, analityka) oraz źródła ruchu, najlepiej eksport z Search Console z ostatnich 12 miesięcy. Na tej podstawie przygotuję pisemny zakres: co przenoszę, które adresy się zmieniają, jaki framework i dlaczego oraz w którym tygodniu warto przełączyć stronę.

#WordPress może zostać panelem redakcji

Headless nie wymaga wymiany panelu. WordPress może dalej trzymać treści, role i harmonogram publikacji. Astro lub Next.js pobiera dane przez REST API albo WPGraphQL. Redakcja zostaje przy znanym procesie. Najpierw opisuję model treści z jawnymi polami, potem buduję nową warstwę prezentacji równolegle do żywej witryny. Krótkie ograniczenie publikacji pojawia się wyłącznie przy końcowej synchronizacji, jeśli źródło danych tego wymaga, i jest zapisane w runbooku.

#Okno pomiarowe po przełączeniu

Po zmianie DNS porównuję Search Console z okresem przed migracją: indeksację, 404, robots i kliknięcia na stronach z wcześniejszym ruchem. Mapę przekierowań odpytuję skryptem na produkcji. Formularze i CRM testuję ponownie. Kryteria powrotu zapisuję wcześniej. Stary system zostaje gotowy do cofnięcia DNS, dopóki kryteria odbioru nie są spełnione. Archiwum obejmuje kod, bazę, pliki i instrukcję odtworzenia.

#Kiedy nie migrować

Nie rekomenduję migracji, gdy wystarczy porządek w wtyczkach, cache i obrazach. Nowa warstwa prezentacji nie naprawi nieaktualnej oferty ani braku właściciela treści. Nie zaczynam przełączenia tuż przed kluczową kampanią. Migracja jest złym wyborem, jeśli po odbiorze nikt nie utrzyma procesu budowania i monitoringu.