Jak diagnozować problemy z indeksacją nowych podstron

Nowa podstrona, a Google jej nie widzi – każdy SEO-wiec prędzej czy później mierzy się z tym scenariuszem. Zamiast bez końca klikać przycisk proszenia o zaindeksowanie, warto systematycznie przejść przez pełny łańcuch sygnałów technicznych i treściowych. Od serwera i dyrektyw, przez architekturę informacji, po jakość oraz sposób generowania zawartości – każdy element może zablokować lub spowolnić indeksacja. Poniżej znajdziesz proces diagnozy, który pozwala precyzyjnie namierzyć faktyczną przyczynę.

Mapowanie problemu: sygnały z narzędzi i szybka diagnoza

Raporty Search Console: statusy i co znaczą

Punktem wyjścia jest zebranie faktów. Zanim poprawisz cokolwiek w witrynie, wylistuj wszystkie nowe URL-e i sprawdź ich statusy w Google Search Console. Najczęstsze stany to: Odkryto, ale nie zindeksowano; Zindeksowano, mimo że zablokowano w robots.txt; Duplikat – przesłana strona nie jest kanoniczna; Strona z przekierowaniem; Nie znaleziono (404); Miękki 404; Wykluczono przez tag noindex; Zablokowano przez robots.txt; Crawlowano – aktualnie nie zindeksowano. Każdy z nich wskazuje na inną kategorię przyczyn i nakieruje Cię na kolejne kroki.

Status Odkryto, ale nie zindeksowano oznacza, że bot zna URL, ale nie uznał go jeszcze za wart zasobów. Przy niskim autorytecie, słabym linkowaniu wewnętrznym albo niskiej jakości treści to typowy objaw. Status Crawlowano – aktualnie nie zindeksowano bywa sygnałem jakościowym: treść jest zbyt cienka, wtórna lub brakuje jej sygnałów użyteczności. Z kolei Zindeksowano, mimo że zablokowano w robots.txt to klasyczny skutek publikowania adresów w publicznych miejscach – Google może znać URL, ale nie wejdzie, jeśli plik robots.txt go blokuje; w indeksie może jednak pozostać wersja bez treści.

Test adresu URL na żywo i różnice desktop/mobile

Narzędzie Inspekcji adresu URL pozwala uruchomić test na żywo i porównać wersję zaindeksowaną z aktualną. To tu szybko zobaczysz przekierowania, nagłówki, problemy z meta robots, a także czy zasoby CSS/JS są dostępne dla smartfonowego bota (domyślny user-agent Google). Koniecznie sprawdź renderowaną wersję HTML: jeżeli istotna treść pojawia się dopiero po interakcji, wstrzyknięciu przez ciężki skrypt lub pobraniu danych z API, Google może nie dotrzeć do kluczowych elementów. Wykryte różnice między desktop a mobile często tłumaczą, czemu wersja mobilna nie jest pełna i finalnie strona nie trafia do indeksu.

Porównanie z logami serwera

Bez danych z serwera trudno odróżnić brak zainteresowania botów od problemu dostępowego. Analiza plików logi (z filtrem na user-agenta Googlebota i weryfikacją reverse DNS) pokaże: czy adres był crawlowany; jak często; jakie kody HTTP zwracał; czy wystąpiły błędy czasowe, 5xx, 429 lub przekierowania pętlowe. Jeśli w logach nie ma śladu po nowej podstronie, przyczyną może być brak linków prowadzących do niej, nadmierna głębokość, niska wartość sygnałów lub błędy w mapie witryny. Jeżeli wejścia są, a indeksacji brak, przyczynę najczęściej znajdziesz w dyrektywach, jakości treści lub duplikacji.

Kolejność reakcji: kiedy prosić o indeksację

Przycisk Poproś o zindeksowanie ma sens dopiero po usunięciu blokad technicznych i zapewnieniu właściwej jakości. Lepiej zainwestować czas w: poprawę linkowania wewnętrznego; dodanie URL do mapy witryny; sprawdzenie dyrektyw; usunięcie błędów 4xx/5xx; a następnie poprosić o indeksację jedynie dla kluczowych adresów. Jeżeli mimo to strona nie wchodzi do indeksu, wróć do dzienników i GSC – poszukaj komunikatów o przeciążeniu hosta, ograniczeniu tempa crawl czy trwale powracających soft 404.

Dostępność techniczna: serwer, HTTP i dyrektywy

Kody odpowiedzi i edge case’y

Nowa podstrona musi zwracać spójny, szybki i jednoznaczny status HTTP 200. Powszechne pułapki to:

• Przekierowania 302 zamiast 301 – tymczasowe przekierowania wydłużają proces, a w niektórych konfiguracjach prowadzą do utraty sygnałów.
• Łańcuchy i pętle – więcej niż jedno przekierowanie obniża szanse na dogłębną analizę treści.
• Miękki 404 – strona niby 200, ale treść lub szablon sugeruje, że zasób nie istnieje (np. brak unikatowej zawartości, komunikat o braku produktu bez alternatyw).
• Błędy 5xx i 503 – krótkotrwale akceptowalne przy pracach, lecz nadużywane sygnalizują niestabilność hosta; częsta przyczyna wstrzymania indeksacji.
• 429 Too Many Requests – limity WAF/CDN, rate limiting lub API po stronie aplikacji. Google ograniczy próby, cofając priorytet.
• 401/403 – autoryzacja lub blokada geograficzna. Jeśli Google nie może pobrać treści, nie zindeksuje jej.

Stabilność TTFB i brak timeoutów są równie ważne jak sam kod statusu. Zbyt wolny pierwszy bajt prowadzi do crawl anomalies lub przerwania sesji. Dbaj o cache po stronie serwera, CDN dla statycznych zasobów, oraz niewielką liczbę blokujących zapytań do bazy.

robots.txt, meta robots, X-Robots-Tag, canonical i pułapki

Sprawdź trzy warstwy dyrektyw: plik robots.txt, meta robots w HTML oraz nagłówek X-Robots-Tag. Zasada pierwsza: robots.txt nie służy do wykluczania duplikatów, a do zarządzania dostępnością crawl; jeśli zablokujesz adres, Google nie wejdzie, nie odczyta metatagów i może utrzymać go w indeksie bez podglądu treści. Aby definitywnie wyłączyć indeks, stosuj noindex (meta lub X-Robots-Tag) na stronach dostępnych do pobrania.

Relacje kanoniczne bywają źródłem paradoksów. Gdy nowa strona wskazuje canonical na inny URL (np. listę zamiast detalu), Google z dużym prawdopodobieństwem wybierze tamten jako reprezentanta i pominie nowy adres. Upewnij się, że canonicale są samowystarczalne i nie tworzą łańcuchów ani pętli. Nie kanonikalizuj do stron z parametrami lub przekierowaniami. W przypadku wersji wydruków, sortowań czy filtrów – albo noindex, albo canonical do wersji podstawowej, ale nie jednocześnie sprzeczne instrukcje.

Weryfikuj również nagłówki HTTP: X-Robots-Tag może być ustawiony na poziomie serwera lub CDN i przypadkowo dziedziczony przez nowe ścieżki. To częsta przyczyna niewidoczna w kodzie HTML. W systemach headless pamiętaj, że polityka może być różna dla assetów i HTML – blokada CSS lub JS przez dyrektywy może utrudnić Google zrozumienie układu strony.

Blokady na poziomie infrastruktury: WAF, CDN, IP, cookies

Systemy bezpieczeństwa potrafią uznać Googlebota za źródło nietypowego ruchu. Zweryfikuj logikę WAF/CDN: whitelistuj znane zakresy i włącz weryfikację reverse DNS dla Googlebota. Upewnij się, że reguły ograniczające ruch nie są aktywne dla ścieżek z nowymi treściami. Sprawdź też, czy podstrona nie wymaga zaakceptowania bannera cookies do wyświetlenia podstawowej treści – jeśli DOM bez interakcji nie zawiera kluczowych elementów, bot nie znajdzie kontekstu. Uwaga na geoblokady: jeżeli serwer odrzuca ruch z regionów crawlerów, indeksu nie będzie.

W pamięci podręcznej CDN i przeglądarek może pozostawać zasób z innymi dyrektywami. Skontroluj cache-control, vary i ETag – zbyt agresywne bufory utrudniają zobaczenie aktualnego stanu. Krótko: najpierw pozwól botom łatwo dotrzeć do stabilnej i poprawnej wersji.

Sitemapy i odkrywanie adresów

Mapa witryny powinna wskazywać tylko adresy zwracające 200 i będące indeksowalne. Usuń z niej przekierowania, noindex i 4xx. Utrzymuj lastmod zgodny z realnymi zmianami – nadużywanie tej daty obniża wiarygodność. Dla dużych serwisów podziel mapę na sekcje tematyczne, aby szybciej wykrywać anomalie (np. część produktowa vs. poradnikowa). Kompresuj, lecz pamiętaj o limitach rozmiaru i liczby URL-i.

Nie polegaj wyłącznie na mapie: silne linkowanie wewnętrzne jest równie ważnym sygnałem do odkrycia adresu. Linki muszą być widoczne w HTML i łatwo parsowalne. Dodanie URL do sitemap przy braku odniesień w nawigacji i treści rzadko wystarczy, zwłaszcza w niskim autorytecie domeny.

Architektura informacji i linkowanie wewnętrzne

Głębokość kliknięć, PageRank wewnętrzny i priorytety

Nowe strony stoją w kolejce: im dalej od strony startowej i kluczowych hubów tematycznych, tym mniejsza szansa na szybkie odwiedziny crawlera. Planuj architekturę tak, aby krytyczne podstrony były osiągalne w 2–3 kliknięciach. W praktyce: dodaj linki z kategorii, tagów, powiązanych artykułów, breadcrumbów i stron listujących. Zadbaj o sensowną dystrybucję wewnętrznego PageRank poprzez linki kontekstowe, a nie tylko menu globalne.

Jeżeli podstrona jest częścią kampanii lub ważnego klastra tematycznego, dołącz ją do istniejących przewodników i hubów. Sygnał popularności (wejścia, interakcje, linki) przyspiesza decyzje Google – choć nie jest bezpośrednim czynnikiem indeksacji, koreluje z zainteresowaniem botów. Dobrze zaprojektowane sekcje Najnowsze lub Ostatnio aktualizowane w hubach tematycznych realnie pomagają.

Sieroty, parametry i facety: kontrola duplikacji

Strony-sieroty nie mają żadnych linków wewnętrznych – w efekcie nie są odkrywane, a nawet jeśli są, mogą być ignorowane. Wyłapiesz je, porównując crawl własny (np. z użyciem crawlera desktopowego) z danymi z logów: URL-e widoczne w logach lub mapach, a niewidoczne w crawl, to sygnał problemu. Z linkowaniem parametrycznym i fasetami unikaj eksplozji kombinacji: sortowanie, zakresy cen, kolory, lokalizacje. Używaj canonical do wersji podstawowej i meta robots noindex dla wariantów, które nie niosą unikatowego zapytania użytkownika.

Nie próbuj walczyć z duplikacją wyłącznie przez robots.txt – to zablokuje wejście bota i uniemożliwi mu zrozumienie relacji kanonicznych. Dla facetów, które mają wartość wyszukiwaniową (np. kategoria + kluczowy filtr), przygotuj dedykowane landing page z unikalnymi nagłówkami, opisami i linkowaniem – wtedy masz argument za indeksacją tych konkretnych wariantów.

Nawigacja i JS: jak zapewnić odkrywalność linków

Linki muszą być standardowymi anchorami z a href i możliwym do odczytania URL-em. Elementy klikalne renderowane przez framework, które nie generują klasycznego linku w HTML po stronie serwera, bywają niewidoczne dla botów. Upewnij się, że krytyczne ścieżki mają fallback w postaci serwowania pełnego HTML bez konieczności interakcji. Wewnątrz list i siatek produktów stosuj paginację, która generuje prawdziwe adresy – unikanie infinity scroll bez SSR skutkuje brakiem odkrycia części elementów.

Anchor text powinien być opisowy; unikaj ogólników. Wewnętrzne linki kontekstowe między powiązanymi treściami budują semantykę i pomagają w decyzji o indeksacji nowych zasobów.

Hreflang, kanonikalizacja i międzynarodowe warianty

W projektach wielojęzycznych i wieloregionalnych problemy z indeksacją nowych podstron często wynikają z konfliktu hreflang z canonical. Zasada: każda wersja językowa kanonikalizuje do samej siebie i wskazuje alternatywy przez hreflang, a nie do wersji nadrzędnej. W mapach hreflang smapuj pełne zestawy ekwiwalentów – brak wzajemności lub rozbieżne canonicale prowadzą do deprecjacji niektórych wariantów. Jeżeli masz subdomeny lub katalogi językowe, zadbaj o spójność struktury i linkowania między nimi.

Renderowanie i jakość treści: wpływ na zaindeksowanie

JavaScript i rendering: SSR, ISR, prerendering

Google stosuje dwuetapowy proces: najpierw pobiera dokument HTML, potem w kolejce renderuje skrypty. Jeżeli kluczowa treść powstaje dopiero w przeglądarce, indeksacja może się opóźnić lub nie dojść do skutku. Zastosuj serwowanie po stronie serwera (SSR), incremental static regeneration (ISR) lub wiarygodny prerendering dla krytycznych szablonów. Sprawdź, czy przy renderowaniu nie ma zależności od localStorage, cookies, zdarzeń przewinięcia, czy interakcji użytkownika. Upewnij się, że podstawowe linki i nagłówki są obecne w HTML bez konieczności wykonania JavaScript.

W Inspekcji adresu URL porównaj kod HTML zrenderowany przez Google z tym, co widzi przeglądarka. Jeżeli znikają elementy tytułu, opisy, dane strukturalne lub nawigacja, problemem jest pipeline renderujący. Dobrym testem jest też użycie prostych narzędzi tekstowych do pobrania strony – jeśli treści nie ma w surowym HTML, bot może mieć ten sam kłopot.

Blokowane zasoby, CLS, LCP i budżet renderowania Google

Nawet przy działającym SSR dostęp do zasobów ma znaczenie. Zablokowane CSS/JS w robots.txt lub poprzez reguły serwera utrudniają zrozumienie układu. Jeśli arkusze stylów lub skrypty kluczowe dla szablonu mają statusy 403/404, Google widzi zdegradowaną wersję. Wysokie opóźnienia i niestabilny układ (CLS) mogą zwiększyć koszty przetwarzania – Google potrafi odłożyć renderowanie w czasie, a tym samym decyzję o indeksacji. Optymalizuj łańcuchy zasobów, minimalizuj zależności, włącz HTTP/2 i kompresję br, dbaj o preconnect i preload dla krytycznych plików.

Jeżeli Twoja platforma korzysta z hydratacji, monitoruj błędy w konsoli i sprawdź degradację w przypadku niepowodzenia JS. Dobre praktyki to serwowanie treści krytycznych w HTML, a warstw interaktywnych jako progresywne uzupełnienie. Nie opieraj podstawowych linków na eventach kliknięcia, które nie działają bez skryptów.

Jakość i unikalność: kiedy Crawlowano – aktualnie nie zindeksowano

Gdy aspekty techniczne są poprawne, a wciąż widzisz komunikaty o braku indeksacji, problem najczęściej leży w jakości. Krótkie, wtórne lub automatycznie generowane opisy, duży udział tekstów zduplikowanych z innych miejsc witryny, brak wartości dodanej – wszystko to obniża priorytet. Zadbaj o unikalne nagłówki, wyczerpujące treści, media własne, tabelaryczne dane, FAQ i linkowanie do źródeł. Dodaj dane strukturalne adekwatne do typu strony (np. Article, Product, FAQPage), aby ułatwić zrozumienie kontekstu. Pamiętaj, że sygnały zewnętrzne – nawet jeden jakościowy link – potrafią przechylić szalę.

W e‑commerce typowa pułapka to setki wariantów produktu różniących się detalem, bez widocznej różnicy w opisie. Wydzielaj landing page tylko dla wariantów mających popyt, resztę konsoliduj kanonicznie. Unikaj autopublikacji skeletonów stron bez contentu. Google bywa zachowawczy po fali niskiej jakości publikacji – nowy URL musi pokazać, że zasługuje na indeks.

Procedury wdrożeń: staging, noindex i checklista

Najbardziej przyziemne błędy są najczęstsze. Oto lista kontroli przed i po publikacji nowych podstron:

• Usuń globalne noindex, które mogło pozostać po środowisku staging. Sprawdź też X-Robots-Tag na poziomie serwera i CDN.
• Zweryfikuj canonical: rel=canonical do samego siebie, brak łańcuchów i wskazań na adresy z parametrami lub przekierowaniami.
• Dodaj linki wewnętrzne z miejsc o wysokim autorytecie i ruchem. Unikaj pozostawiania stron jako sierot.
• Dopisz adresy do mapy witryny i pingnij endpoint Google dla sitemap po większym wdrożeniu.
• Sprawdź kody odpowiedzi (200), brak miękkich 404 i czas odpowiedzi serwera pod obciążeniem.
• Zweryfikuj dostępność zasobów CSS/JS i brak blokad w robots.txt dla ścieżek zasobów.
• Uruchom inspekcję na żywo, porównaj HTML zrenderowany i surowy, oceń obecność kluczowej treści.
• Zabezpiecz reguły WAF/CDN, aby nie limitowały Googlebota; sprawdź reverse DNS.
• Upewnij się, że treść jest kompletna, unikalna i odpowiada na konkretne intencje użytkownika.
• Złóż prośbę o indeksację tylko dla priorytetowych adresów i monitoruj logi przez kilka dni.

W codziennej praktyce największy zysk przynosi dyscyplina: każdy nowy szablon przechodzi te same testy, a każdy rollout ma checklistę cofającą „tymczasowe” ustawienia. Dzięki temu ograniczasz przypadkowe blokady, skracasz czas do pierwszego crawlu i usuwasz z drogi bariery, zanim wpłyną na szeroką skalę.

Jeśli mimo przejścia całej ścieżki problem pozostaje, przyjrzyj się zależności treści od zewnętrznych usług: API wolne lub niestabilne, które opóźnia konstrukcję DOM, może powodować, że Google zobaczy pustą stronę. W takiej sytuacji rozważ cache na serwerze, SSR lub asynchroniczną strategię wyświetlania (najpierw treść, potem dane wtórne). W raportach i dziennikach szukaj korelacji między czasem odpowiedzi a datami prób odwiedzin bota – to tam najczęściej kryje się realna przyczyna wstrzymania renderowanie i decyzji o indeksie.

Pamiętaj też o rzadziej spotykanych, lecz istotnych przypadkach: strony chronione hasłem, wymagające tokenów, gated content zależny od paywalla lub A/B testy wpływające na dyrektywy. Testuj jako niezalogowany użytkownik i jako bot – narzędzia typu cURL lub prosty fetch bez ciasteczek pokażą, czy serwujesz tę samą wersję. Gdy wdrożysz poprawki, daj Google czas – sygnały o zmianach propagują się od mapy witryny, przez linkowanie, po realny crawl i aktualizację stanu w indeksie.

Podsumowując proces diagnostyczny w praktyce: najpierw narzędzia i logi, później dyrektywy i HTTP, następnie architektura i linki, na końcu jakość treści i mechanika frontendu. Taki porządek minimalizuje „strzelanie w ciemno” i pozwala precyzyjnie uchwycić wąskie gardło: czy to dyrektywa, błąd serwera, brak odniesień, czy po prostu niedostateczna wartość materiału. Dopiero gdy każdy z tych etapów jest czysty, prośba o indeksację ma realną siłę przebicia.