Migracja Next.js / Astro w Berlinie

Berlin jest jednocześnie stolicą Niemiec, krajem związkowym i gminą, a według Wikipedii spis z 2022 roku policzył tu 3 596 999 mieszkańców. Firmy z Berlina, które chcą odejść od WordPressa, Joomli, Drupala albo starego frameworka, zwykle mają serwis w kilku językach, długą historię adresów URL i wtyczki, których nikt już nie pamięta. Przenoszę takie serwisy na Astro lub Next.js tak, żeby po przełączeniu każdy stary adres miał odpowiednik, a ruch z wyszukiwarki nie zniknął. Prowadzę migrację sam, od spisu adresów po kontrolę w Search Console po starcie.

#Kiedy migracja z WordPressa na Astro lub Next.js ma sens?

Migracja ma sens, gdy obecny CMS ogranicza wydajność, bezpieczeństwo albo pracę redakcji, a porządek we wtyczkach i cache już tego nie naprawia. Jeśli wystarczy usunąć trzy ciężkie wtyczki i włączyć cache strony, mówię to i zostajesz przy WordPressie.

Objawy, które przemawiają za zmianą:

• panel administracyjny działa wolniej niż strona publiczna,
• aktualizacje rdzenia i wtyczek idą bez środowiska testowego, więc każda jest ryzykiem,
• każda wtyczka dokłada własny JavaScript i CSS, a wyniki LCP i INP w Core Web Vitals (opis metryk: web.dev/articles/vitals) nie poprawiają się bez zmiany architektury,
• redakcja publikuje w kilku językach i ręcznie pilnuje, żeby wersje się zgadzały.

Astro wybieram, gdy serwis to głównie treść: strony usług, blog, dokumentacja, oferty pracy. Generuje HTML przy budowaniu i dokłada JavaScript tylko tam, gdzie jest potrzebny. Next.js wybieram, gdy serwis ma logowanie, panel klienta, wyszukiwarkę po stronie serwera albo dużo danych zmieniających się w ciągu dnia. Redakcja może dalej pisać w WordPressie jako CMS bez frontu albo przejść na pliki Markdown i headless CMS. Ta decyzja zapada przed pierwszą linią kodu, bo zmienia model treści.

Migracji nie polecam, gdy cała wartość strony siedzi w jednej wtyczce (rezerwacje, konfigurator, kurs online), której odpowiednika w nowym stosie nie ma. Napisanie jej od zera bywa droższe niż cała reszta projektu.

#Jak nie stracić pozycji w Google przy zmianie adresów?

Podstawą jest mapa przekierowań. Listę adresów składam z crawla, mapy witryny, eksportu z Search Console i logów serwera. Sama sitemapa pomija strony, które mają linki z zewnątrz, ale wypadły z menu. Każdy URL z ruchem, linkami zewnętrznymi albo w indeksie dostaje w arkuszu jedną decyzję: zostaje bez zmian, dostaje 301 na konkretny nowy adres albo zwraca 410, bo treść jest martwa.

Google w dokumentacji o przenoszeniu witryny zaleca przekierowania trwałe (301 albo 308) prosto do adresu docelowego, bez łańcuchów, i utrzymanie ich tak długo, jak to możliwe, zwykle co najmniej rok. Zalecenie traktuję jako minimum: mapa 301 zostaje w konfiguracji na stałe, bo stare linki z artykułów i katalogów firm nie znikają po dwunastu miesiącach.

Przed przełączeniem uruchamiam na środowisku testowym skrypt, który przechodzi całą listę i sprawdza trzy rzeczy: czy przekierowanie kończy się w jednym skoku, czy cel zwraca 200 i czy cel dotyczy tego samego tematu co źródło. Przekierowanie wszystkiego na stronę główną to błąd, który najczęściej widzę po cudzych migracjach. Google traktuje takie przekierowania jak miękkie 404.

#Co z wersjami de, en i pl oraz hreflang?

Firma z Berlina, która sprzedaje w Niemczech i za granicą, często prowadzi serwis po niemiecku i po angielsku, a firmy z polskim zapleczem dokładają wersję polską. Przy migracji każda wersja dostaje własne adresy, wzajemne wskazania hreflang i osobne tytuły. Tłumaczenie maszynowe jednej wersji nie zastępuje drugiej, bo klient w Niemczech szuka innymi frazami niż klient w Polsce.

Najwięcej problemów robią wersje dorobione wtyczką typu WPML albo Polylang: część adresów z prefiksem języka, część z parametrem. Google ignoruje atrybuty hreflang, gdy dwie strony nie wskazują na siebie nawzajem. Dlatego w nowej wersji nie wpisuję hreflang ręcznie, tylko generuję je z modelu treści. Po budowie skrypt sprawdza, czy każda para jest wzajemna, czy żaden odnośnik nie trafia w przekierowanie i czy jest ustawiony x-default.

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

Zaczynam od spisu modelu treści: typy wpisów, pola ACF, taksonomie i relacje, które naprawdę są używane, oraz te, które zostały w bazie po dawno usuniętych wtyczkach. W Astro każdy typ dostaje schemat kolekcji. Wpis bez wymaganego pola zatrzymuje budowanie, więc błąd w treści wychodzi na etapie builda, a nie na produkcji.

Dane strukturalne (Organization, LocalBusiness, Article, BreadcrumbList, FAQPage) generuję z tych samych pól, z których powstaje widoczna treść, żeby nie rozjechały się ze stroną. Dla każdego URL z listy porównuję stary i nowy tytuł, opis meta oraz adres kanoniczny. Obrazy przenoszę z zachowaniem nazw plików albo z przekierowaniem, bo też zbierają ruch z wyszukiwarki grafiki. PDF-y w wp-content/uploads mają często linki z zewnątrz i dostają przekierowanie albo zostają pod tym samym adresem.

#Co jest specyficzne dla firm z Berlina?

Senat Berlina wymienia wśród branż miasta między innymi turystykę, handel, rzemiosło, gospodarkę ICT, przemysł, media i gospodarkę kreatywną oraz gospodarkę zdrowotną i przemysł farmaceutyczny. Każda z nich zmienia zakres migracji inaczej. Hotel czy biuro podróży ma silnik rezerwacji osadzony w stronie, który trzeba przenieść bez zmiany adresu potwierdzeń. Sklep ma koszyk i płatności, więc do Next.js albo do osobnej warstwy sklepu. Firma z branży zdrowotnej ma formularze z danymi, które wymagają szczególnej ostrożności przy wyborze dostawcy formularzy i hostingu. Agencja medialna ma archiwum materiałów, w którym liczą się stare adresy.

Firmy i stowarzyszenia z siedzibą w Berlinie mają swój urząd ochrony danych: Berliner Beauftragte für Datenschutz und Informationsfreiheit. Przy migracji z WordPressa najczęstszy problem to skrypty, które ładowały wtyczki: czcionki z zewnętrznego serwera, osadzone mapy i filmy, piksele reklamowe. Nowy serwis nie ładuje niczego, czego świadomie nie dodam, więc spisuję każdy skrypt i cookie ze starej wersji, a decyzję o tym, co wraca i na jakiej podstawie, podejmujesz Ty. Formularze, analityka i hosting to podmioty przetwarzające, z którymi potrzebna jest umowa powierzenia przetwarzania według art. 28 RODO.

Serwis z Astro to w większości pliki HTML, więc danych osobowych po stronie serwera jest niewiele. Zakres danych wyznaczają głównie formularze, analityka i zewnętrzne skrypty. Hosting i dostawców usług wybieram z przetwarzaniem danych w UE tam, gdzie to możliwe, i wpisuję tę decyzję do dokumentacji projektu.

#Trzy typowe układy serwisów z Berlina

Poniższe układy są scenariuszami zbudowanymi z problemów typowych dla firm w tym mieście. Nie opisują konkretnych klientów.

#Studio kreatywne albo produkcja medialna

Serwis pokazuje projekty, reel, listę klientów i często blog. Motyw jest ciężki od wtyczek do galerii i osadzonych filmów. Migracja zaczyna się od inwentarza mediów: które pliki mają linki z zewnątrz, które wystarczy przenieść bez zachowania adresu. Astro generuje strony treściowe przy budowaniu, a odtwarzacz wideo ładuje się dopiero po interakcji. Kryterium odbioru obejmuje LCP na stronach z dużym obrazem oraz to, że PDF-y z portfolio nadal otwierają się pod starymi adresami albo po jednym 301.

#Firma B2B z wersją niemiecką i angielską

Oferta, opisy realizacji trzymane wewnętrznie (bez publicznej listy), kariera i blog produktowy. Wersje językowe powstały wtyczką i mają niespójne ścieżki. Przed migracją ujednolicam wzorzec adresów i dla każdej pary tworzę mapę 301. Hreflang generuję z modelu treści. Trasy logowania albo panelu partnera, jeśli istnieją, idą do Next.js, a reszta zostaje w Astro pod tą samą domeną.

#Sklep albo serwis z rezerwacjami

Koszyk, płatności albo silnik rezerwacji nie mieszczą się w samym HTML. Zakres migracji obejmuje albo przeniesienie sklepu do osobnej warstwy z własnymi przekierowaniami, albo Next.js dla ścieżek transakcyjnych i Astro dla katalogu i treści. Adresy potwierdzeń zamówień i maili transakcyjnych nie mogą się zmienić bez zapisanej decyzji w arkuszu.

#Astro i Next.js na konkretnych trasach

Duży serwis rzadko jest jednorodny. Dzielę go na rodziny tras i dla każdej zapisuję wymagania: czy treść jest wspólna dla wszystkich, jak często się zmienia, czy wymaga logowania i jakie dane musi pobrać w momencie żądania.

Astro obsługuje strony treściowe: ofertę, komunikaty, dokumentację, profile zespołu i archiwa. Generuje HTML przy budowaniu, więc pod ruchem po komunikacie prasowym serwuje pliki z CDN, a nie wykonuje zapytań do bazy. Next.js bierze trasy z sesją: strefę klienta, panel partnera, wyszukiwarkę z uprawnieniami lub formularze wieloetapowe. Granicę rysuję po stronie danych: jeśli trasa nie potrzebuje użytkownika ani świeżych danych przy każdym żądaniu, zostaje statyczna.

Obie części mogą działać pod jedną domeną, z jedną warstwą routingu, wspólnymi nagłówkami bezpieczeństwa i wspólnym monitoringiem. Uzasadnienie podziału zapisuję w repozytorium, żeby zespół, który przejmie projekt, nie musiał go odtwarzać z historii commitów.

#Co może pójść źle i jak to sprawdzam?

• Ukośnik na końcu adresu. WordPress często obsługiwał oba warianty. Testuję listę adresów obu wersjach: odpowiedź ma być jedna, 200 albo pojedyncze 301 do adresu kanonicznego.
• Łańcuchy przekierowań. Stare reguły z .htaccess plus nowe reguły dają dwa lub trzy skoki. Crawl zgłasza każde przekierowanie dłuższe niż jeden skok.
• Parametry kampanii. Przekierowanie, które gubi UTM albo gclid, kasuje atrybucję reklam. Wchodzę na stare adresy z parametrami i sprawdzam, czy docierają do analityki.
• Treść widoczna dopiero po JavaScripcie. W Next.js sprawdzam, czy tekst i JSON-LD są w HTML zwróconym przez serwer.
• Zgubione pola SEO. Tytuł, opis, canonical i meta robots porównuję maszynowo dla wszystkich adresów.
• Noindex na produkcji. Reguła ze środowiska testowego przechodzi na nową stronę. Sprawdzam nagłówki i znaczniki robots zaraz po przełączeniu.

#Okno pomiarowe i przećwiczony powrót

Przed przełączeniem zbieram stan wyjściowy: Core Web Vitals z danych terenowych, czas odpowiedzi serwera, liczbę zaindeksowanych adresów, ruch z wyszukiwarki dla grup stron i skuteczność formularzy. Wyniki rozbijam według typu strony i urządzenia, bo średnia dla całej domeny ukrywa lokalne problemy.

Kryteria powrotu ustalam z osobą, która podejmuje decyzję po stronie firmy: niedostępny formularz kontaktowy, błąd w sekcji kariery, nieoczekiwany noindex, awaria integracji z rezerwacjami. Procedurę cofnięcia ćwiczę na środowisku przedprodukcyjnym i zapisuję w runbooku z godziną, kolejnością kroków i osobami do powiadomienia. Stary system zostaje gotowy przez uzgodnione okno, a jego archiwizację robię dopiero po spełnieniu kryteriów odbioru. Archiwum obejmuje kod, bazę, pliki i konfigurację, nie sam eksport treści.

#Kiedy nie migrować

Nie rekomenduję migracji, gdy problemem jest ciężki motyw albo brak cache, a system ma aktualne wtyczki i właściciela technicznego. Nie rekomenduję jej też wtedy, gdy główną wartością strony jest rozbudowana integracja z wewnętrznym systemem, której nie da się odtworzyć bez kosztu przekraczającego korzyść. Nowy frontend nie naprawi nieaktualnych treści ani braku właściciela serwisu.

Odradzam przełączenie w tygodniu ważnej kampanii albo znanego szczytu ruchu. Przygotowania mogą trwać wcześniej, ale sama publikacja potrzebuje okna na pomiar i reakcję. Jeśli firma nie ma osoby, która po odbiorze utrzyma proces budowania i zależności, ustalam utrzymanie przed rozpoczęciem prac.

#Jak prowadzę migrację z zespołem z Berlina

Pierwszy etap to audyt: inwentarz adresów, mapa integracji, pomiar bazowy i pisemna rekomendacja, czy wystarczy naprawa, relaunch w obecnym systemie czy migracja. Zakres i wycena są indywidualne.

Drugi etap to architektura tras, model treści i role redakcyjne. Trzeci to równoległa budowa z powtarzalnym importem, testami przekierowań, metadanych i głównych ścieżek użytkownika. Przed publikacją przechodzę próbę przełączenia. Po starcie przez uzgodniony okres raportuję różnice względem stanu bazowego. Na końcu przekazuję repozytorium, dokumentację, mapę 301, opis środowisk bez sekretów i procedurę odtwarzania kopii. Konta pozostają Twoją własnością.

#Co dostajesz po migracji?

Repozytorium z kodem, zmienne środowiskowe, opis wdrożenia i arkusz przekierowań zostają u Ciebie. Każdy programista, który zna Astro albo Next.js, może przejąć projekt bez mojego udziału. Po starcie poprawiam błędy wykryte w przekierowaniach i indeksowaniu. Szerzej opisuję te zasady na stronie migracja do Astro i Next.js, a samą pracę z frameworkiem na stronie programista Astro.

#Od czego zacząć?

Wyślij adres obecnego serwisu, nazwę CMS-a i najważniejszych wtyczek, źródła ruchu (Search Console i analityka, jeśli masz dostęp) oraz listę wersji językowych. Na tej podstawie przygotuję pisemny zakres: co przenoszę, co zostawiam, ile adresów wymaga przekierowania i czy migracja w ogóle jest lepsza od porządków obecnym systemie. Wyślij to przez stronę kontaktową.

#Dostęp do systemów i bezpieczeństwo wdrożenia

Przed startem spisuję, kto ma dostęp do repozytorium, paneli hostingu, zmiennych środowiskowych, CMS-a i DNS. Konta są imienne, uwierzytelnianie wieloskładnikowe jest włączone, a sekrety trafiają do menedżera uzgodnionego z Tobą, nie do repozytorium ani do maila. Mój dostęp jako zewnętrznego wykonawcy ma najmniejszy zakres potrzebny do zadania i kończy się razem z projektem.

Publiczna strona zbudowana z HTML przy budowaniu nie wystawia bazy ani logowania do internetu. Zależności Node i panel CMS, jeśli zostaje, wymagają osobnej procedury aktualizacji w dokumentacji przekazania. Dla firm z Berlina z formularzami z danymi zdrowotnymi albo rekrutacyjnymi osobno zapisuję, gdzie fizycznie lądują te dane, zanim wybiorę hosting i dostawcę formularzy.

#Czy po migracji strona firmy z Berlina zachowa pozycje w Google?

Zachowa je, jeśli każdy stary adres dostanie odpowiednik z jednym przekierowaniem 301, a tytuły, nagłówki, canonical i dane strukturalne przejdą razem z treścią. Sprawdzam to na kopii testowej dla pełnej listy adresów, a po starcie w Search Console.

#Czy serwis po niemiecku, angielsku i polsku potrzebuje hreflang?

Tak, jeśli te same treści istnieją w kilku językach pod różnymi adresami. Wskazania muszą być wzajemne, a adresy docelowe muszą zwracać 200.

#Kto w Berlinie zajmuje się ochroną danych firm?

Berliner Beauftragte für Datenschutz und Informationsfreiheit, urząd, który doradza firmom i stowarzyszeniom z siedzibą w Berlinie. Przy migracji pilnuję, żeby nowy serwis nie ładował skryptów, o których nikt nie zdecydował.

#Co mam wysłać, żeby dostać zakres migracji?

Adres obecnego serwisu, nazwę CMS-a i najważniejszych wtyczek, źródła ruchu oraz listę wersji językowych. Na tej podstawie przygotowuję pisemny zakres.

#WordPress może zostać panelem redakcji

Headless nie wymaga wymiany panelu. WordPress może dalej trzymać treści, role, wersje robocze i harmonogram publikacji. Astro lub Next.js pobiera dane przez REST API albo WPGraphQL i buduje to, co widzi odwiedzający. Redakcja w Berlinie albo w Polsce zostaje przy znanym procesie, a ja zmieniam tylko warstwę prezentacji.

Najpierw opisuję model treści: tytuł, lead, pola SEO, pliki i relacje muszą mieć jawne pola, nie zależności od starego buildera. Podczas prac dotychczasowa witryna nadal publikuje. Nowy serwis buduje się równolegle. 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.

#Co sprawdzam po przełączeniu domeny w Berlinie

Po zmianie DNS zaczyna się okno pomiarowe, nie odbiór. Porównuję Search Console z okresem przed migracją: indeksację, 404, dyrektywy robots i kliknięcia na stronach, które wcześniej przynosiły ruch. Mapę przekierowań odpytuję skryptem na produkcji. Formularze, newsletter i CRM testuję ponownie, bo zmiana warstwy prezentacji często urywa właśnie te ścieżki.

Dla firm z polskim zespołem i niemieckim rynkiem sprawdzam hreflang oraz to, czy stopka i dane firmy są spójne w obu językach. Kryteria powrotu zapisuję wcześniej: niedostępność kontaktu, utrata danych z formularza albo masowe błędy indeksacji. Stary system zostaje gotowy do cofnięcia DNS, dopóki kryteria odbioru nie są spełnione.