Next.js a SEO: co daje stronie, a czego nie załatwi

Next.js daje kilka mechanizmów, które dobrze pasują do wymagań technicznego SEO. Może renderować stronę po stronie serwera albo wygenerować ją statycznie, dzięki czemu treść nie musi zależeć wyłącznie od JavaScriptu uruchamianego w przeglądarce użytkownika. Do tego dochodzą narzędzia do zarządzania metadanymi, mapą strony, plikiem robots.txt i danymi strukturalnymi.

To jednak ważne rozróżnienie: framework dostarcza możliwości, ale nie gwarantuje rezultatu. Możesz zbudować w Next.js stronę z prawidłowymi metadanymi, dobrą strukturą i małą ilością kodu po stronie przeglądarki. Możesz też zbudować stronę ciężką, wolną i źle skonfigurowaną. Sama nazwa technologii nie rozwiązuje problemu.

Google potrafi renderować JavaScript. Po pobraniu strony dokument może trafić do kolejki renderowania Web Rendering Service opartego na Chromium, gdzie wykonywany jest JavaScript. Nie ma więc podstaw do twierdzenia, że zwykła aplikacja React jest dla Google z definicji niewidoczna albo że Next.js gwarantuje indeksację natychmiast po publikacji.

Przewaga praktyczna polega na czymś innym. Jeśli kluczowa treść jest dostępna w HTML wygenerowanym na serwerze albo wcześniej utworzonym statycznie, nie uzależniasz jej pojawienia się od wykonania kodu w przeglądarce. To daje bardziej przewidywalną podstawę techniczną i pozwala świadomie zdecydować, które elementy muszą być interaktywne, a które mogą pozostać po stronie serwera.

Dlatego przy tworzeniu stron Next.js patrzę nie tylko na wybór frameworka. Sprawdzam również sposób renderowania, strukturę podstron, metadane, wydajność oraz to, czy treść faktycznie znajduje się tam, gdzie powinien ją znaleźć crawler.

Jednym z najbardziej mylących argumentów wokół JavaScriptu i SEO jest przekonanie, że Google nie potrafi czytać stron renderowanych po stronie użytkownika. Potrafi. Dokumentacja Google opisuje proces, w którym pobrana strona może zostać przekazana do usługi renderującej opartej na Chromium, a JavaScript zostaje wykonany.

Z tego powodu nie da się uczciwie sprowadzić porównania do hasła „React nie jest indeksowany, Next.js jest indeksowany”. Różnica dotyczy przede wszystkim tego, ile pracy musi zostać wykonane po pobraniu strony i w którym miejscu powstaje jej właściwa treść.

W Next.js możesz przygotować treść po stronie serwera albo wygenerować ją statycznie. W takim wariancie HTML zawiera informacje potrzebne użytkownikowi i wyszukiwarce bez konieczności czekania na zbudowanie całego widoku wyłącznie przez kod po stronie przeglądarki. To mechanizm, który daje kontrolę nad architekturą, ale nadal wymaga poprawnej konfiguracji konkretnej strony.

Nie oznacza to również, że sam sposób renderowania decyduje o pozycji. Trzeba tu postawić wyraźną granicę: Core Web Vitals są częścią sygnałów związanych z page experience, ale Google wskazuje, że treść i trafność mają większe znaczenie. Technicznie dobra strona nie zastępuje więc treści odpowiadającej na pytanie użytkownika.

Osobnym tematem jest sposób, w jaki różne crawlery przetwarzają JavaScript. Nie rozwijam go tutaj, bo temu służy osobny tekst o tym, jak działa SSR czy CSR pod SEO. W tym wpisie wystarczy jedna praktyczna zasada: jeśli ważna treść może być dostarczona w HTML bez uzależniania jej od wykonania JavaScriptu, korzystaj z tej możliwości.

Next.js ma wbudowane mechanizmy, które pozwalają utrzymać techniczne elementy SEO blisko kodu odpowiedzialnego za daną podstronę. Metadata API umożliwia definiowanie metadanych dla strony, a pliki sitemap.ts i robots.ts pozwalają generować mapę witryny oraz instrukcje dla crawlerów.

W praktyce oznacza to, że tytuł, opis, adres kanoniczny czy informacje wykorzystywane przy udostępnianiu podstrony mogą wynikać z jej danych i struktury aplikacji. Gdy treść pochodzi z systemu zarządzania treścią, metadane również mogą zostać przygotowane na podstawie tych samych danych zamiast być wpisywane ręcznie w wielu miejscach.

Podobnie działa mapa strony. sitemap.ts może powstawać na podstawie listy dostępnych podstron i treści. Nie jest to automatycznie gwarancja poprawnej indeksacji, tylko uporządkowany sposób dostarczenia informacji o adresach, które chcesz udostępnić wyszukiwarce.

robots.ts pełni inną rolę. Pozwala opisać zasady dostępu crawlerów i wskazać mapę strony. Sama obecność tego pliku nie poprawia pozycji. Jego wartość polega na tym, że konfiguracja jest jawna, wersjonowana razem z aplikacją i może odpowiadać faktycznej strukturze serwisu.

Next.js pozwala też umieszczać dane strukturalne JSON-LD w komponentach. Możesz dzięki temu powiązać dane strukturalne z konkretną podstroną i jej treścią. Ważniejsze od samego dodania znacznika jest jednak to, żeby opis odpowiadał rzeczywistej zawartości strony.

Wydajność często pojawia się jako argument za Next.js, ale również tutaj potrzebne jest zastrzeżenie. Next.js może pomóc zbudować szybką stronę, lecz nie gwarantuje dobrego wyniku Core Web Vitals.

Google uznaje za dobry wynik na poziomie 75. percentyla LCP poniżej 2,5 s, INP poniżej 200 ms oraz CLS poniżej 0,1. Wskaźniki te opisują odpowiednio szybkość pojawienia się głównej treści, reakcję strony na interakcje oraz stabilność układu. Są częścią sygnałów page experience, ale nie zastępują trafnej i wartościowej treści.

Dobrym przykładem jest moja własna strona marcinsiwonia.pl zbudowana na Next.js 16. We wrześniu 2026 przed optymalizacją LCP na telefonie wynosił 4,7 s. Po zmianach spadł do 2,0 s. Jednocześnie waga podstrony /projekty zmniejszyła się z około 27 MB do około 240 KB.

Najważniejszy jest jednak powód problemu. Wolne LCP nie wynikało z tego, że Next.js jest wolny. Przyczyną była plansza intro renderowana na serwerze. Framework nie uchronił strony przed decyzją implementacyjną, która pogorszyła wynik.

Dlatego nie traktuję wyniku wydajności jako właściwości frameworka. Mierzę konkretną stronę, znajduję element powodujący problem i dopiero wtedy zmieniam implementację. Ten sam stos technologiczny może dać zupełnie inne rezultaty zależnie od tego, jak został wykorzystany.

Dobra konfiguracja zaczyna się od podstaw, które da się utrzymać razem z kodem aplikacji. Nie chodzi o zestaw trików, tylko o sprawdzenie, czy wszystkie ważne elementy techniczne mają swoje miejsce i wynikają z rzeczywistej struktury serwisu. Przy stronie opartej na Next.js sprawdzam przede wszystkim:

• Metadane w layoucie i na podstronach: podstawowa konfiguracja plus metadane właściwe dla konkretnego adresu, przy dynamicznych podstronach generowane z ich danych.

• Mapę strony w sitemap.ts, która wynika z rzeczywiście dostępnych stron, a nie jest osobnym, ręcznie utrzymywanym plikiem.

• Reguły w robots.ts: które crawlery mają dostęp do których części strony i czy wskazana jest właściwa mapa witryny.

• Adres kanoniczny: każda podstrona jednoznacznie wskazuje adres, który ma reprezentować daną treść.

• Metadane do udostępniania: tytuł, opis i obraz podglądu dla konkretnej strony, a nie jeden zestaw kopiowany w całym serwisie.

• Dane strukturalne JSON-LD tylko tam, gdzie odpowiadają rzeczywistemu typowi i zawartości strony.

• Obrazy: mechanizmy Next.js do obsługi obrazów plus kontrola ich rzeczywistej wagi i wpływu na główną treść widoczną podczas ładowania.

• Fonty ładowane tak, żeby nie powodowały przesunięć układu.

• Linkowanie wewnętrzne wynikające z treści, bez osobnych podstron, do których nic nie prowadzi.

• Pomiar: dane rzeczywistych użytkowników, Core Web Vitals i Search Console do obserwowania stanu strony w Google.

Taka checklista nie gwarantuje pozycji. Jej zadaniem jest usunąć typowe techniczne zaniedbania i zapewnić, że wyszukiwarka ma dostęp do treści, metadanych i struktury serwisu zgodnie z tym, co rzeczywiście znajduje się na stronie. Do pomiarów wracam po każdej większej zmianie, bo przykład marcinsiwonia.pl pokazał, że problem z wydajnością może pojawić się w miejscu, którego sam wybór Next.js nie rozwiązuje.

Największą zaletą Next.js w tym kontekście nie jest automatyczny wzrost ruchu ani obietnica szybszej indeksacji. Jest nią możliwość świadomego zdecydowania, jak powstaje HTML, jakie metadane otrzymuje każda podstrona, jak tworzona jest mapa witryny i gdzie znajdują się dane strukturalne.

To istotne również poza Google. Badanie Vercel i MERJ z grudnia 2024 wskazało, że główne crawlery AI, w tym GPTBot, ClaudeBot i PerplexityBot, nie wykonywały JavaScriptu. Jeżeli zależy Ci na tym, aby podstawowa treść była dostępna także dla takich systemów, renderowanie jej bez uzależniania od JavaScriptu po stronie przeglądarki ma praktyczne znaczenie.

Nie oznacza to, że każdą stronę trzeba renderować w ten sam sposób. Next.js daje kilka możliwości właśnie po to, aby architekturę dopasować do treści i sposobu działania serwisu. Kluczowe jest to, co użytkownik i crawler faktycznie otrzymują, a nie nazwa zastosowanego mechanizmu.

Jeśli więc oceniasz Next.js pod kątem SEO, patrz na niego jako na zestaw możliwości technicznych. Renderowanie po stronie serwera lub generowanie statyczne, Metadata API, sitemap.ts, robots.ts i JSON-LD pomagają zbudować uporządkowaną podstawę. O tym, czy ta podstawa faktycznie działa, decydują konfiguracja, treść, wydajność i pomiar rzeczywistej strony.