Migracja Next.js / Astro w Rzeszowie

Rzeszów liczy 199 604 mieszkańców (dane GUS z 30 czerwca 2026 r. za Wikipedią) i od 1 stycznia 1999 r. jest stolicą województwa podkarpackiego. Działają tu Uniwersytet Rzeszowski i Politechnika Rzeszowska, a w okolicy skupia się przemysł lotniczy. Stowarzyszenie Dolina Lotnicza zrzeszało w listopadzie 2025 r. 212 podmiotów, w większości z Rzeszowa, Mielca, Sędziszowa Małopolskiego, Krosna i Świdnika. Ta strona opisuje, jak prowadzę migrację firmowej witryny z WordPressa, Joomli, Drupala lub starego frameworku do Astro albo Next.js, tak żeby nie stracić ruchu z wyszukiwarki.

#Kiedy migracja do Astro lub Next.js ma sens?

Ma sens, gdy obecny system ogranicza wydajność, bezpieczeństwo albo pracę redakcji, a porządki we wtyczkach i cache nie wystarczają. Typowe objawy to wolny panel, aktualizacje bez środowiska testowego, kilkanaście wtyczek o niejasnym właścicielu i czas ładowania, którego nie da się obniżyć bez zmiany architektury. Jeśli problem leży w jednej wtyczce albo w hostingu, taniej go naprawić na miejscu i tego nie przepisuję.

Astro wybieram dla stron firmowych, katalogów usług i blogów: strona jest generowana z góry, a JavaScript trafia do przeglądarki tylko tam, gdzie jest potrzebny. Next.js wybieram, gdy dochodzą logowanie, panel klienta, konfiguratory albo dużo renderowania po stronie serwera. Więcej o samej usłudze piszę w migracji do Astro i Next.js oraz na stronie o programiście Astro.

#Jak wygląda migracja krok po kroku?

Inwentaryzacja adresów. Zbieram URL-e z mapy witryny, z crawla całego serwisu, z Search Console i z logów serwera. Same sitemapy nie wystarczą, bo pomijają strony, które nadal zbierają ruch albo linki zewnętrzne. Do listy dochodzą adresy mediów z /wp-content/uploads/, paginacje, kategorie, tagi, strony autorów, kanały RSS i strony załączników.

Mapa przekierowań. Dla każdego starego adresu zapisuję w arkuszu decyzję: ten sam adres, nowy adres z jednym przekierowaniem 301 albo celowe usunięcie. Łańcuchy przekierowań wycinam, bo każdy dodatkowy skok opóźnia crawl. Osobno sprawdzam wielkość liter, ukośnik na końcu adresu i parametry zapytania, bo te trzy rzeczy najczęściej rozjeżdżają się między starym serwerem a nowym.

Model treści. Wpisy, strony i pola własne przenoszę do kolekcji treści ze schematem walidowanym przy buildzie. Brakujące pole, na przykład opis meta, zatrzymuje build zamiast trafić na produkcję jako pusty tag. Treść z WordPressa wyciągam przez REST API (/wp-json/wp/v2/) albo z eksportu bazy, a potem czyszczę z shortcode’ów i bloków, które nie mają odpowiednika w nowym froncie.

Dane strukturalne, canonical, hreflang. Przenoszę je razem z treścią i porównuję wyrenderowany HTML starej i nowej wersji: title, description, canonical, robots, nagłówki, JSON-LD. Jeśli serwis ma wersje językowe, każda para wersji musi wskazywać się nawzajem, inaczej Google ignoruje adnotacje. Dotyczy to na przykład katalogów produktowych firm, które sprzedają poza Polską.

Formularze i integracje. Formularz kontaktowy, newsletter, mapy, wideo i skrypty analityczne wymagają osobnego rozwiązania, bo strona zbudowana do HTML nie uruchamia PHP. Zastępuję je endpointem lub usługą zewnętrzną i testuję dostarczanie wiadomości, a nie tylko wygląd.

Wdrożenie etapowe. Nowa wersja działa najpierw na adresie testowym zamkniętym przed indeksacją. Przed przełączeniem skracam TTL w DNS, żeby ewentualny powrót trwał minuty. Na małych serwisach przełączam całość naraz, na większych sekcjami, zaczynając od mniej ważnych.

#Co sprawdzam po starcie w Search Console?

W pierwszych tygodniach sprawdzam, czy nowa mapa witryny została przetworzona, czy liczba stron zindeksowanych zbliża się do liczby adresów mapie i czy w raporcie stron nie pojawiają się nowe błędy 404, przekierowania ani wykluczenia przez noindex. Przeglądam też logi pod kątem adresów, które nadal odbierają ruch, a nie są w mojej mapie. Wydajność mierzę według Core Web Vitals (opis metryk: web.dev/articles/vitals), na danych terenowych, nie tylko w teście laboratoryjnym.

Co może pójść źle: pominięty adres z ruchem, przekierowanie na stronę główną zamiast na odpowiednik treści (Google traktuje to jak błąd miękki), pozostawiony na produkcji noindex z wersji testowej, zmiana struktury nagłówków lub linkowania wewnętrznego, która odbiera stronom sygnały. Każdy z tych przypadków da się wykryć porównaniem crawla przed i po, dlatego robię je przed przełączeniem i po nim.

#Jakie wymagania prawne dotyczą strony firmowej w Rzeszowie?

Dane osobowe zbierane przez formularze, analitykę i skrypty zewnętrzne podlegają RODO, a skargi i zgłoszenia naruszeń przyjmuje Urząd Ochrony Danych Osobowych. W migracji oznacza to inwentaryzację wszystkich skryptów ładowanych na stronie, sprawdzenie, które ustawiają pliki cookie lub wysyłają dane do dostawców, i przeniesienie baneru zgody tak, żeby skrypty nie startowały przed zgodą. Hosting wybieram z uwzględnieniem lokalizacji danych w UE.

Jeśli strona należy do podmiotu publicznego, obowiązuje ją ustawa z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848). Przy takiej migracji dostępność jest wymaganiem, a nie dodatkiem: kontrast, nawigacja klawiaturą, opisy obrazków i deklaracja dostępności muszą przejść do nowej wersji. Przy stronach firm prywatnych ta ustawa nie ma zastosowania wprost, a dobre praktyki dostępności i tak ułatwiają pracę z treścią.

#Co jest specyficzne dla firm z Rzeszowa i Podkarpacia?

Rzeszowska gospodarka ma wyraźny sektor lotniczy. Wikipedia podaje m.in. Pratt & Whitney Rzeszów (dawniej WSK PZL-Rzeszów) i międzynarodowy port lotniczy w Jasionce. Dla dostawców i podwykonawców takiej branży strona jest często pierwszym punktem kontaktu z odbiorcą z zagranicy, więc liczą się czytelne wersje językowe, poprawny hreflang, szybkie ładowanie dokumentacji technicznej i przejrzysty katalog kompetencji. Nie podaję tu liczb o ruchu czy konwersji w tej branży, bo nie mam na nie źródła.

Środowisko akademickie (Uniwersytet Rzeszowski i Politechnika Rzeszowska) oznacza też lokalny rynek informatyków, ale to nie zmienia samej migracji: przekazuję repozytorium, zmienne środowiskowe i pipeline wdrożeniowy, żeby Twój zespół albo dowolny inny wykonawca mógł dalej pracować.

#Strona dostawcy z branży lotniczej jako dokument kompetencji

Skoro w Rzeszowie i okolicy skupia się przemysł lotniczy, wśród firm, które do mnie piszą, mogą być podwykonawcy i dostawcy usług dla tej branży. Ich strona rzadko służy do sprzedaży detalicznej. Czyta ją inżynier albo zakupowiec, który sprawdza, czy firma ma park maszynowy, procesy i dokumenty potrzebne do współpracy. Oparcie strony na tym założeniu zmienia sposób, w jaki projektuję migrację.

Kompetencje jako uporządkowane dane. Technologie obróbki, materiały, wielkości serii, branże obsługiwane i posiadane certyfikaty trzymam w kolekcji treści ze schematem. Każda pozycja ma ten sam zestaw pól, a lista na stronie głównej, filtry i dane strukturalne pochodzą z jednego źródła. Certyfikaty wpisuję tylko te, które firma faktycznie posiada i może udokumentować. Nie dopisuję żadnych standardów branżowych “dla wiarygodności”.

Karty techniczne i dokumenty do pobrania. Pliki PDF mają stałe, czytelne adresy i nie znikają przy zmianie wykonawcy. Przy migracji sprawdzam, które pliki są linkowane z zewnątrz, na przykład z portali dostawców lub dokumentów partnerów, i zachowuję ich adresy albo ustawiam przekierowania 301. Zła ścieżka do karty technicznej, na którą odwołuje się cudza dokumentacja, to utracony sygnał i niezadowolony odbiorca.

Zapytania ofertowe bez ujawniania wrażliwych informacji. Formularz zapytania nie powinien prosić o rysunki objęte umową o poufności. Jeżeli przesyłanie takich plików jest potrzebne, projektuję osobny, chroniony kanał, a nie zwykły upload do publicznego katalogu. Co mogę zapewnić po stronie frontendu: walidację typów plików, ograniczenie rozmiaru, ochronę przed spamem i potwierdzenie dla nadawcy. Ocena, jakie dane wolno przesyłać, należy do Ciebie.

Wersje językowe dla odbiorców zagranicznych. Odbiorca z zagranicy zwykle wchodzi z wyszukiwarki w swoim języku. Dlatego każda wersja ma własny adres, własny tytuł i własny opis, a hreflang wskazuje pary wzajemnie. Treść techniczną tłumaczy osoba znająca terminologię, bo automatyczny przekład błędnie oddaje nazwy procesów i norm.

#Jak wygląda mapa adresów serwisie technicznym

Serwisy firm przemysłowych mają zwykle inną historię adresów niż strony usługowe. Przez lata powstają podstrony technologii, realizacji, aktualności i dokumenty, a każdy zmieniający się wykonawca zmieniał też strukturę katalogów. Dlatego przy takim serwisie zaczynam od tabeli, w której każdy stary adres ma status i uzasadnienie.

Adresy kart technicznych i stron technologii zachowuję bez zmian, jeśli tylko nowa struktura na to pozwala, bo mogą mieć linki z zewnątrz. Aktualności sprzed lat, które nikomu już nie służą, nie muszą zostać przeniesione, ale nie kieruję ich zbiorczo na stronę główną. Jeżeli odpowiednika nie ma, zwracam kod oznaczający, że treść została usunięta. Jeśli odpowiednik jest, ustawiam jedno przekierowanie 301 na najbliższą tematycznie stronę.

Przed przełączeniem uruchamiam skrypt, który przechodzi całą mapę, sprawdza kod odpowiedzi każdego adresu i wykrywa pętle oraz łańcuchy. Drugi skrypt porównuje wyrenderowany HTML starej i nowej wersji dla próbki stron: tytuł, opis, canonical, robots, nagłówki i JSON-LD. Raport z obu trafia do Ciebie przed zmianą DNS, razem z listą różnic, które uznałem za świadome.

Blog techniczny lub dział aktualności traktuję osobno, bo ma własną paginację, kategorie i tagi. Archiwa z niską wartością, na przykład tagi z jednym wpisem, mogę wyłączyć z indeksu, ale decyzję podejmuję na podstawie danych z Search Console, a nie na podstawie domysłu, które archiwa są nieużyteczne.

#Strona uczelni, koła naukowego lub spółki akademickiej

Uniwersytet Rzeszowski i Politechnika Rzeszowska to jednostki, wokół których powstają projekty badawcze, koła naukowe i firmy założone przez absolwentów. Ich strony mają cechę wspólną: wielu autorów treści, którzy zmieniają się co kilka lat, bo kończą studia albo projekt. Stary WordPress z dziesiątkami kont, niejasnymi rolami i pluginami zainstalowanymi przez osoby, których już nie ma, to typowy obraz takiej witryny.

W takim przypadku proponuję dwa warianty. Pierwszy to zachowanie WordPressa jako panelu redakcyjnego z kontami imiennymi, jasnymi rolami i frontendem w Astro, który nie ujawnia panelu publicznie. Drugi to treść w plikach Markdown w repozytorium, gdzie każda zmiana ma autora, datę i możliwość cofnięcia. Pierwszy wariant jest wygodniejszy dla osób nietechnicznych, drugi daje pełną historię i prostsze utrzymanie. Wybór zależy od tego, kto będzie publikował za rok, a nie od moich preferencji.

Jeżeli strona należy do jednostki publicznej, w tym uczelni publicznej, stosuje się ustawa z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848), o której piszę wyżej. Przy migracji przenoszę deklarację dostępności, sprawdzam kontrast, kolejność fokusu, opisy obrazków i dostępność dokumentów do pobrania. Zakres obowiązków konkretnej jednostki potwierdza jej inspektor lub prawnik, ja dostarczam wyniki testów technicznych.

#Rytm roku akademickiego a termin migracji

Rzeszów jest miastem akademickim, więc dla części firm ruch zmienia się z kalendarzem uczelni. Dotyczy to na przykład wynajmu pokoi, korepetycji, szkół językowych, gastronomii, usług drukarskich czy punktów przy kampusie. Dane o tym, jak wygląda ten rytm w Twoim biznesie, znajdziesz w Search Console: porównaj zapytania z początku i końca semestru oraz z okresu wakacji.

Przełączenia nie planuję na początku roku akademickiego ani w okresie rekrutacji, jeśli to wtedy przychodzi najwięcej zapytań. Wolę zrobić je w miesiącu, w którym ruch jest mniejszy, a zespół ma czas sprawdzić nową wersję. Dla jednostek uczelnianych dochodzi jeszcze zasada, żeby nie zmieniać adresów stron, na które kierują materiały rekrutacyjne i dokumenty w obiegu. Takie adresy zachowuję bez zmian albo zostawiam przekierowania na wiele lat.

#Strona kariery w firmie z korytarza IT

Rzeszów ma lokalne środowisko informatyczne i firmy technologiczne, które rekrutują. Dla takiej firmy strona kariery bywa najważniejszą częścią serwisu. Przy migracji zwracam uwagę na kilka rzeczy.

Oferty pracy jako dane strukturalne. Każda oferta ma tytuł, opis, lokalizację, tryb pracy, datę publikacji i datę ważności. Dane z tego samego źródła zasilają listę ofert, stronę pojedynczej oferty i znacznik JobPosting w JSON-LD. Wygasłe oferty nie powinny wisieć w indeksie jako aktywne, więc po dacie ważności strona zwraca odpowiedni status albo prowadzi do listy aktualnych ofert.

Integracja z systemem rekrutacyjnym. Jeżeli firma używa zewnętrznego ATS, frontend pobiera z niego oferty i przekazuje kandydata do formularza dostawcy. Nie przechowuję zgłoszeń w statycznym buildzie ani w repozytorium.

Dane kandydatów. Kodeks pracy ogranicza zakres danych, których pracodawca może żądać od osoby ubiegającej się o zatrudnienie (art. 22 indeks 1), a RODO nakłada obowiązki informacyjne i dotyczące przechowywania. Formularz powinien zbierać tylko to, co jest potrzebne na etapie rekrutacji, z klauzulą informacyjną i zgodą na dalszy proces tam, gdzie jest wymagana. Treść klauzul zatwierdza Twój inspektor ochrony danych lub prawnik. Ja odpowiadam za to, żeby po migracji klauzula nie zniknęła z formularza.

#Hosting, dane w UE i dostęp wykonawcy

Przy firmach z Rzeszowa, które współpracują z zagranicznymi odbiorcami, pytanie o lokalizację danych wraca na każdym wstępnym spotkaniu. Odpowiadam na nie przez spis: gdzie działa hosting frontendu, gdzie CMS, gdzie baza, kto obsługuje pocztę transakcyjną, analitykę i kopie zapasowe. Dla każdej usługi zapisuję region i dostawcę. Nie zakładam, że wybranie centrum danych w UE oznacza, że wszystkie usługi pomocnicze też tam działają.

Mój dostęp do Twoich środowisk dokumentuję: konta imienne, najmniejsze potrzebne uprawnienia, uwierzytelnianie wieloskładnikowe, a po zakończeniu projektu cofnięcie dostępu. To element odbioru, nie dodatek.

#Kiedy nie warto migrować

Jeśli Twoja strona jest wolna z powodu jednej ciężkiej wtyczki lub słabego hostingu, wymiana frameworka nie jest najtańszą ścieżką. Zaproponuję wtedy poprawki w obecnym systemie. Nie przepisuję też serwisów, w których nie wiadomo, kto odpowiada za treść: nowy frontend przeniesie ten sam bałagan, tylko szybciej.

Migracja nie ma sensu, gdy po odbiorze nikt nie utrzyma zależności i procesu budowania. Astro i Next.js wymagają aktualizacji tak samo jak każdy inny stos. Przed startem ustalamy, czy robi to Twój zespół, czy zewnętrzny partner, i spisuję to w dokumentacji przekazania.

#Przekazanie projektu i utrzymanie

Po zakończeniu pracy dostajesz repozytorium, opis architektury, mapę przekierowań w czytelnym pliku, listę zmiennych środowiskowych bez wartości sekretnych i instrukcję publikowania zmian. Konta usług zostają Twoje. Okno obserwacji po starcie obejmuje raport stron w Search Console, błędy 404, dane Core Web Vitals i kluczowe konwersje, a wnioski wyciągam po kilku tygodniach, bo dane terenowe aktualizują się z opóźnieniem.

#Co wysłać, żebym przygotował pisemny zakres?

Wyślij adres obecnej strony, nazwę i wersję CMS-a, listę wtyczek, źródła ruchu (Search Console, analityka), informację o wersjach językowych oraz o formularzach i sklepie. Odpowiem opisem prac, ryzyk i założeń. Wycena zależy od liczby adresów, złożoności modelu treści i integracji, dlatego podaję ją dopiero po obejrzeniu strony.