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

Dlaczego GSC jest niezbędne?

Trudno wyobrazić sobie współczesną analitykę bez (GSC), czyli podstawowego narzędzia pokazującego dane bezpośrednio z Google Search. PageSpeed Insights mierzy wydajność, Ahrefs śledzi backlinki, ale GSC pokazuje całą paletę danych (ale też problemów/błędów) dotyczących strony internetowej. Przykładowo, które strony są zaindeksowane, jakie błędy crawlowania występują, na jakie frazy rankujesz i jakie wyniki mają istniejący użytkownicy.

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

Weryfikacja własności

Metoda DNS (rekomendowana)

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

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

Metoda meta tag

Code

// app/layout.tsx
export const metadata = {
  verification: {
    google: 'twoj-kod-weryfikacyjny',
  },
}

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

Sitemapa - zgłoszenie i monitoring

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

GSC → Sitemaps → dodaj https://strivelab.pl/sitemap.xml,
Sprawdź status — „Success" z liczbą wykrytych URL-ów,
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 .

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, canonical i 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 canonicale potrafią rozbić indeksację na kilka wariantów tej samej strony. Bałagan gotowy.

Indeksacja — raport „Strony"

GSC → Pages → raport pokazuje status każdej strony:

Statusy i co z nimi robić

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 , duplikacje treści, słaby canonical, niewiele unikalnej wartości albo HTML, który po renderowaniu wygląda biedniej niż zakładasz. W Next.js sprawdź rendered HTML w , canonical oraz to, czy główna treść nie zależy wyłącznie od Client Componentu.

Duplikat bez wskazanego canonical — 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 canonical, 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 canonical 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. W GSC możesz też skorzystać z wbudowanego testera robots.txt (Settings → Crawl stats → robots.txt tester), żeby zweryfikować reguły bez guessowania.

— 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.

Code

// DOBRZE — 404 gdy brak danych
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
 
  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ę

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 canonical i Google-selected canonical — 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 canonical Google wybierze po kolejnym crawl.

Test Live URL — weryfikacja streamingu

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

URL Inspection → Test Live URL,
View Tested Page → Rendered HTML,
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 — dane na podstawie rzeczywistych użytkowników

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

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 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.

Performance — frazy 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.

Praktyczne użycie danych

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 — 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

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 (backlinki)

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 — dane strukturalne

GSC → Search Appearance → Rich results to raport pokazujący, czy Google poprawnie parsuje dane strukturalne () 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 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

Manual Actions

GSC → — 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.

Poza tym, mogę dodać, że Manual Action to jeden z najpoważniejszych komunikatów, jakie możesz zobaczyć w Google Search Console. Nie oznacza błędu technicznego, tylko ręczną interwencję Google wobec strony.

Security Issues

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 specyficzne dla Next.js

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.

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

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.

Code

// Generuj statyczne strony — Google je znajdzie łatwiej
export async function generateStaticParams() {
  const posts = await getAllPosts()
  return posts.map((post) => ({ slug: post.slug }))
}

Podsumowanie

Google Search Console to obowiązkowe narzędzie dla każdej strony, nie tylko dla opartej na Next.js. Weryfikacja DNS, zgłoszenie sitemap, monitoring indeksacji, URL Inspection do sprawdzania rendered HTML i Core Web Vitals z danych od rzeczywistych użytkowników — to wszystko fundamenty technicznego SEO. Bez GSC trudno mieć to wszystko pod kontrolą, szczególnie w początkowym okresie istnienia witryny, kiedy może pojawić się większa liczba błędów, niedopatrzeń czy innych "niespodzianek".

Jeśli miałbym wymienić najczęstsze problemy Next.js w GSC to soft 404 (brak notFound()), brakujące strony w sitemap, orphan pages bez linków wewnętrznych, błędy w danych strukturalnych w Rich Results, wysoki LCP na mobile (np. brak preload na hero image) i CLS z fontami lub dynamicznymi elementami bez zarezerwowanego miejsca. Warto też regularnie zaglądać do Manual Actions i Security Issues — te raporty są pomijane, a potrafią blokować całą widoczność strony.

Najczęściej zadawane pytania

Jak często sprawdzać GSC?

Cotygodniowy przegląd raportu Pages w poszukiwaniu nowych błędów i Performance (zmiany pozycji), a Core Web Vitals co kilka tygodni. W wypadku nowych stron, można sprawdzać nieco częściej i reagować odpowiednio szybko na błędy.

Czy GSC pokazuje dane w czasie rzeczywistym?

Nie. Raport Performance ma widok ostatnich 24 godzin z danymi wstępnymi, ale standardowo dane mają opóźnienie 2–3 dni i mogą być jeszcze aktualizowane po tym czasie. Core Web Vitals opierają się na danych CrUX w 28-dniowym oknie rolling — po deployu poprawki performance musisz czekać kilka tygodni, żeby wynik ustabilizował się w raporcie. Raport indeksacji (Pages) aktualizuje się szybciej, ale też nie jest to real-time.

Jak przyspieszyć indeksację nowej strony?

URL Inspection → Request Indexing pomaga przy pojedynczych ważnych URL-ach, ale nie da nam gwarancji indeksacji - strona musi być odpowiednio napisana, treść musi spełniać wyznaczone przez Google normy etc. Dla wielu stron istotna jest aktualna sitemapa z poprawnym lastmod, odpowiednie linkowanie wewnętrzne i sensowna architektura informacji. Zwykle efekty zgłoszenia mogą pojawić się po dniu lub kilku dniach, czasem trwa to dłużej.

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

Dlaczego GSC jest niezbędne?

Weryfikacja własności

Metoda DNS (rekomendowana)

Metoda meta tag

Sitemapa - zgłoszenie i monitoring

Indeksacja — raport „Strony"

Statusy i co z nimi robić

URL Inspection — jak Google widzi stronę

Test Live URL — weryfikacja streamingu

Core Web Vitals — dane na podstawie rzeczywistych użytkowników

Typowe problemy Next.js w CrUX

Performance — frazy i pozycje

Praktyczne użycie danych

Links — linki wewnętrzne i zewnętrzne

Linki wewnętrzne

Linki zewnętrzne (backlinki)

Rich Results — dane strukturalne

Crawl Stats — kiedy problem leży po stronie serwera

Manual Actions i Security Issues

Manual Actions

Security Issues

Problemy specyficzne dla Next.js

Client-side navigation, a crawling

`generateStaticParams`, a indeksacja

Podsumowanie

Najczęściej zadawane pytania

Jak często sprawdzać GSC?

Czy GSC pokazuje dane w czasie rzeczywistym?

Jak przyspieszyć indeksację nowej strony?

Źródła i dokumentacja

Czytaj dalej

WordPress → Next.js — migracja treści, redirecty 301 i zachowanie pozycji SEO

Sanity CMS + Next.js — od instalacji po live preview i Visual Editing

Hreflang i canonical w Next.js — SEO wielojęzycznych stron bez duplikacji

Dlaczego GSC jest niezbędne?

Weryfikacja własności

Metoda DNS (rekomendowana)

Metoda meta tag

Sitemapa - zgłoszenie i monitoring

Indeksacja — raport „Strony"

Statusy i co z nimi robić

URL Inspection — jak Google widzi stronę

Test Live URL — weryfikacja streamingu

Core Web Vitals — dane na podstawie rzeczywistych użytkowników

Typowe problemy Next.js w CrUX

Performance — frazy i pozycje

Praktyczne użycie danych

Links — linki wewnętrzne i zewnętrzne

Linki wewnętrzne

Linki zewnętrzne (backlinki)

Rich Results — dane strukturalne

Crawl Stats — kiedy problem leży po stronie serwera

Manual Actions i Security Issues

Manual Actions

Security Issues

Problemy specyficzne dla Next.js

Client-side navigation, a crawling

generateStaticParams, a indeksacja

Podsumowanie

Najczęściej zadawane pytania

Jak często sprawdzać GSC?

Czy GSC pokazuje dane w czasie rzeczywistym?

Jak przyspieszyć indeksację nowej strony?

Źródła i dokumentacja

Czytaj dalej

WordPress → Next.js — migracja treści, redirecty 301 i zachowanie pozycji SEO

Sanity CMS + Next.js — od instalacji po live preview i Visual Editing

Hreflang i canonical w Next.js — SEO wielojęzycznych stron bez duplikacji

`generateStaticParams`, a indeksacja