Migracja Next.js / Astro w Wiedniu

Wiedeń to rynek niemieckojęzyczny: urzędowym językiem Austrii jest niemiecki, a samo miasto jest jednym z dziewięciu krajów związkowych i liczy około 2 mln mieszkańców. Jeśli prowadzisz tu firmę z polskim zapleczem albo polską firmę z oddziałem w Austrii, migracja strony z WordPressa, Joomli lub Drupala na Astro albo Next.js ma zwykle dwa cele naraz: prostszy, szybszy frontend i ruch z Google, który nie spada w żadnej z wersji językowych. Poniżej opisuję, jak taką migrację prowadzę, co sprawdzam przed przełączeniem i po nim oraz gdzie najczęściej coś się psuje.

#Czy moja strona w Wiedniu w ogóle potrzebuje migracji?

Nie zawsze. Jeśli strona jest wolna przez kilkanaście wtyczek, brak cache i ciężki motyw, często wystarczy porządek w obecnym CMS-ie, a to kosztuje mniej niż przenosiny. Migracja ma sens, gdy problem siedzi w samej architekturze: frontend renderowany przy każdym wejściu, aktualizacje, których nikt nie testuje, bo każda coś psuje, albo stara Joomla czy Drupal bez ścieżki aktualizacji. Wtedy gotowy albo hybrydowy HTML zmniejsza powierzchnię ataku i daje redakcji przewidywalne publikowanie.

Zanim cokolwiek zaproponuję, patrzę na trzy rzeczy: skąd przychodzi ruch, które adresy go przynoszą i co redakcja naprawdę robi w panelu. Jeśli odpowiedź brzmi “dodajemy dwa wpisy w miesiącu”, nie ma powodu budować złożonej warstwy headless.

#Astro czy Next.js: co wybrać?

Astro wybieram dla serwisów, w których dominuje treść: strony firmowe, blogi, katalogi usług, serwisy wielojęzyczne. Strony są generowane z góry, a JavaScript trafia tylko tam, gdzie jest potrzebny. Next.js ma przewagę, gdy strona to w praktyce aplikacja: logowanie, panel klienta, dane zależne od użytkownika, rozbudowane formularze.

Treść nie musi opuszczać WordPressa. Dokumentacja Astro opisuje wariant, w którym WordPress zostaje jako headless CMS, a Astro tylko pobiera z niego treść i jest wdrażane osobno. Druga droga to eksport wpisów do Markdown, przy dużych i złożonych serwisach z ręcznymi poprawkami. Wybór zależy od tego, kto i jak często publikuje. Szerzej porównuję oba podejścia na stronie o migracji do Next.js i Astro, a o samej pracy z frameworkiem piszę w opisie usługi programisty Astro.

#Jak przenieść stronę bez utraty pozycji w Google?

Pracuję według wytycznych Google dla przenosin witryny ze zmianą adresów URL. W praktyce to kolejne kroki, każdy z kontrolą:

1. Spis starych adresów. Zbieram je z map witryny, logów serwera, analityki, bazy CMS-a i raportu linków Search Console. Sam crawl nie wystarcza, bo pomija strony, do których nic już nie linkuje, a które wciąż mają linki zewnętrzne.
2. Mapa przekierowań. Każdy stary adres dostaje jeden konkretny nowy odpowiednik i przekierowanie stałe 301 lub 308 po stronie serwera. Nie kieruję setek adresów na stronę główną, bo Google wprost to odradza.
3. Model treści. Typy wpisów, pola niestandardowe, kategorie, autorzy i media przenoszę do schematu kolekcji w nowym projekcie. Każde pole ma właściciela i walidację, żeby brak opisu albo zdjęcia wyrzucał błąd przy budowaniu, a nie pustą sekcję na produkcji.
4. Meta i dane strukturalne. Tytuły, opisy, canonical i JSON-LD przechodzą razem z treścią. Porównuję je skryptem między starą a nową wersją, adres po adresie.
5. Środowisko testowe. Nowa strona stoi pod osobnym adresem z blokadą indeksowania. Testuję na niej wszystkie przekierowania z mapy, zanim cokolwiek trafi na produkcję.
6. Przełączenie. Mały serwis przełączam w całości, większy sekcjami. Po starcie zgłaszam nową mapę witryny, a przy zmianie domeny także narzędzie zmiany adresu w Search Console.
7. Kontrola po starcie. Śledzę raporty map witryny, indeksowania i zapytań w Search Console, logi serwera pod kątem Googlebota i nieoczekiwanych kodów błędów oraz analitykę, w której ruch powinien spadać na starej wersji i rosnąć na nowej.

Google uprzedza, że w czasie przenosin pozycje chwilowo się wahają, a przy średnich serwisach zastąpienie starych adresów nowymi trwa kilka tygodni lub dłużej. Dlatego nie oceniam migracji po trzech dniach, tylko po danych z kilku tygodni.

#Jak ustawić hreflang dla wersji niemieckiej, polskiej i angielskiej?

Firmy w Wiedniu często prowadzą stronę po niemiecku i angielsku, a te z polskim zapleczem także po polsku. Przy migracji hreflang łatwo zgubić, bo stary CMS generował go wtyczką, a nowy projekt musi to robić sam. Pilnuję kilku zasad z dokumentacji Google:

• każda wersja wskazuje siebie i wszystkie pozostałe, a powiązania muszą być wzajemne, inaczej Google je ignoruje,
• kod języka może mieć dopisany region, na przykład de-AT dla niemieckiego w Austrii, ale sam kod kraju nie wystarczy,
• adresy w hreflang są pełne, z protokołem https://,
• x-default wskazuje stronę dla użytkowników, których język nie pasuje do żadnej wersji.

Po zmianie adresów hreflang musi wskazywać nowe URL-e, nie stare z przekierowaniem. To jeden z punktów, które sprawdzam skryptem na zbudowanej stronie, a nie na szablonie.

#Co z RODO i hostingiem po migracji?

Migracja często zmienia dostawców: nowy hosting, CDN, usługa formularzy, czasem zewnętrzny CMS. Każdy z nich, który przetwarza dane w Twoim imieniu, jest podmiotem przetwarzającym w rozumieniu art. 28 RODO, więc przed przełączeniem przeglądam z Tobą umowy powierzenia. Jeśli dostawca przekazuje dane poza Europejski Obszar Gospodarczy, wchodzą w grę warunki przekazywania z rozdziału V (art. 44 i kolejne). Dobrze też wiedzieć, że przy naruszeniu ochrony danych administrator zgłasza je organowi nadzorczemu w miarę możliwości w ciągu 72 godzin (art. 33).

Dla firmy z siedzibą w Wiedniu organem nadzorczym jest Österreichische Datenschutzbehörde, która mieści się przy Barichgasse 40-42 w 3. dzielnicy. HTML z Astro sam w sobie zbiera mniej danych niż rozbudowany WordPress z wtyczkami, ale formularze, analityka i osadzone usługi nadal wymagają przeglądu.

#Dla jakich wiedeńskich branż ma to znaczenie?

Miasto wskazuje jako swoje mocne strony między innymi biomedycynę, budownictwo socjalne i turystykę. W turystyce strona musi działać w kilku językach i wytrzymać sezonowe szczyty, co dobrze pasuje do HTML serwowanego z CDN. W Wiedniu działa też jedno z czterech głównych biur ONZ, w Vienna International Centre mieszczą się między innymi IAEA, UNIDO i UNODC. Dla firm, które obsługują takie środowisko, strona po angielsku jest równie ważna jak niemiecka, a poprawny hreflang decyduje, która wersja pojawi się w wynikach.

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

Turystyka daje ruch sezonowy: hotele, atrakcje, restauracje i biura podróży mają szczyty wokół świąt, długich weekendów i festiwali. Datę przełączenia ustawiam poza tymi oknami. Po starcie porównuję dane z analogicznymi tygodniami roku wcześniej, nie z poprzednim miesiącem.

Drugi nurt to turystyka biznesowa i konferencje. Strony hoteli konferencyjnych i organizatorów mają skoki przed wydarzeniem. Adresy poprzednich edycji często mają linki z mediów i programów, więc dostają osobne wiersze w mapie 301 zamiast trafiać na stronę główną.

Trzeci nurt to firmy obsługujące środowisko międzynarodowych organizacji i biomedycynę: strony po niemiecku i angielsku, dokumentacja, oferty pracy, raporty. Tutaj Search Console zwykle pokazuje sensowny udział zapytań angielskich. Wersję, która nie ma kliknięć, nie traktuję jak równorzędną przy planowaniu nakładu.

#Cztery wzorce projektów z Wiednia

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

#Obiekt noclegowy albo atrakcja z ruchem sezonowym

Ciężkie skrypty na każdej podstronie, wersje językowe jako kopie stron, rezerwacje w zewnętrznym systemie. Zaczynam od stabilnych adresów pokoi i atrakcji, bo to na nie wskazują linki z portali. Astro buduje strony treściowe, rezerwacje zostają w sprawdzonej usłudze. Odbiór obejmuje hreflang dla języków z realnym ruchem i test widżetu na telefonie.

#Firma obsługująca środowisko VIC albo klientów anglojęzycznych

Niemiecka i angielska wersja muszą wskazywać siebie nawzajem z kodem de-AT tam, gdzie treść jest lokalna. Formularze testuję w obu językach. Jeśli firma ma też polską wersję dla zaplecza, przenoszę ją w tej samej fali, żeby hreflang nie wskazywał adresów, które jeszcze nie istnieją.

#Producent albo laboratorium z dokumentacją PDF

Karty produktów, certyfikaty, instrukcje. Pliki PDF mają ruch z wyszukiwarki i linki z maili. Trafiają do mapy przekierowań. Ustalam jedno źródło danych do kart produktowych, żeby katalog na stronie nie rozjechał się z tym, co wysyła handlowiec.

#Organizator konferencji albo festiwalu

Program, bilety, archiwum edycji. Rozdzielam trwałe adresy od edycyjnych. Każda edycja dostaje ścieżkę z rokiem. HTML z CDN zdejmuje ryzyko przeciążenia w dniu otwarcia sprzedaży, a sprzedaż zostaje w zewnętrznym systemie.

#Co może pójść nie tak i jak to sprawdzam?

• Zgubione adresy. Strona z linkami zewnętrznymi nie trafiła do mapy i zwraca 404. Sprawdzam to, porównując listę z logów i Search Console z mapą przekierowań przed startem i ponownie po kilku dniach.
• Łańcuchy przekierowań. Stare przekierowania z WordPressa nakładają się na nowe. Spłaszczam je, żeby każdy stary adres prowadził do celu jednym skokiem.
• Puste meta i znikające dane strukturalne. Wyłapuje je porównanie zbudowanych stron z wersją produkcyjną.
• Media pod starymi ścieżkami. Obrazy z katalogu uploads też mają adresy i ruch z wyszukiwarki grafiki, więc trafiają do mapy przekierowań.
• Formularze, które nic nie wysyłają. Każdy testuję na środowisku testowym z prawdziwą skrzynką odbiorczą.

#Jakie progi wydajności przyjmuję przy odbiorze?

Progi Core Web Vitals z web.dev: LCP w 2,5 s lub szybciej, INP w 200 ms lub szybciej, CLS nie większe niż 0,1 dla 75. percentyla. Mierzę osobno telefon i komputer oraz typy stron: strona główna, karta usługi, artykuł, formularz. Porównuję z pomiarem sprzed migracji na tych samych URL-ach. Dane z rzeczywistych użytkowników zbierają się z opóźnieniem, więc pierwsze dni opieram na testach laboratoryjnych.

#Jakie kryteria powrotu ustalam przed startem?

Zapisuję w runbooku mierzalne warunki powrotu: niedziałający formularz, błąd w rezerwacji albo zapytaniu ofertowym, utrata danych z formularza, przypadkowy noindex, niedostępna kluczowa integracja. Przy każdym kryterium jest osoba decydująca. Dwa dni wcześniej obniżam TTL w DNS. Stara wersja zostaje gotowa przez uzgodnione okno. Po jego zakończeniu archiwizuję kod, bazę, pliki i instrukcję odtworzenia.

Przed startem zapisuję stan wyjściowy: Core Web Vitals, czas odpowiedzi, skuteczność formularzy, ruch organiczny, liczbę zaindeksowanych stron.

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

Zaczynam od trzech list: adresów z crawla, mapy witryny i stron z wyświetleniami w Search Console z ostatnich 16 miesięcy. Do tego logi serwera, bo pokazują wejścia z PDF, newsletterów i starych landingów konferencyjnych. Dla każdego adresu zapisuję: bez zmian, 301 albo 410.

Przy kilku językach robię osobny arkusz na każdy język. Hreflang generuję z modelu treści: każda strona zna odpowiedniki, odwołanie jest wzajemne. Skrypt po budowie sprawdza pary, czy żaden odnośnik nie trafia w przekierowanie i czy canonical zwraca 200. Dane strukturalne buduję z tych samych pól co widoczna treść. Tytuły i opisy porównuję adres po adresie i oznaczam różnice.

#Czy redakcja w Wiedniu musi zmieniać sposób pracy?

Nie musi. WordPress może zostać panelem, a Astro albo Next.js pobiera treść przez REST API lub GraphQL. Redaktorzy zostają przy znanym edytorze. Publiczna strona nie wystawia już wp-admin na świat.

Przed budową opisuję model treści: tytuł, lead, sekcje, pliki, relacje, metadane SEO. Bloki z martwego buildera zamieniam na komponenty z kontraktem pól. Podczas prac stara strona publikuje dalej. Podgląd nowej wersji odpala się po zmianie treści, więc uwagi redakcji kosztują minuty, nie tygodnie.

Jeśli firma ma polskie zaplecze i austriacki oddział, uzgadniam kto zatwierdza niemiecką, angielską i polską treść. Bez właściciela treści migracja tylko przyspieszy publikację sprzecznych wersji.

#Jak wygląda okno pomiarowe po przełączeniu?

Przed pracami zbieram stan wyjściowy: Core Web Vitals, czas odpowiedzi, skuteczność formularzy, ruch organiczny i liczbę zaindeksowanych stron, osobno dla telefonu i komputera oraz dla typów stron. Datę przełączenia wybieram poza sezonem turystycznym firmy i poza dużymi konferencjami.

Po zmianie DNS ponownie przechodzę całą mapę 301 na produkcji. Przez kilka tygodni sprawdzam raport indeksowania, 404 w logach i zapytania tracące wyświetlenia. Porównuję z analogicznymi tygodniami roku wcześniej. Spadek na grupie stron zwykle oznacza brakujące przekierowanie albo zgubiony hreflang.

#Co z mediami, PDF i starymi landingami konferencyjnymi?

Obrazy z katalogu uploads mają własne adresy i ruch z wyszukiwarki grafiki. Przenoszę je z zachowaniem nazw albo z przekierowaniem, nigdy „po cichu” na nowe hashe bez wpisu w mapie. Pliki PDF z programów konferencji, cenników i raportów często zbierają więcej linków zewnętrznych niż strony HTML obok nich. Trafiają do arkusza 301 osobno.

Landingi edycji wydarzeń sprzed kilku lat ludzie trzymają w zakładkach i newsletterach. Zamiast kierować je na stronę główną, daję przekierowanie na archiwum edycji albo na aktualny odpowiednik tematyczny. Dzięki temu intencja wyszukiwania zostaje czytelna dla Google i dla człowieka.

Jeśli rezerwacje albo sprzedaż biletów siedzą w zewnętrznym systemie, przed startem przechodzę całą ścieżkę na telefonie: wybór terminu, formularz, płatność, mail potwierdzający. W sezonie nikt nie czeka na naprawę, tylko otwiera konkurencję.

#Kiedy nie rekomenduję migracji?

Gdy wystarczy uporządkować wtyczki, cache i hosting. Gdy nikt nie wie, które treści są aktualne. Gdy start wypada tuż przed sezonem turystycznym albo dużą konferencją. Gdy po odbiorze nikt nie utrzyma zależności i procesu budowania. W tych przypadkach napiszę to w wycenie zamiast sprzedawać przenosiny.

#Co zostaje u Ciebie po odbiorze?

Repozytorium, dokumentacja architektury, mapa przekierowań, opis środowisk bez sekretów, procedura publikacji i instrukcja odtworzenia z kopii. Konta hostingu, domeny i narzędzi analitycznych zostają Twoją własnością. Mój dostęp ograniczam do kont imiennych z uwierzytelnianiem wieloskładnikowym. Zakres i wycena są indywidualne: dwie strony z tą samą liczbą podstron mogą mieć inną historię adresów i inną liczbę języków, więc stawek nie podaję przed audytem.

#Jak zacząć?

Wyślij mi adres obecnej strony, nazwę i wersję CMS-a oraz informację, skąd przychodzi ruch (wyszukiwarka, kampanie, polecenia) i które wersje językowe są dla Ciebie najważniejsze. Na tej podstawie przygotuję pisemny zakres: co przenoszę, co zostaje, jaką architekturę proponuję i jak wygląda przełączenie.

#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.