Migracja Next.js / Astro w Bernie

Migracja do Astro lub Next.js dla firm w Bernie, z WordPressa, Joomli, Drupala i innych systemów.

Migracja Next.js / Astro

Migracja stron i aplikacji w Bernie

Migruję strony z WordPressa, Joomli, Drupala, Angulara, Vue i innych technologii do Astro i Next.js. Każdą migrację planuję tak, żeby zachować SEO, treści i funkcje, a przełączenie robię w uzgodnionym oknie. Pracuję sam i od lat znam zarówno starsze, jak i nowoczesne stacki.

  • Konto na wordpress.org mam od 2006 roku.
  • Współtworzyłem rdzeń WordPressa w wersjach 7.0 i 7.1.
  • Utrzymuję 30 wtyczek na wordpress.org.
  • Organizuję WordCampy i występuję na nich jako prelegent.
  • Byłem na każdym WordCamp Europe od 2017 do 2026 roku.

Mój profil na WordPress.org

Migracja do Next.js i Astro w Bernie

01. Z WordPressa do headless

Przenoszę strony z monolitycznego WordPressa, Joomla, Drupal i innych CMS-ów do nowoczesnej architektury Headless opartej o Astro lub Next.js. W Bernie realizuję migracje bez przestojów, twoja strona działa przez cały proces.

02. Z innych frameworków do Astro / Next.js

Migruję aplikacje z Angular, Vue, starszych wersji React, jQuery, PHP i statycznych generatorów (Hugo, Jekyll, Gatsby) do Astro lub Next.js. Zyskujesz lepszą wydajność, SEO i łatwiejszy rozwój.

03. Wyniki po migracji

Migracja do Astro lub Next.js w Bernie daje PageSpeed 95-100 i wyraźnie niższy TTFB, bo strona jest serwowana z edge zamiast składana przy każdym żądaniu. Statyczny front-end eliminuje typowe wektory ataków i drastycznie obniża koszty hostingu.

04. Zachowanie SEO i treści

Każda migracja obejmuje pełne mapowanie URL-i, przekierowania 301, przeniesienie meta tagów i danych strukturalnych. Twoje pozycje w Google nie tylko się utrzymują, zazwyczaj rosną dzięki lepszym Core Web Vitals.

Firmy w Bernie przenoszą treści i logikę z WordPressa, Joomli, Drupala albo starych frameworków na lżejszy frontend w Astro lub Next.js, kiedy Core Web Vitals, koszt utrzymania albo liczba wtyczek do łatania przestają się bronić. Prowadzę takie migracje sam, od inwentaryzacji adresów po kontrolę Search Console po starcie. Poniżej opisuję, co dokładnie robię, co zwykle się psuje i co w Bernie trzeba uwzględnić inaczej niż w Polsce.

#Kiedy migracja do Astro albo Next.js ma sens, a kiedy nie?

Ma sens, gdy obecny CMS ogranicza wydajność, bezpieczeństwo albo pracę redakcji. Typowe objawy: wolna odpowiedź serwera mimo cache, panel wolniejszy niż sama strona, aktualizacje odkładane, bo nikt nie wie, która wtyczka się wysypie, i szablon, którego nikt już nie umie bezpiecznie zmienić.

Nie ma sensu, gdy problem rozwiąże porządek we wtyczkach, lepszy hosting i cache. Wtedy mówię to od razu, bo migracja kosztuje więcej niż sprzątanie. Nie ma też sensu, gdy redakcja potrzebuje wyłącznie edytora WordPressa i nie chce go zmieniać: wtedy rozważam headless, w którym WordPress zostaje panelem, a Astro albo Next.js tylko wyświetla treść przez REST API.

#Astro czy Next.js dla strony firmy z Berna?

Astro wybieram do stron, które są w większości treścią: strona firmowa, oferta usług, blog, dokumentacja. Domyślnie generuje statyczny HTML i nie wysyła JavaScriptu tam, gdzie go nie potrzeba. Next.js wybieram, gdy strona ma strefę klienta, logowanie, wyszukiwarkę z filtrami po danych zmieniających się na bieżąco albo renderowanie po stronie serwera pod dane z zewnętrznego systemu.

Treść może zostać w CMS-ie headless (na przykład w tym samym WordPressie) albo przejść do plików Markdown w repozytorium. Decyduje o tym to, kto edytuje, jak często i w ilu językach. Więcej o samym podejściu piszę na stronie migracja do Astro i Next.js, a o rozdzieleniu panelu i frontendu na stronie programista headless CMS.

#Jak wygląda migracja krok po kroku, żeby nie stracić pozycji?

  1. Inwentaryzacja. Crawluję obecną stronę i porównuję wynik z mapą witryny oraz z adresami, które w Search Console dostają kliknięcia i wyświetlenia. Adres, którego nie ma w żadnym z tych źródeł, i tak trafia na listę, jeśli prowadzą do niego linki z zewnątrz.
  2. Mapa URL. Każdy stary adres dostaje jedną decyzję: ten sam adres, nowy adres z przekierowaniem 301 albo świadome usunięcie zapisane w arkuszu. Bez łańcuchów przekierowań, bo każdy dodatkowy skok to ryzyko błędu.
  3. Model treści. Typy stron, pola, taksonomie i powiązania między wersjami językowymi przechodzą do kolekcji z określonym schematem. Shortcody i pola z wtyczek sprawdzam strona po stronie, bo tam najczęściej znika tekst.
  4. Dane strukturalne i meta. Organization, BreadcrumbList, Article albo Product, zależnie od strony, generuję z treści, a nie wklejam ręcznie. Tytuły, opisy, canonical i hreflang porównuję ze starą wersją adres po adresie.
  5. Środowisko testowe. Nowa strona działa pod adresem zablokowanym dla wyszukiwarek. Crawluję ją tym samym narzędziem co starą i porównuję oba wyniki.
  6. Przełączenie etapami. Przy dużym serwisie nowy frontend przejmuje sekcję po sekcji pod tą samą domeną. Przy małym robię jedno przełączenie w zaplanowanym oknie.
  7. Po starcie. Zgłaszam nową mapę witryny, sprawdzam najważniejsze adresy narzędziem do sprawdzania URL w Search Console i śledzę raporty indeksowania oraz stron z przekierowaniem przez kolejne tygodnie.

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

  • Noindex przeniesiony ze środowiska testowego. W dniu przełączenia sprawdzam nagłówki i wyrenderowany HTML próbki stron z każdego szablonu.
  • Przekierowania działające tylko z ukośnikiem na końcu albo tylko bez niego. Testuję oba warianty każdego wzorca, także z parametrami w adresie.
  • Formularze, które przestały wysyłać. Ich obsługa często żyła w PHP starego CMS-a. Każdy formularz ma na liście odbioru wysyłkę testową, która musi dojść do adresata.
  • Obrazki i pliki PDF pod starymi ścieżkami. Linki z zewnątrz prowadzą często do plików, nie do stron, więc pliki też trafiają do mapy przekierowań.
  • Gorsze Core Web Vitals mimo nowego frontendu. Skrypty marketingowe przeniesione bez zmian potrafią zjeść cały zysk. Mierzę LCP, INP i CLS przed migracją i po niej na tych samych szablonach.

#Dlaczego język ma takie znaczenie przy stronie z Berna?

Berno jest siedzibą władz federalnych Szwajcarii (Bundesstadt) i stolicą kantonu Berno, leży w regionie administracyjnym Bern-Mittelland. Konstytucja kantonu w art. 6 uznaje niemiecki i francuski za języki kantonu: francuski jest językiem urzędowym w regionie Berner Jura, oba w regionie Seeland i w okręgu Biel/Bienne, niemiecki w pozostałych regionach, w tym tam, gdzie leży samo miasto. Firma z Berna, która obsługuje cały kanton albo zachodnią Szwajcarię, często publikuje więc po niemiecku i po francusku.

Przy migracji przekłada się to na konkretną pracę: osobną mapę URL dla każdego języka, wzajemny hreflang między wszystkimi wersjami, świadomie wybrany x-default i stałe foldery językowe. Jeśli stary CMS używał wtyczki tłumaczeń z parametrem w adresie (?lang=fr), te adresy też trafiają do mapy przekierowań.

#Jakie przepisy o danych dotyczą strony dla klientów Szwajcarii?

Szwajcaria nie jest w Unii Europejskiej i ma własną ustawę o ochronie danych (Federal Act on Data Protection, FADP, po niemiecku DSG). Obecna wersja obowiązuje od 1 września 2023. Nadzoruje ją Federalny Komisarz ds. Ochrony Danych i Informacji (FDPIC, po niemiecku EDÖB).

  • Zakres. Art. 3 stosuje ustawę do sytuacji wywołujących skutki w Szwajcarii, nawet jeśli zaczęły się za granicą. Strona dla klientów z Berna podlega jej niezależnie od tego, gdzie stoi serwer.
  • Obowiązek informacyjny. Art. 19 wymaga poinformowania osoby przy zbieraniu jej danych, a jeśli dane trafiają za granicę, także o państwie docelowym. Przy zmianie hostingu albo CDN poprawiam politykę prywatności w tym samym projekcie.
  • Przekazywanie za granicę. Art. 16 pozwala przekazać dane do państwa, którego przepisy Rada Federalna uznała za zapewniające odpowiedni poziom ochrony; bez takiej decyzji potrzebne są gwarancje, na przykład klauzule umowne. Dlatego oddaję listę, gdzie każda usługa nowej strony przechowuje dane.
  • Naruszenia. Art. 24 nakazuje zgłosić FDPIC naruszenie bezpieczeństwa danych, które prawdopodobnie niesie wysokie ryzyko dla osób, których dotyczy.

Ocenę prawną robi szwajcarski prawnik. Ja dostarczam dokładną listę usług, ciasteczek i przepływów danych, na której może pracować.

#Co zostaje u ciebie po migracji?

Repozytorium z kodem, konfiguracja hostingu i zmiennych środowiskowych, mapa przekierowań w formie arkusza oraz krótki dokument: jak opublikować zmianę, jak dodać wersję językową i jak cofnąć wdrożenie. Po starcie poprawiam błędy krytyczne i przeglądam wydajność po pierwszym większym ruchu.

#Berno z polskiej perspektywy: miasto federalne, nie centrum handlu internetowego

Wikipedia opisuje Berno jako de facto stolicę Szwajcarii, nazywaną miastem federalnym, z populacją około 146 tysięcy w 2024 roku. Jest piątym co do wielkości miastem kraju, a aglomeracja obejmuje 36 gmin. Stare miasto wpisano na listę światowego dziedzictwa UNESCO w 1983 roku. W Bernie mieszczą się Pałac Federalny z parlamentem i rządem oraz Powszechny Związek Pocztowy, a Uniwersytet Berneński działa głównie w dzielnicy Länggasse. Według danych z grudnia 2020 roku około 34 procent mieszkańców to cudzoziemcy.

Te fakty zmieniają skład odbiorców strony. W stolicy federalnej działają instytucje, stowarzyszenia, uczelnie, kancelarie i firmy doradcze, które piszą do kilku grup naraz: do administracji, do partnerów z innych kantonów i do osób spoza Szwajcarii. Strona często ma więc trzy wersje językowe, a nie dwie: niemiecką, francuską i angielską. Według danych z 2000 roku, które cytuje Wikipedia, 81,2 procent mieszkańców miasta podawało niemiecki jako pierwszy język, 3,9 procent włoski, a 3,6 procent francuski. Reszta serwisu musi więc uwzględniać też wersję angielską i ewentualnie włoską, o ile klient obsługuje cały kraj.

Ruch lokalny ma własny kalendarz. W Bernie odbywają się między innymi festiwal Gurtenfestival, karnawał Fasnacht i jarmark cebulowy Zibelemärit, który wypada w czwarty poniedziałek listopada. Dla strony hotelu, restauracji albo organizatora wydarzeń każda z tych dat to szczyt zapytań i rezerwacji, więc przełączenia nie planuję w ich pobliżu.

#Trzy scenariusze projektowe z Berna

To scenariusze zbudowane z cech miasta opisanych w Wikipedii i z typowych problemów migracji. Nie opisują konkretnych klientów WPPoland.

#Stowarzyszenie lub firma doradcza blisko administracji federalnej

Organizacja branżowa prowadzi stronę z aktualnościami, stanowiskami, dokumentami do pobrania i archiwum z wielu lat. Dokumenty PDF są cytowane w opracowaniach i linkowane z serwisów instytucji, więc ich adresy muszą przetrwać migrację. Każdy plik trafia do mapy przekierowań razem z adresem strony, na której go opublikowano. Astro dobrze obsługuje taki serwis treściowy: archiwum, komunikaty i profile zespołu budują się jako statyczny HTML. Wersje niemiecka i francuska mają osobne mapy adresów, a każda para odsyła do siebie wzajemnie przez hreflang.

#Uczelnia, instytut i spin-off badawczy

Wikipedia wskazuje, że Uniwersytet Berneński i uczelnia zawodowa (Fachhochschule) mają siedzibę w mieście. Zespół z takiego otoczenia prowadzi stronę projektu, listę publikacji i dokumentację narzędzia w jednym WordPressie. Zaczynam od wspólnego modelu treści: publikacja, projekt, osoba, wydarzenie. Panel wymagający logowania, na przykład portal uczestników badania, może działać w Next.js pod osobną ścieżką, a reszta zostaje w Astro. Test odbioru obejmuje zgodność liczby publikacji, identyfikatorów i plików do pobrania ze stanem sprzed migracji.

#Obiekt noclegowy i organizator wydarzeń w starym mieście

Hotel w pobliżu Zytglogge albo organizator imprez przy PostFinance Arena i na stadionie Wankdorf ma stronę z kalendarzem wydarzeń, galerią i widżetem rezerwacji. Wikipedia podaje, że hokejowy klub SC Bern gra w PostFinance Arena, a na Stadion Wankdorf rozegrano między innymi trzy mecze Euro 2008. Kalendarz wydarzeń generuje wiele podobnych adresów, które po sezonie wygasają. Mapa adresów rozróżnia trwałe strony obiektów od wydarzeń jednorazowych i nie kieruje wygasłych terminów na stronę główną. Rezerwacje zostają w systemie dostawcy, a widżet testuję na telefonie w obu językach.

#Polska firma, klienci w Szwajcarii: RODO, UODO i FADP razem

Szwajcaria nie należy do Unii Europejskiej, więc polska firma z klientami w Bernie wchodzi w układ, który w Hiszpanii czy we Włoszech nie występuje. Przetwarzanie danych przez administratora z siedzibą w Polsce podlega RODO pod nadzorem Prezesa UODO. Strona kierowana do osób w Szwajcarii wywołuje przy tym skutki, o których mówi art. 3 FADP, więc stosuje się także szwajcarska ustawa. Dwa porządki nie wykluczają się, a zakres każdego ocenia prawnik.

Z mojej strony ma to konkretne konsekwencje techniczne:

  • Rozdział V RODO. Szwajcaria jest dla RODO państwem trzecim. Jeśli dane z formularza lub analityki trafiają do dostawcy w Szwajcarii albo od niego wracają, każdy taki przepływ opisuję i sprawdzam podstawę transferu przed podpisaniem umów.
  • Umowy powierzenia. Art. 28 RODO wymaga umowy z procesorem. Hosting, poczta transakcyjna, analityka i narzędzie rezerwacji dostają osobne pozycje na liście do podpisania przed przełączeniem.
  • Cookies i skrypty. Art. 399 Prawa komunikacji elektronicznej wymaga poinformowania użytkownika o celu i uzyskania zgody na zapis lub odczyt informacji w urządzeniu końcowym. Nowy frontend startuje czysty, więc każdy skrypt dodaję świadomie i opisuję jego cel.
  • Dostępność. Polska ustawa z 26 kwietnia 2024 roku obejmuje między innymi handel elektroniczny podmiotów gospodarczych i od 28 czerwca 2025 roku nie dotyczy mikroprzedsiębiorców. Dyrektywa 2019/882 nie obowiązuje w Szwajcarii jako państwie spoza UE, więc wymagania wobec samej szwajcarskiej strony ustalam z miejscowym prawnikiem.

Nie jestem prawnikiem i nie podpisuję ocen prawnych. Dostarczam dokumentację przepływów i dowody testów, z którą pracuje doradca klienta.

#Praca zdalna z Polski w strefie czasowej Berna

Polska i Szwajcaria leżą w tej samej strefie czasowej środkowoeuropejskiej, więc warsztaty, odbiór i okno przełączenia nie wymagają godzin wieczornych ani porannych. Dokumentację, mapę przekierowań i runbook piszę po polsku. Jeśli zespół w Bernie pracuje po niemiecku lub francusku, uzgadniamy język streszczeń decyzji na początku projektu. Teksty publikowane na stronie w danym języku przygotowuje albo zatwierdza osoba, dla której to język ojczysty. Ja odpowiadam za strukturę, adresy, metadane i dane strukturalne.

Dostęp do środowisk klienta ograniczam do niezbędnego minimum: konta imienne, uwierzytelnianie wieloskładnikowe, rejestr operacji administracyjnych. Sekrety trafiają do menedżera wskazanego przez klienta. Konta pozostają jego własnością także po zakończeniu projektu.

#Hreflang dla niemieckiego, francuskiego i angielskiego w jednej domenie

Google przyjmuje w hreflang kod języka z opcjonalnym kodem kraju, więc dla firmy z Berna zapisuję wersje jako de-CH, fr-CH i en, a przełącznik języka dostaje x-default. Każda strona wskazuje siebie i wszystkie pozostałe odpowiedniki. Dokumentacja Google zaznacza, że wzajemność jest warunkiem: jeśli dwie strony nie odsyłają do siebie, tagi są ignorowane.

Przy starym CMS-ie z wtyczką tłumaczeń odtwarzam powiązania z bazy, a nie z szablonu. Wtyczka mogła trzymać pary stron w tabelach, w parametrach adresu (?lang=fr) albo w osobnych podkatalogach. Sprawdzam to na zbudowanym HTML, każdą parę osobno, a wynik dostajesz jako plik z listą stron bez odpowiednika. Ten sam arkusz pokazuje wersję językową, której brakuje w mapie witryny.

#Okno pomiarowe i warunki powrotu

Zanim cokolwiek przełączę, mierzę stan wyjściowy osobno dla każdej wersji językowej: Core Web Vitals z danych rzeczywistych, liczbę wyświetleń i kliknięć w Search Console, skuteczność formularzy oraz liczbę błędów. Średnia z całej domeny ukryłaby wolny formularz we francuskiej wersji albo błędne przekierowania w angielskiej.

Kryteria powrotu zapisuję przed startem i przypisuję osobę decyzyjną. Mogą nimi być: niedziałający formularz kontaktowy, przypadkowy noindex, lawina błędów 404 na adresach z ruchem, niedostępny portal logowania albo błąd integracji. Poprzedni system pozostaje gotowy przez uzgodnione okno, a zmianę DNS lub routingu ćwiczę wcześniej na środowisku przedprodukcyjnym. Jeśli nowy system zapisuje dane, plan określa, jak zabezpieczyć rekordy utworzone po przełączeniu.

#Kiedy nie migrować strony z Berna

Nie rekomenduję migracji, gdy wolne są dwa szablony, a WordPress ma aktualne wtyczki, czysty motyw i właściciela technicznego. Cache, usunięcie zbędnych skryptów i poprawa obrazów wystarczą wtedy bez drugiego stosu technologicznego. Nie zaczynam jej także tuż przed ważną kampanią, wydarzeniem albo okresem składania wniosków, jeśli strona obsługuje taki proces.

Migracja nie naprawi sprzecznych treści w dwóch językach. Jeżeli wersje niemiecka i francuska rozjechały się merytorycznie, najpierw potrzebny jest audyt treści i decyzja, która wersja jest źródłem. Przeniesienie rozjechanych tekstów do szybszego systemu tylko utrwali problem. Przed rozpoczęciem wskazuję też właściciela utrzymania, bo Astro i Next.js wymagają aktualizacji zależności i monitoringu.

#Od czego zacząć?

Wyślij mi adres obecnej strony, nazwę i wersję CMS-a, języki, w których publikujesz, oraz główne źródła ruchu (wyszukiwarka, kampanie, linki z innych stron). Odpowiem pisemnym zakresem: co przenoszę, co zostaje poza projektem, Astro czy Next.js i jakie ryzyka znalazłem w obecnej stronie.

Mapa w Bernie i okolic

Przewodniki metodyczne (SEO, GEO, compliance)

Te materiały opisują, jak pracujemy nad cytowaniami w modelach językowych, modernizacją WooCommerce B2B oraz odpornością operacyjną pod NIS2 i przetargi - niezależnie od miasta realizacji.

Zobacz też w innych miastach Szwajcarii

Co wyróżnia w Bernie

Lokalna ekspertyza:

  • Migracja do Astro i Next.js dla firm w Bernie, Szwajcaria
  • Z WordPressa, Joomli, Drupala i starszych frameworków
  • Mapa URL z przekierowaniami 301, hreflang i dane strukturalne sprawdzane przed przełączeniem

Pracuję zdalnie dla firm w Bernie.

Potrzebujesz usługi: Migracja Next.js / Astro w Bernie?

Opisz projekt mailem. Odpowiadam w ciągu 48 godzin.

Opisz projekt

FAQ - Migracja Next.js / Astro w Bernie

Czy szwajcarska ustawa o ochronie danych obejmuje stronę hostowaną poza Szwajcarią?

Tak, jeśli przetwarzanie ma skutki w Szwajcarii. Art. 3 FADP stosuje ustawę do sytuacji wywołujących skutki w Szwajcarii, nawet jeśli zaczęły się za granicą. Przeniesienie strony na globalny CDN nie wyjmuje jej spod tych przepisów.

Astro czy Next.js, co wybrać?

Astro wybieram do stron, które są w większości treścią (strona firmowa, blog, dokumentacja), bo domyślnie nie wysyła JavaScriptu do przeglądarki. Next.js, gdy jest dużo interakcji, strefa zalogowanego użytkownika albo renderowanie po stronie serwera pod dynamiczne dane. Rekomendację uzasadniam na piśmie.

Czy migrujesz wszystko naraz?

Przy dużym serwisie przenoszę go sekcjami pod tą samą domeną: nowy frontend przejmuje jedną część, reszta zostaje w starym CMS-ie. Przy małej stronie jedno przełączenie wychodzi taniej niż utrzymywanie dwóch systemów.

Czy strona po niemiecku i francusku komplikuje migrację?

Komplikuje mapę URL i hreflang, nie technologię. Każda wersja językowa ma własną mapę przekierowań i wzajemne odwołania hreflang, a obie sprawdzam osobno przed przełączeniem i po nim.

Czy polska firma, która obsługuje klientów w Bernie, stosuje RODO czy szwajcarską ustawę?

Obie warstwy mogą działać jednocześnie. Firma z siedzibą w Polsce podlega RODO pod nadzorem Prezesa UODO, a strona kierowana do odbiorców w Szwajcarii wywołuje skutki objęte FADP. Transfer danych do Szwajcarii oceniam według rozdziału V RODO. Ostateczną ocenę wydaje prawnik, a ja dostarczam spis usług, cookies i lokalizacji danych.

Sprawdź inne usługi WordPress i bazę wiedzy