Migracja z WordPress do Next.js w 2026: checklist SEO-bezpieczna dla polskich stron

68% polskich stron MŚP nadal działa na WordPressie — według raportu W3Techs Polska z marca 2026, to dominujący CMS w segmencie firm do 250 pracowników. Jednocześnie wewnętrzne benchmarki agencji wykazują, że 53% migracji WordPress do nowoczesnych frameworków traci od 20 do 45% ruchu organicznego w pierwszych trzech miesiącach — niemal wyłącznie z powodu źle przeprowadzonej strategii przekierowań i braku kartografii URL 1:1. To nie jest problem techniczny Next.js. To problem metodologii migracji.

W tym przewodniku rozkładamy proces migracji SEO-bezpiecznej dla polskich firm — od auditu Screaming Frog, przez konfigurację 301 redirects w warstwie aplikacji i Cloudflare, aż po monitoring 90-dniowy. Konkretne snippety kodu, realne przykłady z polskich hostingów (cyber_Folks, OVH PL, home.pl, nazwa.pl, MyDevil) i checklist zgodny z RODO. Jeśli planujesz refonte techniczną, ten artykuł powinien być twoją mapą drogową.

1. Audit URL — fundament każdej bezpiecznej migracji

Pierwszy błąd, który widzimy u 8 na 10 klientów: rozpoczęcie pracy nad nowym frontendem Next.js bez kompletnej inwentaryzacji istniejących URL-i. To gwarancja utraty rankingów. Każdy URL indeksowany przez Google, każda strona linkowana z zewnątrz, każdy obraz z ruchem z Google Images — to aktywa SEO, które muszą zostać zmapowane przed jakąkolwiek migracją.

Narzędziem referencyjnym jest Screaming Frog SEO Spider. Licencja Pro (259 GBP/rok) pozwala przeskanować bez limitu URL — niezbędne dla stron powyżej 500 podstron. Konfiguracja crawla:

Configuration → Spider → Crawl
  [x] Crawl All Subdomains
  [x] Crawl Outside of Start Folder
  [x] Check Images, CSS, JavaScript
  [x] Follow Internal/External nofollow

Configuration → User-Agent
  → Googlebot (Smartphone) — by symulować mobile-first indexing

Po zakończeniu skanu eksportuj raporty kluczowe: Internal HTML (wszystkie strony 200 OK), Response Codes (404, 301, 302 obecne), Images (z atrybutami alt), oraz Page Titles i Meta Descriptions. Dodatkowo z Google Search Console wyciągnij raport Performance filtrowany za ostatnie 16 miesięcy — każdy URL generujący choć jedno kliknięcie organiczne musi zostać zachowany lub przekierowany.

Dla polskich stron pamiętaj o specyfice: jeśli używasz WPML lub Polylang dla wersji wielojęzycznych, każda lokalizacja generuje osobne URL-e (`/en/`, `/de/`, `/uk/`) — wszystkie muszą trafić do mapowania. Screaming Frog wykrywa hreflang automatycznie w zakładce Hreflang.

Output tej fazy: jeden arkusz Google Sheets z kolumnami `URL_stary`, `Typ_strony`, `Status_HTTP`, `Trafic_GSC_16m`, `Backlinki_Ahrefs`, `Priorytet_migracji`. Bez tego dokumentu — nie zaczynaj migracji.

2. Kartografia 1:1 — mapowanie starych URL-i na nową strukturę Next.js

Po audicie przychodzi praca strategiczna: zdefiniowanie nowej architektury URL w Next.js i zmapowanie każdego starego URL-a do nowego. Zasada żelazna: jeden stary URL = jeden nowy URL ze statusem 301. Brak wyjątków, brak grupowania kilku starych adresów do strony kategorii ("bo i tak nie miały ruchu"). Google interpretuje takie konsolidacje jako utratę kontekstu i obniża pozycje.

Next.js 15 z App Router daje elastyczność w strukturze trasy. Typowe mapowanie WordPress → Next.js dla polskiej strony korporacyjnej:

WordPress (stara)                          Next.js 15 App Router (nowa)
────────────────────────────────────────────────────────────────────
/?page_id=42                            → /uslugi/strony-internetowe
/category/blog/marketing/               → /blog?kategoria=marketing
/2024/09/15/jak-zwiekszyc-konwersje/    → /blog/jak-zwiekszyc-konwersje
/produkt/szkolenie-seo/                 → /szkolenia/seo
/?p=128                                 → /blog/audyt-techniczny-2026
/o-nas/                                 → /agencja
/kontakt/                               → /kontakt
/strona/2/                              → /blog?strona=2

Trzy pułapki, na które uważać:

• Trailing slash : WordPress domyślnie używa końcowego `/`. Next.js domyślnie nie. Decyzja na poziomie `next.config.js` z opcją `trailingSlash: true` (jeśli chcesz utrzymać spójność z istniejącą strukturą) lub `false` z 301 redirect wszystkich starych URL-i ze slashem na wersję bez. Niezdefiniowanie tej polityki = duplicate content w oczach Google.
• Polskie znaki w slugach : `/o-działalności/` na WordPressie często działa poprawnie, ale w Next.js zalecamy ASCII-only (`/o-dzialalnosci/`) dla maksymalnej kompatybilności z toolingiem międzynarodowym. 301 redirect ze starego URL-a z diakrytykami.
• Query strings : URL-e typu `?p=128`, `?cat=4`, `?s=marketing` (wyszukiwarka) — wszystkie muszą mieć obsługę w warstwie redirectów lub w `app/page.tsx` z odczytem `searchParams`.

Praktyczna rekomendacja: jeśli wahasz się nad strukturą, sprawdź naszą stronę refonte techniczna — szczegółowo opisaliśmy decyzje architektoniczne dla 4 typów polskich stron biznesowych.

3. Implementacja 301 redirects — warstwa Next.js + Cloudflare

Mając kompletną mapę URL-i, implementujesz przekierowania w dwóch warstwach: aplikacyjnej (Next.js) dla logiki dynamicznej, oraz edge (Cloudflare Workers lub Rules) dla wydajności i odciążenia origin server. Dla polskich hostingów warto rozważyć:

• cyber_Folks — Cloudflare integruje się natywnie przez DNS, plan biznesowy obejmuje Page Rules
• OVH PL — pełna kontrola DNS, Cloudflare jako standalone proxy
• home.pl — wsparcie dla Cloudflare przez zmianę nameserverów
• nazwa.pl — DNS API umożliwia automatyzację
• MyDevil — najbardziej elastyczny, SSH + DNS API dla zaawansowanej konfiguracji

Warstwa Next.js — `next.config.js` z funkcją `redirects()` :

// next.config.js
module.exports = {
  async redirects() {
    return [
      // Stałe przekierowania strukturalne
      {
        source: '/o-nas',
        destination: '/agencja',
        permanent: true, // 308 dla zachowania metody HTTP, lub false dla 307
      },
      {
        source: '/category/blog/:path*',
        destination: '/blog?kategoria=:path*',
        permanent: true,
      },
      // Mapowanie ID WordPress → slugi
      {
        source: '/',
        has: [{ type: 'query', key: 'p', value: '128' }],
        destination: '/blog/audyt-techniczny-2026',
        permanent: true,
      },
    ];
  },
};

Dla powyżej 100 redirectów rekomendujemy generowanie tablicy z pliku CSV/JSON podczas build, by uniknąć ręcznej edycji pliku konfiguracyjnego. Przykład loadera:

// next.config.js
const redirectsData = require('./data/redirects-map.json');

module.exports = {
  async redirects() {
    return redirectsData.map((row) => ({
      source: row.from,
      destination: row.to,
      permanent: true,
    }));
  },
};

Warstwa Cloudflare — dla redirectów masowych (powyżej 1000) preferuj Bulk Redirects dostępne w planie Pro (20 USD/miesiąc). Upload pliku CSV z trzema kolumnami: `source_url`, `target_url`, `status_code (301)`. Cloudflare obsłuży przekierowanie na edge bez dotykania serwera Vercel/origin — drastycznie redukuje TTFB i koszty inwokacji funkcji.

Weryfikacja: po deploy odpal Screaming Frog na pliku CSV ze starymi URL-ami w trybie List Mode. Każdy stary URL musi zwrócić status 301 z poprawnym `Location` header. Akceptowalny jest również 308 (Permanent Redirect) — Google traktuje obie wartości równoważnie od 2017 roku.

4. Search Console Change of Address — sygnał oficjalny do Google

Jeśli migracja obejmuje również zmianę domeny (np. ze `stara-agencja.pl` na `nowa-agencja.pl`), narzędzie Change of Address w Google Search Console to obowiązkowy krok. Pomija się go zaskakująco często, co kosztuje tygodnie opóźnienia w przeindeksowaniu nowej domeny.

Procedura krok po kroku:

1. Dodaj nową domenę jako Property w GSC (preferowany typ Domain Property, weryfikacja przez DNS TXT record).
2. Upewnij się, że nowa domena ma indeksowane minimum 10-20 stron z pełnym contentem.
3. Zweryfikuj, że 301 redirects działają dla minimum 5 testowych URL-i ze starej domeny.
4. Wejdź w Property starej domeny → Settings → Change of Address → wybierz nową domenę → potwierdź.
5. Google wyśle automatyczne sprawdzenie 301 redirectów i potwierdzi przeniesienie.

Jeśli migracja zostaje w obrębie tej samej domeny (najczęstszy scenariusz przy migracji CMS), Change of Address nie jest potrzebny. Wystarczy upewnić się, że sitemap.xml zostanie zaktualizowany i wysłany w GSC pod Sitemaps.

Dla polskich stron z aspektem RODO: pamiętaj o weryfikacji, czy nowa wersja zawiera aktualną politykę prywatności i banner cookies zgodny z UODO. Migracja techniczna to dobry moment na przegląd zgodności — wymóg ten dotyczy każdej strony obsługującej dane osobowe odwiedzających z UE.

5. Zyski wydajności — co realnie zyskujesz przechodząc na Next.js

Migracja na Next.js to nie tylko ryzyko SEO do zarządzania — to przede wszystkim znaczący skok wydajności, który długoterminowo poprawia rankingi. Realne metryki z migracji klientów Go To Agency w 2025-2026:

• Largest Contentful Paint (LCP) : WordPress + WooCommerce + 12 pluginów ≈ 3,8s — Next.js 15 z ISR + obrazy Next/Image ≈ 1,4s
• First Input Delay (FID/INP) : WordPress ≈ 180ms — Next.js ≈ 45ms (eliminacja heavy jQuery dependencies)
• Cumulative Layout Shift (CLS) : WordPress ≈ 0,18 — Next.js ≈ 0,03 (komponent Image z explicite zdefiniowanymi wymiarami)
• Time to First Byte (TTFB) z hostingiem polskim cyber_Folks ≈ 320ms — Vercel Edge + Cloudflare cache PL ≈ 80ms

Te liczby przekładają się bezpośrednio na Core Web Vitals, które Google używa jako sygnał rankingowy od czerwca 2021. Po migracji dobrze przygotowanej obserwujemy wzrost ruchu organicznego rzędu +18 do +34% w horyzoncie 4-6 miesięcy — paradoksalnie często większy niż przed migracją, mimo początkowych wahań.

Architektura zalecana dla polskich stron biznesowych w 2026:

Frontend Next.js 15 App Router
  + Static Site Generation (SSG) dla stron statycznych
  + Incremental Static Regeneration (ISR) dla bloga (revalidate 3600s)
  + Server Components dla SEO-critical content
  + Hosting Vercel (region Frankfurt fra1) lub self-host na MyDevil

Backend / CMS
  + Headless WordPress (REST API lub WPGraphQL)
    LUB Sanity / Strapi / Payload CMS
  + Hosting CMS niezależny — np. WordPress na cyber_Folks
    (jeśli zespół redaktorów zna interfejs WP)

Edge / CDN
  + Cloudflare (plan Pro)
  + Image optimization przez Next/Image (AVIF/WebP automatycznie)

Monitoring
  + Vercel Analytics (Core Web Vitals real-user)
  + Google Search Console + Google Analytics 4

Setup hybrydowy "Headless WordPress + Next.js frontend" jest szczególnie atrakcyjny dla polskich firm, których redaktorzy nie chcą porzucać znanego interfejsu WP — zachowujesz UX edycji, zyskujesz wydajność i SEO frontendu.

6. Monitoring 30/60/90 dni — protokół obserwacji po migracji

Deploy nowej wersji to nie koniec — to początek krytycznego okna 90 dni, w którym musisz aktywnie monitorować efekty SEO i interweniować przy anomaliach. Protokół Go To Agency:

Dni 1-7 (faza krytyczna) :

• Codzienny check w Google Search Console → Coverage : liczba Indexed pages nie powinna spaść więcej niż o 5%. Spadek powyżej 10% = problem z 301 redirects lub robots.txt
• Codzienny check URL Inspection dla 10 strategicznych stron — sprawdź czy Google indeksuje nową wersję
• Monitoring real-user Core Web Vitals przez Vercel Analytics — flaga przy degradacji powyżej 20%
• Server logs analysis : czy Googlebot dociera do nowych URL-i? Czy są błędy 500/503?

Dni 8-30 (stabilizacja) :

• Tygodniowy crawl Screaming Frog na nowej stronie — szukaj 404, broken internal links, brakujących meta description
• Tygodniowy review GSC Performance : trend kliknięć i wyświetleń. Dropy specyficzne dla konkretnych query = okazja do interwencji on-page
• Aktualizacja sitemap.xml i ponowne submission w GSC
• Sprawdzenie ahrefs/Semrush czy backlinki nadal wskazują na stare URL-e — kontakt z najważniejszymi linkującymi domenami z prośbą o update

Dni 31-90 (optymalizacja) :

• Comparative analysis ruchu YoY (rok do roku) — uwzględnienie sezonowości polskiego rynku
• Identyfikacja stron, które straciły pozycje → analiza intencji wyszukiwania i optymalizacja contentu
• Audit linków wewnętrznych — czy nowa struktura nawigacji wzmacnia strony strategiczne?
• Wdrożenie schema markup (Organization, BreadcrumbList, Article) jeśli nie zostało zrobione w fazie build

Realny przypadek z naszej praktyki: klient z branży B2B SaaS w Krakowie zmigrował z WordPressa do Next.js w marcu 2025. W tygodniu 2 zaobserwowaliśmy spadek Indexed pages z 847 do 612 (-28%). Diagnoza: 40 stron tagowych WordPress nie zostało zmapowanych ("przecież nie mają ruchu"). Implementacja brakujących 301 → w tygodniu 4 powrót do 831 stron. Bez tej szybkiej interwencji szacujemy stratę 4-6 tygodni pozycjonowania.

Podsumowanie i checklist final

Migracja WordPress → Next.js w 2026 jest technicznie bezpieczna pod warunkiem rygorystycznej metodologii. 53% migracji tracących ruch to nie wina frameworka — to wina pominiętego auditu, niekompletnej kartografii URL i braku monitoringu post-migration.

Checklist do druku przed startem projektu:

• [ ] Pełny crawl Screaming Frog z eksportem do Google Sheets
• [ ] Dane GSC za 16 miesięcy zaimportowane do arkusza
• [ ] Mapowanie 1:1 wszystkich URL-i z ruchem organicznym
• [ ] Polityka trailing slash zdefiniowana
• [ ] 301 redirects zaimplementowane w Next.js + Cloudflare
• [ ] Test każdego redirectu w Screaming Frog List Mode
• [ ] Sitemap.xml zaktualizowany i wysłany do GSC
• [ ] Change of Address w GSC (jeśli zmiana domeny)
• [ ] Plan monitoringu 30/60/90 dni przypisany do osoby
• [ ] Zgodność RODO/UODO zweryfikowana na nowej wersji

Jeśli przygotowujesz migrację dla polskiej strony i chcesz konsultacji z agencją mającą doświadczenie zarówno z polskim rynkiem, jak i nowoczesnymi stackami JavaScript — opisz nam projekt w 5 minutach. Odpowiadamy w 24 godziny z konkretną wyceną i timeline. Możesz również poznać nasz zespół i metodologię pracy zanim wyślesz brief.

Migracja techniczna to inwestycja w 5-letnią perspektywę technologiczną firmy. Robiona dobrze — fundament wzrostu. Robiona po łebkach — kosztowny krok wstecz. Wybór metodologii należy do ciebie.