Optymalizacja Google Search Console w projektach Next.js

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 i tworzy usługę typu Domain. Obejmuje ona wszystkie subdomeny oraz warianty protokołu:

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

Weryfikacja przez meta tag w Next.js

Meta tag służy do weryfikacji usługi typu URL-prefix. Obejmuje tylko wskazany protokół i prefiks adresu, dlatego nie zastępuje weryfikacji domenowej, gdy chcesz analizować całą domenę.

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" oznacza, że Google odczytał sitemapę, ale nie gwarantuje zaindeksowania znajdujących się w niej URL-i,
3. Monitoruj liczbę wykrytych URL-i i porównuj ją z liczbą opublikowanych stron.

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

• Sitemap zwraca 404, więc 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, czyli trailing slash vs bez, www vs non-www → skonfiguruj przekierowania i spójne linkowanie, a następnie ustaw link kanoniczny. W sitemapie umieść wyłącznie warianty kanoniczne.

lastModified jest opcjonalne, ale może pomóc Google ustalać kolejność ponownego crawlowania, jeśli pozostaje wiarygodne. Przy blogu pobieraj updatedAt z CMS albo pliku MDX, a przy e-commerce używaj daty ostatniej istotnej zmiany produktu. Przy stronach programmatic SEO nie ustawiaj wszystkim URL-om dzisiejszej daty tylko dlatego, że przebudowałeś aplikację. Google może zacząć ignorować daty, które regularnie nie odpowiadają zmianom treści.

Duże sitemapy w Next.js

Jeden plik sitemap może zawierać maksymalnie 50 000 URL-i i mieć do 50 MB przed kompresją. Przy większym serwisie podziel adresy za pomocą generateSitemaps(). Osobne sitemapy dla artykułów, produktów lub wersji językowych ułatwiają też porównywanie liczby wykrytych i zaindeksowanych stron w GSC.

import type { MetadataRoute } from 'next'
 
const PAGE_SIZE = 50_000
 
export async function generateSitemaps() {
  const total = await countPublishedProducts()
  return Array.from({ length: Math.ceil(total / PAGE_SIZE) }, (_, id) => ({
    id,
  }))
}
 
export default async function sitemap({
  id,
}: {
  id: Promise<string>
}): Promise<MetadataRoute.Sitemap> {
  const sitemapId = Number(await id)
  const products = await getPublishedProducts({
    offset: sitemapId * PAGE_SIZE,
    limit: PAGE_SIZE,
  })
 
  return products.map((product) => ({
    url: `https://example.com/products/${product.slug}`,
    lastModified: product.updatedAt,
  }))
}

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 grupuje znane Google URL-e według stanu indeksacji. Nie jest to pełny spis wszystkich stron istniejących w aplikacji, dlatego dane z raportu porównuj z sitemapami i własną listą opublikowanych adresów. Zanim przejdziemy do statusów, warto zrozumieć cykl od odkrycia URL-a do pojawienia się w wynikach:

Każdy z kolejnych statusów w raporcie Pages odpowiada konkretnemu węzłowi w tym przepływie. 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łówek X-Robots-Tag i logikę środowiskową. Częsty błąd polega na pozostawieniu na produkcji dyrektywy dodanej wcześniej na stagingu.

• Zablokowana przez robots.txt. Sprawdź app/robots.ts, czy nie blokujesz ścieżek, które powinny być indeksowane. Google nie zobaczy noindex na stronie, której nie może pobrać, więc znany z linków URL nadal może pojawić się w wynikach bez opisu. Klasyczny robots.txt Tester został wycofany. W GSC korzystaj z raportu robots.txt w Settings, który pokazuje ostatnio pobraną wersję pliku oraz błędy i ostrzeżenia.

• Soft 404. Strona zwraca HTTP 200, ale Google interpretuje ją jak stronę błędu, ponieważ nie zawiera oczekiwanej treści. Zdarza się to w Next.js przy renderowaniu pustego stanu po braku danych. Wywołaj notFound() zamiast zwracać pustą stronę i sprawdzaj istnienie zasobu możliwie wcześnie.

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() // Kończy segment i dodaje noindex
 
  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. 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:

• Indexed URL, czyli ostatnią wersję znaną Google, datę crawlowania, możliwość indeksacji i Google-selected canonical.

• Live Test, czyli bieżącą dostępność strony, odpowiedź HTTP, możliwość crawlowania i rendered HTML po wykonaniu JavaScriptu.

• View Tested Page, czyli HTML, nagłówki odpowiedzi, błędy konsoli, załadowane zasoby i screenshot dostępny po teście live.

• User-declared link kanoniczny i Google-selected link kanoniczny. Porównaj je w raporcie wersji zaindeksowanej. Live Test nie przewiduje wyboru dokonywanego przez Google podczas indeksowania.

W Next.js z SSR screenshot powinien zawierać główną treść strony. Jeśli jest pusty lub niekompletny, sprawdź błędy JavaScriptu, blokowane zasoby, wymagane uwierzytelnienie oraz zależności od API uruchamiane dopiero w przeglądarce.

Pamiętaj, że pierwszy widok URL Inspection pokazuje ostatnią wersję znaną Google, a niekoniecznie aktualny stan produkcji, więc jeśli przed chwilą wdrożyłeś poprawkę, kliknij Test Live URL i dopiero tam sprawdzaj bieżący HTML, odpowiedź, screenshot i zasoby. Warto też zaznaczyć, że pozytywny wynik nie gwarantuje indeksacji. Test nie sprawdza między innymi jakości strony, ręcznych działań, zgłoszenia w sitemapie, duplikacji ani przyszłego wyboru linku kanonicznego.

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 wyniki pojedynczego testu Lighthouse. Raport dzieli strony na Mobile i Desktop, ze statusem Good, Needs Improvement albo Poor. Wartość metryki opisuje 75. percentyl wizyt z ostatnich 28 dni. Oznacza to, że co najmniej 75% zarejestrowanych wizyt osiągnęło podany wynik lub lepszy.

Tu są trzy ważne ograniczenia:

1. Raport nie pokazuje każdej strony, tylko URL-e z wystarczającą ilością danych CrUX,
2. Wyniki są grupowane dla podobnych stron, więc jeden przykład w raporcie może reprezentować całą grupę URL-i,
3. 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. Typowe przyczyny to 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. Najczęściej winne są zbyt liczne Client Components, ciężkie hydration i event handlery blokujące main thread. Pełna skala: ≤200 ms = Good, od 200 do 500 ms = Needs Improvement, >500 ms = Poor.

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

Raport Performance: frazy, kliknięcia i pozycje

GSC → Performance → najważniejszy raport SEO:

• Queries, czyli frazy, kliknięcia, impressions, CTR i średnią pozycję,
• Pages, czyli strony generujące ruch,
• Countries, czyli kraje, z których pochodzi ruch,
• Devices, czyli 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 od 11 do 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".

Nie traktuj jednak niskiego CTR jako automatycznego dowodu na słaby title. Wynik zależy też od rodzaju zapytania, urządzenia, kraju i układu strony wyników. Przed zmianą porównaj tę samą stronę i zapytanie w zbliżonych okresach oraz sprawdź, czy nie zmieniła się średnia pozycja.

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.

Raport Performance nie pokazuje całego surowego zbioru danych. Część zapytań jest anonimizowana, tabela ma ograniczoną liczbę wierszy, a większość danych zostaje przypisana do URL-a wybranego przez Google jako kanoniczny. Dlatego suma widocznych zapytań może być niższa od sumy na wykresie. Dla większych serwisów najpełniejszą analizę daje codzienny eksport danych do BigQuery.

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

GSC → Links pokazuje próbkę linków wewnętrznych i zewnętrznych wykrytych przez Google. Raport nie jest pełnym indeksem linków, a jego tabele mają limity, więc brak odnośnika w GSC nie dowodzi, że Google go nie zna.

Linki wewnętrzne w Google Search Console

Top linked pages. Raport pomaga sprawdzić, czy najważniejsze strony są łatwo dostępne w architekturze witryny. Sama liczba linków nie jest miarą autorytetu, ponieważ znaczenie ma także kontekst, źródło, tekst odnośnika i pozycja linku. Jeśli ważna usługa, kategoria lub artykuł ma niewiele linków, sprawdź nawigację i ścieżki prowadzące do tej strony.

W Next.js szczególnie warto sprawdzić:

• Czy strony dynamiczne ([slug]) są linkowane z kluczowych sekcji, a 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

Google Search Console udostępnia informacje o domenach linkujących oraz przykładowych adresach docelowych. Raport ten skutecznie pomaga w odszukaniu odnośników prowadzących do starych adresów po zakończonej migracji serwisu, jednak nie daje stuprocentowej gwarancji, że każdy z nich fizycznie nadal istnieje. Z tego powodu warto osobiście zweryfikować stronę źródłową, a jeśli usunięty URL posiada swój trafny odpowiednik w nowej strukturze, należy zastosować stałe przekierowanie bezpośrednio na ten adres.

Rich Results i dane strukturalne w Next.js

GSC pokazuje osobne raporty ulepszeń dla obsługiwanych typów danych strukturalnych, które Google wykrył w witrynie. Nie istnieje jeden raport obejmujący wszystkie typy schema.org. Brak raportu nie dowodzi również, że kod JSON-LD jest niepoprawny, ponieważ nie każdy typ danych tworzy bogaty wynik ani osobny raport w Search Console.

Dla stron zbudowanych w Next.js często stosuje się:

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

FAQPage nie kwalifikuje się już do FAQ rich results w Google Search, ponieważ Google wycofał tę funkcję 7 maja 2026 roku, a w czerwcu usunął jej dokumentację. Sekcja FAQ nadal może być wartościowa dla użytkownika, ale nie należy obiecywać na jej podstawie rozszerzonego wyniku wyszukiwania.

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

• Brakujące właściwości wymagane dla konkretnego rich result. Wymagania zależą od typu i funkcji. Dla Article Google nie określa obecnie pól wymaganych, lecz zaleca uzupełnienie między innymi autora, dat i obrazów.

• Niezgodność z treścią strony, ponieważ 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. Sprawdź kluczowe typy stron w Rich Results Test, a następnie użyj URL Inspection, żeby zweryfikować wersję wyrenderowaną przez Google. Poprawny test oznacza możliwość przetworzenia danych, ale nie gwarantuje wyświetlenia bogatego wyniku.

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.

Google kieruje ten raport do zaawansowanych użytkowników i zaznacza, że przy witrynie mającej mniej niż około tysiąca stron zwykle nie trzeba analizować crawlowania na tym poziomie. Crawl budget staje się realnym tematem głównie w dużych albo bardzo często aktualizowanych serwisach.

Najważniejsze rzeczy do sprawdzenia:

1. Host status. Czy Google widzi problemy z dostępnością DNS, serwera albo robots.txt,
2. Average response time. Czy SSR/API/CMS nie spowalniają odpowiedzi dla Googlebota,
3. Crawl responses, czyli ile requestów kończy się 200, 301/308, 404, 5xx, 401/403 albo redirect error,
4. File type. Jakie rodzaje dokumentów i zasobów dominują w żądaniach oraz pobranych danych,
5. 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. Nie ufaj samemu nagłówkowi User-Agent, ponieważ można go podrobić. Potwierdź Googlebota przez opublikowane zakresy IP albo weryfikację reverse DNS i forward DNS.

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 pokazuje kary manualne nałożone na stronę lub jej fragment, np. za spam, cloaking albo nienaturalne linki. Przy takim problemie 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 Google wykryje problem, wysyła powiadomienie e-mail i może oznaczyć stronę w wynikach wyszukiwania. To wymaga szybkiej reakcji.

W przypadku aplikacji Next.js z zewnętrznymi zależnościami, CDN i skryptami firm trzecich warto zaglądać do tego raportu regularnie, szczególnie po wdrożeniach z nowymi integracjami. Po usunięciu wszystkich skutków ataku i zamknięciu jego źródła prześlij request o review bezpośrednio w GSC. Google ponownie oceni witrynę przed zdjęciem ostrzeżenia.

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.

Google Search renderuje JavaScript i samo użycie kodu po stronie klienta nie oznacza gorszej indeksacji. Problem pojawia się wtedy, gdy link nie istnieje jako element <a href="...">, wymaga działania użytkownika albo nie trafia do DOM z powodu błędu skryptu, blokady zasobu lub niedostępnego API. W takich przypadkach Google może nie odkryć adresu mimo poprawnego wyglądu strony w zwykłej przeglądarce. Gdy GSC nie pokazuje przyczyny, sprawdź 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. Umieść je 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 }))
}

Szybka diagnostyka spadku widoczności

Zakres spadku podpowiada, od którego raportu zacząć:

1. Cała witryna. Porównaj okresy w Performance, sprawdź Manual Actions, Security Issues, dostępność hosta, ostatnie wdrożenia i globalne dyrektywy robots.
2. Katalog lub typ stron. Użyj filtra Page z wyrażeniem regularnym, porównaj odpowiednią sitemapę i sprawdź wspólny szablon, link kanoniczny oraz linkowanie wewnętrzne.
3. Pojedynczy URL. Porównaj wersję zaindeksowaną z Live Test, odpowiedź HTTP, rendered HTML, dyrektywy indeksowania i oba linki kanoniczne.

Taki podział ogranicza przypadkowe poprawianie pojedynczych stron, gdy źródłem problemu jest wspólny layout, middleware, CMS albo konfiguracja domeny.

GSC wysyła powiadomienia o wybranych błędach, ale nie jest kompletnym systemem monitoringu w czasie rzeczywistym. Problemy z ruchem często zauważysz dopiero z opóźnieniem. Jeśli zależy Ci na własnym radarze, który łapie anomalie codziennie, opisałem to w artykule o wykrywaniu anomalii SEO przez połączenie GSC z BigQuery i AI.