Migracja z WordPressa na Next.js to jedna z tych operacji, która potrafi podwoić ruch albo go zabić, zależnie od wykonania. Różnica leży w dyscyplinie przekierowań i danych strukturalnych. Oto plan, po którym pracowaliśmy przy ostatnich migracjach.
Etap 1: inwentaryzacja adresów URL
Zanim cokolwiek ruszy: pełna lista adresów z WordPressa (posty, strony, kategorie, tagi, autorzy, pliki). Źródła: sitemap, Search Console, eksport bazy. Bez tej listy nie ma bezpiecznej migracji, bo nie wiesz, co masz zmapować.
Etap 2: mapa przekierowań 301
Każdy stary adres dostaje nowy albo conscious 410, jeśli treść znika. Największy błąd migracji to allow 404 na podstronach z ruchem. Mapę przekierowań wdrażamy na poziomie hostingu, nie skryptu w stronie, żeby działała natychmiast.
Etap 3: treść i dane strukturalne w Next.js
Wszystkie meta title, description, canonical, Open Graph i dane strukturalne JSON-LD przenoszone są 1:1 albo świadomie poprawiane. Next.js Metadata API potrafi to załatwić per strona, przy setkach podstron generuje się z danych w headless CMS.
Etap 4: testy przed zmianą DNS
- Renderowanie po stronie serwera dla botów: pobierz stronę jako Googlebot i sprawdź treść w HTML.
- Sitemap nowa, robots zaktualizowany, przekierowania przetestowane na środowisku podglądowym.
- Analityka i zdarzenia konwersji działają na nowej wersji.
Etap 5: przełączenie i monitoring
Zmiana DNS, monitorowanie Search Console przez 30 dni: indeksowanie, błędy crawlowania, pozycje. Pierwsze dwa tygodnie nie ruszamy niczego dużego, żeby nie zaciemniać obrazu.
Kiedy migracja ma sens
Gdy WordPress przestaje wystarczać: nietypowe funkcje, duży ruch, rozwój w stronę aplikacji. Wtedy zapraszamy do wdrożeń Next.js. Jeśli powodem jest tylko „wolna strona”, zwykle taniej wychodzi optymalizacja WordPressa, o czym piszemy w porównaniu WordPress vs Next.js. Masz wątpliwości, którą drogę wybrać? Napisz, rozeźlimy to na audycie.