Crawled - currently not indexed: co to znaczy i kiedy warto się tym zajmować

Otwierasz Google Search Console, wchodzisz w raport indeksowania i widzisz status Crawled - currently not indexed. Sto adresów, dwieście, czasem więcej. Pierwsza reakcja: coś jest zepsute. Druga: trzeba to naprawić od razu. Obie reakcje są przedwczesne.

Ten status oznacza dokładnie to, co mówi. Googlebot odwiedził adres, przeczytał treść, ale nie zdecydował się dodać jej do indeksu. To nie błąd techniczny w rozumieniu 404 czy 500. To decyzja algorytmu, że dana strona nie zasługuje na miejsce w wynikach - przynajmniej teraz.

Czym różni się to od innych statusów

W raporcie Coverage masz kilka podobnych, ale nie identycznych kategorii. Discovered - currently not indexed znaczy, że Google widzi adres w sitemapie albo w linkach, ale jeszcze nie zdążył go odwiedzić. To problem budżetu crawlowania albo priorytetów.

Crawled - currently not indexed to krok dalej. Bot był, treść przeczytał, ocenił i odłożył na bok. To ważne rozróżnienie, bo naprawa w obu przypadkach jest inna. W pierwszym pracujesz nad tym, żeby bot w ogóle trafił na stronę. W drugim - nad tym, żeby uznał ją za wartą pokazania.

Jest też Excluded by noindex - to sytuacja, w której sam poprosiłeś Google, żeby strony nie indeksował. Często okazuje się, że część adresów z „crawled not indexed” ma w tle właśnie tag noindex wysłany przypadkiem albo przez błąd w szablonie.

Pierwsze, co sprawdzam: czy to faktycznie problem

Zanim zaczniesz cokolwiek naprawiać, zadaj sobie jedno pytanie: czy te adresy w ogóle powinny być w indeksie? W sklepie na Payload CMS masz zwykle kilka typów stron, które generują się automatycznie - warianty produktów, strony filtrów, tagi, archiwa kategorii z paginacją. Część z nich nie ma prawa rywalizować w wynikach i to jest normalne.

Jeśli status dotyczy strony głównej, kategorii głównej albo kluczowego produktu - to realny problem. Jeśli dotyczy strony filtrowania „kolor: czerwony, rozmiar: M” w sklepie z ubraniami - to nie problem, to naturalny efekt architektury e-commerce.

Sprawdzenie w Search Console krok po kroku

Wejdź w raport Pages (Strony), znajdź kategorię „Crawled - currently not indexed”, kliknij, żeby zobaczyć listę adresów. Nie patrz na liczbę - patrz na to, co jest na liście. Segreguj mentalnie na trzy grupy: strony ważne dla biznesu, strony generowane automatycznie, strony, które w ogóle nie powinny istnieć jako osobne URL-e.

Dla każdej ważnej strony z listy sprawdź w narzędziu URL Inspection, czy Google widzi treść tak, jak chcesz. Czasem renderowanie strony na froncie różni się od tego, co dostaje bot - szczególnie przy komponentach ładowanych po stronie klienta w aplikacjach Next.js.

Robots.txt i meta robots - klasyczne pułapki

W projektach na Payload CMS + Next.js robots.txt bywa generowany dynamicznie albo trzymany w publicznym katalogu. Sprawdź, czy jakaś reguła nie blokuje przypadkiem całej sekcji - np./produkty/*albo/kategoria/*. To się zdarza po migracji albo po zmianie struktury URL, kiedy stara reguła zostaje, a nowa struktura już jej podlega.

Meta robots to druga rzecz do sprawdzenia. Tag noindex w kodzie strony wygrywa z każdą sitemapą i każdym linkowaniem wewnętrznym. Jeśli szablon kolekcji w Payload ustawia go warunkowo - np. dla stron bez opisu - i warunek jest zbyt szeroki, możesz w ten sposób wyłączać z indeksu strony, które chciałbyś mieć widoczne.

Warto też zerknąć na nagłówek X-Robots-Tag wysyłany po stronie serwera. To rzadziej sprawdzana ścieżka, a bywa źródłem problemu, gdy noindex ustawia middleware albo konfiguracja CDN, a nie sam kod strony.

Kanibalizacja - kiedy Google wybiera inną wersję

Częsty scenariusz w sklepach: masz produkt dostępny w trzech kategoriach, każda generuje swój URL do tego samego produktu. Treść identyczna albo prawie identyczna. Google widzi trzy adresy, indeksuje jeden, resztę oznacza jako crawled not indexed - bo z jego perspektywy to duplikat.

To nie błąd algorytmu. To efekt architektury informacji, która nie mówi jasno, który adres jest kanoniczny. Rozwiązanie nie polega na „naprawianiu” każdego z trzech adresów. Polega na decyzji: który URL ma być tym jedynym, i konsekwentnym oznaczeniu tego przez tag canonical.

W Payload CMS łatwo to zepsuć, jeśli kolekcja produktów jest powiązana z kolekcją kategorii przez relację wiele-do-wielu, a każda relacja generuje własną ścieżkę. Warto na poziomie modelu danych zdecydować się na jedną kanoniczną ścieżkę per produkt i renderować resztę jako linki do tego samego adresu, nie jako osobne strony.

Jak to sprawdzić bez zgadywania

Weź adres z listy „crawled not indexed”, wklej treść (albo pierwsze 200-300 słów) do wyszukiwarki w cudzysłowie. Jeśli w wynikach wyskakuje inny Twój adres z bardzo podobną treścią - to kanibalizacja, nie awaria techniczna.

Cienka treść - najczęstszy powód w sklepach

Strona produktu z jednym zdaniem opisu, zdjęciem producenta i tabelą parametrów skopiowaną z karty katalogowej - to jest właśnie to, co Google odrzuca najczęściej. Nie dlatego, że jest „zła” w sensie moralnym. Dlatego, że nie różni się niczym od setek innych stron sprzedających ten sam produkt.

Algorytm nie ocenia długości tekstu jako takiej. Ocenia, czy strona daje coś, czego nie ma gdzie indziej. Krótki, ale unikalny opis z konkretną informacją - wymiary w praktyce, uwaga o pasowaniu, różnica względem podobnego modelu - działa lepiej niż długi tekst złożony z ogólników.

W praktyce sklepów na Payload to często kwestia pola opisu w kolekcji produktów, które jest opcjonalne i łatwo je zostawić puste albo wypełnić automatycznie danymi z feedu producenta. To rozwiązanie wygodne operacyjnie i słabe pod SEO.

Budżet crawlowania i priorytety Googlebota

Google nie ma nieograniczonego czasu na Twoją domenę. Jeśli masz tysiące adresów wygenerowanych przez filtry, paginację i warianty, bot część czasu spędza na nich, a mniej zostaje na strony, które faktycznie chcesz mieć w indeksie. To nie jest kara - to matematyka.

Jeśli sklep generuje dużo adresów o niskiej wartości, warto ograniczyć ich indeksowalność u źródła - przez parametr w URL wykluczony z crawlowania albo przez logikę w Payload, która nie generuje osobnej strony dla każdej kombinacji filtrów, tylko renderuje je jako widok z parametrem, niewłączany do sitemapy.

Kiedy nie warto walczyć o każdą podstronę

To jest część, którą wielu właścicieli sklepów ignoruje, bo brzmi nieintuicyjnie: nie każdy adres zasługuje na indeksację i nie każdy status „crawled not indexed” trzeba naprawiać.

Jeśli masz sklep z 5000 produktów i 200 z nich ma status crawled not indexed, bo to warianty kolorystyczne tego samego modelu z identycznym opisem - nie pisz 200 unikalnych opisów tylko po to, żeby zadowolić algorytm. Skonsoliduj je do jednej strony z wyborem wariantu. To lepsze dla użytkownika i tańsze dla Ciebie niż walka o indeksację duplikatów.

Podobnie ze stronami sezonowymi, promocjami, które trwają tydzień, czy landing page'ami pod jednorazową kampanię reklamową. Jeśli strona ma żyć krótko i ruch przyjdzie z reklamy płatnej, a nie z organika - status w Coverage jest nieistotny. Budżet, który wydałbyś na optymalizację takiej strony pod indeksację, lepiej przeznaczyć na strony z długim cyklem życia.

Realny budżet na porządki indeksacyjne w małym sklepie to zwykle kilka godzin pracy miesięcznie - audyt raportu, poprawki w szablonach, decyzje kanoniczne. Jeśli ktoś proponuje Ci ręczne przeglądanie tysiąca adresów co miesiąc, to zła alokacja czasu. Lepiej naprawić przyczynę w szablonie kolekcji raz, niż gasić pojedyncze pożary.

Co konkretnie zrobić w kolejności

Zacznij od segmentacji listy adresów - ważne, automatyczne, zbędne. Dla ważnych sprawdź robots.txt, meta robots i nagłówek X-Robots-Tag. Dla podejrzenia kanibalizacji sprawdź duplikację treści i ustaw canonical na jeden adres. Dla cienkiej treści - zdecyduj, czy dopisać unikalną wartość, czy skonsolidować stronę z inną.

Na końcu zostaw grupę adresów, których świadomie nie naprawiasz, bo ich obecność w indeksie nie ma wpływu na biznes. To normalny, zdrowy wynik audytu - nie każdy status musi zmienić się na zielony.

FAQ

Czy status crawled not indexed sam się zmieni?

Czasem tak - jeśli treść zyska linki wewnętrzne albo zewnętrzne, albo jeśli Google ponownie oceni stronę po zmianach na całej domenie. Ale liczenie na to bez żadnej akcji rzadko działa przy stronach z realnym problemem treści lub duplikacji.

Ile trzeba czekać po poprawkach, żeby zobaczyć efekt?

Zwykle od kilku dni do kilku tygodni, zależnie od częstotliwości crawlowania domeny. Warto użyć funkcji „Zażądaj indeksowania” w Search Console dla priorytetowych adresów, ale to nie gwarancja, tylko przyspieszenie kolejki.

Czy warto usuwać strony ze statusem crawled not indexed?

Tylko jeśli strona faktycznie nie ma sensu istnieć - np. duplikat po błędzie technicznym. Jeśli strona ma wartość dla użytkownika, ale nie dla algorytmu, lepiej ją poprawić lub skonsolidować niż usunąć.

Czy to wpływa na całą domenę, czy tylko na te adresy?

Bezpośrednio dotyczy tylko wskazanych adresów. Pośrednio - jeśli masz dużo cienkiej treści na dużej części domeny, może to wpływać na ogólną ocenę jakości serwisu przez Google, co odbija się na całości.