Migracja WordPress do Next.js: SEO i przekierowania 301

Migracja WordPress do Next.js: zakres projektu i ryzyka SEO

Migracja z WordPressa na Next.js jest pojęciem bardzo szerokim, za którym kryją się zupełnie odmienne podejścia do przebudowy serwisu. W pierwszym, bardziej radykalnym wariancie WordPress zostaje całkowicie porzucony na rzecz plików MDX lub innego systemu zarządzania treścią. W drugim, często preferowanym, zachowujemy go w roli headless CMS, wymieniając jedynie warstwę widoku - czyli zmieniamy frontend, a zachowujemy wordpressowy backend. Trzecia ścieżka to natomiast gruntowna rewolucja, podczas której obok samej technologii zmienia się domena, struktura adresów URL oraz całkowity wygląd serwisu. Jak widać, mówiąc o migracji, możemy mieć na myśli różny zakres zadań.

Każdy z wymienionych scenariuszy posiada inne ryzyko:

1. Ta sama domena i te same adresy. Publiczne adresy nadal zwracają 200, więc nie potrzebują przekierowań i tutaj najważniejsza jest zgodność treści, metadanych, statusów HTTP i moment przełączenia hostingu.
2. Ta sama domena, ale nowe ścieżki. Każdy zmieniony adres wymaga decyzji w mapie migracyjnej i zwykle stałego przekierowania do odpowiadającej mu treści.
3. Nowa domena. Oprócz mapowania i przekierowań dochodzi weryfikacja obu domen oraz narzędzie Zmiana adresu w Google Search Console.
4. Headless WordPress. Odpada import do nowego CMS-a, ale pozostają integracja API, podgląd szkiców, pamięć podręczna, webhooki i odtworzenie funkcji motywu oraz wtyczek. Trzeba też zapobiec indeksowaniu dawnej warstwy prezentacji WordPressa pod techniczną domeną lub adresem serwera źródłowego, aby nie utworzyć drugiej publicznej wersji treści.

Ten sam URL oznacza zgodność całego publicznego adresu, a nie tylko samej ścieżki. Przed wdrożeniem sprawdź protokół, nazwę hosta (www lub bez www), wielkość liter, końcowy ukośnik, kodowanie znaków, paginację oraz parametry, które zmieniają treść. Jedną wersję wybierz jako kanoniczną, a pozostałe warianty sprowadź do niej spójnymi przekierowaniami.

W sytuacji, gdy wersja testowa jest dostępna publicznie, zabezpiecz ją uwierzytelnianiem lub ograniczeniem sieciowym. Plik robots.txt steruje skanowaniem, ale nie służy do kontroli dostępu — zablokowany robot nie odczyta również znacznika noindex. W związku z powyższym, nie polegaj na samym robots.txt, jeśli środowisko testowe zawiera poufne dane albo kopię treści z produkcji.

Migracja WordPress do Next.js bez utraty SEO: co trzeba zachować?

Framework Next.js daje bardzo dużą kontrolę nad renderowaniem, pamięcią podręczną i kodem warstwy widoku, ale sam z siebie nie daje automatycznie lepszych Core Web Vitals, większego bezpieczeństwa ani pozycji w SERP. Warto wiedzieć, że prawidłowo zoptymalizowany WordPress może być szybszy od nieprawidłowo zbudowanej aplikacji w Next.js. O wszystkim decyduje prawidłowa implementacja, odpowiednia infrastruktura oraz zachowanie tego, co użytkownik i wyszukiwarka otrzymywali przed migracją.

Same przekierowania to za mało, aby uchronić serwis przed problemami – nie uratują strony, z której nagle zniknęła połowa treści, poprawny link wewnętrzny czy właściwy status indeksacji. Kompleksowa i bezpieczna migracja chroni jednocześnie:

• Znaczenie i kompletność głównej treści.
• Publiczne URL-e i linki prowadzące do serwisu.

• Tytuły, opisy, linki kanoniczne, robots i hreflang.

• Dane strukturalne, autorów i daty publikacji.
• Linkowanie wewnętrzne oraz nawigację.

• Obrazy, pliki do pobrania, kanały RSS lub Atom i inne zasoby.

• Analitykę, formularze i ścieżki konwersji.

Warto pamiętać, że Google może potrzebować kilku tygodni na przetworzenie średniego serwisu, a w dużych witrynach proces może potrwać nawet kilka miesięcy. Co do samej migracji, celujemy i jest to główne założenie, by ograniczyć zmiany niezwiązane z technologią i szybko wykrywać jakiekolwiek odstępstwa.

Audyt SEO przed migracją WordPressa: stan wyjściowy i cele

Zanim rozpoczniesz eksport, zapisz stan, z którym porównasz nową stronę. Sam ogólny wykres ruchu nie wystarczy, ponieważ sezonowość, kampanie i aktualizacje Google mogą zaciemnić obraz.

Stan wyjściowy powinien obejmować:

• Organiczne kliknięcia, wyświetlenia i najważniejsze strony wejścia

• Konwersje z ruchu organicznego, a nie tylko liczbę sesji

• Najważniejsze frazy i grupy podstron
• Liczbę URL-i indeksowanych oraz przyczyny wykluczeń

• Błędy 404, 5xx, przekierowania i statusy linków kanonicznych

• Próbki wyrenderowanego HTML-a, danych strukturalnych i zrzutów kluczowych szablonów

• Wyniki Core Web Vitals i wydajność kluczowych szablonów

• Działanie formularzy, wyszukiwarki, koszyka i innych funkcji biznesowych.

Przed wdrożeniem warto spisać jasne warunki akceptacji, takie jak brak nieplanowanych błędów 404, pełna zgodność kluczowych treści na najważniejszych adresach oraz poprawne rejestrowanie konwersji. Określenie precyzyjnych progów dla błędów 5xx, dopuszczalnego czasu odpowiedzi oraz dopuszczalnych wahań w liczbie stron sprawi, że decyzja o publikacji lub ewentualnym wycofaniu zmian będzie oparta na twardych danych.

Inwentaryzacja URL-i WordPressa przed migracją do Next.js

Raport Skuteczność w Search Console nie jest pełną bazą zaindeksowanych stron, ponieważ pokazuje adresy obecne w dostępnych danych wyszukiwania, a eksport z interfejsu ma limit wierszy. Z kolei mapa witryny również nie wystarczy, bo może nie zawierać starych, osieroconych lub już usuniętych adresów, do których nadal prowadzą linki.

W związku z powyższym, trzeba połączyć co najmniej:

• Eksport publicznych treści i bezpośrednich odnośników z WordPressa.

• Wszystkie mapy witryny.
• Wyniki pełnego skanowania serwisu.

• Raporty Skuteczność, Indeksowanie stron i Linki w Google Search Console.

• Organiczne strony wejścia z analityki.
• Logi serwera z odpowiednio długiego okresu.
• Adresy z linkami zewnętrznymi.

• Istniejące przekierowania w WordPressie, wtyczkach, CDN i konfiguracji serwera.

Uwzględnij nie tylko wpisy i strony, ponieważ musisz też sprawdzić własne typy treści, kategorie, tagi, autorów, paginację, strony załączników, kanały RSS lub Atom, obrazy, PDF-y, warianty językowe i istotne parametry zapytań. Weź też pod uwagę, że w serwisie sezonowym logi z ostatniego miesiąca mogą nie pokazać URL-i odwiedzanych tylko w określonej części roku.

Przed połączeniem danych zrób normalizację nazwy hosta, protokołu oraz sposobu zapisu ścieżek. Pamiętaj jednak, aby zachować oryginalny adres wejściowy — dzięki temu nie zgubisz wariantów wymagających przekierowania i unikniesz kilkukrotnego zliczenia tej samej strony. Osobno oznacz parametry śledzące, parametry wpływające na treść oraz adresy powstałe w wyniku błędnych linków.

Arkusz migracyjny, który będzie kluczowym źródłem danych, powinien zawierać przynajmniej: stary URL, planowany nowy URL, obecną odpowiedź HTTP, decyzję migracyjną, typ treści, ruch, linki zewnętrzne, link kanoniczny, status indeksacji, właściciela oraz wynik testu przed i po wdrożeniu. Mapa adresów jest artefaktem wdrożeniowym, dlatego wersjonuj ją razem z kodem lub konfiguracją infrastruktury.

Mapa przekierowań 301: co zrobić z każdym starym URL-em?

Najbezpieczniej zachować dotychczasową strukturę URL-i, a w sytuacji, kiedy nie jest to możliwe, nie stosuj jednej reguły do całego serwisu:

Jeszcze jedna uwaga: nie kieruj wszystkich usuniętych wpisów na stronę główną ani luźno powiązaną kategorię, ponieważ takie przekierowanie nie tylko nie pomaga użytkownikowi, ale może też zostać potraktowane przez Google jako miękki błąd 404 (soft 404).

Przekierowania 301 i 308 w Next.js: konfiguracja

W Next.js ustawienie permanent: true zwraca kod 308 zamiast klasycznego 301 — przy czym dla robotów Google oba te statusy oznaczają przekierowanie stałe. Różnica leży wyłącznie w protokole HTTP: kod 308 wprost wymusza zachowanie pierwotnej metody żądania. W sytuacji, kiedy specyfika integracji wymaga tradycyjnego kodu 301, możesz go wymusić za pomocą parametru statusCode: 301, pamiętając jednak, aby stosować go rozłącznie i nigdy nie łączyć z flagą permanent.

// next.config.ts
import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  async redirects() {
    return [
      {
        source: '/2024/01/stary-adres',
        destination: '/blog/nowy-adres',
        permanent: true, // Next.js zwróci kod 308, czyli stałe przekierowanie
      },
    ]
  },
}
 
export default nextConfig

Stosuj reguły wzorcowe wyłącznie w sytuacjach, gdy struktura adresów jest w pełni regularna. WordPress potrafi w tym względzie zaskoczyć, wykorzystując własną bazę kategorii, daty w bezpośrednich odnośnikach, końcowe ukośniki, wielojęzyczność czy historycznie zmieniane końcówki adresów. Jedna zbyt szeroka reguła może skierować poprawne adresy URL do nieistniejących celów, a stała odpowiedź zostać zapamiętana przez przeglądarkę lub CDN.

Przy setkach indywidualnych adresów traktuj przekierowania jako wersjonowane dane powiązane z arkuszem migracyjnym i testami. W Next.js 16 dawne middleware.ts nazywa się teraz proxy.ts, ale nie każda mapa powinna trafiać do Proxy. Najpierw użyj prostych reguł redirects(), natomiast większe lub często zmieniane zbiory rozważ w CDN, konfiguracji hostingu albo szybkim magazynie klucz–wartość. Zwróć też uwagę na limity samej platformy wdrożeniowej – na Vercel funkcja redirects() pozwala na zdefiniowanie maksymalnie 1024 reguł. Pamiętaj również, że w trybie eksportu statycznego (output: 'export') Next.js nie obsługuje przekierowań HTTP z redirects() w next.config.ts, nawet jeśli jest to stała lista adresów. Takie przekierowania musi zapewnić serwer, CDN lub platforma hostingowa, która serwuje gotowe pliki.

Sprawdź również zachowanie wariantów z końcowym ukośnikiem, basePath, prefiksami językowymi i parametrami zapytania. Next.js domyślnie przekazuje parametry ze starego adresu do celu reguły, co bywa pożądane dla UTM-ów, ale może niepotrzebnie przenieść parametry techniczne WordPressa. Ustawienia trailingSlash oraz automatyczna normalizacja adresów mogą natomiast utworzyć dodatkowy skok przed właściwym przekierowaniem. Przetestuj rzeczywiste URL-e wejściowe, a nie tylko uproszczone ścieżki z mapy.

Automatyczny test mapy przekierowań

Tę samą mapę wykorzystaj w automatycznych testach, zamiast sprawdzać adresy ręcznie po wdrożeniu. Test powinien zatrzymać automatyczne podążanie za przekierowaniem, aby osobno ocenić pierwszy status i nagłówek Location:

import { describe, expect, it } from 'vitest'
import redirects from './redirects.json'
 
const baseUrl = process.env.TEST_BASE_URL ?? 'http://localhost:3000'
 
describe.each(redirects)('$source', ({ source, destination }) => {
  it('prowadzi bezpośrednio do właściwego celu', async () => {
    const requestUrl = new URL(source, baseUrl)
    const response = await fetch(requestUrl, {
      redirect: 'manual',
    })
 
    expect([301, 308]).toContain(response.status)
 
    const location = response.headers.get('location')
    expect(location).not.toBeNull()
 
    const actualUrl = new URL(location!, requestUrl)
    const expectedUrl = new URL(destination, baseUrl)
 
    // Kontrolujemy protokół, nazwę hosta, ścieżkę i parametry zapytania
    // oraz fragment, jeśli został jawnie podany w nagłówku Location.
    // Test nie odtwarza dziedziczenia fragmentu ze źródłowego URL-a.
    expect(actualUrl.href).toBe(expectedUrl.href)
  })
})

Po sprawdzeniu pierwszego skoku wykonaj drugi test, który przechodzi kolejne odpowiedzi ręcznie, z ustalonym limitem liczby kroków. Dzięki temu wykryjesz pętlę lub dodatkowe przekierowanie, czego pojedyncze wywołanie fetch z automatycznym podążaniem nie pokaże. Końcowa strona powinna zwrócić 200, właściwy adres kanoniczny i oczekiwany fragment treści. Proces opisuję szerzej w artykule o kontroli jakości technicznego SEO.

Fragment źródłowego adresu, np. #sekcja, nie jest wysyłany do serwera. Jeśli odpowiedź przekierowująca nie zawiera fragmentu w nagłówku Location, przeglądarka dziedziczy go ze starego URL-a. Powyższy test sprawdza cel wskazany w nagłówku, ale nie odtwarza tego zachowania. Zachowanie kotwic i obecność odpowiednich elementów na nowej stronie sprawdź osobno w teście przeglądarkowym.

Migracja treści z WordPressa do Next.js: wpisy, metadane i CMS

Eksport post_content obejmuje jedynie fragment danych WordPressa, a pełny zakres zależy od serwisu, ale zwykle zawiera wpisy, strony, własne typy treści, taksonomie, autorów, daty, komentarze, menu, pola niestandardowe i metadane wtyczek SEO. W przypadku WooCommerce dochodzą jeszcze produkty, warianty, kategorie, konta, zamówienia i integracje, co w zasadzie jest osobnym projektem migracyjnym.

Przy korzystaniu z REST API musisz kontrolować liczbę rekordów za pomocą dedykowanych nagłówków X-WP-Total oraz X-WP-TotalPages. WordPress ogranicza parametr per_page do 100 rekordów, więc eksport musi poprawnie obsługiwać paginację. Pamiętaj, że błędu sieci, statusu 429 (Too Many Requests) ani 500 (Internal Server Error) nie wolno uznawać za prawidłowe zakończenie eksportu. Wprowadź mechanizm ponawiania prób z opóźnieniem (backoff), zapisuj identyfikatory pobranych rekordów, a na koniec porównaj ich liczbę w rozbiciu na poszczególne typy.

Jeżeli redakcja publikuje podczas migracji, sam jednorazowy eksport nie daje spójnego obrazu danych. Ustal moment odcięcia, wykonaj eksport przyrostowy po polu modified albo czasowo zamroź publikację. Po imporcie wykonaj uzgodnienie danych: policz rekordy źródłowe i docelowe, wykryj duplikaty, brakujące relacje, niedostępne media oraz elementy odrzucone przez transformację.

Automatyczna konwersja HTML do Markdowna lub MDX jest przydatnym punktem wyjścia, jednak nie zapewnia pełnego odwzorowania treści z edytora Gutenberg. Shortcode’y, formularze, galerie, bloki dynamiczne, pola ACF, elementy z Elementora czy nietypowy HTML wymagają dedykowanych reguł transformacji lub ręcznej interwencji. Oprócz technicznej walidacji składni potrzebny jest też wizualny i merytoryczny audyt reprezentatywnych szablonów oraz najważniejszych podstron generujących największy ruch.

W sytuacji, kiedy treść trafia do MDX, ustal też nowy proces redakcyjny: kto publikuje, jak działa podgląd, planowanie publikacji, korekta, role i historia zmian.

Migracja mediów WordPressa: obrazy, pliki i next/image

Komponent next/image optymalizuje sposób dostarczania grafik, jednak sam w sobie nie jest magazynem plików. Pliki multimedialne mogą pozostać na stabilnym CDN lub dawnej domenie WordPressa, skąd będą obsługiwane jako zdalne źródła. Wtedy trzeba jawnie skonfigurować dozwolone remotePatterns. Alternatywnie można przenieść je do nowego magazynu albo zachować dotychczasową strukturę ścieżek /wp-content/uploads/.

Niezależnie od wariantu:

• Korzystaj z rzeczywistego adresu pliku, a nie pola WordPress guid.

• Zachowaj lub zmapuj strukturę katalogów bez kolizji nazw.

• Przenieś wymiary, alt, podpis, kredyt i powiązanie z treścią.

• Uwzględnij PDF-y, wideo i inne pliki do pobrania.
• Sprawdź warianty rozmiarów używane wcześniej w srcset.

• Przekieruj stare URL-e plików tylko wtedy, gdy ich publiczne adresy naprawdę się zmieniły.

Samo pobranie oryginalnych plików nie wystarczy, jeśli HTML nadal odwołuje się do miniaturek WordPressa albo nowa ścieżka różni się od celu przekierowania.

Techniczne SEO przed wdrożeniem Next.js: lista kontrolna

W App Routerze musisz ustalić jedno źródło prawdy dla wszystkich metadanych. Skonfiguruj metadataBase w głównym układzie (layout), a dla dynamicznych wpisów generuj tytuł, opis, adres kanoniczny i alternatywne wersje językowe przez generateMetadata. Z kolei mapę witryny i reguły dla robotów możesz wystawić przez sitemap.ts oraz robots.ts. Finalnie sprawdź wynik w HTML-u odpowiedzi, ponieważ metadane dodawane dopiero przez efekt w komponencie klienckim nie powinny być podstawą technicznego SEO.

• Każdy URL z inwentaryzacji ma oczekiwany status: 200, 301/308, 404 albo 410.

• Przekierowania prowadzą do trafnych, końcowych celów bez pętli i łańcuchów.

• Nowa mapa witryny zawiera wyłącznie kanoniczne, indeksowalne URL-e zwracające 200.

• Linki wewnętrzne prowadzą bezpośrednio do nowych URL-i, a nie przez przekierowania.

• Tytuł strony, opis meta, link kanoniczny, dyrektywy robots, Open Graph i hreflang są poprawne.

• Główna treść, nagłówki, autorzy i daty odpowiadają zaakceptowanej migracji.

• Dane uporządkowane Schema.org w formacie JSON-LD są zgodne z widoczną treścią i przechodzą testy.

• Obrazy, PDF-y, kanały RSS lub Atom i pozostałe zasoby są dostępne.

• Formularze, wyszukiwarka, analityka, zgody i konwersje działają.

• Produkcyjny robots.txt i reguły noindex nie blokują ważnych ścieżek.

• Google Search Console pozostanie zweryfikowane po zmianie hostingu.

• Odpowiedź serwera zawiera właściwą treść i metadane bez oczekiwania na kod uruchamiany wyłącznie w przeglądarce.

Zadbaj o testy priorytetowych stron oraz próbek z poszczególnych szablonów. Sam kod HTTP to za mało, by wyłapać błędy renderowania czy problemy z działaniem elementów witryny. Porównuj zarówno źródłowy HTML odpowiedzi, jak i DOM po wykonaniu JavaScriptu, ponieważ to pozwala wykryć rozbieżności w renderowaniu, hydracji i metadanych.

Przełączenie hostingu i domeny: DNS, przekierowania i plan wycofania

Przepięcie domeny na nowy hosting nie jest przekierowaniem 301/302. DNS po prostu kieruje ruch do nowej infrastruktury, a za wysłanie właściwego kodu odpowiedzi HTTP odpowiada CDN, serwer lub aplikacja.

Przed wdrożeniem:

1. Obniż TTL rekordów DNS z wyprzedzeniem, jeśli zmieniasz hosting.
2. Ustal krótkie zamrożenie publikacji albo sposób synchronizacji zmian powstałych po eksporcie.
3. Przygotuj kopię zapasową, właściciela decyzji, instrukcję wycofania oraz konkretne progi, które je uruchamiają.
4. Włącz przekierowania najpóźniej w momencie skierowania ruchu na nową wersję.
5. Usuń produkcyjne noindex i blokady używane w środowisku testowym.
6. Sprawdź dostępność z zewnątrz, CDN, firewall, pamięć podręczną i wydajność serwera.
7. Pozostaw dostęp do starej infrastruktury i logów do czasu potwierdzenia poprawnego przełączenia.

Stałe przekierowania mogą zostać zapamiętane przez przeglądarkę lub CDN, dlatego plan wycofania musisz przetestować przed uruchomieniem ich na produkcji. Na środowisku testowym możesz najpierw zweryfikować mapę kodem tymczasowym, ale w momencie właściwej migracji adresów włącz przekierowania stałe. Pamiętaj też, że wycofanie aplikacji i wycofanie mapy adresów to dwie osobne operacje i musisz określić, czy stara wersja potrafi obsłużyć nowe ścieżki i co stanie się z treściami opublikowanymi po przełączeniu.

Gdy zmienia się domena, stara domena musi nadal działać, utrzymywać ważny certyfikat TLS i obsługiwać przekierowania. Dopiero wtedy użyj narzędzia Zmiana adresu w Search Console. Zweryfikuj wszystkie warianty starej i nowej domeny, a dla każdego zweryfikowanego wariantu starego hosta i każdej subdomeny wyślij osobne zgłoszenie — także wtedy, gdy dany wariant nie był aktywnie używany. Narzędzia nie stosuje się do samej zmiany ścieżek, migracji HTTP do HTTPS, przejścia między www i wersją bez www w tej samej domenie ani zmiany hostingu przy zachowanych URL-ach.

Monitorowanie SEO po migracji: Search Console, logi i konwersje

Pierwsza kontrola powinna nastąpić bezpośrednio po wdrożeniu, wtedy sprawdź kluczowe URL-e, logowanie analityki, konwersje i błędy serwera. Potem, w kolejnych dniach, monitoruj nowe 404, 5xx, pętle przekierowań, zachowanie Googlebota oraz różnice w treści. W Search Console przede wszystkim musisz obserwować:

• Indeksowanie stron i przyczyny wykluczeń,
• Statystyki indeksowania,
• Mapy witryn,
• Skuteczność z podziałem na strony i typy wyszukiwania,
• Sprawdzanie adresu URL dla reprezentatywnych przypadków,
• dane dla starej i nowej domeny, jeżeli domena się zmieniła.

Planując migrację adresów URL, stwórz dwa stałe zestawienia: bazową listę starych adresów oraz docelową listę ich nowych, kanonicznych odpowiedników. Starą zachowaj jako dane do testów i monitorowania, natomiast w Search Console zgłoś nową mapę witryny zawierającą wyłącznie kanoniczne adresy zwracające 200. Po rozpoczęciu migracji starą mapę witryny można usunąć z Search Console; stan dawnych URL-i kontroluj za pomocą arkusza migracyjnego, raportów indeksowania, inspekcji adresów i logów serwera.

Ruch oceniaj w podziale na konkretne grupy stron oraz konwersje, zestawiając analogiczne okresy i uwzględniając sezonowość. Jeden zbiorczy wykres może zamaskować poważny problem dotyczący tylko wybranego szablonu podstron. Oznacz w analityce dokładny moment wdrożenia i zapisuj wszystkie późniejsze poprawki, aby odróżnić efekt migracji od kolejnych zmian. Stałe przekierowania utrzymuj co najmniej rok, a jeśli stare linki nadal generują ruch, najlepiej na zawsze. Intensywne monitorowanie może trwać kilka tygodni, ale kontrola mapy przekierowań i starych linków zewnętrznych powinna pozostać stałym elementem kontroli jakości.

Po przełączeniu zaktualizuj także najważniejsze linki, nad którymi masz kontrolę, czyli mam tu na myśli profile firmy, wizytówki, kampanie reklamowe, newslettery i integracje partnerskie. W przypadku wartościowych linków zewnętrznych generujących dużo wejść warto, jeśli to możliwe, poprosić wydawcę o zmianę linkowania. Przekierowanie oczywiście pozostaje zabezpieczeniem, ale bezpośredni link skraca ścieżkę użytkownika i zmniejsza obciążenie starej infrastruktury.

Błędy SEO przy migracji WordPress do Next.js

1. Zgubione dane Yoast lub RankMath. Tytuł, opis meta, dyrektywy robots i dane uporządkowane mogą znajdować się poza post_content.
2. Zbyt szerokie reguły wzorcowe. Historyczne końcówki adresów, języki, parametry i końcowe ukośniki mogą trafić do błędnego celu mimo pozornie regularnej struktury.
3. Kilka niespójnych warstw przekierowań. Reguły pozostawione jednocześnie w WordPressie, CDN, hostingu i Next.js łatwo tworzą pętle albo łańcuchy niewidoczne w jednej konfiguracji.
4. Zablokowana produkcja. Reguły noindex, robots.txt, firewall albo ochrona środowiska testowego pozostają aktywne po przełączeniu.
5. Brak kontroli funkcji biznesowych. Ruch może wyglądać poprawnie, mimo że formularze lub pomiar konwersji nie działają.
6. Testowanie wyłącznie w przeglądarce. Poprawny DOM po wykonaniu JavaScriptu może ukrywać pusty HTML, błędny status HTTP albo metadane niewidoczne w odpowiedzi serwera.

Pamiętaj, że migracja z WordPressa do Next.js ma sens przy projektach z dużą interaktywnością, niestandardowym interfejsem lub integracjami, które uzasadniają koszt nowej architektury. W wypadku blogów i stron opartych na treści, gdzie celem jest głównie szybkość i niski koszt utrzymania, podobne zasady SEO stosuje się przy przejściu na Astro, co opisuję w artykule o migracji bloga z WordPressa na Astro.