SEO SPA w 2026 roku: przewodnik HTML-First dla Next.js, Nuxt, SvelteKit i Astro

TL;DR: Aplikacje jednopodstronowe mogą zdobywać pozycje w wyszukiwarce, ale tylko wtedy, gdy adresy URL, kody statusu, metadane i kluczowa treść znajdują się już w pierwszej odpowiedzi HTML. Google może wyrenderować JavaScript z opóźnieniem; większość botów AI nie renderuje go wcale. Dobierz model renderowania dla każdej trasy osobno: najpierw dostarcz dokument, potem stan aplikacji, a na końcu pozwól JavaScriptowi na hydrację. Poniżej: poradnik terenowy 2026 dla zespołów pracujących w Next.js, Nuxt, SvelteKit i Astro.

Przestań pytać, czy Google „obsługuje JavaScript”

Pytanie otwierające temat SEO dla SPA nie brzmi już „czy Googlebot potrafi renderować JavaScript”. Tak, potrafi. Martin Splitt powtarza to od lat. Ludzie wciąż debugują SPA, patrząc w view-source:, jakby to była strona, którą Google faktycznie indeksuje.

„Wielu ludzi wciąż patrzy na view source. To nie jest to, czego używamy do indeksowania. Korzystamy z wyrenderowanego HTML.”

Martin Splitt, Developer Advocate w Google

To eliminuje jeden zły nawyk. Jeśli sprawdzasz wyłącznie początkowe źródło aplikacji React, Vue, Angular, SvelteKit, Nuxt, Remix czy Next.js, przegapisz to, co ostatecznie widzi Google. Liczy się wyrenderowany DOM.

Ale pytanie na 2026 rok nie dotyczy tego, czy Google potrafi renderować, lecz czy dokument dociera wystarczająco szybko, by był użyteczny dla Googlebota, parserów społecznościowych i botów AI, które coraz częściej dominują w grafie cytowań.

Luka w renderowaniu przez boty AI zmieniła zasady gry

Przez lata traktowałem to jako problem wyłącznie Google (myliłem się). Potem pojawiły się boty AI z innym podejściem.

„Wyniki konsekwentnie pokazują, że żaden z głównych botów AI nie renderuje obecnie JavaScriptu.”

Vercel Engineering

GPTBot, ClaudeBot, PerplexityBot, fetch treningowy Gemini — wszystkie pobierają surowy HTML. Jeśli Twoja najważniejsza treść pojawia się dopiero po hydracji, te boty zobaczą pusty shell tam, gdzie powinien być cennik, opis produktu, FAQ czy zestawienie porównawcze. Uruchom nasze AI Crawler Inspector na kilku stronach SPA i zobaczysz to, co one.

Najpierw sklasyfikuj trasy, potem sam problem renderowania

Większość zespołów pomija ten krok i pyta, czy całe SPA potrzebuje SSR. Tak postawione pytanie marnuje czas inżynierów.

Prawdziwe SPA łączy dwie rzeczy: strony, które powinny być indeksowane, oraz prywatne stany aplikacji. Cenniki, wpisy blogowe, dokumentacje, szablony, integracje, strony porównawcze czy landing pages to strony. Pulpity, onboarding, modale, filtry, ekrany konta i zapisane raporty to stany aplikacji.

Zacznij od klasyfikacji. Nie proś inżynierów, by „naprawili SEO w aplikacji”. Poproś ich, aby zaznaczyli, które trasy zasługują na ruch z wyszukiwarki, a następnie dobierz renderowanie, indeksowanie, canonicale i kody statusu dla każdej z osobna.

Typ trasy	Czy powinna rankować?	Model renderowania	Zasada indeksacji
Wpis na blogu	Tak	SSG lub SSR	Index, canonical na siebie
Landing page produktu	Tak	SSG lub SSR	Index, canonical na siebie
Wyniki wyszukiwania wewnętrznego	Zazwyczaj nie	CSR lub SSR	Często noindex
Pulpit	Nie	CSR wystarczy	Zablokować za auth lub noindex
URL z filtrem fasetowym	Czasami	SSR tylko jeśli kuratowany	Canonical lub noindex

SPA z 40 publicznymi adresami i 4 000 stanów pulpitu nie ma 4 040 stron SEO. Ma 40 stron i interfejs produktu. Publiczne trasy potrzebują stabilnych URL-i, self-canonicali, metadanych serwerowych, linków do indeksacji, użytecznego HTML-a w pierwszym bajcie i poprawnych kodów statusu. Trasy pulpitu potrzebują szybkiej interakcji, autoryzacji i zarządzania stanem. Wciskanie obu grup w jeden model renderowania zwykle szkodzi obu.

Wybieraj model renderowania na poziomie trasy, nie całej aplikacji

Strategia renderowania to decyzja architektoniczna, nie ustawienie wtyczki. Jeśli wybierzesz zły model, każde kolejne zadanie staje się obejściem.

CSR: w porządku dla pulpitów, ryzykowne dla landing pages

Renderowanie po stronie klienta jest świetne dla ekranów wymagających logowania. Skoro użytkownik musi się zalogować, boty i tak nie powinny indeksować tej trasy. CSR robi się ryzykowne, gdy ten sam shell serwuje cenniki, dokumentacje, artykuły i strony produktowe, w których treść pojawia się dopiero po uruchomieniu JavaScriptu i zwrocie z API.

SSG: nudne, szybkie i zazwyczaj najlepsze

Statyczne generowanie buduje strony do HTML-a z wyprzedzeniem. Dla blogów, dokumentacji, changelogów, glosariuszy, szablonów i większości treści marketingowych SSG jest nie do pobicia: szybkie, keszowalne, tanie i przyjazne crawlerom. Astro 5 stawia na to najmocniej dzięki architekturze islands i domyślnemu zero-JS.

SSR: przydatne, gdy publiczna treść zmienia się często

Renderowanie po stronie serwera sprawdza się, gdy publiczna treść zależy od zapytania, geolokalizacji, stanu magazynowego, uprawnień lub świeżości. Lee Robinson opisał model Next.js jasno:

„Next.js prerenderuje stronę do HTML-a na serwerze przy każdym żądaniu.”

Lee Robinson, VP Developer Experience w Vercel

SSR dostarcza crawlerom HTML bez czekania na paczkę kliencką, a strona może jednocześnie pokazywać świeże dane.

ISR i PPR: praktyczny środek dla dużych serwisów

Incremental Static Regeneration odświeża statyczne strony po publikacji. Dla programmatic SEO, dokumentacji i rozbudowanych bibliotek szablonów ISR zapobiega bólowi pełnych rebuildów bez cofania się do CSR. Next.js 15 wyniósł Partial Prerendering (PPR) do stabilnej opcji: statyczny shell plus streamowane dynamiczne dziury w tej samej trasie. To miesza oba podejścia w jednym URL-u — bliżej prawdziwego zachowania stron produktowych.

Dynamic rendering: obejście, które powinno wygasnąć

Dynamic rendering podaje jedną wersję crawlerom, a inną użytkownikom. Może uratować legacy SPA, gdy migracja nie jest gotowa, ale nie projektowałbym nowej strategii wyszukiwania wokół niego.

„Traktowałbym to jako tymczasowe obejście – a tymczasowe może znaczyć kilka lat – ale to rozwiązanie na określony czas.”

John Mueller, Search Advocate w Google

Używaj dynamic rendering jako mostu. Gdy tylko się da, zastąp go trasami publicznymi renderowanymi na serwerze lub statycznie.

Szczegóły frameworków, które mają znaczenie w 2026

Właściwy model renderowania to również rozmowa o frameworku. Domyślne ustawienia zmieniły się w ostatnich dwunastu miesiącach, a część z nich wpływa na decyzje SEO dla SPA.

• Next.js 15. React 19 w stabilnej wersji, Turbopack stabilny w dev, fetch i obsługa GET-route domyślnie bez cache. Poprzednie domyślne cachowanie maskowało bugi ze starą treścią; nowe ustawienia wymuszają jawne cachowanie per trasa. Partial Prerendering to kluczowa funkcja SEO — statyczny shell z streamowanymi dynamicznymi dziurami — pozwalająca stronom produktowym być przyjaznymi crawlerom bez utraty świeżości. Szczegóły w naszym przewodniku SEO dla Next.js, React i Nuxt.
• Nuxt 4. Kod aplikacji domyślnie w app/. Osobne projekty TypeScript dla app, server, shared i builder zmniejszają problem „wycieku” typów serwera do paczek klienckich. Nuxt 4.4 (marzec 2026) dodał vue-router v5 i typowane propsy layoutów – małe, lecz ważne dla czystego dostarczania metadanych per trasa.
• SvelteKit 2 z runami Svelte 5. Strony domyślnie renderowane na serwerze; prerendering włączany per trasa. Mentalny model to „każda trasa to SSR, chyba że oznaczę statycznie”, co odwraca pułapkę „SPA by default”. Paczki są na tyle małe, że koszt hydracji rzadko blokuje first paint.
• Astro 5 (i 6). Domyślnie zero JavaScriptu, architektura islands, wsparcie dla komponentów wielu frameworków. Po przejęciu Astro przez Cloudflare w styczniu 2026 wdrożenia edge stały się jeszcze prostsze. Astro to łatwa odpowiedź dla treściowych SPA, które potrzebują komponentów Reacta czy Vue tylko na wybranych stronach.

Framework liczy się mniej niż dyscyplina per trasa. Każdy z tych czterech może dostarczyć crawlable SPA. Każdy może też dostarczyć niewidoczne, jeśli publiczną treść schowasz za hydracją.

Pułapki crawl, które wciąż psują indeksowanie

Najpoważniejsze błędy SEO w SPA są zazwyczaj nudne. Nie tajemnicze kary za rankingi – błędy dostarczania.

Pierwsza pułapka to uniwersalny shell. Każdy URL zwraca ten sam 200, tę samą pustą rootkę, tę samą paczkę. Router później decyduje, czy /pricing, /docs/api lub /totally-fake-url istnieją. To zmusza crawlery do zbyt ciężkiej pracy i tworzy drugą pułapkę: soft 404.

„Zamiast zwrócić 404, zawsze odpowiada 200 … zawsze pokazując stronę po wykonaniu JavaScriptu.”

Martin Splitt, Developer Advocate w Google

Niepoprawne trasy powinny zwracać prawdziwe 404 lub 410. Ładny klient-side „page not found” z kodem 200 wciąż marnuje crawl budget i myli sygnały indeksowania.

Trzecia pułapka to nawigacja, której crawlery nie mogą śledzić. Przyciski, click handlery i zdarzenia routera są świetne do interakcji, ale wewnętrzne odkrywanie wciąż potrzebuje anchorów z prawdziwymi atrybutami href. Jeśli do najważniejszych stron można dotrzeć tylko po wykonaniu handlera JavaScript, Twoja crawlability jest słabsza, niż myślisz.

Metadane to kolejna częsta porażka. Wiele SPA aktualizuje tytuły, opisy, canonicale, robots, Open Graph i schemę po zmianie trasy. Wizualnie w zakładce to działa. Crawlerom, parserom społecznościowym i botom AI już nie. Metadane specyficzne dla trasy muszą być w zwracanym HTML.

Canonicale zasługują na osobne ostrzeżenie. Widziałem aplikacje z hydracją, które nadpisywały poprawny canonical domeną stagingową, URL-em root lub poprzednią trasą. Błąd cichy, dopóki duplikaty nie zbiorą się w klastry lub nie zacznie rankować niewłaściwa strona.

Infinite scroll chowa treść za stanem klienta. Jeśli strona druga, trzecia i starsze elementy nie mają crawlable URL-i, wyszukiwarki mogą ich nigdy nie odkryć. Używaj stronicowanych URL-i fallback dla ważnych archiwów i kategorii.

Treść główna ładowana z API jest krucha. Jeśli H1, treść główna, szczegóły produktu, recenzje czy linki wewnętrzne wymagają wywołań API po hydracji, masz więcej punktów awarii. Ruch botów trafia w limity zapytań. API blokują nieznane user-agenty. Timeouty zostawiają wyrenderowany DOM ubogi.

Co AI Overviews faktycznie cytują ze SPA

To nowość na 2026. AI Overviews Google podsumowują odpowiedzi nad listą organiczną i cytują źródła użyte do stworzenia podsumowania. Te cytaty są nowym wierzchołkiem lejka i nagradzają konkretny kształt HTML.

System cytatów korzysta z jasnych, statycznych sygnałów: widocznego tekstu, nagłówków, list, tabel, semantycznego HTML dostępnego w pierwszej odpowiedzi. Nie czeka cierpliwie na hydrację. Jeśli Twój najbardziej cytowalny akapit pojawia się dopiero po wywołaniu useEffect, AI Overview go nie zobaczy.

Trzy rzeczy są ważne dla stron SPA, które chcą być cytowane:

1. Akapity z odpowiedzią dostępne w HTML-u. Pierwsze 300-400 słów każdej indeksowalnej trasy powinno odpowiadać na jej główne pytanie bez JavaScriptu. Większość cytatów AIO pochodzi z tych sekcji.
2. Semantyczna struktura list i tabel. Listy punktowane, numerowane i tabele HTML są wyciągane bezpośrednio do Overviews. Divy udające tabele – nie.
3. Stabilne URL-e, które bot AI może odświeżyć. Bot ponownie sprawdza źródła. Hash-routy, trasy tylko z parametrami query i forki dynamic rendering utrudniają refetch.

Ta sama logika dotyczy cytowań w Perplexity, odpowiedzi ChatGPT z przeglądaniem internetu czy odczytów sieciowych Claude’a. Ich crawlery pobierają surowy HTML; jeśli odpowiedzi tam nie ma, strona nie jest cytowana. Optymalizacja pod cytaty AI Overview opisuje to szerzej, a analiza wpływu AIO wyjaśnia, dlaczego utrata wyświetleń boli bardziej niż spadek kliknięć.

Każdą indeksowalną trasę dostarczaj najpierw jako dokument

Zasada, do której wciąż wracam: jeśli trasa zasługuje na ruch z wyszukiwarki, pierwsza odpowiedź powinna wyglądać jak strona.

Oznacza to, że każdy publiczny URL zwraca użyteczny HTML z już umieszczonymi kluczowymi sygnałami:

• Prawidłowy <title>.
• Meta description.
• Self-canonical.
• Jeden wyraźny H1.
• Treść główna.
• Crawlable linki wewnętrzne.
• Strukturalne dane tam, gdzie to ma sens.
• Poprawny kod statusu.
• Tagi Open Graph i Twitter, jeśli udostępnianie jest ważne.

JavaScript może potem hydradować komponenty, personalizować elementy, śledzić zdarzenia i wzbogacać doświadczenie. Nie powinien być wymagany, by crawler zrozumiał, o czym jest strona.

Architektura serwisu też ma znaczenie. Publiczna trasa bez crawlable linków prowadzących do niej wciąż jest słaba — nawet jeśli jest renderowana na serwerze. Perfekcyjnie wyrenderowany dokument ukryty pięć kliknięć głęboko za nawigacją klient-side nie działa tak dobrze, jak ten w klarownym systemie linków wewnętrznych.

Testuj SEO SPA na wyrenderowanym HTML, nie na nadziei

Jeśli testujesz tylko w przeglądarce, sprawdzasz najbardziej optymistyczną ścieżkę. SEO SPA potrzebuje brzydszych testów.

1. Pobierz URL z wyłączonym JavaScriptem i sprawdź, czy treść wciąż ma sens.
2. Sprawdź adres w Google Search Console i przejrzyj wyrenderowany HTML.
3. Porównaj początkowy HTML z wyrenderowanym DOM w Chrome DevTools.
4. Testuj kody statusu komendą curl -I https://example.com/missing-route.
5. Przeskanuj serwis jednym crawlerem z JS i jednym bez JS.
6. Potwierdź, że tytuły, canonicale, robots, schema i linki wewnętrzne istnieją przed hydracją.
7. Sprawdź logi serwera pod kątem hitów botów, zablokowanych API, timeoutów i nieoczekiwanych przekierowań.
8. Zweryfikuj dane strukturalne w Rich Results Test Google po renderze.

Niewygodny test to test H1. Jeśli Googlebot potrzebuje pięciu kroków i dwóch wywołań API, by znaleźć H1, strona jest krucha, nawet gdy ostatecznie zostanie zindeksowana. Zastosuj ten sam test do GPTBota, ClaudeBota i PerplexityBota: jeśli nie widzą H1 w surowym HTML, trasa nie pojawi się jako cytat AI.

Checklist SEO dla SPA w 2026

Stosuj ją na poziomie trasy. Ocena „site-wide pass” ukrywa zbyt wiele błędów SPA.

• Renderowanie: Strony publiczne używają SSG, SSR, ISR lub PPR. Prywatne ekrany aplikacji mogą zostać na CSR.
• Routing: Każdy indeksowalny URL ma unikalną trasę, unikalną treść i self-canonical.
• Kody statusu: Brakujące strony zwracają 404 lub 410, nie 200.
• Linki: Nawigacja wewnętrzna używa anchorów z prawdziwymi href.
• Metadane: Tytuły, opisy, canonicale, robots, Open Graph i schema są specyficzne dla trasy i obecne w HTML.
• Treść: Główna kopia, H1, informacje produktowe i kluczowe linki istnieją bez czekania na dane klient-only.
• Wydajność: Kontroluj rozmiar paczek, koszt hydracji, skrypty third-party i dzielenie kodu per trasa.
• Kontrola indeksu: Pulpity, prywatne trasy, niskowartościowe filtry i cienkie strony wyszukiwania są blokowane lub noindex.
• Testowanie: Porównuj początkowy HTML, wyrenderowany DOM i zindeksowaną treść na ważnych szablonach.
• Widoczność w AI: Cytowalne akapity, listy i tabele znajdują się w surowym HTML, aby AI Overviews i wyszukiwarki AI mogły je zacytować.

Wyszukiwarki, odpowiedzi AI, podglądy linków i systemy odkrywania zależą od dostępu. Rankingi są dopiero drugie.

Najprostsza architektura SEO dla SPA, jaką wdrożyłbym dziś

Gdybym zaczynał nowoczesne SPA z myślą o ruchu z wyszukiwarki, nie renderowałbym całego produktu na serwerze. Podzieliłbym go.

Obszar serwisu	Rekomendowane podejście
Strona marketingowa	Statyczne generowanie
Blog i dokumentacja	Statyczne generowanie lub ISR
Strony produktowe	SSR, ISR lub PPR w Next.js
Strony programmatic SEO	Statyczne generowanie z mocnym prunowaniem
Pulpit	CSR za auth
Strony wyszukiwania i filtrów	Noindex, chyba że ręcznie kuratowane
Niepoprawne trasy	Prawdziwe 404 lub 410
Wspólny layout	Serwerowo renderowane metadane i nawigacja

Strony marketingowe i artykuły powinny być HTML-first. Powierzchnie produktowe wymagające świeżości używają SSR, ISR lub PPR. Pulpit pozostaje aplikacyjny, bo rankowanie go nie ma sensu. Strony programmatic SEO wymagają umiaru. Statyczne generowanie ułatwia stworzenie tysięcy stron, w tym takich, których nikt nie powinien indeksować. Generuj tylko strony z realnym popytem, wartościową treścią i linkami wewnętrznymi. Odrzuć resztę, zanim Google zrobi to za Ciebie.

Wygrywa nie to SPA, które udowodni crawlerom, że potrafią uruchomić JavaScript. Wygrywa to, które nie zmusza crawlerów do zbędnej pracy.

FAQ

Czy aplikacja jednopodstronowa może rankować w Google w 2026 roku?

Tak. SPA może rankować, jeśli indeksowalne trasy zwracają crawlable treść, poprawne metadane, linki wewnętrzne i prawidłowe kody statusu już w pierwszej odpowiedzi HTML. Google potrafi renderować JavaScript, ale poleganie na nim we wszystkim czyni witrynę bardziej kruchą i niewidoczną dla botów AI, które w ogóle nie renderują.

Czy do SEO SPA wymagany jest SSR?

Nie dla każdej trasy. SSR pasuje do stron publicznych z często zmieniającą się treścią. Dla treści stabilnej lepsze jest SSG lub ISR. Partial Prerendering w Next.js 15 łączy oba podejścia w jednej trasie. CSR jest w porządku dla prywatnych pulpitów i stanów aplikacji, które nie powinny być indeksowane.

Czy trasy z hashem są złe dla SEO?

Hash-routy to kiepski wybór dla stron indeksowalnych. Sprawdzają się przy fragmentach na stronie, ale publiczna treść powinna mieć czyste URL-e, metadane per trasa i kody statusu po stronie serwera.

Czy strony z wynikami wyszukiwania w SPA powinny być indeksowane?

Zazwyczaj nie. Wewnętrzne wyszukiwania i filtry fasetowe często tworzą cienkie lub zduplikowane URL-e. Kuratowane strony filtrów można indeksować, gdy mają unikalny popyt, stabilną treść i klarowną strategię canonical.

Skąd wiem, że moje SPA ma problem soft 404?

Wywołaj fikcyjny URL i sprawdź kod statusu. Jeśli /this-page-should-not-exist zwraca 200 z klient-side not-found, masz ryzyko soft 404, które marnuje crawl budget.

Czy AI Overviews zacytuje SPA renderowane JavaScriptem?

Tylko jeśli cytowana treść istnieje w surowym HTML. Większość botów AI nie wykonuje JavaScriptu. Zrenderuj na serwerze lub prerenderuj akapity z odpowiedziami, listy i tabele, które chcesz cytować.

Potrzebujesz pomocy w zamianie SPA na strony crawlable?

SEOJuice pomaga zespołom wzmacniać crawlable linki wewnętrzne i sygnały HTML-first na publicznych stronach zasługujących na ruch z wyszukiwarki. Jeśli Twoje SPA ma osierocone trasy, ukryte szablony lub strony, do których Google nigdy nie dociera, automatyczne linkowanie wewnętrzne może ułatwić warstwę dokumentu dla crawlerów i botów AI.

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Czy aplikacja jednopodstronowa może rankować w Google w 2026 roku?", "acceptedAnswer": { "@type": "Answer", "text": "Tak. SPA może rankować, jeśli indeksowalne trasy zwracają crawlable treść, poprawne metadane, linki wewnętrzne i prawidłowe kody statusu już w pierwszej odpowiedzi HTML. Google potrafi renderować JavaScript, ale poleganie na nim we wszystkim czyni witrynę bardziej kruchą i niewidoczną dla botów AI, które w ogóle nie renderują." } }, { "@type": "Question", "name": "Czy do SEO SPA wymagany jest SSR?", "acceptedAnswer": { "@type": "Answer", "text": "Nie dla każdej trasy. SSR pasuje do stron publicznych z często zmieniającą się treścią. Dla treści stabilnej lepsze jest SSG lub ISR. Partial Prerendering w Next.js 15 łączy oba podejścia w jednej trasie. CSR jest w porządku dla prywatnych pulpitów i stanów aplikacji, które nie powinny być indeksowane." } }, { "@type": "Question", "name": "Czy trasy z hashem są złe dla SEO?", "acceptedAnswer": { "@type": "Answer", "text": "Hash-routy to kiepski wybór dla stron indeksowalnych. Sprawdzają się przy fragmentach na stronie, ale publiczna treść powinna mieć czyste URL-e, metadane per trasa i kody statusu po stronie serwera." } }, { "@type": "Question", "name": "Czy strony z wynikami wyszukiwania w SPA powinny być indeksowane?", "acceptedAnswer": { "@type": "Answer", "text": "Zazwyczaj nie. Wewnętrzne wyszukiwania i filtry fasetowe często tworzą cienkie lub zduplikowane URL-e. Kuratowane strony filtrów można indeksować, gdy mają unikalny popyt, stabilną treść i klarowną strategię canonical." } }, { "@type": "Question", "name": "Skąd wiem, że moje SPA ma problem soft 404?", "acceptedAnswer": { "@type": "Answer", "text": "Wywołaj fikcyjny URL i sprawdź kod statusu. Jeśli /this-page-should-not-exist zwraca 200 z klient-side not-found, masz ryzyko soft 404, które marnuje crawl budget." } }, { "@type": "Question", "name": "Czy AI Overviews zacytuje SPA renderowane JavaScriptem?", "acceptedAnswer": { "@type": "Answer", "text": "Tylko jeśli cytowana treść istnieje w surowym HTML. Większość botów AI nie wykonuje JavaScriptu. Zrenderuj na serwerze lub prerenderuj akapity z odpowiedziami, listy i tabele, które chcesz cytować." } } ] } </script>