Migracja Next.js / Astro w Genewie

Jeśli twoja firma albo organizacja w Genewie ma stronę na WordPressie, Joomli, Drupalu albo starym frameworku i chcesz przenieść ją na Astro lub Next.js bez utraty ruchu z Google, poniżej opisuję, jak prowadzę taką migrację. Inwentarz adresów, mapa przekierowań 301, model treści, dane strukturalne, hreflang dla wersji francuskiej i angielskiej, przełączenie etapami, kontrola w Search Console. Do tego to, co szwajcarska ustawa o ochronie danych zmienia na nowej stronie.

#Czym różni się strona z Genewy od typowej strony firmowej?

Genewa jest stolicą kantonu Genewa i liczyła około 204 tys. mieszkańców na początku 2021 roku. Urzędowym językiem jest francuski. W mieście mają siedziby liczne agencje ONZ, Międzynarodowy Komitet Czerwonego Krzyża i Międzynarodowa Federacja Stowarzyszeń Czerwonego Krzyża i Czerwonego Półksiężyca, a szwajcarski MSZ opisuje “międzynarodową Genewę” jako centrum multilateralizmu.

Dla migracji ma to praktyczny skutek: strona z Genewy rzadko ma jedną wersję językową. Zwykle jest francuska, angielska, czasem niemiecka dla klientów z reszty Szwajcarii. Każda z nich ma własne adresy, własne linki z zewnątrz i własny ruch z wyszukiwarki. Migracja, która przenosi tylko wersję główną, a pozostałe zostawia “na później”, gubi ruch tam, gdzie nikt go nie mierzy. Przed spisaniem mapy 301 proszę o eksport stron z Search Console osobno dla najważniejszych wersji językowych, żeby nakład na hreflang wynikał z kliknięć, a nie z liczby języków menu.

#Kiedy przenosić stronę na Astro albo Next.js, a kiedy zostać przy obecnym CMS?

Migracja ma sens, gdy CMS realnie ogranicza wydajność, bezpieczeństwo albo pracę redakcji. Objawy, które sprawdzam na początku: czas odpowiedzi serwera powyżej sekundy, panel wolniejszy niż sama strona, aktualizacje wtyczek bez testów, redaktorzy, którzy publikują w jednym języku, bo dodanie tłumaczenia psuje układ. Jeśli wystarczy uporządkować wtyczki, cache i hosting, mówię to wprost i nie przepisuję strony, którą taniej naprawić tam, gdzie jest.

Astro wybieram dla stron, które są głównie treścią: oferta, publikacje, raporty, aktualności, oferty pracy. Generuje gotowy HTML i wysyła do przeglądarki tylko ten JavaScript, którego potrzebuje dana sekcja. Next.js wybieram, gdy strona zachowuje się jak aplikacja: logowanie, strefa dla członków albo partnerów, dane zmieniające się przy każdym wejściu.

WordPress może zostać jako headless CMS. Redakcja pracuje w znanym panelu, frontend pobiera treść przez REST API albo GraphQL. Osobne źródło treści proponuję dopiero wtedy, gdy panel przeszkadza ludziom, którzy publikują codziennie.

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

1. Lista starych adresów. Zbieram je z map witryny, logów serwera, analityki, CMS-a i eksportu stron z kliknięciami z Search Console. Osobno spisuję pliki PDF i obrazy, do których linkują inne serwisy, bo one też potrzebują przekierowań.
2. Mapa 301. Arkusz: stary URL, nowy URL, kod odpowiedzi. Każdy stary adres prowadzi wprost do swojego odpowiednika, bez łańcuchów i bez zrzucania wielu stron na stronę główną. Google wprost odradza kierowanie wielu starych adresów na jedną niezwiązaną stronę.
3. Model treści. Typy treści, pola, taksonomie, media i powiązania między wersjami językowymi. Import robię skryptem, który mogę puścić ponownie, gdy redakcja zmieni coś w trakcie prac.
4. Dane strukturalne. Organization, BreadcrumbList, Article, FAQPage przechodzą razem z treścią. Na środowisku testowym sprawdzam wyrenderowany JSON-LD narzędziem Google do weryfikacji danych strukturalnych.
5. Canonical, hreflang, linki wewnętrzne. Wszystkie wskazują już nowe adresy, nie stare, które dopiero przekierowują.
6. Środowisko testowe. Kopia zablokowana przed indeksacją i skrypt, który dla każdego adresu z listy porównuje title, meta description, canonical, H1 i kod odpowiedzi na starej i nowej stronie.
7. Przełączenie. Na dużym serwisie sekcja po sekcji, na małym jednorazowo. Dzień wcześniej obniżam TTL rekordów DNS, żeby ewentualny powrót trwał minuty, nie godziny.
8. Kontrola po starcie. Nowa mapa witryny w Search Console, raport indeksowania stron, dane o zapytaniach, logi serwera. Ruch na starych adresach ma spadać, na nowych rosnąć.

Google pisze wprost, że po zmianie adresów pozycje mogą się chwilowo wahać, a średnie serwisy potrzebują kilku tygodni lub więcej, zanim nowe adresy zastąpią stare. Dlatego porównuję kliknięcia na poziomie pojedynczych adresów, a nie całej domeny.

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

Kod języka może mieć dopisany region: fr-CH dla francuskiej wersji szwajcarskiej, de-CH dla niemieckiej. Sam kod kraju nie działa. Jeśli wersja angielska jest skierowana do wszystkich, oznaczam ją jako en, bez regionu. Strona wyboru języka dostaje x-default.

Każda wersja wymienia siebie i wszystkie pozostałe. Gdy dwie strony nie wskazują siebie nawzajem, Google ignoruje te znaczniki. Typowy błąd po migracji wielojęzycznej: wersja francuska wskazuje angielską, a angielska po przeniesieniu wskazuje już tylko siebie. Sprawdzam to skryptem na wyrenderowanym HTML całego serwisu, nie na szablonie.

#Co może pójść źle i jak to wyłapuję?

• Łańcuchy i pętle przekierowań: skrypt przechodzi każdy stary adres i zapisuje liczbę skoków oraz końcowy kod.
• Znacznik noindex ze środowiska testowego na produkcji: sprawdzam żywą stronę, nie konfigurację.
• Wersja językowa przeniesiona bez części podstron: liczę adresy w każdym języku przed i po.
• Formularze, które przestały wysyłać: testuję każdy na produkcji, łącznie z dostarczeniem wiadomości.
• Brak tagu analityki: bez niego nie porównasz ruchu przed i po, więc sprawdzam go pierwszego dnia.

#Co szwajcarska ustawa o ochronie danych oznacza dla nowej strony?

Szwajcaria ma własną ustawę federalną o ochronie danych z 25 września 2020 r. (Loi fédérale sur la protection des données, LPD, RS 235.1). Nadzór sprawuje federalny pełnomocnik ds. ochrony danych i jawności (PFPDT, po angielsku FDPIC), który sprawdza, czy organy federalne i firmy prywatne przetwarzają dane zgodnie z prawem. Przy migracji strony liczy się kilka przepisów:

• Art. 19 wymaga poinformowania osoby o zbieraniu jej danych, co najmniej o tożsamości i danych kontaktowych administratora, celu i odbiorcach. Gdy dane trafiają za granicę, trzeba też podać państwo.
• Art. 16 pozwala przekazać dane za granicę, gdy Rada Federalna uznała ochronę w danym państwie za odpowiednią, a w innych przypadkach na przykład na podstawie umowy międzynarodowej albo klauzul umownych.
• Art. 7 każe uwzględnić ochronę danych już przy projektowaniu przetwarzania. Nowy frontend to dobry moment, żeby usunąć skrypty zewnętrzne, których nikt nie używa.
• Art. 24 wymaga zgłoszenia PFPDT naruszenia bezpieczeństwa danych, które prawdopodobnie niesie wysokie ryzyko, w możliwie krótkim czasie.
• Art. 60 przewiduje grzywnę do 250 000 franków dla osób prywatnych, które umyślnie nie spełnią obowiązku informacyjnego.

Migracja zwykle zmienia hosting, CDN, dostawcę formularzy albo analitykę, więc polityka prywatności przestaje się zgadzać ze stanem faktycznym. Przekazuję ci listę usług i krajów, w których przetwarzane są dane. Tekst prawny przygotowuje twój prawnik, nie ja.

#Skąd bierze się ruch na stronach z Genewy?

Pierwszy nurt to organizacje międzynarodowe i ich ekosystem: strony fundacji, stowarzyszeń, firm konsultingowych i dostawców usług. Ruch jest często angielski albo francuski w zależności od odbiorcy. Search Console pokazuje udział krajów i języków; na tej podstawie planuję nakład na hreflang, a nie na podstawie tego, ile wersji ktoś kiedyś dorobił.

Drugi nurt to firmy lokalne obsługujące kanton: usługi B2B, zatrudnienie, wydarzenia. Tutaj dominuje francuski (fr-CH). Adresy ofert pracy mają krótkie życie: wygasają co kilka tygodni, a mimo to zbierają kliknięcia. Wygasłej ofercie daję 410 albo przekierowanie na listę w tym samym dziale, nie na stronę główną.

Trzeci nurt to publikacje i raporty PDF. Organizacje i think-tanki linkują do PDF latami. Te pliki trafiają do mapy 301 osobno, bo crawl HTML ich nie widzi, a logi i Search Console już tak.

#Cztery wzorce projektów z Genewy

To scenariusze z problemów powtarzających się lokalnie. Nie opisują konkretnych klientów.

#Organizacja z wersją FR i EN oraz strefą dla członków

Publiczna treść idzie do Astro. Strefa po zalogowaniu zostaje w Next.js albo w obecnym systemie pod osobną ścieżką. Hreflang i canonical ustawiam tylko na stronach publicznych. Formularz członkostwa testuję w obu językach przed startem.

#Fundacja albo stowarzyszenie z archiwum publikacji

Raporty, komunikaty, strony wydarzeń. Rozdzielam trwałe adresy od edycyjnych. Każdy raport z ruchem dostaje stały URL. Jeśli redakcja publikuje rzadko, treści mogą przejść do Markdowna. Jeśli publikuje często, WordPress zostaje panelem.

#Firma B2B z klientami w CH-DE i CH-FR

Francuska i niemiecka wersja szwajcarska z kodami fr-CH i de-CH, plus ewentualnie en. Każda para musi być wzajemna. Formularz ofertowy testuję wysyłką do CRM. Karty usług buduję z jednego źródła danych, żeby tłumaczenia nie rozjechały się po roku.

#Dostawca usług konferencyjnych albo eventowych

Landingi edycji, rejestracja, archiwum. Datę przełączenia ustawiam poza oknem największego wydarzenia w kalendarzu firmy. HTML z CDN znosi skok ruchu w dniu otwarcia rejestracji. Formularz rejestracji zostaje w sprawdzonej usłudze.

#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, publikacja, oferta pracy, formularz. Porównuję z pomiarem sprzed migracji. 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ę mierzalne warunki: niedziałający formularz, utrata danych ze zgłoszenia, przypadkowy noindex, niedostępna integracja z CRM albo systemem członkowskim. 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 nim archiwizuję kod, bazę, pliki i instrukcję odtworzenia.

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

#Jak zachowuję sygnały SEO przy fr-CH, en i de-CH?

Zaczynam od list z crawla, mapy witryny i Search Console (16 miesięcy), plus logów serwera. Organizacje w Genewie często mają w logach stare raporty PDF i landingi wydarzeń. Dla każdego adresu: bez zmian, 301 albo 410. Osobny arkusz na każdy język.

Hreflang generuję z modelu treści. Skrypt sprawdza wzajemność par, brak odwołań do przekierowań i canonical zwracający 200. Przy zmianie domeny z .com na .ch używam narzędzia zmiany adresu w Search Console dla wszystkich zweryfikowanych wariantów. Dane strukturalne buduję z tych samych pól co treść. Tytuły i opisy porównuję adres po adresie.

#Czy redakcja musi zmieniać sposób pracy?

Nie musi. WordPress może zostać panelem, frontend pobiera treść przez API. Przy publikacjach w FR i EN uzgadniam, kto zatwierdza każdą wersję. Bez właściciela treści hreflang tylko utrwali rozjazdy.

Przed budową opisuję model: tytuł, lead, sekcje, pliki, powiązania językowe, metadane. Martwe bloki z buildera zamieniam na komponenty z kontraktem. Stara strona publikuje w trakcie prac. Podgląd nowej wersji odpala się po zmianie treści.

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

Stan wyjściowy zapisuję osobno dla FR i EN: Core Web Vitals, czas odpowiedzi, skuteczność formularzy, ruch, liczba zaindeksowanych stron. Datę startu ustawiam poza dużym wydarzeniem i kampanią rekrutacyjną. Po DNS ponownie testuję mapę 301 na produkcji. Przez kilka tygodni śledzę indeksowanie, 404 i zapytania. Porównuję z analogicznymi tygodniami, nie z poprzednim miesiącem.

#Co z PDF, ofertami pracy i strefą członkowską?

Raporty i komunikaty w PDF linkują organizacje partnerskie latami. Każdy plik z ruchem albo linkami zewnętrznymi dostaje wiersz w mapie 301. Oferty pracy mają krótkie życie: wygasłej daję 410 albo przekierowanie na listę w tym samym dziale, nie na stronę główną. Dzięki temu wyniki wyszukiwania nie prowadzą do pustej strony głównej.

Jeśli strona ma strefę dla członków albo partnerów, oddzielam ją od warstwy publicznej. Publiczna treść idzie do Astro. Strefa po zalogowaniu zostaje w Next.js albo w obecnym systemie pod osobną ścieżką. Canonical i hreflang ustawiam tylko na stronach publicznych, żeby nie indeksować paneli.

Formularze członkostwa, darowizn i aplikacji testuję w każdym języku z listy zakresu, łącznie z dostarczeniem wiadomości do docelowego systemu. Zgubione zgłoszenie wychodzi dopiero wtedy, gdy ktoś zapyta, dlaczego nikt nie odpisał.

#Kiedy nie rekomenduję migracji?

Gdy wystarczy porządek w wtyczkach i hostingu. Gdy nikt nie wie, które wersje językowe są aktualne. Gdy start wypada tuż przed dużym wydarzeniem albo kampanią rekrutacyjną. Gdy po odbiorze nikt nie utrzyma procesu budowania. W takich przypadkach kończę na audycie i rekomendacji naprawy obecnego CMS.

#Co zostaje u ciebie po migracji?

Repozytorium z kodem, zmienne środowiskowe, pipeline wdrożeniowy, mapa przekierowań, dokumentacja architektury i krótka instrukcja wdrażania zmian, tak żeby twój zespół albo inny wykonawca mógł przejąć projekt. Konta hostingu i domeny zostają twoją własnością. Mój dostęp ograniczam do kont imiennych z uwierzytelnianiem wieloskładnikowym. Po starcie poprawiam błędy krytyczne i przeglądam wydajność po pierwszym szczycie ruchu. Zakres i wycena są indywidualne: stawek nie podaję przed audytem. Więcej o samej usłudze piszę na stronie migracja do Next.js i Astro, a o pracy z samym frameworkiem na stronie programista Astro.

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

Wyślij adres obecnej strony, nazwę i wersję CMS-a, listę wersji językowych, formularze i integracje oraz źródła ruchu: wyszukiwarka, kampanie, newsletter, linki z serwisów partnerskich. Napisz też, czy planujesz zmianę domeny. Na tej podstawie przygotowuję pisemny zakres: co przenoszę, czego nie ruszam, wybór Astro albo Next.js z uzasadnieniem i plan przełączenia.

#Jak wygląda praca równoległa do żywej strony w Genewie?

Headless nie wymaga wymiany panelu. WordPress może dalej trzymać treści po francusku i angielsku, a Astro albo Next.js pobiera je przez API. Redakcja zostaje przy znanym procesie. Najpierw opisuję model z jawnymi polami i powiązaniami językowymi, potem buduję nową warstwę prezentacji obok żywej witryny. Krótkie ograniczenie publikacji pojawia się tylko przy końcowej synchronizacji, jeśli źródło danych tego wymaga, i jest zapisane w runbooku.

Po zmianie DNS porównuję Search Console osobno dla FR i EN: indeksację, 404 i kliknięcia na stronach, które wcześniej miały ruch. Mapę przekierowań odpytuję skryptem na produkcji. Formularze członkostwa 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, nie sam eksport treści.