Google Search Console + Next.js — indeksacja, błędy, performance i co z nimi robić

Dlaczego Google Search Console jest niezbędne dla Next.js?

Dla strony Next.js, GSC jest szczególnie ważne, ponieważ App Router z SSR, ISR i streamingiem ma specyficzne zachowania, które mogą w różny sposób wpływać na indeksację.

Weryfikacja własności strony Next.js w Google Search Console

Weryfikacja DNS w Google Search Console

Najczystsza metoda, która nie wymaga zmian w kodzie:

1. GSC → Add Property → Domain → strivelab.pl,
2. Skopiuj rekord TXT,
3. Dodaj w DNS (Cloudflare/rejestrator),
4. Poczekaj na propagację (5 min – 24h).

Weryfikacja przez meta tag w Next.js

export const metadata = {
  verification: {
    google: 'twoj-kod-weryfikacyjny',
  },
}

Wynikowy HTML: <meta name="google-site-verification" content="twoj-kod-weryfikacyjny" />

Sitemapa w Google Search Console: zgłoszenie i monitoring

Po wdrożeniu sitemap (natywne API App Routera lub next-sitemap):

1. GSC → Sitemaps → dodaj https://example.com/sitemap.xml,
2. Sprawdź status — „Success" z liczbą wykrytych URL-ów,
3. Monitoruj co tydzień, ponieważ wszystkie nowe strony powinny pojawiać się automatycznie.

Jakie są typowe problemy z sitemap w projekcie na Next.js:

• Sitemap zwraca 404 — sprawdź, czy app/sitemap.ts eksportuje domyślną funkcję,
• Za mało URL-ów — dynamiczne strony zwykle wymagają dynamicznej sitemap z bazy lub CMS; generateStaticParams pomaga w pre-renderingu, ale nigdy nie zastąpi sitemap,
• Duplikaty — trailing slash vs bez, www vs non-www → skonfiguruj link kanoniczny.

Przy większej liczbie nowych lub aktualizowanych stron ważne jest też lastModified, ponieważ poprawnie wygenerowana sitemapa nie tylko pokazuje Google listę URL-i, ale też daje sygnał, które strony faktycznie się zmieniły. W praktyce wygląda to tak, że przy blogu pobierać updatedAt z CMS albo pliku MDX, z kolei przy e-commerce najlepiej używać daty ostatniej zmiany produktu, a przy stronach programmatic SEO nie ustawiaj wszystkim URL-om dzisiejszej daty tylko dlatego, że przebudowałeś aplikację.

Jeśli pracujesz ze stroną wielojęzyczną, musisz pilnować, żeby sitemapa, link kanoniczny i hreflang były ze sobą spójne. Używając w Next.js alternates.languages, sprawdź w GSC nie tylko główny URL, ale też wersje językowe, ponieważ błędy typu /pl, /en, slash na końcu i różne linki kanoniczne potrafią rozbić indeksację na kilka wariantów tej samej strony. Bałagan gotowy.

Indeksacja w GSC: raport „Strony"

GSC → Pages → raport pokazuje status każdej strony. Zanim wejdziemy w listę statusów, warto rozumieć cały cykl, przez który Google przeprowadza URL — od momentu odkrycia aż po pojawienie się w wynikach:

Każdy z kolejnych statusów w raporcie Pages odpowiada konkretnemu węzłowi w tym przepływie — i to determinuje, czego szukać, by URL ruszył dalej.

Statusy indeksacji i jak na nie reagować

Zaindeksowana — strona jest w Google, więc sprawdź, czy ranking odpowiada oczekiwaniom.

Wykryta, obecnie nie zaindeksowana — Google zna URL, ale jeszcze go nie pobrał albo nie nadał mu wysokiego priorytetu, co nie musi od razu oznaczać nieprawidłowo skonstruowanej czy generycznej treści. Sprawdź, czy URL jest w sitemapie, czy ma linki wewnętrzne z ważnych podstron i czy ma odpowiednią ilość unikatowej treści.

Zeskanowana, obecnie nie zaindeksowana — Google już pobrał stronę, ale nie dodał jej do indeksu - tutaj najczęściej wchodzą problemy jakościowe strony i może chodzić o tzw thin content, duplikacje treści, słaby link kanoniczny, niewiele unikalnej wartości albo HTML, który po renderowaniu wygląda biedniej niż zakładasz. W Next.js sprawdź rendered HTML w URL Inspection, link kanoniczny oraz to, czy główna treść nie zależy wyłącznie od Client Componentu.

Duplikat bez wskazanego linku kanonicznego — Google uznał stronę za podobną do innego URL-a i sam wybrał wersję kanoniczną. Jeśli wybór jest poprawny, nie musisz nic robić, ale jeśli nie, ustaw alternates.canonical, popraw linkowanie wewnętrzne, zadbaj o jeden wariant slash/www/protokół i usuń niepotrzebne warianty URL-i.

Duplikat, Google wybrał inną stronę kanoniczną niż użytkownik — to ważniejszy sygnał, ponieważ oznacza, że deklarujesz jeden link kanoniczny, ale Google bardziej "ufa" innemu URL-owi. Porównaj User-declared canonical i Google-selected canonical w URL Inspection. Najczęściej oznacza to, że deklarowany link kanoniczny nie pasuje wystarczająco dobrze do treści analizowanej strony albo inne sygnały, takie jak linkowanie wewnętrzne i sitemap, wzmacniają inny wariant URL-a.

Wykluczona przez noindex — sprawdź metadata.robots, nagłówki HTTP i logikę środowiskową. Częsty błąd: noindex dodany na stagingu zostaje po deployu produkcyjnym albo warunek zależny od NODE_ENV działa inaczej niż zakładasz.

Zablokowana przez robots.txt — sprawdź app/robots.ts, czy nie blokujesz ścieżek, które powinny być indeksowane. Klasyczny robots.txt Tester został wycofany — w GSC korzystasz teraz z raportu robots.txt (Settings → robots.txt), który pokazuje, jaką wersję pliku Google ostatnio pobrał oraz ewentualne błędy i ostrzeżenia, bez guessowania.

Soft 404 — strona zwraca HTTP 200, ale Google uważa ją za pustą - zdarza się to w Next.js przy SSR z pustymi danymi. Rozwiązaniem będzie zwrócenie notFound() (HTTP 404), gdy nie ma danych, zamiast renderowania pustej strony.

import { notFound } from 'next/navigation'
 
export default async function PostPage({
  params,
}: {
  params: Promise<{ slug: string }>
}) {
  const { slug } = await params
  const post = await getPost(slug)
  if (!post) notFound() // Zwraca HTTP 404 — Google nie traktuje już URL jako problematyczny
 
  return <article>...</article>
}

Redirect — strona przekierowuje. W takiej sytuacji sprawdź, czy redirect jest celowy (301 permanent) i prowadzi do właściwego URL.

Błąd serwera 5xx — Google nie mógł pobrać strony z powodu problemu po stronie serwera, a w Next.js oznacza to by szukać wyjątków w Server Components, Route Handlers, middleware, integracji z CMS/API i limitów hostingu. Warto podkreślić, że jeśli błąd dotyczy ważnych URL-i, napraw go z najwyższym priorytetem.

Unauthorized / Forbidden — strona zwraca 401 albo 403 i jeśli to panel użytkownika, wszystko jest w porządku, ale jeśli to publiczny landing, blog albo produkt - sprawdź middleware, reguły auth, Basic Auth, WAF i blokady po user-agencie.

Redirect error — Google trafił na pętlę, zbyt długi łańcuch albo niepoprawne przekierowanie, co w Next.js oznacza niespójne reguły w next.config.js, middleware.ts, vercel.json, slash handling albo przekierowania domeny www / non-www.

Warto też podkreślić, że walka o 100% zaindeksowanych URL-i nie ma sensu, ponieważ Google nie musi indeksować filtrów, parametrów, duplikatów, starych redirectów i stron bez samodzielnej wartości. Celem jest to, żeby zaindeksowane były kanoniczne wersje najistotniejszych stron w witrynie, np stron usług, artykułów, kategorii, produktów i landing page'y.

URL Inspection: jak Google widzi stronę Next.js

GSC → URL Inspection → wklej URL strony.

Narzędzie pokazuje:

• Live Test — jak Google widzi stronę teraz (rendered HTML po JavaScript),
• Crawl info — status HTTP, czas crawlowania, rozmiar strony,
• Screenshot — jak Googlebot renderuje stronę (sprawdź, czy JavaScript się wykonał),
• User-declared link kanoniczny i Google-selected link kanoniczny — porównanie tego, co deklarujesz, z tym, co Google faktycznie wybrał.

Dla Next.js z SSR — screenshot powinien wyglądać jak pełna strona (nie puste div'y). Jeśli widzisz pustą stronę — problem z hydracją lub blokowaniem JS w robots.txt.

Ważna pułapka: pierwszy widok URL Inspection pokazuje ostatnią wersję znaną Google, a niekoniecznie aktualny stan produkcji. Jeśli przed chwilą wdrożyłeś poprawkę, kliknij Test Live URL i dopiero tam sprawdzaj bieżący HTML, status fetchowania, screenshot i zasoby. Live Test też nie jest wyrocznią — może powiedzieć, że URL da się zaindeksować, ale nie gwarantuje indeksacji ani nie przewidzi na pewno, jaki link kanoniczny Google wybierze po kolejnym crawl.

Test Live URL i weryfikacja streamingu w Next.js

Next.js ze streamingiem wysyła HTML w porcjach. Google renderuje stronę, ale przy krytycznych sekcjach zweryfikuj, co faktycznie trafiło do rendered HTML:

1. URL Inspection → Test Live URL,
2. View Tested Page → Rendered HTML,
3. Sprawdź, czy dynamiczne sekcje (Suspense boundaries) mają treść.

Jeśli w rendered HTML brakuje ważnej treści, problemem może być zbyt wolne pobieranie danych, błędy JS albo treść zależna wyłącznie od klienta. Rozwiązaniem jest trzymanie krytycznej treści w HTML z serwera, ograniczenie wolnych zależności w Server Components i rezygnacja z ukrywania najważniejszych sekcji za client-only renderingiem.

Core Web Vitals w GSC: dane od rzeczywistych użytkowników

GSC → Core Web Vitals → raport pokazuje LCP, INP i CLS z danych Chrome User Experience Report (CrUX).

To dane z prawdziwych użytkowników, a nie syntetyczne dane jak w Lighthouse. Raport dzieli strony na Mobile i Desktop, ze statusem: Good / Needs Improvement / Poor.

Tu są trzy ważne ograniczenia:

• raport nie pokazuje każdej strony, tylko URL-e z wystarczającą ilością danych CrUX,
• wyniki są grupowane dla podobnych stron, więc jeden przykład w raporcie może reprezentować całą grupę URL-i,
• status grupy wynika z najsłabszej metryki, dlatego dobry LCP nie uratuje grupy, jeśli INP albo CLS są słabe.

Brak danych w GSC nie oznacza, że strona jest szybka, ale że Google nie ma wystarczającej próbki danych. Dla mniejszych stron używaj wtedy PageSpeed Insights, Lighthouse, WebPageTest albo własnego Real User Monitoringu.

Typowe problemy Next.js widoczne w CrUX

Wysoki LCP na mobile — hero image bez preload w next/image, fonty z Google CDN zamiast next/font, render-blocking JS albo third-party scripts ładowane zbyt wcześnie.

INP > 200 ms — zbyt dużo Client Components, ciężkie hydration, event handlery blokujące main thread. Pełna skala: ≤200 ms = Good, 200–500 ms = Needs Improvement, >500 ms = Poor.

CLS > 0.1 — obrazy bez wymiarów (width/height), fonty bez size-adjust (nie next/font), dynamicznie ładowane reklamy/banery.

Raport Performance: frazy, kliknięcia i pozycje

GSC → Performance → najważniejszy raport SEO:

• Queries — na jakie frazy rankujesz, ile kliknięć, impressions, CTR i średnia pozycja,
• Pages — które strony generują ruch,
• Countries — skąd pochodzi ruch,
• Devices — mobile vs desktop.

Jak praktycznie używać danych z raportu Performance

Zainteresuj się frazami z wysokimi impressions, ale niskim CTR i popraw im meta title oraz description tak, żeby lepiej odpowiadały intencji. Przy wysokiej pozycji (top 10), ale niskim ruchu sprawdź, czy wynik nie konkuruje z reklamami, AI Overviews, featured snippets albo map packiem. Przy pozycjach 11–20 dodaj treść, internal links i realne przykłady, ponieważ te URL-e są blisko pierwszej strony i warto dać im w ten sposób małego "kopa".

Najbardziej praktyczny widok to nie samo Queries, tylko połączenie Query + Page, ponieważ ta sama fraza może prowadzić do kilku URL-i, a średnia pozycja na poziomie całej domeny potrafi ukryć kanibalizację. Jeśli Twoja witryna posiada podobne strony, które rankują na ten sam temat, zdecyduj, która ma być główna i wzmocnij ją linkowaniem albo rozważ połączenie lub przebudowę słabszej.

Do analizy trendów porównuj okresy, np. ostatnie 28 dni vs poprzednie 28 dni albo rok do roku przy sezonowości. Widok 24h jest przydatny po publikacji lub migracji, ale traktuj go jako świeży sygnał, nie pełny raport decyzyjny, ponieważ do stabilnych decyzji lepiej używać danych dziennych, tygodniowych i miesięcznych.

Warto też pamiętać, że kliknięcia i wyświetlenia z AI Overviews oraz AI Mode nie mają osobnego raportu w Search Console. W praktyce analizujemy je pośrednio w typie wyszukiwania Web, obserwując zmiany CTR, zapytań, stron i jakości ruchu w analityce.

Links w GSC: linki wewnętrzne i zewnętrzne

GSC → Links pokazuje, które strony mają najwięcej linków wewnętrznych i zewnętrznych. To dane oficjalnie od Google — inne niż Ahrefs czy Semrush, ale warto je porównywać.

Linki wewnętrzne w Google Search Console

Top linked pages — strony z największą liczbą linków wewnętrznych mają zazwyczaj największy autorytet w obrębie domeny. Jeśli ważna strona (usługa, kluczowy artykuł, kategoria) ma mało linków wewnętrznych, a słabsza strona ma ich dużo, wymaga to zmian i trzeba wyrównać to przez architekturę i odpowiednie linkowanie.

W Next.js szczególnie warto sprawdzić:

• czy strony dynamiczne ([slug]) są linkowane z kluczowych sekcji, nie tylko dostępne przez sitemap,
• czy nie ma tzw. orphan pages, czyli URL-ów w sitemapie bez żadnego linku wewnętrznego,
• czy po migracji lub reorganizacji struktury strony, linki wewnętrzne nie wskazują nieistniejących ścieżek.

Linki zewnętrzne i backlinki w GSC

GSC pokazuje domeny linkujące i konkretne linkowane URL-e, raport pomaga wykryć, czy nowe treści zdobywają backlinki oraz czy stare URL-e po migracji nadal zbierają linki oraz czy przekierowania działają poprawnie. Jeśli widzisz backlinki do URL-i, które nie istnieją (bez redirectu), to stracony autorytet do odzyskania przez 301.

Rich Results i dane strukturalne w Next.js

GSC → Search Appearance → Rich results to raport pokazujący, czy Google poprawnie parsuje dane strukturalne (JSON-LD) na stronie i czy kwalifikuje się do bogatych wyników w wyszukiwarce.

Dla Next.js najczęściej stosowane typy:

• Article / BlogPosting — artykuły blogowe,
• Product — karty produktów w e-commerce,
• FAQPage — sekcje FAQ,
• BreadcrumbList — ścieżka nawigacyjna,
• Organization / LocalBusiness — dane firmowe.

Raport pokazuje błędy i ostrzeżenia dla każdego typu, typowymi problemami są:

• Brakujące pola wymagane — np. brak datePublished w Article albo price w Product,
• Niezgodność z treścią strony — dane strukturalne muszą opisywać treść widoczną na stronie, a nie być wyłącznie metadanymi ukrytymi w HTML,
• Błąd parsowania JSON-LD — najczęściej literówka w składni lub nieprawidłowe enkodowanie znaków.

W Next.js dane strukturalne najwygodniej dodawać przez <script type="application/ld+json"> bezpośrednio w Server Component. Zanim zgłosisz sitemap nowej sekcji, sprawdź kluczowe typy stron w Rich Results Test — naprawienie błędów strukturalnych przed indeksacją jest łatwiejsze niż po.

Crawl Stats: kiedy problem leży po stronie serwera

GSC → Settings → Crawl stats to raport dla bardziej technicznych przypadków. Nie musisz zaglądać tam codziennie przy małej stronie usługowej, ale po migracji, wdrożeniu dużej sekcji contentu albo spadku indeksacji jest bardzo użyteczny.

Najważniejsze rzeczy do sprawdzenia:

• Host status — czy Google widzi problemy z dostępnością DNS, serwera albo robots.txt,
• Average response time — czy SSR/API/CMS nie spowalniają odpowiedzi dla Googlebota,
• Crawl responses — ile requestów kończy się 200, 301/308, 404, 5xx, 401/403 albo redirect error,
• File type — czy Google nie marnuje crawl budgetu na zasoby, które nie pomagają w indeksacji,
• Googlebot type — czy problem dotyczy crawlowania mobile, desktop, obrazów, wideo albo zasobów strony.

Dla Next.js szczególnie groźne mogą być przejściowe 5xx, ponieważ jeśli Server Component zależy od CMS-a, który czasem ma time-out, użytkownik może tego prawie nie zauważyć, ale Googlebot trafi na serię błędów i finalnie ograniczy crawl. W logach hostingu szukaj requestów Googlebota, statusów 500/502/504, czasu odpowiedzi i wyjątków z middleware.

Jeśli crawl rate nagle spada, sprawdź 3 rzeczy - czy nie dodałeś zbyt szerokiej reguły w robots.txt, czy serwer nie odpowiada wolniej oraz czy nie wzrosła liczba 5xx. Przy dużych serwisach aktualizuj sitemapę dla świeżych URL-i i zadbaj o odpowiednie linkowanie z ważnych stron.

Manual Actions i Security Issues w Google Search Console

Manual Actions, czyli ręczne działania Google

GSC → Manual Actions — jeśli Google nałożył karę manualną na stronę lub jej fragment (np. za spam, cloaking, nienaturalne linki), tu pojawi się komunikat, a przy braku naruszeń raport jest pusty. Po migracji domeny, rebrandingu albo po przejęciu starszej domeny warto sprawdzić ten raport jako jeden z pierwszych — kara manualna silnie blokuje widoczność niezależnie od technicznego stanu strony i nie jest widoczna w żadnym innym miejscu GSC.

Security Issues, czyli problemy bezpieczeństwa

GSC → Security Issues, czyli alerty o wykrytym malware, hackowanej treści, phishingu i social engineeringu. Jeśli zdarzy się, że Google wykryje problem - wysyła powiadomienie e-mail i może oznaczyć stronę w wynikach wyszukiwania. Jest to problem i należy reagować szybko.

W przypadku aplikacji Next.js z zewnętrznymi zależnościami (npm, CDN, third-party scripts) warto zaglądać do tego raportu regularnie, szczególnie po deployach z nowymi integracjami. Po naprawieniu problemu prześlij niezwłocznie request o review bezpośrednio w GSC, ponieważ Google musi ręcznie zweryfikować, że strona jest bezpieczna, zanim zdejmie ostrzeżenie z Twojej strony.

Problemy indeksacji specyficzne dla Next.js

Client-side navigation a crawling Google

Sam komponent Link nie jest problemem dla SEO, jeśli renderuje normalny link z href, Google znajdzie go tak jak każdy inny odnośnik w HTML-u. Problem zaczyna się natomiast wtedy, gdy ważne URL-e pojawiają się dopiero po wykonaniu JavaScriptu: po kliknięciu w filtr, po załadowaniu kolejnej porcji infinite scrolla, po odpowiedzi z API albo w komponencie renderowanym wyłącznie po stronie klienta.

Co prawda Googlebot potrafi renderować JavaScript, ale to dodatkowy etap pracy, ponieważ najpierw musi pobrać stronę, a potem uruchomić JS i następnie poczekać na dane - dopiero wtedy odkryje część linków. Przy małej stronie zwykle nie robi to dużej różnicy, ale nie jest efektywne w wypadku dużego serwisu i wpływa negatywnie na tempo odkrywania głębszych podstron - innymi słowy powoduje to wolniejszą indeksację całego serwisu. Gdy GSC pokazuje tylko spowolnienie, a nie jego przyczynę, warto zejść poziom niżej i sprawdzić logi Cloudflare oraz realne ścieżki Googlebota.

Dlatego najważniejsze URL-e powinny być dostępne bez zgadywania i bez czekania na interakcję użytkownika - w zwykłych linkach HTML, w sensownym linkowaniu wewnętrznym i w sitemapie.

generateStaticParams a indeksacja dynamicznych tras

Dynamiczne strony bez generateStaticParams mogą być renderowane on-demand, ale Google nadal musi je odkryć przez linki wewnętrzne lub poprzez sitemap. generateStaticParams pomaga pre-renderować znane ścieżki, ale nie dodaje ich automatycznie do sitemap, więc musisz wygenerować je osobno w app/sitemap.ts.

export async function generateStaticParams() {
  const posts = await getAllPosts()
  return posts.map((post) => ({ slug: post.slug }))
}

GSC to niezastąpione narzędzie diagnostyczne, ale nie jest systemem alertów — problemy z ruchem zauważasz w nim po fakcie, zwykle z kilkudniowym opóźnieniem. Jeśli zależy Ci na własnym radarze, który łapie anomalie dziennie, zanim ręcznie otworzysz raport, opisałem to w artykule o wykrywaniu anomalii SEO przez połączenie GSC z BigQuery i AI.