Jak migracja z WordPressa na Nuxt odblokowała indeksację 16 tys. podstron [Case Study]

Masz serwis z unikalnymi treściami. Masz mocne linki. Dbasz o optymalizację on-site. A mimo to w Google Search Console widzisz „czerwoną ścianę” w raporcie indeksacji: „Strona wykryta – obecnie niezaideksowana”.

Tak wyglądała sytuacja w jednym z serwisów, który trafił na nasz stół operacyjny we FratreSEO. Prawie 20 tysięcy podstron, z czego w indeksie Google znajdowało się zaledwie 25%. Reszta? Googlebot wiedział o ich istnieniu, ale nie miał „czasu”, by je przetworzyć.

Oto techniczna historia o tym, jak zamiast reanimować powolnego WordPressa, przepisaliśmy architekturę na Nuxt + Vercel, schodząc z czasem odpowiedzi serwera (TTFB) z ~1500 ms do 150 ms.

Pacjent: WordPress na sterydach (i kulach)

Serwis, o którym mowa, to klasyczny przykład długu technologicznego narastającego latami.

• Typ: Serwis contentowy, treści statyczne (evergreen), część bazodanowa i kilka formularzy (kalkulatory)
• Stack: WordPress + ciężki motyw DIVI + kilkanaście wtyczek + baza MySQL (kilkaset MB).
• Infrastruktura: Tani VPS + proxy Cloudflare.

Mimo prób optymalizacji – czyszczenia tabeli wp_options, konfiguracji cache (Litespeed) i tuningu bazy – pacjent wciąż ledwo oddychał.

Diagnoza: To nie wina treści, to wina „tlenu”

Wielu specjalistów SEO w tym momencie szukałoby problemów w kanibalizacji słów kluczowych lub „thin contentu”. My zajrzeliśmy głębiej – w logi serwera.

Analizując zachowanie botów, zauważyliśmy niepokojący wzorzec. Choć serwer zwracał kod 200 OK, czas odpowiedzi (response_time) często przekraczał 1500-2000 ms. Co więcej, w logach Nginx zaczęliśmy dostrzegać specyficzne błędy: Code 499 (Client Closed Request). Oznacza to, że bot wysyłał żądanie, ale serwer „mielił” PHP tak długo, że klient zrywał połączenie.

Co bardzo ważne – problem dotyczył nie tylko Googlebota.

Podobnie zachowywały się boty zbierające dane dla modeli AI (GPTBot, ClaudeBot). Serwis skutecznie odcinał się nie tylko od wyszukiwarki Google, ale też od „rewolucji” AI Search / AIO. Jeśli bot AI nie może szybko pobrać Twojej strony, po prostu ją pominie.

Wniosek: Serwis dusił każdego robota, który próbował go odwiedzić. Przy 20 tysiącach podstron, Crawl Budget kończył się szybciej, niż serwer zdążył wygenerować HTML.

Decyzja: Reanimacja vs Przeszczep

Mieliśmy dwie drogi:

1. Reanimacja: Zainwestować w droższy serwer dedykowany, rozpocząć mozolny proces optymalizacji i walczyć o każde milisekundy na wielu poziomach
2. Przeszczep: Zmienić technologię na taką, która serwuje statyczny HTML bez narzutu bazy danych.

Wybraliśmy opcję numer 2. A konkretnie: Nuxt (Vue.js) + Vercel.

Dlaczego taki stack?

• Vercel: Chcieliśmy przetestować alternatywę dla Cloudflare i wykorzystać ich globalną sieć Edge Network.
• Nuxt: Potrzebowaliśmy frameworka, który obsługuje nowoczesny routing i daje pełną kontrolę nad renderowaniem (SSR/SSG).
• Dane: Zamiast bazy SQL – pliki Markdown. Skoro treść się nie zmienia, po co trzymać ją w bazie danych?
• Bez CMS: „a komu to potrzebne i po co?” – ponieważ na pokładzie nie było rozbudowanej, nietechnicznej redakcji – zrezygnowaliśmy z graficznego CMSa i oparliśmy serwis o repozytorium na Github.

Proces Migracji: Inżynieria zamiast „Wtyczkologii”

To nie była prosta przesiadka. Musieliśmy przenieść +10 lat historii serwisu do nowoczesnego środowiska JS.

1. Migracja Danych (MySQL -> Markdown)

Pierwszym wyzwaniem było wyciągnięcie treści z WordPressa. DIVI i stare wtyczki zostawiły w bazie mnóstwo „śmieci” (shortcode’y, zagnieżdżone spany, dziwne formatowanie). Napisaliśmy skrypty konwertujące bazę do plików Markdown, jednocześnie czyszcząc kod HTML. Efekt? Czysty, semantyczny tekst, który waży ułamek tego, co „wypluwał” WordPress.

2. Hybrydowe Renderowanie (SSG + SSR + ISR)

To największa zaleta Nuxta. Nie musieliśmy decydować się na jedno podejście. Zastosowaliśmy mix:

• SSG (Static Site Generation): Główne treści, czyli artykuły. Są budowane raz, podczas deployu. Dla serwera to zwykły plik tekstowy. Czas dostępu? Natychmiastowy.
• SSR (Server Side Rendering): Kalkulatory i narzędzia, które wymagają logiki po stronie serwera.
• ISR (Incremental Static Regeneration): Podstrony generowane dynamicznie na podstawie parametrów (baza danych) – budują się przy pierwszym wejściu i cachują dla kolejnych użytkowników.

3. Koszmar Routingu (Gdzie WP wygrywa z JS)

Tutaj trafiliśmy na największe wyzwanie, o którym rzadko mówi się w tutorialach. W WordPressie (Apache/Nginx) obsługa tysięcy przekierowań i struktury URL jest trywialna. W aplikacji SPA/SSR (JavaScript) musieliśmy obsłużyć to programowo – wielowarstwowo.

Musieliśmy napisać zaawansowaną logikę routingu (Vue Router), która obsługuje stare struktury URL, zarządza stronami typu „catch-all” i poprawnie zwraca nagłówki 404/301 (co nie jest takie proste i oczywiste, że już o logowaniu tych kodów nie wspomnę). Początkowo dynamiczne trasy gryzły się ze statycznymi plikami, co powodowało błędy w renderowaniu. Wymagało to kilku iteracji, ale dało nam potężną wiedzę deweloperską.

Wyniki: Google (i AI) odzyskują oddech

Wdrożenie odbyło się płynnie. Po przełączeniu DNS-ów, Googlebot zobaczył zupełnie nową jakość infrastruktury.

Oto twarde dane (porównanie „Przed” i „Po”):

Anegdota z życia:
Pamiętam, jak w trakcie rozmów o poprawie wydajności, jeden z developerów tłumaczył, że nie da się zejść poniżej 400 ms czasu odpowiedzi, bo przecież to wynika z drogi, którą sygnał (światłowodem) musi pokonać trasę z Europy do USA.

Efekt w GSC:

W ciągu tygodnia od wdrożenia wykres „Zaindeksowane” wystrzelił pionowo w górę. Google zaindeksował ~16 tysięcy podstron, które wcześniej omijał.

A w statystykach crawlowania z +-850ms (średnio) do +- 150ms (średnio):

Efekt Biznesowy:

Obawialiśmy się, że w dobie AI Overviews (AIO) ruch może spaść. Tymczasem zanotowaliśmy ~20% wzrost kliknięć i kilkukrotny wzrost wyświetleń. Dzięki czystemu kodowi i szybkości, nasze treści zaczęły być cytowane przez moduły AI w wynikach wyszukiwania.

Adwokat Diabła: „A nie dało się po prostu zoptymalizować WordPressa?”

Gdy wspominam o tym wdrożeniu, często słyszę: „Nie umiecie w WordPressa. Wystarczyło wdrożyć Redis, Varnish, wyczyścić bazę i zoptymalizować zapytania SQL”.

Odpowiedź brzmi: Tak, dało się. Ale czy to miało sens biznesowy?

W tym zadaniu nie chodziło o to, by przez miesiąc uprawiać „sztukę dla sztuki” i walczyć z kodem legacy. Chodziło o to, by out-of-the-box mieć działający, szybki serwis.

Kluczowym problemem WordPressa przy tej skali jest tzw. „Cache Miss”. Cache działa świetnie dla popularnych artykułów. Ale gdy Googlebot (lub AI bot) chce wejść na stary wpis z 2020 roku, którego nie ma w pamięci podręcznej – WordPress musi „wstać”, odpytać bazę i wygenerować HTML. To trwa.

W architekturze SSG (Nuxt) ten problem nie istnieje. Strona z 2018 roku to statyczny plik HTML. Serwuje się tak samo szybko (50ms) jak strona główna. Zawsze.

Decyzja o migracji była podyktowana chłodną kalkulacją: chcieliśmy systemu, który jest szybki z natury (by design), a nie szybkiego, bo został obłożony dziesięcioma warstwami wspomagaczy.

Reanimacja czy Nowe Życie?

Czytając to case study, możesz zadać sobie pytanie:

„Czy mój serwis też kwalifikuje się do takiego przepisania?”.

Migracja na stack typu Nuxt/Vercel to nie jest złoty środek na wszystko. To poważna operacja inżynieryjna, która wiąże się z kosztami i zmianą procesów.

Kiedy warto walczyć o WordPressa, a kiedy czas „zaorać” i budować od nowa? Oto 3-stopniowy filtr, który stosujemy we FratreSEO podczas audytów wstępnych.

Filtr 1: Gotowe procesy (Monolit) vs elastyczność (Headless)

Frameworki takie jak Nuxt świetnie radzą sobie z dynamicznymi aplikacjami i sklepami (e-commerce na Nuxt to potęga). Pytanie nie brzmi „czy to udźwignie?”, ale „czy masz budżet na przepisanie logiki?”.

• Zostań przy WP (Monolit), jeśli: Twój biznes opiera się na skomplikowanej logice dostarczanej przez wtyczki, której nie chcesz pisać od zera. Masz sklep na WooCommerce z wieloma specyficznymi dodatkami (np. konfiguratory produktów, skomplikowane reguły wysyłki, subskrypcje), które działają „out of the box”. Przeniesienie tego 1:1 na architekturę Headless (Nuxt + API) to ogromny koszt deweloperski, bo musisz odtworzyć działanie tych wtyczek na frontendzie.
• Wybierz Nuxt (Headless), jeśli: WordPress służy Ci głównie jako CMS (baza danych treści/produktów), a frontend ogranicza Twój UX. Jeśli budujesz dedykowane doświadczenia użytkownika, aplikację webową (SPA) lub Twój sklep wymaga wydajności, której nie da się osiągnąć, gdy backend miesza się z frontendem. Nuxt jest idealny do dużych sklepów, ale wymaga podejścia „API First”.

Filtr 2: Głębokość długu technologicznego

Jak bardzo „toksyczna” jest Twoja obecna instalacja WordPressa?

• Reanimuj (Optymalizuj WP), jeśli: Masz czysty motyw (najlepiej autorski, oparty np. o Gutenberg/ACF), używasz 5-10 niezbędnych wtyczek, a baza danych jest w miarę uporządkowana. Wtedy wdrożenie Redisa, dobrego hostingu i odpowiedniej polityki cache może dać świetne rezultaty (TTFB < 300ms) znacznie niższym kosztem.
• Przepisuj, jeśli: Korzystasz z ciężkiego page buildera (typu DIVI/Elementor) na kilkudziesięciu tysiącach podstron, masz 30 aktywnych wtyczek (w tym 3 „kombajny” SEO, 2 do cache i 5 do bezpieczeństwa 😉 ), a w bazie danych straszą pozostałości po motywach sprzed 8 lat. W takim przypadku optymalizacja to walka z hydrą – odetniesz jedną głowę (problem), wyrosną dwie kolejne.

Filtr 3: Problem „Cache Miss” a Crawl Budget

To kryterium dla dużych serwisów (powyżej 5-10 tys. podstron), którym zależy na SEO.

• Zostań przy WP, jeśli: Masz mały serwis (np. 500 podstron), a Google indeksuje wszystko bez problemu. Jeśli Twoim jedynym problemem są słabe wyniki w PageSpeed Insights dla użytkowników, często wystarczy dobra konfiguracja wtyczki cache i CDN.
• Rozważ migrację, jeśli: Widzisz w GSC, że tysiące podstron wisi jako „Wykryta – niezaideksowana”, a logi serwera pokazują, że Googlebot czeka na odpowiedź serwera powyżej 600-800ms (zwłaszcza na starych wpisach). To znak, że Twój obecny stack nie skaluje się do potrzeb botów wyszukiwarek.

Werdykt

Decyzja o migracji na Nuxt/Next.js + Vercel/Netlify nigdy nie powinna być podyktowana modą („bo teraz wszyscy robią w JS”). To musi być chłodna kalkulacja biznesowa: czy koszt utrzymania długu technologicznego WordPressa przewyższył już koszt inwestycji w nową architekturę? W opisywanym przypadku odpowiedź była twierdząca.

Podsumowanie

Ten eksperyment potwierdził starą prawdę inżynierską:

Optymalizacja ma swoje granice. Czasem trzeba zmienić architekturę.

Dług technologiczny to nie tylko brzydki kod. To konkretny koszt, który płacisz brakiem widoczności w Google i ignorowaniem przez algorytmy AI.

Podejrzewasz, że Twój serwis też potrzebuje tlenu?

Masz rozbudowany serwis, publikujesz treści, a wykresy w GSC stoją w miejscu? Widzisz, że Googlebot „odbija się” od Twoich podstron, a konkurencja ucieka?

Odezwij się do mnie. Nie będziemy wróżyć z fusów.

Sprawdzimy „stan zdrowia” Twojego pacjenta: zajrzymy w logi, zmierzymy TTFB i powiemy Ci szczerze, czy Twój serwis wymaga tylko witamin (optymalizacji), czy może potrzebny jest inżynierski przeszczep, który odblokuje Twój potencjał.