Migracja Next.js / Astro w Düsseldorfie

Firma z Düsseldorfu, która ma stronę na WordPressie, Joomli albo Drupalu, może przenieść ją na Astro albo Next.js bez utraty adresów URL i ruchu z Google, pod warunkiem że każdy stary adres dostanie zaplanowane przekierowanie, a niemieckie obowiązki prawne przejdą razem z treścią. Opisuję tu, jak prowadzę taką migrację krok po kroku, co sprawdzam przed przełączeniem i co w Düsseldorfie wymaga osobnej uwagi.

#Kiedy firmie z Düsseldorfu opłaca się migracja z WordPressa do Astro?

Migracja ma sens, gdy obecny system przeszkadza: panel jest wolniejszy niż strona, każda aktualizacja wtyczek to ryzyko, a redakcja odkłada publikację, bo boi się, że coś się rozsypie. Ma też sens, gdy serwis jest w większości treścią (oferta, blog, strony branżowe), a dynamiczne funkcje ograniczają się do formularza i kilku integracji.

Nie ma sensu, gdy strona działa szybko, ma kilkanaście podstron i nikt nie zgłasza problemów z edycją. Wtedy taniej jest uporządkować wtyczki, cache i hosting. Pisemny zakres zaczynam od tego pytania i jeśli odpowiedź brzmi “nie migrować”, mówię to wprost.

Astro wybieram dla serwisów treściowych: strony generowane z góry, mało JavaScriptu w przeglądarce, prosty hosting. Next.js wybieram, gdy potrzebne są logowanie, panel klienta, personalizacja albo renderowanie po stronie serwera. Więcej o samym podejściu piszę na stronie migracji do Next.js i Astro oraz na stronie o programowaniu w Astro.

#Jak wygląda migracja krok po kroku?

1. Spis adresów URL. Łączę trzy źródła: sitemapę obecnego CMS-a, eksport stron z Google Search Console z ostatnich miesięcy i crawl całego serwisu. Każdy adres, który ma wyświetlenia albo linki zewnętrzne, trafia do arkusza.
2. Mapa przekierowań 301. Dla każdego starego adresu zapisuję nowy adres albo decyzję, że strona znika (i dokąd wtedy prowadzi przekierowanie). Każda zmiana adresu to osobny wiersz z uzasadnieniem, żeby generator niczego nie zmienił po cichu.
3. Model treści. Wpisy, strony, kategorie, pola niestandardowe (ACF w WordPressie, pola w Drupalu) przekładam na kolekcje z typowanym schematem. Treść eksportuję skryptem, nie ręcznie, a potem porównuję liczbę elementów przed i po.
4. Meta i dane strukturalne. Title, description, canonical, Open Graph i JSON-LD (Organization, LocalBusiness, Article, FAQPage) przechodzą razem z treścią. Na wersji testowej porównuję je automatycznie z produkcją.
5. Hreflang. Wiele firm w Düsseldorfie prowadzi stronę po niemiecku i angielsku. Wtedy każda para językowa musi wskazywać na siebie nawzajem, a adresy w hreflang muszą być tymi po przekierowaniu, nie starymi.
6. Przełączenie. Mały serwis przełączam jednym ruchem w nocy. Większy przenoszę sekcjami: najpierw blog, potem oferta, a stary system obsługuje resztę, aż do ostatniego etapu.
7. Kontrola w Search Console. Po starcie zgłaszam nową sitemapę, sprawdzam raport indeksowania stron i adresy, które zwracają 404, oraz porównuję kliknięcia na poziomie podstron z okresem sprzed migracji.

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

Najczęstsze błędy przy migracji to łańcuchy przekierowań (stary adres prowadzi do innego starego adresu, który dopiero prowadzi do nowego), zgubione parametry w adresach kategorii, ukośnik na końcu adresu raz obecny, raz nie, oraz obrazki, które w treści dalej wskazują na stary katalog uploads.

Sprawdzam to skryptem przed przełączeniem: każdy adres z arkusza musi zwrócić 301 do adresu, który odpowiada kodem 200, w jednym kroku. Drugi skrypt szuka w gotowym HTML odwołań do starej domeny i starych ścieżek plików. Trzeci porównuje liczbę nagłówków, linków wewnętrznych i obrazków na każdej podstronie przed migracją i po niej, bo zgubiona sekcja treści nie daje błędu, tylko po cichu zmniejsza stronę.

Po starcie przez kilka tygodni porównuję w Search Console kliknięcia i wyświetlenia podstron z okresem sprzed zmiany. Spadek na jednej podstronie zwykle oznacza konkretną przyczynę: złe przekierowanie, zgubiony canonical albo brakujący fragment treści.

#Jakie niemieckie przepisy trzeba przenieść razem ze stroną?

Firma z siedzibą w Düsseldorfie działa na niemieckim rynku, więc nowa strona musi spełniać te same obowiązki co stara. Przy migracji pilnuję trzech rzeczy.

Impressum. Paragraf 5 niemieckiej ustawy o usługach cyfrowych (DDG) wymaga, żeby dostawca komercyjnej usługi cyfrowej podał między innymi nazwę i adres, dane do szybkiego kontaktu elektronicznego z adresem e-mail, rejestr handlowy z numerem i numer VAT, jeśli go ma. Informacje mają być łatwo rozpoznawalne i bezpośrednio dostępne. W praktyce oznacza to link do Impressum w stopce każdej podstrony nowego serwisu, sprawdzany automatycznie.

Zgoda na cookies. Paragraf 25 ustawy TDDDG pozwala zapisywać informacje w urządzeniu użytkownika albo je odczytywać tylko za jego zgodą, z wyjątkiem sytuacji, gdy jest to bezwzględnie konieczne do świadczenia usługi, o którą użytkownik prosił. Wtyczka zgód z WordPressa nie przechodzi do Astro ani Next.js, więc baner wdrażam od nowa i sprawdzam w przeglądarce, że analityka i piksele reklamowe nie startują przed kliknięciem zgody.

Dostępność. Niemiecka ustawa BFSG obejmuje między innymi usługi handlu elektronicznego świadczone konsumentom po 28 czerwca 2025 roku. Jeśli firma sprzedaje online klientom indywidualnym, migracja to dobry moment, żeby nowy frontend od początku miał poprawną strukturę nagłówków, opisy obrazków, obsługę klawiaturą i kontrast. Sklep wymaga osobnej oceny, czy przepis go obejmuje.

Organem nadzorczym w sprawach ochrony danych dla firm z Nadrenii Północnej-Westfalii jest Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen (LDI NRW), z siedzibą przy Kavalleriestraße w Düsseldorfie. Nie udzielam porad prawnych: treść polityki prywatności i Impressum przygotowuje prawnik albo firma, a ja odpowiadam za to, żeby technicznie trafiły na każdą stronę i żeby skrypty działały zgodnie z ustawieniem zgody.

#Co jest specyficzne dla rynku w Düsseldorfie?

Düsseldorf to stolica Nadrenii Północnej-Westfalii, położona nad Renem, z ponad 619 tysiącami mieszkańców według danych na koniec 2025 roku. Miejska strona wspierania gospodarki wyróżnia gospodarkę cyfrową oraz przemysł kultury i kreatywny, a także około 500 startupów.

Miasto ma też największą społeczność japońską w Niemczech: w samym Düsseldorfie mieszkało w 2023 roku 6265 obywateli Japonii. Dla firm obsługujących ten rynek strona często ma wersję niemiecką, angielską i japońską. Przy migracji wielojęzycznego serwisu sprawdzam wtedy, czy każda wersja ma własne adresy, poprawne hreflang i czy wyszukiwarka wewnętrzna oraz fonty radzą sobie z japońskim pismem.

Dane klientów (formularze, newsletter, CRM) zostają w tych samych usługach co dziś, chyba że firma chce je przenieść. Strona zbudowana w Astro jako gotowy HTML nie przechowuje danych osobowych, więc hosting w UE dotyczy głównie formularzy, analityki i ewentualnego panelu CMS. Wybór dostawcy i lokalizacji serwerów zapisuję w zakresie, żeby dział prawny mógł go ocenić przed startem.

#Skąd bierze się ruch na stronach düsseldorńskich firm?

Pierwsze źródło to targi i kalendarz Messe Düsseldorf. Firmowa strona wystawcy albo dostawcy usług dla branży ma ruch skokowy: przed wydarzeniem i w jego trakcie odwiedza ją wielokrotnie więcej osób niż w zwykły wtorek. HTML serwowany z CDN znosi taki skok bez dokupowania mocy, a stary WordPress na współdzielonym hostingu często nie. Datę przełączenia ustawiam poza oknem najważniejszych branżowych wydarzeń firmy, nie według kalendarza projektu.

Drugie źródło to ruch dwujęzyczny i trójjęzyczny. Firma z oddziałem w Düsseldorfie i klientami w Londynie, Amsterdamie albo Tokio zwykle ma niemiecką i angielską wersję, czasem japońską. Search Console pokazuje, które kraje i języki naprawdę dają kliknięcia. Przed migracją sprawdzam to na poziomie podstron, bo wersja dorobiona “na zapas” nie zasługuje na ten sam nakład co wersja, która sprzedaje.

Trzecie źródło to lokalny B2B: zapytania ofertowe, karty produktów, dokumentacja PDF i strony kariery. Adresy PDF i archiwalne karty produktów często mają linki z katalogów branżowych i maili sprzed lat. Trafiają do mapy 301 osobno, bo crawl samej strony ich nie widzi, a logi serwera już tak.

#Cztery wzorce projektów z Düsseldorfu

To scenariusze zbudowane z problemów, które powtarzają się w branżach powyżej. Nie opisują konkretnych klientów.

#Wystawca albo firma obsługująca Messe

Strona żyje w rytmie wydarzeń: landing edycji, program, rejestracja, archiwum. Po zakończeniu edycji zespół często nadpisuje stronę nową, a adresy z mediów i newsletterów przestają działać. W migracji rozdzielam trwałe adresy (firma, oferta, archiwum lat) od edycyjnych. Każda edycja dostaje własną ścieżkę z rokiem. Gotowy HTML zdejmuje ryzyko przeciążenia w dniu otwarcia rejestracji, a formularz zostaje w sprawdzonej usłudze.

#Firma z wersją japońską obok niemieckiej i angielskiej

Największe ryzyko to hreflang i fonty. Każda wersja dostaje własne adresy i wzajemne odwołania. Sprawdzam, czy japońskie pismo nie łamie układu na telefonie i czy wyszukiwarka wewnętrzna indeksuje znaki spoza alfabetu łacińskiego. Formularz kontaktowy testuję w każdym języku, łącznie z dostarczeniem wiadomości.

#Producent albo dystrybutor B2B z katalogiem PDF

Katalog produktów, karty techniczne i cenniki dla zalogowanych partnerów. Ustalam jedno źródło danych: arkusz, ERP albo pola w CMS, z których Astro buduje karty przy każdym wdrożeniu. Pliki PDF dostają przekierowania, jeśli mają ruch z Grafiki Google albo z linków zewnętrznych. Formularz dla dystrybutorów testuję wysyłką do CRM przed startem.

#Studio kreatywne albo firma z sektora kultury

Portfolio, opisy realizacji bez wymyślonych liczb, kalendarz wydarzeń. Motyw zbudowany w page builderze często nie da się przenieść jeden do jednego, więc układ przepisuję na komponenty z jawnym kontraktem pól. Jeśli redakcja publikuje rzadko, treści mogą przejść do Markdowna w repozytorium. Jeśli publikuje co tydzień, WordPress zostaje jako panel, a frontend tylko pobiera treść.

#Jakie progi wydajności przyjmuję przy odbiorze?

Punktem odniesienia są progi Core Web Vitals z web.dev: największy element treści (LCP) w 2,5 s lub szybciej, reakcja na interakcję (INP) w 200 ms lub szybciej i przesunięcia układu (CLS) nie większe niż 0,1, mierzone dla 75. percentyla odwiedzin. Sprawdzam je osobno dla telefonu i komputera oraz osobno dla typów stron: strony głównej, karty usługi, artykułu i formularza.

Same progi nie decydują o odbiorze. Porównuję wynik z pomiarem sprzed migracji na tych samych podstronach, bo nowa strona może przejść próg i mimo to być wolniejsza od starej na najważniejszym wejściu. Dane z rzeczywistych użytkowników zbierają się z opóźnieniem, więc w pierwszych dniach opieram się na testach laboratoryjnych i traktuję je jako przybliżenie.

#Jakie kryteria powrotu ustalam przed startem?

Zanim zmienię DNS, zapisuję w runbooku warunki, przy których wracam do starej wersji, i osobę, która o tym decyduje. Typowe kryteria to niedziałający formularz kontaktowy, błąd w ścieżce zapytania ofertowego, utrata danych z formularza, przypadkowy noindex na produkcji i niedostępność kluczowej integracji. Każde kryterium musi być mierzalne. Zdanie “nowa strona działa gorzej” nie wystarcza podczas incydentu.

Dwa dni przed przełączeniem obniżam TTL w DNS, żeby powrót zajął minuty. Stara wersja zostaje gotowa do uruchomienia przez uzgodnione okno pomiarowe. Jeśli nowy system zapisuje dane, plan opisuje, jak zabezpieczyć rekordy utworzone po przełączeniu. Po zakończeniu okna archiwizuję kod, bazę, pliki i instrukcję odtworzenia, nie sam eksport treści.

Przed startem zapisuję też stan wyjściowy: Core Web Vitals z danych rzeczywistych, czas odpowiedzi, skuteczność formularzy, ruch organiczny i liczbę zaindeksowanych stron, osobno dla telefonu i komputera oraz dla typów stron.

#Jak zachowuję sygnały SEO w serwisie wielojęzycznym?

Zaczynam od trzech list: adresów z crawla, adresów z mapy witryny i stron, które w ostatnich 16 miesiącach dostały wyświetlenia w Search Console. Do tego dodaję adresy z logów serwera, bo logi pokazują wejścia z PDF, newsletterów i zakładek. Firma z oddziałem w Düsseldorfie często ma w logach stare landingi targowe i stopki maili sprzed kilku lat.

Dla każdego adresu zapisuję jedną z trzech decyzji: bez zmian, 301 na konkretny odpowiednik albo 410. Przy serwisie z kilkoma językami robię osobny arkusz na każdy język, a hreflang generuję z modelu treści. Skrypt po budowie sprawdza, czy para wskazuje na siebie, czy żaden odnośnik nie trafia w przekierowanie i czy canonical odpowiada adresowi zwracającemu 200.

Dane strukturalne buduję z tych samych pól, z których powstaje widoczna treść. Tytuły i opisy porównuję między starą a nową wersją dla każdego adresu z listy i oznaczam różnice, żeby zmiana była decyzją, a nie skutkiem ubocznym.

#Czy redakcja musi zmieniać sposób pracy?

Nie musi. WordPress może zostać panelem redakcyjnym, a frontend w Astro albo Next.js pobiera z niego treść przez REST API lub WPGraphQL. Redaktorzy dalej piszą w znanym edytorze. Zmienia się to, co widzi odwiedzający, oraz to, że publiczny adres nie wystawia już wp-admin ani wtyczek na świat.

Przed budową opisuję model treści. Tytuł, lead, sekcje, pliki i metadane SEO dostają jawne pola. Bloki z buildera, którego nikt już nie rozwija, zastępuję komponentami z kontraktem: jakie dane są obowiązkowe i co się dzieje, gdy pole jest puste. Podczas prac stara strona dalej publikuje. Nowy frontend buduje się równolegle, a podgląd odpala się po zmianie treści.

#Kiedy nie rekomenduję migracji?

Gdy problemem jest kilka wolnych szablonów, a WordPress ma aktualne wtyczki, czysty motyw i właściciela technicznego. Profilowanie zapytań, usunięcie zbędnych skryptów, cache i kompresja obrazów często rozwiązują problem bez drugiego stosu.

Gdy nikt nie wie, które treści zachować i kto zatwierdza zmiany. Nowy frontend nie naprawi nieaktualnej oferty ani zdublowanych tekstów. Gdy termin wypada tuż przed Messe albo dużą kampanią: inwentarz i testy można przygotować wcześniej, ale publikacja potrzebuje okna pomiarowego. I gdy po odbiorze nikt nie utrzyma zależności i procesu budowania. Astro i Next.js mają własne cykle wersji, więc przed startem ustalam, kto odpowiada za aktualizacje.

#Co zostaje u Ciebie po migracji?

Repozytorium z kodem, konfiguracja hostingu, zmienne środowiskowe, pipeline wdrożeniowy, mapa przekierowań i krótka instrukcja, jak publikować treść i wdrażać zmiany. Konta hostingu, domeny i narzędzi analitycznych pozostają własnością firmy, a mój dostęp ograniczam do kont imiennych z uwierzytelnianiem wieloskładnikowym. Po starcie poprawiam błędy krytyczne związane z migracją i sprawdzam wydajność po pierwszym większym ruchu.

Zakres i wycena są indywidualne, bo dwie strony z tą samą liczbą podstron mogą mieć zupełnie inną historię adresów, inne integracje i inną liczbę wersji językowych. Stawek nie podaję przed audytem.

#Od czego zacząć?

Wyślij mi adres obecnej strony, nazwę CMS-a (z wersją, jeśli ją znasz), listę integracji (formularze, CRM, sklep, newsletter) i informację, skąd przychodzi ruch: z Google, kampanii, czy z poleceń. Jeśli masz dostęp do Search Console, przydatny będzie eksport stron z ostatnich miesięcy. Na tej podstawie przygotuję pisemny zakres: co przenoszę, czego nie, jak wygląda mapa przekierowań i w jakiej kolejności przełączam serwis.