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.