Migracja Next.js / Astro w Leeds

Migracja z WordPressa, Drupala, Joomli albo starszej aplikacji do Astro lub Next.js ma sens dopiero wtedy, gdy rozwiązuje mierzalny problem. w Leeds takim problemem bywa wolny serwis generujący zapytania dla firmy doradczej, trudny w utrzymaniu portal rekrutacyjny albo witryna fintech, w której publiczny CMS niepotrzebnie zwiększa powierzchnię ataku. Sam wiek strony nie wystarcza. WPPoland zaczyna od audytu, a nie od wyboru frameworka.

Przenosimy treść, adresy URL, metadane, dane strukturalne i proces publikacji jako jeden system. Frontend może się zmienić, lecz redakcja nie musi porzucać WordPressa. Przełączenie odbywa się z przygotowanym powrotem, a odbiór opiera się na danych z okresu przed i po wdrożeniu. Ten sposób pracy pasuje do zespołów Leeds, które potrzebują brytyjskiego kontekstu prawnego i roboczych godzin bliskich Polsce, ale nie chcą uzależniać utrzymania od jednej agencji.

#Migracja czy relaunch w obecnym systemie

Relaunch zmienia sposób prezentacji, architekturę informacji i warstwę wizualną bez koniecznego opuszczania obecnego CMS-a. Migracja zmienia podstawę techniczną, zachowując lub świadomie przekształcając to, co już działa. Rozróżnienie wpływa na ryzyko, harmonogram i kryteria odbioru.

Migrację uzasadnia system, którego ograniczenia wracają po każdej lokalnej naprawie. Przykładem jest motyw WordPress powiązany z niewspieranym builderem, przez co aktualizacja PHP blokuje kluczowe szablony. Innym sygnałem jest Drupal albo autorski CMS, w którym wdrożenie drobnej zmiany wymaga dostępu do wiedzy jednej osoby. W projektach lead generation problem może ujawniać się jako niestabilny LCP, skrypty ładowane na każdej podstronie i formularze połączone z CRM-em bez testów kontraktowych. Kolejny plugin optymalizacyjny nie usuwa wtedy przyczyny.

Relaunch w WordPressie jest lepszy, gdy backend jest aktualny, zespół zna proces publikacji, a kłopot ogranicza się do ciężkiego motywu, chaotycznych bloków lub niespójnej nawigacji. Nowy, lekki motyw i porządek w rozszerzeniach mogą dać oczekiwany wynik przy mniejszej zmianie operacyjnej. Podobnie postępujemy, gdy firma planuje przebudowę oferty. Najpierw stabilizuje treści i ścieżki użytkownika, a dopiero później ocenia, czy nowy frontend nadal jest potrzebny.

Audyt kończy się rekomendacją z uzasadnieniem. Jeżeli naprawa istniejącego WordPressa wystarczy, nie dokładamy headless tylko po to, aby użyć Astro albo Next.js. Technologia ma ograniczyć koszt zmian i ryzyko działania, nie stworzyć nowy projekt utrzymaniowy.

#Astro i Next.js dobierane do konkretnych tras

Jedna domena nie wymaga jednego sposobu renderowania. Dzielimy serwis na rodziny tras i dla każdej zapisujemy wymagania: czy treść jest wspólna dla wszystkich, jak często się zmienia, czy użytkownik się loguje, skąd pochodzą dane, jaki czas odpowiedzi jest akceptowalny i co ma się wydarzyć podczas awarii API.

Astro pasuje do stron usług, centrum wiedzy, dokumentacji, profili ekspertów i większości publikacji. Generuje HTML podczas budowania i pozwala dołączać JavaScript tylko do elementów, które go potrzebują. Dla serwisu firmy prawniczej, księgowej lub konsultingowej z Leeds oznacza to szybkie strony treściowe bez stałego serwera aplikacyjnego w ścieżce każdego wejścia. Interaktywny kalkulator albo formularz może działać jako odrębna wyspa, bez zmiany całej strony w aplikację React.

Next.js jest właściwszy dla portalu klienta, panelu z danymi zależnymi od uprawnień, zaawansowanego wyszukiwania ofert pracy albo produktu finansowego prezentującego wynik zależny od sesji. Renderowanie na serwerze lub na żądanie ma wtedy konkretne zadanie. Nadal ograniczamy kod wysyłany do przeglądarki i oddzielamy publiczną warstwę marketingową od operacji wymagających uwierzytelnienia.

W większym serwisie oba rozwiązania mogą współistnieć. Astro obsługuje główną witrynę i publikacje, a Next.js portal pod wybraną ścieżką lub subdomeną. Warstwa routingu utrzymuje wspólne adresy, nagłówki bezpieczeństwa i obserwowalność. Decyzja zostaje w repozytorium jako krótki zapis architektoniczny. Następny zespół powinien wiedzieć, dlaczego dana trasa korzysta z Next.js, zamiast zakładać, że tak wyszło z historii projektu.

#Zachowanie adresów URL i sygnałów SEO

Największe straty po migracji zwykle zaczynają się od niepełnego inwentarza. Crawl pokazuje strony osiągalne przez linki wewnętrzne, ale nie obejmuje całej historii. Google Search Console ujawnia adresy znane wyszukiwarce, a logi serwera pokazują stare wejścia z dokumentów PDF, newsletterów, zakładek i zewnętrznych serwisów. Łączymy te trzy źródła i usuwamy duplikaty dopiero po zachowaniu informacji o pochodzeniu.

Każdy dotychczasowy URL otrzymuje status w mapie migracji. Najbezpieczniejszy wariant zachowuje tę samą ścieżkę. Gdy treści zostały połączone, stary adres prowadzi jednym przekierowaniem 301 do najbardziej zbliżonego następcy. Usunięty materiał bez odpowiednika zwraca świadomie wybrany kod odpowiedzi. Nie kierujemy całych grup starych stron na stronę główną, ponieważ taki skrót utrudnia użytkownikom dotarcie do celu i zaciera informację dla wyszukiwarki.

Równolegle porównujemy tytuły, opisy, canonicale, robots directives, hreflang, dane Open Graph, schema markup i linki wewnętrzne. Migracja nie może zgubić oznaczeń organizacji, artykułów, FAQ ani breadcrumbs tylko dlatego, że poprzednio tworzyła je wtyczka. Dla witryn kierowanych na kilka rynków sprawdzamy każdą parę hreflang oraz odwołanie zwrotne. Mapa witryny zawiera wyłącznie kanoniczne, indeksowalne adresy i odpowiada temu, co rzeczywiście zbudował frontend.

Przed wdrożeniem automat pobiera zestaw reprezentatywnych stron ze starego i nowego środowiska. Porównuje kody odpowiedzi, elementy head, nagłówki, treść krytyczną oraz linki. Osobny test przechodzi pełną mapę przekierowań i wykrywa pętle lub łańcuchy. Dzięki temu błąd trafia do raportu przed zmianą DNS, a nie do Search Console kilka tygodni później.

#WordPress pozostaje narzędziem redakcji

Headless nie musi oznaczać wymiany panelu. WordPress może dalej przechowywać treści, użytkowników redakcyjnych, wersje robocze, harmonogram publikacji i pola zdefiniowane dla poszczególnych typów materiału. Astro lub Next.js pobiera dane przez REST API albo WPGraphQL i odpowiada za prezentację. Zmieniamy motyw widoczny dla odwiedzających, lecz nie odbieramy redaktorom sprawdzonego przepływu pracy.

Najpierw opisujemy model treści. Tytuł, lead, autor organizacyjny, sekcje, relacje, pliki i metadane SEO muszą mieć jawne pola zamiast ukrytych zależności od starego buildera. Bloki wymagają kontraktu, który określa dane obowiązkowe, warianty i zachowanie bez obrazu lub odnośnika. To ogranicza sytuacje, w których wpis wygląda poprawnie w panelu, ale nie może zostać wyrenderowany poza starym motywem.

Podczas prac dotychczasowa witryna nadal publikuje. Nowy frontend buduje się równolegle na tych samych danych, a webhook uruchamia wersję testową po zmianie treści. Przed przełączeniem wykonujemy synchronizację i ustalamy krótkie okno ograniczonej publikacji tylko wtedy, gdy wymaga tego źródło danych. Runbook podaje godzinę, odpowiedzialność i sposób potwierdzenia, że ostatnie zmiany są widoczne w nowym systemie.

Backend administracyjny można ograniczyć sieciowo, objąć dodatkowym uwierzytelnieniem i oddzielić od publicznego hosta. Nie przedstawiamy tego jako automatycznej ochrony. Aktualizacje WordPressa, kontrola ról, kopie zapasowe oraz monitoring API nadal są potrzebne. Zyskiem jest mniejsza liczba publicznych punktów wejścia i brak połączenia z bazą danych w statycznej stronie dostarczanej użytkownikowi.

#Okno pomiarowe i przećwiczony powrót

Wdrożenie zaczyna się od pomiaru stanu wyjściowego. Zbieramy Core Web Vitals z danych rzeczywistych, czas odpowiedzi, liczbę błędów aplikacji, skuteczność formularzy, główne konwersje, ruch organiczny i poziom indeksacji. Wyniki przypisujemy do typów stron i urządzeń. Jedna średnia dla całej domeny mogłaby ukryć wolny formularz mobilny albo problemy wyłącznie w archiwum publikacji.

Przed przełączeniem ustalamy kryteria powrotu. Mogą nimi być niedostępność ścieżki kontaktowej, błąd logowania, utrata danych z formularza, nieoczekiwane blokowanie indeksacji albo awaria integracji krytycznej. Kryteria muszą być obserwowalne i powiązane z osobą decyzyjną. Samo stwierdzenie, że nowa strona działa gorzej, nie wystarcza podczas incydentu.

Poprzedni system pozostaje gotowy przez ustalone okno pomiarowe. Zmiana routingu lub DNS ma udokumentowaną procedurę cofnięcia, którą ćwiczymy na środowisku przedprodukcyjnym. Jeżeli nowy system zapisuje dane, plan określa, jak zabezpieczyć rekordy utworzone po przełączeniu. Bez tego techniczny powrót mógłby uratować dostępność kosztem zgłoszeń klientów.

Po publikacji obserwujemy błędy 404, przekierowania, logi funkcji, wydajność, indeksację i konwersje. Porównanie odbywa się z właściwym okresem odniesienia, z uwzględnieniem dnia tygodnia, kampanii oraz sezonowości. Stary system archiwizujemy dopiero po spełnieniu kryteriów odbioru. Kopia obejmuje kod, bazę, pliki, konfigurację infrastruktury i instrukcję odtworzenia, a nie sam eksport treści.

#Dane w Wielkiej Brytanii i transfery międzynarodowe

Statyczny frontend nie usuwa obowiązków związanych z danymi. Formularz kontaktowy, analityka, CRM, narzędzie rekrutacyjne, nagrania sesji i logi infrastruktury nadal mogą przetwarzać identyfikatory lub treści przekazane przez użytkownika. Migracja daje dobry moment na sporządzenie rzeczywistej mapy przepływów, ponieważ zmiana hostingu i integracji i tak wymaga ich ponownego podłączenia.

Dla firmy z Leeds punktem odniesienia są UK GDPR i Data Protection Act 2018. Dokumentujemy kategorie danych, podstawę przetwarzania wskazaną przez klienta, retencję, procesorów, lokalizacje oraz mechanizmy transferu międzynarodowego. Nie zakładamy, że platforma z regionem w Londynie utrzyma każdy log i każdą usługę pomocniczą w Wielkiej Brytanii. Sprawdzamy osobno hosting frontendu, system CMS, bazę, monitoring, kopie zapasowe, pocztę transakcyjną i analitykę.

Zespół WPPoland pracuje w modelu bliskiego geograficznie dostarczania usług między Polską a Wielką Brytanią. Wspólna część dnia roboczego ułatwia warsztaty z zespołem w Leeds i reakcję podczas wdrożenia. Jednocześnie dostęp polskiego zespołu do środowisk klienta musi znaleźć się w dokumentacji dostępu i transferów. Stosujemy najmniejsze potrzebne uprawnienia, konta imienne, uwierzytelnianie wieloskładnikowe i rejestr operacji administracyjnych.

Equality Act 2010 wprowadza obowiązki związane z niedyskryminacją i rozsądnymi dostosowaniami, ale techniczna lista kontrolna nie zastępuje oceny prawnej konkretnej usługi. W projekcie używamy WCAG jako standardu testowego: sprawdzamy obsługę klawiaturą, kolejność fokusu, nazwy dostępne dla kontrolek, kontrast, powiększenie, komunikaty błędów oraz zachowanie formularzy z czytnikiem ekranu. Wyniki i wyjątki trafiają do raportu odbiorowego, aby klient mógł połączyć dowody techniczne ze swoją analizą prawną.

#Trzy wzorce projektów z Leeds

Poniższe wzorce są scenariuszami projektowymi zbudowanymi z powtarzalnych problemów, a nie opisami konkretnych klientów WPPoland.

#Serwis usług profesjonalnych z rozproszonymi publikacjami

Firma doradcza prowadzi główną stronę w WordPressie, bazę analiz w osobnym narzędziu i profile ekspertów jako ręcznie składane podstrony. Ten sam autor, sektor i temat mają różne nazwy w trzech miejscach. Migracja zaczyna się od wspólnego modelu treści oraz identyfikatorów, nie od wyglądu strony. WordPress pozostaje backendem, a Astro buduje ofertę, publikacje i profile z jednego zestawu danych. Dotychczasowe adresy analiz zostają zachowane, ponieważ mają linki z mediów branżowych i dokumentów klientów. Wyszukiwanie korzysta z przygotowanego indeksu, więc nie wymaga uruchamiania całej strony jako aplikacji.

Odbiór obejmuje zgodność liczby publikacji, relacji autorów, metadanych i plików do pobrania. Osobno testujemy formularze kontaktowe przypisane do praktyk oraz rejestrowanie zgód. Nowy frontend nie rozwiąże bałaganu taksonomii samodzielnie, dlatego decyzje redakcyjne zapadają przed masowym importem.

#Fintech z publiczną wiedzą i chronionym panelem

Firma produktowa ma stronę marketingową, dokumentację pomocy i panel dla klientów. Stary frontend łączy wszystko w jednej aplikacji, przez co nawet zwykły artykuł pobiera kod uwierzytelnienia i komponenty panelu. Podział tras daje czytelną granicę. Astro obsługuje publiczną ofertę oraz pomoc, a Next.js pozostaje przy panelu, gdzie sesja, uprawnienia i dane na żądanie są uzasadnione.

Warstwa routingu utrzymuje jedną domenę i spójne nagłówki bezpieczeństwa. Testy kontraktowe sprawdzają API panelu, a crawl porównawczy pilnuje publicznych adresów. Migracja przebiega etapami: najpierw treści, następnie logowanie i widoki konta. Powrót może dotyczyć jednej grupy tras, zamiast wycofywać cały serwis.

#Organizacja rekrutująca w Yorkshire

Serwis rekrutacyjny publikuje strony sektorów, poradniki i oferty pobierane z systemu ATS. W starym rozwiązaniu wygasła oferta nadal pojawia się w indeksie, a każda zmiana integracji blokuje publikację zwykłych treści. Astro generuje trwałe strony redakcyjne, natomiast mała warstwa serwerowa pobiera aktualne oferty i zwraca kontrolowany komunikat podczas niedostępności ATS.

Mapa URL rozdziela trwałe strony zawodów od krótkotrwałych ogłoszeń. Wygasłe oferty nie są mechanicznie kierowane na stronę główną. Zależnie od wartości i dostępnego następcy pokazują status wygaśnięcia, prowadzą do właściwej kategorii albo zwracają uzgodniony kod. Test dostępności obejmuje filtry, komunikaty walidacji i formularz aplikacyjny. Dane kandydatów nie trafiają do statycznego buildu, a logi nie zapisują treści CV.

#Kiedy nie migrować

Nie rekomendujemy migracji, gdy zadaniem jest wyłącznie poprawa kilku wolnych szablonów, a WordPress ma aktualne rozszerzenia, czysty motyw i właściciela technicznego. Profilowanie zapytań, usunięcie zbędnych skryptów, cache i poprawa obrazów mogą wtedy rozwiązać problem bez wprowadzania drugiego stosu technologicznego.

Nowy frontend nie naprawi nieaktualnej oferty, powielonych tekstów ani braku odpowiedzialności redakcyjnej. Jeżeli zespół nie wie, które treści zachować i kto zatwierdza ich zmianę, najpierw potrzebny jest audyt treści. Migracja wykonana przed tym etapem przeniesie sprzeczności do szybszego systemu i utrudni późniejsze porządki.

Nie zaczynamy przełączenia tuż przed kluczową kampanią, naborem lub terminem regulacyjnym. Można wcześniej przygotować inwentarz, testy i nowy frontend, ale publikacja potrzebuje czasu na okno pomiarowe oraz reakcję zespołu. Data narzucona bez miejsca na cofnięcie zwiększa ryzyko utraty zgłoszeń i błędnej indeksacji.

Migracja jest również złym wyborem, jeśli po odbiorze nikt nie będzie utrzymywać zależności, procesu budowania i monitoringu. Astro ogranicza kod wykonywany po stronie klienta, lecz nadal wymaga aktualizacji. Next.js ma własny cykl wersji i wymagania infrastrukturalne. Przed rozpoczęciem wskazujemy właściciela usługi po stronie klienta albo uzgadniamy utrzymanie zewnętrzne.

#Jak WPPoland prowadzi migrację z zespołem w Leeds

Pracę dzielimy na etapy z osobnymi wynikami i kryteriami odbioru. Pierwszy etap to audyt systemu, danych, integracji i ruchu. Powstaje inwentarz URL, mapa zależności, pomiar bazowy, rejestr ryzyk oraz rekomendacja: naprawa, relaunch w obecnym systemie albo migracja. Zakres i wycena są indywidualne, ponieważ dwa serwisy o tej samej liczbie podstron mogą mieć zupełnie inną historię adresów i integracji.

Drugi etap projektuje architekturę tras i model treści. Wspólnie z redakcją z Leeds sprawdzamy, co musi pozostać w WordPressie, które pola wymagają uporządkowania i jakie operacje muszą działać bez dostępu do API. Decyzje zapisujemy po angielsku lub polsku zależnie od składu zespołu. Spotkania odbywają się w godzinach wspólnych dla Wielkiej Brytanii i Polski, a pytania wymagające decyzji biznesowej trafiają do jednego rejestru.

Trzeci etap to równoległa budowa. Importy są powtarzalne, a nie jednorazowe. Testy obejmują komponenty krytyczne, kontrakty API, przekierowania, metadane i główne ścieżki użytkownika. Zespół klienta otrzymuje środowisko podglądu dla zmian treści. Lokalna społeczność, w tym WordPress Leeds meetup, może być dobrym miejscem do poznania praktyk i specjalistów, ale decyzje projektowe opieramy na audycie konkretnego systemu.

Przed publikacją przechodzimy próbę przełączenia. Runbook opisuje kolejność zmian, właścicieli, kanał incydentowy, testy dymne i powrót. Po wdrożeniu rozpoczyna się okno pomiarowe z regularnym raportem różnic względem stanu bazowego. Reagujemy na przyczynę, nie na pojedynczy skok wykresu.

Ostatni etap to przekazanie. Klient otrzymuje repozytorium, dokumentację architektury, mapę przekierowań, konfigurację środowisk opisaną bez sekretów, procedurę publikacji, odtwarzanie kopii i listę obowiązków utrzymaniowych. Sekrety trafiają do uzgodnionego menedżera, a konta pozostają własnością klienta. Zespół w Leeds może dalej rozwijać system samodzielnie, z wybranym partnerem albo z WPPoland, bez technicznej blokady na jednego wykonawcę.